This adds a flag to the list of values returned by VbInit(). When
this flag is set, the BIOS may be asked to boot something other than
ChromeOS. If this requires some sort of special preparation, the BIOS
should do it.
BUG=chromium-os:22454
TEST=none
There is no test for this. It requires a change to the BIOS in order
to do anything differently, and we haven't yet decided whether the
BIOS should pay attention to it.
Change-Id: I5d89e7cd5b745ee74b8ace7fa613c0db03eebefd
Reviewed-on: https://gerrit.chromium.org/gerrit/11714
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
VbCmosWrite should seek to correct offset before starting to write;
also fixed file handle leakage.
BUG=chromium-os:23000
TEST=crossystem recovery_request=1; echo $? # show: 0
crossystem recovery_request # show: 1
reboot # see recovery screen
Change-Id: I33bca8af2b351ba9b364309838df699a31bb543a
Reviewed-on: https://gerrit.chromium.org/gerrit/11756
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
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>
Many of the compile flags are common between archs, so this makes that
more obvious.
BUG=chromium-os:16808
TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario
Change-Id: I62bfbaadac392e3dd03d6997f24055fafac162af
Reviewed-on: https://gerrit.chromium.org/gerrit/11549
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>
A legacy checksum in CMOS is not maintained by coreboot and may be invalid. If
the Linux kernel driver sees that the checksum is wrong, it will return EIO
when read from or written to. That makes crossystem return an error since it
can't read the CMOS, and it also prevents it from changing some settings.
One way to fix the problem would be to remove the checksum check in the kernel
driver. This would change the semantics of the driver so that either x86 was
inconsistent with the other architectures, or change the semantics of those
other architectures as well.
Another option would be to fix the checksum during manufacturing since nothing
should be changing those particular bytes of CMOS. The problem with this
approach is that something might corrupt the CMOS after manufacturing, and
we'd have the same problem again.
Yet another solution would be to make the firmware, most likely coreboot,
actually keep the checksum up to date. This seems like an awful waste of boot
time, the bytes protected by the checksum aren't actually used by anything,
and the bytes of the CMOS that are used are protected by vboot using its own
checksum.
The solution implemented here is to make crossystem recognize when the driver
has determined that the checksum is invalid and make it call an ioctl that
gets the driver to fix the checksum. Wrapper functions for fread, fwrite,
fgetc, and fputc are implemented which first attempt to read or write, on
failure check for the EIO error code, and if they find it to call the
appropriate ioctl and attempt the access again. This way, we won't take any
extra time to talk to the CMOS when everything is working properly, and when
there's a problem it gets fixed up transparently. One problem with this
approach is that using the /dev/nvram device file will still fail until
crossystem is run at least once and given a chance to fix the checksum.
BUG=chrome-os-partner:6718
TEST=For version 1, verified that crossystem reported an error on Sameer's
Lumpy. Used strace to verify that crossystem received an EIO error when trying
to read or write /dev/nvram. Built a new image with this change and booted it
using a USB stick. Ran crossystem and verified that crossystem no longer
reported an error. Rebooted into the original image and verified that
crossystem worked there as well, indicating that the persistent problem in the
CMOS had been corrected.
For version 2, the same as version 1 except that I used a custom version of
u-boot to purposefully corrupt the CMOS rather than using Sameer's Lumpy.
Change-Id: I929535bd2a7d666e41a707b6b24c3f0b0df1147f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11373
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
This new version adds a bunch more output, displays the TPM rollback version
values (if it can; Cr-48 doesn't export this info through crossystem), looks
for and validates all kernels on all devices, etc.
It also add some command-line arguments to use to examine files containing
BIOS, kernel, and disk images.
BUG=chromium-os:6676
TEST=manual
Boot, wait a minute or so, then log in and go to chrome://system
Click the Expand button for "verified boot". You should see a bunch of
useful text describing the firmware and kernel partitions.
I tried this on Cr-48, Stumpy, and Kaen.
Change-Id: I2d9aa0fcb0c12cf2b951ce9e2316b89532901125
Reviewed-on: https://gerrit.chromium.org/gerrit/11327
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
We should have been using Droid Sans, not Helvetica, and some of the
non-Roman locales need special handling to render clearly and correctly. We
also get better results if we avoid scaling after rendering the text.
Added scripts/newbitmaps/Makefile to regenerate it all, updated the READMEs.
Since Hung-Te figured out how to use pango-view to render the UTF-8
reliably, we don't need to keep all the pre-rendered locale images anymore
either.
This provides the x86 bmpblock for Stumpy PVT. We may need some more
tweaking for Lumpy and/or ARM.
BUG=chrome-os-partner:6595
TEST=manual
Put the new screens into the bios:
gbb_utility -s --flags=0 -b bmpblock_x86.bin OLDBIOS NEWBIOS
flashrom -w NEWBIOS
Then reboot and look at the BIOS screens. The lettering is much clearer.
Change-Id: Icb07bc6d131920730f41348c7de9151e42cc9518
Reviewed-on: https://gerrit.chromium.org/gerrit/11007
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@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>
BUG=chrome-os-partner:6595
TEST=manual
User our new officially finally final localizations for Stumpy.
Start by removing some of the subtle speckles from the background images so
they'll compress a little better, then modify the Makefile to autogenerate
the bitmap blob (for x86, anyway).
Note: the size improvment isn't much, but every little bit helps. With all
43 locales, bmpblock.bin was 659798 bytes. Now it's 665142 (5344 bytes saved).
And, no, we can't fit all 43 locales in our current BIOS. Yet.
Change-Id: I78cf8215f3da41a7ebc0e354cd1964c427a8c651
Reviewed-on: https://gerrit.chromium.org/gerrit/10879
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The -isystem and the rest of the CFLAGS for firmware builds is copied
from U-Boot, where U-Boot generates it on the fly, as a temporary
solution before we figure out how make the CFLAGS right.
Given that, the hard-coded -isystem is both incorrect (since tool chain
is upgraded to a new version) and unnecessary. It is unnecessary
because firmware lib is carefully written that the lib does not (and
probably should not) depend on any system header.
Even if in the future a system header is added to the firmware lib,
because firmware build sets -nostdinc to CFLAGS, the compiler will
safely report missing header instead of silently using the standard
system header.
So this commit removes the -isystem.
BUG=chromium-os:16808
TEST=Make sure non-firmware build still works by running
`emerge-{tegra2_seaboard,x86-alex} vboot_reference`
TEST=Run firmware build successfully
`emerge-{tegra2_seaboard,x86-alex} vboot_reference-firmware`
TEST=Add #include<stdarg.h> to any header in firmware/include/ and run
firmware build again and observe build fail on missing stdarg.h
Change-Id: I8291390f21a975446993640d7a92a3eed4750e32
Reviewed-on: http://gerrit.chromium.org/gerrit/10072
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The rest of the chromiumos build system uses amd64 as the
architecture name for 64bit x86. This adds support for this
name to vbutil.
BUG=chromium-os:21284
TEST=vbutil --arch amd64 should not return unknown architecture
Change-Id: I37531591a7a31486f6447ae611d54569d1ea59d5
Reviewed-on: http://gerrit.chromium.org/gerrit/9959
Tested-by: Sonny Rao <sonnyrao@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>
* 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>
