I think I should continue here, sorry that my previous response was to gcc requirements.
David Hendricks wrote:
Can you be more specific? I ran thru the instructions and built for a qemu target and did not run into any problems
Here are the commands that I've used. Without submodules, coreboot won't compile. The only reason for this is the badly integrated vboot submodule, nothing else. All the other submodules are optional.
$ git clone https://review.coreboot.org/coreboot $ cd coreboot $ make crossgcc-i386 CPUS=2 $ make -C payloads/coreinfo olddefconfig $ make -C payloads/coreinfo $ make menuconfig
(here I've added coreinfo payload)
$ make safedefconfig $ cat defconfig CONFIG_PAYLOAD_ELF=y CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf" $ cat .config | grep VBOOT # CONFIG_VBOOT is not set CONFIG_VBOOT_VBNV_OFFSET=0x2c $ make
(... removed for clearity ...)
FMAP build/util/cbfstool/fmaptool -h build/fmap_config.h build/fmap.fmd build/fmap.fmap SUCCESS: Wrote 182 bytes to file 'build/fmap.fmap' (and generated header) The sections containing CBFSes are: COREBOOT CP bootblock/arch/x86/memlayout.ld In file included from src/arch/x86/memlayout.ld:3: src/include/memlayout.h:9:10: fatal error: vb2_constants.h: No such file or directory #include <vb2_constants.h> ^~~~~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:362: build/bootblock/arch/x86/memlayout.ld] Error 1 $
(here I've simply commented out the include inside memlayout.h for a quick test)
$ make GEN build.h CC bootblock/arch/x86/id.o CP bootblock/arch/x86/memlayout.ld CC bootblock/arch/x86/memmove.o CC bootblock/arch/x86/memset.o CC bootblock/arch/x86/mmap_boot.o CC bootblock/arch/x86/post.o CC bootblock/arch/x86/timestamp.o CC bootblock/commonlib/bsd/cbfs_private.o In file included from src/commonlib/bsd/include/commonlib/bsd/cbfs_private.h:8, from src/commonlib/bsd/cbfs_private.c:3: src/commonlib/bsd/include/commonlib/bsd/cbfs_serialized.h:7:10: fatal error: vb2_sha.h: No such file or directory #include <vb2_sha.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:362: build/bootblock/commonlib/bsd/cbfs_private.o] Error 1 $
I'd like put emphasis on this part:
$ cat .config | grep VBOOT # CONFIG_VBOOT is not set
and on the fact by removing the include from memlayout.h solved the issue and the compilation went a step further. This means that include clearly doesn't belong there.
David Hendricks wrote:
As Julius mentioned this is possible but it's a fair bit of work with little benefit.
Patrick Georgi wrote:
I lined out how that could look like above.
I believe you are both unnecessarily overcomplicate this. The way I see it the only issue here is a few missing ifdef guards for CONFIG_VBOOT in cbfs, that's all. Quite straightforward to solve.
Forcing vboot on users is not the right answer, imho. Integrating vboot with proper ifdef guards is. But that's just my two cents.
Have a nice day, bzt
On 11/18/20, Patrick Georgi via coreboot coreboot@coreboot.org wrote:
Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge peter@stuge.se:
Patrick Georgi via coreboot wrote:
coreboot doesn't, cbfstool does.
If that were the case things would already be a lot better!
Alas, coreboot unconditionally requires vboot in these files:
Oops, I forgot about those, you're right!
So: we discussed that in today's meeting and had two take-aways:
- people have issues with older host toolchains failing to build vboot.
We'll work on improving those scenarios.
- We generally prefer to build our utilities fully featured to prevent
partial feature sets from popping up in installed binaries. That said, if there were a patch that cleanly cuts out cbfs hashing support from coreboot (and cbfstool used for building coreboot) based on a Kconfig flag, we would consider it.
"Cleanly" meaning:
- It needs to be optional
- The result needs to be maintainable. Things shouldn't break apart when
looking at the flag funny
- cbfstool should behave properly and reasonably when built without
hashing but the relevant options are used (that is: say that it's a stripped down build, not just "command line error")
- cbfstool and cbfs in coreboot without those flags still need to be able
to deal with hash attributes sanely, that is, skip them safely. I don't expect that to be an issue (the data structures are robust enough), but something to keep in mind.
Maybe we view Kconfig differently. I expect it to control not only the
final build artefact but also the build process, meaning what gets built and what is needed for successful build.
I'm not entirely happy about the way we use Kconfig to enable ccache (to pick an example) because IMHO changes to config.h should lead to a different coreboot build (outside config.h). I guess with this "feature", the build would be different, so this satisfies my personal criterion.
Right, but maybe we at least agree that requiring some submodule(s) for nothing is at a minimum unneccessary?
As I mentioned elsewhere, we could import vboot as a git subtree (even though I wouldn't recommend it). That changes next-to-nothing for users (but makes life hell for developers), but satisfies that criterion. So, why the hate on submodules?
I don't want any submodules, so I go over the source and remove the
requirement.
I lined out how that could look like above. (Good) Patches accepted.
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado