Re: [Etherboot-developers] UNDI driver

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

> 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"...

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

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.

Michael