Ken,
Ken.Fuchs@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