On 2017-02-15 13:34, Aaron Durbin wrote:
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.
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
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
