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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed Mar 5 15:51:26 CET 2008

On 28.02.2008 19:40, ron minnich wrote:
> I have no idea if this helps. But there's been discussion of "DRAM
> settings in DTS" and "where does CARBASE go" and so on, so I think we
> need to try to document some rules. Here is a first cut.
> [...]
> Kconfig
> Kconfig has two uses. First, Kconfig is used to select a mainboard and
> set build options for the mainboard, e.g. whether compression is used or
> not. Kconfig can also set runtime parameters, such as baud rate for the
> console. Kconfig should rarely, if ever, be used to set device options
> that belong in the dts;

There is a problem with that approach. I disagree that baud rate for the 
console is different from the address of the serial port when you 
consider their scope. So it does not make sense to have one in Kconfig 
and one in the dts. Sure, the baud rate is going to be changed more 
often, but the amount of change a variable is going to see during 
configuration is not a consideration of the dts/Kconfig placing decision 

The address of the serial port is the poster child for how complicated 
the interaction between Kconfig and code and dts is:
mainboard/pcengines/alix1c/stage1.c:#define SERIAL_IOBASE 0x3f8
superio/winbond/w83627hf/dts: com1io = "0x3f8";
We need the #define in stage1 code because we have to access to the 
device tree yet. However, we also store the value in the dts. We also 
could place this in Kconfig (I'm against that) and control this centrally.

How about a way to mark a dts property "must be available as #define in 



More information about the coreboot mailing list