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