BUG=chromium-os:17433
TEST=make && make runtests. Additional manual tests:
0. Insert a valid dev-signed USB key.
1. Boot with dev switch off.
`crossystem dev_boot_usb` should print 0.
2. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Ctrl+U at dev screen should beep, but not boot USB.
3. Type `crossystem dev_boot_usb=1`. Should succeed.
`crossystem dev_boot_usb` should print 1.
4. Reboot system.
At the dev mode warning, press Ctrl+U
System should boot from USB key
`crossystem dev_boot_usb` should print 0.
5. Flip dev switch off.
`crossystem dev_boot_usb` should print 0.
6. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Note that this does not apply to Cr-48, Alex, or ZGB.
Change-Id: Idf85fdd642f38f531c89e5fa5b1679e84936d4da
Reviewed-on: http://gerrit.chromium.org/gerrit/3875
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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>
Change-Id: I836796c45849c03172f2a4947f39302616d03f1b
BUG=none
TEST=manual - run on test platform, see alphabetized variables.
Review URL: http://codereview.chromium.org/6877054
Change-Id: I649b0d745316acc38b5a121dfd1c353c475ac44a
R=reinauer@chromium.org
BUG=chromium-os:13204
TEST=manual
crossystem # should not print vdat_lfdebug and vdat_lkdebug
crossystem --all # should print them
Review URL: http://codereview.chromium.org/6824020
R=petkov@chromium.org
BUG=chromium-os:13322
TEST=manual
The following command lines should cause crossystem to fail with a
warning about a poorly formed parameter:
crossystem ''
crossystem '=cros_debug'
crossystem '?cros_debug'
The following command line should warn that you can't use both = and ?:
crossystem cros_debug?=0
(that is, it warns, not just compares with '=0')
The following should print 'UNEQUAL'
crossystem cros_debug? || echo UNEQUAL
(because it's comparing cros_debug with an empty string)
Review URL: http://codereview.chromium.org/6718012
Change-Id: I2e2851515f4914b16aba64065600fb92d9ad1a63
R=reinauer@chromium.org
BUG=chrome-os-partner:2578
TEST=manual
crossystem vdat_timers
should show 'LFS=0,0 LF=number1,number2 LK=number3,number4'
where number1 < number2 < number3 < number4
crossystem vdat_lfdebug
run from a dev mode console, should show
'check=12,0 index=0x00 tpmver=(hex number) lowestver=(hex number)'
crossystem vdat_flags
run from a dev mode console, flags should be 0x04.
Review URL: http://codereview.chromium.org/6685068
Change-Id: Id7b958ae300d10cdcdc1b17a1bb17b7e5069166f
This CL is a user space counterpart of
http://codereview.chromium.org/6690023, which provided the
ability to retrieve buffers through chromeos_acpi driver.
The buffer contents is communicated as a multi line string
with each buffer byte represented as a two symbol hex
number. `crosstool', on the other has to map the buffer
contents into a certain binary structure. This CL add
conversion of the multiline string into a binary buffer and
also adds a temp. routine to dump the buffer contents on the
screen when `crosstool' is invoked.
Change-Id: I8dd3eb935332f9bc8769c71de0db302365f12d70
BUG=chromium-os:13069, chromium-os:13091
TEST=manual
- Install the new image on a target with firmware providing
the VDAT ACPI method.
- Run crosstool and watch for the last line:
vdat = 11 22 33 44 ff 1f 1c 40 ff 57 74 41 ff ff ff ff # Raw VDAT contents.
localhost tmp #
Review URL: http://codereview.chromium.org/6695012
Change-Id: I35158810184be03f18d98893e4dd640088384579
BUG=12904
TEST=manual
crossystem fwb_tries=1
crossystem fwb_tries?1 && echo YES || echo NO --> YES
crossystem fwb_tries?0x01 && echo YES || echo NO --> YES
crossystem fwb_tries?0 && echo YES || echo NO --> NO
crossystem fwb_tries=0
crossystem fwb_tries?0 && echo YES || echo NO --> YES
crossystem fwb_tries?1 && echo YES || echo NO --> NO
crossystem fwb_tries?0x01 && echo YES || echo NO --> NO
crossystem ecfw_act --> RW (if it's not, change RW to RO in the tests below)
crossystem ecfw_act?RW && echo YES || echo NO --> YES
crossystem ecfw_act?BOB && echo YES || echo NO --> NO
For the following tests, boot Alex with dev switch on and fwb_tries=1
Expected output of `crossystem mainfw_type mainfw_act cros_debug` under each of the following scenarios:
* Neither "cros_debug" nor" cros_nodebug" in kernel command line: normal B 1
* Kernel command line changed to include "cros_nodebug": normal B 0
* Kernel command line changed to include "cros_nodebugg": normal B 1
* Kernel command line changed to include "ccros_nodebug": normal B 1
Review URL: http://codereview.chromium.org/6665005
Change-Id: Ie62364a87f7f144ee647054d2a9ef83522cdbe7d
BUG=12904
TEST=manual
Expected output of `crossystem mainfw_type cros_debug` under each of the following scenarios:
* Boot Alex with dev switch off: normal 0
* Boot Alex with dev switch on (and dev firmware): developer 1
* Boot Alex with dev switch on (and normal firmware): normal 1
* Boot Alex with recovery firmware: recovery 0
* Boot Alex with dev switch off, then turn the dev switch on after booting: normal 0
* Boot Cr-48 with dev switch off: normal 0
* Boot Cr-48 with dev switch on: developer 1
* Boot Cr-48 with recovery firmware: recovery 0
* Boot Alex with dev switch off and kernel command line changed to include "cros_debug": normal 1
* Boot Alex with dev switch off and kernel command line changed to include "cros_debugg": normal 0
* Boot Alex with dev switch off and kernel command line changed to include "ccros_debug": normal 0
* Boot H2O BIOS with kernel command line changed to include "cros_debug": nonchrome 1
* Boot H2O BIOS with kernel command line changed to include "cros_debugg": nonchrome 0
* Boot H2O BIOS with kernel command line changed to include "ccros_debug": nonchrome 0
Review URL: http://codereview.chromium.org/6659021
Fix try_b processing
And move key block flags check up in LoadFirmware(), which speeds up
boot when the dev switch is off because it doesn't do a signature
check and then throw it out.
BUG=12282
TEST=build firmware, try by hand
Review URL: http://codereview.chromium.org/6596081
Change-Id: I10474e9e0ae324906dfe02a351347d04ce847f67
1) Did firmware attempt RW slot B before slot A?
2) Did firmware check the kernel keyblock signature, or just its hash?
Added crossystem support as well.
BUG=chrome-os-partner:1657
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6597011
Change-Id: I0d743ae87cedd938ba988170793717d3fdbd8ce9
Change-Id: I37b42088f94ee838e0d82f155ab0674323d859fc
BUG=none
TEST=manual (run crossystem and see that it prints hex values for savedmem_base and fmap_base)
Review URL: http://codereview.chromium.org/6582004
Change-Id: If2106cbde445edc0970862a06d3837d2e466d9ef
BUG=chrome-os-partner:2487
TEST=manual
From a root shell, type: crossystem fmap_base
Should match the contents of /sys/devices/platform/chromeos_acpi/FMAP
(note that you need a new BIOS >0049 to get one that supports FMAP)
Review URL: http://codereview.chromium.org/6580037
crossystem now covers all data currently provided by chromeos_acpi.
Change-Id: I3364c4d65ddf63fe788d3d9c1e9d05e64be22856
BUG=chromium-os:12282
TEST=manual - test on Cr-48 and compare with ACPI values
Review URL: http://codereview.chromium.org/6557001
crossystem can now be used in place of reboot_mode.
BUG=12327
TEST=manual by comparing with the old reboot_mode utility
crossystem recovery_request=1
reboot_mode
crossystem dbg_reset=1
reboot_mode
crossystem fwb_tries=1
reboot_mode
crossystem recovery_request=0
reboot_mode
crossystem dbg_reset=0
reboot_mode
crossystem fwb_tries=0
reboot_mode
Review URL: http://codereview.chromium.org/6538066
Change-Id: Ifde661d4621129d52e757654d85e386e65f90df5
Works for getting switch positions, hwid, fwid.
BUG=chrome-os-partner:1940
TEST=ran manually on Mario and Alex
Review URL: http://codereview.chromium.org/6413002
Change-Id: I874df3b5adf872fec2d36e574cb4b8b4a72d331c
