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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
