Re: [Etherboot-developers] UNDI driver

[<prl...@sy...>]

> > I like the fact we can unload and reload the PXE stack.  The only dow=
nside
> > 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 locat=
e
> and initialise an UNDI driver, let it find its own NIC".

Eric, if I understand Michael right, the issue I'm griping about is more
how BIOSen interacts with the PXE code. The dumb BIOS action we've seen
is to initialise everything (in PCI scan order) and then try to boot off
the first nic (in PCI scan order).

But as there's a common context for all these initialisations, the
upshot is that though we actually find nic 0, but we use the context
(MAC address etc) from the LAST nic in the search order (or rather, the
last nic that initialised). D'oh... where are 2 nics embedded on a mobo,
this may work more sanely because the BIOS hopefully knows exactly what
is in there. Our local workround was to scrunge the 3Com nic rom for all
everything except the first NIC.

Michael's code use the normal Etherboot search order, initialises each
NIC and then immediately tries to use the NIS; only if it fails and
needs to try the next nic will it go on and initialise *that*.  So the
context we use is always the right one for the nic.

Vasil pointed out to me recently that Etherboot is a very effective way
of getting round buggy BIOSen. :) Here is another example.