[U-Boot] Design principles (was: Re: [PATCH] net, fec_mxc: use mac address stored in env before looking in eeprom)

[Wolfgang Denk <wd@denx.de>]

Dear Detlev,

In message <m2hbo3jx28.fsf_-_@ohwell.denx.de> you wrote:
> 
> > 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.

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.

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.

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.

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


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.

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.


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
Where people stand is not as important as which way they face.
        - Terry Pratchett & Stephen Briggs, _The Discworld Companion_