etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Dropping DHCP messgaes

[<ke...@us...>]

>Are you sending nisdomain in a parameter request list from Etherboot?

Yes, you have to add the option to the request list in main.c. There are
a couple of initialised arrays which are used to construct the DISCOVER
and REQUEST messages.

Re: [Etherboot-developers] Oversized code

[<ke...@us...>]

>When I try to put other stuff into etherboot, when compile it gives an 
>error of  code size exceed limit, how can I overcome this? This there a 
>physical limit of code size even I have a very large bootrom? Thanks.

The limitation is not the size of the bootrom but the memory area
between 0x94000 and 0xa0000. You have to review your coding practices to
keep memory use down. Large arrays for example are a waste of memory.

Re: [Etherboot-developers] Dropping DHCP messgaes

[Peter L. <P.L...@sy...>]

> Ok, in first32.c of mknbi, I modify it so that is also extract the =

> nisdomain (rfc1533 tag 40)  from the bootp messages. But when using dhc=
p =

> I find the nisdomain tag is missing or empty string. What is the =

> problem? It seems the messages are sent by the dhcp server but the =

> client cannot receive it? Is there a bug in the current ISC dhcpd that =

> use non-standard vendor tag number for nisdomain or it is dropped by =

> etherboot? I just want to make sure what's happening.... Thanks.

Are you using "option dhcp-parameter-request-list" in dhcpd.conf? If so
is the nisdomain code included?

Are you sending nisdomain in a parameter request list from Etherboot?

RFC2132 says...

   9.8. Parameter Request List

   This option is used by a DHCP client to request values for specified
   configuration parameters.  The list of requested parameters is
   specified as n octets, where each octet is a valid DHCP option code
   as defined in this document.

   The client MAY list the options in order of preference.  The DHCP
   server is not required to return the options in the requested order,
   but MUST try to insert the requested options in the order requested
   by the client.

   The code for this option is 55.  Its minimum length is 1.

    Code   Len   Option Codes
   +-----+-----+-----+-----+---
   |  55 |  n  |  c1 |  c2 | ...
   +-----+-----+-----+-----+---

[Etherboot-developers] Oversized code

[David C. <dav...@rc...>]

Dear all,

When I try to put other stuff into etherboot, when compile it gives an 
error of  code size exceed limit, how can I overcome this? This there a 
physical limit of code size even I have a very large bootrom? Thanks.

regards,

DC

Re: [Etherboot-developers] Dropping DHCP messgaes

[David C. <dav...@rc...>]

Ok, in first32.c of mknbi, I modify it so that is also extract the 
nisdomain (rfc1533 tag 40)  from the bootp messages. But when using dhcp 
I find the nisdomain tag is missing or empty string. What is the 
problem? It seems the messages are sent by the dhcp server but the 
client cannot receive it? Is there a bug in the current ISC dhcpd that 
use non-standard vendor tag number for nisdomain or it is dropped by 
etherboot? I just want to make sure what's happening.... Thanks.

regards,

DC

Ken Yap wrote:

>>I cannot find here does the vendor tag goes when ethberboot receive dhcp 
>>messages.. it seems like etherboot somehow drop those packets but I 
>>beleive not, I am sure my dhcp is configured properly, but which part of 
>>the code that I can use to retrieve additional options from the dhcp 
>>messages? Thanks.
>>
>
>Can you explain again please? I didn't understand that.
>
>_______________________________________________
>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] Dopping DHCP messgaes

[<ke...@us...>]

>I cannot find here does the vendor tag goes when ethberboot receive dhcp 
>messages.. it seems like etherboot somehow drop those packets but I 
>beleive not, I am sure my dhcp is configured properly, but which part of 
>the code that I can use to retrieve additional options from the dhcp 
>messages? Thanks.

Can you explain again please? I didn't understand that.

[Etherboot-developers] Dopping DHCP messgaes

[David C. <dav...@rc...>]

Dear all,

I cannot find here does the vendor tag goes when ethberboot receive dhcp 
messages.. it seems like etherboot somehow drop those packets but I 
beleive not, I am sure my dhcp is configured properly, but which part of 
the code that I can use to retrieve additional options from the dhcp 
messages? Thanks.

regards,

David Chow

[Etherboot-developers] Fwd: netbooting memtest86-2.8 failed but fixed

[Hans-Peter J. <hp...@ur...>]

[FYI; send this to Eric, but cc'ed this to the wrong list]

Hi Eric,

just tested the new memtest-2.8 release. 
Tried with etherboot-5.0.2 and 5.0.4.fd0, both with same result:
memtest.img (ELF)... segment below 0x10000
-> back to bootmenu

After setting LOW_TEST_ADR to 0x010000 in defs.h, it finally works.

GREAT! May consider this as the default, or does it any harm
anywhere else?  Otherwise, I think, this is worth a note in the docs.

Thanks a lot
FrisPete

Re: [Etherboot-developers] Booting from /dev/hd[eg] via etherboot 5.0.4

[<ke...@us...>]

>I'm trying to boot locally from /dev/hd[eg] on my Asus A7V133,
>which carries a Promise PDC20268 as the 3rd and 4th IDE controller.

Are you able to boot from these devices from the BIOS, or from LILO? If
not, then you can't boot it from Etherboot, because Etherboot relies on
the BIOS being able to read the disk. The fact that Linux can read them
is not enough as Linux loads its own drivers. In general with ATAPI
BIOSes one can only rely on being able to boot from hda or hdb. Some
controller BIOSes extend this to hdc and hdd.

[Etherboot-developers] Booting from /dev/hd[eg] via etherboot 5.0.4

[Hans-Peter J. <hp...@ur...>]

Hello,

I'm trying to boot locally from /dev/hd[eg] on my Asus A7V133,
which carries a Promise PDC20268 as the 3rd and 4th IDE controller.

I "fixed" main.c the obvious way, but it doesn't work:
[diff fake]

#ifndef CAN_BOOT_DISK
#define loadkernel(s) download((s), downloadkernel)
#else
static int loadkernel(const char *fname)
{
    if (!memcmp(fname,"/dev/",5) && fname[6] == 'd') {
        int dev, part = 0;
        if (fname[5] == 'f') {
            if ((dev = fname[7] - '0') < 0 || dev > 3)
                goto nodisk; }
        else if (fname[5] == 'h' || fname[5] == 's') {
-            if ((dev = 0x80 + fname[7] - 'a') < 0x80 || dev > 0x83)
+            if ((dev = 0x80 + fname[7] - 'a') < 0x80 || dev > 0x87)
                goto nodisk;
            if (fname[8]) {
                part = fname[8] - '0';
                if (fname[9])
                    part = 10*part + fname[9] - '0'; }
            /* bootdisk cannot cope with more than eight partitions */
            if (part < 0 || part > 8)
                goto nodisk; }
        else
            goto nodisk;
        return(bootdisk(dev,part));
    }
nodisk:
    return download(fname, downloadkernel);
}
#endif

I tried with and without a partition nr as boot device, e.g.:
    option vendor-tag-196 "Local hde:::/dev/hde";
    option vendor-tag-197 "Local hdg:::/dev/hdg1";

But it throws an error, when selected:
read error (0X01) Unable to load file
Reading those devices from linux works as expected, and fdisk -l
shows a valid partition table.

Somebody else looked in this before?
Any proposals?

Cheers,
Hans-Peter

[Etherboot-developers] Etherboot now also at berlios.de

[<ke...@us...>]

There is now an alternate Web site for Etherboot at
http://etherboot.berlios.de

BerliOS Developers is hosted at GMD Fokus and uses the same Sourceforge
software for the site.

For the moment, only the download and news facilities of BerliOS will be
used, the mailing lists and other features remain at Sourceforge, to
keep a single site for discussions and to keep the admin work low. It is
hoped that this will help spread the download traffic and make it easier
for European users to fetch packages.

Many thanks to BerliOS for their contribution to the Open Source
community.

Re: [Etherboot-developers] Can i use etherboot on a ARM CPU system?

[<ke...@us...>]

>> >    I know the etherboot is based on x86 cpu system.
>> >But,can i re-compilier it to base on arm cpu system?
>> >If i can,then how to do this?
>> 
>> No, not without tons of work.  Too many x86isms. Read the developers
>> manual for an explanation.  And what is the ARM architecture standard to
>> aim for?
>
>But it should be possible to get it working.  It is just a matter
>of porting etherboot to the ARM.  With linuxBIOS we have shown it will
>work just fine in a stand-alone environment.  So  it matter of porting
>the support infrastructure.  And most hardware platforms have a lot of
>x86'isms, so that shouldn't be too bad.  Basically you need a timer,
>and a way to scan the pci bus.

Sure, I don't want to discourage people from trying, just pointing out
that Etherboot is not an app you can just recompile with a different
compiler target and have it work. It's is very architecture (I wouldn't
say machine, it's not really a machine instruction problem) dependent
program, and you need to understand which bits of it need to be
replaced. At least the bits are fairly well identified, but some
decisions still need to be made about memory placement, etc. Still it
can't get worse than x86 can it? :-)

There's a prize of a mention in the acknowledgements list and also the
announcements page on the web site for the first person to port it to
another architecture, if that is any encouragement. :-) I'm sure the
process will throw light on areas of Etherboot that need improvement.

Re: [Etherboot-developers] Can i use etherboot on a ARM CPU system?

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >hi all:
> >    I know the etherboot is based on x86 cpu system.
> >But,can i re-compilier it to base on arm cpu system?
> >If i can,then how to do this?
> 
> No, not without tons of work.  Too many x86isms. Read the developers
> manual for an explanation.  And what is the ARM architecture standard to
> aim for?

But it should be possible to get it working.  It is just a matter
of porting etherboot to the ARM.  With linuxBIOS we have shown it will
work just fine in a stand-alone environment.  So  it matter of porting
the support infrastructure.  And most hardware platforms have a lot of
x86'isms, so that shouldn't be too bad.  Basically you need a timer,
and a way to scan the pci bus.

Eric

Re: [Etherboot-developers] Boot LynxOS with etherboot

[<ke...@us...>]

>Hi all,
>
>with the following patch it is possible to boot
>a LynxOS KDI image with etherboot. The patch is
>against 5.0.4, maybe you like to implement this feature.
>In case of response, please CC me, I'm not on the list.

Seems reasonable. I'll put it in the next release. Thanks.

[Etherboot-developers] Boot LynxOS with etherboot

[Armin S. <ac...@sy...>]

Hi all,

with the following patch it is possible to boot
a LynxOS KDI image with etherboot. The patch is
against 5.0.4, maybe you like to implement this feature.
In case of response, please CC me, I'm not on the list.

Regards,

Armin Schindler <ac...@sy...>
Sysgo RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany
phone: +49 6136 9948-0
fax  : +49 6136 9948-10

--------------------------------------

diff -ur etherboot-5.0.4_orig/src/Config etherboot-5.0.4/src/Config
--- etherboot-5.0.4_orig/src/Config	Thu Sep 13 06:25:11 2001
+++ etherboot-5.0.4/src/Config	Thu Sep 20 15:28:00 2001
@@ -239,8 +239,9 @@
 
 # Enable tagged image, generic ELF, Multiboot ELF
 # or FreeBSD ELF/a.out boot image support
-CFLAGS32+=	-DTAGGED_IMAGE -DELF_IMAGE
-# CFLAGS32+=	-DAOUT_IMAGE -DIMAGE_MULTIBOOT -DIMAGE_FREEBSD
+#CFLAGS32+=	-DTAGGED_IMAGE -DELF_IMAGE
+#CFLAGS32+=	-DAOUT_IMAGE -DIMAGE_MULTIBOOT -DIMAGE_FREEBSD
+CFLAGS32+=	-DAOUT_IMAGE -DAOUT_LYNX_KDI
 
 # Change download protocol to NFS, default is TFTP
 # CFLAGS32+=	-DDOWNLOAD_PROTO_NFS
Only in etherboot-5.0.4/src: Config~
diff -ur etherboot-5.0.4_orig/src/osloader.c etherboot-5.0.4/src/osloader.c
--- etherboot-5.0.4_orig/src/osloader.c	Thu Aug  2 01:42:57 2001
+++ etherboot-5.0.4/src/osloader.c	Thu Sep 20 16:00:37 2001
@@ -405,10 +405,25 @@
 			longjmp(restart_etherboot, -2);
 		}
 #endif
+#ifdef AOUT_LYNX_KDI
+			(*entry)();
+#endif
 		printf("unexpected a.out variant\n");
 		longjmp(restart_etherboot, -2);
 	}
 	offset = 0;
+
+#ifdef AOUT_LYNX_KDI
+  segment++;
+  if (segment == 0) {
+    curaddr = 0x100000;
+		info.head.a_entry = curaddr + 0x20;
+  }
+	memcpy((void *)curaddr, data, len);
+	curaddr += len;
+	return 1;
+#endif
+
 	do {
 		if (segment != -1) {
 			if (skip) {

Re: [Etherboot-developers] Can i use etherboot on a ARM CPU system?

[<ke...@us...>]

>hi all:
>    I know the etherboot is based on x86 cpu system.
>But,can i re-compilier it to base on arm cpu system?
>If i can,then how to do this?

No, not without tons of work.  Too many x86isms. Read the developers
manual for an explanation.  And what is the ARM architecture standard to
aim for?

[Etherboot-developers] Can i use etherboot on a ARM CPU system?

[yujyh <yu...@li...>]

hi all:
    I know the etherboot is based on x86 cpu system.
But,can i re-compilier it to base on arm cpu system?
If i can,then how to do this?

[Etherboot-developers] HELP ME ! error in bootrom RTL8139

[Alexander <ra...@ma...>]

error in bootrom RTL8139

after choice in Boot Agent Configuration MENU (shift + F10): PXE, INT19
(Always Boot Network First, then local devices)

From BIOS:
Intel UNDI PXE-2.0 Build 082
Copyright (C) 1997-2000 Intel Corporaton
For Realtek RTL8139(A/B/C/8130) Based Fast Ethernet Controller v2.11
(001205)

PXE-EC1: Base-Code ROM ID structure was not found.
PXE-M0F: Exiting PXE ROM

What can i do to get normal prompt about DHCP and TFTP services?
Or it shows me, that this adapter isn' have the bootrom?
Plese, send me utils for operation with etherboot, if it help in my case.

My hardware:
PC-BOOK
Model : BKi810 (made in China)
5.1 Chanel

chipset 810E
net adapter onboard


With BEST REGARD Alexander Rudakov

Re: [Etherboot-developers] Cisco Aironet-Cards

[Doug A. <amb...@am...>]

Andreas Schlager writes:
| I have here a RF-device w/ a cisco aironet 340 series PCMCIA-card. I 
| want to use Etherboot to boot off from a linux-box. 
| 
| Does anyone have gotten this thing running w/o getting nuts?
| Is there a chance?

Well, there is support for doing Etherboot on an Airport Base Station
with the Lucent card.  Similar work could be extended to the Aironet
card.  I forget the details to get the PCMCIA adapter up and running.
That is the first part and then get the card working.  Since PCMCIA
adapter hardware varies greatly that would be the biggest challenge.
Look at the code in any open source OS for handling PCMCIA cards for
an idea of the complexity.

Doug A.

[Etherboot-developers] Cisco Aironet-Cards

[Andreas S. <asc...@ka...>]

Hi there,

I have here a RF-device w/ a cisco aironet 340 series PCMCIA-card. I 
want to use Etherboot to boot off from a linux-box. 

Does anyone have gotten this thing running w/o getting nuts?
Is there a chance?

Pls help!!!!

Tnx,

Andreas.

Re: [Etherboot-developers] EEPRO100.C PCI activiation

[<ke...@us...>]

>So what do other think?  Should we consider creating some core routines 
>to give a little more consistency and simplicity to the driver probe 
>code?  Or since it's a small amount of code, and drivers are 
>comparmentalized, just let it go. If you have an opinion, please let us 
>hear it.

I think some common utility routines should be created to do these jobs
and the code in the drivers replaced by calls. It doesn't matter if they
are true routines or inline since the ROM has only one driver. I guess
pci.[ch] are the places to put them.

Re: [Etherboot-developers] EEPRO100.C PCI activiation

[<ebi...@ln...>]

Christoph Plattner <chr...@al...> writes:

> Hello Etherboot Hackers !
> 
> Have a look at eepro100.c in the eepro100_probe():
> 
> 
>         /* From Matt Hortman <mbh...@ac...> */
>         if (p->dev_id == PCI_DEVICE_ID_INTEL_82557 ) {
>                 /*
>                 * check to make sure the bios properly set the
>                 * 82557 (or 82558) to be bus master
>                 *
>                 * from eepro100.c in 2.2.9 kernel source
>                 */
> 
> 		code
> 		code
>         }
> 
> 
> Why is this code only done for 82775 and not all derivates.

Because it was initialially coded that way.  There is no good reason
for it.

> Should there not be all chips of the familiy in the "if" ?

yes.

> An interesting thing: We are working on a prototype version
> of a new built hardware using the i82559ER. On prototype A
> the NIC works, on protoype B, the problem occurs. So there
> is a depenceny on BIOS and hardware mapping of addresses, etc...

It is a BIOS dependency.  And removing the if should remove that
dependency.  Though after I ported this code to the 3com series
nics that this should really be a generic routine like the 2.4
pci_set_master() that gets called instead of nic dependant code.

Eric

Re: [Etherboot-developers] EEPRO100.C PCI activiation

[Marty C. <md...@th...>]

On 10/8/2001 11:34 AM Christoph Plattner chr...@al... 
wrote:
>An interesting thing: We are working on a prototype version
>of a new built hardware using the i82559ER. On prototype A
>the NIC works, on protoype B, the problem occurs. So there
>is a depenceny on BIOS and hardware mapping of addresses, etc...

I think the PCI detection code should not be driver specific, except in 
truly bizarre cases.  I need to go through all the PCI drivers and see 
which ones are doing:

    /* from tulip driver */
    if (io_addrs == 0 || *io_addrs == 0)
        return 0;

------------

and which ones are doing stuff like this:

        /* rtl8139 driver */
        if (probeaddrs == 0 || probeaddrs[0] == 0) {
                printf("\nERROR: no probeaddrs given, using 
pci_device\n");
                for (p = pci; p->vendor; p++) {
                        if ( ( (p->vendor == PCI_VENDOR_ID_REALTEK)
                            && (p->dev_id == PCI_DEVICE_ID_REALTEK_8139) )
                          || ( (p->vendor == PCI_VENDOR_ID_SMC_1211)
                            && (p->dev_id == PCI_DEVICE_ID_SMC_1211) ) ) {
                                probeaddrs[0] = p->ioaddr;
                                printf("rtl8139: probing %hX (membase 
%hX)\n",
                                        p->ioaddr, p->membase);
                        }
                }
                return 0;
        }

In the RTL case, I think we should do this in the core.  If the correct 
vendor IDs aren't in config.c, then we should add them there so the 
driver won't have to know do stuff like this.

---------------

Or how about this in the eepro100 driver:

Below, the problem isn't that the card isn't found, it's that the card 
isn't set to be bus mastering, and then the PCI latency is sanity 
checked. I think Eric suggested adding a core routine that can be called 
that does this consistently for any cards that need it.  I suspect that 
it was a hack for someone's broken BIOS, and they would have the same 
trouble if they had other PCI cards as well.

        /* eepro100 */
        if (probeaddrs == 0 || probeaddrs[0] == 0)
                return 0;

        ioaddr = probeaddrs[0] & ~3; /* Mask the bit that says "this is 
an io addr\
" */

        /* From Matt Hortman <mbh...@ac...> */
        if (p->dev_id == PCI_DEVICE_ID_INTEL_82557 ) {
                /*
                * check to make sure the bios properly set the
                * 82557 (or 82558) to be bus master
                *
                * from eepro100.c in 2.2.9 kernel source
                */

                pcibios_read_config_word(p->bus, p->devfn, PCI_COMMAND, 
&pci_comma\
nd);
                new_command = pci_command | 
PCI_COMMAND_MASTER|PCI_COMMAND_IO;

                if (pci_command != new_command) {
                        printf("\nThe PCI BIOS has not enabled this 
device!\nUpdat\
ing PCI command %hX->%hX. pci_bus %hhX pci_device_fn %hhX\n",
                                   pci_command, new_command, p->bus, 
p->devfn);
                        pcibios_write_config_word(p->bus, p->devfn, 
PCI_COMMAND, n\
ew_command);
                }

                pcibios_read_config_byte(p->bus, p->devfn, 
PCI_LATENCY_TIMER, &pci\
_latency);
                if (pci_latency < 32) {
                        printf("\nPCI latency timer (CFLT) is 
unreasonably low at \
%d. Setting to 32 clocks.\n", pci_latency);
                        pcibios_write_config_byte(p->bus, p->devfn, 
PCI_LATENCY_TI\
MER, 32);
                }
        }

------------

and how about this one from via-rhine.c:

Here it first checks for bus master (like in the eepro100 driver), and 
then for  and unreasonably small PCI latency value. Sounds like a good 
candidate for a couple of core PCI routines.

    if (!pci->ioaddr)
        return NULL;
    nic = rhine_probe1 (nic, pci->ioaddr, 0, -1);

    if (nic)
    {
        /* Get and check the bus-master and latency values. */
        pcibios_read_config_word (pci->bus, pci->devfn, PCI_COMMAND, 
&pci_command)\
;
        if (!(pci_command & PCI_COMMAND_MASTER))
        {
            printf ("  PCI Master Bit has not been set! Setting...\n");
            pci_command |= PCI_COMMAND_MASTER;
            pcibios_write_config_word (pci->bus, pci->devfn, PCI_COMMAND,
                                       pci_command);
        }
        pcibios_read_config_byte (pci->bus, pci->devfn, PCI_LATENCY_TIMER,
                                  &pci_latency);
        if (pci_latency < 10)
        {
            printf ("  PCI latency timer (CFLT) is unreasonably low "
                    "at %d.  Setting to 64 clocks.\n", pci_latency);
            pcibios_write_config_byte (pci->bus, pci->devfn, 
PCI_LATENCY_TIMER, 64\
);
        }
        else if (rhine_debug > 1)
            printf ("  PCI latency timer (CFLT) is %#hX.\n", pci_latency);
    }

--------------

So what do other think?  Should we consider creating some core routines 
to give a little more consistency and simplicity to the driver probe 
code?  Or since it's a small amount of code, and drivers are 
comparmentalized, just let it go. If you have an opinion, please let us 
hear it.

Marty



---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] EEPRO100.C PCI activiation

[Christoph P. <chr...@al...>]

Hello Etherboot Hackers !

Have a look at eepro100.c in the eepro100_probe():


        /* From Matt Hortman <mbh...@ac...> */
        if (p->dev_id == PCI_DEVICE_ID_INTEL_82557 ) {
                /*
                * check to make sure the bios properly set the
                * 82557 (or 82558) to be bus master
                *
                * from eepro100.c in 2.2.9 kernel source
                */

		code
		code
        }


Why is this code only done for 82775 and not all derivates.
I tried to use a 82559ER which was NOT able to run etherboot.
The chip was found, mac address, etc, was read out, but writing
a command to the chips, the CMD registers does not get 0 after 
writing to it. And the return STATUS register was always 0.

In the GRUB I used a local patch in the eepro100 driver with the 
lines:

	if ((p->dev_id == PCI_DEVICE_ID_INTEL_82557 ) || 
	    (p->dev_id == PCI_DEVICE_ID_INTEL_82559er) ) {
		/*
		* check to make sure the bios properly set the

... and here the chip works.

Should there not be all chips of the familiy in the "if" ?

An interesting thing: We are working on a prototype version
of a new built hardware using the i82559ER. On prototype A
the NIC works, on protoype B, the problem occurs. So there
is a depenceny on BIOS and hardware mapping of addresses, etc...

Bye
	Christoph P.


-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

[Etherboot-developers] ROM-o-matic.net update Etherboot 5.0.4,5.0.4-mc1

[Marty C. <md...@th...>]

I've updated http://www.rom-o-matic.net/ with the latest production 
release of Etherboot, version 5.0.4

I've also created an experimental version, 5.0.4-mc1 specifically for 
people who have trouble with Netgear FA310TX and other LC82C168/169 based 
cards, using the "tulip" driver.  Other than that, it's identical to 
5.0.4.

Please try these releases out, and report new-successes/problems to the 
Etherboot-Users list.

Thanks for your help,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/