etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.7rc2 at rom-o-matic

[Eric W B. <ebi...@ln...>]

Marty Connor <ma...@et...> writes:

> I'm wondering if anyone is successfully making LinuxBIOS ROM images at
> rom-o-matic.net.
> 
> I was toying with adding some logic that says "if the user chooses a
> LinuxBIOS output format, override PCBIOS option and set LINUXBIOS
> instead", but I don't know the right options to get a successful build. 
> I don't really want to override user-supplied options, so perhaps I
> should put out a message upon a failed LinuxBIOS build that says
> "LinuxBIOS requires special options to be set, please consult a LinuxBIOS
> expert." or something.
> 
> Any advice would be appreciated.  I'm hoping that someone on the
> linuxbios mailing list has explained the right options to check and
> uncheck and people are actually succeeding. If not, perhaps we can figure
> out how best to fix things. 

There is a commented line in Config that has a recommended set of options
for a LinuxBIOS build.  You can start there.

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

[Eric W B. <ebi...@ln...>]

<ja...@Mc...> writes:

> On Sat, 13 Jul 2002, Ken Yap wrote:
> 
> > 
> > Eric, you're a genius. (Sound of me hitting side of head muttering why
> > didn't I think of that, like when Marty explained rom-o-matic.)

Does any have some ice so I can keep all of these comments
from going to my head and swelling it up?

> > No server IP (all zeros) -> ignore offer
> > No filename and DEFAULT_BOOTFILE not defined -> ignore offer
> > 
> > But Jim, you're still going to have to fix the dhcpclient in the LTSP
> > initrd.
> 
> Yes, I know.  I wonder if eric knows a way to squeeze more hours
> into a day, so I can do all the things that I need to do. :)

I do know that dhclient has the ability to do interesting filtering
of dhcp requests.  So you can ignore selected servers.

Eric

[Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.7rc2 at rom-o-matic

[Marty C. <ma...@et...>]

I'm wondering if anyone is successfully making LinuxBIOS ROM images at
rom-o-matic.net.

I was toying with adding some logic that says "if the user chooses a
LinuxBIOS output format, override PCBIOS option and set LINUXBIOS
instead", but I don't know the right options to get a successful build. 
I don't really want to override user-supplied options, so perhaps I
should put out a message upon a failed LinuxBIOS build that says
"LinuxBIOS requires special options to be set, please consult a LinuxBIOS
expert." or something.

Any advice would be appreciated.  I'm hoping that someone on the
linuxbios mailing list has explained the right options to check and
uncheck and people are actually succeeding. If not, perhaps we can figure
out how best to fix things. 

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: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] Re: Looking in all the wrong places

[Marty C. <ma...@et...>]

On Sat, 13 Jul 2002 23:58:10 +1000 Ken Yap
<ke...@us...> wrote:
>I don't think 5.1.2rc1 needs to be put on rom-o-matic. It offers nothing
>beyond 5.0.7rc2 until someone has written a multicast server and even
>then only for one model of NIC.

OK.  I'll focus on 5.0.7rc2.  I like the idea about Etherboot being more
selective about which DHCP servers it responds to, btw.  There's been a
ton of great work going on, and it's nice to see people enjoying
themselves while hacking.  It will be fun to demo at LinuxWorld SF next
month.  I hope I can get the wireless stuff to work so we can show that
as well.  Maybe I can get Michael Brown to help me if I get stuck ;)

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: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] Re: Looking in all the wrong places

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

>Thanks.  It's Saturday morning here, and I'm about to start working on
>5.0.7 support for rom-o-matic.  I'll let you know when it's up.  I'll
>also take a look at 5.1.  Let's see how it goes.

I don't think 5.1.2rc1 needs to be put on rom-o-matic. It offers nothing
beyond 5.0.7rc2 until someone has written a multicast server and even
then only for one model of NIC.

[Etherboot-developers] Re: Looking in all the wrong places

[Marty C. <ma...@et...>]

On Sat, 13 Jul 2002 17:33:53 +1000 Ken Yap
<ke...@us...> wrote:
>Ok, done. CVS has been updated for both 5.0 and 5.1. Marty, the tarball
>is in the top directory of the website. No PHP changes are needed, the
>DEFAULT_BOOTFILE define was not in Config anyway.

Thanks.  It's Saturday morning here, and I'm about to start working on
5.0.7 support for rom-o-matic.  I'll let you know when it's up.  I'll
also take a look at 5.1.  Let's see how it goes.

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: ma...@et...
    Web: http://www.etherboot.org/

Re: [Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

[<ja...@Mc...>]

On Sat, 13 Jul 2002, Ken Yap wrote:

> 
> Eric, you're a genius. (Sound of me hitting side of head muttering why
> didn't I think of that, like when Marty explained rom-o-matic.)
> 
> No server IP (all zeros) -> ignore offer
> No filename and DEFAULT_BOOTFILE not defined -> ignore offer
> 
> But Jim, you're still going to have to fix the dhcpclient in the LTSP
> initrd.

Yes, I know.  I wonder if eric knows a way to squeeze more hours
into a day, so I can do all the things that I need to do. :)

Jim.

Re: [Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

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

>Ok, this will be the 5.0.7 behaviour:
>
>No server IP (all zeros) -> ignore offer
>No filename and DEFAULT_BOOTFILE not defined -> ignore offer
>
>Anybody who wants the fallback filename will have to edit etherboot.h
>and uncomment the #define.

Ok, done. CVS has been updated for both 5.0 and 5.1. Marty, the tarball
is in the top directory of the website. No PHP changes are needed, the
DEFAULT_BOOTFILE define was not in Config anyway.

Re: [Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

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

>I like the idea.
>
>In LTSP we always depend on a filename being sent.

Eric, you're a genius. (Sound of me hitting side of head muttering why
didn't I think of that, like when Marty explained rom-o-matic.)

Ok, this will be the 5.0.7 behaviour:

No server IP (all zeros) -> ignore offer
No filename and DEFAULT_BOOTFILE not defined -> ignore offer

Anybody who wants the fallback filename will have to edit etherboot.h
and uncomment the #define.

But Jim, you're still going to have to fix the dhcpclient in the LTSP
initrd.

Marty, give me a sec to put up the new tarball.

Re: [Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

[<ja...@Mc...>]

I like the idea.

In LTSP we always depend on a filename being sent.

Jim McQuillan
ja...@Lt...


On Sat, 13 Jul 2002, Ken Yap wrote:

> >Ken for 5.2 would it make sense to always require a non-null filename?
> >In most cases this would remove the need for REQUIRE_VCI_ETHERBOOT,
> >and the setup is some simpler.
> 
> Wait, I think I understand what you're trying to say. You mean take the
> absence of a filename (or perhaps of a useful IP also) to indicate a
> DHCP server we should ignore and wait for another reply from a DHCP
> server we control. Our DHCP server would still have to be careful not to
> assign IPs to clients we don't care about, but this can be done by
> looking for the Vendor Indentifier of Etherboot which is always sent or
> by using MAC addresses. That sounds reasonable.  I think the fallback to
> /tftpboot/kernel is marginally useful anyway.  What is the experience of
> other developers? If it's a good idea, it can even go into 5.0.7.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Gadgets, caffeine, t-shirts, fun stuff.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

-- 

[Etherboot-developers] Re: [Etherboot-users] Looking in all the wrong places

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

>Ken for 5.2 would it make sense to always require a non-null filename?
>In most cases this would remove the need for REQUIRE_VCI_ETHERBOOT,
>and the setup is some simpler.

Wait, I think I understand what you're trying to say. You mean take the
absence of a filename (or perhaps of a useful IP also) to indicate a
DHCP server we should ignore and wait for another reply from a DHCP
server we control. Our DHCP server would still have to be careful not to
assign IPs to clients we don't care about, but this can be done by
looking for the Vendor Indentifier of Etherboot which is always sent or
by using MAC addresses. That sounds reasonable.  I think the fallback to
/tftpboot/kernel is marginally useful anyway.  What is the experience of
other developers? If it's a good idea, it can even go into 5.0.7.

[Etherboot-developers] can't boot with my laptop ...

[Peter S. <dvr...@se...>]

Hello!

I have a laptop with a internal Accton EN2242 Serie Mini-PCI-Fast Ethernet
Adapter. Windows use the ADMtek an983 NIC driver. I also use this driver
from the etherboot project to create a floppy image to boot my laptop over
the network. But if i start them with the Floppy, it always tells me, that
he can't find the card.
Can you help me how i can boot over the network my laptop?

regards

Peter

Re: [Etherboot-developers] [RFC] Relocation techniques...

[Michael B. <mb...@fe...>]

On Thu, 11 Jul 2002, Peter Lister wrote:
> Anyway, networks being what they are, dropouts are expected and packets
> just get resent. After all, there is no restriction on restarting the
> NFS *server*, right? :)

Yep, done that one.  Accidentally rebooted the server providing / for 120
diskless clients.  All suspended for two minutes and then picked up from
where they left off.  Very impressive.

> > 2a. If you didn't already have a dhcpd.conf then one will have been
> >     created for you based on your network configuration.  Just uncomment
> >     and edit the "range" line and then restart dhcpd.
> > *or*
> > 2b. If you did already have a dhcpd.conf file then just add the line
> >     "include /etc/dhcpd.conf.etherboot.include;" somewhere and restart
> >     dhcpd.
> I'm sure what you have done is fine but I've had practical experience of
> an automatic dhcp configuration which automatically stomped on my dhcp
> config because it was not what the installation "expected". Even
> included files can cause dhcpd to not work, although they limit damage.

I've been fairly careful: the included file doesn't do anything to clients
that aren't Etherboot or udhcpc.  It won't touch your existing config if
you already have one; you have to add the include yourself.

My approach is currently being integrated into Mandrake, according to the
most recent Mandrake Newsletter.

> Extension Path (option 18) should be a much safer way to add dhcp config
> chunks (see recent rant on ltsp-discuss) and need not even be done on
> the machine running the dhcp server. I'll play with the Perl stuff;
> producing raw DHCP options is quite easy, and it should be fairly
> straightfoward to make it emit ISC dhcpd language, so we can have a
> choice.

I've already produced something that does this based on GNU m4.  You can
use the same code to produce either DHCP extension path files or
straightforward ANSI include files.  An example m4 file looks like:

motd(`graphicsmode(80,30,16)`'white`'bgwhite`'cls`'includefile(``backdrop.ansi'')')
menu(`1',``linux'',`Linux',,,,,,`devfs=mount')

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

> Is it possible to unload and reload the network driver that is connecting
> you to your root file system?

Linux has become a bit more careful about whether one can ifconfig down
a net driver which is in use, but since (unlike char and block devices)
there is no direct association between a network connection / socket and
the driver, then in principle yes. Even if not, it is easy enough to
create a "root" net device which can be mapped to the whichever net dev
is appropriate, in the same way that /dev/console is a way of
indirecting console output to /dev/tty0 or /dev/ttyS0 rather than
mapping to a physical device.

Anyway, networks being what they are, dropouts are expected and packets
just get resent. After all, there is no restriction on restarting the
NFS *server*, right? :) Personally I'd never use NFS for a root fs if I
could avoid it. Life easier would be easier if the root were a ramdisk,
or a network FS which likes to cache locally and doesn't mind extended
network outages.

> 2a. If you didn't already have a dhcpd.conf then one will have been
>     created for you based on your network configuration.  Just uncomment
>     and edit the "range" line and then restart dhcpd.
> *or*
> 2b. If you did already have a dhcpd.conf file then just add the line
>     "include /etc/dhcpd.conf.etherboot.include;" somewhere and restart
>     dhcpd.

I'm sure what you have done is fine but I've had practical experience of
an automatic dhcp configuration which automatically stomped on my dhcp
config because it was not what the installation "expected". Even
included files can cause dhcpd to not work, although they limit damage.

Extension Path (option 18) should be a much safer way to add dhcp config
chunks (see recent rant on ltsp-discuss) and need not even be done on
the machine running the dhcp server. I'll play with the Perl stuff;
producing raw DHCP options is quite easy, and it should be fairly
straightfoward to make it emit ISC dhcpd language, so we can have a
choice.

Re: [Etherboot-developers] [RFC] Relocation techniques...

[Michael B. <mb...@fe...>]

On Thu, 11 Jul 2002, Peter Lister wrote:
> > > I agree with what you say, Eric, but this implies complexity on the
> > > dhcp server side to give out images with the right driver. People find
> > > that complicated, so there will be pressure to supply use the initial
> > > firmware driver to be nicely device indepedent.
> > It's not complicated to set up DHCPD to do this; you can find code that
> > will automate it completely in contrib/initrd.
> *I* know that, *you* know that, *Eric* knows that. :)
> <snip>
> WRT safety of design, Eric's absolutely right, though it's worth noting
> that the "opposition" is PXE so the quality threshold is not high. :) I
> think my point is valid; a user who doesn't know much *does* know that
> PXE lets him not worry about which driver to use, so that many people
> will expect drivers to stay resident. Even if one's net booting a full
> Linux kernel, using an EB driver is still useful. If a Linux 'driver'
> for the EB driver using is built in, the kernel can use the EB driver
> for its initial DHCP config; the system can boot and then dynamically
> load a better network driver module later on.

Is it possible to unload and reload the network driver that is connecting
you to your root file system?

> > As is, this will create NBI files for each network module and will
> > provide dhcpd.conf fragments that deal with automatically selecting
> > the correct NBI based on the PCI/ISA IDs that Etherboot sends.  (I
> > need to update this to use the new binary structures.)
> If new LTSP users can automagically get something that just works, then
> that's a significant step forward, but my perception is that most people
> find dhcp voodoo a bit scary, especially if it seems that they have to
> do (as they see it) dangerous things before anything good happens. Yes,
> it's a dhcp server config issue, but we still have to cope with it.

It's pretty automagic.  Steps to get a working terminal server the way
I've done it are:

1. Install the terminal-server package (which will drag in mkinitrd-net
   as well).

2a. If you didn't already have a dhcpd.conf then one will have been
    created for you based on your network configuration.  Just uncomment
    and edit the "range" line and then restart dhcpd.
*or*
2b. If you did already have a dhcpd.conf file then just add the line
    "include /etc/dhcpd.conf.etherboot.include;" somewhere and restart
    dhcpd.

3. It works.  Honestly, that's all you need to do.

NBI images are created automatically and selected automatically via the
dhcpd.conf.etherboot.include file and the
dhcpd.conf.etherboot-pcimap.include file that mkinitrd-net generates
(which dhcpd.conf.etherboot.include includes!).  You really don't need to
know any of the intimate details to get it working.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

Peter Lister <P.L...@sy...> writes:

> > On Mon, 8 Jul 2002, Peter Lister wrote:
> > > > Alternatively the type of NIC is supplied in the DHCP query.
> > > .
> > > > Given that it is safer for the loaded image to bring along it's
> > > > network driver, and stack, because the loaded image can be recompiled
> > > > and fixed.
> > > I agree with what you say, Eric, but this implies complexity on the
> > > dhcp server side to give out images with the right driver. People find
> > > that complicated, so there will be pressure to supply use the initial
> > > firmware driver to be nicely device indepedent.
> > 
> > It's not complicated to set up DHCPD to do this; you can find code that
> > will automate it completely in contrib/initrd.
> 
> *I* know that, *you* know that, *Eric* knows that. :)
> 
> But sites regard DHCP servers as critical, and have strict "no buggering
> around" rules on amending the main server which handles leases or
> setting up another config only server which should respond only to
> requests with the EB VCI. The worst effect of all is if an adventurous
> sysadmin trying non MS code for the first time gets his fingers burned
> and his MS fixated boss decides that it's a sacking offence to run
> another dhcp server.
> 
> WRT safety of design, Eric's absolutely right, though it's worth noting
> that the "opposition" is PXE so the quality threshold is not high. :) I
> think my point is valid; a user who doesn't know much *does* know that
> PXE lets him not worry about which driver to use, so that many people
> will expect drivers to stay resident. Even if one's net booting a full
> Linux kernel, using an EB driver is still useful. If a Linux 'driver'
> for the EB driver using is built in, the kernel can use the EB driver
> for its initial DHCP config; the system can boot and then dynamically
> load a better network driver module later on.

On the side of callbacks.  I have already decided that I won't write
code that prevents them from working, at this point.  At the same time
I won't code the support either.
 
> > As is, this will create NBI files for each network module and will
> > provide dhcpd.conf fragments that deal with automatically selecting
> > the correct NBI based on the PCI/ISA IDs that Etherboot sends.  (I
> > need to update this to use the new binary structures.)
> 
> If new LTSP users can automagically get something that just works, then
> that's a significant step forward, but my perception is that most people
> find dhcp voodoo a bit scary, especially if it seems that they have to
> do (as they see it) dangerous things before anything good happens. Yes,
> it's a dhcp server config issue, but we still have to cope with it.

Or fix it.  If the problem is the dhcp server that is what should
be fixed.

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

> On Mon, 8 Jul 2002, Peter Lister wrote:
> > > Alternatively the type of NIC is supplied in the DHCP query.
> > .
> > > Given that it is safer for the loaded image to bring along it's
> > > network driver, and stack, because the loaded image can be recompiled
> > > and fixed.
> > I agree with what you say, Eric, but this implies complexity on the
> > dhcp server side to give out images with the right driver. People find
> > that complicated, so there will be pressure to supply use the initial
> > firmware driver to be nicely device indepedent.
> 
> It's not complicated to set up DHCPD to do this; you can find code that
> will automate it completely in contrib/initrd.

*I* know that, *you* know that, *Eric* knows that. :)

But sites regard DHCP servers as critical, and have strict "no buggering
around" rules on amending the main server which handles leases or
setting up another config only server which should respond only to
requests with the EB VCI. The worst effect of all is if an adventurous
sysadmin trying non MS code for the first time gets his fingers burned
and his MS fixated boss decides that it's a sacking offence to run
another dhcp server.

WRT safety of design, Eric's absolutely right, though it's worth noting
that the "opposition" is PXE so the quality threshold is not high. :) I
think my point is valid; a user who doesn't know much *does* know that
PXE lets him not worry about which driver to use, so that many people
will expect drivers to stay resident. Even if one's net booting a full
Linux kernel, using an EB driver is still useful. If a Linux 'driver'
for the EB driver using is built in, the kernel can use the EB driver
for its initial DHCP config; the system can boot and then dynamically
load a better network driver module later on.

> As is, this will create NBI files for each network module and will
> provide dhcpd.conf fragments that deal with automatically selecting
> the correct NBI based on the PCI/ISA IDs that Etherboot sends.  (I
> need to update this to use the new binary structures.)

If new LTSP users can automagically get something that just works, then
that's a significant step forward, but my perception is that most people
find dhcp voodoo a bit scary, especially if it seems that they have to
do (as they see it) dangerous things before anything good happens. Yes,
it's a dhcp server config issue, but we still have to cope with it.

[Etherboot-developers] Why are HGH products different?

[Staff <Hea...@om...>]

SGkNCg0KPGh0bWw+DQoNCjxoZWFkPg0KDQo8bWV0YSBodHRwLWVxdWl2PSJD
b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5k
b3dzLTEyNTIiPg0KDQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9
Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCg0KPG1ldGEgbmFtZT0iUHJv
Z0lkIiBjb250ZW50PSJGcm9udFBhZ2UuRWRpdG9yLkRvY3VtZW50Ij4NCg0K
PHRpdGxlPlRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQgdHlwZXMgb2YgSEdI
IHByb2R1Y3RzPC90aXRsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBiYWNrZ3Jv
dW5kPSJjbG91ZHMuanBnIj4NCg0KPHA+PGZvbnQgc2l6ZT0iNCI+PGZvbnQg
Y29sb3I9IiM4MDAwMDAiPjxiPlRoZXJlIGFyZSB0aHJlZSBkaWZmZXJlbnQg
dHlwZXMgb2YNCg0KSEdIIHByb2R1Y3RzLjwvYj48L2ZvbnQ+PGJyPg0KDQpU
aGUgY29uZnVzaW9uIGlzIHRoYXQgYWxsIHRocmVlIGFyZTxicj4NCg0KYWR2
ZXJ0aXNlZCBhcyBpZiB0aGV5IHdlcmUgdGhlIHNhbWUuPC9mb250Pjxicj4N
Cg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgPHU+VGhlIHRocmVlIHR5cGVzIGFyZTo8L3U+PGJy
Pg0KDQombmJzcDs8YnI+DQoNCjxiPjEpPC9iPiAtLS0gPGZvbnQgY29sb3I9
IiMwMDAwRkYiPjxiPkhvbWVvcGF0aGljIEhHSDwvYj48L2ZvbnQ+PGJyPg0K
DQo8Yj4yKTwvYj4gLS0tIDxmb250IGNvbG9yPSIjMDAwMEZGIj48Yj5QcmUt
Y3Vyc29yIEhHSDwvYj48L2ZvbnQ+PGJyPg0KDQo8Yj4zKTwvYj4gLS0tIDxm
b250IGNvbG9yPSIjMDAwMEZGIj48Yj5SZWFsIG9yIHN5bnRoZXRpYyBIR0g8
L2I+PC9mb250Pg0KDQooZGVsaXZlcmVkIGJ5IGluamVjdGlvbjxicj4NCg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9y
LCBieSBhbiBvcmFsIHNwcmF5IG1ldGhvZCkuPGJyPg0KDQombmJzcDs8YnI+
DQoNCkRvIHlvdSBrbm93IGRpZmZlcmVuY2VzPzxicj4NCg0KJm5ic3A7PGJy
Pg0KDQpDYWxsIHVzIGFuZCB3ZSdsbCBleHBsYWluIHRoZW0gdG8geW91Ljxi
cj4NCg0KJm5ic3A7PGJyPg0KDQpPdXIgdG9sbCBmcmVlIG51bWJlciBpcyA8
Zm9udCBjb2xvcj0iIzAwMDA4MCI+PGI+MS04ODgtNjIxLTczMDA8L2I+PC9m
b250Pjxicj4NCg0KQW4gSEdIIHN0YWZmIG1lbWJlciBpcyBhdmFpbGFibGU8
YnI+DQoNCjkgdG8gNSBQYWNpZmljIFRpbWUuPGJyPg0KDQpJZiBhZnRlciBo
b3VycywgcGxlYXNlIGxlYXZlIHlvdSBuYW1lPGJyPg0KDQphbmQgZGF5IGFu
ZCBldmVuaW5nIHBob25lIG51bWJlcnMuPGJyPg0KDQpXZSB3aWxsIGNhbGwg
eW91IGJhY2sgaW4gYSBubyBwcmVzc3VyZSw8YnI+DQoNCmVkdWNhdGlvbmFs
IG1hbm5lci48YnI+DQoNCklmIHlvdSBhcmUgb3ZlcnNlYXMgY2FsbCB5b3Vy
IGxvbmcgZGlzdGFuY2U8YnI+DQoNCm9wZXJhdG9yIGFuZCBhc2sgdG8gYmUg
Y29ubmVjdGVkIHRvIG91cjxicj4NCg0KcGhvbmUgbnVtYmVyLiZuYnNwOyBX
ZSB3aWxsIGNhbGwgeW91IGJhY2sgc288YnI+DQoNCndlIGNhbiBwYXkgZm9y
IHRoZSBsb25nIGRpc3RhbmNlIGNoYXJnZXMuPGJyPg0KDQombmJzcDs8YnI+
DQoNCjxmb250IGNvbG9yPSIjRkYwMDAwIj5Gb3IgbW9yZSBpbmZvcm1hdGlv
biBvbiBIR0ggcmVhZCBvbi4uLi4uLi4uLi4uLjwvZm9udD48YnI+DQoNCiZu
YnNwOzxicj4NCg0KSEFWRSBZT1UgSEVBUkQgT0Y8YnI+DQoNCkhVTUFOIEdS
T1dUSCBIT1JNT05FIChIR0gpPz8/PGJyPg0KDQombmJzcDs8YnI+DQoNCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWxlYXNlZCBieSB5b3VyIG93biBw
aXR1aXRhcnkgZ2xhbmQsIEhHSCBzdGFydHMNCg0KZGVjbGluaW5nPGJyPg0K
DQppbiB5b3VyIDIwcywgZXZlbiBtb3JlIGluIHlvdXIgMzBzIGFuZCA0MHMs
IGV2ZW50dWFsbHkgcmVzdWx0aW5nPGJyPg0KDQppbiB0aGUgc2hyaW5rYWdl
IG9mIG1ham9yIG9yZ2FucyAtLSBwbHVzLCBhbGw8YnI+DQoNCm90aGVyIHN5
bXB0b21zIHJlbGF0ZWQgdG8gb2xkIGFnZS48YnI+DQoNCiZuYnNwOzxicj4N
Cg0KJm5ic3A7PGJyPg0KDQpJTiBUSE9VU0FORFMgT0YgQ0xJTklDQUwgU1RV
RElFUyw8YnI+DQoNCkhHSCBIQVMgQkVFTiBTSE9XTiBUTyBBQ0NPTVBMSVNI
IFRIRSBGT0xMT1dJTkc6PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVkdWNl
IEJvZHkgRmF0IGFuZCBCdWlsZCBMZWFuIE11c2NsZTxicj4NCg0KJm5ic3A7
Jm5ic3A7IFdJVEhPVVQgRVhFUkNJU0UhPGJyPg0KDQombmJzcDs8YnI+DQoN
CiogRW5oYW5jZSBTZXh1YWwgUGVyZm9ybWFuY2U8YnI+DQoNCiZuYnNwOzxi
cj4NCg0KKiBSZW1vdmUgV3JpbmtsZXMgYW5kIENlbGx1bGl0ZTxicj4NCg0K
Jm5ic3A7PGJyPg0KDQoqIExvd2VyIEJsb29kIFByZXNzdXJlIGFuZCBJbXBy
b3ZlIENob2xlc3Rlcm9sIFByb2ZpbGU8YnI+DQoNCiZuYnNwOzxicj4NCg0K
KiBJbXByb3ZlIFNsZWVwLCBWaXNpb24gYW5kIE1lbW9yeTxicj4NCg0KJm5i
c3A7PGJyPg0KDQoqIFJlc3RvcmUgSGFpciBDb2xvciBhbmQgR3Jvd3RoPGJy
Pg0KDQombmJzcDs8YnI+DQoNCiogU3RyZW5ndGhlbiB0aGUgSW1tdW5lIFN5
c3RlbTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIEluY3JlYXNlIEVuZXJneSBh
bmQgQ2FyZGlhYyBPdXRwdXQ8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBUdXJu
IGJhY2sgeW91ciBib2R5J3MgQmlvbG9naWNhbCBUaW1lIENsb2NrIDEwIC0g
MjAgeWVhcnM8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBMaXZlIExvbmdlciBB
TkQgU3Ryb25nZXI8YnI+DQoNCiZuYnNwOzxicj4NCg0KQWxsIG5hdHVyYWwg
YW5kIG9yZ2FuaWMgcGxhbnQgYmFzZWQ8YnI+DQoNCiZuYnNwOzxicj4NCg0K
PGZvbnQgY29sb3I9IiMwMDAwRkYiPjxiPkZFRUwgMTAgWUVBUlMgWU9VTkdF
UiBXSVRIIE9SQUwgU1BSQVkgSEdILjxicj4NCg0KR1VBUkFOVEVFRDwvYj48
L2ZvbnQ+PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNw
OyBXZSBhcmUgdGhlIG1hbnVmYWN0dXJlciBhbmQgd2Ugc2VsbCBkaXJlY3Rs
eSB0byBEb2N0b3JzLDxicj4NCg0KQ2hpcm9wcmFjdG9ycywgYW5kIGNvbnN1
bWVycyB3b3JsZCB3aWRlIHRoZSBoaWdoZXN0IGdyYWRlPGJyPg0KDQombmJz
cDtIR0ggT3JhbCBTcHJheSBhdmFpbGFibGUuJm5ic3A7PGJyPg0KDQombmJz
cDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaXRoIGludGVy
bmV0IG1hcmtldGluZywgd2UgYXJlIGFibGUgdG8gc2F2ZQ0KDQphZHZlcnRp
c2luZzxicj4NCg0KY29zdCBhbmQgcGFzcyB0aG9zZSBzYXZpbmdzIGFsb25n
IHRvIHlvdS48YnI+DQoNCkJ1dCB5b3UgbXVzdCBhY3Qgbm93LiZuYnNwOzxi
cj4NCg0KJm5ic3A7PGJyPg0KDQpUbyByZWNlaXZlIG1vcmUgaW5mb3JtYXRp
b24gY2FsbCZuYnNwOyB1cyBub3cuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBUT0xMIEZSRUUgPGI+PGZvbnQgY29sb3I9
IiMwMDAwODAiPjEtODg4LTYyMS03MzAwPC9mb250PjwvYj48YnI+DQoNCiZu
YnNwOzxicj4NCg0KV2UgbXVzdCBzcGVhayB0byB5b3UgaW4gcGVyc29uIHRv
IHF1YWxpZnkgeW91ciB1c2FnZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsbCBvZiB5b3VyIHF1ZXN0aW9ucyB3
aWxsIGJlIGFkZHJlc3NlZCBhbmQgYW5zd2VyZWQgaW4NCg0KYSBmcmllbmRs
eSw8YnI+DQoNCm5vIHByZXNzdXJlIG1hbm5lci4mbmJzcDsgT3VyIG1haW4g
cHVycG9zZSBpcyB0byBwcm92aWRlIHlvdSB3aXRoPGJyPg0KDQombmJzcDtp
bmZvcm1hdGlvbiBzbyB5b3UgY2FuIG1ha2UgYW4gZWR1Y2F0ZWQgZGVjaXNp
b24uPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBjYWxsPGJyPg0KDQombmJzcDs8
YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Yj48Zm9udCBjb2xvcj0i
IzAwMDA4MCI+MS04ODgtNjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5i
c3A7PGJyPg0KDQombmJzcDtJZiB5b3UgYXJlIG9uIGxpbmUgd3JpdGUgZG93
biBvdXI8YnI+DQoNCnBob25lIG51bWJlciBhbmQgY2FsbCB1cyB3aGVuIHlv
dSBjYW4uPGJyPg0KDQombmJzcDs8YnI+DQoNClNvb24sIHlvdSBhbmQgeW91
ciBsb3ZlZCBvbmVzIHdpbGwgYmUgdmVyeSBnbGFkIHlvdSBkaWQuPGJyPg0K
DQombmJzcDs8YnI+DQoNClJlYWQgd2hhdCBwZW9wbGUgYXJlIHNheWluZzo8
YnI+DQoNCiZuYnNwOzxicj4NCg0KJnF1b3Q7VGhlIGVmZmVjdHMgb2YgNiBt
b250aHMgb2YgR0ggb248YnI+DQoNCmxlYW4gYm9keSBtYXNzIGFuZCBmYXQg
d2VyZSBlcXVpdmFsZW50PGJyPg0KDQppbiBtYWduaXR1ZGUgdG8gdGhlIGNo
YW5nZXMgaW5jdXJyZWQ8YnI+DQoNCmR1cmluZyAxMC0yMCB5ZWFycyBvZiBh
Z2luZy4mcXVvdDs8YnI+DQoNCkRyLiBEYW5pZWwgUnVkbWFuLCBNRCw8YnI+
DQoNCk5ldyBFbmdsYW5kIEpvdXJuYWwgb2YgTWVkaWNpbmUuPGJyPg0KDQom
bmJzcDs8YnI+DQoNCiZxdW90O1dpdGhpbiBmb3VyIG1vbnRocywgbXkgYm9k
eSBmYXQgZGVjcmVhc2VkPGJyPg0KDQombmJzcDtmb3JtIDMwJSBkb3duIHRv
IDIxJSEgSSBub3RpY2VkIG15IHNraW48YnI+DQoNCiZuYnNwO2lzIG1vcmUg
c3VwcGxlIGFuZCBteSBvdmVyYWxsIG1lbnRhbDxicj4NCg0KJm5ic3A7b3V0
bG9vayBpbXByb3ZlZCBzaWduaWZpY2FudGx5LiZxdW90Ozxicj4NCg0KJm5i
c3A7RC5XLiwgTmV3IEplcnNleTxicj4NCg0KJm5ic3A7PGJyPg0KDQomcXVv
dDtXZSBoYXZlIGJlZW4gb24gdGhlIHNwcmF5IGZvciBqdXN0IDMgd2Vla3M8
YnI+DQoNCm5vdywgYW5kIGJlc2lkZXMgdGhlIHRyZW1lbmRvdXMgZW5lcmd5
IHdlPGJyPg0KDQpib3RoIGZlZWwsIG15IGh1c2JhbmRzIGFsbGVyZ2llcyBh
bmQgc3BlbGxzPGJyPg0KDQpvZiBkZXByZXNzaW9uIGhhdmUgbGlmdGVkLiBJ
IGFtIGhlYWxpbmc8YnI+DQoNCmV4dHJlbWVseSBmYXN0IGFmdGVyIGFuIGFj
Y2lkZW50IGFuZCBoYXZlPGJyPg0KDQpsb3N0IDcgbGJzLiB3aXRob3V0IHRy
eWluZyEmcXVvdDs8YnI+DQoNCkMuQi4sIEZsYWdzdGFmZi4gQVo8YnI+DQoN
CiZuYnNwOzxicj4NCg0KVGhhbmtzIGZvciByZWFkaW5nIG91ciBsZXR0ZXIs
PGJyPg0KDQpUaGUgSEdIIFN0YWZmPGJyPg0KDQpVU0EgRGl2aXNpb248YnI+
DQoNCiZuYnNwOzxicj4NCg0KUFM6Jm5ic3A7IFRoZSBIR0ggU3RhZmYgZ3Vh
cmFudGVlcyB0aGU8YnI+DQoNCmhpZ2hlc3QgcXVhbGl0eSBhbmQgbG93ZXN0
IHByaWNlLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDtXZSBtYW51ZmFj
dHVyZSBhbmQgc2hpcCBkaXJlY3RseSB0byB5b3VyIGRvb3IuPGJyPg0KDQom
bmJzcDs8YnI+DQoNCkNhbGwgdXMgbm93IDxiPjxmb250IGNvbG9yPSIjMDAw
MDgwIj4xLTg4OC02MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8
YnI+DQoNCj09PT09PT0mbmJzcDsmbmJzcDsgRW5kIG9mIG1lc3NhZ2UgPT09
PT09PT0mbmJzcDs8YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7
IFRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IGlzIHByb3ZpZGVkIHRvIGJlPGJy
Pg0KDQppbiBjb21wbGlhbmNlIHdpdGggY29tbWVyY2lhbCBlbWFpbCBsYXdz
Ljxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsgSWYgeW91IGRv
IG5vdCB3aXNoIHRvIHJlY2VpdmUgZnVydGhlcjxicj4NCg0KbWFpbGluZ3Ms
IHBsZWFzZSBjbGljayByZXBseSB0bzogIHRoZV9oZ2hfY2xpbmljQGJ0YW1h
aWwubmV0LmNuICBhbmQgdHlwZSByZW1vdmUgaW4gdGhlIHN1YmplY3QgYm94
Ljxicj4NCg0KVGhlbiBjbGljayBzZW5kLjxicj4NCg0KJm5ic3A7PGJyPg0K
DQombmJzcDsmbmJzcDsgVGhpcyBtZXNzYWdlIGlzIGluIGZ1bGwgY29tcGxp
YW5jZSB3aXRoPGJyPg0KDQpVLlMuIEZlZGVyYWwgcmVxdWlyZW1lbnRzIGZv
ciBjb21tZXJjaWFsPGJyPg0KDQplbWFpbCB1bmRlciBiaWxsIFMuMTYxOCBU
aXRsZSBsbGwsIFNlY3Rpb24gMzAxLDxicj4NCg0KUGFyYWdyYXBoIChhKSgy
KShDKSBwYXNzZWQgYnkgdGhlIDEwNXRoIFUuUy48YnI+DQoNCkNvbmdyZXNz
IGFuZCBpcyBub3QgY29uc2lkZXJlZCBTUEFNPGJyPg0KDQpzaW5jZSBpdCBp
bmNsdWRlcyBhIHJlbW92ZSBtZWNoYW5pc20uKjxicj4NCg0KVGhpcyBtZXNz
YWdlIGlzIG5vdCBpbnRlbmRlZCBmb3IgcmVzaWRlbnRzIGluIHRoZTxicj4N
Cg0Kc3RhdGVzIG9mIENBLCBOQywgTlYsIFJJLCBUTiwgVkEgJmFtcDsgV0Eu
PGJyPg0KDQpTY3JlZW5pbmcgb2YgYWRkcmVzc2VzIGhhcyBiZWVuIGRvbmUg
dG8gdGhlIGJlc3Q8YnI+DQoNCm9mIG91ciB0ZWNobmljYWwgYWJpbGl0eS48
YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IENhbGwgdXMNCg0Kbm93IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4x
LTg4OC02MjEtNzMwMDwvZm9udD48L2I+IGZvciB5b3VyPGJyPg0KDQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnJlZQ0KDQpIR0ggY29uc3VsdGF0
aW9uLjwvcD4NCg0KPHA+PGJyPg0KDQpUaGFuayB5b3U8L3A+DQoNCjwvYm9k
eT4NCg0KPC9odG1sPg0KDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog
DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog
DQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog
DQogDQogDQogDQogDQogDQoNCi0tDQoNCjA3MjJBSE53Mi01MTNaUHVTOTc1
M2d0VFMyLTA2M1RUbUYyMzg5V1dxbTEtNDk4cUVVbDQ3

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

Peter Lister <P.L...@sy...> writes:

> > It's the age old problem of how to communicate load locations to the
> > loader. Etherboot does it by prepending a directory in front, but this
> > annoys people who want to boot kernel images fresh from the build.
> > Personally I don't see an extra tagging step is a big hassle. Maybe one
> > day all kernel images will be netloader friendly out of the build.
> 
> Some people seem offended by the idea of tagging. A few months ago,
> someone on the syslinux / pxelinux list referred to LTSP's nbi images as
> "polluted". This seems odd to me, but maybe if you are used to the
> syslinux view of the world it makes sense.

Another perspective is that it is an Executable file format, which
is litterally the case when you use ELF.
 
> > Another way might be a smart TFTP daemon that can assemble virtual
> > tagged images on the fly.
> 
> It would nice to be able to break out into perl (i.e. a tftp cgi) since
> mknbi is perl anyway.

Unless you were careful the overhead of perls interpretation could
easily get in the way. 

Eric

Re: [Etherboot-developers] [RFC] Relocation techniques...

[Michael B. <mb...@fe...>]

On Mon, 8 Jul 2002, Peter Lister wrote:
> > Alternatively the type of NIC is supplied in the DHCP query.
> .
> > Given that it is safer for the loaded image to bring along it's
> > network driver, and stack, because the loaded image can be recompiled
> > and fixed.
> I agree with what you say, Eric, but this implies complexity on the
> dhcp server side to give out images with the right driver. People find
> that complicated, so there will be pressure to supply use the initial
> firmware driver to be nicely device indepedent.

It's not complicated to set up DHCPD to do this; you can find code that
will automate it completely in contrib/initrd.  As is, this will create
NBI files for each network module and will provide dhcpd.conf fragments
that deal with automatically selecting the correct NBI based on the
PCI/ISA IDs that Etherboot sends.  (I need to update this to use the
new binary structures.)

Michael

[Etherboot-developers] new web pages up

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

The new look web pages by Marty Connor and his assistant are up. Please
report any broken links you find. Thanks to Timothy and Marty for being
so quick to spot a few.

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

> Alternatively the type of NIC is supplied in the DHCP query.
.
.
.
> Given that it is safer for the loaded image to bring along it's
> network driver, and stack, because the loaded image can be recompiled
> and fixed.  

I agree with what you say, Eric, but this implies complexity on the
dhcp server side to give out images with the right driver. People find
that complicated, so there will be pressure to supply use the initial
firmware driver to be nicely device indepedent.

That said, I'd certainly like to be able to load a new driver -
e.g. for link 802.1ad aggregation on my multiple NICs. :)

Re: [Etherboot-developers] [RFC] Relocation techniques...

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

> It's the age old problem of how to communicate load locations to the
> loader. Etherboot does it by prepending a directory in front, but this
> annoys people who want to boot kernel images fresh from the build.
> Personally I don't see an extra tagging step is a big hassle. Maybe one
> day all kernel images will be netloader friendly out of the build.

Some people seem offended by the idea of tagging. A few months ago,
someone on the syslinux / pxelinux list referred to LTSP's nbi images as
"polluted". This seems odd to me, but maybe if you are used to the
syslinux view of the world it makes sense.

> Another way might be a smart TFTP daemon that can assemble virtual
> tagged images on the fly.

It would nice to be able to break out into perl (i.e. a tftp cgi) since
mknbi is perl anyway.

> Yet another way might be a special tagged flag
> that says: this is just the header, keep the header around then append
> or subtract something from the filename to get the body of the image to
> fetch. I.e. the TFTP directory would contain:
> 
> 	vmlinuz.nb.dir	512 bytes, just the header
> 	vmlinux.nb	the real image
> 
> But then you'd need a utility to generate the headers, you can't just
> dump the image in the directory hot from the build, so why not just tag
> the thing in the first place?

Search me. It just seems to offend some people.

Re: [Etherboot-developers] changes checked into CVS

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

> But you'd have to do the same thing for other binary strucutres in
> dhcpd.conf. Can't you use colon notation?

I strongly feel that processing human readable strings is the server's
job. The ONLY exception I'd make to this is the VCI, because it's the
major thing used for the switches in dhcpd.conf, and probably should be
human readable.

Doing things right for Etherboot shouldn't be limited by ISC dhcpd's
config language - and colon separated hex seems a reasonable compromise
at this stage. That some existing Etherboot options are colon separated
strings doesn't mean that this is good idea. ISC dhcpd v3 improved
matters a great deal, though there's much room for improvement.

I currently have to say...

option Etherboot-defaults "timeout=2:default=192";
option Etherboot-menu01 "Netboot(nodes456 2.2.19):::sychron/nodes456/vml
inuz-2-2-19.nbi::0i0p:";

...I'd prefer to say...

option space vendor-specific.Etherboot.menu
  option timeout 2 ;
  option default 1 ;
  option boot(1).name "Netboot(nodes456 2.2.19)" ;
  option boot(1).image "sychron/nodes456/vmlinuz-2-2-19.nbi"
  option boot(2).name "Netboot(nodes456 2.4.9)" ;
  option boot(2).image "sychron/nodes456/vmlinuz-2-4-9.nbi"

...this is easier to read in the dhcpd.conf, easier for Etherboot to
parse and much less error prone.

ISC dhcpd dot notation for encapsulated types makes colon-separated
strings redundant, though it has room for improvment. I'd like a syntax
above which allows multiple instances of encapsulated options; it would
also be nice to be able to add enumerated types so that one can add nic
types by name. Mind you, I really want to be able to express this as
perl...

Re: [Etherboot-developers] Re: [RFC] Relocation techniques...

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

pjc...@el... writes:

> I'm not sure if this precisely fits in with the relocation being discussed
> here, but it foiled my efforts to etherboot from my existing network 
> cards.
> 
> I've got one of the 3com 3C905B-NM cards, for which 
> disklessworkstations.com sells proms.  These are the cards that overload 
> the MII signal to choose which ROM bank to read.  The current (hack) 
> solution is to use a boot disk which locks the MII setting on.  That way 
> the card can see more than 4KB of the boot rom, and load the etherboot
> code into memory.
> 
> However, this is rather sloppy.  It leaves the one signal stuck on.  
> Always.  Even when you don't boot from the bootrom.  Linux handles this 
> situation just fine.  However, DOS TCP stacks pitch a fit.  This makes our 
> Ghost boot disks fail, rendering the machines rather useless.
> 
> Apparently the right solution is to have a small piece of code which lives 
> in the low 4KB of the ROM.  It switches the banks, copies the ROM into RAM 
> somewhere, and switches back.  Then it boots.
> 
> All that to say, if you're toying with relocation and other such memory 
> constraints, please consider building the little low-memory shim into your 
> plans.

We need a loader shim for loading the code somewhere in memory.
Currently this is loader.S and it needs updating, to handle your
interesting case.

Of course the other possibility is to actually fix the DOS driver so
it doesn't have a problem with this case.

When we start relocating etherboot to live at different memory
locations we will probably need to touch loader.S as well.

Go ahead and submit the code, only someone with the same hardware
as you can test it, so you look like the perfect canidate. 

Eric