On Wed, Feb 15, 2017 at 3:20 PM, <ttu...@codeaurora.org> wrote: > On 2017-02-15 09:45, Aaron Durbin via coreboot wrote: >> >> On Wed, Feb 15, 2017 at 11:38 AM, <ttu...@codeaurora.org> wrote: >>> >>> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote: >>>> >>>> >>>> On Tue, Feb 14, 2017 at 8:26 PM, <ttu...@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. > > >> >>> >>> 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@coreboot.org >>>>> https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot