This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Ethernet driver questions (was RE: Innovator patches)
- From: "Patrick Doyle" <wpd at delcomsys dot com>
- To: "Jonathan Larmour" <jifl at eCosCentric dot com>
- Cc: "eCos" <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 14 Feb 2003 09:28:13 -0500
- Subject: [ECOS] RE: Ethernet driver questions (was RE: Innovator patches)
>
> 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 :-).
>
As I was thinking about it last night, I think that it is just a case of
moving some of the #ifdefs around so that the "devs_eth_inntovator.inl" code
(and later, the "devs_eth_arm_ed7xxx.inl" code from which it will have been
derived, once I am done) so that it behaves as you desire. I shall try that
when I return the the office this afternoon.
FWIW, at this stage of the game, do you want me to rename
"devs_eth_innovator.inl" to be "devs_eth_arm_innovator.inl"? I guess it
means that the next patch I produce will (somehow) delete the old file and
create the new.
> > 2) I notice that, in some cases, the cdl for the platform
[snip]
> I can't really imagine any advantage to either.
I couldn't either, but I wanted to make sure I wasn't missing something.
> > 3) I noticed that the CYGPKG_DEVS_ETH_ARM_EDB7XXX package defined a
[snip]
> flexible but it's not that important.
Ok, thanks...
--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