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: I3f158115c8514bda0b271674870d68717c4816e6
BUG=12282
TEST=manual
crossystem fwb_tries=0 && crossystem fwb_tries
This should print 0 on both BIOSes.
crossystem fwb_tries=6 && crossystem fwb_tries
This should print 1 on an older BIOS and 6 on a new BIOS (0050+)
Then reboot and run
crossystem mainfw_act
This should print 'B', since fwb_tries was non-zero.
Review URL: http://codereview.chromium.org/6576059
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
Note that both the current and boot settings are incorrect as reported
by the BIOS. This fixes both.
Change-Id: Iebd2b4ac91232444e538f6e2763a22cb227f2e4f
BUG=chrome-os-partner:2078
TEST=manual
Run crossystem on Mario and Alex with WP enabled, disabled and check
Verify true hardware WP status by doing:
flashrom --wp-enable
flashrom --wp-status
flashrom --wp-disable
flashrom --wp-status
On a system with hardware WP enabled, the disable step should fail and write
protect will still report enabled.
Review URL: http://codereview.chromium.org/6531035
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
