[coreboot] newconfig to Kconfig for Dummies

[Joseph Smith]

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


-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org