<types.h> is supposed to provide <stdint.h> and <stddef.h>.
When <types.h> is included, <stdint.h> and/or <stddef.h> is removed.
Change-Id: I2db0a647bc657a3626cb5e78f23e9198e290261a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
This fixes the following changes, which made qualcomm Kconfig
appear on all platforms:
bd0b51c0be7a3e46d767
Use proper Kconfig logic.
Change-Id: I0195fd186ac39dd4258fe0781dd6d3d1b1d1679f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32805
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
That's how we do it these days.
Change-Id: I1c088d23dff709bcdcb21310059e6a2aab84c0be
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch fixes up all code that would throw a -Wtype-limits warning.
This sometimes involves eliminating unnecessary checks, adding a few odd
but harmless casts or just pragma'ing out the warning for a whole file
-- I tried to find the path of least resistance. I think the overall
benefit of the warning outweighs the occasional weirdness.
Change-Id: Iacd37eb1fad388d9db7267ceccb03e6dcf1ad0d2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32537
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CB acts as I/O handler for QCLib (e.g. DDR training data)
This interface allows bi-directional data flow between
CB and QCLib
Tested and working interfaces:
DDR Training data
QCLib serial console output
DDR Information (base & size)
limits cfg data
TEST=build & run
Change-Id: I073186674a1a593547d1ee1d15c7cd4fd8ad5bc1
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
TEST=build & run
Change-Id: I222a56f1c9b74856a1e1ff8132bab5e041672c5d
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25207
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds code to initialize two USB DWC3.0 controllers
and its associated QUSB V2 10nm PHYs to the SDM845 SOC, and uses them to
initialize USB3.0 on the cheza mainboard.
Synopsis controller initialization and configuration sequences taken from
USB 3.0 HPG chapter 2.2 and refer PHY HPG chapter 10.2 for QUSB phy
programming.
Includes Super speed mode support.
TEST=USB keypad and mass-storage device enumeration tested with this patch
Change-Id: I475a7757239acb8ef22a4d61afd59b304a7f0acc
Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I38d086c379a3c2f54d1603a2fed5b33860f7f4d7
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32288
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idebbbd89de05d949e6f953aa49d8662d64383d1a
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The name OPROM is somewhat inaccurate, since other steps to bring
up display and graphics are needed depending on mainboard/SoC.
This patch cleans up OPROM code nomenclature, and works towards
the goal of deprecating vboot1:
* Rename CONFIG_VBOOT_OPROM_MATTERS to
CONFIG_VBOOT_MUST_REQUEST_DISPLAY and clarify Kconfig
description
* Remove function vboot_handoff_skip_display_init
* Remove use of the VbInit oflag VB_INIT_OUT_ENABLE_DISPLAY
* Add |flags| field to vboot_working_data struct
* Create VBOOT_FLAG_DISPLAY_REQUESTED and set in vboot_handoff
BUG=b:124141368, b:124192753, chromium:948529
TEST=make clean && make test-abuild
TEST=build and flash eve device; attempt loading dev/rec modes
BRANCH=none
Change-Id: Idf111a533c3953448b4b9084885a9a65a2432a8b
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Update SPI enable/disable and configure clock
API for supporting all the blsp and qup for qcs405.
Change-Id: I39622571cb671f62312283a010129ceecb654f61
Signed-off-by: Shefali Jain <shefjain@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add required changes for USB host mode for
USB disk enumeration.
TEST=build & run
Change-Id: I35ec549b49b9789389c80843f6103e7243d52aac
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@partner-android.googlesource.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Introduce new and required GPIO APIs, using common pinmux
definitions for GPIO configuration.
TEST=build & run
Change-Id: I85ce9007c545b44371c4704a0456774d0eff12a8
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, the size of memory made for vboot_working_data
through the macro VBOOT2_WORK was always specified in each
individual memlayout file. However, there is effectively no
reason to provide this customizability -- the workbuf size
required for verifying firmware has never been more than 12K.
(This could potentially increase in the future if key sizes
or algorithms are changed, but this could be applied globally
rather than for each individual platform.)
This CL binds the VBOOT2_WORK macro to directly use the
VB2_WORKBUF_RECOMMENDED_DATA_SIZE constant as defined by vboot
API. Since the constant needs to be used in a linker script, we
may not include the full vboot API, and must instead directly
include the vb2_constants.h header.
BUG=b:124141368, b:124192753
TEST=Build locally for eve
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
TEST=make clean && make test-abuild
BRANCH=none
CQ-DEPEND=CL:1504490
Change-Id: Id71a8ab2401efcc0194d48c8af9017fc90513cb8
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Drop 'include <string.h>' when it is not used and
add it when it is missing.
Also extra lines removed, or added just before local includes.
Change-Id: Iccac4dbaa2dd4144fc347af36ecfc9747da3de20
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Adding the basic infrastruture soc support for qcs405 and
a new build variant.
TEST=build
Change-Id: Ia379cf375e4459ed55cc36cb8a0a92cab18b705e
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch is a raw application of
find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
MMIO operations are arch-agnostic so the include
path should not be arch/.
Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Invert the default instead of selecting it everywhere. Restores the
ability to use its Kconfig prompt.
Beside Qemu targets, the only platforms that didn't select it seem
to be samsung/exynos5420, intel/cannonlake, and intel/icelake. The
latter two were about to be patched anyway.
Change-Id: I7c5b671b7dddb5c6535c97c2cbb5f5053909dc64
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30891
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This sets up initial clock configuration for QUP and QSPI,
and includes configuration of Root Clock Generators(RCG) and
clock branches enablement.
TEST=build & run
Change-Id: I0b1d7f6daa179c0b24a97d42b66c1a9ee596b0a3
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/25454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The dependencies of CONSOLE_SERIAL and DRIVERS_UART were somehow
backwards. Fix that. Now, CONSOLE_SERIAL depends on DRIVERS_UART,
because it's using its interface. The individual UART drivers
select DRIVERS_UART, because they implement the interface and
depend on the common UART code.
Some guards had to be fixed (using CONSOLE_SERIAL now instead of
DRIVERS_UART). Some other guards that were only about compilation
of units were removed. We want to build test as much as possible,
right?
Change-Id: I0ea73a8909f07202b23c88db93df74cf9dc8abf9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch replaces the UART in the bootblock of SDM845 with a bitbang
implementation. Since SDM845 hardware UART needs a firmware blob loaded
into it before it becomes usable, it is not really suited for use in the
bootblock (since by the time we can read blobs from SPI, the bootblock
is essentially over anyway). This solution allows us to still have some
console output during early SoC initialization.
Change-Id: I0c252ec83a7993edce5c4debc687f1fdd0d7b36d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Introduces new and required GPIO APIs, using common pinmux
definitions for GPIO configuration.
TEST=build & run
Change-Id: I8cef9dae2072da32cb0678efefeb8f0070cdde9c
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Reviewed-on: https://review.coreboot.org/26233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Bootblock has grown beyond 32K, grow to 40K
Change-Id: Iedc52151e223ebf4ff5b35a419b5378a6f1c661b
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/26760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This change adds and updates headers in all of the soc files that
had missing or unrecognized headers. After this goes in, we can
turn on lint checking for headers in all soc directories.
Change-Id: I8b34dcd10c692f1048bd8d6c0fe3bfce13d54967
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/26569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Use of device_t has been abandoned in ramstage.
Change-Id: Ib7bcfefaecc053a1ed28d708a614acb81207bccf
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
TEST=build
Change-Id: Icf934caf8b4584ef2633054a5cc7f5be7cc734ee
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Frequency set to 19.2 MHz
TEST=build
Change-Id: I56e57156df8a74cf629f7ada86cf5a5fcd5ad3c4
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25202
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On a second look broadcom/cygnus and imgtec/pistachio appear to
support full duplex. Therefore, remove the use of spi_xfer_two_vectors().
For mediatek/mt8173 and qualcomm/ipq40xx, the driver is written in such
a way that it does not support full duplex. Remove the use of
spi_xfer_two_vectors() and explicitly error out when a full duplex
transaction is requested.
Change-Id: I8689bc9bb2b27563d25e9f165487d38881c0b059
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25742
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Removed 33KB hole in SSRAM
TEST=build & run
Change-Id: I6851860f878d9a0688975fa855980870d657ee1a
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25391
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST=build
Change-Id: Ie54e310a94f61b8d86c13261937015e3f5a2ab01
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The rationale is to allow the mainboard to override the default
baudrate for instance by sampling GPIOs at boot.
A new configuration option is available for mainboards to select
this behaviour. It will then have to define the function
get_uart_baudrate to return the computed baudrate.
Change-Id: I970ee788bf90b9e1a8c6ccdc5eee8029d9af0ecc
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
These typos were found through manual review and grep.
Change-Id: I6693a9e3b51256b91342881a7116587f68ee96e6
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/23706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Allows explicit ordering for vendors that share a common configuration
that must be sourced last.
The issue is that chips in soc/{amd,intel}/[ab].* will be able to
override defaults set in this file, but Kconfig files that get sourced
later (soc/amd/[d-z].*) will NOT be able to override these defaults.
Note: intel and amd soc chips now need to be added manually to the new
Kconfig file
BUG=b:62235314
TEST=make lint-stable
Change-Id: Ida82ef184712e092aec1381a47aa1b54b74ed6b6
Signed-off-by: Chris Ching <chingcodes@google.com>
Reviewed-on: https://review.coreboot.org/22123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There have been discussions about removing this since it does not seem
to be used much and only creates troubles for boards without defaults,
not to mention that it was configurable on many boards that do not
even feature uart.
It is still possible to configure the baudrate through the Kconfig
option.
Change-Id: I71698d9b188eeac73670b18b757dff5fcea0df41
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Split `i2c.h` into three pieces to ease reuse of the generic defi-
nitions. No code is changed.
* `i2c.h` - keeps the generic definitions
* `i2c_simple.h` - holds the current, limited to one controller driver
per board, devicetree independent I2C interface
* `i2c_bus.h` - will become the devicetree compatible interface for
native I2C (e.g. non-SMBus) controllers
Change-Id: I382d45c70f9314588663e1284f264f877469c74d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our current struct for I2C segments `i2c_seg` was close to being compa-
tible to the Linux version `i2c_msg`, close to being compatible to SMBus
and close to being readable (e.g. what was `chip` supposed to mean?) but
turned out to be hard to fix.
Instead of extending it in a backwards compatible way (and not touching
current controller drivers), replace it with a Linux source compatible
`struct i2c_msg` and patch all the drivers and users with Coccinelle.
The new `struct i2c_msg` should ease porting drivers from Linux and help
to write SMBus compatible controller drivers.
Beside integer type changes, the field `read` is replaced with a generic
field `flags` and `chip` is renamed to `slave`.
Patched with Coccinelle using the clumsy spatch below and some manual
changes:
* Nested struct initializers and one field access skipped by Coccinelle.
* Removed assumption in the code that I2C_M_RD is 1.
* In `i2c.h`, changed all occurences of `chip` to `slave`.
@@ @@
-struct i2c_seg
+struct i2c_msg
@@ identifier msg; expression e; @@
(
struct i2c_msg msg = {
- .read = 0,
+ .flags = 0,
};
|
struct i2c_msg msg = {
- .read = 1,
+ .flags = I2C_M_RD,
};
|
struct i2c_msg msg = {
- .chip = e,
+ .slave = e,
};
)
@@ struct i2c_msg msg; statement S1, S2; @@
(
-if (msg.read)
+if (msg.flags & I2C_M_RD)
S1 else S2
|
-if (msg.read)
+if (msg.flags & I2C_M_RD)
S1
)
@@ struct i2c_msg *msg; statement S1, S2; @@
(
-if (msg->read)
+if (msg->flags & I2C_M_RD)
S1 else S2
|
-if (msg->read)
+if (msg->flags & I2C_M_RD)
S1
)
@@ struct i2c_msg msg; expression e; @@
(
-msg.read = 0;
+msg.flags = 0;
|
-msg.read = 1;
+msg.flags = I2C_M_RD;
|
-msg.read = e;
+msg.flags = e ? I2C_M_RD : 0;
|
-!!(msg.read)
+(msg.flags & I2C_M_RD)
|
-(msg.read)
+(msg.flags & I2C_M_RD)
)
@@ struct i2c_msg *msg; expression e; @@
(
-msg->read = 0;
+msg->flags = 0;
|
-msg->read = 1;
+msg->flags = I2C_M_RD;
|
-msg->read = e;
+msg->flags = e ? I2C_M_RD : 0;
|
-!!(msg->read)
+(msg->flags & I2C_M_RD)
|
-(msg->read)
+(msg->flags & I2C_M_RD)
)
@@ struct i2c_msg msg; @@
-msg.chip
+msg.slave
@@ struct i2c_msg *msg; expression e; @@
-msg[e].chip
+msg[e].slave
@ slave disable ptr_to_array @ struct i2c_msg *msg; @@
-msg->chip
+msg->slave
Change-Id: Ifd7cabf0a18ffd7a1def25d1d7059b713d0b7ea9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is in preparation to get rid of the strong spi_setup_slave
implemented by different platforms.
BUG=b:38430839
Change-Id: I6cc8c339e008e16449fa143c1d21e23534bdaf0b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
spi_crop_chunk is a property of the SPI controller since it depends
upon the maximum transfer size that is supported by the
controller. Also, it is possible to implement this within spi-generic
layer by obtaining following parameters from the controller:
1. max_xfer_size: Maximum transfer size supported by the controller
(Size of 0 indicates invalid size, and unlimited transfer size is
indicated by UINT32_MAX.)
2. deduct_cmd_len: Whether cmd_len needs to be deducted from the
max_xfer_size to determine max data size that can be
transferred. (This is used by the amd boards.)
Change-Id: I81c199413f879c664682088e93bfa3f91c6a46e5
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19386
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: coreboot org <coreboot.org@gmail.com>
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some Chrome OS boards previously didn't have a hardcoded vboot
configuration (e.g. STARTS_IN_BOOTBLOCK/_ROMSTAGE, SEPARATE_VERSTAGE,
etc.) selected from their SoC and mainboard Kconfig files, and instead
relied on the Chrome OS build system to pass in those options
separately. Since there is usually only one "best" vboot configuration
for a certain board and there is often board or SoC code specifically
written with that configuration in mind (e.g. memlayout), these options
should not be adjustable in menuconfig and instead always get selected
by board and SoC Makefiles (as opposed to some external build system).
(Removing MAINBOARD_HAS_CHROMEOS from Urara because vboot support for
Pistachio/MIPS was never finished. Trying to enable even post-romstage
vboot leads to weird compiler errors that I don't want to track down
now. Let's stop pretending this board has working Chrome OS support
because it never did.)
Change-Id: Ibddf413568630f2e5d6e286b9eca6378d7170104
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19022
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Adding spi_xfer_two_vectors as .xfer_vector for ipq40xx spi_ctrlr.
Commit c2973d196d ("UPSTREAM: spi: Get rid of SPI_ATOMIC_SEQUENCING")
has added a new driver method xfer_vector to support combined write-read
operation within a single CS cycle. The method is wrapped in the
spi_xfer_vector() API. When spi_ctrlr structure does not have
xfer_vector method, API calls write and read operations sequentially.
However the QCA40xx SPI driver has "forced" CS activation-inactivation
in xfer method, so individual operation will break CS after write
operation, making combined write-read cycle broken.
Adding xfer_vector method to spi_ctrlr is a simple fix to prevent this.
BUG=None
BRANCH=none
TEST=built and run on Gale
Change-Id: I2258e563d0793bcacd626f78b8e96b3649a8e4a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 88a8824951cef4fe293dfa6e3a1a837ae07b6156
Original-Change-Id: I031e85ce5b847353cb1084f6f68b2af8c6f702e1
Original-Signed-off-by: Yuji Sasaki <sasakiy@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/433439
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/18297
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Martin Roth <martinroth@google.com>
SPI_ATOMIC_SEQUENCING was added to accomodate spi flash controllers with
the ability to perform tx and rx of flash command and response at the
same time. Instead of introducing this notion at SPI flash driver layer,
clean up the interface to SPI used by flash.
Flash uses a command-response kind of communication. Thus, even though
SPI is duplex, flash command needs to be sent out on SPI bus and then
flash response should be received on the bus. Some specialized x86
flash controllers are capable of handling command and response in a
single transaction.
In order to support all the varied cases:
1. Add spi_xfer_vector that takes as input a vector of SPI operations
and calls back into SPI controller driver to process these operations.
2. In order to accomodate flash command-response model, use two vectors
while calling into spi_xfer_vector -- one with dout set to
non-NULL(command) and other with din set to non-NULL(response).
3. For specialized SPI flash controllers combine two successive vectors
if the transactions look like a command-response pair.
4. Provide helper functions for common cases like supporting only 2
vectors at a time, supporting n vectors at a time, default vector
operation to cycle through all SPI op vectors one by one.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: I4c9e78c585ad95c40c0d5af078ff8251da286236
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17681
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Define a new structure spi_ctrlr that allows platforms to define
callbacks for spi operations (claim bus, release bus, transfer).
2. Add a new member (pointer to spi_ctrlr structure) in spi_slave
structure which will be initialized by call to spi_setup_slave.
3. Define spi_claim_bus, spi_release_bus and spi_xfer in spi-generic.c
which will make appropriate calls to ctrlr functions.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Icb2326e3aab1e8f4bef53f553f82b3836358c55e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17684
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For spi_setup_slave, instead of making the platform driver return a
pointer to spi_slave structure, pass in a structure pointer that can be
filled in by the driver as required. This removes the need for platform
drivers to maintain a slave structure in data/CAR section.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia15a4f88ef4dcfdf616bb1c22261e7cb642a7573
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17683
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Use size_t instead of unsigned int for bytes_out and bytes_in.
2. Use const attribute for spi_slave structure passed into xfer, claim
bus and release bus functions.
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: Ie70b3520b51c42d750f907892545510c6058f85a
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17682
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RW flag was added to spi_slave structure to get around a requirement on
some AMD flash controllers that need to group together all spi volatile
operations (write/erase). This rw flag is not a property or attribute of
the SPI slave or controller. Thus, instead of saving it in spi_slave
structure, clean up the SPI flash driver interface. This allows
chipsets/mainboards (that require volatile operations to be grouped) to
indicate beginning and end of such grouped operations.
New user APIs are added to allow users to perform probe, read, write,
erase, volatile group begin and end operations. Callbacks defined in
spi_flash structure are expected to be used only by the SPI flash
driver. Any chipset that requires grouping of volatile operations can
select the newly added Kconfig option SPI_FLASH_HAS_VOLATILE_GROUP and
define callbacks for chipset_volatile_group_{begin,end}.
spi_claim_bus/spi_release_bus calls have been removed from the SPI flash
chip drivers which end up calling do_spi_flash_cmd since it already has
required calls for claiming and releasing SPI bus before performing a
read/write operation.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Idfc052e82ec15b6c9fa874cee7a61bd06e923fbf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17462
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
3ms delay was found in testing to be sufficient for
qup_i2c_write_fifo_flush(), but 1 additional ms was added to give
additional headroom.
Change the Delay from 10ms to 4ms.
BUG=b:28942403
TEST=Boot up Gale board and the TPM functions normally.
BRANCH=None
Change-Id: I6821e2a101cc44e11d74eb6a6215aa9b848ae8c6
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: d93520fab15c5695ea18db21d0f3b24a108f204d
Original-Change-Id: I202f5b8a1ef62bb039c56ba5a25b48b205cf4a67
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/357961
Original-Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: SARAVANAKUMAR SUDALAI <ssudalai@qti.qualcomm.com>
Reviewed-on: https://review.coreboot.org/16126
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In FIFO mode, the I2C driver was not able to fetch
more than 32 bytes of data from the TPM device. Switch to
block mode to be able to read more data.
BUG=chrome-os-partner:51096
TEST=TPM commands succeed
BRANCH=None
Change-Id: Ib52a1b03667f61a08ce048d38407a5b60abf660d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: fbcd40dc67d796d3e31675bd35321282667fe9fa
Original-Change-Id: I765b76f9d7743f6d387470de594fb6eee99e08ca
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357960
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16051
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
EVT1 has two board IDs.
Use binary first mode of base3 encoding for board ID.
BUG=chrome-os-partner:55320
TEST=None.
BRANCH=None
Change-Id: I1cac1f74207f42616111d39db5c0494b7d1a0fb2
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2b16cc74c4c147315b7db345678bbaf536ab4a7b
Original-Change-Id: I6e95c7be4a6d28a0aae38b0838bd2ab71d288ba1
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/364623
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
Reviewed-on: https://review.coreboot.org/16030
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use
of verified boot library without having to stick to CHROMEOS.
BUG=chrome-os-partner:55639
Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15867
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix the board ID handling.
Recovery switch and WP status GPIO has been reassigned in board rev3.
Configure related GPIOs based on Board ID.
BUG=chrome-os-partner:55320
TEST=Verified GPIO assignment for Rev.1 board.
BRANCH=None
Change-Id: Id8e1ba1c039f8b5b503f0da038e5cfc84b72678f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: d295ab514e31d9ebd1b77e0af9b769e64cbf567e
Original-Change-Id: I6d3d5df2e9017f7845edc3cd0b2c19ad7c58a97c
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/361393
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/15809
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I195fd3a9c7fc07c35913342d2041e1ffef110466
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15549
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
TPM should be only be reset once in verstage.
BUG=chrome-os-partner:51096
TEST=Depthcharge no longer shows TPM error.
BRANCH=None
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Commit-Id: 911bdaa83a05fa5c8ea82656be0ddc74e19064c3
Original-Change-Id: I52ee6f2c2953e95d617d16f75c8831ecf4f014f9
Original-Reviewed-on: https://chromium-review.googlesource.com/343537
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8047b7ba44c604d97a662dbf400efc9eea2c7719
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14845
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The origin of UART config is less interesting than having the config be
correct.
Change-Id: I834e3a54105a8fd7d62f388e4a9ad0992ecec807
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14767
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
The code needs to know what kind of part the SoC is, but the question
was weirdly phrased and also exposed to the user (instead of being a
silent "select" to do in a board).
Change-Id: I0344c528d86ac047fc49ccff9e149865bbd4b481
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14766
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
BUG=none
BRANCH=none
TEST=compiled
Change-Id: I125585e33783a39194bb12b2dd746bb968da5fee
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6f986e57bc1ce341e1b0ae6a419d4bbe0f169aa
Original-Change-Id: Ife4cde2318e007a76c978973c13bbce583d082a8
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/343556
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14760
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Rename Ipq806xLcc* to IpqLcc*.
Change-Id: Ib235c1cdb36bb007a673133f59026863990e1a6f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14752
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Increase the HEAP size to handle large vpd data.
BUG=chrome-os-partner:50499
TEST=board with vpd data no longer showing out of memory error
BRANCH=none
Change-Id: Ia0793a626c3500c3469c608bae987ae15a176016
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 12090652d2b70ec553a4f59fe9917a1b3b204579
Original-Change-Id: I1ead4c104b27cf678c68132b0ab08e32c15790b2
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/340267
Original-Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Clear the crash dump cookie set by SBL to indicate that
it is a normal reset.
Inform DDR image of the entrypoint for SDI image to be
preserved in OCIMEM which will be needed during watchdog
resets.
BUG=chrome-os-partner:49249
TEST=DDR image is able to fetch the entry point address
BRANCH=none
Change-Id: I3e6e4a108585bb257e3ad02956c420acbcb2554e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd726256a5ae89672810b57e1d2a7a9287f60627
Original-Change-Id: Id6e09516209f47c3ea8fa3d8d90440789b395660
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333321
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Able to talk to the TPM device and the commands
seem to succeed.
BUG=chrome-os-partner:49249 chrome-os-partner:49250
TEST=All commands to the TPM succeed
BRANCH=none
Original-Commit-Id: c13900108f524c8422c38dee88469c8bfe24d0bd
Original-Change-Id: Ie8c3c1ab1290cd8d7e6ddd1ae22f765c7be81019
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333314
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
squashed:
soc/qualcomm/ipq40xx: Add support for BLSP QUP SPI
- Enable BLSP SPI driver for ipq40xx
- supports only FIFO mode
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: 0714025975854dd048d35fe602824ead4c7d94e9
Original-Change-Id: If809b0fdf7d6c9405db6fd3747a3774c00ea9870
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333303
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ia518af5bfc782b08a0883ac93224d476d07e2426
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Without monotonic timer support, timer related APIs like
timer_monotonic_get etc. are optimized out by the compiler. This
results in timed loops to become indefinite loops
stopwatch_init_msecs_expire(...);
do {
something();
} while (!stopwatch_expired(...));
In our specific case, loops sampling the recovery/wipeout button
in src/mainboard/google/gale/chromeos.c:get_switch_state() turned
into infinite loops and the boot didn't proceed.
BUG=chrome-os-partner:49249
TEST=Confirmed that the loop breaks per the specified timeout
using the minicom's console log time stamps
[2016-04-11 12:34:37] recovery button pressed
[2016-04-11 12:34:45] wipeout requested, checking recovery
[2016-04-11 12:34:53] recovery requested
BRANCH=none
Change-Id: I7ed2616c50ebb28b43ad769d3105f7d4e31b1114
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e00f888570b577849cb526220ffe6f22fe9d2ece
Original-Change-Id: Ic0b800558ebce482da6321c30dbf732080b82941
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/339873
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/14673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This file had the memory regions applicable to ipq806x.
Update the regions as applicable to ipq40xx.
BUG=chrome-os-partner:49249
TEST=Able to boot on DK04 board
BRANCH=none
Change-Id: I0d782eb70fd62c6bf92f9fac39d2e42e9af82012
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6a088c2666cf5be52358bb4271b45cb65d11f7c
Original-Change-Id: I4fb3ca7fb168813d8871bfb87d475fd09d1a9d97
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333310
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14670
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Change-Id: I7c58fe7dc0132e8c01163fc049217f07081c658a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d746b667e309fd8eec62cf84e4ea4006ab2984f0
Original-Change-Id: Idcb3189a812e75815eb15a61c1de273b5e218875
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333305
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14669
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This is stale code from ipq806x, n/a for ipq40xx.
Hence removing it.
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Change-Id: I2ac73677f77d4bfbc70f56c73a661cc2c22dd384
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f9796588648bc477f118282aad89037f0577f23
Original-Change-Id: I8bcf928ee23ac24a21b0e633e207354ea9fa0511
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333299
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14664
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: 35c0e6046899dc1af03736ae9fa77f9eeec7f668
Original-Change-Id: I681e92fa673c1d3aee2974a7bba5074e2bfd6e02
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333297
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
squashed:
soc/qualcomm/ipq40xx: Enable UART on ipq40xx
- BLSP/UART Clock configuration
- GPIO Configuration
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: 7bba1fc7f50e7aeb4e7b37f164e85771e53f47e6
Original-Change-Id: I474a0e97b24ac9b3f2cba599cd709b6801b08f91
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333300
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5e31d036ee7ddcf72ed9739cef1f7f7d0ca6c427
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14667
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
DRAM initialization on gale requires ipq blobs to be
loaded from cbfs. vboot_locator first checks cbmem_find to see if cbmem is
initialized and contains selected region info, else it falls back to
vboot work buffer.
Since cbmem_find calls into cbmem_top to identify the location of
cbmem area, board/chipset is expected to return NULL until the backing
store is ready, which in this case until DRAM is initialized in
romstage, return NULL for cbmem_top.
BUG=chrome-os-partner:49249
TEST=Able to compile and boot to depthcharge. Doesn't crash in
imd_handle_init_partial_recovery
BRANCH=none
Change-Id: Iaac24252ee4fb9f59d767730bf9dd68baa42a68f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4849c15dee2d3782ede4ee4157e432bd4d5602f0
Original-Change-Id: I3722b7ab5a6585a250138c828eb3d7919b0c1178
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/335425
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14660
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Update the memory to map to align with the internal memory region
map of IPQ40XX
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: e33712a729ef9831508c2e9aae81d0b32495b681
Original-Change-Id: Iba1c5281a2fbda4ab96126676b901ba71f6b28e0
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333295
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
squashed:
soc/qualcomm/ipq40xx: Update DRAM address ranges
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: 9150c125cb82f8dccb1347d898106703d85a5192
Original-Change-Id: Ic48d3e3f46a7c13a009a5cbed20984bd253eb85b
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333296
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iea40484751a1c0439ed511319ef09a0254eba757
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14654
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This avoids issues the Makefile can have when running the createxbl.py
script directly.
BUG=none
BRANCH=none
TEST="emerge-gale coreboot" works
Change-Id: I78b6b0cd4d64c022cbe02fc40202da382e1f1ec7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5351abafcc4bfe5de74d3242a907e86d3aa94bbd
Original-Change-Id: I87b8c9991cfc4d5a14903ec565e6a05281b00c82
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/338652
Reviewed-on: https://review.coreboot.org/14653
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Copy 'ipq806x' files as a template
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: dc6a5937953fe61cd4b5a99ca49f9371c4b712d4
Original-Change-Id: If171fcdd3b0561cb6b7dab5f8434de7ef711ea41
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/333178
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
squashed:
soc/qualcomm/ipq40xx: Update ipq806x/storm references
Since the files were taken from ipq806x/storm as
template. Update those references to reflect
ipq40xx/gale.
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Original-Commit-Id: c6c76d184cc92c09e6826fbdc7d7fac59b2cb69b
Original-Change-Id: Ieae1bce25291243b4a6034d37a6949978f318997
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333293
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ie5794c48131ae562861074b406106734541880d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14644
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
DRAM initialization on storm requires ipq blobs to be
loaded from cbfs. vboot_locator first checks cbmem_find to see if cbmem is
initialized and contains selected region info, else it falls back to
vboot work buffer.
Since cbmem_find calls into cbmem_top to identify the location of
cbmem area, board/chipset is expected to return NULL until the backing
store is ready, which in this case until DRAM is initialized in
romstage, return NULL for cbmem_top.
Change-Id: I1880ce61dcfdabaa527d7a6dcc3482dfe5d5fd17
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This just updates existing guard name comments on the header files
to match the actual #define name.
As a side effect, if there was no newline at the end of these files,
one was added.
Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently the CBFS mmap cannot be accessed at the beginning of romstage
because it waits until DRAM is initialized. This change first loads CBFS
into SRAM and then switches to using DRAM as the backing once it is
initialized.
BUG=chromium:210230
BRANCH=none
TEST=confirm that the cbfs can be access at the beginning and end of
romstage on different boards.
Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83
Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796
Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312577
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently coreboot expects the loader to clear the bss section
for all stages. i.e. stages don't clear their own bss. On ARM
SoCs the BootROM would be responsible for this. To do that
one needs to include the bss section data (all zeros) in the
bootblock.bin file. This was previously being attempted by
keeping the .bss info in the .data section because objcopy
happened zero out non-file allocated data section data.
Instead go back to linking bootblock with the bss section
but mark the bss section as loadable allocatable data. That
way it will be included in the binary properly when objcopy
-O binary is emplyed. Also do the same for the data section
in the case of no non-zero object values are in the data
section.
Without this change the trick of including .bss in .data
was not working when there wasn't a non-zero value object
in the data section.
BUG=None
BRANCH=None
TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains
the cleared bss.
Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add CHROMEOS dependencies to selects for the following Kconfig
symbols:
CHROMEOS_RAMOOPS_DYNAMIC
CHROMEOS_RAMOOPS_NON_ACPI
CHROMEOS_VBNV_CMOS
CHROMEOS_VBNV_EC
CHROMEOS_VBNV_FLASH
EC_SOFTWARE_SYNC
LID_SWITCH
RETURN_FROM_VERSTAGE
SEPARATE_VERSTAGE
VBOOT_DISABLE_DEV_ON_RECOVERY
VBOOT_EC_SLOW_UPDATE
VBOOT_OPROM_MATTERS
VBOOT_STARTS_IN_BOOTBLOCK
WIPEOUT_SUPPORTED
This gets rid of these sorts of Kconfig errors:
warning: BOARD_SPECIFIC_OPTIONS selects CHROMEOS_VBNV_EC which has
unmet direct dependencies (MAINBOARD_HAS_CHROMEOS && CHROMEOS)
Note: These two boards would never actually have CHROMEOS enabled:
intel/emeraldlake2 has MAINBOARD_HAS_CHROMEOS commented out
google/peach_pit doesn't have MAINBOARD_HAS_CHROMEOS
Change-Id: I51b4ee326f082c6a656a813ee5772e9c34f5c343
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
One kilobyte of SRAM needs to be allocated and the feature enabled.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=timer error messages do not show up in the coreboot log any more
Change-Id: I1d5e5521bf9ae495d4f4f50ff017c846a8420719
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffb9bfb0cdfab1391f8ae07669a2ab6b24d88dd7
Original-Change-Id: I60066672334db36f5e7adbef6794d7afd177d292
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235893
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10847
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
An old Kconfig symbol from Chrome OS survived into the Makefile (but is
nowhere declared or used). Use the same symbol as for uart.c in the other
stages.
Change-Id: I7a6f1b82254e888d6f2d65d6cff87c4d546ec097
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10703
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
vboot configuration (separate stage or not, which stage loads romstage)
depends on SoC properties (eg. amount of SRAM), not on board specifics, so
move this part of the configuration to the SoC.
Change-Id: I70b4cd1794ddf2aba7cdae94859ea1d76ae019f4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CBFS size is really mainboard specific, since it really depends on
size of the chip on the mainboard, so it makes sense to have it in
the mainboard menu along with the ROM-chip size.
- Move the CBFS_SIZE definition up in src/kconfig
- Move the Mainboard Menu markers out of src/mainboard/kconfig into
src/Kconfig so CBFS_SIZE can live in the mainboard menu.
- Add a long list setting default values to do what the chipset
directories were previously defaulting the values to. This will
be trimmed down in a following patch that creates a common set of
IFD routines. (Who knew that kconfig supported line wrapping?)
- Update the help text.
Change-Id: I2b9eb5a6f7d543f57d9f3b9d0aa44a5462e8b718
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10610
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The RPM initialization Acknowledge is cleared by writing 1
into bit-10 of the RPM_INT_ACK register.
The existing code got it wrong and is writing zero to that bit.
BRANCH=storm
BUG=chrome-os-partner:39231
TEST=with this patch and an RPM firmware update, an SP4 device
survived more than 1000 reboots in a row.
Change-Id: Ibba296ed0571ad9403a0c51c7f82f07f185b4e83
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 13b4a0f093ba652ad6bccdfc4b3686c0741c6fe7
Original-Change-Id: I39e6ea50e0f66b4af68bdb868dd4437c34bb4524
Original-Signed-off-by: Viswanath Kraleti <vkraleti@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/266969
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Reviewed-on: http://review.coreboot.org/10310
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
DYNAMIC_CBMEM is only selected a couple of times but never declared
or read. Remove it.
Change-Id: I5016dac2c935d3f261001e9f388a8989540e93ae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "drop
in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BOARD_ID functionality is not what requires the GPIO lib,
but it is the mainboard specific implementations that do.
The option essentially says whether the SoC provides
<soc/gpio.h> (with the interface required by the common
GPIO code). Right now, x86 and Samsung's Exynos SOCs
don't have support for this interface.
So this should be selected by the SOC, not by
BOARD_ID_SUPPORT.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=none
BRANCH=none
TEST=emerge-storm coreboot still successfully compiled an image
Change-Id: I0ce2bd7ce023f22791d31a6245833b61135504b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0dd4dea521372194eedf11b077d95fd3b15ad9f7
Original-Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d
Original-Reviewed-on: https://chromium-review.googlesource.com/262743
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9899
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DDR init blob version string can be found at a fixed location in
memory once the blob is loaded. Maximum size of the string is 48
bytes.
The RPM RW version is defined in a 32 bit version stored at yet
another fixed address once RPM RW has started.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=ran this command on the booted system:
localhost ~ # egrep '(DDR|RPM)' /sys/firmware/log
Loaded DDR init blob version 99ce41d@-AAABANAZA
DDR initialized
Starting RPM
Started RPM version 1.0.128
localhost ~ #
Change-Id: If3c3c8368845b978605ccfda7e09c21ae2e5ab9a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 328c9c57cf93110bc0fdd267134d72e386d70834
Original-Change-Id: If411f6f7bca53ea20390b7e851cb3d120681eade
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/256738
Original-Reviewed-by: Varadarajan Narayanan <varada@qti.qualcomm.com>
Reviewed-on: http://review.coreboot.org/9860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SP5 whirlwind is the earliest hardware version equipped with the LED
ring.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=none
Change-Id: I4c90a75911350bafd8ccb8755b2491e9447f285b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3dfee90457295668a2b60d5a1e913caf52557877
Original-Change-Id: I6bffdcc47fe9c72796e3bac44d211f907538ef0b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9857
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some platforms may pass as a parameter the maskrom or vendor startup
code information when calling the bootblock.
Make sure the bootblock startup code saves this parameter for use by
coreboot. As we don't want to touch memory before caches are
initialized, save the passed in parameter in r10 for the duration of
cache initialization.
Added warning comments to help enforcing that cache initialization
code does not touch r10.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=with the rest of the patches applied see the QCA uber-sbl report
in the coreboot console output.
Change-Id: Ic6a09e8c3cf13ac4f2d12ee91c7ab41bc9aa95da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e41584f769eb042604883275b0d0bdfbf5b0d358
Original-Change-Id: I517a79dc95040326f46f0b80ee4e74bdddde8bf4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255144
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com>
Reviewed-on: http://review.coreboot.org/9842
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This describes the structure of the information passed through a
pointer by uber-sbl to be processed by the coreboot bootblock.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=with the rest of the patches applied observed uber-sbl
information added to the coreboot console log.
Change-Id: If04c4ee0ccfda3df45bd22eb576aaa5b51f1c4b5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ed39e2bcd793fd490416b407f627b5a9a86b8f78
Original-Change-Id: I1dffbf4559853a818e81ca5fdeff013cf008dd6a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255143
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com>
Reviewed-on: http://review.coreboot.org/9841
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a manual cleanup of all the rubble left by coccinelle
waltzing through our code base. It's generally not very good with line
breaks and sometimes even eats comments, so this patch is my best
attempt at putting it all back together.
Also finally remove those hated writel()-style macros from the headers.
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d
Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254865
Reviewed-on: http://review.coreboot.org/9837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch changes the argument order for the (now temporarily unused)
write32() accessor macro (and equivalents for other lengths) from
(value, address) to (address, value) in order to conform with the
equivalent on x86. Also removes one remaining use of write32() on ARM
that slipped through since coccinelle doesn't inspect header files.
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: Id5739b144f6a5cfd40958ea68510dcf0b89fbfa9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f02cae8b04f2042530bafc91346d11bb666aa42d
Original-Change-Id: Ia91c2c19d8444e853a2fc12590a52c2b6447a1b9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to the
directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>,
src/soc/<arm(64)-soc> and src/drivers/gic:
@@
expression A, V;
@@
- write32(V, A)
+ writel(V, A)
@@
expression A, V;
@@
- write16(V, A)
+ writew(V, A)
@@
expression A, V;
@@
- write8(V, A)
+ writeb(V, A)
This replaces all uses of write{32,16,8}() with write{l,w,b}()
which is currently equivalent and much more common. This is a
preparatory step that will allow us to easier flip them all at once to
the new write32(a,v) model.
BRANCH=none
BUG=chromium:451388
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24
Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254862
Reviewed-on: http://review.coreboot.org/9834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I2c transfer may consist of multiple segments (for instance write
segment to set the register address and then a read segment to read
the register value). Transfer should be stopped as soon as a segment
processing error has been reported.
BRANCH=master
BUG=chrome-os-partner:35328
TEST=transfer shall not process the read segment when the write segment fails
Change-Id: I85b7b59b376ce33ba3f6d2526be86e9f6585d97b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 50cd4d40851b3cea99183c549c47b4486a3deb4a
Original-Change-Id: Id65f995d860dd670b289fbdd9eb0ca19a50d7007
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254494
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The qup_i2c_write_fifo() made to query QUP_I2C_MASTER_STATUS after QUP
transitions into PAUSE state to ensure that it captures the correct status.
Handled more error bits.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:35328
TEST=Booted up storm P0.2, verified that the TPM on GSBI1 works.
Verified that SUCCESS is not reported when the write FIFO has failed.
Change-Id: Ia91638d37b3fa8449630aa2cf932114363b2db78
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75e0d59d2e6ba03182003f22944dbf99ce3eb412
Original-Change-Id: Ic4e8e85686499ce71ad3258b52e687ceff36a1f8
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254495
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9823
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ipq806x UART is based on the same universal serial port which can
be also configured as i2c or SPI. Configuring it is not a trivial
task, so in case the kernel wants to use earlyprintk() the port needs
to be configured by the firmware.
Invoking uart_init() when the console is not enabled causes include
file collisions, which would require changes to more than 100 files.
Leaving this to another day, rearranging the ipq806x driver to be able
to invoke UART initialization function even when serial console is not
configured.
Also add a check to avoid initialization if UART has been already
set up.
BRANCH=storm
BUG=chrome-os-partner:35364
TEST=verified that storm console is still fully operational when
enabled, and that the kernel boots fine to the serial console
login prompt even if the firmware console is disabled.
Change-Id: Ibbbab875449f2ac2f0d6c504c18faf0da8251ffa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c512d6c1d0c0868137d1213ea84cd4bca58872db
Original-Change-Id: I421acba3edf398d960b5058f15d1abb80ebc7660
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240516
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Originally ported QCA UART driver used hardware accessor macros where
both address and data were represented by 32 bit integers. Coreboot
uses macros where addresses are represented by pointers, this make the
code more robust, as accidental swap between address and data does not
go unnoticed.
This patch converts ipq806x UART driver to use coreboot accessors. It
relies on gcc void pointer arithmetic considering objects pointed at
by void pointers to be one byte in size. Also replacing spaces with
hard tabs where appropriate.
BRANCH=storm
BUG=chrome-os-partner:34790
TEST=new code still boots fine on Storm with console output present.
Change-Id: I3ded9c338ff241bb1d839994f7296756aad8772d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10616351704ebbcfcf25793ae974b256bc5bd6b0
Original-Change-Id: Ie15e09f9f3ea10a8566b6845219c2e09fed39218
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240514
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Reviewed-on: http://review.coreboot.org/9793
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That function requirement was added upstream but not in Chromium, so
add an implementation.
Change-Id: Ie384b315adb205586defa730b843c7c8e96f77fb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9776
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GSBI driver is extended to be able to program the CTRL reg for any given
GSBI block. The NS and MD registers programming is made more readable by
programming the M, N, D and other bits of the registers individually.
Defined configure structs for each QUP block to be able to track the init
status for each qup.
Configured GPIO8 and GPIO9 for I2C fuction.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:36722
TEST=Booted up storm P0.2, verified that the TPM on GSBI1 still works.
Change-Id: I17906beedef5c80267cf114892080b121902210a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 07bc79211770decc1070c3a88874a4e452b8f5bc
Original-Change-Id: I841d0d419f7339f5e5cb3385da98786eb18252ad
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250763
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9759
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a clock control driver to initialize the clock tree inside the
low-power audio subsystem. Depthcharge builds up on this to enable
audio function on storm.
The clock is hardcoded for 48KHz frame rate, two 16 bit channels.
BRANCH=storm
BUG=chrome-os-partner:35247
TEST=with depthcharge patches applied and Using depthcharge CLI audio
test program verified that the target generates sensible sounds
audio 100 100
audio 1000 5000
Change-Id: I56513fc782657ade99b6e43b2d5d3141d27ecc4e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0d4f408408aa38b2f0ee19b83ed490de39074760
Original-Change-Id: If8ffc326698fcea17e05d536930d927ca553481f
Original-Signed-off-by: Kenneth Westfield <kwestfie@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/248830
Original-Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: http://review.coreboot.org/9758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 4 byte offset value will be stored in SRAM and shared between
different coreboot stages.
BRANCH=storm
BUG=chrome-os-partner:3416, chromium:445938
TEST=with the rest of the patches in, storm successfully boots into
Linux login prompt
Change-Id: Id8df75b0c679e274532660d55410291e59f3b520
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8f2f7cf6263f4c2db70b1c87ec67f6b0308059b3
Original-Change-Id: I1ebfada93e222992300cd695d04669988206d4b1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237660
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Prudhvi Yarlagadda