Am Mittwoch, den 26.08.2009, 20:57 -0700 schrieb ron minnich:
Would be interesting, for working targets, to create a defconfig in the mainboard directory for that target. Then, as each mainboard is tested and known-good in Kconfig, people (and an automated tool) could easily see that we had a Kconfig-supported mainboard.
A defconfig per board when we already set defaults in the Kconfig files? That's redundant, isn't it?
Given that we want to impose a structure on the Kconfig files, we could probably automate creation of "default configs". Try this prototype: #!/bin/sh # $1: mainboarddir gmake distclean || make distclean grep "depends[\t ]on[\t ]*VENDOR" src/mainboard/$1/../Kconfig | sed \ "s,^.*(VENDOR_.*)[^A-Z0-9_]*,CONFIG_\1=y," > .config grep "config[\t ]*BOARD" src/mainboard/$1/Kconfig | \ sed "s,^.*(BOARD_.*)[^A-Z0-9_]*,CONFIG_\1=y," >> .config grep "select[\t ]*ARCH" src/mainboard/$1/Kconfig | \ sed "s,^.*(ARCH_.*)[^A-Z0-9_]*,CONFIG_\1=y," >> .config echo "CONFIG_MAINBOARD_DIR=$1" >> .config yes "" | (make oldconfig || gmake oldconfig)
put that in the top level of coreboot-v2 (say as createconfig.sh) and run ./createconfig.sh via/vt8454c
This cleans out the current config, creates the smallest necessary set of definitions, and runs oldconfig over it, choosing the default options for every question asked. (allyesconfig misbehaves in that it changes the board selection, and defconfig merely copies a pre-existing file)
So far, it only works for the via boards, as the others aren't normalized yet.
Patrick