[coreboot] newconfig to Kconfig for Dummies

Patrick Georgi patrick at georgi-clan.de
Thu Feb 4 11:55:49 CET 2010


Am 04.02.2010 05:47, schrieb Joseph Smith:
> Hello,
> I really want to get my boards up to date, but I really don't know where
> to start. I ran the kbuildall util on my boards, stared at the the files
> it created for about an hour and then walked away. Being new to Kconfig
> and all I am a bit lost. If someone could please write a brief
> "newconfig to Kconfig for Dummies" I would be truly grateful.
The simplest test of all is to build boards and try to run the images
generated by it (build/coreboot.rom)

Then, kbuildall compares the configuration between newconfig and kconfig
- it's printed in our kbuild reports on the list, and by kbuildall after
every build. It's also stored in
kbuildall.results/vendor_board.variables.txt

With that list in hand, you can edit the board's Kconfig file to match
up differences between newconfig (prefixed with "-" in the report) and
kconfig (prefixed with "+").

We generally have two methods of setting variables:

Normally you'll need the 4-liner as commonly used:
config WHATEVER (for CONFIG_WHATEVER)
	int (or hex, string, bool)
	default the_default_for_this_board
	depends on BOARD_VENDOR_MAINBOARD (as stated in the first entry)

The type is normally already defined in some global Kconfig file, and
should match it (src/Kconfig, src/arch/i386/Kconfig, or for northbridge
specific stuff in the respective northbridge directory)

For boolean values that default to false, you can set them with the
"select" statement in the board's entry as a shortcut (eg.
"select UDELAY_LAPIC")

Now the thing is that some values shouldn't end up in the board's
Kconfig, but in the Kconfig file of the component that is really
affected. For example, we set IOAPIC use per southbridge (as these have
to setup IOAPICs in our code)

Unfortunately, this decision is nothing we can easily define in a "for
Dummies" set of rules. But having all boards match the newconfig config
(and be boot-tested, sometimes newconfig is wrong, too!), even if that
information is stuffed into boards when it doesn't belong there is
better than the current state where values vary wildly.

So, having newconfig and kconfig match (ie. only have values differ in
the report that don't affect booting, eg. DEFAULT_LOGLEVEL), and have
them boot-tested with kconfig is a very useful goal for now.

We can still shuffle items around later, but for now, newconfig is still
the gold standard. Once both match, we can kick out newconfig and move on.


Regards,
Patrick




More information about the coreboot mailing list