[U-Boot] Design principles

[Wolfgang Denk]

Dear Detlev,

In message <m2sk7ngv95.fsf at ohwell.denx.de> you wrote:
> 
> >> > We do not want to touch interfaces that we don't use. If we don't use
...


...
> Full ACK and I really _never_ questioned this.

Good.

> > I cannot understand how you might think that writing some data to
> > registers or internal RAM of a device could be NOT considered as
> > "touching" this device. You modify the state of this device, ergo you
> > are touching it. Or not?
> 
> This is getting philosophical, really and I can find good arguments for
> both views: If you consider the mac sram cells to be part of the state
> of the device, you _do_ change the state.  On the other hand, the
> ethernet controller ip block very likely has no idea whatsoever if those
> sram was touched, so in this view you _do not_ change the state.

This argument takes you from bad to worse. If you consider this SRAM
as a separate device (not related to the Ethernet), then the
"Initialize devices only when they are needed within U-Boot" rule
still means that this SRAM device shall not be touched, as we don't
need or use it in U-Boot (unless running some network command).


> So if this is getting philosophical, why not ask the question "under
> what circumstances could this writing into sram have negative
> effects?".  I for myself cannot find any point to raise here.

With this approach we can probably partially initialize a number of
other devices as well.

But does it make sense?  Shall we start to accept code that will
perform the "fast" part of initialization for a random collection of
devices?  Leaving devices in a "half-initialized" state?

As I see it, the core problem is a gap loophole in the (ARM) Linux
kernel interface. If we had - for example - device tree support for
ARM, or something like a MAC ATAG, all this discussion would be void.

Do you agree?

So why cannot you simply concede that we are knowingly violating our
own rules and take the line of least resistance?


> Yes, it solves a problem.  Also it is a static initialization which I
> feel is something the bootloader should do.  U-Boot knows ethaddr, so
> again I see no negative, only positive consequences of doing such a
> thing

It is a violation of the design rule, still. We don't make any
difference there between "static" or "dynamic", "fast" or "slow"
initializations.  I think it is good that we don't.

> > If you re-read my previous postings in this thread you might even see
> > that I tend to take a pretty pragmatic position here and support  the
> > suggested fix for the exiting (obviously incorrect) behaviour.
> 
> So it seems I did not understand your "please include in your fix"
> statement.  Can you tell me exactly what you meant by this?


I was referring to this part of Heikos mail:

> While writing this, and realizing that this behaviour is a feature,
> maybe this problem occur on other network drivers on arm plattforms
> too ... hah, found one:
> 
> drivers/net/kirkwood_egiga.c
> 
> did it in the same way as drivers/net/fec_mxc.c ... Ok, it is
> in line with uboot standard, but arm plattforms which booting
> linux without doing network trafic under uboot tend to have
> different mac addresses ...
> 
> This should be solved!

The "Please include in your fix" means that the same bug fix as
implemented for the fec_mxc driver should also be applied to the
kirkwood_egiga driver - I see no sense in knowing the same bug is in
two files and fixing it in just one.


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
Never ascribe to malice that which can  adequately  be  explained  by
stupidity.