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.
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.
Thank you for taking the time to read this, and I welcome any feedback.
Kind regards,
Thomas