When should we retire newconfig?

[Patrick Georgi]

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

On January 6, 2010 at 12:03 PM Patrick Georgi  wrote:
> 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.

Hello Patrick,
Are there any boards that have completely crossed over that I can look at for an
example?

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