[coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C code

[Carl-Daniel Hailfinger]

On 29.02.2008 01:39, Peter Stuge wrote:
> Ron, awesome writeup! Thanks for putting it together so well!
>   

Indeed, thanks!


> On Thu, Feb 28, 2008 at 10:40:41AM -0800, ron minnich wrote:
>   
>> In general, control variables that are not intended to be changed,
>> and which can cause undetectable problems, should remain in C code.
>>     
>
> Disagree. Or - well - variables controlling _what_ exactly?
>   

If they are constant for all code, simply use one #define or declare the 
stuff as const for better type checking.


>> I am inclined to include Cache As Ram (CAR) settings here. CAR is
>> very tricky. It's easy to get it slightly wrong, and not know it. I
>> think CAR settings should, once they are right, remain hidden and
>> hard to adjust.
>>
>> DRAM timing that is fixed belongs here too.
>>     
>
> Code should be used for runtime logic. I have a huge issue of
> principle with code being used as data storage when there exists
> another good method intended specifically for the purpose.
> [...]
> Another is a compiler/linker that generates code which doesn't use a
> data segment for storage, but the code segment. Static initialized
> data is compiled into move instructions that copy data from code at
> runtime.
>   

Move instructions shouldn't happen if the data is declared const.


>> dts should be used for control variables that are per-mainboard.
>>     
>
> Yes! I equate this with specifics of the hardware design. What is
> connected where and in cases where it matters also how it is
> connected. For example how interrupts are routed to PCI slots, if
> those four muxed signals on the sobridge are used for COM2 or SATA
> on this board, and the timing compensation constant that is needed
> for the particular series resistance to RAM on this board. (for MCs
> that have such settings.)
>   

What about per-mainboard settings which are totally uninteresting to 
stage2 and payload?


>> The dts variables are currently usually static for a given
>> mainboard, since they reflect the hardware of the mainboard.
>>     
>
> Yep.
>
>   
>> The device tree compiler compiles dts down to C code for use by the
>> image. Currently this code is initialized structures and a .h file
>> with type definitions.
>>     
>
> I agree 100% with you on the dts, but I think your reasoning around
> the C code goes against it. :\
>
>   
>> Kconfig should rarely, if ever, be used to set device options that
>> belong in the dts; or, set very low level build options such as
>> DRAM timing.
>>     
>
> It may be tempting to add (invisble) data into Kconfig. This is
> presumably because it is simple to create dependencies and easy
> to access in code.
>
> That would be a testament to dts not being easy enough to deal with.
>   

We already have invisible data in Kconfig because we need to access that 
data when the device tree is not yet available. CARBASE is an example of 
that. It is constant for a given subarch, but also used by the generic 
printk code (and that code is not subarch-specific).

I wrote this in another thread:

We currently abuse Kconfig for settings which should be available 
before/outside stage2, iow when the device tree is not available. 
Depending on our design stategy, we may want to generate a subset of the 
device tree as #defines suitable for inclusion outside stage2.


Regards,
Carl-Daniel

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