This flag will be used by the firmware updater to indicate that RO
software sync should be attempted.
BUG=chrome-os-partner:48703
BRANCH=None
TEST=make runtests
Change-Id: I42090ac47da45c724e66334648ab447ad3c21178
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/320621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a new post-EC software sync API VbExEcVbootDone() to take actions
which normally need to happen after EC verification / sysjump.
BUG=chromium:537269
TEST=Manual on Glados. Set CHG_MW thresh to 20000, BAT_PCT to 50. Verify
that LIMIT_POWER host event is set until Zinger negotiates to 20V. Also
verify that we do not proceed with boot when Donette is plugged.
BRANCH=None
CQ-DEPEND=CL:307885,CL:309523
Change-Id: I77e6000aa8a44e3aca4fb5982e5b5f5191774989
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307952
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
VbExGetLocalizationCount is a callback function which is supposed to
return the number of screen locales supported by VbExDisplayScreen.
After this change, we still try to get the number of locales from GBB
first but when it fails, VbExGetLocalizationCount is called. The error
code from VbGbbReadBmpHeader will be masked, similarly to the error from
VbDislayScreenFromGBB.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests
Change-Id: I04ef8bf1ea02b1aaa05e65673b57bcea1932d8b0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304376
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change makes VbDisplayScreen read the last saved locale from nvram
and pass it to VbExDisplayScreen so that it can draw locale dependent
screens.
BUG=chromium:502066
BRANCH=tot
TEST=Tested on Samus. make runtests.
CQ-DEPEND=CL:304382,CL:306100,CL:306110
Change-Id: I9782ec5a8a9f8393998aa8a0d64e88ad1809233b
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304375
In developer mode, this option will make the system try to boot into
a legacy OS first after the 30 second timeout. This removes the need to
press a key during boot to try legacy mode and the need to remove the
write protect screw to boot legacy as default.
BUG=chromium:310697
BRANCH=none
TEST=make runtests
Change-Id: I9a9f64c14ad015e21d08eec36e8fc187189cd2f2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the new recovery process, a user will see 'broken' screen
instead of 'remove' screen, where usb stick presence is no longer
detected. A user instead has to hit esc+refresh+power to proceed
to recovery mode.
BUG=chromium:501060
BRANCH=tot
TEST=make runtests
Change-Id: Icd511c1ca892628b96befbb0a34c2c84b881c857
Reviewed-on: https://chromium-review.googlesource.com/304404
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When a TPM goes from the disabled state to the enabled state, it must
reboot after being enabled, before it can be initialized. In vboot1,
TLCL was part of vboot and this was handled internally. In vboot2, the
caller must set a context flag, so that vboot can decide whether to
allow the reboot, or whether to go directly to recovery mode. This
check is necessary to handle the following cases:
1) The device is booting normally, but the TPM needs a reboot. This
should simply reboot, without going to recovery mode.
2) The device is booting in recovery mode, but the TPM needs a reboot.
If this is the first time it asked us, allow the reboot.
3) The TPM asked for a reboot last time, so we did. And it's still
asking. Don't reboot, because that runs the risk that whatever is wrong
won't be fixed next boot either, and we'll get stuck in a reboot loop
that will prevent recovery. Boot into recovery mode.
Add a new NvStorage bit to track whether the TPM requested a reboot on
the previous boot. That's better than what we did in vboot1, where we
used a special recovery request. Vboot1 couldn't track getting stuck in
a reboot loop in normal mode, only in recovery mode. The new code can
catch both.
BUG=chrome-os-partner:45462
BRANCH=ryu
TEST=make runtests
Change-Id: I2ee54af107275ccf64a6cb41132b7a0fc02bb983
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300572
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
1. Change offset 8 to hold all misc settings (fastboot, boot_on_ac
detect) instead of only fastboot settings.
2. Add flag to hold state of boot_on_ac_detect (If set to 1, AP should
start booting as soon as AC is connected in off-state).
BUG=chrome-os-partner:41680
BRANCH=None
TEST=Compiles successfully. make runtests successful.
Change-Id: I64b3fc69bd52cbcaf5899c953ccafa2e81b5b8a5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/289900
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
When one of GPT headers is invalid the corresponding partition table
is not loaded and corresponding pointers in GptData are NULL.
GptRepair will try to memcpy one entries table to another which
results in SIGSEGV.
This change fixes it by freeing and then reallocating bad copy of
partition table. This potentially fixes problems which would occur
if two tables have different size.
Change that initially introduced this problem by not always allocating
secondary_entries:
https://chromium-review.googlesource.com/223800
TEST="cgpt repair" works where it previously didn't
TEST=make runtests
BUG=brillo:1203
BRANCH=none
Change-Id: Ibb2fcf33faa5ba157b0865d04c90ee3f26eee113
Reviewed-on: https://chromium-review.googlesource.com/276766
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Andrey Ulanov <andreyu@google.com>
Tested-by: Andrey Ulanov <andreyu@google.com>
When linking vboot_api_kernel4_tests, there are two VbBootNormal()
available, the gcc chooses the one in vboot_api_kernel4_tests.c and
the test passes, the clang chooses the one in vboot_api_kernel.c and
make the unittest fail. This CL makes the one in vboot_api_kernel.c
a weak symbol so that clang can choose the one in
vboot_api_kernel4_tests.c
BUG=chromium:498469
BRANCH=none
TEST=CC=x86_64-cros-linux-gnu-clang FEATURES='test'
emerge-amd64-generic vboot_reference
Change-Id: Ibcb78ee055fc9485dbc2bcc1d1cf98144a1a3b64
Reviewed-on: https://chromium-review.googlesource.com/276504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
This can be used by implementations that want to request vboot to
favor a particular kernel entry for booting without affecting the
checks for rollback protection and image verification.
CQ-DEPEND=CL:274716, CL:274932, CL:275171
BUG=None
BRANCH=None
TEST=Compiles successfully. make -j runtests successful.
Change-Id: I6a4600020354f5d4118c17f083c353c2585c4181
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/274558
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Trybot-Ready: Nicolas Boichat <drinkcat@chromium.org>
Add support for functions to request unlock and lock of devices in
response to fastboot oem unlock/lock commands. Unlock operation is
equivalent to enabling dev mode and lock operation is equivalent to
leaving dev mode. It is the responsibility of the caller to ensure
that user confirmation is obtained before unlock/lock operations.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully and fastboot lock/unlock operations work as
expected on smaug. Added tests to ensure lock/unlock operations are
covered. Verified using make -j runtests.
Change-Id: Ibafe75abdd1202473009208a414f3996d537db4f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/273182
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
When the lid is closed and external power is applied
the system may boot and shut down faster than required
for the OS to determine that things were alright.
In timed charging setups this led to systems ending up
to consider the current version broken because it "failed"
repeatedly.
Remain generic about the reason for not counting boots
since there may be more situations in which we want to
handle the situation optimistically.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Iea350e3c98d5c00156da682e52c90a882ba017c0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249150
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This API allows fastboot boot from memory command to verify that the
image loaded in memory is signed properly using recovery keys. Thus,
only officially signed recovery images can be booted using fastboot
boot command in recovery mode.
However, if GBB_FLAG_FORCE_DEV_BOOT_FASTBOOT_FULL_CAP is set, then
this routine will not perform any check and return okay for any image
sent by fastboot boot.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully. With GBB override for FASTBOOT_FULL_CAP
set any signed image is allowed to boot. With FASTBOOT_FULL_CAP not
set, then only officially signed image is allowed to boot. (make -j
runtests successful)
Change-Id: I78028853bd1ad09d3c610a687f327560557d5681
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/272696
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Add a new flag to nvstorage for controlling fastboot capabilities
offered in firmware in dev-mode. By default, value of this flag would
be ignored in normal mode. Thus, when fastboot-based recovery is
entered from normal mode, only limited capability would be available
in firmware.
After switching to dev-mode, this flag can be set automatically by
user script after performing the wipe or it can be set manually using
crossystem. When fastboot-based recovery is entered from dev mode and
this flag is set, it will provide full fastboot capability in the
firmware.
BUG=chrome-os-partner:40196
BRANCH=None
TEST=Compiles successfully for smaug. make runalltests successful.
Change-Id: I761a9ab304dd90f0b73081acc9ce1f8d9052325f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/271369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
And add a vb2_digest_buffer() call which produces the hash of a buffer
all in a single function call. That function actually already
existed, but was in a unit test file rather than in the library
itself. It's a small function, so adding it won't increase the size
of the library significantly - or at all, on platforms which compile
with -ffunction-sections.
This allows coreboot to reuse this SHA library for hashing CBFS
entries and file data. All it has to do is #define
NEED_VB2_SHA_LIBRARY and then #include "vb2_api.h".
BUG=chromium:482652
BRANCH=none
TEST=make -j runtests
Change-Id: Ice2d0929324b58b2665f3989b5b887225f6ef61e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269523
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is done to break a circular DEPENDency as we want to
send UMA stats from tcsd. Without this, metrics depends on
vboot_reference which depends on trousers which depends on
metrics. Technically the vboot_reference dependency on trousers
is header-file only, but we can't cope with that.
BUG=chromium:481552
TEST=compiled with emerge-<something> vboot_reference
BRANCH=none
Change-Id: Iea5c0c39bb70977c9d375e63ea607687debe9f9f
Reviewed-on: https://chromium-review.googlesource.com/267744
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Some Chrome OS devices do not allow to login even in developer mode,
as they do not have display/keyboard and sshd is not part of the
Chrome OS image. Even enabling developer mode on those devices is very
involved (requires taking the device apart and is guaranteed to take
long time).
We still want to allow the end user to control those devices in dev
mode. The solution is enabling the ability to boot from the USB stick
when the device transitions from normal to developer mode.
A simple way to do it is to set the NVRAM flag, which allows USB boot.
The flag is set on normal=>dev transition only, and only on those
devices where it is configured (as discovered by invoking
VbExGetSwitches with the appropriate parameters).
BRANCH=storm
BUG=chrome-os-partner:38303
TEST=tested with the corresponding depthcharge patches
Change-Id: I5fa58963256598cde3b534f5250101fba6042f8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264187
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request. The best mechanism for this is NVRAM, as the
request needs to be detected very early in the boot process, before
other means of communications with the upper layers are available.
A previously unused NVRAM bit (bit 0x08 at offset zero) is taken for
this purpose.
A new flag is introduced to allow the firmware to signal the need to
assert this bit.
A new variable name/parameter ('wipeout_request') added to crossystem
to provide user space access to the setting of the dedicated NVRAM
bit.
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: If1f6f061ce5b3f357b92aaa74cb129671dc30446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259857
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Kernel preamble flags are set by the signer for passing hints about
the image. Read these flags from the preamble and pass it back to the
caller in kparams structure.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles and boots to kernel prompt for both CrOS image and bootimg.
Change-Id: I07a8b974dcf3ab5cd93d26a752c989d268c8da99
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245951
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
1. Increase kernel preamble revision from 2.1 to 2.2.
2. Add flags field to kernel preamble.
3. Update futility to accept flags parameter for vbutil_kernel and
cmd_sign for kernel.
4. Pass in an extra flags field to SignKernelBlob and
CreateKernelPreamble.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=1) "make runalltests" completes successfully. 2) vboot_reference
compiles successfully for ryu. 3) Verified flags field in header using
futility show.
Change-Id: If9f06f98778a7339194c77090cbef4807d5e34e2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/245950
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
vboot2 added a few new recovery reasons (and abolished many old ones).
In the current vboot2/vboot1 hybrid architecture used on Veyron, the
vboot1 kernel verification part controls the status display when
pressing the TAB key, which may try to show recovery reasons set by the
vboot2 firmware verification part. These currently result in the not
very helpful "We have no idea what this means", so lets hack a few more
strings into vboot1 which will be otherwise harmless. Also add the
recovery_subcode field to the display, which is used much more
extensively by vboot2 and often very useful in firguring out what really
went wrong.
BRANCH=veyron
BUG=None
TEST=Manually set a few recovery reasons and subcodes through crossystem
and made sure they get displayed correctly on my Jerry.
Change-Id: I3f3e6c6ae6e7981337841c0c5e3cd767628472c3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248391
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The length of the signature is 8 bytes. We've been checking 9
bytes instead, pretty much forever. All the tests have passed
because although the signature we're looking for is an 8-byte
string followed by a '\0', the next field in the header contains
the revision number 0x00010000, so the 9th byte is always zero.
We should follow the spec, though.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I7cc6370250fa36a193f4a9fa5bc0099aea465618
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Following changes are done to the cgptlib API in order to allow backend
component of fastboot to perform erase and write operations on
partitions and manipulate GPT entries:
GptFindNthEntry - Returns the nth entry in GPT that matches provided
GUID.
GptGetEntrySizeLba - Returns size of a partition in lba.
GptGetEntrySizeBytes - Returns size of a partition in bytes.
GptUpdateKernelWithEntry - Given kernel entry is updated using the
provided update_type. GptUpdateKernelEntry calls this function with
entry for current_kernel.
Add flags GPT_UPDATE_ENTRY_RESET and GPT_UPDATE_ENTRY_INVALID for
calls to GptUpdateKernelEntry. These operations are used by write
image and erase partition respectively.
BUG=chrome-os-partner:35861
BRANCH=None
TEST=Compiles successfully and all the newly added functions work as expected.
Change-Id: I82c87e4c97de2d207e80209dbd4922b4bcd5880a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/240268
Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Adding functionality to allow for rebuilding of vmlinuz after it
has been processed into vblock and header stripped. Basically appends
the 16-bit header of a vmlinuz image onto the end of the vblock.
BUG=chromium:438302
BRANCH=none
TEST=Successfully ran "make runalltests".
Also, ran:
1. Repack kernel block (so that 16-bit header is included):
"vbutil_kernel --pack kern_0 ..."
2. Verify kernel: "vbutil_kernel --verify kern_0 ... ". This should
be done before booting into kernel, but not necessary for it to work.
3. Rebuild vmlinuz image:
"vbutil_kernel --get-vmlinuz kern_0 --vmlinuz-out vm.out"
4. Set up kexec with vmlinuz (this should complete with no errors):
"kexec -l vm.out (other kernel cmd line args)"
5. Boot into kernel:
"kexec -e"
Change-Id: Iaa1582a1aedf70b43cdb3a56cde1fb248f1793d4
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232750
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And include it in vb2_api.h if VB20 internals are needed.
This allows coreboot to get at the fields more cleanly for now, rather
than duplicating the field definitions. In the long run, we should
have APIs for this rather than having coreboot peek at the bits
directly.
BUG=none
BRANCH=none
TEST=emerge-veyron_pinky coreboot && make -j runtests
Change-Id: Ic308c3470773b91191bf682ff1b3cfce8864d26a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240285
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch makes some small modifications to cgpt and vboot to
root out the last vestigates of a fixed 128-entry GPT:
- Get rid of the TOTAL_ENTRIES_SIZE constant and all users.
- Reduce MAX_NUMBER_OF_ENTRIES to 128 (which is what the GPT
spec specifies) so that this can be used for things like memory
allocations without additional overhead.
- Base the amount of GPT read/written on the number of entries
specified in the GPT header on disk/flash.
BUG=chromium:433433
TEST=make runalltests
TEST=Modified fmap to make an 8k RW_GPT, wrote a GPT with cgpt, then
rebooted and found that the GPT was correctly read after restarting
and the appropriate mtd partitions were present.
BRANCH=none
Change-Id: I45317377da20259caf04a7a4fa077a892b03c45f
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238245
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Handle GBB_FLAG_DISABLE_LID_SHUTDOWN to disable lid-triggered system
shutdown.
BUG=chromium:434462
BRANCH=Auron
TEST=Manual on Auron, with corresponding depthcharge change. Set GBB
flag 0x1000 and disable powerd launch on boot. Close lid and issue
'reboot' command over ssh. Verify system reboots successfully into OS.
Change-Id: Id2731508296a5ba9229f969f8224565d64f3d4a3
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234995
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch reinstates the external GPT support which was previously
committed and reverted. Improvements since last time include:
- Cleaned-up internal interface based on code review
- Function correctly on legacy bootloaders (e.g., depthcharge before
NAND-related patches are added)
- Better comments
- Treat new field values = 0 -> not use new feature
- Tests are added to ensure external GPT flag is passed down properly
The original commit had change-id
I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Its commit message is reproduced below, and then an additional test.
----
To support an external GPT, disks have two new attributes:
- A binary flag indicating whether the GPT is in the same address
space as the payloads or a separate one.
- The number of sectors of the streaming portion of storage, as
opposed to the portion containing the GPT.
These have been added elsewhere to GptData (in cgptlib) and BlockDev
(in depthcharge). This patch adds the plumbing between those, including
in the DiskInfo interface between the firmware and vboot.
BUG=chromium:425677
BRANCH=none
TEST=Interactively wrote the GPT with cgpt and observed the following
boot with depthcharge to read the GPT from SPI and then read from
the proper locations in NAND flash.
TEST=make runalltests passes.
TEST=boots from USB with depthcharge from HEAD.
Change-Id: Ia7956517a7b9da0301f01fac5a10204f6d78cf4f
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234640
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Over in depthcharge, IsEntryUnused will be useful for presenting the
partition table to the kernel. This patch moves that function to
gpt_misc.[ch] for export to depthcharge.
TEST=Booted a kernel on NAND with all this compiled in
TEST=make runtests passed
BRANCH=none
BUG=none
Signed-off-by: Dan Ehrenberg <dehrenberg@google.com>
Change-Id: I56445d1a420fec4d8385ddffc5469b7d77eab576
Reviewed-on: https://chromium-review.googlesource.com/231455
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
- Rename drive_sectors to streaming_drive_sectors, to contrast with
gpt_drive_sectors
- Replace stored_on_device field with flags field for future
extensibility
BUG=chromium:433433
TEST=make runtests
BRANCH=none
Change-Id: I785a3b735b8eb96f647a334659329db3ee43eb80
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234283
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is part 4 of a series of changes to rearrange the vboot2 library
so that it's possible to start using the new-style data structs. This
change moves knowledge of the old vboot1 data structs into lib20; 2lib
now contains only code which is common to both vboot2.x libraries
(that is, code which is data structure version agnostic).
No functional changes; just rearranging code and tests.
BUG=chromium:423882
BRANCH=none
TEST=make runtests && VBOOT2=1 make runtests (works with/withoug VBOOT2 flag)
And compile firmware for veyron_pinky
CQ-DEPEND=CL:233051
Change-Id: I8f9e67157575e5be14952ef4809c3dfafd92596d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233021
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is what other firmware should include. Other firmware must NOT
attempt to include headers from deeper inside the vboot2
implementation; that will likely break as vboot2 is refactored.
BUG=chromium:423882
BRANCH=none
TEST=VBOOT2=1 make runtests
Change-Id: I63638b03bb108296fa5069e7cc32ee9e25183846
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233050
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This commit adds a new VbInit() flag which will indicate that it is
being called before option roms are loaded and can therefore respond
to the VbNv flag without needing an immediate reboot.
When the BIOS calls VbInit() in firmware it may not yet know if the
system is in developer mode if there is a virtual developer mode
switch, instead it relies on the VbNv flag that is prepared by VbInit().
So this new flag only affects VbInit() checks itself, the later checks
still do the right thing because OPROM_LOADED can be set based on the
VbNv value that is set by VbInit().
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=pass FAFT tests on samus
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7a12f3d318a04ff43ac1ddfc0ba8baa112253bad
Reviewed-on: https://chromium-review.googlesource.com/230885
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a GBB flag which can be used in VbExShutdownRequested
to ignore the state of the lid switch and enable factory to run
with the lid closed.
BUG=chromium:434462
BRANCH=samus
TEST=none in this commit, just adding a new unused flag
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ife93adcc90b2c48e79d4e0c8164d2e64e6326ca7
Reviewed-on: https://chromium-review.googlesource.com/230884
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This reverts commit 5040a945df.
This patch breaks booting any image (both fixed and
removable) on Veyron_Pinky (and presumably every other
non-NAND board?). By the power vested in me through the
office of ChromeOS tree sheriff (well, five hours early
but whatever) it is hereby reverted!
BUG=chromium:425677
BRANCH=none
TEST=Can successfully boot on Veyron_Pinky again.
Change-Id: I9323a3d5e34491337fc7eb09dd00d845ac42997d
Reviewed-on: https://chromium-review.googlesource.com/229963
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
To support an external GPT, disks have two new attributes:
- A binary flag indicating whether the GPT is in the same address
space as the payloads or a separate one.
- The number of sectors of the streaming portion of storage, as
opposed to the portion containing the GPT.
These have been added elsewhere to GptData (in cgptlib) and BlockDev
(in depthcharge). This patch adds the plumbing between those, including
in the DiskInfo interface between the firmware and vboot.
BUG=chromium:425677
BRANCH=none
TEST=Interactively wrote the GPT with cgpt and observed the following
boot with depthcharge to read the GPT from SPI and then read from
the proper locations in NAND flash.
make runalltests passes.
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I5a77e417aea8ee9442d18c200d1b073aa5375ecf
Reviewed-on: https://chromium-review.googlesource.com/228943
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This CL allows the GPT headers and partition entry arrays to be stored
in a NOR flash device. Instead of treating both the NOR and NAND devices
as one (in a sandwich way), this CL writes and reads the GPT structs
independently of the actual device that houses the partitions.
Therefore, the first usable LBA of the partitions will be at 0, and the
last usable LBA is at the end of the NAND.
+------------------------+
| NOR houses GPT structs |
+------------------------+
|
0 | Index into
v v
+------------------------+
| NAND houses partitions |
+------------------------+
Note that the "my_lba", "alternate_lba", "entries_lba" in the GPT headers
are no longer meaningful.
Consumers of cgptlib will have to set "stored_on_device" to either
GPT_STORED_ON_DEVICE or GPT_STORED_OFF_DEVICE, and "gpt_drive_sectors"
to the number of 512-byte sectors available to store GPT structs.
The NOR read and write operations are done by "flashrom".
BUG=chromium:425677
BRANCH=none
TEST=unittest
TEST=build with DEBUG, cgpt create/add/show on a stumpy-moblab
Change-Id: I083b3c94da3b0bb3da1a7b10c6969774080a2afd
Reviewed-on: https://chromium-review.googlesource.com/226800
Reviewed-by: Nam Nguyen <namnguyen@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
For kernel NAND support, some vboot/cgptlib functionality is
needed from depthcharge. This patch moves certain function
declarations to a new header in firmware/include and puts
their definitions in a common place.
TEST=make runalltests passes and packages build
BRANCH=none
BUG=chromium:403432
Change-Id: Idd42b1f9f531651d78bb4afb80ca90c24aae93d9
Reviewed-on: https://chromium-review.googlesource.com/224996
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Daniel Ehrenberg <dehrenberg@chromium.org>
Tested-by: Daniel Ehrenberg <dehrenberg@chromium.org>
This adds a field in the GBB header to store the sha256 digest of
the HWID string, and updates gbb_utility so that it stores the
digest when it modifies the HWID. Because this is a new field,
the GBB_MINOR_VER is incremented.
BUG=chromium:415227
BRANCH=ToT
TEST=make runtests, VBOOT2=1 make runtests
Since the GBB is in the RO firmware, there should be no side
effects for existing devices (but even without that, they should
handle a minor version change without complaint).
Change-Id: Icdb2a0b564677b0b65e58df897d2ec5af3964998
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221360
In order to display the slow EC update screen on x86 devices
in normal mode it is necessary to request a reboot where the
VGA Option ROM is loaded.
This needs a bit of plumbing to pass the OPROM_MATTERS and
OPROM_LOADED flags into shared data so they can be consumed
in the VbEcSoftwareSync() function. It also needs the VbInit()
function to not immediately request a reboot if the VGA Option
ROM was loaded in normal mode and the SLOW_EC flag is set as it
will still need to be used during software sync.
A FIXME in VbEcSoftwareSync() is implemented and the comment is
removed, and two extra checks are done. First, if rebooting to
RO then also check if the VGA Option ROM is needed to save an
extra reboot, and second when exiting the software sync function
request a reboot without the VGA Option ROM if it was done in
normal mode and the option rom was needed+loaded.
The request for a reboot from VbEcSoftwareSync() is saved when
doing EC update in case there is an (optional) PD software sync
that may also need to display the screen.
BUG=chrome-os-partner:12257,chrome-os-partner:32379
BRANCH=samus
TEST=all tests pass, manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Id592181efd640f4cd37a986cd1dcc29f3ca45104
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223718
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
