[coreboot] v3 patch: fix dtc to correctly parse @x values as hex, not decimal.
c-d.hailfinger.devel.2006 at gmx.net
Wed Jul 30 03:32:33 CEST 2008
On 30.07.2008 01:53, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> On 29.07.2008 22:10, ron minnich wrote:
>>> On Tue, Jul 29, 2008 at 1:05 PM, Stefan Reinauer
>>> <stepan at coresystems.de> wrote:
>>>> Peter Stuge wrote:
>>>>> Yes, I argued strongly for this when they first appeared and even
>>>>> sent a patch. The problem is that the filenames are tied hard into
>>>>> the struct names generated by dtc.
>>>> Hm. I definitely want to support your idea here then.
>>>> Adding .dts to the filename is about as hard as not doing that.
>>>> Also, in 2
>>>> out of 3 dts files I see struct names.
>> And what about files which are named dts right now? Do we call them
>> dts.dts (ugly) or .dts (hidden file)? Stripping a given file suffix in
>> dtc before creating the struct name is easy.
> Read my initial proposal.
That proposal said:
> To make clear what those files are, we should rename them...
> dts -> mainboard.dts
> ide -> ide.dts
> apic -> apic.dts
I can either take your words literally ( southbridge/amd/cs5536/dts
becomes southbridge/amd/cs5536/mainboard.dts ) or I take their intent
and conclude the initial proposal was incomplete.
>>>> If we'd really autocreate something, we should drop that behavior.
>> struct name autocreation is a feature I really like.
> Absolutely. "That behavior" meant mentioning the struct name manually
> in the dts files.
Indeed. I'll take a look at those files in the next few months. I'd be
happy if someone could tackle this before.
>>> oh no! it's harder! we blew it!
>> I'd like to disagree. I still haven't fully understood the v2 device
>> tree, while the v3 device tree seems obvious and simple to me.
> On a code level beyound the dts they're 100% the same. Now go compare
> a mainboard Config.lb (minus the makefile stuff) to the scattered dts
> mentioning struct names for components etc etc. It is really much more
> complex than in v2. Yet, it does not have more features.
>> v3 has a few perceived problems and a few real problems. The problem is
>> that everybody has his own idea about which problems are real. I'm not
>> claiming that my version of the story is the absolute truth(tm)
> What exactly are you trying to say?
It's like flashrom. Agreeing on features and roadmap is probably more
difficult than coding stuff up.
> What is your version of the story anyways?
The v2 config files are completely unreadable. In v3, the situation is a
lot better. Maybe not optimal, but orders of magnitude better than v2.
One thing I see as a problem in both versions is how I can specify
different settings for each instance of a chip appearing multiple times
on a board. (I may be misinterpreting struct name generation...)
More information about the coreboot