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 <[email protected]> wrote: > Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge <[email protected]>: > >> 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: > > 1. people have issues with older host toolchains failing to build vboot. > We'll work on improving those scenarios. > > 2. 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 > _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
