RE: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Eno C. <Eno...@Mi...> - 2001-02-07 15:44:05
|
Hmmm, very helpful, Ken. Thanks. I'll post once in a while as the development goes along - keep everybody amused with my travails. >You'd have to decide what fails to boot means... Don't know, but I hope there is some ethernet signal, analogous to rs232 data-set-ready or clear-to-send, that says something is plugged into the port thus implying logical clear-to-send. I was thinking of checking that signal and doing as you suggest with the absence of dhcp responses. Had a quick peek at csr0 in the AM79C960 spec. The descriptions of the bits is a little vague and I don't see a signal that offers but then I haven't invested time enough to truly understand the bits. Eno -----Original Message----- From: Ken Yap [mailto:ke...@nl...] Sent: Wednesday, February 07, 2001 7:43 AM To: eth...@li... Subject: Re: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ? >Being unfamiliar with Etherboot Architecture, I am unsure how to >approach this development. My first thought was to confine my >modifications to the lance driver itself. Considering over night >though, I think there must be higher level logic, that calls the lance >driver, where simple modifications might fit easier. My thought here is >to modify the lance driver such that the probe routine knows to ignore >a device. With this ability, the higher routine could call lance >normally (use any device you can find). Failing the first device, the >higher routine could call lance again with a parameter that says, in >effect, use any device you can find except this one. You probably don't need to modify the lance driver. The way the PCI subsystem works is that the pci_probe routine returns (or is supposed to return) a list of addresses at which an adaptor has been detected. Currently it just hands the first one to the lance driver and assumes that one will work. What you could do is use a static variable to index into the list, and if the first one fails to boot, then advance the index to the next device and call the probe routine again on the next adaptor. You'd have to decide what fails to boot means, probably no DHCP reply within so many retries. Oh and probably you should disable the current device before moving on to the next one. If you get this to work, it might be a useful addition to the code. >Your statement about non-reentrancies worries me, but that can't be a killer >unless space restrictions are insurmountable. We intend to keep the code in >about 16k of available space in bios rom. If this is insufficient, we will >just have to make other arrangements, something we need to avoid if >possible. It's not a space problem per se, just that the driver keeps in static variables info about the current device. It could be remedied by rewriting the driver to have no static variables, except perhaps read-only lookup tables and strings, and to hang device specific data off the NIC structure, there is a pointer field for private data. However if you are dealing with only one interface at any given time then you shouldn't need to modify the driver. Non-reentrant is probably the wrong term, single threaded is probably closer to what I meant. _______________________________________________ Etherboot-developers mailing list Eth...@li... http://lists.sourceforge.net/lists/listinfo/etherboot-developers |