Status Update
Comments
bu...@chromium.org <bu...@chromium.org> #2
commit f6780a36ff19b36abcdb5ace903c4ae2272fb574
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Dec 01 22:54:40 2017
firmware: header tweaks for depthcharge
Depthcharge currently includes vboot_nvstorage.h directly, instead of
including only the API header files directly. Add 2nvstorage.h to the
list of headers which can be requested impolitely.
Also fix the definition of ARRAY_SIZE to match exactly what
depthcharge and coreboot provide, so that the compiler does not get
sad when it's included from both libpayload.h and 2common.h.
BUG=chromium:789276
BRANCH=none
TEST=make runtests; emerge-reef depthcharge coreboot
Change-Id: Idc0390eaf813c3079df1676781e8bf5bc9b46450
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Shelley Chen <shchen@chromium.org>
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #3
commit 74f442d830e6be3e91bcd9d57532d9877d65a464
Author: Randall Spangler <rspangler@chromium.org>
Date: Tue Dec 05 01:33:56 2017
vboot: Use 2nvstorage API instead of vboot_nvstorage
We are removing the old vboot_nvstorage API from vboot_reference.
Depthcharge should really not have been including any header files
other than vboot_api.h and vb2_api.h, but for historical reasons it
uses the vboot nvstorage API directly.
Port that code to use the vboot2 (2nvstorage) API.
Don't include the 2nvstorage.h header file directly. Instead, define
NEED_VB20_INTERNALS so that vb2_api.h supplies it. This makes it
easier to refactor vboot, and highlights the places that are peeking
at vboot internals so they're easier to fix later.
BUG=chromium:789276
BRANCH=none
TEST=emerge-reef depthcharge
Build and boot reef firmware.
CQ-DEPEND=CL:802176
Change-Id: Ief51dc7a0a33c403c16e4f75976441a7746a23a6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #4
commit a3d4a78a7c7080b80afdf6432a9bc652dc386a82
Author: Randall Spangler <rspangler@chromium.org>
Date: Thu Dec 07 16:04:38 2017
UPSTREAM: security/vboot: Remove unused include of vboot_nvstorage.h
This include is not needed, and the header file is going away in
vboot_reference. So, remove it.
BUG=chromium:789276
BRANCH=none
TEST=emerge-reef coreboot
Change-Id: I35e7fc7e5e90c755c72d696d36c4490fc1e246b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 8fdbd114ec528ac414b49393f6e856cee4056d87
Original-Change-Id: Ie0b37ae3d2f979f79060a15ca3f7157f49c89785
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Signed-off-by: Randall Spangler <randall@spanglers.com>
Original-Reviewed-on:
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on:
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
[modify]
bu...@chromium.org <bu...@chromium.org> #5
commit 1a094a9ad168d80ad1f4a69d321d758b1e7386cc
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Dec 08 23:12:48 2017
vboot: Use 2nvstorage API instead of vboot_nvstorage
We are removing the old vboot_nvstorage API from vboot_reference.
Depthcharge should really not have been including any header files
other than vboot_api.h and vb2_api.h, but for historical reasons it
uses the vboot nvstorage API directly.
Port that code to use the vboot2 (2nvstorage) API.
Don't include the 2nvstorage.h header file directly. Instead, define
NEED_VB20_INTERNALS so that vb2_api.h supplies it. This makes it
easier to refactor vboot, and highlights the places that are peeking
at vboot internals so they're easier to fix later.
BUG=chromium:789276
BRANCH=none
TEST=emerge-reef depthcharge
Build and boot reef firmware.
CQ-DEPEND=CL:802176
Change-Id: Ief51dc7a0a33c403c16e4f75976441a7746a23a6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
(cherry picked from commit 74f442d830e6be3e91bcd9d57532d9877d65a464)
Reviewed-on:
Commit-Queue: Shelley Chen <shchen@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #6
commit fa82985a2a7bb58894f26eac9bca774e8064e297
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Dec 08 23:19:25 2017
firmware: header tweaks for depthcharge
Depthcharge currently includes vboot_nvstorage.h directly, instead of
including only the API header files directly. Add 2nvstorage.h to the
list of headers which can be requested impolitely.
Also fix the definition of ARRAY_SIZE to match exactly what
depthcharge and coreboot provide, so that the compiler does not get
sad when it's included from both libpayload.h and 2common.h.
BUG=chromium:789276
BRANCH=none
TEST=make runtests; emerge-reef depthcharge coreboot
Change-Id: Idc0390eaf813c3079df1676781e8bf5bc9b46450
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Shelley Chen <shchen@chromium.org>
(cherry picked from commit f6780a36ff19b36abcdb5ace903c4ae2272fb574)
Reviewed-on:
Commit-Queue: Shelley Chen <shchen@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #7
commit cbea37158457f6b9242ed70ff6e7a546ef1414bf
Author: Randall Spangler <rspangler@chromium.org>
Date: Sat Dec 09 00:22:54 2017
UPSTREAM: security/vboot: Remove unused include of vboot_nvstorage.h
This include is not needed, and the header file is going away in
vboot_reference. So, remove it.
BUG=chromium:789276
BRANCH=none
TEST=emerge-reef coreboot
Change-Id: I35e7fc7e5e90c755c72d696d36c4490fc1e246b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 8fdbd114ec528ac414b49393f6e856cee4056d87
Original-Change-Id: Ie0b37ae3d2f979f79060a15ca3f7157f49c89785
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Signed-off-by: Randall Spangler <randall@spanglers.com>
Original-Reviewed-on:
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on:
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on:
Commit-Queue: Shelley Chen <shchen@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
[modify]
bu...@chromium.org <bu...@chromium.org> #8
commit dff5852c2f41c240842b49549b212c36287d5e26
Author: Randall Spangler <rspangler@chromium.org>
Date: Mon Dec 11 23:16:25 2017
vboot: Use 2nvstorage instead of vboot_nvstorage
Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and
use the vboot2 library (vb2_nv_*()) instead. This is needed in
preparation for moving to 64-byte records; no sense in implementing
that change twice...
Should be (better be) no change in system behavior.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
compare output of crossystem before/after change (should be identical)
Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #9
commit 008b1db9e576a38e409fdd3fc7f7f4b513f2bcaf
Author: Randall Spangler <rspangler@chromium.org>
Date: Thu Jan 11 08:12:53 2018
vboot: Use 2nvstorage instead of vboot_nvstorage
Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and
use the vboot2 library (vb2_nv_*()) instead. This is needed in
preparation for moving to 64-byte records; no sense in implementing
that change twice...
Should be (better be) no change in system behavior.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
compare output of crossystem before/after change (should be identical)
Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
(cherry picked from commit dff5852c2f41c240842b49549b212c36287d5e26)
Reviewed-on:
Reviewed-by: Shelley Chen <shchen@chromium.org>
Commit-Queue: Shelley Chen <shchen@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[delete]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #10
commit 4ff95009177da30bb517d702b161be372578a1b7
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Mar 02 03:13:12 2018
fastboot: set NV storage directly instead of VbLockDevice()
All VbLockDevice() does is the equivalent of
vbnv_write(VB2_NV_DISABLE_DEV_REQUEST, 1);
So, do that, rather than requiring another API. Fastboot already uses
vbnv_write() in other places.
This will allow removing the VbLockDevice() API entirely, rather than
needing to rewrite it to support larger NV storage records.
BUG=chromium:789276
BRANCH=none
TEST=none (no firmware in ToT uses fastboot)
Change-Id: I915a7384d9a736574ca2e44649064fb61b8ce638
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
[modify]
bu...@chromium.org <bu...@chromium.org> #11
commit 68ca41067083ee78f5e6b96ba0e2ce9a76cecd3b
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Mar 02 03:13:13 2018
firmware: Remove VbLockDevice()
VbLockDevice() would be inconvenient to port to 64-byte NV storage
records because it doesn't take VbSharedData flags or a vb2_context.
So, just have depthcharge call vbnv_write() directly (as it does in
other places in fastboot.c) and get rid of this API.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:944183
Change-Id: I2aeaecf7f929cd1a1ebd1f6850d0dd96c6fabb49
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #12
commit 7ed54a351e4588819f6e50e2b1290ea6ec7ab5a3
Author: Randall Spangler <rspangler@chromium.org>
Date: Fri Mar 02 23:56:48 2018
fastboot: set NV storage directly instead of VbLockDevice()
All VbLockDevice() does is the equivalent of
vbnv_write(VB2_NV_DISABLE_DEV_REQUEST, 1);
So, do that, rather than requiring another API. Fastboot already uses
vbnv_write() in other places.
This will allow removing the VbLockDevice() API entirely, rather than
needing to rewrite it to support larger NV storage records.
BUG=chromium:789276
BRANCH=none
TEST=none (no firmware in ToT uses fastboot)
Change-Id: I915a7384d9a736574ca2e44649064fb61b8ce638
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on:
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
[modify]
bu...@chromium.org <bu...@chromium.org> #13
commit 8bf997ddfe96c7826dd9607ccf7b5a63a3dfe1ae
Author: Randall Spangler <rspangler@chromium.org>
Date: Sat Mar 03 00:11:04 2018
firmware: Remove VbLockDevice()
VbLockDevice() would be inconvenient to port to 64-byte NV storage
records because it doesn't take VbSharedData flags or a vb2_context.
So, just have depthcharge call vbnv_write() directly (as it does in
other places in fastboot.c) and get rid of this API.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:944183
Change-Id: I2aeaecf7f929cd1a1ebd1f6850d0dd96c6fabb49
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 68ca41067083ee78f5e6b96ba0e2ce9a76cecd3b)
Reviewed-on:
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #14
commit a80a79f9f5ca0250eb31330d9dfdacf3a250efb0
Author: Randall Spangler <rspangler@chromium.org>
Date: Thu Mar 08 00:55:15 2018
2lib: Add support for 64-byte nvstorage record
The calling firmware can set ctx->flags VB2_CONTEXT_NVDATA_V2 to tell
vboot that nvdata is a 64-byte record instead of a 16-byte record, or
equivalently, set the VBSD_NVDATA_V2 flag if calling the old vboot1
API.
If calling firmware does not (which is the current coreboot and
depthcharge default), then the 16-byte record is used, and V2 fields
return explicit default values.
Added the fw_max_rollforward V2 field, which defaults to 0xfffffffe on
V1. This will be used by a subsequent CL.
Added unit tests to verify all that.
Added crossystem support, though it will only work with the current
16-byte records until firmware sets the VBSD flag and mosys supports
larger records.
(Note that because coreboot/depthcharge do not yet set the new context
flag, this CL should not change ToT firmware behavior.)
See go/vboot-nvstorage for design doc.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
Change-Id: I43072ef153dfa016c051f560892af1fbb3508e3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
[modify]
bu...@chromium.org <bu...@chromium.org> #15
commit 0bdb8713be40abfe963d9ef625dbb67961068840
Author: Randall Spangler <rspangler@chromium.org>
Date: Thu Mar 08 19:33:26 2018
crossystem: Fix null pointer dereference on VMs
Check the result of VbSharedDataRead() before dereferencing it.
BUG=chromium:789276,chromium:819695
BRANCH=none
TEST=make runtests
Change-Id: I1b1cc90bdc2fca61a9aad6b02e8b7e1f6a919797
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on:
Commit-Ready: Keith Haddow <haddowk@chromium.org>
Reviewed-by: Keith Haddow <haddowk@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
[modify]
re...@google.com <re...@google.com>
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #16
commit b10e5e32cc34dba7660b070616d3481742a28e70
Author: Yu-Ping Wu <yupingso@chromium.org>
Date: Fri Dec 13 05:42:38 2019
vboot: Make 2nvstorage.h private to vboot_reference
Since 2nvstorage.h is no longer used in both coreboot and depthcharge
(CL:1957766), remove the include of it from vb2_api.h.
BRANCH=none
BUG=chromium:789276
TEST=1. emerge-nami vboot_reference coreboot depthcharge
2. FEATURES=test emerge-nami vboot_reference
Cq-Depend: chromium:1957766
Change-Id: I53ad0967abd440167547bcbf710c49787d011e15
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on:
Reviewed-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
[modify]
ki...@google.com <ki...@google.com> #17
coreboot
====
We need to introduce a config option to coreboot to choose between 16/64-bit nvdata space. coreboot's vbnv_layout.h should then use that value to define its VB2_NVDATA_SIZE constant. Any devices for which we want to add 64-bit support need to make sure there is enough space in FMAP layout (for flash-based storage), or in CMOS.
depthcharge
====
depthcharge's drivers would also need to be modified to support 64-bit spaces. Specifically, the flash-based storage has a hard-coded 16-bit size. It could detect the size using vboot's context flag, which will be passed down from coreboot via persistent context. The CMOS driver looks like it would work out-of-the-box, since the size is passed down through lbtable.
ad...@google.com <ad...@google.com> #18
dl...@google.com <dl...@google.com> #19
ki...@google.com <ki...@google.com> #20
dl...@google.com <dl...@google.com> #21
However when we first made the transition to storing NV in flash on x86 it was handled in coreboot by syncing the CMOS to flash. (and restoring from flash if CMOS was corrupt) Later mosys was changed to write to flash directly as well, for another issue where a flag needed to take effect immediately without a reboot to sync it to flash. (IIRC this affected a factory use case)
So I think we actually have all the groundwork laid to just remove the CMOS part and rely on flash directly like ARM does and make everything consistent. I think the work required would be:
- changes in coreboot to remove this CMOS<>flash backup/restore
- remove the CMOS interface from mosys and change it to read/write from flash by default (I think it writes, but reads from cmos to be faster)
ki...@google.com <ki...@google.com> #22
Here's a document outlining the proposed changes:
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #23
commit 1978c84e51cc8eb99f55167c6b5b6cc85439f832
Author: Jack Rosenthal <jrosenth@chromium.org>
Date: Tue Jun 09 16:30:56 2020
host/lib: add lightweight flashrom wrapper library
Lightweight wrapper around flashrom, exposing two APIs:
flashrom_read(programmer, region, data_out, size_out)
flashrom_write(programmer, region, data, size)
|region| can be NULL, in which case operate on the whole flash chip.
The intended usage of this wrapper library is to read/write VBNV from
SPI flash directly, avoiding the call thru mosys (which has deprecated
the command). Bringing this logic into crossystem directly will also
help with expanding VBNV to 64-bytes.
BUG=chromium:1032351,chromium:1030473,chromium:789276
BRANCH=none
TEST=provided unit tests
Change-Id: I3997bd03a2db7e58e4e76fc200c637dd3b5b20a4
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-on:
[add]
[add]
[modify]
[modify]
[add]
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #24
commit c95ea3f2cb7b9aaf64d8b2d7ede13783191e0b73
Author: Jack Rosenthal <jrosenth@chromium.org>
Date: Tue Jun 09 16:30:57 2020
crossystem: add functions to read and write VBNV via flashrom
This will replace the usage of "mosys nvram vboot {read,write}" on x86
platforms, and all ARM platforms except veyron (chromebooks only) and
nyan_kitty (which use VBNV storage in the ChromeOS EC, deprecated for
new platforms). These affected ARM devices will be going AUE sometime
this summer, and we can expect to remove the mosys usage in crossystem
later this year.
The code to find the active VBNV in SPI flash was modeled to match the
logic in mosys (see mosys/lib/vbnv/vbnv_flash.c).
BUG=chromium:1032351,chromium:1030473,chromium:789276
BRANCH=none
TEST=provided unit tests
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I4f42af2f9a6b0703302635f8d8ebb2d7599d9847
Reviewed-on:
[modify]
[modify]
[modify]
[add]
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #25
commit 15651696684fce77f2e978c03342f3fe80fc546b
Author: Jack Rosenthal <jrosenth@chromium.org>
Date: Tue Jun 09 16:30:58 2020
crossystem: x86: switch to VBNV backup using flashrom instead of mosys
Previously, x86 platforms with vboot2 will backup VBNV in SPI flash
using mosys, which will in turn execute flashrom to preform the
underlying operation.
The set of parent CLs to this commit port this functionality from
mosys directly to vboot's host libraries. This CL switches to use the
new functionality.
(The CL to switch is provided as a separate CL for x86 only so it's an
easy and clean revert should something go wrong.)
BUG=chromium:1032351,chromium:1030473,chromium:789276
BRANCH=none
TEST=On octupus, write VBNV using crossystem and manually inspect
RW_NVRAM region in SPI flash.
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I9f945dca99ebd394abea1490fa25d3763834bfa1
Reviewed-on:
Reviewed-by: Joel Kitching <kitching@chromium.org>
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #26
commit 9a923c7dba003a5ddbc55937469c975689effa62
Author: Jack Rosenthal <jrosenth@chromium.org>
Date: Tue Jun 09 16:31:00 2020
crossystem: arm: switch to VBNV using flashrom from mosys
Most ARM platforms will store VBNV in SPI flash by calling out to
mosys, which in turn calls out to flashrom.
The set of parent CLs to this commit port this functionality from
mosys directly to vboot's host libraries. This CL switches to use the
new functionality.
(The CL to switch is provided as a separate CL for ARM only so it's an
easy and clean revert should something go wrong.)
BUG=chromium:1032351,chromium:1030473,chromium:789276
BRANCH=none
TEST=On scarlet, read and write VBNV using crossystem
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I1949522b665170ebeb35f3c46177f1957980d6a3
Reviewed-on:
Reviewed-by: Joel Kitching <kitching@chromium.org>
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #27
commit 5cd75be8d1e908adbf73edf04c903539864efab0
Author: Shik Chen <shik@chromium.org>
Date: Wed Jun 10 10:27:16 2020
Revert "crossystem: arm: switch to VBNV using flashrom from mosys"
This reverts commit 9a923c7dba003a5ddbc55937469c975689effa62.
Reason for revert:
Original change's description:
Bug: chromium:1032351, chromium:1030473, chromium:789276
Change-Id: I3ccb6c6653e24e61072ee9227e870a2f211cd114
Reviewed-on:
Reviewed-by: Shik Chen <shik@chromium.org>
Commit-Queue: Shik Chen <shik@chromium.org>
Commit-Queue: Stimim Chen <stimim@chromium.org>
Tested-by: Stimim Chen <stimim@chromium.org>
[modify]
bu...@chops-service-accounts.iam.gserviceaccount.com <bu...@chops-service-accounts.iam.gserviceaccount.com> #28
commit f20a27dafac8852d919392f8fba95fb0b220ee48
Author: Jack Rosenthal <jrosenth@chromium.org>
Date: Thu Jun 18 19:30:47 2020
crossystem: arm: reland nvstorage using flashrom
This relands CL:2218891, which was reverted as the "mkbp" case was
forgotten, and lit all sorts of stuff on fire when the CQ skipped
hardware tests and the lab was accidentally soaked in gasoline.
The devices which this affected are re-enabled in the lab, the CQ is
now configured to enable hardware tests, so let's land it again ;)
BUG=chromium:1032351,chromium:1030473,chromium:789276
BRANCH=none
TEST=On scarlet and nyan_kitty, read and write using crossystem
Change-Id: Ife4d17eeca484a2784f7e2b2f7c22fef27b9d083
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-on:
Reviewed-by: Joel Kitching <kitching@chromium.org>
[modify]
sc...@google.com <sc...@google.com>
ki...@google.com <ki...@google.com>
jr...@google.com <jr...@google.com>
yu...@google.com <yu...@google.com> #29
Jack, are you still working on this?
Julius, Looking at the design doc, I'm not sure how to deprecate CMOS in coreboot for platforms without RW_NVRAM
.
Alternatively, can we leave VBOOT_VBNV_CMOS
in coreboot for now? Then, all we need to do is to add a new Kconfig option NVDATA_V2
(or NVDATA_V1
), and set VB2_CONTEXT_NVDATA_V2
in coreboot for boards with NVDATA_V2
set.
jr...@google.com <jr...@google.com> #30
Jack, are you still working on this?
At the moment, not actively. If you're interested in taking over, please do!
jw...@google.com <jw...@google.com> #31
You would need to add an RW_NVRAM section to all boards that switch from CMOS to flash nvdata, obviously. Hopefully you can find enough free space in each board. x86 boards tend to have very big flash sizes, so 4K shouldn't be too hard to fit in somewhere.
Moving from CMOS to flash and expanding to 64 bytes aren't directly related, but this seems like a good opportunity to do it because then you don't need to figure out how CMOS works and whether there'd be enough space for the expansion in there. Getting away from CMOS would mean that our nvdata is no longer battery-dependent and we would only need to maintain one nvdata backend going forward, so it's something we've kinda wanted to do for a while.
yu...@google.com <yu...@google.com> #32
You would need to add an RW_NVRAM section to all boards that switch from CMOS to flash nvdata, obviously.
Okay, I'm going to give it a try.
yu...@google.com <yu...@google.com>
bu...@google.com <bu...@google.com> #33
Bugjuggler:
Description
Currently, vboot non-volatile storage uses a 16-byte record. This was as much CMOS as we could get back in 2009 on the first Chromebook.
We're now out of space in that record, so we need to increase the size. Might as well go up to 64 bytes, to give us some room for future features as well.
Firmware will support either 16-byte (current/old) or 64-byte (new ToT) records. No need to dynamically determine record size.
Crossystem, mosys, and anyone else directly mucking with the records from the OS will need to support both old and new record sizes. Firmware will provide a flag to the OS to indicate if 64-byte records should be used (default=no, for backwards-compatibility).