| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I99d8124a7d5a3a644f0d8d64ad36f51e78d851e5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42018
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should use only arm, x86, and x86_64; currently we also use i386 to
mean x86, and amd64 to mean x86_64.
BUG=chromium-os:26317
BRANCH=none
TEST=manual
sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-link vboot_reference chromeos-u-boot chromeos-installer
FEATURES=test emerge-daisy vboot_reference chromeos-u-boot chromeos-installer
FEATURES=test emerge-x86-alex vboot_reference chromeos-installer
make && make runtests (both inside and outside chroot)
Change-Id: I4fb64fafa9c48a76ded862e074776cab9ea54ab3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41838
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a necessary precursor to getting coverage working.
BUG=chromium-os:26317
BRANCH=none
TEST=manual
sudo emerge vboot_reference
emerge-link vboot_reference chromeos-u-boot
emerge-daisy vboot_reference chromeos-u-boot
Change-Id: Ibed91c64a5ca5fa486169d64fb01a9e868ce27e5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 13ed1f4812f810ee0a47b946ad990f1fa93f366c)
Reviewed-on: https://gerrit.chromium.org/gerrit/40906
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds a one-byte field in the nvstorage region for use in debugging
hard-to-catch errors. There's no official meaning or expectation for this
field. It's just a handy place to emit some information.
BUG=chrome-os-partner:11534
BRANCH=parrot
TEST=manual
Just change the value and ensure that it persists across a (working) reboot.
It's only updated at specific points under very exacting error conditions,
so all we really want to test is that it works as a place to store some
extra info.
crossystem recovery_subcode
crossystem recovery_subcode=14
reboot
crossystem recovery_subcode
The recovery_subcode byte is at index [6] of the VbNv.raw bytes that appear
when you press TAB, so you can find it there too:
VbNv.raw: 60 20 00 00 00 00 0e 00 00 00 00 00 00 00 00 65
Decimal 14 == 0x0e
Change-Id: I1930b8f81a03ab838dbee99a8d72c35a444efdfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39803
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devsw_cur is really a meaningless concept on systems with virtual dev
switches; it exists primarily to support factory test of physical
developer switches. However, some plugins use this instead of the
preferred devsw_boot, and it's easier to modify crossystem than the
plugins at this point in time.
BUG=chrome-os-partner:12928
BRANCH=none (affects all current products, but is an OS-level change, not FW)
TEST=manual
- On link, 'crossystem devsw_cur devsw_boot' with dev switch on -> '1 1'
- On link, 'crossystem devsw_cur devsw_boot' with dev switch off -> '0 0'
- On lumpy or earlier, 'crossystem devsw_cur' should return current dev
switch position; check this by toggling the physical switch without
rebooting and see that the reported value follows the switch value.
Change-Id: Ie7416e5cb03c133572c32af677b55ed18884dfb8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34531
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older firmware does not provide nonvolatile-context-storage FDT
property, and crossystem complains about it.
This is harmless; so just make it quiet.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=none
BUG=chrome-os-partner:14475
TEST=manual, see blow
Run crossystem and make sure its output does not contain
"Unable to open FDT property nonvolatile-context-storage"
messages.
Check crossystem still works by comparing its output w/ and w/o this
change.
Change-Id: I0b8f40775833457a75d801f185344e931ac08847
Reviewed-on: https://gerrit.chromium.org/gerrit/33896
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option is disabled per default and can be enabled with
crossystem dev_boot_legacy=1
or by setting the GBB flag
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080
BUG=chrome-os-partner:6108
TEST=crossystem dev_boot_legacy=1
boot to dev mode screen, press CTRL-L, see SeaBIOS start
(other CLs needed)
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38
Reviewed-on: https://gerrit.chromium.org/gerrit/31265
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may have multiple storage types (disk or mkbp) of VbNvContext.
crossystem should switch the type and choose the corresponding device
driver.
After patching U-Boot, you may check storage type:
[ "mkbp" = "$(cat /proc/device-tree/firmware/chromeos/nonvolatile-context-storage)" ]
And cross-verify crossystem with mosys:
$ mosys nvram vboot read
70000000000000000000000000000020
$ crossystem recovery_request
0
$ crossystem recovery_request=123
$ mosys nvram vboot read
70007b0000000000000000000000005d
$ mosys nvram vboot write 70000000000000000000000000000020
$ crossystem recovery_request
0
More importantly, crossystem should also work with older version of
firmware, which does not pass down this information.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=none
BUG=chrome-os-partner:13766
TEST=Check storage type on a Snow device:
[ "mkbp" = "$(cat /proc/device-tree/firmware/chromeos/nonvolatile-context-storage)" ]
Make sure that FAFT is still happy:
./run_remote_tests.sh --remote $ADDR --board daisy 'firmware_TryFwB/control$'
./run_remote_tests.sh --remote $ADDR --board daisy 'firmware_TryFwB/control.dev$'
More importantly, check crossystem worked well even when ChromeOS
is booted from an older version of firmware.
Change-Id: I3989a8c181efe03cd9f06127743763e0ad97e281
Reviewed-on: https://gerrit.chromium.org/gerrit/32470
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 92951c813dc416c24d8a9eda39d037f46baeb077.
BUG=chromium-os:33963,
TEST=None
BRANCH=None
Change-Id: I186432ab4cdb91495f81a1574863fada28f59603
Reviewed-on: https://gerrit.chromium.org/gerrit/31690
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to know not only whether the HW WP pin is asserted, but whether the
flash chip has configured its software protection registers to actually
protect anything. This flag can be used to indicate that.
BUG=chrome-os-partner:13265
BRANCH=link
TEST=none
This just adds the flag. Nothing actually sets the flag yet, so there's
nothing to test.
Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31642
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FMAP requires to be aligned at 64-byte. Searchin at 4-byte could
lead bug if a designated FMAP is located at 4-byte address.
BUG=chrome-os-partner:13143,
TEST=Tested in CL https://gerrit.chromium.org/gerrit/#/c/31436/
BRANCH=link,snow
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: Ib7f36dc89d7d2763b1a72b641433d45bec6c2bef
Reviewed-on: https://gerrit.chromium.org/gerrit/31442
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These fields are part of the version 1 struct, but were mistakenly
labeled as version 2 fields. Since ZGB firmware produces a version 1
struct, crossystem was treating the fields as unavailable.
BUG=chromium-os:33685
TEST=crossystem tpm_fwver tpm_kernver
BRANCH=none (OS utility change, not firmware, and affects only Alex/ZGB)
Change-Id: Ic857ee2da9a7ae7f0d42317b711bf102d068de64
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30904
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The value of the ChromeOS write protect switch is now provided through the new
chromeos_arm platform device which avoids the mismatch between U-Boot and
kernel GPIO numbering.
BUG=chrome-os-partner:11297
TEST=gmerge-ed onto a snow and verified that crossystem got the right value of
the write protect switch.
BRANCH=snow
Change-Id: I466370e4f6bf2d14c067518a9d620e9e60142a0b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/30534
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two new flags to crossystem:
clear_tpm_owner_request
clear_tpm_owner_done
The first one requests that the firmware clear the TPM owner on the
next boot. When the firmware does this, it will set
clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can
use the done-flag as a hint that trusted things guarded by the TPM are
no longer trustable.
BUG=chromium-os:31974
TEST=manual
crossystem
// both flags initially 0
crossystem clear_tpm_owner_request=1
crossystem clear_tpm_owner_done=1
// request=1, done=0; done can be cleared but not set by crossystem
reboot
tpmc getownership
// owned=no
crossystem
// request=0, done=1
crossystem clear_tpm_owner_done=0
crossystem
// both flags 0 again
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd
Reviewed-on: https://gerrit.chromium.org/gerrit/25646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to avoid confusion with the canonical common.mk file that is
a CrOS build system.
BUG=chromium-os:33327
TEST=`cros_run_unit_tests --board x86-alex -p vboot_reference` still works
Change-Id: I4b6719d58a4a8ab44b62c23c0e2c45b154374958
Reviewed-on: https://gerrit.chromium.org/gerrit/29578
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more reliable than reading them through FDT/ACPI, since it reflects
the positions as shown to verified boot code.
Notes:
1. This affects ALL platforms with virtual dev switches (x86 AND arm)
2. The fix should have no effect on older platforms, but I haven't tested those.
BUG=chrome-os-partner:11805
TEST=manual
1. boot in normal mode.
devsw_boot = 0 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
2. boot in developer mode.
localhost ~ # crossystem
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
3. boot in developer-recovery mode using keyboard combo.
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 2 # Recovery mode reason for current boot
recoverysw_boot = 1 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
4. disable WP and reboot. wpsw_boot should be 0.
Change-Id: If4156b5e14c6923c5b331c7e5feaabbffe1dad37
Reviewed-on: https://gerrit.chromium.org/gerrit/29199
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As kernel has adjusted the value of /sys/class/gpio/gpio${PORT}/ with
active_low stuff before returning it to user, crossystem should not do
another adjustment.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:11297
TEST=On Snow, run crossystem and see wpsw_boot equals to wpsw_cur.
Then invert /sys/class/gpio/gpio${PORT}/active_low value, and
see wpsw_boot does not equal to wpsw_cur.
Change-Id: I09fec89788bc4393775d5cf9763b8cebeb645ad4
Reviewed-on: https://gerrit.chromium.org/gerrit/27252
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the record, zero is a valid GPIO port number. Unfortunately
firmware uses port zero to denote that a GPIO port is not exist.
So crossystem should not attempt to read GPIO port zero, but
return error instead.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:11296
TEST=On Snow, run crossystem and see devsw_cur and recoverysw_cur
are "(error)"
Change-Id: I70b15824f613df1e46bf152515ad4e9362c9f066
Reviewed-on: https://gerrit.chromium.org/gerrit/27251
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 7ec59576f6f61effdc35482c8cfd4aa32b643b1a.
We would like to keep dev_cur and recovery_cur output "(error)" so that
factory process knows that firmware uses virtual switches.
I think this is strange, but this is how factory process works for now.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chromium-os:10007
TEST=none
Change-Id: I370a3e9f5a8847916445348abb81f7c4bbf3d27f
Reviewed-on: https://gerrit.chromium.org/gerrit/26909
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change exports gpio number if it can not be accessed. Ignore
the active_low checking for compatibility.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:11029
TEST=manual
Run crossystem and check WP pin status
Change-Id: I0885ab21c6c6d614945e4fda49a373e8619772a9
Reviewed-on: https://gerrit.chromium.org/gerrit/26563
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As dev switch and recovery switch may be virtual, crossystem has to
distinguish virtual switches from physical ones.
Since to a virtual switch, its current value should always equal to its
boot value, return a boot value when asked for a current value.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:10007
TEST=crossystem devsw_cur|recoverysw_cur show correct value on Snow
Change-Id: Ia73147ecd5528a3cc5276aff02a632ce4f52ea8b
Reviewed-on: https://gerrit.chromium.org/gerrit/26568
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Samsung want to know what memory type on the device. So this CL adds a
new field ddr_type to crossystem utility in order to query this info.
It is only available on ARM platform so far.
BUG=chrome-os-partner:10857
TEST=Built and boot on Snow successfuly. On userspace, query the field via:
localhost ~ # crossystem ddr_type
ddr3
Change-Id: I01d1dec412fe4052e1ea6cfe2e53830da97a710b
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26411
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For fastest boot, we don't want to load the VGA Option ROM every time, but
only when we need it. Coreboot does that loading, but it can't always know
when it's needed (with keyboard-based dev-mode, coreboot can't tell if we're
in dev-mode or not). By the time we get to U-Boot, it's too late, so we need
two extra bits - one for vboot to tell coreboot to load the Option ROM and
another for coreboot to let vboot know it's been done.
BUG=chrome-os-partner:8789
TEST=manual
The only visible change is that crossystem will now have an "oprom_needed"
flag that can be set or cleared. Nothing actually pays attention to it yet,
though.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I521a6afdfb8ea17a8148b32eeb858844c981de9c
Reviewed-on: https://gerrit.chromium.org/gerrit/26272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:10872
TEST=run crossystem on snow, check output
Change-Id: I413cbd86833fc8abff9afbf12a85abe53b586af4
Reviewed-on: https://gerrit.chromium.org/gerrit/26090
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confirmed via codesearch that these fields are not used outside of
vboot_reference itself, and the only use inside vboot_reference is one
test which checked that the test error generation itself worked.
BUG=chromium-os:31668
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic393e126ca2853f7aaff19ffd6fcdbdb1c47689f
Reviewed-on: https://gerrit.chromium.org/gerrit/24895
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just creates the bit. It doesn't actually do anything yet.
BUG=chrome-os-partner:9980
TEST=manual
crossystem disable_dev_request=1
crossystem
crossystem disable_dev_request=0
crossystem
Change-Id: I0e92a6b5ef5074ee5eae2d6d469c1c9826faecb3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23752
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Change-Id: Ib9781238274285f73d00d8fca4ecda28fc2c6678
Reviewed-on: https://gerrit.chromium.org/gerrit/21748
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to be able to tell when a ChromeOS machine was brought up
using netboot. This condition will be communicated from firmware using
the BINF.3 ACPI object (upcoming u-boot change).
BUG=chrome-os-partner:7952
TEST=manual
. boot a ChromeOS machine using the updated firmware and examine the
main firmware type reported by crossystem:
localhost ~ # echo $(/var/crossystem mainfw_type)
netboot
Change-Id: I35b10f41eb1f928a122c384d0179c9027f263acd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/20707
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, 'cros_debug' would ignore the kernel command line if
the system was booted in recovery mode. The check provided no
particular security benefit; it served only to complicate the work
of developers who wanted to boot debug images over USB with dev-key
signed firmware.
BUG=chromium-os:19236
TEST=Test 'crossystem cros_debug' on a system in the cited use case
Change-Id: Ie664c50984411340a10896137022d7d4ff503d0a
Reviewed-on: https://gerrit.chromium.org/gerrit/6663
Commit-Ready: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a filter in crossystem which makes sure that it accepts GPIO
information only from a subset of GPIO controllers. Panther Point
needs to be included in the list.
BUG=chrome-os-partner:8615
TEST=manual
. run the new crossystem on a Link
. modify write protect and and recovery (as it comes from servo-2)
pins' status
. observe the appropriate crossystem values change
Change-Id: I3ac269a9ea520f2c44ee090fe71ec8ad808692ba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18936
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started out as a simple fix for a minor bug and turned into a nearly
complete rewrite. Now that it's done I'm not sure it really matters. This
version is a lot cleaner about handling command-line args, but isn't
otherwise noticeably better. Sigh.
BUG=none
TEST=manual
make
make runtests
Change-Id: I9c194e9c0e6418488635989ef666bc83c6e39816
Reviewed-on: https://gerrit.chromium.org/gerrit/18268
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds in logic to check that ReadFdtBlock within ReadFdtPlatformFamily
succeeded, returning NULL on failure.
BUG=None
TEST=Manual, run crossystem on an ARM system without a valid compatible FDT
entry and ensure (error) is returned for platform_family.
Change-Id: I6351292ff73e4bc08b028f85e72ccfe62159194a
Reviewed-on: https://gerrit.chromium.org/gerrit/14321
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the ReadFdtBlock function for ARM to allow for a direct path
to a FDT entry by starting the property with a '/'. This allows the
ReadFdtPlatformFamily function to use a direct path instead of stepping back
through folders, and will enable future crossystem entries to do the same.
BUG=chromium-os:24669
TEST=Manual
Change-Id: Ibddb881815947259c2532d7f5474eda5fdc9f803
Reviewed-on: https://gerrit.chromium.org/gerrit/14305
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements a platform_family value within the crossystem utility,
as the platform (particularly for ARM) is not easily accessable elsewhere at
runtime.
For the ARM side this contains a table which is used to determine the platform
family based on the /proc/device-tree/compatible entry. Similarly on x86 the
table is used to check against PCI entries. Additional entries can be made
as new platform families emerge.
BUG=chromium-os:24669
TEST=Manual, verified that crossystem runs properly and returns a valid
platform_family value on various platforms (mario, alex, z600, x220, etc).
Change-Id: Id0e973902d27ead471c1243bcc6c3292acc8479d
Reviewed-on: https://gerrit.chromium.org/gerrit/13520
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since x86 and amd64 boards use the same firmware and are otherwise identical
use the same implementation for crossystem on both
BUG=chromium-os:21386
TEST=emerge-x86-generic ; test crossystem works on Samsung Series 5
TEST=emerge-amd64-generic ; test crossystem works on Samsung Series 5
TEST=run unit tests on build machine with:
RUNTESTS=1 make
Change-Id: Ica516cca7ead6cb9cdfae0894bd532669ba3ba88
Reviewed-on: https://gerrit.chromium.org/gerrit/12059
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you enter dev-mode,
Pressing Ctrl-U to boot from USB is DISABLED.
Booting any self-signed kernel from the SSD is ENABLED.
This replaces the "crossystem dev_boot_custom" argument with
"crossystem dev_boot_signed_only", which has the opposite polarity.
So if you want to dev-mode to only boot official kernels, you have to
explictly set it that way. If you leave dev-mode and then come back,
it will go back to the conditions shown above.
BUG=chrome-os-partner:5954
TEST=manual
Just run the factory flow. It was broken; this should fix it (except for any
workarounds that were added while it was broken; those may need to be
reverted).
Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805
Reviewed-on: https://gerrit.chromium.org/gerrit/11853
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VbCmosWrite should seek to correct offset before starting to write;
also fixed file handle leakage.
BUG=chromium-os:23000
TEST=crossystem recovery_request=1; echo $? # show: 0
crossystem recovery_request # show: 1
reboot # see recovery screen
Change-Id: I33bca8af2b351ba9b364309838df699a31bb543a
Reviewed-on: https://gerrit.chromium.org/gerrit/11756
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A legacy checksum in CMOS is not maintained by coreboot and may be invalid. If
the Linux kernel driver sees that the checksum is wrong, it will return EIO
when read from or written to. That makes crossystem return an error since it
can't read the CMOS, and it also prevents it from changing some settings.
One way to fix the problem would be to remove the checksum check in the kernel
driver. This would change the semantics of the driver so that either x86 was
inconsistent with the other architectures, or change the semantics of those
other architectures as well.
Another option would be to fix the checksum during manufacturing since nothing
should be changing those particular bytes of CMOS. The problem with this
approach is that something might corrupt the CMOS after manufacturing, and
we'd have the same problem again.
Yet another solution would be to make the firmware, most likely coreboot,
actually keep the checksum up to date. This seems like an awful waste of boot
time, the bytes protected by the checksum aren't actually used by anything,
and the bytes of the CMOS that are used are protected by vboot using its own
checksum.
The solution implemented here is to make crossystem recognize when the driver
has determined that the checksum is invalid and make it call an ioctl that
gets the driver to fix the checksum. Wrapper functions for fread, fwrite,
fgetc, and fputc are implemented which first attempt to read or write, on
failure check for the EIO error code, and if they find it to call the
appropriate ioctl and attempt the access again. This way, we won't take any
extra time to talk to the CMOS when everything is working properly, and when
there's a problem it gets fixed up transparently. One problem with this
approach is that using the /dev/nvram device file will still fail until
crossystem is run at least once and given a chance to fix the checksum.
BUG=chrome-os-partner:6718
TEST=For version 1, verified that crossystem reported an error on Sameer's
Lumpy. Used strace to verify that crossystem received an EIO error when trying
to read or write /dev/nvram. Built a new image with this change and booted it
using a USB stick. Ran crossystem and verified that crossystem no longer
reported an error. Rebooted into the original image and verified that
crossystem worked there as well, indicating that the persistent problem in the
CMOS had been corrected.
For version 2, the same as version 1 except that I used a custom version of
u-boot to purposefully corrupt the CMOS rather than using Sameer's Lumpy.
Change-Id: I929535bd2a7d666e41a707b6b24c3f0b0df1147f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11373
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although we're now using a single unified BIOS, it is pretty nice to be able
to get a shell in developer mode while still using verified boot for the
kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode
user to install a special dev-mode BIOS. We don't do that, but we DO require
setting a special flag with "crossystem" to accomplish the same thing.
In order to allow booting a self-signed kernel, you must boot in developer
mode, open a shell, and run this:
crossystem dev_boot_custom=1
Special note to internal developers: If you're in the habit (as I am) of
booting directly from a USB stick in dev-mode, you'll have to run this:
crossystem dev_boot_custom=1 dev_boot_usb=1
Just using dev_boot_usb=1 is no longer enough, because the USB kernel is
signed using the recovery key and by pressing Ctrl-U, we validate it with
the kernel data key. That worked before this change because any self-signed
kernel was fine, and that's how the USB key was treated. Now it actually
requires a verified signature until you enable dev_boot_custom=1 also.
BUG=chrome-os-partner:5954
TEST=manual
Boot once in normal mode, which clears the special flags. Then switch to
developer mode. You should be able to boot and get a root shell.
Run
crossystem dev_boot_usb=1
Obtain a USB recovery image that's keyed differently. For example, if you're
testing with dev-keys, use a PVT-signed image or vice-versa.
Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode
screen, press Ctrl-U. You should hear a single beep, but it should not boot.
Press Ctrl-D to boot from the hard drive, log in to a shell and run
crossystem dev_boot_custom=1
Repeat the previous test. This time when you press Ctrl-U, it should boot
the recovery image. Turn the system off before it does anything.
That's it.
Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69
Reviewed-on: https://gerrit.chromium.org/gerrit/11442
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... instead of using hard-coded 192 constant.
BUG=chromium-os:19876
TEST=manual
If crossystem still reports correct values for devsw_cur recoverysw_cur (and
maybe wpsw_cur, although that's a separate bug), then it works.
Change-Id: Id8d4fb389bfd78f40da9ef08aa372071d77cbec1
Reviewed-on: http://gerrit.chromium.org/gerrit/7014
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:4879
TEST=manual (just try it)
NOTE: You must use a BIOS that exports the correct ACPI tables.
Change-Id: I027680a203f3a566edf9ed82fb1fe1a9fa4c4f0f
Reviewed-on: http://gerrit.chromium.org/gerrit/4957
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:14029
TEST=make && make runtests, and manually check:
crossystem fwupdate_tries=3
crossystem fwupdate_tries kern_nv
(should print 3 0x00000003)
crossystem kern_nv=0
(should fail)
crossystem fwupdate_tries kern_nv
(should print 3 0x00000003)
crossystem fwupdate_tries=0
crossystem fwupdate_tries kern_nv
(should print 0 0x00000000)
Change-Id: I906ad41a36378b93e0c3330d8f94b7d69aafa536
Reviewed-on: http://gerrit.chromium.org/gerrit/4751
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
TEST=run crossystem
BUG=chrome-os-partner:4691
Change-Id: If590d185446dfa7cb628b5014f3a9a9c7b7a901d
Reviewed-on: http://gerrit.chromium.org/gerrit/3355
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
U-Boot should not parse the raw contents of VbNvStorage, and so cannot
read the recovery reason from the VbNvStorage. On the other hand, it is
easy for crossystem to read the recovery reason from the VbNvStorage
itself.
After this change is merged, U-Boot will stop providing the (incorrect)
recovery reason in the device tree.
BUG=chromium-os:17876,chromium-os:17852
TEST=press recovery button and see crossystem reports recovery_reason=2
Change-Id: I236667f0b4f2e25da193cf6b6f7db3871d1e093f
Reviewed-on: http://gerrit.chromium.org/gerrit/4396
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't use FDT to report it on ARM.
This fixes ARM reporting the wrong thing for RO-normal.
BUG=none
TEST=none
Change-Id: Id3a1bd2a1d2502e1d9493ab362be5a58fa88d70e
Reviewed-on: http://gerrit.chromium.org/gerrit/4213
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=make sure developer switch and recovery switch runtime reading works as expected (manually)
Change-Id: I3b17ac66f88b2b789bebe4e7d271666f8c63a8b0
Reviewed-on: http://gerrit.chromium.org/gerrit/4127
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also includes reading the nonvolatile storage from disk instead of
through the device-tree, since it's not updated there.
BUG=none
TEST=read and write a few crossystem variables
Change-Id: I6836a6eb0c92a0560dd393e694690a694bdb77a6
Reviewed-on: http://gerrit.chromium.org/gerrit/4078
Tested-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL builds upon recent changes in u-boot and kernel. (see issue
ids: 15744, 16665)
- Remove /sys/kernel/debug/chromeos_arm share memory mechanism
- Load properties from /proc/device-tree/crossystem/*
- Write NVCXT to /dev/mmcblk0:lba[0]
BUG=chromium-os:17300
TEST=manual
Run crossystem on device console. Check current values of gpio
switches. All other values are exported from FDT directly.
Change-Id: Ib8db4a4aeb6dc36308ad8882403cb2f5978a5c70
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3676
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
|