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