[coreboot] Understand vboot logic to select FW_B

[Aaron Durbin]

On Wed, Feb 15, 2017 at 11:38 AM,  <tturne at codeaurora.org> wrote:
> 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.


The try count should drop on each reset. And then it should swap to
slot B. All of our ARMv8 and x86 boards utilize the same path. Have
you ensured your vbnv bindings are working? And dumping the vbnv
contents to the terminal each time might be helpful. I'm not sure what
platform you are running so it's hard to know what configuration and
support files you are including. Do you have serial console logging
enabled? What's it say?

If you don't have one of these set then you wouldn't be reading any
vbnv -- or saving:

CONFIG_VBOOT_VBNV_CMOS
CONFIG_VBOOT_VBNV_EC
CONFIG_VBOOT_VBNV_FLASH

Check out read_vbnv() and save_vbnv() in src/vboot/vbnv.c.

>
> 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