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

[Marc Jones]

On Mon, May 16, 2011 at 11:26 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> 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.
>

I think that Kconfig should be about building the platform (make). We
have overloaded it with platform configurations that I feel don't
really belong there.  There are a few items for where the make needs
to understand the the code size requirement etc, but options about
memory types, and CPU or slot numbers etc, don't belong there.

>> 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).
>

I agree, but I think that there are few options that might be useful
for an end user to change, but there are many platform config that are
not appropriate CMOS options.

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

CMOS options should only be for runtime options. I think that there
are far more build time and platform configurations than there are
runtime. But, I'll be interested to see what your thoughts are.

>> 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.
>
>
> Patrick

I think that any guidance we could provide would be an improvement.

Marc


-- 
http://se-eng.com