Hi Wolfgang,
>> > 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.
>
> This argument takes you from bad to worse. If you consider this SRAM
> as a separate device (not related to the Ethernet), then the
> "Initialize devices only when they are needed within U-Boot" rule
> still means that this SRAM device shall not be touched, as we don't
> need or use it in U-Boot (unless running some network command).
You are regarding 6 bytes of SRAM as a device _only so you can
mechanically apply a sentence to it_ which may loose its meaning in the
process? You loose me down this route, sorry.
There was this quote on this mailing list previously so maybe it is time
to repost it:
A foolish consistency is the hobgoblin of little minds.
-- Ralph Waldo Emerson
>> 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.
>
> With this approach we can probably partially initialize a number of
> other devices as well.
This is only if you accept that writing 6 bytes of SRAM is "partly
initializing a device", which I do not follow, sorry.
> But does it make sense? Shall we start to accept code that will
> perform the "fast" part of initialization for a random collection of
> devices? Leaving devices in a "half-initialized" state?
Again, I do not agree on the "half-initialized state".
> As I see it, the core problem is a gap loophole in the (ARM) Linux
> kernel interface. If we had - for example - device tree support for
> ARM, or something like a MAC ATAG, all this discussion would be void.
>
> Do you agree?
Not quite. I know that this topic crept up on ARM, but actually it was
also the netdev mailing list that turned down the attempts to allow for
mac addresses to be passed to the network drivers. So this is not
bounded to ARM.
I would rather restate it in the light of "what initializations are to
be done by the firmware and what initializations are to be done by the
linux drivers".
Now this is a controversial thing, for sure, but it is all the more
worthy of real reflection instead of blindly applying rules.
> So why cannot you simply concede that we are knowingly violating our
> own rules and take the line of least resistance?
Why should I? I still do not believe that following a sentence blindly
is one of our rules, sorry. If this is what you think, then say so
clearly and we can let the discussion rest as then there is no room for
discussion in the first place.
I also tried for quite a length to explain why I also consider this not
a "least resistance" way - no matter how often you repeat it.
>> 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
>
> It is a violation of the design rule, still. We don't make any
> difference there between "static" or "dynamic", "fast" or "slow"
> initializations. I think it is good that we don't.
For myself I disagree. I do not consider switching off thought to be a
good 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?
>
>
> I was referring to this part of Heikos mail:
>
>> While writing this, and realizing that this behaviour is a feature,
>> maybe this problem occur on other network drivers on arm plattforms
>> too ... hah, found one:
>>
>> drivers/net/kirkwood_egiga.c
>>
>> did it in the same way as drivers/net/fec_mxc.c ... Ok, it is
>> in line with uboot standard, but arm plattforms which booting
>> linux without doing network trafic under uboot tend to have
>> different mac addresses ...
>>
>> This should be solved!
>
> The "Please include in your fix" means that the same bug fix as
> implemented for the fec_mxc driver should also be applied to the
> kirkwood_egiga driver - I see no sense in knowing the same bug is in
> two files and fixing it in just one.
We are drifing apart even more. I do not say that I grasp every part of
the kirkwood_egiga driver, but for me it seems like it only reads
the ethaddr environment addresses which I fail to see why it does that.
What I cannot see is that it programs the mac address in any way. So
what exactly is the bug you are referring to here and how do you "support
a pragmatic fix"?
Cheers
Detlev
--
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
-- John McCarthy (1980)
--
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
