[coreboot] Understand vboot logic to select FW_B

[tturne at codeaurora.org]

Once spi-nor flash write issue fixed in driver, ability to select FW_B 
works, as Aaron indicated it should.
Cheers,
T.mike

On 2017-02-15 15:01, tturne at codeaurora.org wrote:
> On 2017-02-15 13:34, Aaron Durbin wrote:
>> On Wed, Feb 15, 2017 at 3:20 PM,  <tturne at codeaurora.org> wrote:
>>> 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.
>> 
>> No. We aren't reliant on that. It would get wiped on program load. If
>> it doesn't that's a bug. The vbnv is supposed to maintain the state
>> and the flow will reload the necessary state.
>> 
> 
> Aaron, thanks for your patience with me here.
> Putting printk statements in init_vbnv(), read_vbnv_flash() and
> save_vbnv_flash() clearly shows the NVRAM section is not being
> updated.
> This is first real test of spi-write functionality so this is likely 
> culprit.
> Our unit-test does a page write that appeared to pass, so we are now
> looking closely at the spi-nor driver.
> Cheers,
> T.mike
> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>> 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