Hi Tim thanks for getting back to me, Your correct in the error spawns from `src/security/vboot/vboot_logic.c`. I took the liberty of having the `name` variable printed to the console to confirm what regions were being read. `GBB` (appears) to read without error however, despite leaving `VBOOT_SLOTS_RW_A` undefined (and not in the .fmd) it appears that `VBLOCK_A` is still attempted to be read.
My understanding was that when using a read-only flashmap for use in vboot, a `VBLOCK_A` section was not required, is this correct? I can add a `VBLOCK_A` section but it is not populated unless `VBOOT_SLOTS_RW_A` is defined, and make will fail due to no CBFS in `RW_SECTION_A`. Thanks again! Kind regards, Thomas On Tuesday, October 6, 2020 6:21 PM, Tim Wawrzynczak via coreboot [email protected] wrote: > Hi Thomas, > > On Tue, Oct 6, 2020 at 11:07 AM Thomas Clarke via coreboot > [email protected] wrote: > > > Greetings Coreboot community! > > > > I’m currently engaged in an effort to bring support for vboot on the Asus > > KGPE-D16 for use in the Heads boot environment. Things had been going well > > until I hit a bit of a snag detailed below. > > > > In both situations below vboot was started in the romstage by defining > > VBOOT_STARTS_IN_ROMSTAGE as true, VBOOT_VBNV_OFFSET was defined and > > corresponds to cmos.layout and VBOOT_NO_BOARD_SUPPORT defined as true. The > > coreboot version in use is 4.11. In both situations coreboot builds without > > error. > > > > Situation 1 (working): > > > > A flashmap (.fmd) is used spanning a 16M rom with the about the first half > > dedicated to RW_SECTION_A, a bit in the middle for MISC_RW and about the > > second half dedicated to WP_RO (including GBB) with COREBOOT(CBFS) aligned > > at the end. VBOOT_SLOTS_RW_A is defined as true. > > > > Monitoring the console output via serial, it is noted that vboot passes > > Phase 1, 2, 3 and 4 without error. It is also noted that during Phase 3, > > area GBB is found and area VBLOCK_A is found. The payload is launched. > > > > Situation 2 (not working): > > > > There is no `RW_SECTION_A` in the flashmap, a few hundred kilobytes is > > allocated to `MISC_RW` at the begging the the remainder is occupied by > > `WP_RO` as above. VBOOT_SLOTS_RW_A is left undefined (and is not configured > > further by `make olddefconfig`. > > > > Monitoring the console output in this situation notes that Phase 1 and 2 > > passes, Phase 3 begins and area GBB is found followed by `Reboot requested > > (100a0003)`, `Saving nvdata` and `board_reset() called`. The system will > > reboot (presumably) indefinitely. > > > > I presume based on the difference in the logs that in situation 2 vboot is > > looking for `VBLOCK_A`, not finding it, failing and rebooting but vboot > > isn’t very verbose so I find it difficult to find the fault and ultimately, > > the solution. > > This sounds correct to me based on what you are describing. The error code > you are looking for is here: > https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/2lib/include/2return_codes.h#710 > (VB2_ERROR_EX_READ_RESOURCE_SIZE). If you grep through coreboot's sources for > that, you'll find it in `src/security/vboot/vboot_logic.c`, where it is going > to load either the GBB or VBLOCK_{A,B} (depending on the slot), and if it > is unable to either locate or read from those, then it will return that > error, and vboot will be stuck in that reboot loop forever (that kind of > sounds like a bug somewhere; this is a fatal error, a reboot won't fix this > issue). > > Since you mention the logs say it found the GBB, then it sounds like it > either can't read the GBB or one of the VBLOCK_{A,B} section is missing, as > you point out. > > > > While I understand the KGPE-D16 was dropped in 4.12 things are really > > looking hopeful for having this supported under Heads. Providing I can pass > > this roadblock, this will be the only blob free, RYF certified, Qubes > > compatible board that has firmware verifiable provided a compatible TPM is > > used. > > That sounds like a worthy project! > > > > Thank you for taking the time to read this, and I welcome any feedback. > > > > Kind regards, > > > > Thomas > > _______________________________________________ > > coreboot mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > Good luck, > - Tim /[email protected]/[email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
