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

["Patrick Doyle" <wpd at delcomsys dot com>]

I have moved this to ecos-discuss.  Sorry to the folks who have come in
halfway through the discussion.  Oh well...

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

Hmmm... light is almost dawning upon marble head...
If I have a RedBoot on the board, and I use it to load an application for
which 'CYGSEM_DEVS_ETH_ARM_EDB7XXX_ETH0_SET_ESA' is true, then that will
override whatever option was built into RedBoot (flash, hardwired, or
eeprom).
If I have a RedBoot on the board, and I use it to load an application for
which 'CYGSEM_DEVS_ETH_ARM_EDB7XXX_ETH0_SET_ESA' is _false_, then the
application will attempt to use the RedBoot provisioned ESA, or fall back to
the eeprom (if none was provisioned).

So, what happens if RedBoot was configured (and installed on the board) with
'*_SET_*' to true?  There will be no ESA parameters in FLASH, so the
application will either provide its own, or use the eeprom.

So, what happens if I run a RedBoot with '*_SET_*' set to false, write an
ESA to flash, and then install my previous RedBoot (with '*_SET_*' set to
true) as the bootloader?  I suspect that the application would get the
fconfig'd ESA.

(This last case could be one of taking very careful aim at one's foot and
pulling the trigger, or it could be a case of version skew between different
development efforts, leading to some bizarre configuration problems.)

1) Am I misinterpreting something here?

Actually, as long as I am asking questions, a couple more popped into my
head as i was wandering through the code...

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?

--wpd


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