[coreboot] Re: System gcc requirements
Julius Werner wrote: > > > needed in cbfstool (e.g. for the --hash-algorithm parameter to add a > > > hash attribute to a file), and there is no Kconfig cbfstool so you > > > can't just configure it out if you don't need it. > > > > It is clear that I don't need that functionality when I build a > > coreboot version without any vboot code, right? > > It's just an optional feature of cbfstool, it actually doesn't have > anything to do with the firmware verification part of vboot. I mean, > yes, you may not need it, but you may just as likely not need > --alignment or --topswap-size or --empty-fits Sure, but those don't pull in some other dependencies. > cbfstool is a toolbox utility that supports everything people may > want to do with CBFS images Thanks for the reminder. Consider the two different use cases, or build targets, for cbfstool. One is what you describe - a generic utility supporting everything that gets installed into say /usr/local/bin for lots of different invocations to do lots of different things with lots of different coreboot images. Two is specifically what is required to complete the configured build. It's certainly useful, and I argue highly desirable, to consider these two cases distinct. > The goal with linking vboot into cbfstool is generally to be > transparent, it's just pulling a few routines from a submodule, > you're not really supposed to notice it. It's absurd to me that coreboot would require any routines out of any submodule for a build which will not use those routines. I find that completely flawed. Even worse is that you find it acceptable, or desirable, that a submodule is silently pulled in during the build. That may be typical for web development, but nothing that should be proliferated. One purpose of Kconfig is to ensure that only what's neccessary gets built. > Just like when you run `make unit-tests` it's pulling in a third-party > testing library from a submodule but generally you don't need to care > about those details either. It's wrong to pull in anything during build. I too am guilty of this by pushing for buildgcc, it would be good to improve that case too. Anyway, I understand that your culture may be the complete opposite of mine. > I am just saying I don't think this discussion should be about vboot It is because that's what consistently causes me extra work and frustration every time I want to build a minimal coreboot. What some people always want isn't OK to require when other people do not want it. I think that's just lazy, and not the smart kind. :\ //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
> > vboot is used for more than just boot verification these days, we use > > it as a sort of generic crypto toolbox for all of coreboot's crypto > > needs (because it wouldn't make sense to implement, say, SHA-256 > > algorithms twice). For host utilities in particular, some of these are > > needed in cbfstool (e.g. for the --hash-algorithm parameter to add a > > hash attribute to a file), and there is no Kconfig cbfstool so you > > can't just configure it out if you don't need it. > > It is clear that I don't need that functionality when I build a > coreboot version without any vboot code, right? It's just an optional feature of cbfstool, it actually doesn't have anything to do with the firmware verification part of vboot. I mean, yes, you may not need it, but you may just as likely not need --alignment or --topswap-size or --empty-fits, or the locate, compact and add-flat-binary commands, or any other optional niche case feature that is supported in cbfstool. cbfstool is a toolbox utility that supports everything people may want to do with CBFS images, not all of which everyone necessarily needs. And it currently doesn't have a configuration infrastructure like Kconfig to disable individual features (and I hope that shouldn't become necessary either, because that would just make it complicated and confusing). The goal with linking vboot into cbfstool is generally to be transparent, it's just pulling a few routines from a submodule, you're not really supposed to notice it. Just like when you run `make unit-tests` it's pulling in a third-party testing library from a submodule but generally you don't need to care about those details either. Unfortunately, if there is a situation where you can run into issues that Jenkins couldn't test for, you may see those issues anywhere in the code you build including inside those submodules, but I think that's really a problem with Jenkins and not one one with using submodules. I am just saying I don't think this discussion should be about vboot just because an issue that could have occurred in literally any piece of code happened to occur in vboot code. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memory initialisation error
Don't know how to recover SPD from UEFI but Try to read memory part number written on chip and provide that. Look for SPD file with that name if it's already present in coreboot. Regards, Naresh solanki On Mon, 16 Nov, 2020, 11:46 pm Matt DeVillier, wrote: > > > src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params > called > > means your board isn't overriding mainboard_memory_init_params() -- so all > the defaults are being used, which I'm not sure will result in a bootable > device. You might want to look at the CML/CFL reference boards, or > system76/lemp9 to see how they are set up and then adapt for your board. > You'll definitely need to load the SPD somehow for a memory-down config, > though I'm not sure how to best obtain it from the stock firmware > > On Mon, Nov 16, 2020 at 11:36 AM Andy Pont > wrote: > >> Hello, >> >> I have some life out of my Comet Lake based board but the debug output >> ends with >> >> FMAP: area RW_MRC_CACHE found @ 42 (65536 bytes) >> MRC: no data in 'RW_MRC_CACHE' >> PRMRR disabled by config. >> WEAK: >> src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params >> >> called >> FspMemoryInit returned 0x8007 >> FspMemoryInit returned an error! >> >> The board has all of the memory soldered directly down. The spd.bin >> file in the build directory is 0 bytes. Is there a way to extract the >> correct SPD information from either the original UEFI firmware or from a >> running Linux system? >> >> -Andy. >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Feature request: add payload "Tianocore with SeaBIOS CSM"
I'm also interested in this option & raised it sometime last year. As a user, I don't have the skills necessary to do it, and was informed of the same conclusion. However, I DID succeed in building a coreboot which contains both Tianocore & SeaBIOS separately, then using Grub to choose which payload to run. You might try that. R On Mon, Nov 16, 2020 at 8:39 AM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote: > Am So., 15. Nov. 2020 um 19:43 Uhr schrieb Matt DeVillier < > matt.devill...@gmail.com>: > >> if it were as simple as building Tianocore with SeaBIOS as the CSM, that >> would be the default option offered, but unfortunately it's not. The >> neither Tianocore package (the default CorebootPayloadPkg, nor >> UefiPayloadPkg) has support for a CSM, like the emulator package (OmvhPkg). >> I maintain the default CorebootPayloadPkg, and have tried unsuccessfully to >> integrate SeaBIOS as a CSM, but I've also not put a ton of effort into it. >> If someone else manages to get it working, I'll gladly take a pull request >> on github >> > corebootPkg used to support CSM a long time ago. The remains are archived > at > https://code.georgi.software/patrick/corebootPkg/src/branch/coreboot-pkg/corebootPkg > (see > https://code.georgi.software/patrick/corebootPkg#user-content-csm-support > for some minimal documentation.) While I won't spend time reviving or > integrating it with the modern coreboot/edk2 bridges, it might serve as a > starting point for whoever is interested. Good luck. > > > 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 -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memory initialisation error
> src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params called means your board isn't overriding mainboard_memory_init_params() -- so all the defaults are being used, which I'm not sure will result in a bootable device. You might want to look at the CML/CFL reference boards, or system76/lemp9 to see how they are set up and then adapt for your board. You'll definitely need to load the SPD somehow for a memory-down config, though I'm not sure how to best obtain it from the stock firmware On Mon, Nov 16, 2020 at 11:36 AM Andy Pont wrote: > Hello, > > I have some life out of my Comet Lake based board but the debug output > ends with > > FMAP: area RW_MRC_CACHE found @ 42 (65536 bytes) > MRC: no data in 'RW_MRC_CACHE' > PRMRR disabled by config. > WEAK: > src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params > > called > FspMemoryInit returned 0x8007 > FspMemoryInit returned an error! > > The board has all of the memory soldered directly down. The spd.bin > file in the build directory is 0 bytes. Is there a way to extract the > correct SPD information from either the original UEFI firmware or from a > running Linux system? > > -Andy. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Memory initialisation error
Hello, I have some life out of my Comet Lake based board but the debug output ends with FMAP: area RW_MRC_CACHE found @ 42 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' PRMRR disabled by config. WEAK: src/soc/intel/cannonlake/romstage/fsp_params.c/mainboard_memory_init_params called FspMemoryInit returned 0x8007 FspMemoryInit returned an error! The board has all of the memory soldered directly down. The spd.bin file in the build directory is 0 bytes. Is there a way to extract the correct SPD information from either the original UEFI firmware or from a running Linux system? -Andy. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Feature request: add payload "Tianocore with SeaBIOS CSM"
Am So., 15. Nov. 2020 um 19:43 Uhr schrieb Matt DeVillier < matt.devill...@gmail.com>: > if it were as simple as building Tianocore with SeaBIOS as the CSM, that > would be the default option offered, but unfortunately it's not. The > neither Tianocore package (the default CorebootPayloadPkg, nor > UefiPayloadPkg) has support for a CSM, like the emulator package (OmvhPkg). > I maintain the default CorebootPayloadPkg, and have tried unsuccessfully to > integrate SeaBIOS as a CSM, but I've also not put a ton of effort into it. > If someone else manages to get it working, I'll gladly take a pull request > on github > corebootPkg used to support CSM a long time ago. The remains are archived at https://code.georgi.software/patrick/corebootPkg/src/branch/coreboot-pkg/corebootPkg (see https://code.georgi.software/patrick/corebootPkg#user-content-csm-support for some minimal documentation.) While I won't spend time reviving or integrating it with the modern coreboot/edk2 bridges, it might serve as a starting point for whoever is interested. Good luck. 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 -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
