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
Kernel body load address was hard-coded to CROS_32BIT_ENTRY_ADDR, which
could be an invalid/unavailable memory location on other platforms.
This CL adds an option for setting the load address, and it is default to
CROS_32BIT_ENTRY_ADDR to maintain backward-compatibility.
BUG=chromium-os:1304
TEST=emerge vboot_reference successfully
Review URL: http://codereview.chromium.org/6651022
Change-Id: I158cfce10ac59bd019bca41cb061039d0085d5cc
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
Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60
BUG=chrome-os-partner:1657
TEST=manual - see below
make && make runtests
Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified)
build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin
build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk
And make sure the firmware with this change actually boots to USB and SSD.
NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change
Review URL: http://codereview.chromium.org/6626045
Make dev_debug_vboot look first for the new section names, then the old ones.
Change-Id: I723f022bbbb23257c7c57db9543d7c35f524f95d
BUG=chromium-os:12611
TEST=manual
Rerun the steps that reproduce the problem as reported in the initial bug
report. You should see much more information.
Review URL: http://codereview.chromium.org/6621003
(somehow that never got committed)
Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38
BUG=12282
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6610019
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
Change-Id: I19f402904978581eb5ca990ffbdf2f762b48c217
BUG=12282
TEST=make H2C firmware and verify using crossystem utility
(set fwb_tries, reboot, verify that mainfw_act is B)
Review URL: http://codereview.chromium.org/6597018
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
When --arch flag is not x86, x86-only operations in pack mode are
turned off so that we can reuse vbutil_kernel to generate kernel partition
images for other targets, such as arm.
See CL:6538014 for its application.
BUG=chromium-os:3790
TEST=Run "emerge vboot_reference" successfully
Review URL: http://codereview.chromium.org/6538015
Change-Id: If45cf092d1ecc762fad6fda1aa57d23e26a7e47a
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
BUG=chromium-os:11490
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ia887fc1aa1de873c6da6c04995bc0a9ad6b364aa
Review URL: http://codereview.chromium.org/6541001
