[coreboot] Understand vboot logic to select FW_B

[tturne at codeaurora.org]

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