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

[Marc Jones]

On Mon, May 16, 2011 at 1:18 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> Am 16.05.2011 01:42, schrieb Peter Stuge:
>> Talking to a lot of visitors at LinuxTag it is absolutely clear that
>> this is an example of what should actually be an NVRAM option.
>>
>> Do we have some policy for where to place an option? I don't think we
>> do. Do we want to create one?
> My idea for a long term plan:
> - move most stuff to NVRAM
> - allow defaults in NVRAM config (per chip component)
> - allow boards to override these defaults
> - allow boards to lock down options (so they're compiled out in our code
> and present as "hard coded values" in cbtable)
> - probably/eventually: allow user to change defaults/lock them down in
> Kconfig
>
> That way we can make everything flexible, yet lock down options that
> make no sense (eg. disable IDE/SATA option on boards with IDE function
> on chip but no connector on board).
> The hard part will be (again) how to extend Kconfig, and I guess this
> will require automatic Kconfig file creation (ie. Makefile magic).
> But since this is the last step (right after Infrastructure
> Projects/CMOS), this can wait.
>

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.

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.

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.

3. Devicetree is a good place for platform configuration, but the
allocator is complicated and not documented. Options are not available
in the romstage.

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.

Marc


-- 
http://se-eng.com