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