[ECOS] Re: Ethernet driver questions (was RE: Innovator patches)

[Jonathan Larmour]

Patrick Doyle wrote:
>>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]

In that case, I think you've stumbled across a problem with the cs8900a 
implementation rather than anything else! The intention was definitely 
that a hard-coded built address (which is by default off so requires user 
intention to enable) overrides the EEPROM, and defining an address in 
Flash (again default off) overrides all.

I think there's at least one other driver that tries to do it this way, 
although I don't remember which one off-hand. Perhaps that one works the 
way it was meant to :-).

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

I can't really imagine any advantage to either.

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

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss