This is required for U-Boot's sandbox test system.
BUG=chromium-os:16808
TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario
Change-Id: I18b48b069dc56f9b2c826de99780dfff1e544ded
Reviewed-on: https://gerrit.chromium.org/gerrit/5980
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The Makefile requires a few defines and isn't very friendly if they are
missing. This adds some warnings which should alert as to what is wrong.
BUG=chromium-os:16808
TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario
Change-Id: Id3b20365cfcc7f0aa7d984b33b6a0906ae0d44a5
Reviewed-on: https://gerrit.chromium.org/gerrit/11548
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Based on the compile-time constants, I don't think we were in any danger,
but I've added the checks anyway. It never hurts to be certain!
BUG=chromium-os:22786
TEST=none
Change-Id: I469dda19b4589e484a41ca9bae1e107787f3cf4d
Reviewed-on: https://gerrit.chromium.org/gerrit/11516
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
As shipped, H2C only loads the option ROM for the built-in video, and that
only when it needs display the BIOS warning screens.
By setting a flag in the GBB, you can allow all option ROMs to be loaded:
Note that we'll never enable this ourselves (and there's a factory test to
ensure that*) because it executes non-verified code. But if a customer wants
to void their warranty and set this flag in the read-only flash so they can
install and use other PCI devices, they should be able to do so.
BUG=chrome-os-partner:6148
TEST=none
The only way to test this is to use a BIOS that was compiled with serial
debugging enabled, so there's nothing for QA to do. If you have such a BIOS,
you can see the difference like so:
flashrom -r oldbios.bin
gbb_utility -s --flags=2 oldbios.bin newbios.bin
flashrom -w newbios.bin
<reboot>
When bit 1 of the GBB flags is 0, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
When bit 1 of the GBB flags is 1, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!!
This happens in any boot mode (normal, developer, recovery).
--
*The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in
src/platform/factory_test_tools
Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a
Reviewed-on: https://gerrit.chromium.org/gerrit/11505
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Although we're now using a single unified BIOS, it is pretty nice to be able
to get a shell in developer mode while still using verified boot for the
kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode
user to install a special dev-mode BIOS. We don't do that, but we DO require
setting a special flag with "crossystem" to accomplish the same thing.
In order to allow booting a self-signed kernel, you must boot in developer
mode, open a shell, and run this:
crossystem dev_boot_custom=1
Special note to internal developers: If you're in the habit (as I am) of
booting directly from a USB stick in dev-mode, you'll have to run this:
crossystem dev_boot_custom=1 dev_boot_usb=1
Just using dev_boot_usb=1 is no longer enough, because the USB kernel is
signed using the recovery key and by pressing Ctrl-U, we validate it with
the kernel data key. That worked before this change because any self-signed
kernel was fine, and that's how the USB key was treated. Now it actually
requires a verified signature until you enable dev_boot_custom=1 also.
BUG=chrome-os-partner:5954
TEST=manual
Boot once in normal mode, which clears the special flags. Then switch to
developer mode. You should be able to boot and get a root shell.
Run
crossystem dev_boot_usb=1
Obtain a USB recovery image that's keyed differently. For example, if you're
testing with dev-keys, use a PVT-signed image or vice-versa.
Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode
screen, press Ctrl-U. You should hear a single beep, but it should not boot.
Press Ctrl-D to boot from the hard drive, log in to a shell and run
crossystem dev_boot_custom=1
Repeat the previous test. This time when you press Ctrl-U, it should boot
the recovery image. Turn the system off before it does anything.
That's it.
Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69
Reviewed-on: https://gerrit.chromium.org/gerrit/11442
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- loop unrolling has a positive effect on execution speed.
- This change also drops the -march=i386 and thus allows
the compiler to use SSE instructions.
- A few duplicate options are dropped from CFLAGS.
- drop -fno-toplevel-reordering. This sneaked in from
u-boot where it might be needed by some drivers.
With this change I just successfully booted my Stumpy in 833ms
BUG=chrome-os-partner:4675
TEST=boot tested on stumpy
Change-Id: I805cbcaec48b4f8d1d8fa7d7bed9241178f59a8e
Reviewed-on: https://gerrit.chromium.org/gerrit/11061
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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>
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>
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>
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>
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>
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>
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>
This is OFF by default, and must be turned on via the gbb_utility.
BUG=chrome-os-partner:2317
TEST=manual
Build a firmware image and flash it. Should have the same 30-sec
delay as it does now. Pressing TAB should show GBB flags = 0x0.
Modify the firmware image using gbb_utility to set GBB flags to 1 and
reboot. Dev delay should be 2 sec. Pressing TAB should show GBB
flags = 0x00000001.
Change-Id: If96ab9e7d0d142a9cd9a2c6af3849421d073de5e
Reviewed-on: http://gerrit.chromium.org/gerrit/4829
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
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>
When we're trying a new firmware B with a new kernel subkey, if it
can't find any kernels there may still be a kernel which the old
firmware A likes. So instead of going to recovery mode, just reboot
so we fall back to firmware A. If firmware A doesn't find any valid
kernels we'll still go to recovery mode.
BUG=chrome-os-partner:1657
TEST=manual:
Do a firmware+OS update which involves kernel subkey rotation. After
installing the new firmware but before rebooting into the new OS,
corrupt the new kernel so that it'll fail validation. Then reboot.
On previous firmware, this would go to recovery mode. Now it should
simply reboot and be back in firmware A / kernel A.
Change-Id: I12796f428fd6969ea5ef36f39c4f58cb0a2bff0d
Reviewed-on: http://gerrit.chromium.org/gerrit/4770
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
When compiling for coreboot the printf format helpers are not
available (they come from the Insyde tree).
The specifier is use in a very limited number of places, it is
probably better to typecast the variable being printed to avoid
compilation errors. This CL accomplishes just that.
BUG=none
TEST=manual:
run the following commands:
emerge-x86-alex -C sys-boot/chromeos-coreboot \
sys-boot/chromeos-u-boot\
chromeos-base/vboot_reference \
chromeos-base/vboot_reference-firmware
emerge-x86-alex chromeos-bootimage
observe the second one succeed.
Change-Id: If19e3a583eb759ba5a21863d1b9b28636c7f00b0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4690
This also fixes one place where TPM error codes were getting lost.
BUG=chromium-os:18132
TEST=make && make runtests
Change-Id: I83c74e1103805f166d1dc7448be7d67bd46d15b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4659
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-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>
Add recovery reason for already in recovery and need to reboot to
recovery to let the TPM init.
Add vboot_struct fields.
Fix type for keyblock flags param to SetTPMBootModeState().
BUG=none
TEST=make && make runtests
Change-Id: I4035bdb377aaebaca03a43799be57977166da739
Reviewed-on: http://gerrit.chromium.org/gerrit/4599
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
