Originally, we didn't trust the firmware to provide these functions from
a standard library. Now, with coreboot, we do.
BUG=chromium:611535
BRANCH=none
TEST=make runtests; emerge-kevin coreboot depthcharge
Change-Id: I4e624c40085f2b665275a38624340b2f6aabcf11
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/399120
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
vboot_reference originally used 2-space indentation, rather than
kernel-style tabs. This makes it painful to maintain given that newer
source files are kernel-style.
Re-indent the files that need it, and reflow comments.
No functionality changes.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: I7dabed41f69434b1988a52600c0cb1eac8c8d7e6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396488
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
If there is no HWID and mainfw_type is "nonchrome", report that the
host is a VM. If HWID is present, it's not a VM. Make the detection
architecture-independent.
BUG=chromium:632303
TEST=emerge-cyan vboot_reference and test binary on QEMU and HW
TEST=emerge-veyron_minnie vboot_reference and test binary on HW
BRANCH=none
Change-Id: I076eb9838a3b724ded0cfded9fb8d8a5392631c8
Reviewed-on: https://chromium-review.googlesource.com/368650
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add "inside_vm" command to crossystem.
x86: If there is no HWID and mainfw_type is "nonchrome", report that the
host is a VM. If HWID is present, it's not a VM.
ARM: Detection not implemented and so far no ARM VMs exist, always
report that the system is not a VM
BUG=chromium:632303
TEST=emerge-cyan vboot_reference and test binary on cyan QEMU and HW
BRANCH=none
Change-Id: I18f5cb24b68e51f3097d9aafd9f0db0e610d322a
Reviewed-on: https://chromium-review.googlesource.com/367240
Commit-Ready: Nicolas Norvez <norvez@chromium.org>
Tested-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If this is an x86 system using vboot2 then write VbNv data
to CMOS and also use mosys to write it directly to flash.
BUG=chrome-os-partner:51846
BRANCH=none
TEST=emerge-chell vboot_reference; emerge-oak vboot_reference
verify on chell that "crossystem dev_disable_request=1" is
written to both CMOS and flash.
Change-Id: Ifd5dcee4d401f8de36801c5c0a7db3255e618e28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336311
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code to read/write vbnv with mosys was implemented in the
ARM specific code so move it to the generic crosystem code
so it can be used on x86.
No functional changes in this commit.
BUG=chrome-os-partner:51846
BRANCH=none
TEST=emerge-chell vboot_reference; emerge-oak vboot_reference
Change-Id: I3fe18fadb924094e710427208976328caf12a009
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336310
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
I don't even know what this is. It seems to have marked some kind of
debug buffer provided by H2C BIOS on pre-Daisy Chromebooks and has not
been touched since it was copied in here when crossystem was first
added. I can't find any references in our codebase so I doubt anybody
would miss it. Let's remove it so the '(error)' fields returned there on
any modern Chromebook stop confusing our vendors.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: Ie2baec536b50bb192eb4cd3e48df212cce53561a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311346
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
This field doesn't seem to be used for anyone and it keeps adding work
for people trying to bring up new platforms. If we ever needed something
like this again, we'd probably prefer to have it in mosys now anyway.
Let's get rid of it.
BRANCH=None
BUG=chromium:551715
TEST=Built for Falco and Jerry.
Change-Id: I6b96e255968fdd22a345d4a75bfdc1e79d3f5896
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311345
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
(resubmit)
Previously crossystem assumed that mosys was located
in /usr/sbin. In Android mosys is currently located
in /system/bin. Using fixed paths as opposed to
'which' to prevent attacks where attacker could insert
mosys in PATH.
difference from previous commit:
Removed the allocation of duplicate arrays. Kept
with simplicity of original version, just returning
correct constant depending on detected platform.
BUG=chromium:527484
BRANCH=none
TEST=ran crossystem, crossystem fw_try_count/
fw_try_next, crossystem fw_try_count/fw_try_next=x
on smaug and daisy.
Change-Id: I923206db1411a9a35c9c8e3f9ede5016f49b5f26
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299801
Reviewed-by: danny chan <dchan@chromium.org>
Previously crossystem assumed that mosys was located
in /usr/sbin. In Android mosys is currently located
in /system/bin. Using fixed paths as opposed to
'which' to prevent attacks where attacker could insert
mosys in PATH.
BUG=none
BRANCH=none
TEST=ran crossystem, crossystem fw_try_count/
fw_try_next, crossystem fw_try_count/fw_try_next=x
on link and smaug.
Change-Id: I9604f008d457147188dc852c173d5a184163b339
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/292314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the GPIO controller ID that is used in the Skylake PCH
so it can properly export and use GPIOs that are exported
in VBNV for write protect.
BUG=chrome-os-partner:42560
BRANCH=none
TEST=verify crossystem output with and without WP enabled
Change-Id: Ic85c202bd0ca15c154c10481926ef18bafe3fac5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286827
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the skylake-u and skylake-y vendor/device IDs so it can be
reported by crossystem.
BUG=chrome-os-partner:42560
BRANCH=none
TEST=run "crossystem platform_family" on glados
Change-Id: I5f9b92d404166e56d77cf8b0cd627a3a0b63bedf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286921
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For crossystem to work correctly on Strago/Cyan,
add Braswell string and correct GPIO offset
calculations.
In Braswell, write protect line is MF_ISH_GPIO_4
as encoded as 0x10016 where the GPEAST offset
(COMMUNITY_OFFSET_GPEAT) is 0x10000
BUG=chrome-os-partner:40835
BRANCH=None
TEST=test_that -b <strago/cyan> <IP> platform_Crossystem
Change-Id: I365f3d6ca9f3ac7ef50abb9b2ba13f184d39c100
Signed-off-by: John Zhao <john.zhao@intel.com>
Signed-off-by: Arindam Roy <arindam.roy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/274841
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
We may have been over-zealous earlier when trying to eliminate
references to mkbp. Since crossystem runs on all ChromeOS devices,
this re-adds "mkbp" back to mitigate the risk of encountering
problems on systems running newer versions of ChromeOS but with
older firmware.
BUG=chrome-os-partner:21097
BRANCH=none
TEST=Compiled for veyron_brain
Change-Id: Ia0086687fbc3a1195b062367ccb6ee5c41acd026
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282602
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This changes the string we look for in the devicetree on ARM
platforms to look for "cros-ec" (DT uses dashes instead of
underscores) instead of "mkbp".
BUG=chrome-os-partner:21097
CQ-DEPEND=CL:273347
BRANCH=none
TEST=with depthcharge patch applied, ran crossystem on newly
booted system and saw VBNV-related variables turn out the same.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iac43f5381327eb878a8d0db606b78bb7bdce816f
Reviewed-on: https://chromium-review.googlesource.com/273391
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
AFAICT this property is not really used by anything. All factory
scripts that need detailed memory info get it from mosys. Most
platforms display "unknown" which causes confusion whenever
a bug is filed to support crossystem on a new platform.
BUG=chrome-os-partner:36176
BRANCH=none
TEST=no more "unknown" ddr-type shown in crossystem output on speedy
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I97e66c362e9d88c843128a411512d5a76ac5f87d
Reviewed-on: https://chromium-review.googlesource.com/263982
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The following works from a Mac with these changes:
make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility
Only vbutil_keyblock and vbutil_kernel have been exercised.
BUG=none
TEST='make Q= ARCH=arm HAVE_MACOS=1 `pwd`/build/futility/futility'
BRANCH=none
Signed-off-by: David Riley <davidriley@chromium.org>
Change-Id: Ie69cfee0c650d4ff96be6322083a2fea1543ee39
Reviewed-on: https://chromium-review.googlesource.com/246773
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
The kernel chromeos_arm platform device provides the recovery status
with the consideration of active polarity.
Thus make crossystem to read from chromeos_arm device first. If this
is not available, read directly from gpio pin status.
BUG=chrome-os-partner:36425
BRANCH=none
TEST=ran on kitty,
'crossystem recoverysw_cur' return 0 with recovery switch off
'crossystem recoverysw_cur' return 1 with recovery switch on
Change-Id: Ie20630d7d07aeadf24044cd3ffc495df7cdd8a4a
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/246883
Tested-by: Titan Lee <titanlee@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Titan Lee <titanlee@nvidia.com>
The current logic for finding a GPIO expects only one gpiochip
entry to exist in /sys/class/gpio. With Samus there is a second
entry because the codec also exports a set of GPIOs.
To solve this we can use the gpiochip#/label file and compare
against the GPIO controller name described in ACPI.
This adds support for that detection method, as well as a new
GPIO controller entry for INT3437:00 which is used in Broadwell
systems.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossytem wpsw_cur works on samus (TOT with enabled codec)
Change-Id: Ib06f25c7c7e1451a3ab3bb00fd063e23b4d75878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224156
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently ReadFileInt assumes that an integer value read from a file
is never going to be "-1" and uses that value to indicate failure.
In particular for GPIO values that may be returned by the kernel it
is possible for them to be not simply 0 or 1 but instead a bit within
the GPIO status register that indicates the value.
The function semantics are changed to have the caller pass in the
variable to store the integer in, and use the return code explicitly
as a pass or fail condition.
This requires all the callers of ReadFileInt to be changed to use the
new scheme, and the x86 ReadGpio function is changed to normalize the
GPIO value that is read from the kernel instead of assuming it is
always 1 for active high values.
BUG=chrome-os-partner:32645
BRANCH=samus,auron
TEST=build for samus, check crossystem output and ensure that all
values are properly reported and that wpsw_cur is correct now.
Also tested to ensure no changes in output on: x86-alex, daisy,
peach_pit, lumpy, stumpy, nyan_big, nyan_blaze, rush_ryu, panther,
wolf, zako, auron, rambi, squawks, parrot_ivb, veyron_pinky
Change-Id: I824152eed5f96cf1faaa18ba31a01f4d346ad172
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223009
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is just a cosmetic tweak to make it a bit clearer that
mosys is the underlying interface for these particular vbnv
read/write functions.
BUG=none
BRANCH=none
TEST=it still compiles
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ide172bfecf608a30489d25026268aedfc421ce4d
Reviewed-on: https://chromium-review.googlesource.com/222062
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This handles VBNV data stored in SPI flash which happens to be
the exact same way we handle VBNV data stored in the EC.
BUG=chrome-os-partner:31529
BRANCH=none
TEST=with CL:221349 applied, crossystem on storm no longer
spews tons of errors
Change-Id: I021d9f430acfac34dff44a927361a5a0e5ae2ff8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222061
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rather than continuing to report different variants of PCH GPIO the same
way use the common name of PCH-LP.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=boot on samus and ensure there are no (error) reported
Change-Id: I9321e7bd85b2b3b3ebadc22ac32be6759e85f822
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210393
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Teach crossystem the tegra124 compatibility string so that it can identify the
platform for tegra124 based systems.
I called the platform Tegra5 to fit in with what seems to be the naming scheme
for the other Tegra SOCs.
BUG=chrome-os-partner:25355
TEST=Built and ran on nyan and saw the "platform_family" setting return Tegra5
instead of (error).
BRANCH=None
Change-Id: I1044f958ecdac37ad285fdc3d53e7bc36ca69315
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/184051
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
BayTrail systems have 3 banks of gpios. Therefore,
the Linux kernel exposes these 3 banks as 3 gpiochip
entries. The kernel driver expects the 3 banks to be
exposed with specific UIDs associated with a specific
banks. ChromeOS firmware maps gpios within a given
bank using the bank's MMIO offset. In summary:
Bank Type | UID | Offset
----------+-----+-------
SCORE | 1 | 0x0000
NCORE | 2 | 0x1000
SUS | 3 | 0x2000
BUG=chrome-os-partner:24408
BUG=chrome-os-partner:24324
BRANCH=None
TEST=Built. 'crossystem wpsw_cur' works correctly.
Change-Id: I251f86285ce9733f7ca90ed1ebef536f4fe5c07c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179513
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Up until recently the x86 systems had a single contiguous
set of gpio numbers exported through /sys/class/gpio
as /sys/class/gpiochip<X> values. BayTrail systems have
3 sets of gpio numbers. Therefore, there needs to be a
translation/look-up function based on chipset. The existing
chipsets have a 1:1 mapping, but this patch lays the ground-
work for chipset-specific translation.
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BUG=chrome-os-partner:24408
BRANCH=None
TEST=Built. Ran on Rambi.
Change-Id: I32bcd975aea421f86a0220ee30332f48fe727656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179512
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BayTrail is a valid chromeos platform. Therefore, allow
it to be returned for 'platform_family'.
BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BRANCH=None
TEST=Built. 'crossystem platform_family' reports 'BayTrail'.
Change-Id: I8d0b835f5f40e7f34adb4f91bd974c428bbaf6da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179511
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This adds a VB_MAX_STRING_PROPERTY for callers that don't
want to guess at how big to make their buffers.
Additionally, it changes the size parameter to VbGetPropertyString()
from int to size_t.
BUG=None
TEST=compile the code
BRANCH=none
Change-Id: I22809d48e13b535593cb22a56444e2dcb27791a5
Reviewed-on: https://chromium-review.googlesource.com/175039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
A few places in the code through up warnings when building with strict
compiler flags. Correct these.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
Build with:
FEATURES=test emerge-peach_pit vboot_reference
and see that iot now succeeds. Warnings include:
host/arch/arm/lib/crossystem_arch.c: In function 'ReadFdtValue':
host/arch/arm/lib/crossystem_arch.c:93:8: error: ignoring return value of 'fread', declared with attribute warn_unused_result [-Werror=unused-result]
Change-Id: I765723636e5f8979b794925c7b610081b2849026
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66174
At present the kernel tests produce valgrind errors since the GPT data is
sometimes accessed before it is read. This is unnecessary, so update the
code to avoid this.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
valgrind --leak-check=full ./build/tests/vboot_kernel_tests
See that we no longer get valgrind errors.
Change-Id: I9e9660e38a62a735cf01a37c2d81ddb5ab8b1528
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66173
Haswell CPUs are paired with the LynxPoint chipset and this
needs to be a valid controller name for crossystem.
BUG=chrome-os-partner:19263
BRANCH=none
TEST=manual
This was tested on a wtm2 system to ensure that a GPIO
defined in chromeos ACPI that is exported by the kernel at
/sys/devices/platform/chromeos_acpi/GPIO.# is used by crossystem
and the GPIO is exported in /sys/class/gpio and read.
$ cat /sys/devices/platform/chromeos_acpi/GPIO.1/GPIO.2
34
$ cat /sys/class/gpio/gpio196/value
1
$ crossystem wpsw_cur
1
Change-Id: I04064109e99270d7d26b27182b17fffbf47b025b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50224
Reviewed-by: Aaron Durbin <adurbin@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>
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>
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>
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 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 7ec59576f6.
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>
