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>
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>
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>
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
