BUG=chrome-os-partner:3698
TEST=manual
1. Run the firmware key/version autoupdate test; this rolls forward your stored TPM version numbers.
2. Put back the original firmware.
3. Reboot.
4. Press TAB at recovery screen.
5. Should see Recovery Reason 0x14.
Change-Id: I7791f594dbd8919e74d1e6b97b99775cf1e73d1d
Reviewed-on: http://gerrit.chromium.org/gerrit/567
Reviewed-by: Bill Richardson <wfrichar@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>
BUG=chromium-os:14904
TEST=manual:
./create_new_keys.sh
verify that keys are created
edit key.versions to change versions to 10 20 30 40
./create_new_keys.sh
verify that keys are created with versions from the file
Change-Id: I459018267883557237ab4cc0de9b443242739346
make_dev_ssd is a powerful command bug may confuse developers by its behavior.
Adding sanity checks can prevent developers throwing their system into
un-bootable ste.
BUG=chromium-os:14219
TEST=./make_dev_ssd.sh -i some_images; # no check, pass
./make_dev_ssd.sh # see alert for live partitions
(with non-developer firmware) ./make_dev_ssd.sh --partitions 2 # seeing firmware warning
(with developer firmware) ./make_dev_ssd.sh --partitions 2 # pass, no warning
(with dev-signed normal firmware) ./make_dev_ssd.sh --partitions 2 # pass, no warning
./make_dev_ssd.sh -f # seeing 5 second condown alert screen and then continue
Change-Id: I7ae134c03899b2dc4a6d95f6d9091c38e6f8cf65
R=rspangler@chromium.org
Review URL: http://codereview.chromium.org/6870026
Also adding support for the xx-YY variants to the make_yaml_from_hwids
script, which required that I rename those directories from xx-YY to xx_YY.
Providing a default locale ordering for all locales, which is roughly
geographical.
Change-Id: I4919728a0a876b649cef9dec3a023d0263efe794
R=rspangler@chromium.org
BUG=chromium-os:13037
TEST=none
Review URL: http://codereview.chromium.org/6878074
Change-Id: I836796c45849c03172f2a4947f39302616d03f1b
BUG=none
TEST=manual - run on test platform, see alphabetized variables.
Review URL: http://codereview.chromium.org/6877054
Add the missing return statement to allow to tell between
different recovery reasons on legacy firmware.
Change-Id: I287e9d91dde040dd0edbe23422dc8914f81cc9f2
BUG=chromium-os:14295
TEST=manual
On a system with a chromeOS Flash USB drive plugged in:
- preserve currently running firmware
- corrupt both RW firmware sections
- restart the system (it comes up in recovery mode)
- login
- run `crossystem recovery_reason' and observe the result:
it used to print '66' before the fix, prints '3' after the fix.
- restore the firmware
Review URL: http://codereview.chromium.org/6879051
Developers may turn on developer switch, enter shell, and then try to run
make_dev_ssd without switching to developer firmware / dev root key.
And that would make the system showing "NO GOOD" or "INSERT" screen
after reboot.
For sanity check, we should check if firmware type is "developer" before running
make_dev_ssd.
BUG=none
TEST=(using normale firmware) make_dev_ssd # seeing the error messages
sudo chromeos-firmwareupdate --mode=todev; sudo reboot
(using developer firmware) make_dev_ssd # not seeing error
Change-Id: Id62959c91c39b0bbcca604c9e83fd087e3727b8b
R=rspangler@chromium.org
Review URL: http://codereview.chromium.org/6840047
Change the boot default option in partition 12 (ESP) when we want to disable
rootfs verification.
BUG=chromium-os:12424
TEST=./make_dev_ssd --remove_rootfs_verification --recovery_key -i USB_IMAGE
# the image is bootable by H2C and H2C BIOS(EFI).
# Not tried on non-EFI (syslinux) firmware, but it should work.
Change-Id: I7533bb73597041bbdc8cc57e4e8baaf6ca242309
R=wfrichar@chromium.org
Review URL: http://codereview.chromium.org/6813109
When we do perform firmware updates, we'd like to change the kernel subkey to ensure that new firmware and Chrome OS image stay in sync. This CL adds a scripts which makes it possible to do this revving in an automated manner.
The current versions rollback versions corresponding to the keyset are stored in key.versions. If we change the kernel subkey (to enforce firmware/Chrome OS lockstep), we must also update the firmware version. Similarly, since we modify the kernel subkey, we also generate a new set of kernel data keys. Thus, we also increment the kernel key version.
Change-Id: I364ab50bda115991dd4f69331d37291f66abbf36
BUG=chrome-os-partner:3274, chromium-os:8016
TEST=Manually tested using a newly generated keyset.
Review URL: http://codereview.chromium.org/6824059
Change-Id: I1c4240ebe5783ca923c310061e2a76947aa6601b
R=reinauer@chromium.org
BUG=chromium-os:14030
TEST=manual
On a Mario:
crossystem fwupdate_tries=3
crossystem fwupdate_tries # should be 3
cat /mnt/stateful_partition/.need_firmware_update # should be 3
crossystem fwupdate_tries=0
crossystem fwupdate_tries # should be 0
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
On a newer platform:
crossystem fwupdate_tries=3
crossystem fwupdate_tries # should be 3
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
crossystem fwupdate_tries=0
crossystem fwupdate_tries # should be 0
cat /mnt/stateful_partition/.need_firmware_update # should complain file doesn't exist
Review URL: http://codereview.chromium.org/6825047
There are lots of new and changed files here, but they're mostly localized
text strings and prerendered bitmaps of them.
There are a few that still need rendering by hand. These locales don't work
with ImageMagick:
ar el fa hi iw ja ko th vi zh-CN zh-TW
Change-Id: I1777f985460d46d5aedbb3fbc2fd3c159439c454
R=rspangler@chromium.org
BUG=chromium-os:13037
TEST=none
Review URL: http://codereview.chromium.org/6825032
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: Icf9abbff05f9b29664216079b5c008cb7906a4f6
BUG=chrome-os-partner:3229
TEST=manually on an image.
Review URL: http://codereview.chromium.org/6813047
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
This should be ready for the ARM team to pick up and work on. I added
a placeholder ARM implementation file, though it's not hooked up in
the Makefile yet.
As soon as you implement the VbNvStorage APIs, all the related
crossystem commands will start working. Ditto for VbSharedData.
The params which x86 gets from ACPI you'll need to get from u-boot
somehow, probably via your own kernel driver.
R=robotboy@chromium.org
BUG=chromium-os:12522
TEST=emerge-x86-alex vboot_reference, make sure it still works on x86
Review URL: http://codereview.chromium.org/6780008
Change-Id: I628ee56508421b937ed50db7cb9b8385408d2f5e
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
Adding --recovery_key enables make_dev_ssd to process recovery images (including
USB bootable images).
R=gauravsh@chromium.org
BUG=chromium-os:12424
TEST=./make_dev_ssd.sh --remove_rootfs_verification --recovery_key -i /dev/sdd
# then use the USB to boot on a H2C device - success.
Review URL: http://codereview.chromium.org/6799007
Change-Id: Ie983f08ff8eba9472800b2f4097915ce380a0c50
This should let the signer catch errors where there are errors parsing verity output. And failing verification if rootfs hash verification is turned off for whatever reason.
Change-Id: I1e3f239a5b6afab31accdd8f0a737b8685530e8d
BUG=chrome-os-partner:3093, chrome-os-partner:3104
TEST=manually on a badly signed image (verification fails now)
Review URL: http://codereview.chromium.org/6720043
(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
To make the output of kernel_config from make_dev_ssd more close to the original
images, we should eliminate the trailing newline/space.
BUG=chromium-os:13516
TEST=make_dev_ssd.sh # succcess
Change-Id: I17f030f8815dea22b04058456d98db6911888ef6
R=rspangler@chromium.org,clchiou@chromium.org
Review URL: http://codereview.chromium.org/6735009
The script to resign firmware (resign_firmwarefd.sh) has changed its syntax, due to the new "dev
firmware" design.
BUG=chromium-os:13375
TEST=./make_dev_firmware.sh
# seeing the "changed firmware to Developer Keys" message.
Change-Id: Id553f3ce1641f13e732bd5e208cb2fb00ca9c078
R=rspangler@chromium.org,gauravsh@chromium.org
Review URL: http://codereview.chromium.org/6727019
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
A convenient value that firmware to identity the blank screen.
TEST=emerge-tegra2_seaboard vboot_reference-firmware successfully
BUG=chromium-os:1305
Change-Id: Ib38f0c5ba571e95c966ae58c81d22487e416e666
R=clchious@chromium.org
Review URL: http://codereview.chromium.org/6712029
