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>
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>
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 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>
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>
... 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>
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>
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>
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>
The content in VbSharedMem should be VbSharedData instead of FMAP.
BUG=chromium-os:17168
TEST=crossystem # seeing correct value
(the test need a u-boot with fix included)
Change-Id: I3d7d1eb2b35c9475c2047e9479cee69464da20b1
Reviewed-on: http://gerrit.chromium.org/gerrit/3436
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This is part 2 of the wrapper API refactor. It adds stub
implementations for the host, and changes the host-side utilities to
use them. Firmware implementation is unchanged in this CL (other than
a few updates to macros).
BUG=chromium_os:16997
TEST=make && make runtests
Change-Id: I63989bd11de1f2239ddae256beaccd31bfb5acef
Reviewed-on: http://gerrit.chromium.org/gerrit/3256
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Header file changes for wrapper API implementation
Crossystem support for reading recovery reason from VbSharedData, and
explicit support for version 1 VbSharedData structs.
BUG=chromium-os:16970
TEST=make && make runtests; run crossystem on Alex and make sure it still reports recovery_reason in recovery mode.
Change-Id: I15195b899583e425d3c9e8df09842d764528e2cb
Reviewed-on: http://gerrit.chromium.org/gerrit/3203
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The error was:
arch/arm/lib/crossystem_arch.c: In function ‘VbReadSharedMemory’:
arch/arm/lib/crossystem_arch.c:134: error: format ‘%d’ expects type ‘int’, but argument 5 has type ‘long unsigned int’
BUG=none
TEST=(outside choot): cd src/platform/vboot_reference; make
Change-Id: I5e1f69abd125fe06cf6ae04a7946568bdbcef83e
Reviewed-on: http://gerrit.chromium.org/gerrit/1547
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
U-boot and crossystem interpret the same switch state differently
for 'recovery mode' and 'write protect', This change adds the
ability to invert certan GPIO readings such that crossystem and
u-boot return the same values.
BUG=chromium-os:15393
TEST=manual
Running crossystem on the target with developer u-boot image:
- observe that recoverysw_cur reading matches recoverysw_boot and
wpsw_cur reading matches_wpsw_boot.
- try rebooting with recovery or developer mode buttons pressed,
observe the change in reported values of devsw_boot and
recoverysw_boot.
- observe reported values of devsw_cur and recoverysw_cur
following pressing of the buttons.
Change-Id: I628f59b60008719bbff1722d23154ce934af6c36
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/1193
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This CL builds upon earlier firmware and kernel changes (see CLs
related to the same bug, chromium-os:12522).
ARM firmware now simulates both Nvram storage and VDAT buffer, the
structures the x86 version uses extensively to communicate back and
forth between firmware/kernel/userland.
So, to make crossystem work on arm, all what's needed is to provide
architecture specific interface to Nvram and VDAT simulation, and
architecture specific processing for variables which are accessed on
ARM platforms in a different way.
The few discrepancies and platform specifics which had to be addressed
for ARM specifically are as follows:
- the Nvram contents are cached in the shared memory and available for
reading as part of /sys/kernel/debug/chromeos_arm. When writing
Nvram, the same file needs to be written, but only the 16 bytes
(representing the Nvram contents) are aacepted.
- the VDAT buffer also comes from the shared memory (as part of the
same sysfs file)
- when crossystem starts, it needs to read in this shared memory
contents, a` weak' function VbArchInit() is being added such that it
is provided on ARM platforms only, on x86 an empty stub is called.
- current developer/recovery request/ro firmware switch states are
retrieved through GPIO drivers. The GPIO numbers are defined in the
file, the GPIO driver is supposed to be configured before
crsossystem can operate.
- the BINF values are supplied through an array within shared memory,
it would be easy to refactor both x86 and ARM use the same code to
process BINF values, but with this submission the code is duplicated
to minimize x86 impact.
- the following crossystem variables do not have ARM equivalents,
thier values are reported as '(error)':
recoverysw_ec_boot
savedmem_base
savedmem_size
BUG=chromium-os:12522
TEST=manual:
. bring up a kaen system
. execute the following script to enable the appropriate GPIOSs:
for gpio in 56 59 168; do echo $gpio > /sys/class/gpio/export; done
. run `crossystem' and observe reasonable output values
. to verify that it reads GPIOs properly, try
echo $(./crossystem recoverysw_cur)
with the miniservo 'GOOG_REC' button pressed and released, observe
different readings (note that the state of the button is reversed,
the released button is reported as '1')
. to verify the write capabilities, note that the nvram contents can
be accessed using the following shell commands
echo 3 > /proc/sys/vm/drop_caches
2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && \
od -t x1 /tmp/blk | head -1
(the first command cause the device cache dropped, and the second
command accesses the device contents.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
localhost var # echo $(./crossystem fwb_tries)
10
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 0a 00 be 00 00 00 00 00 00 00 02 00 00 00 a2
localhost var # ./crossystem fwb_tries=9
localhost var # echo $(./crossystem fwb_tries)
9
localhost var # echo 3 > /proc/sys/vm/drop_caches
localhost var # 2>/dev/null dd if=/dev/mmcblk0 of=/tmp/blk bs=16 count=1 && od -t x1 /tmp/blk | head -1
0000000 60 09 00 be 00 00 00 00 00 00 00 02 00 00 00 8a
localhost var #
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Change-Id: Ie4c6ff44441d98a42b1057953208fdb90c08f46d
Reviewed-on: http://gerrit.chromium.org/gerrit/113
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Add the missing return statement to allow to tell between
different recovery reasons on legacy firmware.
Change-Id: I287e9d91dde040dd0edbe23422dc8914f81cc9f2
BUG=chromium-os:14295
TEST=manual
On a system with a chromeOS Flash USB drive plugged in:
- preserve currently running firmware
- corrupt both RW firmware sections
- restart the system (it comes up in recovery mode)
- login
- run `crossystem recovery_reason' and observe the result:
it used to print '66' before the fix, prints '3' after the fix.
- restore the firmware
Review URL: http://codereview.chromium.org/6879051
Change-Id: I1c4240ebe5783ca923c310061e2a76947aa6601b
R=reinauer@chromium.org
BUG=chromium-os:14030
TEST=manual
On a Mario:
crossystem fwupdate_tries=3
crossystem fwupdate_tries # should be 3
cat /mnt/stateful_partition/.need_firmware_update # should be 3
crossystem fwupdate_tries=0
crossystem fwupdate_tries # should be 0
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
On a newer platform:
crossystem fwupdate_tries=3
crossystem fwupdate_tries # should be 3
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
crossystem fwupdate_tries=0
crossystem fwupdate_tries # should be 0
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
Review URL: http://codereview.chromium.org/6825047
This should be ready for the ARM team to pick up and work on. I added
a placeholder ARM implementation file, though it's not hooked up in
the Makefile yet.
As soon as you implement the VbNvStorage APIs, all the related
crossystem commands will start working. Ditto for VbSharedData.
The params which x86 gets from ACPI you'll need to get from u-boot
somehow, probably via your own kernel driver.
R=robotboy@chromium.org
BUG=chromium-os:12522
TEST=emerge-x86-alex vboot_reference, make sure it still works on x86
Review URL: http://codereview.chromium.org/6780008
Change-Id: I628ee56508421b937ed50db7cb9b8385408d2f5e
