| Age | Commit message (Collapse) | Author |
|---|
|
BUG=none
TEST=manual
In dev-mode, press "Ctrl-U" with no USB stick inserted.
If "crossystem dev_boot_usb" is 0, you'll hear two 400Hz beeps.
If "crossystem dev_boot_usb" is 1, you'll hear one 200Hz beep.
Signed-off-by: Bill Richardson <wfrichar@google.com>
Change-Id: Ifd45a067ec8b922863331f13f3f4525ef40f7346
Reviewed-on: https://gerrit.chromium.org/gerrit/14529
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
|
|
When telling the memory wipe infrastructure about regions it should and
shouldn't wipe, some of those addresses may be 64 bits on x86. This change
makes the infrastructure pass around those addresses intact instead of
truncating them, and then simply ignore the regions that are unaddressable
by U-Boot.
BUG=None
TEST=Built and booted on Lumpy. Built on Kaen
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I657cd5480ca9a33614b032bf2a727d1a74d38b48
Reviewed-on: https://gerrit.chromium.org/gerrit/14149
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
BUG=chromium-os:24151
TEST=verify ME hash in the OS
Change-Id: I752bdb9e7fedc3a25772ba33b00d981b9e3db4b0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
This is a revised version of this patch which fixes an ARM bug.
This change plumbs the size of the GBB specified in the device tree to the
functions that read it from the flash into memory, and adds checks to those
functions to make sure they don't spill out of the in memory GBB. From a
security standpoint this is a largely theoretical problem since the GBB is
in the read only portion of flash and if that can be modified the machine
is totally compromised, but it's possible somehow an attacker could force
vboot to read the GBB from the wrong place. From a practical perspective
it's not a bad idea to check this to avoid accidental memory corruption.
BUG=chromium-os:24223
TEST=Built and booted on Lumpy. Built for Kaen.
Change-Id: I90d23fd6e055db595af12b1bd63d9932cbffe7ae
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/13279
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
This breaks recovery mode on Kaen - the bitmaps are not displayed.
This reverts commit e1153e1f56ebebff188f3693e534f10bd68e6f07
Change-Id: I300ae39382dc1960bb0375ad660a88b65181edc9
Reviewed-on: https://gerrit.chromium.org/gerrit/13274
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This change plumbs the size of the GBB specified in the device tree to the
functions that read it from the flash into memory, and adds checks to those
functions to make sure they don't spill out of the in memory GBB. From a
security standpoint this is a largely theoretical problem since the GBB is
in the read only portion of flash and if that can be modified the machine
is totally compromised, but it's possible somehow an attacker could force
vboot to read the GBB from the wrong place. From a practical perspective
it's not a bad idea to check this to avoid accidental memory corruption.
BUG=chromium-os:24223
TEST=Built and booted on Lumpy. Built for Kaen.
Change-Id: I4f33552f9d27321e73659520b08be52d775a6a9b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/13228
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
Implement the VbExBeep function so that the DEV screen can beep.
Much of this code was coppied from coreboot.
BUG=chrome-os-partner:7114
TEST=manual, check that Stumpy beeps on DEV screen timeout and when
booting from USB with dev_boot_usb=0.
Change-Id: Icd4eabb0b10cc3d226db71e6a2b52d3ed7eb25ef
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13110
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Instead, once we know which firmware we are actually running on,
copy the FWID to the BIOS version in the SMBIOS table.
BUG=chrome-os-partner:6827
TEST=Boot Stumpy, go to chrome://settings/about and see
Google_Stumpy.... show up as "Firmware"
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Also needs https://gerrit-int.chromium.org/#change,9288
Change-Id: I2e16a2fdb7fb835b0a0fbf08462d8a98b3cfe208
Reviewed-on: https://gerrit.chromium.org/gerrit/13098
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
https://gerrit.chromium.org/gerrit/11152 introduced a bug where the
gbb pointer used during rewriteable firmware boot is bogus.
The pointer is retrieved from the 'chromeos-config' section of the
device tree, but on x86 platform this memory area is never
initialized. The fix is to make sure that the proper gbb address in
the CPU address space is used before gbb contents are accessed.
What it boils down to is that when CONFIG_HARDWARE_MAPPED_SPI is set,
gbb address should be determined before setup_gbb_and_cdata() is
called.
To accomplish that fdt_decode_twostop_fmap() is being modified to
retrieve the flash base address among other things. Calling this
function before setup_gbb_and_cdata() allows to assign the gbb pointer
before it is used.
`google-binary-block' is not yet being removed from the cromeos-config
section of the device tree as this could break some tests.
BUG=chromium-os:22528
BUG=chrome-os-partner:7155
TEST=manual
. build a new firmware image and program it on a Lumpy
. verify that the device comes up as expected
. modify the firmware to use read/write path as suggested by hungte@
cd ~/trunk/src/platform/vboot_reference/scripts/image_signing
./resign_firmwarefd.sh /build/lumpy/firmware/image.bin \
/build/lumpy/firmware/new_image.bin \
../../tests/devkeys/firmware_data_key.vbprivk \
../../tests/devkeys/firmware.keyblock \
../../tests/devkeys/firmware_data_key.vbprivk \
../../tests/devkeys/firmware.keyblock \
../../tests/devkeys/kernel_subkey.vbpubk \
1 0
. put new_image.bin into a lumpy flashrom
. reboot the device
. observe it come up, printing on the console
'vboot_twostop: jump to readwrite main firmware at 0x1110000, size 0xdffc0'
along the way
Change-Id: Ieeaadafdf31ee6199a6f1fce0b9684dd494a7602
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/12969
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
On X86 systems the hardware maps the bootprom SPI flash chip into the
top of memory address range. This could be used for accessing all
information in the SPI flash.
The vboot-reference code requires access to FMAP sections containing
cryptographic information, and as of today, u-boot reads the whole
sections, which are 64 KB in size, even though the actual areas
accessed by vboot-reference are much smaller.
A much faster way of accessing this information would be just passing
around pointers to the appropriate memory areas. This would eliminate
one copy, and also would make sure that only the areas actually
accessed get fetched from SPI flash.
This patch provides this ability trying to keep code changes to a
minimum.
New feature is enabled by defining CONFIG_HARDWARE_MAPPED_SPI. The
firmware storage API for file reads changes when the new configuration
option is set: a pointer to pointer to buffer is passed to the
read_spi() function instead of a pointer to buffer. When the new
feature is enabled the read_spi() function sets the pointer value to
point to the requested data instead of copying the data into the
buffer.
A new data type is introduced (read_buf_type), which is set to be a
(void *) if the new feature is not enabled, or (void **) otherwise.
This type is used as the buffer pointer in the spi_read() function.
Code allocating/freeing buffers used to keep data read from SPI flash
is now conditionally compiled.
Call sites for the spi_read() function are modified to adjust the
buffer pointer parameter (pass the address of the parameter instead of
the parameter, when the new feature is enabled).
gbb field access functions can be aliased to gbb_init(), as they all
in fact do the same - read a certain section of the gbb area.
This change does not benefit the ARM implementations, and makes the
code more complicated that it should be. Some u-boot rearchitecture
along with vboot_reference API enhancements could address this. A
tracking issue
(http://code.google.com/p/chromium-os/issues/detail?id=22528) has been
opened for that.
BUG=chrome-os-partner:6585, chromium-os:22528
TEST=manual
. build a new stumpy firmware image
. boot the stumpy, observe it start up chromeos.
. assess the boot timing using the cbmem.py utility (this
modification shaves in excess of 100ms off the boot time).
. disable the new feature, build a stumpy image, observe that is
still boots chromeOs.
. run emerge-terga2_kaen chromeos-u-boot to confirem that ARM
version builds cleanly.
Change-Id: I4e6ab530d24f5771b5a86a48d3f3135101b469a6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11152
|
|
Add code to retrieve the location of the MRC cache from the FMAP
device tree definition.
fdt_decode.c should be refactored (fmap_offset could be determined
just once and used throughout without passing it as a parameter), will
leave this for another day.
BUG=chrome-os-partner:5808
TEST=manual
. see test description in the second patch commit message.
Change-Id: Ic4003d685609beb61d1dea324bd804a2838e471c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9961
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The memory wipe infrastructure in u-boot makes some assumptions about how
memory is arranged that make it not quite fit with x86. Specifically, it
assumes that there is a single region of memory, and with certain exceptions
that's what should be wiped. In x86, specifically in the e820 map, there are
multiple regions of RAM, possibly multiple regions to exclued from that that
may completely, partially, or not overlap with the others, and then u-boot
related regions.
This is addressed by making the memory wipe infrastructure a little more
generic. Now, areas can be added and subtracted arbitrarily, and will
accumulate in the order they're encountered. In the x86 use case, we can add
the e820 regions marked as RAM, subtract the areas marked as anything else, and
subtract the u-boot related regions.
Rather than tracking the actual regions of the address space, this
implementation tracks the boundaries between the regions using a linked list.
The code itself is short and relatively simple, and I tried to ensure that it
was as clear as possible to make any memory (or other) bugs easier to see and
fix.
BUG=chrome-os-partner:6195
BUG=chrome-os-partner:6194
TEST=Built and booted on kaen using the A-A cable. Ran vboot_test memwipe, and
a modified version that took advantage of the new API.
Change-Id: I122fbf499ef473350afa27b612cb0e565366b1ad
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/9715
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This reverts commit 8e93aec313c2807704b14fbd21123a9ffc86a087.
The bios-base setting has been deprecated.
BUG=None
TEST=Built and booted on Stumpy.
Change-Id: I792761ac44763b06bf1d3abb4db8e9e1a3f113c5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/8823
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This change sets up basic vboot data for use by crossystem. The pieces of
information and what they're set to are below. I assumed that the constants
defined in the coreboot version of this code describe all of the available
settings for each option.
Boot reason: BOOT_REASON_OTHER
The choices here are BOOT_REASON_OTHER and BOOT_REASON_S3DIAG. I don't know
what BOOT_REASON_S3DIAG is for or how to detect which to use. I believe S3
resume happens without going through u-boot, so hardcoding this to
BOOT_REASON_OTHER seems reasonable for now at least.
Active main firmware: ACTIVE_MAINFW_RW_A
The choices are ACTIVE_MAINFW_RECOVERY, ACTIVE_MAINFW_RW_A and
ACTIVE_MAINFW_RW_B. This information isn't stored in the crossystem_data_t
structure. For now it's hard coded to ACTIVE_MAINFW_RW_A which is going to
frequently be wrong. I suspect we also need to add a value which indicates that
the read only firmware was used by itself.
Active EC firmware: cdata->active_ec_firmware
A direct match with data already gathered by u-boot/vboot.
CHSW: Translation from booleans to bitfields.
The cdata boot_write_protect_switch, boot_recovery_switch, and
boot_developer_switch boolean fields are translated into the
CHSW_FIRMWARE_WP_DIS, CHSW_RECOVERY_X86 and CHSW_DEVELOPER_SWITCH bitfields.
The CHSW_RECOVER_EC bitfield is ignored since there's no obviously
corresponding field in crossystem_data_t.
HWID: cdata->hardware_id
A direct match with data already gathered by u-boot/vboot.
FWID: cdata->firmware_id
A direct match with data already gathered by u-boot/vboot.
FRID: cdata->readonly_firmware_id
A direct match with data already gathered by u-boot/vboot.
Active main firmware type: cdata->firmware_type
A direct match with data already gathered by u-boot/vboot.
Recovery reason: RECOVERY_REASON_NONE
The choices are RECOVERY_REASON_NONE and RECOVERY_REASON_ME. Since u-boot has
no information about the ME, this is hardcoded to RECOVERY_REASON_NONE.
FMAP base address: cdata->fmap_offset
An assumed direct match with data already gathered by u-boot/vboot. There is a
little ambiguity as far as what this is the offset of and from.
BUG=chrome-os-partner:5944
BUG=chrome-os-partner:5961
BUG=chrome-os-partner:5962
TEST=Booted successfully on both stumpy and alex. Used crossystem to verify
that information like the firmware ID was extracted successfully. The GPIOs,
which are not sent with this mechanism, seem to work sometimes but not always.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: If7ea2a6470d8edf7122f87f289c19d4464775e8c
Reviewed-on: http://gerrit.chromium.org/gerrit/7977
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This moves the last remaining hard-coded CONFIG to the fdt.
BUG=chromium-os:17062
TEST=build for Seaboard
Change-Id: Ic152ce12a0f87211e4cc98eef15601f0703137b1
Reviewed-on: http://gerrit.chromium.org/gerrit/7642
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
|
|
This setting specifies where the bios image described by the "flash" section
starts in the ROM. When the device tree is consumed by u-boot, this value is
added to the given offset of accesses to the flash so that it ends up in the
right place in the ROM. The binary fmap will reflect that address directly so
that tools like flashrom can use it without modification. By not modifying the
locations of the sections in the "flash" node of the device tree directly, we
can continue to share definitions between boards that have the same layout for
the BIOS image itself but who may be offset differently in the ROM. If not
present, a default value of 0 is used. Unmodified device trees will continue
to behave like they always have.
The name bios-base isn't perfect since on ARM there is no bios. Another
alternative firmware-base is also flawed because there are multiple firmwares
in the ROM on x86. Yet another option, flashmap-base, doesn't quite work either
because flashmap already has a very similarly named field which describes where
the image described by the flashmap appears in the physical address space.
Because bios-base fits the best on x86 and x86 is currently the only place it's
used, that's the name I went with.
BUG=chrome-os-partner:5844
TEST=Used this and other changes to compensate for the image offset and vboot
on stumpy. Vbooted on x86-alex. Built with vboot_test and vbexport_test built
in to verify that they still compile.
Change-Id: Ie727fc2db27f7d0db8ebf7ed2b98bc97052b4923
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7239
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
fmap.h uses uint32_t so it should include compiler.h to get this type.
Change-Id: I07c9664eb19b7f0ec445217c49793e7cb67a20db
Reviewed-on: http://gerrit.chromium.org/gerrit/7638
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
We need to register available boot devices. It seems reasonable that this
library should be initialized before use.
BUG=chromium-os:19518
TEST=build on Seaboard; vbexport_test diskinfo
See that all boot devices are found with SD and USB inserted
Change-Id: I17a535dc85b5aaee669ea67b439632bafb19c806
Reviewed-on: http://gerrit.chromium.org/gerrit/6501
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This reverts commit 23cefdce356de66442d858abf12c72afc8d33cac.
Since we changed our minds about loading FMAP information from CBFS, we can go
back to using the same mechanism on ARM and x86.
BUG=chrome-os-partner:5432
TEST=Built and booted on x86-alex and verified that the FMAP information showed
up in debugging output from vboot_twostop.
Change-Id: Id41c82ca24dbfa301559e24104b5e226ec9b7e03
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5864
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This lets us see the time used by twostop which is outside vboot itself.
BUG=chromium-os:17805
TEST=build and boot on Aebl, see new output:
Timer summary in microseconds:
Mark Elapsed Stage
...
647,449 4,792 do_vboot_twostop
649,768 2,319 twostop_init
661,083 11,315 twostop_select_and_set_main_firmware
886,859 225,776 twostop_main_firmware
1,324,964 438,105 select_and_load_kernel_exit
Change-Id: I85408bf2860a77fae54fcb78ece07314b8929d25
Reviewed-on: http://gerrit.chromium.org/gerrit/5775
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This change makes the FMAP configuration decoding function board specific so
that it can, for instance, use CBFS to store the FMAP on x86. The ARM
implementation uses fdt_decode_twostop_fmap in its implementation and should
behave the same. The new more generic interace is called decode_twostop_fmap.
BUG=chrome-os-partner:5248
TEST=Built, installed and booted on Kaen, built and installed on Alex, ran
vboot_twostop and saw new "unimplemented" message.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I07f6f8f7c8a62c5998ec4919d4609a7ac84783da
Reviewed-on: http://gerrit.chromium.org/gerrit/5233
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This change removes the device tree from one of the vboot support APIs so
that they fit better with coreboot u-boot. Specifically this is
cros_gpio_fetch which is for getting GPIO values. Coreboot will read these and
provide the values through its coreboot tables. The device tree pointer is
global data so it doesn't need to be passed around as a parameter to be
accessible.
This change also removes the device tree from other interfaces in
cmd_vboot_twostop.c so the structure of the code is more consistent. This way
people can expect the device tree to always be the one pointed at by the
global data and not sometimes one and sometimes the other, even though as
written those will be equivalent. This change also takes the opportunity to
mark the local functions in that file static, which is most of them.
BUG=chrome-os-partner:4552
TEST=Built for x86-alex and tegra2_kaen. Installed and booted to chromeos
login on Kaen.
Change-Id: I084e774d97025d9ec71abe09c92fab8a7827892f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5232
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This change separates out the FMAP data structures from the FDT decode
functions and renames them to more neutral names. These structures don't
intrinsically have to be loaded from the FDT, and their new names and location
remove the implied dependency.
BUG=chrome-os-partner:5248
TEST=Built for x86-alex and tegra2_kaen. Installed on Kaen and booted to
chromeos login.
Change-Id: I5680a3f3aaa52efe44c2060d0b6db9ad47a547ec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5231
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This fixes a build breakage in lib/vbexport/display.c when
VBOOT_DEBUG isn't defined.
BUG=none
TEST=compile without VBOOT_DEBUG=1 defined
Change-Id: Icdafd2783190b39bbd031565d14b4b20bdefe446
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5202
|
|
This patch only moves code around.
BUG=chromium-os:16542
TEST=build okay
Change-Id: Idc908fd2e652c114ae8029c120386fb44e63b4f9
Reviewed-on: http://gerrit.chromium.org/gerrit/5204
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
The U-Boot printf() implementation has an output buffer limitation on
output, and so cannot be used for very long output. Instead, puts() has
no such limitation.
BUG=chromium-os:18351
TEST=run on Aebl
Change-Id: I3f3e3b81968f5169a2fe1f581924fa19c3dc1a43
Reviewed-on: http://gerrit.chromium.org/gerrit/4990
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
This patch is derived from kernel's seaboard power management driver and
tps6586x regulator driver.
BUG=chrome-os-partner:4738
TEST=press power button or close lid in dev and rec mode
Change-Id: I285856b52dcaba6ba3c29cacf47a8c592fbe3256
Reviewed-on: http://gerrit.chromium.org/gerrit/4922
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
This change fills up the stubs in lib/vbexport/display.c to
provide support on both ARM (where LCD driver is used) and
X86 (where the CFB driver is used) platforms.
BUG=chrome-os-partner:4552
TEST=manual
On X86 (alex with a Dediprog programmer connected to it), run the
following commands:
. emerge-x86-alex vboot_reference-firmware chromeos-u-boot chromeos-coreboot
dd if=/build/x86-alex/coreboot/coreboot.rom of=/tmp/coreboot seek=3584 bs=1K
sudo flashrom -p dediprog -w /tmp/coreboot
. Reboot the machine, observe it come up to boot> prompt, start
ChromeOS (using the `boot' cli command).
On ARM (tegra2_kaen)
. emerge-tegra2_kaen vboot_reference-firmware chromeos-u-boot chromeos-bootimage
. program the resulting image into Kaen, restart it, observe the
machine come up.
. install the new OS image on the machine, restart it, observe
the machine come up.
. request recovery reboot using crossystem, restart the machine,
observe it come up in recovery request mode.
This test case actually failed: the system did show the
recovery request screen, but then proceeded to boot from the
plugged in USB stick (it was supposed to wait for the stick to
be removed/reinserted)
Change-Id: I75310de3f93464645cc9e61237f65d7d19b71873
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4886
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This patch is cherry-picked from commit 1d01c6b. You may gain 142ms in
boot time.
BUG=chromium-os:16542
TEST=boot normal/developer/recovery on Aebl
Change-Id: I983e2dec32205dd586a2d7f267409eaafefb267f
Reviewed-on: http://gerrit.chromium.org/gerrit/4806
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
This patch also eliminates duplications of decoding fmap from the
device tree.
BUG=chromium-os:16542
TEST=make chromeos_seaboard_vboot_config && make
Change-Id: I0af75335be10823b8644c94f6fc9aac0304a2633
Reviewed-on: http://gerrit.chromium.org/gerrit/4745
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
So far there seems to be no real board-specific data that crossystem
requires (the LBA/offset/size of non-volatile context used on ARM boards
are constants, and could be removed from crossystem data blob).
Nevertheless, I think it should be good to reserve a section for
board-specific data.
BUG=chromium-os:17876
TEST=make
Change-Id: I249fb6bb1ac1740df9f9596e1e1a61ab08c45659
Reviewed-on: http://gerrit.chromium.org/gerrit/4648
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
(commit 5a4a67 does not remove all deprecated stuff)
BUG=none
TEST=make
Change-Id: I458af1218c5afba53f56b0c75bcb0ac1b41caa68
Reviewed-on: http://gerrit.chromium.org/gerrit/4743
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
The LOAD_KERNEL_INVALID constant was a VBOOT internal constant
that has been removed.
BUG=None
TEST=compiled
Change-Id: Id9158ce66c4dbb70eb0a2f8ad59ce2edc3877dd4
Reviewed-on: http://gerrit.chromium.org/gerrit/4764
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
|
|
Make all debug print go to VbExDebug such that it is easy for performance
measurment.
BUG=chromium-os:18126
TEST=build without error
Change-Id: I30d59bd371dc3b122b3c1014107f2238cc01dc3c
Reviewed-on: http://gerrit.chromium.org/gerrit/4725
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
The predicate function is_cold_boot() is in fact telling you whether we
are booting from a processor reset.
BUG=chrome-os-partner:5100
TEST=build cleanly
Change-Id: I70f56448dd1b327426cf759854c35e20e0b4cfcf
Reviewed-on: http://gerrit.chromium.org/gerrit/4644
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
During the code migration to the redesigned vboot_reference API, the
boot_kernel (formerly named load_kernel_helper) was divided and its
private functions were taken out to keep U-Boot compilable
$ git log --oneline -3 -- lib/chromeos/load_kernel_helper.c
6cdb577 CHROMIUM: remove codes based on deprecated API of vboot_reference
29c5f74 CHROMIUM: Separate cmdline update part from load_kernel_helper library.
f853479 CHROMIUM: Separate the pre-boot FDT update part from load_kernel_helper library.
The commit 29c5f74 and f853479 took out the private functions for
updating kernel command line and embedding crossystem data into a device
tree. The functions are the guts of boot_kernel and serve no purpose
other than helping boot kernel.
In fact, if you diff load_kernel_helper and boot_kernel, you will find
they are virtually identical, except that functions based on deprecated
APIs of vboot_reference are removed in boot_kernel.
As the code migration has been completed, it is time for the private
functions to reunite with the boot_kernel.
BUG=chromium-os:16542
TEST=boot on Aebl
Change-Id: I6512d7a5197c41df7a2e9cc5d90c40be87b468b0
Reviewed-on: http://gerrit.chromium.org/gerrit/4573
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=none
TEST=Boot and see "twostop-optional" on output
TEST=Remove "twostop-optional" from flashrom-ro.dtsi and set preambles
flags to 0, then boot and see "not twostop-optional" on output
Change-Id: I53a151107e2bdf1a32f4aeace6f302b66cee3228
Reviewed-on: http://gerrit.chromium.org/gerrit/4651
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
The logic now goes into lib/vbexport/display.
BUG=none
TEST=build without error.
Change-Id: I6f8e694c01c53cace462b08242c57b6649e6ef56
Reviewed-on: http://gerrit.chromium.org/gerrit/4643
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chrome-os-partner:4738
TEST=build without error, run "vboot_test gpio" on Aebl
Tegra2 # vboot_test gpio
cros_gpio: wpsw : port= 59, polarity=0, value=1
cros_gpio: recsw : port= 56, polarity=0, value=0
cros_gpio: devsw : port=168, polarity=1, value=0
cros_gpio: lidsw : port= 23, polarity=0, value=1
cros_gpio: pwrsw : port=170, polarity=0, value=0
--- Pressed the power key ---
Tegra2 # vboot_test gpio
cros_gpio: wpsw : port= 59, polarity=0, value=1
cros_gpio: recsw : port= 56, polarity=0, value=0
cros_gpio: devsw : port=168, polarity=1, value=0
cros_gpio: lidsw : port= 23, polarity=0, value=1
cros_gpio: pwrsw : port=170, polarity=0, value=1
--- Closed the lid ---
Tegra2 # vboot_test gpio
cros_gpio: wpsw : port= 59, polarity=0, value=1
cros_gpio: recsw : port= 56, polarity=0, value=0
cros_gpio: devsw : port=168, polarity=1, value=0
cros_gpio: lidsw : port= 23, polarity=0, value=0
cros_gpio: pwrsw : port=170, polarity=0, value=0
Change-Id: Ib9fe188f39e266f806a823e694d8ea0867a8ef19
Reviewed-on: http://gerrit.chromium.org/gerrit/4485
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
The old code is copied from the old recovery firmware implementation:
http://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/third_party/u-boot.git;a=blob;f=common/cmd_cros_rec.c;h=4188ec98d136129e45d9d6c7664f861b279185f8;hb=refs/heads/chromeos-v2010.09
BUG=chromium-os:17950
TEST=run "vboot_test memwipe" success.
Tegra2 # vboot_test memwipe
memory_wipe: clear memory regions:
memory_wipe: [0x3f760c5c, 0x3f760c5d)
memory_wipe: [0x3f760c64, 0x3f760c65)
Memory wipe test SUCCESS!
Change-Id: Ieb587dbe001f91a58add6bcd3a1bc505e4227bda
Reviewed-on: http://gerrit.chromium.org/gerrit/4478
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
There are members of the blob that crossystem (user space utility) never
uses and are members that have ambiguous names. This patch removes and
renames these members, and further cleans up the code and adds static
assertions to offset of members.
BUG=chromium-os:17876
TEST=boot normal mode on Kaen
TEST=check crossystem output
Note: savedmem_{base,size} are x86-specific and crossystem is supposed
to output "(error)" on ARM boards.
----------------------------------------
arch = arm # Platform architecture
cros_debug = 1 # OS should allow debug features
dbg_reset = 0 # Debug reset mode request (writable)
dev_boot_usb = 1 # Enable developer mode boot from USB/SD (writable)
devsw_boot = 0 # Developer switch position at boot
devsw_cur = 1 # Developer switch current position
ecfw_act = RO # Active EC firmware
fmap_base = 0x000c0000 # Main firmware flashmap physical address
fwb_tries = 0 # Try firmware B count (writable)
fwid = 0.14.785.2011_07_22_1415 # Active firmware ID
fwupdate_tries = 0 # Times to try OS firmware update (writable, inside kern_nv)
hwid = ARM KAEN TEST 3084 # Hardware ID
kern_nv = 0x00000000 # Non-volatile field for kernel use
kernkey_vfy = sig # Type of verification done on kernel key block
loc_idx = 0 # Localization index for firmware screens (writable)
mainfw_act = B # Active main firmware
mainfw_type = normal # Active main firmware type
nvram_cleared = 1 # Have NV settings been lost? Write 0 to clear
recovery_reason = 0 # Recovery mode reason for current boot
recovery_request = 0 # Recovery mode request (writable)
recoverysw_boot = 0 # Recovery switch position at boot
recoverysw_cur = 0 # Recovery switch current position
recoverysw_ec_boot = 0 # Recovery switch position at EC boot
ro_fwid = 0.14.785.2011_07_22_1415 # Read-only firmware ID
savedmem_base = (error) # RAM debug data area physical address
savedmem_size = (error) # RAM debug data area size in bytes
tpm_fwver = 0x00010001 # Firmware version stored in TPM
tpm_kernver = 0x00010001 # Kernel version stored in TPM
tried_fwb = 0 # Tried firmware B before A this boot
vbtest_errfunc = 0 # Verified boot test error function (writable)
vbtest_errno = 0 # Verified boot test error number (writable)
vdat_flags = 0x0000020a # Flags from VbSharedData
vdat_timers = LFS=776638,778923 LF=794303,6382322 LK=8227743,12897100 # Timer values from VbSharedData
wpsw_boot = 0 # Firmware write protect hardware switch position at boot
wpsw_cur = 1 # Firmware write protect hardware switch current position
----------------------------------------
Change-Id: I5041ba3dfe51901aabe97e34583fcfdec7375f9f
Reviewed-on: http://gerrit.chromium.org/gerrit/4554
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
The twostop design is envolved that crossysmem data is now not
reinitialized again in readwrite main firmware, and relied on bootstub
passing the blob around.
Thus, the blob should have a fixed binary layout so that future
readwrite main firmware can reliably parse the blob contents. Currently
the readwrite main firmware just check the sanity of the blob.
BUG=chromium-os:17876
TEST=crossystem blob passes the sanity check by readwrite main firmware
Change-Id: I2981c10234c20d34e1405b5ab127bdc90faa2e3d
Reviewed-on: http://gerrit.chromium.org/gerrit/4373
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
vboot_reference is redesigned and deprecates parts of its API. This
patch remove those U-Boot integration codes that are based on the
deprecated API.
BUG=none
TEST=clean build okay
Change-Id: I45e08b8f5b6cec8f1bd62e760361f169aac4b687
Reviewed-on: http://gerrit.chromium.org/gerrit/4382
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
We has reached a twostop design that differs to prior implementation of
twostop firmware. If we use x86 firmware design as a metaphor, the
finalized twostop design has:
* One bootstub that select one of the main firmware
* One read-only main firmware which can do recovery and normal/dev boot
* Two readwrite main firmware which are virtually identical to x86
readwrite firmware, that is, they only do normal/dev boot
As a consequence, the readwrite main firmware does not reinitialize
itself (this differs to the prior twostop design). As a consequence, a
fixed protocol between the bootstub and the readwrite main firmware must
be defined, specifying which hardware is initialized by which firmware,
what parameters are passed from bootstub to main firmware, and etc.
So, this patch is not complete in this sense; there are some protocol
details that need to be defined and implemented but not included in
this patch.
BUG=chromium-os:17424
TEST=manually tested on Seaboard, Kaen, and Aebl
Test plan:
* Board: Seaboard (S), Kaen (K), and Aebl (A)
* Preamble flag: 0 or 1
* Boot mode: normal (N), dev (D), and recovery (R)
Board Flag Boot Result and crossystem output
------------------------------------------------------------
S 0 N Boot okay, mainfw_{act,type} correct
S 0 D Boot okay, mainfw_{act,type} correct
S 0 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
S 1 N Boot okay, mainfw_act incorrect: "B" instead of "RO"
mainfw_type correct
S 1 D Boot okay, mainfw_act incorrect: "A" instead of "RO"
mainfw_type correct
S 1 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
K 0 N Boot okay, mainfw_{act,type} correct
K 0 D Boot okay, mainfw_{act,type} correct
K 0 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
K 1 N Boot okay, mainfw_act incorrect: "B" instead of "RO"
mainfw_type correct
K 1 D Boot okay, mainfw_act incorrect: "A" instead of "RO"
mainfw_type correct
K 1 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
A 0 N Boot okay, mainfw_{act,type} correct
A 0 D Boot okay, mainfw_{act,type} correct
A 0 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
A 1 N Boot okay, mainfw_act incorrect: "B" instead of "RO"
mainfw_type correct
A 1 D Boot okay, mainfw_act incorrect: "A" instead of "RO"
mainfw_type correct
A 1 R devsw=on: Boot okay, mainfw_{act,type} correct
devsw=off: Boot hangs inside deep function call stack
Note:
* U-Boot was tested with:
+ vboot_reference revision r336 (commit a185b8)
+ chromeos-kernel revision r390
* Boot from external device in developer mode was not tested.
Change-Id: Ia1727326d4bb9552a02b097f3799e2c35a6004e3
Reviewed-on: http://gerrit.chromium.org/gerrit/4244
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
The commit 7ad165 was an inappropriate large chunk of rush fix-up
changes that was only halfway toward supporting new twostop boot.
BUG=none
TEST=check only changes of commit 7ad165 are reverted
git diff 7ad165~1.. -- \
board/nvidia/seaboard/tegra2-aebl.dts \
board/nvidia/seaboard/tegra2-kaen.dts \
common/cmd_vboot_twostop.c \
include/chromeos/crossystem_data.h \
lib/chromeos/crossystem_data.c
Change-Id: I00145c519866a49c81d2556c9c4912592c8c7e6c
Reviewed-on: http://gerrit.chromium.org/gerrit/4243
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
|
|
vboot_reference has just added support of twostop boot, and so u-boot
does not have to make tricks to vboot_reference.
BUG=chromium-os:17424
TEST=boot in developer mode on Seaboard
Change-Id: I79aa3d546a142de8fed07b975a7f37e07585c629
Reviewed-on: http://gerrit.chromium.org/gerrit/4164
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
The existing flashmap is not compatible with the way that Linux does flash
maps. This changes it to fit better. It also works correctly with the new
cros_bundle_firmware tool. We have two alternative maps for 2MB and 4MB
images.
BUG=chromium-os:17065
TEST=build and boot U-Boot on Seaboard
Change-Id: I9fded46d15582e17122a3d40c4b71b7b6cc77174
Reviewed-on: http://gerrit.chromium.org/gerrit/3906
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chromium-os:17424
TEST=build and boot on tegra2_{seaboard,kaen,dev-board}
Change-Id: Idea5a021c0c3888f5cc60c8fd5faf8d875d6267e
Reviewed-on: http://gerrit.chromium.org/gerrit/4088
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
BUG=chromium-os:17424
TEST=boot on Seaboard
Change-Id: I103c7060ed37c340e173498cfa70cf3493b2c503
Reviewed-on: http://gerrit.chromium.org/gerrit/4000
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chromium-os:17424
TEST=boot on Seaboard
Change-Id: I9b1f42801eedfba5e7f4e85a5b3ac1e1c106b6bf
Reviewed-on: http://gerrit.chromium.org/gerrit/3998
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
