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
BUG=chromium-os:12161
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ic7708474ce7009744c9f12154d1967bdae8e55d2
Review URL: http://codereview.chromium.org/6534025
This ensures that equivalent yaml files produce identical bmpblock binaries.
BUG=chromium-os:12158
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ic8103ff90e57034d72fb3920a6c198c77768f162
Review URL: http://codereview.chromium.org/6533012
LZMA has better compression ratio and is also supported in u-boot already.
ARM BIOS will use LZMA to compress BMP files.
BUG=chromium-os:11017
TEST=manual
$ make
$ make runbmptests
Change-Id: I6b791e3284b65eb3085b0de548bd241eab2ee598
Review URL: http://codereview.chromium.org/6523019
This lets bmpbklk_utility generate BMPBLOCKs with EFIv1-compressed bitmaps.
It also adds the ability to display or unpack BMPBLOCK blobs.
The compression/decompression routines come from the tianocore EDK on
sourceforge and are written in C, so now there's a mix of C and C++, but it
works just fine.
BUG=chromium-os:11491
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Review URL: http://codereview.chromium.org/6508006
Change-Id: Ie05e1a3fd42f4694447c8c440b2432af4ac0f601
BUG=chromium-os:11017
TEST=use RLE BMP files as input to run bmpblk_utility
Change-Id: I2398d1c6cb9d5f90a85d8bfcab0af6e41a52b022
Review URL: http://codereview.chromium.org/6489026
This is work-in-progress. More tests to come...
Change-Id: Id2e59fd7d0229be3ad90b29b2d0dc035ceeca666
BUG=chromium-os:11766
TEST=manual
Adding an example to the test framework. Use
make
make runbmptests
to ensure it works.
Review URL: http://codereview.chromium.org/6286157
BUG=chromium-os:11742
TEST=manual
Check out sources, run:
cd src/platform/vboot_reference
make
make runbmptests
It should pass.
Change-Id: I50ebdef26662e7446828315a3f5e2786624508b9
Review URL: http://codereview.chromium.org/6246150
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
This replaces http://codereview.chromium.org/6307007. The only difference is
the Makefile. The vboot_reference ebuild has been changed so that we only
attempt to build bmpblk_utility on the host.
Change-Id: I4902703baba155e0d2d7646d19b233aa695c282f
BUG=chromium-os:11017,chromium-os:10599
TEST=none
No test needed. If buildbot is green, it's verified.
Review URL: http://codereview.chromium.org/6334111
Revert "This change define the data structure of bmp block and implements the create more of bmpblk_utility. It reads a YAML config file, parse the informations, and creates bmpblock file as output."
This reverts commit 95b0ae01ea.
BUG=none
TEST=emerge-x86 vboot_reference
TBR=waihong@chromium.org
Change-Id: If1692ca12ddb61b7814ca7dddccee5a395c8bed1
The list mode and extract mode will be implemented later.
Change-Id: I2b34b323814b1d6b0a369b0e4b2bfa7cf960ff4a
BUG=chromium-os:11017
TEST=build and run, use bvi to check its output.
Review URL: http://codereview.chromium.org/6307007
