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: d...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
