On 02/04/2010 05:55 AM, Patrick Georgi wrote:
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.
Awsome. Thank you Patrick :-)