The thing to do is look at how, say, the cs8900a does it, with
the edb7xxx as an instantiation. Most of the fun stuff happens in the
edb7xxx bit actually. And what happens with RedBoot is that there's one
boolean option default off which controls whether or not an ESA is then
properly set (and then used). The option to set the ESA itself is then
a suboption of that boolean option, so if you don't request to set a
new ESA, you never see it.
That then makes it sensible to do it in the order redboot, compile time,
EEPROM. RedBoot first because someone is insisting they want to override
it; then compile time as someone is wanting to just hard code it at
compile time without looking at any EEPROM - again this is default off so
someone must have explicitly enabled it, and finally EEPROM,
which will be
remain the default method.
Now that I am looking at it more carefully, it seems to me that there is
some disagreement between the code in "if_cs8900a.c" and the code in
"devs_eth_arm_edb7xxx.inl" over which takes precedence, the compile time ESA
vs. the RedBoot supplied ESA.
In "if_cs8900a.c", there is a comment that states the precedence order as
you have described, and, indeed, the code that follows that comment
implements. It checks for a 'provide_esa()' function, and if that exists,
calls it to attempt to set the ESA. If the function returns false
(indicating the ESA was not set) or if it does not exist, the code uses the
ESA hardwired in the cs8900a private data structure. If no such value was
compiled into the structure, the code attempts to fetch the value from the
EEPROM.
All right, that all makes sense to me :-). However (and this is where I
will cancel this email and continue with what I was doing if, after I
explain it, it begins to make sense to me), when I look at
"devs_eth_arm_edb7xxx.inl", what I see is this: If the user modified
his/her ecos.ecc file so that 'CYGSEM_DEVS_ETH_ARM_EDB7XXX_ETH0_SET_ESA' is
true, the ESA is hardwired into the cs8900a private data structure. The
RedBoot options are compiled into the code only if that option is false.
This implies that the compile time option overrides any chance that RedBoot
has to set the ESA.
[snip rest]2) I notice that, in some cases, the cdl for the platform specific ethernet
driver contains the "implements CYGHWR_NET_DRIVERS" command while, in
others, the chip driver contains that command. (Case in point: the edb7xxx
platform does not implement it, but instead, relies on the cs8900a driver to
implement it, while the innovator (and flexanet, from which innovator was
derived/stolen/copied) and smsc91xx drivers do the opposite.) What are
there pros and cons of one technique vs. the other?
3) I noticed that the CYGPKG_DEVS_ETH_ARM_EDB7XXX package defined a
subpackage named CYGPKG_DEVS_ETH_ARM_EDB7XXX_ETH0 which is where the
interesting options for the edb7xxx ethernet driver could be configured.
The innovator (and flexanet, blah blah blah) put all of its options directly
under CYGPKG_DEVS_ETH_ARM_INNOVATOR. Basically, I have the same question as
#2 here, why would/could one approach be considered to be better than the
other?
Perhaps it makes it more flexible to add new interfaces if you're ever
likely to extend it (e.g. a new board revision). Or more likely it was
derived from a different driver that had multiple interfaces, so it just
copied that template. The latter (with the _ETH0) is probably more
flexible but it's not that important.