diff options
author | Duncan Laurie <dlaurie@chromium.org> | 2016-02-19 20:20:10 -0800 |
---|---|---|
committer | chrome-bot <chrome-bot@chromium.org> | 2016-02-23 16:58:50 -0800 |
commit | d187cd3fc792f8bcefbee4587c83eafbd08441fc (patch) | |
tree | d6131fce72fb414346dec9f34b3249e1007dd82d | |
parent | 478b6d34afb9fd98daf0663dd6093d8f058a9f34 (diff) | |
download | vboot-d187cd3fc792f8bcefbee4587c83eafbd08441fc.tar.gz |
vb2: Modify phase2 behavior for S3 resume casestabilize-7978.Bstabilize-7978.74.Bstabilize-7978.66.Bstabilize-7978.51.Bstabilize-7978.18.Bstabilize-7956.Brelease-R50-7978.B
If a platform does verification of memory init then it must be careful
to use the same slot for resume that it booted from. This is
accomplished by adding a context flag to indicate this is an S3 resume
and that vboot should treat it differently than a normal boot.
When this flag is set then the same slot that was booted is read from
VBNV and re-used for the resume path, without adjusting any try flags.
If this slot is B then the related context flag is set.
This will allow the firmware updater to update the other (non-booted)
slot and set flags indicating that on the next boot the updated slot
should be tried, while still allowing suspend/resume to work with the
existing firmware slot.
This assumes that the last tried slot was successfully booted, which
should be a safe assumption since the system was able to boot and then
suspend. It isn't reliable to check last_fw_result for "success"
status because that status is only set some time after boot when
chromeos-setgoodkernel calls chromeos-firmwareupdate --mode=bootok
and so it may still report a status of "trying" on resume depending
on how soon after boot the suspend happened.
It also avoids setting the vboot flag indicating that a slot choice
was made in order to avoid altering the try counter on failure since
this is explicitly not attempting to boot the new slot.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I500faef2b5d19a02f32839976354abf6d551c9f6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
-rw-r--r-- | firmware/2lib/2api.c | 18 | ||||
-rw-r--r-- | firmware/2lib/include/2api.h | 3 |
2 files changed, 21 insertions, 0 deletions
diff --git a/firmware/2lib/2api.c b/firmware/2lib/2api.c index 7f12d22c..059cb6c2 100644 --- a/firmware/2lib/2api.c +++ b/firmware/2lib/2api.c @@ -111,6 +111,24 @@ int vb2api_fw_phase2(struct vb2_context *ctx) { int rv; + /* + * Use the slot from the last boot if this is a resume. Do not set + * VB2_SD_STATUS_CHOSE_SLOT so the try counter is not decremented on + * failure as we are explicitly not attempting to boot from a new slot. + */ + if (ctx->flags & VB2_CONTEXT_S3_RESUME) { + struct vb2_shared_data *sd = vb2_get_sd(ctx); + + /* Set the current slot to the last booted slot */ + sd->fw_slot = vb2_nv_get(ctx, VB2_NV_FW_TRIED); + + /* Set context flag if we're using slot B */ + if (sd->fw_slot) + ctx->flags |= VB2_CONTEXT_FW_SLOT_B; + + return VB2_SUCCESS; + } + /* Always clear RAM when entering developer mode */ if (ctx->flags & VB2_CONTEXT_DEVELOPER_MODE) ctx->flags |= VB2_CONTEXT_CLEAR_RAM; diff --git a/firmware/2lib/include/2api.h b/firmware/2lib/include/2api.h index bf8f6393..709db48b 100644 --- a/firmware/2lib/include/2api.h +++ b/firmware/2lib/include/2api.h @@ -129,6 +129,9 @@ enum vb2_context_flags { * unrecoverable crash loop. */ VB2_CONTEXT_SECDATA_WANTS_REBOOT = (1 << 13), + + /* Boot is S3->S0 resume, not S5->S0 normal boot */ + VB2_CONTEXT_S3_RESUME = (1 << 14), }; /* |