This CL accesses the partition entry array through its header's
entries_lba value.
Previously, we assume the primary entry array lies on third sector, and
the secondary array lies (1 + 32) sectors from disk end. This assumption
was fine, even Wikipedia assumed the same.
But in order for us to support writing boot code to the third sector (as
required by some Freescale board), the primary entry array must be moved
to another location. Therefore, we must use "entries_lba" to locate the
arrays from now on.
BRANCH=none
BUG=chromium:406432
TEST=unittest
TEST=`cgpt create -p` and then `cgpt show`. Make sure the table
header and entries are properly moved.
Change-Id: Ia9008b0bb204f290b1f6240df562ce7d3a9bbff2
Reviewed-on: https://chromium-review.googlesource.com/213861
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Nam Nguyen <namnguyen@chromium.org>
Tested-by: Nam Nguyen <namnguyen@chromium.org>
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167361
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At present the kernel tests produce valgrind errors since the GPT data is
sometimes accessed before it is read. This is unnecessary, so update the
code to avoid this.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
valgrind --leak-check=full ./build/tests/vboot_kernel_tests
See that we no longer get valgrind errors.
Change-Id: I9e9660e38a62a735cf01a37c2d81ddb5ab8b1528
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66173
Some functions of vboot are disabled for sandbox because sandbox could not
support them. This has changed, so remove the sandbox #ifdefs in the code.
Some printf() strings cause warnings on sandbox - mostly that uin64_t is
not 'long long' on a 64-bit machine. The existing format strings in U-Boot
do not seem to take account of this, so add casts to remove the warnings.
Also add a few more debug strings to make it easier to see what is happening
in the vboot flow.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
crosfw -b sandbox -V
See there are no warnings.
Change-Id: I86f90a693e4bd23fcacf6d48297dd32229348dd4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These were macros that were never used, or that were only set to one thing and
could be substituted up front.
I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.
BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None
Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
There are several places where the same recovery_reason was used to report
slightly different points of failure. Let's create some new codes instead.
Remember that recovery mode is handled by RO firmware, so if an updated RW
firmware uses one of the new error codes, pressing TAB at the recovery
screen will say "We have no idea what this means". That's not a bug. This CL
deprecates the original codes, so the fact that the RO firmware doesn't
recognize it just means it's a new code reported by a new RW BIOS.
BUG=chromium-os:36562
TEST=manual
BRANCH=parrot
Run
make && make runtests
It should pass. You can test some of the error cases on actual hardware by
using
crossystem recovery_reason=86
reboot
and pressing TAB at the recovery screen. For that example you should see the
message
recovery_reason: 0x56 TPM lock error in rewritable firmare
Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df
Reviewed-on: https://gerrit.chromium.org/gerrit/38652
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to dual boot Windows and ChromeOS, Windows must
not find a GPT partition table on the disk. So change
ChromeOS to cope with an alternative signature "CHROMEOS"
instead of the standard "EFI PART"
BUG=chrome-os-partner:6108
TEST=rebuild chromeos, install it,
run cgpt legacy /dev/sda
dd if=/dev/sda of=/tmp/x bs=1k
hexdump -C /tmp/X
see the string CHROMEOS
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: Ia88eff33b9880bd73a78c1b8e026c1f8298c4557
Reviewed-on: https://gerrit.chromium.org/gerrit/31264
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
It's not yet possible to verify the kernel in an Chromium OS image
with the Sandbox Version of U-Boot due to the lack of keys. For now,
stub out the verification process and behave as if everything is ok:
Sandbox U-Boot is only interested in the selected kernel and boot mode
at this point.
BUG=chromium-os:32603
TEST=With this change, it's possible to get valid answers from
vboot_twostop command with Sanbox U-Boot.
Change-Id: I3b1142889657315675eacd3a1d1448aeee7ccb62
Signed-off-by: Taylor Hutt <thutt@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30256
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Presently kernel load address and buffer size are programmed in the
u-boot device tree. There is no reason for this: the address and size
are part of the vboot encapsulation headers. Duplicating this
information hardcoded in the device tree does not bring any benefit
and is in fact harmful, as it is easy to get out of sync.
A better way of doing things is to derive kernel load address and size
from the appropriate vboot header. ARM people object to this, as they
want the very same kernel blob operate on devices with DRAM mapped to
different address ranges.
The suggested solution is to exclude the kernel memory section from
the device tree on the platforms where the load address could be
safely taken from the vboot header. In this case u-boot will pass
address of zero to vboot, which will know to derive the address/size
from the appropriate header. vboot then rewrites fields of the u-boot
supplied structure with actual address and size of the kernel blob.
There is no sanity check yet, as it is presumed that there is enough
memory to load any kernel and u-boot does not use the space above
0x100000 for at least 16 megabytes (the kernel partition size). On x86
platform the check could be verify that the top of the kernel space is
well below the stack.
BUG=chrome-os-partner:11994
TEST=manual
. with the appropriate u-boot change run a Link target through a
FAFT cycle, observe it succeed.
Change-Id: I3c2c2cefb1e31d16ac497a01894bf32638479ed7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29038
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Confirmed via codesearch that these fields are not used outside of
vboot_reference itself, and the only use inside vboot_reference is one
test which checked that the test error generation itself worked.
BUG=chromium-os:31668
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic393e126ca2853f7aaff19ffd6fcdbdb1c47689f
Reviewed-on: https://gerrit.chromium.org/gerrit/24895
Reviewed-by: Simon Glass <sjg@chromium.org>
Omit this check because this check is not really necessary and it is
dealing more harms than goods to ARM boards.
While body load address is configurable, it is not quite possible to fix
all the build scripts and runtime scripts to carry this address; so in
reality all scripts use the default body load address.
The problem is, this default address is not friendly to ARM boards, and
it virtually makes this check fails on ARM boards.
BUG=chromium-os:28077
TEST=emerge-{daisy,x86-alex} vboot_reference
TEST=load_kernel_test -b 1 chromiumos_image.bin
TEST=run verified boot on Daisy
Change-Id: I1a1cc0aedf254e2a2b680046812ab7154f26dea7
Reviewed-on: https://gerrit.chromium.org/gerrit/20947
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
When you enter dev-mode,
Pressing Ctrl-U to boot from USB is DISABLED.
Booting any self-signed kernel from the SSD is ENABLED.
This replaces the "crossystem dev_boot_custom" argument with
"crossystem dev_boot_signed_only", which has the opposite polarity.
So if you want to dev-mode to only boot official kernels, you have to
explictly set it that way. If you leave dev-mode and then come back,
it will go back to the conditions shown above.
BUG=chrome-os-partner:5954
TEST=manual
Just run the factory flow. It was broken; this should fix it (except for any
workarounds that were added while it was broken; those may need to be
reverted).
Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805
Reviewed-on: https://gerrit.chromium.org/gerrit/11853
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@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>
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>
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
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>
BUG=chromium-os:17457
TEST=make && make runtests
When this is merged into an actual firmware build, can test it:
* dev switch off -> no dev screen, won't boot self-signed kernel
* dev switch on --> dev warning screen, will boot self-signed kernel
(e.g., it acts like the Cr-48)
Change-Id: I985428256e48b7e05dd4d8fe582a0c0103bf5fb2
Reviewed-on: http://gerrit.chromium.org/gerrit/3901
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
Pressing Tab at a firmware screen now displays real data, including
the recovery reason, HWID, and contents of VbNvStorage.
Entry point start/end time tracking in VbSharedData now refers to the
new wrapper APIs.
Added capability for calling firmware to request recovery mode (for
example, if it's unable to initialize RAM, can't find the SSD, etc.).
Previously, calling firmware had no (good) way to do this other than
faking the recovery button being pressed.
BUG=chromium-os:17018
TEST=emerge on x86 and tegra2_seaboard
Change-Id: I7d377f279842b30a10d945d13571c41c464633f1
Reviewed-on: http://gerrit.chromium.org/gerrit/3814
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Third time's the charm. Now that we've moved to u-boot-next, this
won't break the ARM build.
BUG=chromium-os:17006
TEST=make && make runtests; emerge vboot_reference; emerge-tegra2_seaboard chromeos-bootimage
Change-Id: Ib4fa26c7a23868dd2ffd2b321ee8dc08c66ea322
Original-Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Original-Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/3803
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 0184886c8cb35e8e01d610622df448a7cb063e06
(This works with uboot-next, but not uboot, which doesn't implement its half of the new wrapper API. So rolling back to leave uboot working.
Change-Id: I1f9e3c63e5bbdb20b9195cd68787bef89f24afee
Reviewed-on: http://gerrit.chromium.org/gerrit/3588
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This is part 3 of the vboot wrapper API refactoring. It replaces the
function calls to utility.c functions with new API calls. (It also
fixes up some integer type mismatches in cryptolib that were causing
warnings on the H2C build; those had been fixed a while ago in H2C but
hadn't been propagated across.)
This is a re-commit of the original; I've verified it compiles on both
x86-alex and tegra2, for both vboot_reference and
vboot_reference-firmware, now that the patch from
1c1a883bc7 is checked in.
BUG=chromium-os:17006
TEST=make && make runtests, and emerged on both x86-alex and tegra2
Original-Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Original-Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit bd81b3a7d3)
Change-Id: Iefdbfb3d10eb9aa385fb6dfc3bf0896f637cb64b
Reviewed-on: http://gerrit.chromium.org/gerrit/3582
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
This is part 3 of the vboot wrapper API refactoring. It replaces the
function calls to utility.c functions with new API calls. (It also
fixes up some integer type mismatches in cryptolib that were causing
warnings on the H2C build; those had been fixed a while ago in H2C but
hadn't been propagated across.)
BUG=chromium-os:17006
TEST=make && make runtests
Change-Id: I771085dcdf79d9592de64f35e3b758111a80dd9f
Reviewed-on: http://gerrit.chromium.org/gerrit/3263
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I5ed3509a9d4e578cd2e98f493dab59bc2fbd5827
R=dlaurie@chromium.org
BUG=chrome-os-partner:2748
TEST=manual
crossystem fwb_tries=3
(reboot)
crossystem tried_fwb
(should print 1)
crossystem fwb_tries=0
(reboot)
crossystem tried_fwb
(should print 0)
In dev mode...
Boot a kernel signed with the same key as in the firmware
crossystem kernkey_vfy
(should print sig)
Boot a kernel signed with a different key than the firmware
crossystem kernkey_vfy
(should print hash)
Review URL: http://codereview.chromium.org/6711045
Change-Id: I8d52765227fd3355431bebc77dfbe0106c889eca
BUG=chrome-os-partner:2748
TEST=compiles; will be porting to H2C next
Review URL: http://codereview.chromium.org/6672068
Change-Id: Ib147be7442b93ef429a9796e2b76bee27347e0b3
R=adlr@chromium.org
BUG=13150
TEST=manual
On a current firmware (0052G1+), use 'crossystem vbtest_errfunc=3
vbtest_errno=3' to force a reboot to recovery mode. Then use
'crossystem recovery_reason' to check the recovery reason.
It should be 71. It's not. (You'll get a range of other error reasons
due to a different firmware bug.)
Review URL: http://codereview.chromium.org/6670040
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
(somehow that never got committed)
Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38
BUG=12282
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6610019
This matches the calls in firmware version 0037.
BUG=none
TEST=manual
Review URL: http://codereview.chromium.org/3859002
Change-Id: I3b45051dec3f4f45414802b39122c8d52c4d62f1
Change-Id: Id353323d268835cbcc1fb13c8669cee420c8fb6a
BUG=chrome-os-partner:1046
TEST=manual
Make sure your chromeos install on the hard drive has 2 good kernel
partitions. Do:
sudo cgpt show /dev/sda
If partition 2 has success=1, do:
sudo dd if=/dev/sda2 of=/dev/sda4 bs=1M
sudo dd if=/dev/sda3 of=/dev/sda5 bs=1M
cgpt add -i 4 -S 1 -P 2
(if instead partition 4 has success=1, do:)
sudo dd if=/dev/sda4 of=/dev/sda2 bs=1M
sudo dd if=/dev/sda5 of=/dev/sda3 bs=1M
cgpt add -i 2 -S 1 -P 2
Reboot and do the following:
sudo cgpt show /dev/sda
If the partition you just marked active still has success=1
priority=2, the bug is fixed. If it has success=0 priority=0, the bug
is still there.
Review URL: http://codereview.chromium.org/3324014
This makes the sequence of pictures shown to the user slightly less
confusing, but the whole process needs a bit more cleanup. Some of the work
has to be done in the BIOS code, not just here. This is better, but it's not
complete.
Change-Id: If0b3ecc92716020a06031866849d83411d7f0db8
BUG=chrome-os-partner:903
TEST=manual
Review URL: http://codereview.chromium.org/3249009
