In the unlikely case that params is not set or the LoadKernelParams
structure is not initialized correctly, LoadKernel will exit before
initializing shcall. However, in LoadKernelExit it will be used to
stire the function's return code, thus potentially dereferencing a
NULL pointer.
BUG=chrome-os-partner:6307
TEST=compile tested.
Change-Id: I691c6b5054d8f77296de86834b3125de06e0e398
Reviewed-on: http://gerrit.chromium.org/gerrit/9791
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
* Updated the text strings using the latest results from the localization
experts.
* Strip the leading byte-order-mark and trailing whitespace from the text
files, since it's not used for anything and sometimes renders as a box.
* Added options to the text_to_bmp script to handle right-to-left languages
and to override the font.
* Added scripts/newbitmaps/strings/localized_text/Makefile to regenerate all
the bitmaps from the text strings. This handles right-to-left languages
correctly.
* Modified make_default_yaml so that the th/model.txt string is moved up a
bit to align it properly with the HWID.
* Regenerated DEFAULT.yaml using the new bitmaps.
BUG=chromium-os:13037
TEST=none
Change-Id: I095830a46ba831742d437867a9caac88c8e28de1
Reviewed-on: http://gerrit.chromium.org/gerrit/8834
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This displays the gbb.flags value when being warned about it being nonzero.
It also decodes the recovery_reason value into English.
BUG=chromium-os:20972
TEST=manual
1. Use gbb_utility to create a BIOS with valid bitmaps, but with gbb.flags
set to a non-zero value. Boot into recovery mode. You should see the
warning that gbb.flags is non-zero, and the value itself.
2. Press TAB. The recovery_reason field should display not only a value, but
also an English string explaining the value.
Change-Id: I99b7aa35bc67453bdf3385b9573491090c3dec1d
Reviewed-on: http://gerrit.chromium.org/gerrit/8459
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
To prevent execution permissions lost after being copied to /tmp, force adding
a+rx to the staging file.
BUG=chromium-os:20797
TEST=sudo sign_official_build.sh ssd \
x86-zgb-0.16.1089.0.bin ../../tests/devkeys ssd_image.bin
Change-Id: Ibee12dbb3faea9f6b05600d1343620e0af8633fb
Reviewed-on: http://gerrit.chromium.org/gerrit/8263
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
BUG=none
TEST=manual
Booted in dev-mode. All noises and delays are unchanged (2 second delay when
gbb.flags is 1, 30-second with beeps at 20 seconds when gbb.flags is 0).
Change-Id: I816e57c4f8f6025299851b3d42b4a350f9925994
Reviewed-on: http://gerrit.chromium.org/gerrit/8240
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This enables us to support playing sounds in the background if the BIOS
allows it, so we don't have to block while beeping is happening. The new
declaration is:
VbError_t VbExBeep(uint32_t msec, uint32_t frequency);
If the audio codec can run in the background, then:
zero frequency means OFF, non-zero frequency means ON
zero msec means return immediately, non-zero msec means delay (and
then OFF if needed)
else:
non-zero msec and non-zero frequency means ON, delay, OFF, return
zero msec or zero frequency means do nothing and return immediately
The return value is used by the caller to determine the capabilities. The
implementation should always do the best it can if it cannot fully support
all features - for example, beeping at a fixed frequency if frequency
support is not available. At a minimum, it must delay for the specified
non-zero duration.
Currently, VbExBeep() is called only when displaying the dev-mode screen.
BUG=none
TEST=manual
I've tested on x86 and ARM, all timeouts and noises work as before.
Note that ARM and coreboot will require a corresponding change to their
VbExBeep() implementations, which will have to be handled with separate,
simultaneous CLs.
Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d
Reviewed-on: http://gerrit.chromium.org/gerrit/8234
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Work around the fact that we have 3 different verity kernel arguments depending
on the image being signed (legacy parameters, new key=value parameters, new key=
value parameters with salt).
Since the signer is not branch conscious, expect and use the old verity binary to
be present when legacy kernel arguments are specified. The last 2 types of verity
arguments can be distinguished based on whether a salt is present.
BUG=chromium-os:20640
TEST=manually tested by signing r14, r15 and r16 images and verifying
that kernel parameters are set correctly.
Change-Id: I96ecf6f506a94509a64ef12d7a108e977f94c23c
Reviewed-on: http://gerrit.chromium.org/gerrit/8214
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: David McMahon <djmm@chromium.org>
Tested-by: David McMahon <djmm@chromium.org>
This is again working around the fact that the signer isn't branch
conscious. Depending on which branch you look at, there are 3 possible
verity parameter styles in use.
This CL allows the kernel parameter test to allow multiple alternatives
for verity dm= parameters.
BUG=chromium-os:20640
TEST=manually tried with a R16, R15 and R14 image
Change-Id: I07554594d6adbdfd1988395d3e91edfd603d8cd4
Reviewed-on: http://gerrit.chromium.org/gerrit/8067
Reviewed-by: Jim Hebert <jimhebert@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
This changes the code accept x86.* as an alias for x86 architecture
since both x86 and x86_64 systems will handle things identically
BUG=chromium-os:20336
TEST=try to use update_kernel.sh on a system running an x86_64 kernel
Change-Id: Icf18925bdb8583cd53c6f6254c7493bdec540465
Reviewed-on: http://gerrit.chromium.org/gerrit/7873
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
BUG=chromium-os:17138
TEST=tested changes on vm8-m2, was able to successfully run au-generate.py
and it used the cgpt binary from au-generate.zip
Change-Id: Ia57f1be4b0d669cad430e51977cce6e26d704320
Reviewed-on: http://gerrit.chromium.org/gerrit/7796
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Eric Blake <eblake@chromium.org>
Tested-by: Eric Blake <eblake@chromium.org>
BUG=chrome-os-partner:5919
TEST=manual
Until the factory flow has completed, BIOS screens should display a warning
message about GBB.flags. This message should disappear once the flags field
is zero.
You can see the state of the GBB flags in a particular BIOS image using
gbb_utility -g --flags BIOS.bin
And set it with
gbb_utility -s --flags=VALUE BIOS.bin NEWBIOS.bin
Change-Id: I15d336bda571978ece0a9744f19d80f0ae385fb1
Reviewed-on: http://gerrit.chromium.org/gerrit/7719
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
To prevent hard-coding the procedure to repack a firmware updater, this CL
supports using new "--sb_repack" mode supported by updater so that signer does
not need to care about how the updater is packed anymore.
BUG=chromium-os:20027
TEST=./sign_official_build.sh ssd \
~/trunk/src/build/images/x86-zgb/latest/chromiumos_image.bin \
../../tests/devkeys \
~/trunk/src/build/images/x86-zgb/latest/chromiumos_new_image.bin
# success
Change-Id: I035dfaa86b05b85748e69ec039769b0c08d33f64
Reviewed-on: http://gerrit.chromium.org/gerrit/7311
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
There were some locale bitmaps displayed as question marks (like ???) due to
missing font with ImageMagick. Since we use Pango now, this CL updates the
bitmaps from those locales:
ar el fa hi iw ja ko th vi zh_CN zh_TW
BUG=chromium-os:13037
TEST=for X in ar el fa hi iw ja ko th vi zh_CN zh_TW; do
display $X; done
# all pictures looks fine - at least no question marks anymore
Change-Id: I4b4c443d6afb25cf603f3371a47677744ea9358d
Reviewed-on: http://gerrit.chromium.org/gerrit/7326
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Yaay, LoadFirmware() finally has unit tests!
Fix minor memory leak in LoadFirmware().
BUG=chromium-os:17564
TEST=make && make runtests
Change-Id: I7eabc14484271f488b77f286e846781ccc22b8f2
(cherry picked from commit 2b7c5635d7069c55a1d96d11b99d02291b7e308b)
Reviewed-on: http://gerrit.chromium.org/gerrit/7052
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
... instead of using hard-coded 192 constant.
BUG=chromium-os:19876
TEST=manual
If crossystem still reports correct values for devsw_cur recoverysw_cur (and
maybe wpsw_cur, although that's a separate bug), then it works.
Change-Id: Id8d4fb389bfd78f40da9ef08aa372071d77cbec1
Reviewed-on: http://gerrit.chromium.org/gerrit/7014
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The --flags is added to get/set the "flags" field.
BUG=chrome-os-partner:2317
TEST=gbb_utiltiy --get --flags bios.bin # see flags as 0
gbb_utility --set --flags=0x3052 bios.bin
# for version error message for GBB1.0 files,
# and see flag value changed for GBB1.1+ files
gbb_utility --get --flags bios.bin
# flag as 0 for GBB1.0, 0x3052 for GBB1.1+
Change-Id: I7aab62c8fc32ea08b4822e496f543511ff5e5ebc
Reviewed-on: http://gerrit.chromium.org/gerrit/6721
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BUG=chromium-os:18631
TEST=manual
Boot to recovery mode screen. HWID should be the same size and shape as the
rest of the text.
Change-Id: Iee0b0611c1319a304d911b710dd7f35ef999a1eb
Reviewed-on: http://gerrit.chromium.org/gerrit/6667
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The vboot_api.h doesn't require the BIOS display the ASCII HWID in
a graphical form (ARM U-Boot doesn't know how), so we have to do it
ourselves. This change makes that possible.
Summary of changes:
* bmpblk_font.h defines a structure to map ASCII chars to BMPs
* bmpblk_font utility generates that font structure
* bmpblock format is bumped to version 1.2
- YAML file specifies font to use for $HWID
- make_default_yaml updated to emit the new format
- README updated to describe the difference
BUG=chromium-os:18631
TEST=manual
I've tested this on ARM, like so:
Inside the chroot, build a U-Boot that uses it:
emerge-tegra2_kaen vboot_reference vboot_reference-firmware
emerge-tegra2_kaen tegra-bct tegra2-public-firmware-fdts \
chromeos-u-boot chromeos-bootimage
Outside chroot, but in src/platform/vboot_reference:
make
<copy ./build/utility/bmpblk_font and ./build/utility/bmpblk_utility to
somewhere in your $PATH>
make clean
cd scripts/newbitmaps/fonts
bmpblk_font --outfile ../images/hwid_fonts.bin outdir/*
cd scripts/newbitmaps/images
make arm
cd out_arm
<edit DEFAULT.yaml>
bmpblk_utility -z 2 -c DEFAULT.yaml arm_bmpblock.bin
<use gbb_utility to replace the bitmaps in the U-Boot image, boot it>
The HWID string is displayed.
Change-Id: I782004a0f30c57fa1f3bb246e8c59a02c5e9f561
Reviewed-on: http://gerrit.chromium.org/gerrit/6544
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Also fixes returned value from Memset(). And SafeMemcmp() should
return 0 (equal) if comparing 0 bytes, to match the behavior of memcmp().
BUG=chromium-os:17564
TEST=make && make runtests
Change-Id: Id43e70eecf04815216e1fd952271af35e0a66396
Reviewed-on: http://gerrit.chromium.org/gerrit/6539
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The current bmpblock_utility doesn't preserve the order of images as
specified in the config yaml file. This doesn't affect the
functioning of the firmware, but does break this overly-restrictive
test.
Filed crosbug.com/19541 to fix this after Bill's current refactoring.
BUG=chromium-os:19541
TEST=make && make runtests
Change-Id: I03fe817bd191fec5f65aad37561a3224b6a2b1e6
Reviewed-on: http://gerrit.chromium.org/gerrit/6512
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
bmpblk_utility correctly supports this field, which can be used by the
factory process to map the localization to the correct locale. We forgot to
put the entries in the DEFAULT.yaml file. This change corrects that for
future releases.
BUG=none
TEST=none
Change-Id: Iea65d7439e6ef8cc8730ec1b862abba87041d93f
Reviewed-on: http://gerrit.chromium.org/gerrit/6424
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This refactoring will enable us to test and mock them separately from the
rest of the vboot_api functions.
BUG=chromium-os:17564
TEST=manual
Built for ARM, ran "vbexport_test display" at U-Boot prompt. Still works.
Change-Id: I2ddb01d3e981603f371aaa7317184457bdff48ac
Reviewed-on: http://gerrit.chromium.org/gerrit/6422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The vboot library needs to decompress the images so that it can handle those
that are special cases (like rendering the HWID). This means that 1) it
needs access to the BIOS' native decompression routine, and 2) that
VbExDisplayImage() only needs to handle the uncompressed native-format image
and doesn't need to know about how the image is packed in the GBB.
BUG=chromium-os:19134
TEST=manual
This requires a change to vboot_api.h, which requires a (simultaneous)
matching change to the BIOS, at least for U-Boot, which builds separately.
I've made that change and run the "vbexport_test display" command from the
modified U-Boot, but that also requires a change to the way U-Boot is built
so that I can get at the U-Boot commandline.
Change-Id: I449fb467cd3a68e742f27ec41b95d52685459d89
Reviewed-on: http://gerrit.chromium.org/gerrit/6129
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
The firmware image packing is now done by cros_bundle_firmware of
cros-devutils package, and we may retire pack_firmware_image.
BUG=none
TEST=emerge vboot_reference && [ ! -x /usr/bin/pack_firmware_image ]
Change-Id: I177508bf8aada822535fe61258cd1a0df52bfac6
Reviewed-on: http://gerrit.chromium.org/gerrit/5979
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
