[coreboot] Understand vboot logic to select FW_B

[tturne at codeaurora.org]

On 2017-02-15 09:45, Aaron Durbin via coreboot wrote:
> 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.

CONFIG_VBOOT_VBNV_FLASH is set in our system.
I think the key point I was missing before is the vboot reset has to 
retain vboot bss data.
The vbnv_flash variable (static struct vbnv_flash_ctx) has to remain 
initialized across the reboot.

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