[coreboot] Solution to: filo build failure: get_multiboot_info is undefined

[Peter Stuge]

Ken,

Ken.Fuchs at bench.com wrote:
> libpayload was simply missing the CONFIG_MULTIBOOT option.
..
> Making no selections in either libpayload or filo results in the
> build failure quoted above.

Thanks for tracking this issue down! I think this is very important
from a QA and "user experience" perspective. There are so many
components related to coreboot that it is important to make sure that
they fit together really well.


> However, the instructions should also result in no build errors
> when _no_ explicit configuration changes where made to either
> software package.

I agree. A short term fix could be to disable multiboot support in
FILO by default.

Longer term, I can come up with two ideas:

1. FILO and other programs using libpayload can "autodetect" relevant
   settings in libpayload, and adjust their own configuration
   accordingly.

2. Make sure that libpayload and all it's users keep having
   harmonized default values.

Of these I think 1. is the only one which is really sustainable. In
practise it could take the shape of a pre-configuration script which
presets the current payload configuartion (FILO) according to how
libpayload was built, and a "validator" which is used to check that
any changes from e.g. make menuconfig are actually compatible with
how libpayload was configured. It would be very nice to catch this
already before trying to build, and give a helpful error message
rather than failing at the linker stage.

Ideally I would like libpayload Kconfig to be integrated with the
payload (e.g. FILO) Kconfig, so that there is really only one knob to
turn in order to get, say, multiboot support. Can that be done? I
think it's good for libpayload to also "reach into" the payload
config/build process. Normally I might not, but I think the
consistency it allows is a very important feature.


> This may seem trivial, but most people don't expect to see build
> errors when they carefully follow the instructions and make only
> selections that are explicit within the instructions.

This is a good point.

buildrom is still a good way to build coreboot and payloads, without
being forced to get into all the details of every single component.

But, this is an issue with libpayload that at least I haven't thought
much about earlier, and I think it would be nice to improve the
failure mode.


> I also noticed that the following two invocations have different
> effect
> 
> $ make defconfig
> 
> $ make menuconfig
> <Save config without making any (new) selections.>
> 
> Arguably, both the above make invocations should result in the same
> configuration.

I'd also expect that. Can anyone say why they don't? defconfig just
pulls in the same config as menuconfig when started blank, or no?


> I'm very impressed by the new build system and coreboot.org web
> site. Both have improved immensely over the past 4-5 years. 
> Commercial BIOS vendors are no doubt green with envy.

Wow! Very kind words, thank you so much Ken. You just made my day. :)
And thanks for helping with further improvement!


//Peter