Hi,
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 each run. Either way, this requires support in the build system (either to update, or to build twice in one go), and some alternative tinybootblock routine.
* Documentation 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.
Patrick