Re: [Etherboot-developers] UNDI driver

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

Michael Brown <mb...@fe...> writes:

> > Thought - can the UNDI driver avoid the annoying attribute of 3Com's PXE
> > initialisation (and therefore probably everyone else's, though I haven't
> > tried) with multiple NICs that the MAC address used is that of the
> > *last* NIC to initialise? This confuses people because it almost always
> > means that it never uses the one that Linux calls eth0.
> 
> MAC address used is the MAC address stored on the NIC EEPROM; the one 
> known to UNDI as the "Permanent Node Address".
> 
> We will use PCI cards in the same order that Etherboot normally finds 
> them.  If Etherboot uses the same scanning order as Linux, then we should 
> end up using the one that Linux calls eth0.  This is independent of the 
> Etherboot UNDI driver; it's determined by pci.c.
> 
> > > I imagine that PXE-chaining would also work, although I haven't tested
> > > it yet.
> > PXE chaining is, of course, what lots of people want so that they don't
> > have to worry about loading the right driver. Just remember to leave PXE
> > loaded, since by default the first act of PXE-chaining to is to unload
> > PXE.  :)
> 
> You can happily unload the PXE stack; the UNDI driver will simply 
> reinstall it from the UNDI ROM.  It searches for a PXE stack in memory 
> before looking for ROMs, so a loaded PXE stack should work.
> 
> If the PXE stack has been left in a "running" state then it will fail to
> initialise, ignore the loaded stack and try to load a new one from ROM.  
> There is *no* clean way to tell whether or not a PXE stack is running or
> not; the API call for "get current state" has the same number as the API
> call for "shutdown stack"...

I like the fact we can unload and reload the PXE stack.  The only downside
of this is that we don't know what NIC we booted off of.  Oh well.


> > > Ideally, I'd like to create a file undi_wrapper.S in 
> > > arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> > > have to edit genrules.pl to achieve this, unless anyone can suggest a 
> > > quick and easy method?
> > Dumb question - does anything make UNDI fundamentally different from a
> > nic driver? That's how people will want to treat it, so I say treat it
> > exactly like a driver, with the possible exception that UNDI is included
> > by default as a last resort driver for PXE images but not others.
> 
> No; except that it requires an assembler stub because the UNDI API calls 
> (at least some of them) have to be executed in real mode.  This assembler 
> stub should ideally be present only in the UNDI driver, which means that 
> it shouldn't go in pcbios.S.  The UNDI driver will therefore consist of 
> two files: undi.c and undi_wrapper.S (plus the headers); most drivers 
> consist only of a single C file.  The Makefile will, I think, have to be 
> altered to allow drivers to consist of more than just the one file.

Or we can have a special case in the makefile, for the supporting code.
 
> Another small difference is that the UNDI driver claims to be able to
> handle any NIC, whereas most drivers specify a list of PCI IDs.  If the
> UNDI driver can't find an UNDI ROM for the card, it will give up.  We may
> therefore need to change the core driver scanning code to try multiple
> drivers for a specific PCI vendor:device ID, if people are going to want 
> to build images that contain UNDI and other drivers.

Actually I am pretty certain that functionality is already present.

I had a few bug fixes sitting in my tree with respect to pci scanning
and I have just commited them.

Eric