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.
(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 -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
Good luck,
- Tim