[U-Boot] Design principles

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Detlev Zundel,
> 
> In message <m27hozgrrn.fsf at ohwell.denx.de> you wrote:
[...]
>> We are drifing apart even more.  I do not say that I grasp every part of
>> the kirkwood_egiga driver, but for me it seems like it only reads
>> the ethaddr environment addresses which I fail to see why it does that.
> 
> I think it does so to initialize the envrionment with a (semi-) random
> private MAC address if none is set.

Yep, exactly.

>> What I cannot see is that it programs the mac address in any way.  So
>> what exactly is the bug you are referring to here and how do you "support
>> a pragmatic fix"?
> 
> I did not look at that driver until now. It was Heiko who said that
> "this problem occur on other network drivers" and lists
> kirkwood_egiga as an example.
> 
> 
> My request was to apply the fix that Heiko submitted for fec_mxc.c to
> all other drivers as well that have the sam problem (as far as we

I can make such an attempt, if It gets accepted here?

> know about these, of course). So if kirkwood_egiga is clean (in this
> respect), there is no need to change it.

It ends in the same problem, as the fec_mxc.c driver has ...

If not running network commands in u-boot, the mac is not setup
which results in the problem with booting an arm Linux Kernel.

If running network commands in u-boot, the mac is setup properly
with the content from ethaddr ...

So, what to do? Accept the arm solution with first booting
an intrd and setup the mac with userspace tools, or waiting
for "arm Linux with DTS", or fixing this in u-boot now(maybe with
a comment that this is not in line with u-boot design goals,
and should go away, if arm linux is fixed (fixed is maybe not
the right word ... ))?

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany