Re: [Etherboot-developers] UNDI driver

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

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

You do; when you initialise a PXE stack you have to pass in the PCI bus,
device and function.  The structure is "take this PCI device, try to
locate and initialise an UNDI driver for it", rather than "try to locate
and initialise an UNDI driver, let it find its own NIC".

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

OK.  As mentioned in another message, I'm planning on tidying up the 
Makefiles a bit; there are various other problems like drivers not being 
recompiled when the header files change.  If it's easy to slot in 
undi_wrapper.S in a generic way then I'll do so, otherwise I'll just add a 
special case in arch/i386/Makefile.

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

There's a comment in pci.c that says 
  /* Assume there is only one match of the correct type */

I haven't checked the actual code, so it might be a leftover comment.

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

I'm not seeing anything appearing in CVS.  Can you check that the commit 
worked ok?

Michael