[coreboot] v3 patch: fix dtc to correctly parse @x values as hex, not decimal.

[Carl-Daniel Hailfinger]

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...)


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/