[coreboot] When should we retire newconfig?
patrick at georgi-clan.de
Wed Jan 6 13:03:07 CET 2010
With r5000 all boards build with kconfig. The last step of the
build&config project is to eliminate the old system so we're down to one
method of building an image.
What issues remain before we can remove newconfig from the tree?
My list currently contains:
* Kconfig must match newconfig for all boards, as appropriate.
The automatic KBuild report on the list (which can be regenerated
locally by running util/kbuildall/kbuildall) gives some indication on
how much work is left in that area.
* More testing
I'm not sure how many boards and chipsets were successfully run with a
kconfig image recently.
* Fallback/normal switch
While the hard part in code is done for the switch (via tinybootblock),
there are some issues left. kbuild always builds just one image, not two
as would be necessary to build fallback/normal in a single pass.
Question is, do we want that?
In my opinion, it's more sensible to have a way to add to and update an
existing coreboot image, and expect users who rely on fallback/normal to
build twice (into the same image), with an appropriate configuration for
Either way, this requires support in the build system (either to update,
or to build twice in one go), and some alternative tinybootblock routine.
I'll try to work out some documentation for the new config system and
code flow (esp. tinybootblock).
Apart from that, with kconfig, many of the build tutorials on the wiki
will be outdated.
More information about the coreboot