[coreboot] Runtime config

[Nico Huber]

Hello Bartek,

On 11.04.2018 22:48, bartek.pastudzki 3mdeb.com wrote:
> We have runtime configuration arguments implemented for our platform in
> out fork. This is very simple, we just add few lines in SeaBIOS
> configuration file on CBFS (https://bit.ly/2qmX9nT — config example,
> https://bit.ly/2v5Era6 — handling code). There are only boolean values,
> no syntax, config file of constant size. Perhaps too simple, but it
> serves its purpose. We use it to enable/disable additional UART, EHCI
> and other features. Configuration is done in a payload, but it is
> supposed to affect hardware initialization in coreboot.

thanks for sharing your implementation. I guess it's really too simple;
at some point you might want more than just booleans. And you seem to
assume that CBFS is memory mapped which might not always be the case.
Anyway, as you said "it serves its purpose" ;)

> 
> We would like to have this functionality in mainline coreboot. We expect
> that this proof-of-concept is not good enough to incorporate it, but the
> question is how much better we have to do that. We have read some
> discussion on this topic on mailing list and we have found many ideas
> how this should be done, however we haven't found any definite answer.

I think our primary focus should be to define a common interface, first,
for different implementations. There's already coreboot's "option table"
that is stored in RTC/CMOS RAM. Marcello has started some work to use
VPD as a backend [1]. There's your implementation; and finally, Felix
and me discussed a storage format specifically for dependable updates on
NOR flashes [2].

All of these approaches have their pros and cons. We could also try to
discuss which one is the best and focus on that, though I'd rather try
to stay flexible instead.

> 
> IMHO, a simple solution is the best one as long as it works well. It's
> also certainly better than nothing, especially that question appears
> again and again. A single fixed-size CBFS file seems to be enough for
> most applications. In fact, whole coreboot configuration is just 686
> lines, in my configuration, 602 of them are boolean or disabled, so they
> could be packed in ceil(602/8)=76 bytes. I think 8 bytes for each other
> is quite safe to assume (most of them needs less, some needs more).
> 76+8*82=748 b. So even if we'd like to pack the whole configuration into
> a binary file we'd need 1kB or less. No moving, no resizing, just fixed
> schema binary file, it could be easily done with CBFS.

Personally, I don't care about the space needed. I would wait with the
implementation until somebody really needs it packed tight.

Regarding CBFS, FWIW, taking the CBFS as something immutable is the idea
moving forward. Regions that are mutable (during firmware run-time)
should have their own FMAP entry.

> 
> To make it easy we'd prepare build system so that we could mark some
> options runtime-configurable in menuconfig. Based on those choices
> runtime-config structure would be generated as C header so that it can
> be easily used in source files.

I've had something alike in mind for some time now: Having a list of
options that can either be set at compile-time or run-time, defaults
should be set in the devicetree. From that we could generate Kconfig
entries and finally with a .config the values and / or code to read
them during run-time.

Ideally we'd always have defined default values. So the code using the
option interface won't be cluttered with error handling. Or we could
keep the get_option() style, where the calling code defines the default
value.

Nico

[1] https://review.coreboot.org/25550/
[2] https://mail.coreboot.org/pipermail/coreboot/2017-September/085215.html
     https://mail.coreboot.org/pipermail/coreboot/2017-October/085232.html