diff options
| author | Vadim Bendebury <vbendeb@chromium.org> | 2019-06-04 18:04:35 -0700 |
|---|---|---|
| committer | Vadim Bendebury <vbendeb@chromium.org> | 2019-09-21 19:11:23 -0700 |
| commit | 4f9526b7b9788450ff32512eb2e1eea00a9a8f24 (patch) | |
| tree | 80af737a6a9560cda0ed7e9e022d4d758b53e060 | |
| parent | 62a7abfe00fbe6e9c6bc7553cc0f94327a1dfaef (diff) | |
| download | chrome-ec-4f9526b7b9788450ff32512eb2e1eea00a9a8f24.tar.gz | |
g: enforce order of enabling RO/RW sections
When a post update reset happens and the host sends the vendor command
to enable the update, in case both RO and RW have been updated, the
Cr50 should enable the RW section first, and then the RO. This would
cover the case when the new RO has the new key and would not be able
to start the old RW, so the matching RW must be available first.
Enabling RW without enabling RO is not a problem, worst thing which
could happen is that the old RO would not start the new RW and the
update process will have to be repeated.
BRANCH=cr50, cr50-mp
BUG=b:74100307
TEST=none yet. Will verify when a new RO is available.
Change-Id: I00175a5a957166d4423fb270bbe9f92d4e408d5c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1644479
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
(cherry picked from commit 11f2760452059e9769c7500984fac6402c565ad1)
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1653656
(cherry picked from commit 01dad69ae8b10b7bce41deca8e4cfe4179d69014)
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1705722
(cherry picked from commit fa1f9fd8a91615be0b51b9145444e9bca9f70040)
| -rw-r--r-- | chip/g/upgrade.c | 22 |
1 files changed, 14 insertions, 8 deletions
diff --git a/chip/g/upgrade.c b/chip/g/upgrade.c index c51faf401e..03c6a0450a 100644 --- a/chip/g/upgrade.c +++ b/chip/g/upgrade.c @@ -63,22 +63,28 @@ static int header_restored(uint32_t offset) /* * Try restoring inactive RO and RW headers, Return the number of restored * headers. + * + * Since the RO could come with new keys, we don't want create a situation + * where the RO is restored and the RW is not (say due to power failure or an + * exception, etc.). So, restore the RW first, and then the RO. In this case + * if restoring failed, the currently running RO is still guaranteed to boot + * and start the currently running RW, so the update could be attempted again. */ static uint8_t headers_restored(void) { uint8_t total_restored; - /* Examine the RO first. */ - if (system_get_ro_image_copy() == SYSTEM_IMAGE_RO) - total_restored = header_restored(CHIP_RO_B_MEM_OFF); + /* Examine the RW first. */ + if (system_get_image_copy() == SYSTEM_IMAGE_RW) + total_restored = header_restored(CONFIG_RW_B_MEM_OFF); else - total_restored = header_restored(CONFIG_RO_MEM_OFF); + total_restored = header_restored(CONFIG_RW_MEM_OFF); - /* Now the RW */ - if (system_get_image_copy() == SYSTEM_IMAGE_RW) - total_restored += header_restored(CONFIG_RW_B_MEM_OFF); + /* Now the RO */ + if (system_get_ro_image_copy() == SYSTEM_IMAGE_RO) + total_restored += header_restored(CHIP_RO_B_MEM_OFF); else - total_restored += header_restored(CONFIG_RW_MEM_OFF); + total_restored += header_restored(CONFIG_RO_MEM_OFF); return total_restored; } |