RE: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

[Eno C. <Eno...@Mi...>]

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