Age | Commit message (Collapse) | Author |
|
It seems we put numbers and addresses into environment variables a lot.
We should have some functions to do this.
(cherry picked from commit d67f10c)
Change-Id: I922e72a7db872f26774459a6dc074a80016ef904
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11792
Reviewed-by: Doug Anderson <dianders@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>
|
|
BUG=chromium-os:21033
TEST=run `sf erase, write` and `sf read` on Waluigi
verify the data it reads from SPI flash matches that it writes to
Change-Id: Ibeefd3183e4fa367d68d0035a818e1c166e6d59d
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11473
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chromium-os:21033
TEST=run `sf erase, write` and then `sf read` on seaboard
verify the data it reads from SPI flash matches that it writes to
Change-Id: I1b04afa4b54738cd93be29b70f428bdc3e6b234f
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11472
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
BUG=chromium-os:21033
TEST=build seaboard successfully
Change-Id: Idbfbdbf0bdb1070f4a2b5f8205c1caff6ef0c811
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11471
Reviewed-by: Tom Warren <twarren@nvidia.com>
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
|
|
With this set of config options we can now boot the kernel. With
the kernel I have, it doesn't work yet, but at least it prints out
some messages to the UART.
BUG=chromium-os:21540
TEST=If I have a reasonable kernel in MMC1, I see that it can boot
quite a ways into the kernel w/ autoboot.
Change-Id: I5918fff3d48f2ff9f2bac9261c84e08e60a1560a
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10675
|
|
BUG=chromium-os:21540
TEST=Able to use mmc.
Change-Id: I1d566f08f9dd115b5be1a05ffa0ff07b508e0cee
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10663
|
|
The MMC reader looks like a USB device, so we don't need to support generic
MMC devices directly.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy.
Change-Id: Id5729cd9d51e0c4cb2570b9b452f96bd23764b85
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/10755
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
We aren't currently planning to have network support in production firmware. If
we need it at some point, we can easily turn that support back on.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy
Change-Id: Iad265bb2bbae5360135eaa8577cc6dfde95045f9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/10754
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
Disable it by default since we're using the SCSI interface now. Being able to
turn IDE back on later might be necessary if we haven't gotten AHCI support
working on a new platform yet.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy.
Change-Id: I07e80dc2673529f3f2ec52431e1c0958511539b0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/10753
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
Also disable those options. This way they can be enabled when needed, but when
you aren't expecting to use the command line (most of the time) they can be
excluded to reduce u-boot's size and load time.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy.
Change-Id: I7ea0f02a1aa3537fa4282822bbc0d4976c2b1383
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/10752
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
BUG=chromium-os:21540
TEST=With MMC change and MMC config change, was able to use MMC.
Change-Id: I61d543cbf7b2b6d885dd641b35b7c33cd85b51d6
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10662
|
|
BUG=chromium-os:21540
TEST=Built u-boot and booted u-boot on tegra2_kaen
Change-Id: Id6f11512ea1a95bd57b600601b488ae20b34db2d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10808
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The current location overlaps with the ramoops area, but due to a bug in
coreboot, this is only detected if coreboot is small enough to fit entirely
in that area.
BUG=chrome-os-partner:6649
TEST=Built and booted on Stumpy.
Change-Id: I5f9dbfe2434d42c216257413a6f8b3dd345e087e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/10751
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
We may want to use the PMU to adjust various voltages even if we
don't have clock scaling. Separate these two conecpts.
BUG=chromium-os:21540
TEST=Compiled for Seaboard
Change-Id: I376afe7e795fd2dd8035186c58f48a552391b4d1
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10457
|
|
BUG=chromium-os:21540
TEST=Saw that I could run i2c probe on busses 0-3
Change-Id: I291a7d208843e146738830eda62ccf9849503a17
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10367
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
On the tegra30, it appears that the "DVC" i2c controller has been
normalized and no longer requires special semantics for accessing it
(it has also just been renamed to "i2c5"). This change makes it so
that we don't pick DVC semantics based on the periperal ID, but
instead allow the device tree to specify.
BUG=chromium-os:21540
TEST=Compiled / booted on Kaen
Change-Id: Idfd96d1193b5ac267c61416544c63cc03dab396d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10279
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Exclude kcrashmem from vboot unused memory wipe to allow for recovery of
kernel crash dumps. If the kcrashmem size changes, then the corresponding
fdt must be updated.
BUG=chrome-os-partner:5168
TEST=Manually observed kcrash preserved
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Change-Id: Iecb2bd7f7df958125ed3cb3bf0b789602e314e7c
Reviewed-on: http://gerrit.chromium.org/gerrit/8942
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
|
|
This was added to the non-legacy kernel boot command line in
<http://gerrit.chromium.org/gerrit/8373>. Since legacy has its own
command line, we need it too.
BUG=chromium-os:21650
TEST=Booted a newer kernel with this change and saw vmalloc=234MB.
Change-Id: I1daaa71ce63892ef4534722caa705c4e9608c6ed
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10033
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
To maintain the initialization state of the timestamp facility, the
pointer to the CBMEM section containing the timestamp table should be
kept in the .data section (so that it is maintained across u-boot
relocation).
BUG=chromium-os:20733
TEST=manual
. build a new firmware image
. program it on a Stumpy configured for ssh communications
. reboot the stumpy
. examine the timestamp log
(host) ssh <target ip addr> /var/cbmem.py| grep -A1 'time base'
time base 2195144, total entries 4
1:77,700 2:767,214 1000:1,409,204 1100:2,274,851
observe the new timestamp entry added to the log.
Change-Id: I71edb31f1c0c7b3d24dcc9a611efc999615e09d2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10003
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This change adds a chromebook-x86 platform specific initialization
which does the following:
- find MRC cache in the SPI flash using the FMAP data
- compare the cache contents passed by coreboot through CBMEM with
the contents saved in the SPI flash
- if the two do not match and the new contents would fit into the
FMAP allocated room - update the contents in the SPI flash.
BUG=chrome-os-partner:5808
TEST=manual
. build the new firmware image
. place the updated coreboot/util/cbmem/cbmem.py utility into /var
on a Stumpy (the target) configured for ssh communications
. program the new image on the target
. reboot the target and wait for it to come up to ChromeOS login screen
. run the following from the host:
(host) ssh 172.22.75.233 egrep "'(handle|prepare)_mrc'" /sys/firmware/log
prepare_mrc_cache: MRC cache not initialized?
handle_mrc_cache: cached storage mismatch (-1/2899)
(host) ssh 172.22.75.233 /var/cbmem.py| grep -A1 'time base'
time base 2194240, total entries 3
1:79,373 2:765,726 1000:1,429,038
. reboot the target and repeat the commands once it comes up
(host) ssh 172.22.75.233 /var/cbmem.py| grep -A1 'time base'
time base 2124288, total entries 3
1:48,707 2:112,177 1000:754,652
(host) ssh 172.22.75.233 egrep "'(handle|prepare)_mrc'" /sys/firmware/log
prepare_mrc_cache: at ffbff004, size b53
handle_mrc_cache: cached storage match
Observe that during first startup u-boot detects the MRC cache
mismatch (and presumably saves the new copy). During the second
startup coreboot finds the saved MRC cache blob, and u-boot reports
that the CBMEM and SPI instances are the same.
Also, observe much lower timestamp values on the second run.
Change-Id: I4ab11f9281a7eec777e98fe7a8fd1e0f6abfd859
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9981
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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>
|
|
Quite a few changes have been made in config since the tegra3 header was
forked off in May. This brings this file back into line.
BUG=chromium-os:21033
TEST=build and boot on seaboard
Change-Id: I5244e03ca6a562f09b23bc9f0c11a5019084e399
Reviewed-on: http://gerrit.chromium.org/gerrit/8695
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This adds a very basic config file which will boot to a serial prompt.
BUG=chromium-os:21033
TEST=build and boot on seaboard
Change-Id: I03082d05b9de19473dbe41ef6aff366a2ff044e8
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8701
|
|
BUG=None
TEST=None
Change-Id: I6b8afd8c2da0ec33c9d2c61fa6590e3159273bca
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8687
Reviewed-by: Che-Liang Chiou <clchiou@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>
|
|
It is arduous to maintain two very similar config files for Tegra 2 and
Tegra3. This commit creates a new tegra-common.h to hold these common
items.
BUG=chromium-os:19004
TEST=build and boot on seaboard
Change-Id: I1015d33c1ad581063618466335a27e6f82aab2f2
Reviewed-on: http://gerrit.chromium.org/gerrit/8683
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The GPIO driver is common between T20 and T30, so rename it to indicate
this.
BUG=chromium-os:21033
TEST=build and boot on seaboard
Change-Id: Ibcdd4142cadccd037326e9f6a8426d3c106e5b18
Reviewed-on: http://gerrit.chromium.org/gerrit/8680
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
At present PMU and EMC support comes in by default when I2C is enabled.
This is inconvenient when the platform supports I2C but does not have or
want voltage and frequency scaling.
This feature now has its own config option.
BUG=chromium-os:19353
TEST=build and boot on Seaboard
Change-Id: I2bfc7ca226b6a11c6e215fae93030175a081306c
Reviewed-on: http://gerrit.chromium.org/gerrit/8678
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The T20 and T30 i2c peripherals can use the same driver. This renames the
driver and puts the header file into the common arch-tegra directory.
BUG=chromium-os:19004
TEST=build and boot on seaboard
Change-Id: Iec76bb27340db037fdc67b3509fd35f7b5aaeb34
Reviewed-on: http://gerrit.chromium.org/gerrit/8643
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This patch enables the CBMEM console driver introduced under
http://gerrit.chromium.org/gerrit/#change,8720, see the original
change for test description.
BUG=chrome-os-partner:4200
TEST=manual
as described above.
Change-Id: Ib80e6439e5c492939d4dd5b6ff81ef16f5dd335c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8738
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This patch builds upon the recently introduced CBMEM console
feature of coreboot.
CBMEM console uses a memry area allocated by coreboot to store
the console output. The memory area has a certain structure,
which allows to determine where the buffer is, the buffer size
and the location of the pointer in the buffer. This allows
different phases of the firmware (rom based coreboot, ram based
coreboot, u-boot after relocation with this change) to keep
adding text to the same buffer.
Note that this patch introduces a new console driver and adds the
driver to the list of drivers to be used for console output, i.e.
it engages only after u-boot relocates. Usiong CBMEM console for
capturing the pre-relocation console output will be done under a
separate change.
BUG=chrome-os-partner:4200
TEST=manual
. build the new firmware and program it on a stumpy
. restart the machine
. after it comes up to ChromeOS, run the cbmem.py utility (which
is a part of the coreboot package).
Observe u-boot console output in the log, starting with
vvvvvvvvvvvvvvvvv
SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
flags: 64bit ilck stag led pmp pio
^^^^^^^^^^^^^^^^
and ending with
vvvvvvvvvvvvvvvvv
Magic signature found
Kernel command line: "cros_secure quiet loglevel=1 console=tty2...
^^^^^^^^^^^^^^^^^
Note that the entire u-boot output fits into the buffer only if
the coreboot log level is reduced from the most verbose. Ether
the buffer size will have to be increased, or the coreboot
verbosity permanently reduced.
Change-Id: I399a90f3aeef9fae074db3e0842d876101c1a85e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8720
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
A few CBMEM table entries are included in coreboot to let u-boot
discover the locations of those entries. They all are passed
using the same structure within coreboot table. This patch makes
use of that structure for all communicated entries (timestam,
console and MRC cache).
It does not make sense to keep types of pointers in the sysinfo
table, as nobody but the respective users of those fields use the
types. Let's keep the pointers as void *, this also allows to
reduce the amount of include files in systinfo.h and hide the
timestamp structures in timestamp.c.
BUG=chrome-os-partner:4200
TEST=manual
. build the new firmware and program it on a stumpy
. restart the machine
. after it comes up to ChromeOS, run the cbmem.py utility
Observe that timstamp values are displayed, and there is an entry
with index 1000 (added by u-boot to the coreboot timestamp
table).
Change-Id: Icb808145c4c62cee939eceb3d5bf5afb3bcd00d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8711
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This line is a NC on Asymptote, but right now we're using the pwm line
(incorrectly). This CL removes the backlight-vdd line from Asymptote
dts and ensures that it's safely ignored if it's missing.
BUG=None
TEST=Built u-boot for Asymptote and flashed it on the device. Ensured that the
backlight still works in u-boot.
Change-Id: Id751b6756bac120e2211b7b32c58f356ff30b767
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8063
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This change turns on the code which allows u-boot to add
timestamps to the timestamp table created by coreboot.
Since u-boot does not use the tsc_t like structure to represent
HW counter readings, this structure is being replaced by 64 bit
integer.
The timestamp_init() function is now initializing the base timer
value used by u-boot to calculate the HW counter increments.
Timestamp facility is initialized as soon as the timestamp table
pointer is found in the coreboot table. The u-boot generated
timer events' ID will start at 1000 to clearly separate u-boot
events from coreboot events in the timer trace.
BUG=chromium-os:20733
TEST=manual
A Python script was used to retrieve the CBMEM timestamp table
while running CromeOS. The script will later be submitted into
the ChromeOS tools directory.
The following output was generated by the script:
localhost ~ # /var/vbendeb/cbmem.py
id 1, value 804,824,023
id 2, value 7,846,816,530
id 1000, value 19,356,528,758
Change-Id: I48c46e7b5cd2b2601d12465e0d8946152f31126e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8274
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This change adds code to process the timestamp table infiormation
in case it is included in the coreboot table.
coreboot/timestamp.h had to be modified to make it possible to
compile in u-boot environment. The upcoming change will modify
the timestamp handling code borrowed from coreboot under
http://gerrit.chromium.org/gerrit/8164.
BUG=chromium-os:20733
TEST=manual
. brought up a stumpy to ChromeOS login screen.
Change-Id: I008b5e4c971cbb13de2f055f53da6384035df5eb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8222
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:6077
TEST=none
Change-Id: I417ea3da24dc0cff17aa83ef799fabe78e4b1da5
Reviewed-on: http://gerrit.chromium.org/gerrit/8143
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@google.com>
|
|
This CL adds coreboot sources as is, they are not yet being
compiled and will have to be modified to get included in u-boot.
This is just a checkpoint checkin to establish a baseline for
future modifications.
BUG=chromium-os:20733
TEST=none
Change-Id: Ia2a8e108206b1dd7c27d72e5c72e35b386c3b151
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8164
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
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>
|
|
These options have now moved to the fdt.
BUG=chromium-os:17062
TEST=build for Seaboard, x86-mario
Change-Id: I93283c86f114f34311c915085175554a9e19c74f
Reviewed-on: http://gerrit.chromium.org/gerrit/7682
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
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>
|
|
BUG=chromium-os:19004
TEST=build and boot on T30 board
Change-Id: Ic75a5a6a017714d35584acd6d58876cc32af01a7
Reviewed-on: http://gerrit.chromium.org/gerrit/7132
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Some constants are actually better of with generic Tegra family names.
This also cleans up a few addresses which were in drivers rather than
in the tegra.h header file.
BUG=chromium-os:19004
TEST=build and boot on Seaboard
Change-Id: I1cabb5191a2b36648a37268069beb3b43c12d0e1
Reviewed-on: http://gerrit.chromium.org/gerrit/7128
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This patch provides handling of the two way handshake when SEND_OP_COND
(CMD1) is send to mmc card. It is necessary to inform eMMC card if the
host can work with high capacity cards (Jedec JESD84-A441, point 7.4.3).
The extra flag MMC_MODE_HC (high capacity) is added to indicate if the
host is capable of handling the high capacity eMMC cards.
Since this change is added to the generic mmc framework, then it requires
other boards to indicate if their mmc controllers can handle high capacity
cards. As it is now - the old behaviour of the framework is preserved.
Change-Id: I043cbddecbfd046888f715837df50f5440a0d3ca
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7791
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The ICH SPI controller can't handle more than 64 bytes in one
write transaction, but the SPI chips' drivers routinely invoke
controller transfer function (spi_xfer()) trying to write a full
SPI chip page, which often exceeds the ICH SPI controller capacity.
This condition goes unnoticed, resulting in only the first 64
bytes of the data written into the flash, the rest gets dropped
on the floor.
With this change an error value will be returned to the caller
and an error message will be printed on the screen.
Also, it turned out that the chip level flash drivers interpret
as errors only the negative values returned by the SPI interface
driver. But the SPI interface driver in ich.c was returning +1 to
report errors. This CL takes care of this discrepancy too.
BUG=chromium-os:20105
TEST=manual
. modify the '#ifdef CONFIG_ICH_SPI' line to read
'#ifdef CONFIG_ICH_SPIxx' in include/spi_flash.h
. build x86-alex bootloader image
. program the image on an alex device
. restart the device
. at the 'boot>' prompt run the 'saveenv' command
Observe the command failed and the error message printed on the console.
. restore include/spi_flash.h
. build x86-alex bootloader image
. program the image on an alex device
. restart the device
. at the 'boot>' prompt run the following commands:
setenv xyz 'this is a string'
saveenv
. reboot the device
. at the 'boot>' prompt run 'printenv'
Observe the environment include the new variable (xyz)
Change-Id: I528a85b208213c10fdf8cf3e908caf7bea94bc62
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7697
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This change moves the command line configuration to the end of the file since
config_cmd_default.h refers (minimally) to other settings when deciding what
commands to turn on.
BUG=None
TEST=Built and VBooted on Stumpy.
Change-Id: If802a1ac52a2d24c2d632aac0a03c9560da86524
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7741
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
This change trims down the set of commands built into u-boot with coreboot and
gets rid of some settings which aren't necessary. The list of commands
explicitly includes all of the defaults to make it more obvious what's turned
on and off.
BUG=None
TEST=Built on alex and Newton. Vbooted on Stumpy.
Change-Id: Id8541b87922d39f53dca800c9af915d807921f25
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7701
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
|