[coreboot] Kconfig vs. devicetree vs. CMOS policy for options?

Patrick Georgi patrick at georgi-clan.de
Mon May 16 19:26:51 CEST 2011

Am 16.05.2011 18:31, schrieb Marc Jones:
> These are hard problems and I don't know that there is a good answer.
> Each option seems like a good place to configure the platform, but all
> have drawbacks.
Right now CMOS is somewhat unpopular because it's strictly per-board.
Once we're able to move definitions for options to chipsets (if they
belong there), they're actually useful.

> 1. Kconfig is a poor place for device and platform configuration
> options. Kconfig is the right place for coreboot build options and
> standard features. The advantage of Kconfig is that the options are
> available in romstage.
Kconfig would be proper for user overrides of options. Definitely a
nicer way than requiring users to manage custom Kconfig _and_ custom
$whatever files. Hence Kconfig, but that should come last, once
everything else works properly.

> 2. CMOS is not a good place for platform options either. It is good
> for runtime options, but I don't think that there are many options for
> users to change. What options users would change and how will they
> change them? CMOS options could even go into the device tree.
The problem is that these overlap. See the example IDE/SATA. They ought
to be user configurable (so users can disable IDE on boards that provide
both), but they're also platform options, in case the board has no
connector (in which case it's useless to provide such an option).

So chipset defines that IDE and SATA (and their config options exist),
board overrides that and disables IDE (because no IDE exists).

> 3. Devicetree is a good place for platform configuration, but the
> allocator is complicated and not documented. Options are not available
> in the romstage.
For some things, yes. Others not so. This is really hard, but I'll
concentrate on getting CMOS handling in shape so we can actually make
use of it, instead of the poor job we're doing now.

> We should come up with some guidelines on what types of coreboot
> configuration belongs where. Each developer guesses each time or does
> what is easy for them at the time.
Because our tools suck. IMHO Guidelines are useless at this point.


More information about the coreboot mailing list