This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ethernet driver questions (was RE: Innovator patches)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]