[U-Boot] Design principles

[Wolfgang Denk]

Dear Heiko,

in message <4BADB479.6050604 at denx.de> you wrote:
> 
> > 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?

As far as I am concerned, I already said so.

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

Right.

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

It makes obviously no sense to embedded systems to boot a ramdisk
just to set the MAC address so we can then boot for example with root
file system over NFS.  I feel that people suggesting this must be (at
least in this respekt) so narrow minded that they coold look through
a keyhole with both eyes.

It definitely is a good idea to support all activities to bring
device-tree support for ARM, as this will solve a number of other
issues as well.


In U-Boot, we cannot change the whole world. We can strive to get
clean interfaces to the Linux kernel, and object against adding new
code to U-Boot that violates the design principles.  On the other
hand, no review is perfect, and there are many places in the U-Boot
code that are far from perfect.  And if these imperfect pieces of code
contain obvious bugs (as is the case here), it makes perfect sense at
least to fix these bugs as long it is not possible yet (for whatever
reasons) to replace the whole code with a Perfect Implementation (TM).

So please go on and (re-) submit your (extended) patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Be wiser than other people if you can, but do not tell them so.
                                       -- Philip Earl of Chesterfield