[coreboot] some thoughts on dts vs. Kconfig vs. makefiles vs. C code
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.
> 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
> 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.
More information about the coreboot