[U-Boot] Design principles

[Detlev Zundel <dzu@denx.de>]

Hi Wolfgang,

>> > We do not want to touch interfaces that we don't use. If we don't use
>> > Ethernet in U-Boot, there is no need to probe or initialize it.
>> 
>> Ok, I still don't get it.  Is this "we do not touch interfaces" a truth
>> not to be questioned or is it the essence of other goals we want to
>> achieve summed up in a nice fashion?
>
> You know pretty well that this a design principle which is intended to
> keep U-Boot small, fast, and flexible.

Exactly, it is the essence of these ultimate goals and not a credo in
itself.

> To me it makes little sense to initialize for example a network port
> (and wait hundrets of millisecods, or even seconds) for the link to
> come up and (auto-) negotiation to complete, when we do not use the
> network in U-Boot ourself, and when he have no knowledge if Linux
> will use the network interface (and if it does, it will usually
> re-initialize the PHY, thus waiting again). The same goes for the
> initialization of USB, IDE, or similar interfaces.

Full ACK and I really _never_ questioned this.

> I am well aware that not all code is working like this. Board ports
> that origin from earlier versions of U-Boot (or even from PPCBoot)
> behave differently.  This is a lesson we learned over time.
>
> But now it's written down.

And this is a good thing in full accordance with my previous statements.

> I am not sure at the moment if you question this design principle in
> general, or if you accept it as base for the ongoing discussion.
> Please say so, if you disagree here, so we can try to find a
> compromize to be used as base for this discussion.

I agree to the design principle but for the value it brings and not for
the words it is formulated in.

>> Because what I still fail to see is how writing 6 bytes into an SRAM
>> area is "touching a device".  Yet the absence of this code means that
>> there is no working solution at all to the problem at hand as you may
>> well know.
>> 
>> So can you please enlighten me why as to how initializing SRAM is
>> "touching a device" - or why exactly you oppose this so strict.
>
> 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.

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.

> I guess what you really want to tell us is that this initializing is
> not such a bad thing - it is quick and does not add any real delay to
> the boot process, and it solves a problem that otherwise needs to be
> solved elsewhere (in the Linux Ethernet driver, or the Linux boot
> API), where more effort is needed.

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

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

Cheers
  Detlev

-- 
A change in language can transform our appreciation of the cosmos
                       -- Benjamin Lee Whorf
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de