| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
arch/arm/cpu/armv7/tegra3/warmboot_avp.c
arch/arm/include/asm/arch-tegra/clk_rst.h
|
|
|
|
This change allows to build a customized u-boot image, which includes
networking capabilities, provides diagnostic commands and supports
command line editing. These features are necessary to facilitate the
factory flow.
This image needs to be clearly distinguishable by ChromeOS. This is
achieved by modifying the value presented by the BINF.3 ACPI object.
To build this modified image one needs to add BUILD_FACTORY_IMAGE=1 to
the make invocation line.
BUG=chrome-os-partner:7952
TEST=manual
. build the new firmware image as follows:
USE='pcserial factory-mode' emerge-link chromeos-u-boot \
chromeos-coreboot chromeos-bootimage
. program the new image on the Link target with ChromeOS installed
on the SSD and restart it
. observe the target stop at u-boot command prompt (boot >)
. connect the target to an Ethernet network with a DHCP server
using a USB Ethernet dongle
. run the following commands at the u-boot prompt
boot > usb start
(Re)start USB...
USB: Register 203007 NbrPorts 7
USB EHCI 1.00
Register 20400b NbrPorts 11
USB EHCI 1.00
8 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
scanning bus for ethernet devices... 1 Ethernet Device(s) found
boot > dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
[a few warnings of unsupported DHCP options]
DHCP client bound to address 172.22.75.25
Using asx0 device
TFTP from server 172.16.255.7; our IP address is 172.22.75.25; sending through gateway 172.22.75.254
Filename 'pxelinux.0'.
Load address: 0x100000
Loading: ##
done
Bytes transferred = 15840 (3de0 hex)
boot >
. start ChromeOS on the target by issuing
vboot_twostop
. once ChromeOS boots check the mainfw_type crossystem reported value
localhost ~ # echo $(crossystem mainfw_type)
netboot
localhost ~ #
Change-Id: I1c50517754b6b5f773e432b9adec4b290f303e6f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/21071
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
In bug reports with screen shots of the firmware screens with tab
pressed, it would be extremely useful to see the version of the
currently running firmware and the read-only firmware, so output
this information.
BUG=none
TEST=press TAB at dev screen, see firmware versions printed on the
screen.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If91d4b1da8a7f69ff797b0b00c507248139601cd
Reviewed-on: https://gerrit.chromium.org/gerrit/17002
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
When a USB card reader is empty, it will return "Not Ready - medium not
present" as Key Code Qualifier. In that situation, it's useless waiting
for the full timeout since the result won't change until the user
inserts a card.
U-Boot mass storage returns empty mass storage devices with a size of 0,
skip them in the VBoot devices enumeration.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=On Link, run without a MMC card.
Change-Id: Iac37887742e5738e249f595e0413eec16b391fae
Reviewed-on: https://gerrit.chromium.org/gerrit/15582
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
Add this special handle of Ctrl-Enter, which is converted into '\n'
by i8042 driver.
BUG=chrome-os-partner:6759
TEST=compile the firmware and update it to Lumpy; during the dev screen,
press Ctrl-Enter to trigger USB boot.
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Change-Id: Ifde312f4ef6de9b328dc22b96ca02a2a9ccf6068
Reviewed-on: https://gerrit.chromium.org/gerrit/15805
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
Our security reviewers suggested that we update all copies
of lzma sdk code used in boot loaders to the latest version.
Updated code taken from latest lzma sdk release 9.20 at
http://downloads.sourceforge.net/sevenzip/lzma920.tar.bz2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chromium-os:24221
TEST=boot on stumpy, see it still work
Change-Id: I884546f3aaf013a083fa25f306d7d921245fbc16
Reviewed-on: https://gerrit.chromium.org/gerrit/14757
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
|
|
Right now our code makes the assumption that there always is one
SCSI drive in the system (the AHCI attached SDD). However, this
might not be the case.
This patch prevents vboot from using an uninitialized disk entry
when instead it should go into recovery mode.
BUG=chrome-os-partner:7716
TEST=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I761bbb3c92a60d4205a217c7b025f699deed83b0
Reviewed-on: https://gerrit.chromium.org/gerrit/14753
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
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>
|
|
By using arch_phys_memset, the wiping code doesn't need to worry about what
addresses can be accessed by memset or how to actually get at them.
BUG=chrome-os-partner:7579
TEST=From the original, larger patch:
Built and booted on Lumpy, Stumpy, and Kaen. Looked at the log to see
that the regions in high memory are listed as cleared. Artificially injected
a range to "clear" with 0xA5 and then 0x5A which was over the framebuffer and
covered part or all of the screen on Lumpy. Verified that the screen was
partially or completely filled with an appropriate looking color. Had U-Boot
print the PDTs it was generating to verify that the high address bits were
preserved. Identity mapped only some of memory and verified that things that
should be mapped were accessible and things that shouldn't be weren't.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: Ia1859e8df5a0bbe41839a697829dfc775e1b1e48
Reviewed-on: https://gerrit.chromium.org/gerrit/14419
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
The default implementation of this function is just memset, but other
implementations will be needed when physical memory isn't accessible by
U-Boot using normal addressing mechanisms.
BUG=chrome-os-partner:7579
TEST=From the original, larger patch:
Built and booted on Lumpy, Stumpy, and Kaen. Looked at the log to see
that the regions in high memory are listed as cleared. Artificially injected
a range to "clear" with 0xA5 and then 0x5A which was over the framebuffer and
covered part or all of the screen on Lumpy. Verified that the screen was
partially or completely filled with an appropriate looking color. Had U-Boot
print the PDTs it was generating to verify that the high address bits were
preserved. Identity mapped only some of memory and verified that things that
should be mapped were accessible and things that shouldn't be weren't.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: Ie1ba5bbb8ee2847f450d0057611deee397c316cf
Reviewed-on: https://gerrit.chromium.org/gerrit/14417
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
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>
|
|
This allows booting without a display, mostly as a way of calculating
the time that LCD init and maintenance costs us. Perhaps we might
integrate the lcd and video APIs within U-Boot - it would be a much
nicer solution. With that in mind I feel it is not work refactoring
this into three separate (lcd, video, none) files to implement the
display API.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: Iea4656f8939f7f2fd78292827091de4ee379954b
Reviewed-on: https://gerrit.chromium.org/gerrit/13369
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
Records the total time taken by TPM operations for display as part of the
bootstage report.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I7ce6efa3c2bb90858d17ab6613724e6ae73d918b
Reviewed-on: https://gerrit.chromium.org/gerrit/13371
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@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>
|
|
When we re-enumerate USB devices to configure new USB mass storage key,
we must also properly configure the USB keyboard if there is one
connected.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:5752 chrome-os-partner:6344 chromeos-partner:7188
TEST=on Lumpy, insert and remove a USB key in recovery mode and check
that TAB still triggers the recovery reason screen.
Change-Id: I4bf908023e21c027f6abcb49f168abb3013ed707
Reviewed-on: https://gerrit.chromium.org/gerrit/13251
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Instead of doing USB enumeration in a tight loop,
let's check first if anything has changed first,
then do the enumeration only if needed.
This saves time (the full enumeration currently takes 1.2s while the
insertion/removal detection runs in 19ms), and will allow to do the
keypress detection on USB keyboard in parallel.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:5752 chrome-os-partner:6344
TEST=on Lumpy, insert and remove a USB key in recovery mode.
Change-Id: I3ba084caa41234c8629771e9dd8b06b811712cdb
Reviewed-on: https://gerrit.chromium.org/gerrit/13250
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Because the offset and count parameters for the border_check function are
unsigned, their total could overflow a uint32_t and end up wrapping to look
smaller than the size of the flash even though it's mathematically larger.
This change adds a check for that overflow.
BUG=chromium-os:24222
TEST=Built and booted on a Lumpy.
Change-Id: I63b04dcb519f740f6d591301bc3d4d533bbd4e05
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/13219
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
|
|
https://gerrit.chromium.org/gerrit/#change,13110 assumed that the
coreboot specific enable_beep() and disable_beep() functions are
available on all ChromeOS platforms. However, at this point, only
the coreboot port implements them.
This CL fixes compilation on non-x86 / non-coreboot platforms.
BUG=none
TEST=build chromeos-u-boot for tegra2 kaen.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I084a2c505ea29180f711328dc969ad99c413b7cf
Reviewed-on: https://gerrit.chromium.org/gerrit/13115
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Tested-by: Stefan Reinauer <reinauer@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>
|
|
Move the malloc() out of fdt_decode_alloc_region() and rename it
accordingly. This makes the code somewhat cleaner and allows us
to print a sensible error message.
BUG=chromium-os:17062
TEST=build and boot on Kaen
Change-Id: I8edc8809baa42578e74c5e42cf47494b31b774e7
Reviewed-on: https://gerrit.chromium.org/gerrit/11878
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This function is generally useful and shouldn't hide away in hush. It
has been moved as is.
Signed-off-by: Simon Glass <sjg@chromium.org>
(cherry picked from commit 3cce8a5496452285e1828984ad3945417205cfc3)
Change-Id: I014f58e901e6b035b5eeb694c62e6e881a7b75c2
Reviewed-on: https://gerrit.chromium.org/gerrit/11791
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-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
|
|
All memory operations (except the "safe ones") live in the firmware
so the fast operations can be used. Except Memset. This CL changes that
problem.
There is another CL for this issue (removing the function from
vboot_reference)
BUG=chrome-os-partner:6313
TEST=run coreboot/u-boot on Stumpy
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ic2ee5970d2ee9df64a9eda261a4348341cb4b31a
Reviewed-on: https://gerrit.chromium.org/gerrit/10992
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
But let coreboot pre-fill that field instead.
BUG=chrome-os-partner:6212
TEST=boot coreboot+u-boot on Lumpy, see EC firmware reported as RW in
crossystem.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Icc4ac474e19dc72b61040faafbe1a184738564d0
Reviewed-on: http://gerrit.chromium.org/gerrit/10266
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
This CL simplifies how cros gpios are handled by moving the required logic out
of cros_gpio.c and into the application logic. This means that cros_gpio.c
assumes that none of the gpios are required, and just returns an error when
fetch is called. It's up to the caller of fetch to determine whether or not they
should ignore the error or act upon it.
BUG=chromium-os:21700
TEST=Tested on asymptote, ensured gpio access worked as expected.
Change-Id: Ief3f1915026bfe981d345b9cc4709fef19edc7bf
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10174
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
Verified boot requires writing to GPT attributes (success / tries), so we need
to implement *_write.
"scsi write" command is also added to console for testing.
BUG=chrome-os-partner:6258
TEST=(1) Modified GPT to trigger VBOOT updating GPT, and verified
GPT changed successfully (by firmware) after reboot
(2) ext2load usb 1:1 10000000 /part2.bin # load kernel partition dump
scsi write 10000000 5000 5000 # write into kernel partition in #2
Change-Id: I8027b6075cdabf8df81ea1ba620ca0dcd3d33232
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8841
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
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 file needs to depend on both CONFIG_CHROMEOS and CONFIG_OF_CONTROL.
BUG=chromium-os:19353
TEST=build with CONFIG_OF_CONTROL, but without CONFIG_CHROMEOS;
see that it now succeeds
Change-Id: I94b2616b6bcb10619b00c5fe93adf2e36d459fb0
Reviewed-on: http://gerrit.chromium.org/gerrit/8682
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Instead of using a hardcoded value, set this field of the table used by the
crossystem ACPI driver to whatever is stored in VDAT.
BUG=chrome-os-partner:5944
BUG=chrome-os-partner:5961
BUG=chrome-os-partner:5962
TEST=Booted on Alex. Verified that corrupting firmware A made crossystem change
mainfw_act to B instead of A.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I01b26508fede3d15e78b584b638e1393c5b03501
Reviewed-on: http://gerrit.chromium.org/gerrit/8189
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
|
|
Signed-off-by: Bill Richardson <wfrichar@google.com>
BUG=none
TEST=none
Change-Id: I636eee76069d9f6ae0679135b87f0006d59c2723
Reviewed-on: http://gerrit.chromium.org/gerrit/8242
Tested-by: Bill Richardson <wfrichar@chromium.org>
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 just changes to standard 'blob' naming, and fixes a code style error.
BUG=chromium-os:19353
TEST=build and boot on Seaboard
Change-Id: Ib79d526ef612a181091ef15a5dd427ea73c53330
Reviewed-on: http://gerrit.chromium.org/gerrit/7681
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Simon Glass <sjg@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>
|
|
Copy device_ide.c into device_scsi.c, editing as appropriate
along the way. Ensure that the new file is included if
CONFIG_AHCI_SCSI is defined fro the platform.
BUG=chromium-os:19837
TEST=manual
. program updated image (including AHCI fixes and configuration
changes) on an Alex.
. restart the machine and enter `vboot_twostop' at u-boot prompt.
Observe it boot up all the way to ChromeOs login screen.
Change-Id: I146591c53f61722cc33f7261a1921aa07e861ee3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7234
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
It was noticed that the system fails to come up while running the
latest u-boot from the 2011.06 branch. Further investigation has
discovered that the problem is due to the fact that the
initialization of the verified boot wrapper was not handled
properly and that the IDE index reported by the IDE discovery
routine was wrong.
BUG=chromium-os:19599
TEST=manual
. build and install the new firmware image on an Alex with a
valid ChromeOS image
. restart the machine
. enter vboot_two at u-boot prompt
observe the machine to bring up the ChromeOs login screen.
Change-Id: Icc78d682d5c81d6f08d31896c32c8cd48d0a4f2d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7030
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
Now that we have MMC, USB and IDE, with some enabled for only some platforms,
the code has become ugly. This refactors the code to separate out each device
into its own file, with a generic start/scan interface.
This also fixes the problem with indexing of devices, where it could not cope
with MMC and IDE active at the same time.
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: I4844f7b33885ec01e922686a17c90afdf0a55a9d
Reviewed-on: http://gerrit.chromium.org/gerrit/6254
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6918
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
boot_kernel sets up pointer to crossystem data for embedding into kernel
device tree unconditionally regarding CONFIG_OF_UPDATE_FDT_BEFORE_BOOT.
This patch guards boot_kernel codes that are specific to kernel device
tree with the config flag.
Note: x86 boards might use a mechanism other than device tree to deliver
crossystem data to kernel.
BUG=none
TEST=emerge-{tegra2_aebl,x86-alex} chromeos-u-boot
Change-Id: Ifd04af1681d72c918c838ba3713ddecaca0ff18a
Reviewed-on: http://gerrit.chromium.org/gerrit/6466
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-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>
|
|
BUG=chrome-os-partner:4552
TEST=vboot_twostop does not fail with an error after loading the kernel.
Change-Id: I16016239716c8030ea63c7da6bd99a2f03b0e40d
Reviewed-on: http://gerrit.chromium.org/gerrit/5549
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
From http://gerrit.chromium.org/gerrit/#change,6253
BUG=none
TEST=none
Change-Id: I3145aa84a8426506d8dc44d094da4884f079b3b4
Reviewed-on: http://gerrit.chromium.org/gerrit/6355
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This is a rewrite of http://gerrit.chromium.org/gerrit/#change,5547
which tries to integrate more transparently into vbexport's code
and at the same time removes some (false) assumptions about always
booting from MMC.
BUG=none
TEST=none
Change-Id: I18f3b91f307b16622de9ced97ab00454c29941fe
Reviewed-on: http://gerrit.chromium.org/gerrit/6232
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
|
|
BUG=chromium-os:19353
TEST=build for Seaboard
Change-Id: Iba1da73cdd5a8e3972240e939a40ee4a32e83786
Reviewed-on: http://gerrit.chromium.org/gerrit/6252
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
