Folks, I'm working on coreboot on ARMv8 architecture and recently attempted to verify FW_B can be selected if FW_A is corrupted.
In reviewing the code-path through coreboot vboot wrapper and vboot_reference library I'm not understanding the logic.
The logic appears to be that vboot_reference library determines FW_A is corrupt and forces a reboot.
After reboot, early in verstage_main(), both the NVRAM (flash) and vb2_context structures are initialized, wiping out any history of failure condition.
I know I must be missing something in my analysis but don't see it.
Can anybody on this list share their experiences in confirming the FW_B boot path if FW_A is corrupt? Cheers, T.mike
On Tue, Feb 14, 2017 at 8:26 PM, tturne@codeaurora.org wrote:
Folks, I'm working on coreboot on ARMv8 architecture and recently attempted to verify FW_B can be selected if FW_A is corrupted.
In reviewing the code-path through coreboot vboot wrapper and vboot_reference library I'm not understanding the logic.
The logic appears to be that vboot_reference library determines FW_A is corrupt and forces a reboot.
After reboot, early in verstage_main(), both the NVRAM (flash) and vb2_context structures are initialized, wiping out any history of failure condition.
I know I must be missing something in my analysis but don't see it.
Can anybody on this list share their experiences in confirming the FW_B boot path if FW_A is corrupt?
ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The vbnv (vboot non-volatile) storage keeps counts for slots to try. vb2_select_fw_slot() will do that work for you. It's located in firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2() in firmware/2lib/2api.c. All this logic lives in vboot_reference code repository.
Cheers, T.mike
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Aaron Durbin -
tturneļ¼ codeaurora.org