[coreboot] Understand vboot logic to select FW_B

tturne at codeaurora.org tturne at codeaurora.org
Wed Feb 15 18:38:47 CET 2017


On 2017-02-15 07:46, Aaron Durbin via coreboot wrote:
> On Tue, Feb 14, 2017 at 8:26 PM,  <tturne at 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.
> 

Thanks for this recap, I had identified most of this path previously.

I can clearly see the corrupted A slot being detected and the status 
updated and vboot requesting a reboot.
The reboot causes verstage to go through its initialization sequence, 
which in my case blows away the history of the reboot, so the cycle 
repeats endlessly.
FW_A slot detected as corrupt reboot requested to boot from FW_B, reboot 
blows away this data and FW_A is detected to be corrupt and reboot 
requested, etc.

I have verstage configured to run from bootblock, no DRAM/CBMEM 
available, just the RW_NVRAM fmap partition on the flash.
I haven't made any change in vboot_reference or the coreboot vboot 
wrapper layer so for me, out of the box, something is amiss.

I would be interested in hearing from anybody on the list on an ARMv8 
target who has run the same test I'm trying to reproduce here.
Specifically, I'm not running the test code in vboot_reference, I am 
manually corrupting partition A before flashing it.
Cheers,
T.mike

> 
>> Cheers,
>> T.mike
>> 
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list