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