On Mon, May 16, 2011 at 11:26 AM, Patrick Georgi <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
