[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.
>
Ok, so here is what the Thomson IP1000 looks like (see notations):

-CONFIG_DCACHE_RAM_BASE  = 0xc0000 - I have no idea what this is for???
-CONFIG_DCACHE_RAM_SIZE  = 0x1000 - I have no idea what this is for???
+CONFIG_HAVE_HARD_RESET  = 0x0
+CONFIG_HAVE_HIGH_TABLES  = 0x1
+CONFIG_HAVE_PIRQ_TABLE  = 0x1
-CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x1 - Why would newconfig 
enable this for an Intel P3 processor? Is it enabled by default?
+CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT  = 0x0
+CONFIG_I830_VIDEO_MB_1MB  = 0x0
+CONFIG_I830_VIDEO_MB_512KB  = 0x0
+CONFIG_I830_VIDEO_MB_8MB  = 0x1
+CONFIG_I830_VIDEO_MB_OFF  = 0x0
-CONFIG_LOGICAL_CPUS  = 0x0 - Why would newconfig specify 0 cpus???
+CONFIG_LOGICAL_CPUS  = 0x1
-CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x0 - I want this to be enabled 
by default (0x1), so should I just change it in Options.lb?
+CONFIG_PCI_OPTION_ROM_RUN_REALMODE  = 0x1
+CONFIG_PCI_OPTION_ROM_RUN_X86EMU  = 0x0
+CONFIG_PCI_OPTION_ROM_RUN_YABEL  = 0x0
-CONFIG_PCI_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1), 
so should I just change it in Options.lb?
+CONFIG_PCI_ROM_RUN  = 0x1
-CONFIG_RAMBASE  = 0x4000 - What is the correct value?
+CONFIG_RAMBASE  = 0x100000 - It seems to work fine ether way?
-CONFIG_VGA_ROM_RUN  = 0x0 - I want this to be enabled by default (0x1), 
so should I just change it in Options.lb?
+CONFIG_VGA_ROM_RUN  = 0x1

Help.

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