etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Q: Multiple drivers.

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

Marty Connor <md...@th...> writes:

> The current conversation about multiple NICs has gotten me thinking 
> (always a dangerous thing :)

:)
On a practical note, from a pnp/bbs bios we are passed
for pci a bus, and device.  So we should be able to match on
that to get the expected behavior.

Since it wasn't implemented I thought it was a deliberate feature :)

Eric

Re: [Etherboot-developers] Q: Multiple drivers.

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

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

> >Hmm. Then it isn't intentional that etherboot always boots the first
> >NIC of that type in the system?
> 
> If it does it's by accident. 

This is the code in question.  
For PCI (the common case) it always grabs the NIC with the lowest
address on the pcibus.  The Boot Bios specification provices
information on which pci device to use but currently we don't use it.

int eth_probe(void)
{
	struct pci_device	*p;
	const struct dispatch_table	*t;

	p = 0;
	eth_pci_init(pci_nic_list);
	pci_ioaddrs[0] = 0;
	pci_ioaddrs[1] = 0;
	/* at this point we have a list of possible PCI candidates
	   we just pick the first one with a non-zero ioaddr */
	for (p = pci_nic_list; p->vendor != 0; ++p) {
		if (p->ioaddr != 0) {
			pci_ioaddrs[0] = p->ioaddr;
			break;
		}
	}
	printf("Probing...");
	for (t = NIC; t->nic_name != 0; ++t)
	{
		printf("[%s]", t->nic_name);
		if ((*t->eth_probe)(&nic, t->probe_ioaddrs, p)) {
			return (1);
		}
	}
	return (0);
}

> A case in point is my firewall with two
> 3c509 NICs. Currently Etherboot always boots the first detected NIC,
> using 3com's recommended probe algorithm, which resolves the address of
> all 3c509s on the bus one bit at a time, and is the same algorithm used
> in the Becker driver. 
????  
> So I have to be careful to put Etherboot on the
> first detected NIC on the system. Otherwise I could send out the request
> to the cable modem, which would give me an address, but would be useless
> for TFTP loading.
I think we are violently agreeing.
 
> Without a preference for the home NIC, when the code is on the NIC slot,
> one could have a situation where adding a NIC to the system upsets a
> working boot setup.

I agree but we don't have that preference unless it is something
driver specific...  And when you include a Etherboot NIC into an
traditional BIOS it does seem to still have a prefered NIC even
when you don't have a bootrom.

> And as stressed before, this should be a compile time option.

Definentily size is to important, and policy is an important thing
to control.

Eric

Re: [Etherboot-developers] Q: Multiple drivers.

[Vasil V. <vas...@sy...>]

On Fri, 7 Dec 2001, Ken Yap wrote:

> >Hmm. Then it isn't intentional that etherboot always boots the first
> >NIC of that type in the system?
>
> If it does it's by accident. A case in point is my firewall with two
> 3c509 NICs. Currently Etherboot always boots the first detected NIC,
> using 3com's recommended probe algorithm, which resolves the address of
> all 3c509s on the bus one bit at a time, and is the same algorithm used
> in the Becker driver. So I have to be careful to put Etherboot on the
> first detected NIC on the system. Otherwise I could send out the request
> to the cable modem, which would give me an address, but would be useless
> for TFTP loading.

I don't see problem here if all NICs are tried. Moving to the next NIC doesn't
have to be only because of failure in probing of the current one NIC. It could
be that the TFTP loading failed and then you move on. This may, of course,
slow down the booting in some cases.

> Without a preference for the home NIC, when the code is on the NIC slot,
> one could have a situation where adding a NIC to the system upsets a
> working boot setup.

In theory it may slow it down but it shouldn't upset it otherwise. In practice
because of buggy systems, it may. I would make the default the first to boot
from the home NIC, and if it fails, try the rest. If this was mentioned
before, I seem to have missed it.

> And as stressed before, this should be a compile time option.

Options are always a good thing.

Vasil

Re: [Etherboot-developers] Q: Multiple drivers.

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

>Hmm. Then it isn't intentional that etherboot always boots the first
>NIC of that type in the system?

If it does it's by accident. A case in point is my firewall with two
3c509 NICs. Currently Etherboot always boots the first detected NIC,
using 3com's recommended probe algorithm, which resolves the address of
all 3c509s on the bus one bit at a time, and is the same algorithm used
in the Becker driver. So I have to be careful to put Etherboot on the
first detected NIC on the system. Otherwise I could send out the request
to the cable modem, which would give me an address, but would be useless
for TFTP loading.

Without a preference for the home NIC, when the code is on the NIC slot,
one could have a situation where adding a NIC to the system upsets a
working boot setup.

And as stressed before, this should be a compile time option.

Re: [Etherboot-developers] Q: Multiple drivers.

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

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

> >1) Is it reasonable for etherboot to support multiple cards,
> >   and possible multiple cards with different drivers at
> >   one time.
> 
> Yes, this is a reasonable thing. In the past when the code was in a ROM,
> it would have violated the principle of least surprise for the code on
> one NIC's ROM to boot another NIC, but Etherboot has extended its
> tentacles into the BIOS and other places now. 

Hmm. Then it isn't intentional that etherboot always boots the first
NIC of that type in the system?

As for BIOS's I guess it should be documented that when you have a
relationship with the motherboard vendor, and a motherboard has an
onboard NIC it is a reasonable request to ask the vendor to the
motherboard vendor to include the option rom in their BIOS.

> One thing that would be
> nice, if possible, is for the single driver version to by selection or
> by default boot only the physical NIC it lives in. That way controlling
> the interface is a matter of choosing the right NIC to put the ROM in.

That sounds like a totally reasonable choice.
 
> The interface to the drivers is rather poor, it only takes the first NIC
> it finds. Ideally it should enumerate all the NICs it can boot and
> choose a good default or give the user a choice (one of multiple NICs of
> the same or different models).

A workable strategy is to try each NIC in turn and when that fails
try the next NIC, with ESC selecting the next NIC.  It isn't perfect
but it does a fairly good job.  Starting with the NIC we are associated
with can certainly help.

Trying multiple NIC in parallel is faster, but it is harder to implement.

> >2) Would it be reasonable to have a version of the hard/floppy
> >   booting code that uses polled ide/floppy drivers instead of
> >   the BIOS.
> 
> Provided that this is a compile time option, this is ok. I expect that
> the code will take up room and ROM users should not have to pay the cost
> in ROM space if they are not using the disk access. At the same time,
> the API to disk access could probably be improved.

That isn't a hard provision to meet.
 
> >I have code that implements supports multiple cards with the same
> >drive, and polled ide & floppy access, and I'm trying to find
> >the best place for it to have a home, be maintained, and be useful.
> >
> >If it something you don't mind seeing in etherboot then I will look
> >into this.  
> 
> Sounds great. Any contributions are gratefully received.

Cool.

What got me started is Adam Agnew who assembled the polled ide code is
working on trusted booting.  And intially wrote the code against
etherboot.


Eric

Re: [Etherboot-developers] [Patch] E820 Memory support....

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

Vasil Vasilev <vas...@sy...> writes:

> On 6 Dec 2001, Eric W. Biederman wrote:
> 
> > When this has been previously discussed it was decided to drop
> > it because applications can get their own memory size.  But...
> > I just ran into a machine with 6GiB of ram where the legacy
> > routines tell me I only have 64MiB of ram.  Which is painful.
> >
> > The immediate problem is that at 64MiB and older kernels will
> > over write the ramdisk.
> 
> How old kernels. 

Anything before 2.4.10 + enough memory, where enough memory
is I think 2GB.   With 2.2 + 1GB I have seen a ramdisk at 32MB
overwritten.   After 2.4.10 a ramdisk above 8MB should be safe,
and it is useable if it is under I think 890MB, because as you noted
highmem isn't supported.

Ouch I'm starting to get evil ideas about what you could put in
a ramdisk that would need highmem support.  For a diskless machine on
gigabit ethernet it might even be practical to take 10s to load an
image and have an unabridged linux filesystem system on a ramdisk.   

> I am using 2.2.16 on machine with 256MB but the BIOS
> reporting 66559KB (65535+1024) and mknbi rounding it down to 65556KB. It even
> works when the kernel is forced by a boot option to think there is
> 256MB.

Nasty case.  With only 256MB of ram you are unlikely to hit the
struct page array with a ramdisk at even 32MB.  So I wouldn't worry
about this specific case.


 > > So I have update etherboot so that it will query the E820 memory
> > map so it has a true picture of what the memory layout is.  Doing
> > this I have more freedom to locate ramdisk etc.
> 
> I was looking at kernel 2.4 and it appeared that the ramdisk cannot be in the
> upper memory (above 1GB or so).

Correct assesment.

Eric

Re: [Etherboot-developers] [Patch] E820 Memory support....

[Vasil V. <vas...@sy...>]

On 6 Dec 2001, Eric W. Biederman wrote:

> When this has been previously discussed it was decided to drop
> it because applications can get their own memory size.  But...
> I just ran into a machine with 6GiB of ram where the legacy
> routines tell me I only have 64MiB of ram.  Which is painful.
>
> The immediate problem is that at 64MiB and older kernels will
> over write the ramdisk.

How old kernels. I am using 2.2.16 on machine with 256MB but the BIOS
reporting 66559KB (65535+1024) and mknbi rounding it down to 65556KB. It even
works when the kernel is forced by a boot option to think there is 256MB.

> So I have update etherboot so that it will query the E820 memory
> map so it has a true picture of what the memory layout is.  Doing
> this I have more freedom to locate ramdisk etc.

I was looking at kernel 2.4 and it appeared that the ramdisk cannot be in the
upper memory (above 1GB or so).


Vasil

Re: [Etherboot-developers] [Patch] E820 Memory support....

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

Thanks Eric, it'll go into the next release. I'll also steal the code
for mknbi.

Re: [Etherboot-developers] Q: Multiple drivers.

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

On 12/5/2001 10:46 AM Ken Yap ke...@us... wrote:
>Marty, I'm sorry, I'll have to strongly disagree with you here. I think
>this cure is worse than the disease. While this is nice for bespoke ROMs
>for NICs, it makes it necessary for the user to find out the MAC
>address, have it put into the ROM, and put the ROM on the right NIC. It
>makes mass programming of ROMs impossible. I know it would do wonders
>for the stock price of rom-o-matic though. :-)

No problem.  It was proposed as an option for cases where people needed 
that fine_grained control over NIC and order of search.  I was thinking 
out loud, and pondering what I'd do if I had to make sure that a 
particular NIC was being used.  

>2. If BOOT_HOST_NIC_ONLY is defined AND if the code was started from
>NIC ROM (as discovered from the ROM address, now you know why loader.S
>saves the ROM segment address early in the game), then send the request
>on only the NIC which holds the ROM.

This is nice for the purposes you outline.  And not too hard to implement.

I understand your position on this, and I enjoyed the thought experiment 
in any case.

I think we should create a contrib/ subdirectory called:

    "crazy_ideas_that_will_never_ever_ever_be_in_the_main_distribution
      _but_hey_if_its_what_you_want_to_do_heres_how" :)

or more succinctly:

     hdkois/   ("hopeless dream keepers of intergalactic space :)

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/

Re: [Etherboot-developers] Q: Multiple drivers.

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

>   - What if (as an option) we specified that the ROM had to match
>     a particular MAC address as well as a particular card type 
>     before it was an acceptable card to boot from.  

Marty, I'm sorry, I'll have to strongly disagree with you here. I think
this cure is worse than the disease. While this is nice for bespoke ROMs
for NICs, it makes it necessary for the user to find out the MAC
address, have it put into the ROM, and put the ROM on the right NIC. It
makes mass programming of ROMs impossible. I know it would do wonders
for the stock price of rom-o-matic though. :-)

I think the outline solution we arrived at is acceptable.

1. By default Etherboot sends requests on all interfaces it can
configure.

2. If BOOT_HOST_NIC_ONLY is defined AND if the code was started from
NIC ROM (as discovered from the ROM address, now you know why loader.S
saves the ROM segment address early in the game), then send the request
on only the NIC which holds the ROM.

That way people like me who make Etherboot EPROMs won't get puzzling
surprises when extra NICs are added to a computer, and people like Peter
and Eric who boot clusters and treat Etherboot as an app which can be
added or removed at will from Flash and disks can have their cake too.

Re: [Etherboot-developers] Q: Multiple drivers.

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

The current conversation about multiple NICs has gotten me thinking 
(always a dangerous thing :)

I was considering constraints and dependencies, and realized that one 
thing that:

   - Etherboot drivers try to find a NIC for whatever driver(s)
     are compiled into them.  Thus, the Etherboot code is NIC
     specific.

   - If an Etherboot driver finds a NIC of the right type, the
     first thing it does is try to figure out what its MAC address is,
     because without it, BOOTP or DHCP cannot even happen.

This brought to mind the following idea.

   - What if (as an option) we specified that the ROM had to match
     a particular MAC address as well as a particular card type 
     before it was an acceptable card to boot from.  

I'm thinking out loud here, but please follow my logic:

   - Main Etherboot logic matches NIC type and calls driver code

   - Driver does something like:

     if (this_nic_mac_addr() == NULL)
        print "Unable to get NIC mac address!"
        return FAILED_TO_GET_MAC_ADDR

     if (NIC_MAC_ADDR_TO_MATCH != NULL) 
        if this_nic_mac_addr() != NIC_MAC_ADDR_TO_MATCH
           print "A NIC was found, but does not match the required
                  MAC address for this Etherboot ROM.
                  NIC: this_nic_mac_addr() ROM: NIC_MAC_ADDR_TO_MATCH
           return FAILED_TO_FIND_RIGHT_NIC

     Proceed as usual

There could even be (with a tiny bit more code) an array of 
NIC_MAC_ADDRS_TO_MATCH[] which could also specify the _order_ NICs should 
be matched, which helps solve another issue having to do with making sure 
cards are tried in the right order.

Now, the obvious objection to this scheme is that it puts state about the 
NIC in the ROM.  However, the ROM already contains the type of NIC 
already, which is what allows us to do the "boot another card in the 
machine from the ROM on this NIC" trick.  There would not be a danger of 
corrupting the network like burning IP addresses into ROMs might cause.

I would say this would be useful for people who have multiple NIC cards 
and want to make sure that the one the ROM is on is the one that gets 
chosen, and also for those people who need the control of being able to 
pick the right card from BIOS code.  

The state being put in the ROM is less of a problem than putting 
something like an IP address in the ROM. 

Let's look at some cases:

   -  if NIC_MAC_ADDR_TO_MATCH == ROM_MAC_ADDR then if you put the card
      in another machine it works the same.

   -  if the NIC_MAC_ADDR != ROM_MAC_ADDR then if you put the card
      in another machine it probably fails.  BUT, the failure would 
      occur if you put a NIC a "ROM with a different driver from its host
      NIC" into different machine.  Obviously this would be an option
      for special situations, and a clear error message would be printed.

So what do folks think?  Do you like the idea?  Does this idea have 
useful application (as an option) while not violating the integrity of 
the booting paradigm?

Marty

P.S. Note that this is a case where free software has a big advantage.  
Imagine the overhead of a commercial vendor who would have to burn a 
special ROM with a particular MAC address in it rather than stocking bags 
of ROMs for a particular kind of NIC.  This can be an Etherboot option or 
a rom-o-matic.net field that the user can easily fill in if they need 
this special case.

---
    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/

Re: [Etherboot-developers] Q: Multiple drivers.

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

>> It's wrong to require a special option to handle a common situation.
>> See below.
>
>Hmm. I don't regard REQUIRE_VCI_ETHERBOOT as a "special" option, I must

It's a special option because it requires server side handling and
will not work with a generic DHCP setup.

>> wrong to boot another NIC from this ROM. If I move the NIC with the ROM
>> to another machine I may get a different boot behaviour. No good.
>
>Why not? It's now a different *machine* after all - seems likely that

But it's the same NIC with the same ROM. In one machine it boots using
itself. I move it to another machine that has a second NIC of the same
model and it tries to boot the other NIC. Huh? This is predictable
behaviour, whether it manages to boot depends on whether the second NIC
is plugged in or not?

>Let's not lose sight of the fact that I want to boot a machine: the nic
>offers a network medium, a unique ID and possibly some flash rom. nics
>are fairly mobile anonymous entities in our development servers, so I
>definitely favour predictability of behaviour over any idea that
>particular nic is specially honoured.

Therein lies the difference between our POVs. You treat the EEPROM on
the NIC as extra BIOS storage. You probably don't have any EPROMs.

>these systems have multiple NICs and I assure you that at no time did I
>ever consider changing the boot medium for administrative convenience to
>be a partial or full statement of intent of which nic to use. I just
>appreciated the fact that Etherboot always worked in the same way.

No problem, just don't define BOOT_HOST_NIC_ONLY in the config. I never
proposed that this behaviour be imposed on everybody or all setups. If
you boot off a floppy or the BIOS, there is no HOST_NIC so all
interfaces are equal.  The code should detect that you are not booting
off the NIC's ROM anyway.  By default you will get the behaviour you
want, BOOT_HOST_NIC_ONLY actually requires more work to identify the
host NIC and may not be possible with all hardware.

Re: [Etherboot-developers] Q: Multiple drivers.

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

> >Anyway, REQUIRE_VCI_ETHERBOOT makes you ignore the ISP, no?
> 
> It's wrong to require a special option to handle a common situation.
> See below.

Hmm. I don't regard REQUIRE_VCI_ETHERBOOT as a "special" option, I must
admit. I concede that it's not the ideal way to handle this, but the
point still applies that where one has a choice of networks, it's better
to distinguish nics based on which network they really are connected to,
rather than whether the slot order is still the same and you
accidentally reversed the cables.

> It's not that it's obviously right to use the same NIC, it's obviously
> wrong to boot another NIC from this ROM. If I move the NIC with the ROM
> to another machine I may get a different boot behaviour. No good.

Why not? It's now a different *machine* after all - seems likely that
different boot behaviour is exactly right - e.g. boot using a built-in
network interface (which identifies the machine better than an movable
nic). The BIOS also makes a difference, as I mentioned.

Let's not lose sight of the fact that I want to boot a machine: the nic
offers a network medium, a unique ID and possibly some flash rom. nics
are fairly mobile anonymous entities in our development servers, so I
definitely favour predictability of behaviour over any idea that
particular nic is specially honoured.

> No, if I put the ROM on this NIC, I meant to boot this NIC, not another.

Maybe *you* do, Ken. I don't.

> This is one situation where I have indicated my intent. If I boot from
> floppy or BIOS ROM, my intent has not been fully indicated and some
> other behaviour is plausible. If your intent is for the flash memory on
> the NIC to be a general purpose BIOS extension area, fine, but you
> should have to select that compile option.

Again, I beg to differ. I have been using Etherboot from nic flash, but
we are now using it from LILO on most of the development machines. I
started off with floppy, and we've used PXE in response to test site
feedback and because it's a useful "out of the packet" solution. All of
these systems have multiple NICs and I assure you that at no time did I
ever consider changing the boot medium for administrative convenience to
be a partial or full statement of intent of which nic to use. I just
appreciated the fact that Etherboot always worked in the same way.

> Glad we agree. I look forward to your code. :-)

We agree that our requirements are different. I concede that Sychron
probably represents the extreme end of multi-nic cluster booting. Vasil
and I are agreed that when I was looking for a netboot solution for
Linux, with PXE as an essential requirement, we could have gone for
pxelinux, GRUB didn't seem stable but Etherboot seemed like the right
choice - the work involved in Etherboot via PXE has been amply
justified.

Code? Well, it may happen before too long. :) Sychron's in the middle of
getting a product together, and booting - by whatever means - is a part
of this. I've been keeping an eye on LinuxBIOS as well, and Eric
Biederman's recent work on integrating Etherboot and LinuxBIOS, and the
IDE polling drivers would be very applicable to us.

Re: [Etherboot-developers] Bootrom hang at booting local WORKAROUND found

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

>I have located a workaround - 
>at the end of prloader.s 
>
>line 186:	int 19h 
>
>is executed; this command is not executed if using 
>a floppy boot because of the "magic" value 
>0xE44C put in AX. It seems that it is this instruction
>that causes total freeze on trying to do a local boot.
>
>Question: what is the purpose of this interrupt?
>
>I tried commenting out this instruction and now
>I can boot from network and local using both bootrom and
>floppy, strange huh?

This means your BIOS is non PnP compliant and Etherboot is being run as
a legacy ROM, which is not what you want. Even though your workaround
works,  you won't get to disable the boot from the BIOS menu.

Before PnP, the way to get boot control is to hook INT 19H, let the BIOS
complete initialisation of all devices, then it will call INT 19H to get
started. Etherboot then gets control and removes the marker so that a
return from Etherboot will call INT 19H which will call the old vector,
usually floppy then disk boot.

All this doesn't work with PnP BIOS. At startup Etherboot tests the
longword at ES:DI against "$PnP". If it doesn't see this it assumes a
legacy BIOS.  Your BIOS is not providing this value. The workaround is
to define BBS_BUT_NOT_PNP_COMPLIANT (5.0.4-mc3, or 5.0.4 with latest
patches from site).

Re: [Etherboot-developers] Bootrom hang at booting local WORKAROUND found

[Richard Shih-P. C. <csh...@ds...>]

I have located a workaround - 
at the end of prloader.s 

line 186:	int 19h 

is executed; this command is not executed if using 
a floppy boot because of the "magic" value 
0xE44C put in AX. It seems that it is this instruction
that causes total freeze on trying to do a local boot.

Question: what is the purpose of this interrupt?

I tried commenting out this instruction and now
I can boot from network and local using both bootrom and
floppy, strange huh?

Any enlightenment greatly appreciated...

Cheers
Richard Chan

On Wed, Dec 05, 2001 at 10:50:30AM +0800, Richard Shih-Ping Chan wrote:
> Tried BOOT_INT18H but it didn't work either. It's got something
> to do with the exit() function. I built a new ROM where
> I commented out everything in main() so that it will fall through
> to exit and it also freezes. Tried this on two different Gigabyte
> mobos and had the same problem.
> 
> Any more ideas? BTW what is it that floppy does differently than
> bootrom? Is there anyway to debug the return address (after main)?
> 
> Cheers
> Richard Chan
> 
> 
> On Tue, Dec 04, 2001 at 08:47:32AM -0500, Vasil Vasilev wrote:
> > On 4 Dec 2001, Eric W. Biederman wrote:
> > 
> > > Richard Chan <csh...@ds...> writes:
> > >
> > > > Folks, I have a bootrom which cannot boot the local
> > > > system. It hangs completely after
> > > > pressing "L". Network boot works fine and floppy boot works
> > > > (both "N" and "L").
> > > >
> > > > If I press "N" it works, "L" justs hangs the system.
> > > > Any idea how to debug why this isn't working?
> > >
> > > Basically "L" just returns to the BIOS so something more
> > > can be done.  If there isn't anything in your boot order or
> > > you have a buggy BIOS, or quite unlikely etherboot doesn't
> > > follow some BIOS spec
> > 
> > I've seen this on some BIOSes, including one which supported serial line but
> > continues refreshed "the ANSI screen". Etherboot already does gymnastics to
> > get round buggy BIOSes. Try compiling your own image, and add a define
> > -DBOOT_INT18H. I don't think this would work in your case, but I can't be
> > sure.
> > 
> > As you want to boot locally, why don't you just put etherboot on the boot
> > sector of the local device -- hard disk or floopy or put it as bootable image
> > for lilo, say. Etherboot may be started through a variety of methods and
> > that's what I see as it's major advantage.
> > 
> > Vasil
> > 
> 
> -- 
> Richard Chan <csh...@ds...>
> DSO National Laboratories
> 20 Science Park Drive
> Singapore 118230
> Tel: 7727045
> Fax: 7766476

-- 
Richard Chan <csh...@ds...>
DSO National Laboratories
20 Science Park Drive
Singapore 118230
Tel: 7727045
Fax: 7766476

Re: [Etherboot-developers] Bootrom hang at booting local - any ideas?

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

>Tried BOOT_INT18H but it didn't work either. It's got something
>to do with the exit() function. I built a new ROM where

Yes it's to do with the exit() function in the sense that exit returns
from the boot ROM which then calls INT 18H to return control to the BIOS
as per spec. So it depends on what the BIOS does next. Do you have a
next device on the boot list?  Does Etherboot show up in the BIOS menu?
If not, it may be a sign that the BIOS is not PnP compliant and that
Etherboot is being activated as a legacy ROM. Normally Etherboot should
be detected as a PnP ROM and it can be placed anywhere on the boot list
instead of hogging the boot.  Try the compile option
BBS_BUT_NOT_PNP_COMPLIANT

>Any more ideas? BTW what is it that floppy does differently than
>bootrom? Is there anyway to debug the return address (after main)?

Obviously the BIOS seems to have somewhere to go back to after
attempting to boot from floppy.

Re: [Etherboot-developers] Bootrom hang at booting local - any ideas?

[Richard Shih-P. C. <csh...@ds...>]

Tried BOOT_INT18H but it didn't work either. It's got something
to do with the exit() function. I built a new ROM where
I commented out everything in main() so that it will fall through
to exit and it also freezes. Tried this on two different Gigabyte
mobos and had the same problem.

Any more ideas? BTW what is it that floppy does differently than
bootrom? Is there anyway to debug the return address (after main)?

Cheers
Richard Chan


On Tue, Dec 04, 2001 at 08:47:32AM -0500, Vasil Vasilev wrote:
> On 4 Dec 2001, Eric W. Biederman wrote:
> 
> > Richard Chan <csh...@ds...> writes:
> >
> > > Folks, I have a bootrom which cannot boot the local
> > > system. It hangs completely after
> > > pressing "L". Network boot works fine and floppy boot works
> > > (both "N" and "L").
> > >
> > > If I press "N" it works, "L" justs hangs the system.
> > > Any idea how to debug why this isn't working?
> >
> > Basically "L" just returns to the BIOS so something more
> > can be done.  If there isn't anything in your boot order or
> > you have a buggy BIOS, or quite unlikely etherboot doesn't
> > follow some BIOS spec
> 
> I've seen this on some BIOSes, including one which supported serial line but
> continues refreshed "the ANSI screen". Etherboot already does gymnastics to
> get round buggy BIOSes. Try compiling your own image, and add a define
> -DBOOT_INT18H. I don't think this would work in your case, but I can't be
> sure.
> 
> As you want to boot locally, why don't you just put etherboot on the boot
> sector of the local device -- hard disk or floopy or put it as bootable image
> for lilo, say. Etherboot may be started through a variety of methods and
> that's what I see as it's major advantage.
> 
> Vasil
> 

-- 
Richard Chan <csh...@ds...>
DSO National Laboratories
20 Science Park Drive
Singapore 118230
Tel: 7727045
Fax: 7766476

Re: [Etherboot-developers] Q: Multiple drivers.

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

>Anyway, REQUIRE_VCI_ETHERBOOT makes you ignore the ISP, no?

It's wrong to require a special option to handle a common situation.
See below.

>Using the nic the bios lives might be a tie-breaker when you have a
>choice, but I don't think it is "obviously" right; in fact I think it's

It's not that it's obviously right to use the same NIC, it's obviously
wrong to boot another NIC from this ROM. If I move the NIC with the ROM
to another machine I may get a different boot behaviour. No good.

>evil to vary the behaviour of Etherboot depending on whether you
>happened to boot from a nic rom, bios rom, via PXE, lilo, etc. As Vasil

No, if I put the ROM on this NIC, I meant to boot this NIC, not another.
This is one situation where I have indicated my intent. If I boot from
floppy or BIOS ROM, my intent has not been fully indicated and some
other behaviour is plausible. If your intent is for the flash memory on
the NIC to be a general purpose BIOS extension area, fine, but you
should have to select that compile option.

>> options. I could then put a single driver ROM on my internal NIC, and
>> you can put a multiple driver multiple request ROM in your BIOS.
>
>Absolutely. :) There's a great deal of scope for people to experiment
>with new ways of using this kind of thing. Another of Etherboot's wins
>for me is that it seems eminently extendable. with functionality just
>like this.

Glad we agree. I look forward to your code. :-)

Re: [Etherboot-developers] Q: Multiple drivers.

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

> I agree that user interaction isn't right when you want unattended
> booting.  I'm not so sure that sending out requests on all interfaces is
> the right policy either. An example is my firewall machine. If it sends
> out a request to the cable modem it will get an ISP assigned address,
> but this is useless for remote booting.

It depends why you have multiple nics. In our case it's for channel
bonding and failover, so multiple requests on all available nics is
definitely the right thing to do. I'd add a client identifier to each
request, which identifies the system rather than the nic so that a dhcp
server receiving multiple requests can decide to react to just one. The
multiple requests should all have different xids, though, and the
clients should politely decline they replies they don't use.

Anyway, REQUIRE_VCI_ETHERBOOT makes you ignore the ISP, no?

> When the code is in a ROM on a NIC, the right action is more obvious, it
> should only send out requests on the NIC it lives in. When it's part of
> the BIOS ROM, then it's harder to say what the right policy is.

Using the nic the bios lives might be a tie-breaker when you have a
choice, but I don't think it is "obviously" right; in fact I think it's
evil to vary the behaviour of Etherboot depending on whether you
happened to boot from a nic rom, bios rom, via PXE, lilo, etc. As Vasil
says, the major win of Etherboot is the number of media it will boot
from and the fact that behaviour is identical regardless of how the boot
happens. My experience has been that which nic happens to have been used
for booting is actually a function of dumbass things like which slot the
BIOS chose, which nics were able flashed (I've had 2 bad flash roms in
905Cs, so in a couple of machines it's not the same slot as the others).
These are not criteria which should be influencing Etherboot.

We have lots of systems with multiple NICs, and have used Etherboot via
PXE; which *does* use the nic it booted from - and is inclined to use
different MAC addresses from that which Etherboot chooses (the first it
finds). Initially I thought that was a problem, but now I keep the PXE
Etherboot, and Sychron DHCP configs separate. No problem at all.

Finally, it's worth considering that, if one has e.g. a router or other
system where the nics are not used for channel bonding + failover to a
common infrastructure, then the correct thing to consider is not which
nic it is, which PCI slot it's in, or where it came in Linux's scan
order - the critical factor is what network it is connected to. It seems
perfectly reasonable to me that a router should checking who's at the
other end BEFORE configuring. Maybe you (or your trusted assistant) got
those grey cables back to front. Maybe that minor OS release reversed
the scan order (it's happened to me).

> Perhaps the answer is to allow all these behaviours, chosen by compile
> options. I could then put a single driver ROM on my internal NIC, and
> you can put a multiple driver multiple request ROM in your BIOS.

Absolutely. :) There's a great deal of scope for people to experiment
with new ways of using this kind of thing. Another of Etherboot's wins
for me is that it seems eminently extendable. with functionality just
like this.

Re: [Etherboot-developers] Q: Multiple drivers.

[Donald J C. <dj...@ci...>]

Ken Yap wrote:
> 
> >> The interface to the drivers is rather poor, it only takes the first NIC
> >> it finds. Ideally it should enumerate all the NICs it can boot and
> >> choose a good default or give the user a choice (one of multiple NICs of
> >> the same or different models).
> >
> >If I can give my 2p based on discussions with Peter Lister.
> >If you are booting '0 or '00 of machines you don't want a user's choice.
> >Instead it will be nice to have etherboot send DHCP requests on all NICs it
> >can and chooses a NIC from the ones it receives response on. Some of the NICs
> >may not be connected or connected to different networks. User's interaction i
> >s
> >OK as long as it can be automatic as well.
> 
> I agree that user interaction isn't right when you want unattended
> booting.  I'm not so sure that sending out requests on all interfaces is
> the right policy either. An example is my firewall machine. If it sends
> out a request to the cable modem it will get an ISP assigned address,
> but this is useless for remote booting.
...

If only one of the NICs is connected to a net with a DHCP server configured
to respond to Etherboot DHCP requests, then it shouldn't be too much of a
problem.  Dealing with choosing among several DHCP responses to pick the
right one might not be trivial, but it should be doable.  Making it all
a compile-time option makes great sense, though.

-Don

--
Don Christensen       Senior Software Development Engineer
dj...@ci...         Cisco Systems, Santa Cruz, CA
  "It was a new day yesterday, but it's an old day now."

Re: [Etherboot-developers] Q: Multiple drivers.

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

>> The interface to the drivers is rather poor, it only takes the first NIC
>> it finds. Ideally it should enumerate all the NICs it can boot and
>> choose a good default or give the user a choice (one of multiple NICs of
>> the same or different models).
>
>If I can give my 2p based on discussions with Peter Lister.
>If you are booting '0 or '00 of machines you don't want a user's choice.
>Instead it will be nice to have etherboot send DHCP requests on all NICs it
>can and chooses a NIC from the ones it receives response on. Some of the NICs
>may not be connected or connected to different networks. User's interaction i
>s
>OK as long as it can be automatic as well.

I agree that user interaction isn't right when you want unattended
booting.  I'm not so sure that sending out requests on all interfaces is
the right policy either. An example is my firewall machine. If it sends
out a request to the cable modem it will get an ISP assigned address,
but this is useless for remote booting.

When the code is in a ROM on a NIC, the right action is more obvious, it
should only send out requests on the NIC it lives in. When it's part of
the BIOS ROM, then it's harder to say what the right policy is.

Perhaps the answer is to allow all these behaviours, chosen by compile
options. I could then put a single driver ROM on my internal NIC, and
you can put a multiple driver multiple request ROM in your BIOS.

Re: [Etherboot-developers] Q: Multiple drivers.

[Vasil V. <vas...@sy...>]

On Tue, 4 Dec 2001, Ken Yap wrote:

> >1) Is it reasonable for etherboot to support multiple cards,
> >   and possible multiple cards with different drivers at
> >   one time.
>
> Yes, this is a reasonable thing. In the past when the code was in a ROM,
> it would have violated the principle of least surprise for the code on
> one NIC's ROM to boot another NIC, but Etherboot has extended its
> tentacles into the BIOS and other places now. One thing that would be
> nice, if possible, is for the single driver version to by selection or
> by default boot only the physical NIC it lives in. That way controlling
> the interface is a matter of choosing the right NIC to put the ROM in.
>
> The interface to the drivers is rather poor, it only takes the first NIC
> it finds. Ideally it should enumerate all the NICs it can boot and
> choose a good default or give the user a choice (one of multiple NICs of
> the same or different models).

If I can give my 2p based on discussions with Peter Lister.
If you are booting '0 or '00 of machines you don't want a user's choice.
Instead it will be nice to have etherboot send DHCP requests on all NICs it
can and chooses a NIC from the ones it receives response on. Some of the NICs
may not be connected or connected to different networks. User's interaction is
OK as long as it can be automatic as well.

Vasil

Re: [Etherboot-developers] Bootrom hang at booting local - any ideas?

[Vasil V. <vas...@sy...>]

On 4 Dec 2001, Eric W. Biederman wrote:

> Richard Chan <csh...@ds...> writes:
>
> > Folks, I have a bootrom which cannot boot the local
> > system. It hangs completely after
> > pressing "L". Network boot works fine and floppy boot works
> > (both "N" and "L").
> >
> > If I press "N" it works, "L" justs hangs the system.
> > Any idea how to debug why this isn't working?
>
> Basically "L" just returns to the BIOS so something more
> can be done.  If there isn't anything in your boot order or
> you have a buggy BIOS, or quite unlikely etherboot doesn't
> follow some BIOS spec

I've seen this on some BIOSes, including one which supported serial line but
continues refreshed "the ANSI screen". Etherboot already does gymnastics to
get round buggy BIOSes. Try compiling your own image, and add a define
-DBOOT_INT18H. I don't think this would work in your case, but I can't be
sure.

As you want to boot locally, why don't you just put etherboot on the boot
sector of the local device -- hard disk or floopy or put it as bootable image
for lilo, say. Etherboot may be started through a variety of methods and
that's what I see as it's major advantage.

Vasil

Re: [Etherboot-developers] Bootrom hang at booting local - any ideas?

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

Richard Chan <csh...@ds...> writes:

> Folks, I have a bootrom which cannot boot the local
> system. It hangs completely after
> pressing "L". Network boot works fine and floppy boot works 
> (both "N" and "L").
> 
> System: Etherboot 5.0.4 and an epic100 card (SMC EtherPower II/10/100) with
> a 512kbit flash memory chip (I couldn't find anything smaller -
> did you know that small size flash memories <= 256kbits seem
> to be endangered species?) I'm pretty sure it doesn't clash with
> anything else in himem as I removed all other cards.
> 
> I get the message
> 
> ROM segment 0xca80 length 0x5800 reloc 0x94000
> 
> If I press "N" it works, "L" justs hangs the system.
> Any idea how to debug why this isn't working?

Basically "L" just returns to the BIOS so something more
can be done.  If there isn't anything in your boot order or
you have a buggy BIOS, or quite unlikely etherboot doesn't
follow some BIOS spec 

> BTW using a floppy I get
> 
> ROM segment 0x8000 length 0x4000 reloc 0x94000
> 
> and both "N" and "L" work.

For floppy boot "L" means something completely different.

> Strange that the lengths are different (0x4000->0x5800). 
> The bootrom is burned using epic100.rom (16384 bytes)
> exactly as created.
> 
> P.S. Who sells 256kbit/128kbit 32DIP flash memory?

32 pin DIP is quite common for stock BIOS flash chips
so it should be available, at least in the larger sizes.

Eric

[Etherboot-developers] Bootrom hang at booting local - any ideas?

[Richard C. <csh...@ds...>]

Folks, I have a bootrom which cannot boot the local
system. It hangs completely after
pressing "L". Network boot works fine and floppy boot works 
(both "N" and "L").

System: Etherboot 5.0.4 and an epic100 card (SMC EtherPower II/10/100) with
a 512kbit flash memory chip (I couldn't find anything smaller -
did you know that small size flash memories <= 256kbits seem
to be endangered species?) I'm pretty sure it doesn't clash with
anything else in himem as I removed all other cards.

I get the message

ROM segment 0xca80 length 0x5800 reloc 0x94000

If I press "N" it works, "L" justs hangs the system.
Any idea how to debug why this isn't working?
BTW using a floppy I get

ROM segment 0x8000 length 0x4000 reloc 0x94000

and both "N" and "L" work.

Strange that the lengths are different (0x4000->0x5800). 
The bootrom is burned using epic100.rom (16384 bytes)
exactly as created.

P.S. Who sells 256kbit/128kbit 32DIP flash memory?




-- 
Richard Chan <csh...@ds...>
DSO National Laboratories
20 Science Park Drive
Singapore 118230
Tel: 7727045
Fax: 7766476