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

ron minnich rminnich at gmail.com
Fri Feb 29 18:24:27 CET 2008


On Thu, Feb 28, 2008 at 4:39 PM, Peter Stuge <peter at stuge.se> wrote:

>  IMO an image is merely an instance of code. Fairly important
>  distinction since "image" doesn't say where code in question
>  came from.

let's call them targets then.


>
>
>  > A simple example is DRAM timing.
>
>  Violently disagree.
>

well, we might never agree on this one, but here is an offer. If you
want to prototype a dts which would have this info in it, and post it,
let's take a look. I admit I know it can be done.

>  > 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?

I introduced a term and did not define it.

How do we define variables, which are pretty special, such as CARBASE
and dram timing? What's the name?

>  One example is to make a USB device look like a HID when in fact it
>  is a UPS, because Windows programming is easier with HIDs or whatever.

point taken.


>  If data is worth having in the device tree after boot and can never
>  change at runtime - it belongs in the dts file at build time.

But almost all dram timing is unknown at runtime. We should design for
that case.

>  stuge at n410c ~/co/v3/mainboard/pcengines/alix1c $ ls -l
>  total 36
>  -rw-r--r-- 1 stuge stuge 1082 Feb 15 03:02 Kconfig
>  -rw-r--r-- 1 stuge stuge 1330 Feb 15 03:02 Makefile
>  -rw-r--r-- 1 stuge stuge 2517 Jan 24 04:14 cmos.layout
>  -rw-r--r-- 1 stuge stuge 1717 Feb 29 01:16 dts
>  -rw-r--r-- 1 stuge stuge 4437 Feb 29 01:16 initram.c
>  -rw-r--r-- 1 stuge stuge 5936 Feb 15 03:02 irq_tables.c
>  -rw-r--r-- 1 stuge stuge 1641 Feb 15 03:02 stage1.c
>  stuge at n410c ~/co/v3/mainboard/pcengines/alix1c $

yea, but that code is really tricky due to mainboard inefficiencies
and bugs and ... I think squeezing that very last bit out is going to
be hard, and in the end, we might end up with the moral equivalent of
GNU autoconfig - - sure, there's less code to see, but it's impossible
to figure out what's going on.

Some times, 50 lines of special case code are better than 5000 lines
of generic incomprehensible code.

>  Granted, K8 will be more interesting than Geode in this regard.

yes, let's see how k8 goes ...


>  I would like to have RAM components.

but it will only cover a trivial case -- it won't help most of our targets.

>  I just had another thought; I could probably be convinced that
>  components don't need a dts. We're currently using dtc as a C
>  preprocessor and there's not much point. But it doesn't do any
>  harm either and I do not feel at all strongly about it.

The did not initially have a dts, but some people strong-armed me into
doing it :-)
In the end, I really like it.

ron




More information about the coreboot mailing list