Still need to update gbb_utility and firmware to use the flags.
BUG=chrome-os-partner:2317
TEST=make && make runtests
Change-Id: I16c77a175c78efa3212a00bbf94d68384ef1829f
Reviewed-on: http://gerrit.chromium.org/gerrit/4817
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Try #2, now that ARM has the fix from http://gerrit.chromium.org/gerrit/4667
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Original-Change-Id: I2a52066f2889210af83409872b10f9d6380470af
(cherry picked from commit da55560cddcf7a1aa8a881cdf52792a21a01e766)
Change-Id: I120797145772116f09b8125b9e56fdbb11dc16b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4671
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This cleans up the TPM calls inside vboot_reference.
* TPM calls share mode code between boot modes.
* Better handling for TPM_E_MUST_REBOOT, particularly in recovery mode.
* TAB screen shows current TPM versions.
No changes required to the wrapper API; these changes are internal to vboot.
BUG=chromium-os:18084
TEST=make && make runtests; built for both alex and tegra2-seaboard
Change-Id: I2a52066f2889210af83409872b10f9d6380470af
Reviewed-on: http://gerrit.chromium.org/gerrit/4611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Now indicates it covers SD as well (it did already, but now it's clearer).
BUG=chromium-os:17907
TEST=run `crossystem`; look at new descriptions
Change-Id: I4e4d8502b0dc5a29eb403039535b7512941ab4fa
Reviewed-on: http://gerrit.chromium.org/gerrit/4408
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
BUG=chromium-os:17457
TEST=make && make runtests
When this is merged into an actual firmware build, can test it:
* dev switch off -> no dev screen, won't boot self-signed kernel
* dev switch on --> dev warning screen, will boot self-signed kernel
(e.g., it acts like the Cr-48)
Change-Id: I985428256e48b7e05dd4d8fe582a0c0103bf5fb2
Reviewed-on: http://gerrit.chromium.org/gerrit/3901
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
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 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>
BUG=chromium-os:16456
TEST=manual
To test: run dump_fmap with and without the '-p' option.
Without -p, the output looks like this:
area: 14
area_offset: 0x00110000
area_size: 0x000f0000 (983040)
area_name: RW_SECTION_B
area: 15
area_offset: 0x00110000
area_size: 0x00010000 (65536)
area_name: VBLOCK_B
With -p, the output looks like this:
RW_SECTION_B 1114112 983040
VBLOCK_B 1114112 65536
Change-Id: I53a3527fa92d22fef16563b0a950366a3a3db8a4
Reviewed-on: http://gerrit.chromium.org/gerrit/2545
Tested-by: Rajesh Chenna <rchenna@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The script needs to use proper device names when looking for
'hard drive' and USB storage. This change makes these names
platforms specific. Another change is to look for the USB device
when running off SSD and include it in report if found.
BUG=chromium-os:15896
TEST=manual
Ran dev_debug_vboot in the four permutations (on Alex or Kaen,
off USB or SSD), observed expected results reported, for instance
when running off USB stick on Kaen with a valid system installed
on the SSD partitions 2/4:
localhost chronos # dev_debug_vboot
Saving verbose log as /tmp/debug_vboot_IhtMvRsGt/noisy.log
Extracting BIOS image from flash...
Extracting kernel images from drives...
Extracting BIOS components...
Pulling root and recovery keys from GBB...
Verify firmware A with root key... OK
Verify firmware B with root key... OK
Test kernel_subkey_a.vbpubk... OK
Test kernel_subkey_b.vbpubk... OK
Test hd_kern_a.blob... OK
Test hd_kern_b.blob... OK
Test usb_kern_a.blob... OK
Verify hd_kern_a.blob with kernel_subkey_a.vbpubk... OK
Verify hd_kern_b.blob with kernel_subkey_a.vbpubk... FAILED
Verify usb_kern_a.blob with kernel_subkey_a.vbpubk... FAILED
Verify hd_kern_a.blob with kernel_subkey_b.vbpubk... OK
Verify hd_kern_b.blob with kernel_subkey_b.vbpubk... FAILED
Verify usb_kern_a.blob with kernel_subkey_b.vbpubk... FAILED
Verify hd_kern_a.blob with recoverykey.vbpubk... FAILED
Verify hd_kern_b.blob with recoverykey.vbpubk... FAILED
Verify usb_kern_a.blob with recoverykey.vbpubk... OK
exporting log file as /var/log/debug_vboot_noisy.log
On the same system after corrupting the SSD kernel:
localhost tmp # dev_debug_vboot
Saving verbose log as /tmp/debug_vboot_uLSfFS2g9/noisy.log
Extracting BIOS image from flash...
Extracting kernel images from drives...
Extracting BIOS components...
Pulling root and recovery keys from GBB...
Verify firmware A with root key... OK
Verify firmware B with root key... OK
Test kernel_subkey_a.vbpubk... OK
Test kernel_subkey_b.vbpubk... OK
Test hd_kern_a.blob... FAILED
Test hd_kern_b.blob... OK
Test usb_kern_a.blob... OK
Verify hd_kern_a.blob with kernel_subkey_a.vbpubk... FAILED
Verify hd_kern_b.blob with kernel_subkey_a.vbpubk... FAILED
Verify usb_kern_a.blob with kernel_subkey_a.vbpubk... FAILED
Verify hd_kern_a.blob with kernel_subkey_b.vbpubk... FAILED
Verify hd_kern_b.blob with kernel_subkey_b.vbpubk... FAILED
Verify usb_kern_a.blob with kernel_subkey_b.vbpubk... FAILED
Verify hd_kern_a.blob with recoverykey.vbpubk... FAILED
Verify hd_kern_b.blob with recoverykey.vbpubk... FAILED
Verify usb_kern_a.blob with recoverykey.vbpubk... OK
exporting log file as /var/log/debug_vboot_noisy.log
Change-Id: I4f4cd2377c6acf3db433d629ed0a5c43a5d1a76c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/1938
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* including fmap header in fmap areas
* initializing blobs by string value
BUG=chromium-os:15633
TEST=emerge-tegra2_{seaboard,kaen} chromeos-bios
Change-Id: Ib87a3f60fb11804888c4bc023d595629e017f589
Reviewed-on: http://gerrit.chromium.org/gerrit/1427
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
This change adds an additional (optional) section to the .yaml file which
can enumerate the names of the locales. If present, these names will be
appended to the end of the bmpblock and the (new) locale_string_offset field
in the BmpBlockHeader will point to it. The names are encoded as a series of
null-terminated ASCII strings. The end of the series is indicated by an
extra null (for example, "en_US\0fr\0\0" names two locales).
The BIOS does not use this information. Factory or OOBE could use it to
select the initiale locale for the BIOS screens from the list of locales
included in the BmpBlock.
BUG=chrome-os-partner:3868
TEST=none
Change-Id: I34fd9ece27343d56ec43772de975ac6f2ad7c9a6
Reviewed-on: http://gerrit.chromium.org/gerrit/1156
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Also add --pad as a valid option to --repack and --verify, so that
kernels with larger-than-normal padding can be verified.
BUG=chromium-os:13720
TEST=see bug 13720
Using the supplied kernel images from the bug,
vbutil_kernel --verify 007 --debug
vbutil_kernel --verify 008 --debug
These should now fail with an error that the key block extends past the padding.
Next, supply a large enough padding size that the key block and
preamble fit. For example:
vbutil_kernel --verify 007 --pad 0x900000 --debug
vbutil_kernel --verify 008 --pad 0x900000 --debug
These should now make it past the padding check, and fail on a
subsequent test (for example, no kernel blob found).
Change-Id: I7ec32b4def29970e302bf922b96d3e206d97fe82
Reviewed-on: http://gerrit.chromium.org/gerrit/810
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:3309
TEST=manual:
1. Extract a kernel partition from an image, for example, using
unpack_partitions.sh. Or if running this on a device, use /dev/sda2
or /dev/sda4 for the kernel filename.
2. vbutil_kernel --verify part_2
3. Note the data key version and kernel version printed. For example,
Data key version: 1
Kernel version: 3
4. Test specifying the same version. This should succeed.
vbutil_kernel --verify part_2 --minversion 0x00010003
5. Test specifying a higher data key version. This should fail with a
data key version error.
vbutil_kernel --verify part_2 --minversion 0x00020003
6. Test specifying a higher kernel version. This should fail with a
kernel version error.
vbutil_kernel --verify part_2 --minversion 0x00010004
Change-Id: I7b69041cf41527fc59ad29995135f30d9f496fac
Reviewed-on: http://gerrit.chromium.org/gerrit/792
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
With version 1.0, the BIOS displays its screens using composited images, but
we still have to create a new bmp image for every HWID. Version 1.1 lets us
render the ASCII HWID string directly, so the BIOS screens don't need
modification just because the HWID changes.
In the yaml file, we just replace the hwid image with a magic string, like
so:
bmpblock: 1.1
[...]
screens:
en_remove:
- [ 0, 0, remove_bg]
- [256, 534, en_model_text]
- [314, 534, $HWID]
- [192, 479, url]
- [195, 453, en_remove_text]
This change modifies the bmpblk_utility to accept and generate both 1.0 and
1.1 versions. It also updates the supporting scripts (most of which aren't
needed anymore) and adds a new DEFAULT.yaml file which can be used as the
basis for all locales.
BUG=chrome-os-partner:3264
TEST=none (manual)
Change-Id: I012349393848393928282
Reviewed-on: http://gerrit.chromium.org/gerrit/378
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@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
Two things here: Use mktemp to create a unique and new temporary directory
to work in, and copy the published log file to a known path in a way that
can't be redirected with symlinks.
There are also a couple of minor tweaks to cleanup a little bit rot in the
information that the script provides.
BUG=chromium-os:8947
TEST=manual
Boot, wait 60 seconds, look for "/tmp/debug_vboot_noisy.log". It should
exist and contain useful and interesting data.
Change-Id: Iff9c5c86802ab7fcf3342e82ba128a1795dba16d
R=rspangler@chromium.org,wad@chromium.org,gauravsh@chromium.org
Review URL: http://codereview.chromium.org/6824018
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
EntryWiped takes a byte value wipe_value of range [00:ff] as one of its
arguments that pack_firmware_image uses the value to "wipe" the entry.
R=yjlou@chromium.org
BUG=chrome-os-partner:3089
TEST=emerge-tegra2_seaboard chromeos-bios
Review URL: http://codereview.chromium.org/6799009
Change-Id: Ib2265caf5cfbd6d297465684e87f5a299cd4d043
(This helps us do some instrumented fuzz testing with "bunny the fuzzer".)
Change-Id: I4d06129d577115b9dd5cd9bec2c2e1b526490456
BUG=chromium-os:13690
TEST="CC=/usr/local/google/bunny-0.93/bunny-gcc make -k" now builds vbutil_*, and regular gcc/make did not break.
STATUS=Fixed
Review URL: http://codereview.chromium.org/6783006
This reverts commit bc7a84d9a1.
It was a false alarm that --kloadaddr causes chromeos-install on a
x86 targets to fail. The error of chromeos-install cannot be
reproduced, and judging by the reported error message, the error
should not be attributed to --kloadaddr, which has no effect in x86
targets. So --kloadaddr is restored.
Verification process are below:
(Verify that --kloadaddr option is restored)
$ dump_kernel_config -h
Expected argument after options
dump_kernel_config - Prints the kernel command line
Usage: dump_kernel_config [--kloadaddr <ADDRESS>] <image/blockdevice>
(Setup a x86 target with kernel-next profile)
$ rm -rf /build/${X86_TARGET}
$ ./setup_board --board=${X86_TARGET} --profile=kernel-next
$ ./build_packages --board=${X86_TARGET}
$ ./build_image --board=${X86_TARGET}
(Run chromeos-install on target machine successfully)
$ /usr/sbin/chromeos-install
(Change directory to where image sits)
$ cd ~/trunk/src/build/images/${X86_TARGET}/latest
(Unpack Chromium OS image)
$ ./unpack_partitions.sh chromiumos_image.bin
(Verify that dump_kernel_config runs successfully)
$ dump_kernel_config part_2
console=tty2 init=/sbin/init add_efi_memmap boot=local noresume noswap
i915.modeset=1 cros_secure kern_guid=%U tpm_tis.force=1
tpm_tis.interrupts=0 nmi_watchdog=panic,lapic i8042.nomux=1
root=/dev/dm-0 quiet loglevel=1 rootwait ro dm_verity.error_behavior=3
dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="vroot none ro,0 1740800
verity %U+1 %U+1 1740800 1 sha1
c357e07395150770ce25ebc0e3c6d15941675c58"
(Run load_kernel_test)
$ load_kernel_test -b 2 chromiumos_image.bin
/usr/share/vboot/devkeys/recovery_key.vbpubk
Read 2088 bytes of key from /usr/share/vboot/devkeys/recovery_key.vbpubk
bootflags = 6
Reading from image: chromiumos_image.bin
Ending LBA: 3989538
Read(1, 1)
Read(2, 32)
Read(3989506, 32)
Read(3989538, 1)
Read(4096, 128)
Read(4224, 6472)
LoadKernel() returned 0
Partition number: 2
Bootloader address: 4345856
Bootloader size: 16384
Partition guid: b2a453b0-a64a-5c4d-a957-1388cea384a5
R=marcheu@chromium.org,sjg@chromium.org
BUG=none
TEST=see verification process above
Review URL: http://codereview.chromium.org/6685079
Change-Id: I932753197550b853495f2c03e8880ad71df765a7
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
Firmware specification has several sections that are overlapped. This CL allows
limited overlapping that only "pure" fmap areas can be overlapped.
See also CL=6694022,6696016 for its application.
BUG=chrome-os-partner:2333
TEST=emerge vboot_reference && emerge-${ARM_BOARD} chromeos-bios
Review URL: http://codereview.chromium.org/6677040
Change-Id: I9ca34caec3665136b1babd08cd074cf733cf0d51
We need to also assign the target in dev_debug_vboot.
BUG=chromium-os:11339
TEST=flashrom -p internal:bus=lpc
dev_debug_vboot # still seeing success
Change-Id: I33cfed77dba5afb668f6d9036ecc077e3bcb19d0
R=wfrichar@chromium.org
Review URL: http://codereview.chromium.org/6698022
This reverts commit 1a0975f5f4.
This fixes chromeos-install on x86-mario with a kernel-next profile.
BUG=None
TEST=Build an x86-mario image with kernel-next, check that /usr/sbin/chromeos-install works.
Review URL: http://codereview.chromium.org/6677033
Change-Id: I67fc5c0f70a05a4d662952105542edf454da8022
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
