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