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)


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


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