Age | Commit message (Collapse) | Author |
|
This adds a common cbmem_top implementation to all coreboot target.
In romstage a static variable will be used to cache the result of
cbmem_top_romstage.
In ramstage if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is set a global variable
needs to be populated by the stage entry with the value passed via the
calling arguments. if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is not set the
same implementation as will be used as in romstage.
Change-Id: Ie767542ee25483acc9a56785ce20a885e9a63098
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I9c1228d3f9e7a12fe30c48e3b1f143520fed875c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Initialize the input_hertz and uart_pci_addr fields of the lb_serial
struct to prevent later undefined reads in lb_add_serial(). This was
done for exynos5420 in commit ff94e00362 (soc/samsung/exynos5420/uart.c:
Init new serial struct variables), and this patch finishes the rest.
Note that not all of the drivers can have the UART PCI address
configured at build time, so a follow-up patch will be needed to correct
those ones.
Change-Id: I733bc8185e2f2d28a9823495b53d6b09dce4deb1
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1354778
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34548
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9dbf0fc14516f766fd164c7308906456f2865e89
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34982
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id8918f40572497b068509b5d5a490de0435ad50b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Also remove allwinner/a10 dummy monotonic_timer
implementation.
Change-Id: I9dfa9b92dc63375465e3bb87b73eeefad601c810
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ib843eb7144b7dc2932931b9e8f3f1d816bcc1e1a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/26796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Guckian
|
|
Change-Id: I23bc0191ca8fcd88364e5c08be7c90195019e399
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: David Guckian
|
|
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>
|
|
Change-Id: If5c5ebacd103d7e1f09585cc4c52753b11ce84d0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Until now the TCPA log wasn't working correctly.
* Refactor TCPA log code.
* Add TCPA log dump fucntion.
* Make TCPA log available in bootblock.
* Fix TCPA log formatting.
* Add x86 and Cavium memory for early log.
Change-Id: Ic93133531b84318f48940d34bded48cbae739c44
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
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>
|
|
This is spotted using ./util/lint/kconfig_lint
To work around the issue, rename the prefix from `CONFIG_` to `CONF_`.
Change-Id: Ia31aed366bf768ab167ed5f8595bee8234aac46b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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 removes CEIL_DIV and div_round_up() altogether and
replace it by DIV_ROUND_UP defined in commonlib/helpers.h.
Change-Id: I9aabc3fbe7834834c92d6ba59ff0005986622a34
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/29847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
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>
|
|
Change-Id: I89e03b6def5c78415bf73baba55941953a70d8de
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I40f8b4c7cbc55e16929b1f40d18bb5a9c19845da
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I2f69d9f01ac5f7e28dd98e704f3280bf62b9ce58
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29052
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>
|
|
Change-Id: I21680354f33916b7b4d913f51a842b5d6c2ecef3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Use of device_t has been abandoned in ramstage.
Change-Id: Ibf21100eb2232932ea52740bd5250319d3c9adfa
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
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>
|
|
Also unify __attribute__ ((..)) to __attribute__((..)) and
handle ((__packed__)) like ((packed))
Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/15921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There are many good reasons why we may want to run some sort of generic
callback before we're executing a reset. Unfortunateley, that is really
hard right now: code that wants to reset simply calls the hard_reset()
function (or one of its ill-differentiated cousins) which is directly
implemented by a myriad of different mainboards, northbridges, SoCs,
etc. More recent x86 SoCs have tried to solve the problem in their own
little corner of soc/intel/common, but it's really something that would
benefit all of coreboot.
This patch expands the concept onto all boards: hard_reset() and friends
get implemented in a generic location where they can run hooks before
calling the platform-specific implementation that is now called
do_hard_reset(). The existing Intel reset_prepare() gets generalized as
soc_reset_prepare() (and other hooks for arch, mainboard, etc. can now
easily be added later if necessary). We will also use this central point
to ensure all platforms flush their cache before reset, which is
generally useful for all cases where we're trying to persist information
in RAM across reboots (like the new persistent CBMEM console does).
Also remove cpu_reset() completely since it's not used anywhere and
doesn't seem very useful compared to the others.
Change-Id: I41b89ce4a923102f0748922496e1dd9bce8a610f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19789
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I7945ddb988262e7483da4e623cedf972380e65a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
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>
|
|
Implement writeat and eraseat support into the region_device_ops struct.
Change-Id: Iac2cf32e523d2f19ee9e5feefe1fba8c68982f3d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15318
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I58b2c3c52444d9a755d05529992507086a423f1a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14620
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
coreboot passes information about the serial port implementation to
payloads through a cbtables entry.
We set the register width to 1 on most SoCs because that looked as good
a default as any, but checking the uart structs they use, it's 4 for all
of them.
Change-Id: I9848f79737106dc32f864ca901c0bc48f489e6b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13746
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@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>
|
|
Implement hard_reset() as power_reset() to make
vboot happy.
Change-Id: I16831055bd6ba8a8c95836fcf31f29c068153fcc
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12722
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
Change-Id: Ia7d2cafc958859be782f63c956dbd632e28bcf11
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11101
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I7b177b4c57f8e304167610205196ecfe4beb4fea
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11102
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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 boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10253
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>
|
|
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>
|
|
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>
|
|
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I30b742146069450941164afb04641b967a214d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9738
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
BUG=none
BRANCH=ToT
TEST=Built daisy.
Change-Id: I64033f8e7beb247b2b8bd66e58de6c5e263ee634
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1ff51e887a07a0f2426e5111df683ce2a9d4097d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Id6e006be1db08933dc97b5e797a85f3cbf9f6486
Original-Reviewed-on: https://chromium-review.googlesource.com/232513
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10
Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234061
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch aligns exynos5250 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Daisy.
Change-Id: I39805c0346e117a0f9b2667763ecaa428f0f55a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: db6762f0c8425371d9860f908a5cefdeee8d1abc
Original-Change-Id: Ic358061ddcbbe7d83a95ca11247b8b505b20491d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224500
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9323
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provide finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42
Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219172
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9304
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Instead of open coding monotonic timer usage,
use the stopwatch API.
BUG=None
BRANCH=None
TEST=None
Change-Id: I1c541c1c9f3fde0dec9163ad6cc94322538ac7f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 46ede0897687da6bcf730a8904f25e5a4485d6cd
Original-Change-Id: Ia63a05850a1b6afdc42c2422332f77af516d27e3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219716
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These files were trying to document the parameters, but didn't have
the syntax quite right. Change the comments from @varname to
@param varname as required by doxygen.
Change-Id: I63662094d3f1686e3e35b61925b580eb06e72e28
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8100
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The doxygen parameter names in the comments no longer matched the
functions they were attached to. Doxygen complains about extra
parameter comments and uncommented parameters in the functions.
Change-Id: I21b8a951f8d8d04b07c3779000eeaf1e69fed463
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8101
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Original-Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198791
Original-Reviewed-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f71503dbbd74c5298e90e2163b67d4efe3e89db)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id6c5f75bb5baaabd62b6b1fc26c2c71d9f1ce682
Reviewed-on: http://review.coreboot.org/7947
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
The following patches had to be squashed
to properly build all the different ARM boards.
ipq8064: storm: re-arrange bootblock initialization
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197835
(cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
arm: Redesign mainboard and SoC hooks for bootblock
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57
Reviewed-on: http://review.coreboot.org/7879
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
It's not needed, as we can use a simpler macro instead.
Change-Id: Ib96f5cfa434d0383ee3bfe49995a8f8830987f20
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7925
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Iaacd4d7977ddeff4204acdc32d4d13fd88b6660b
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7928
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Reduce difference with exynos5420/clock.c by fixing some whitespace
and an include directive.
Change-Id: Ifbdd61c8300f3988f5f729fe7d6124ac8a9b7821
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7926
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I06d83be840b49ee7523b34e1dba5ec038256b3f4
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7918
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I272fea9c2767c341e8a545bf7a9ac18eefa2bda5
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7917
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c06c69d580ee3ec0a3892ebf164a5fe)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Iaf2b2873bd1c52d7f936bd9b483e194a0872a626
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7285
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
We had lots of casts that caused warnings when compiling on RISCV.
Clean them up.
Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7066
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds a new static assertion macro that can be used to check
the offsets in structures that overlay register sets at compile time. It
uses the _Static_assert() declaration from the new ISO C11 standard,
which is supported (even without -std=c11) by GCC after version 4.6.
(There is supposedly also support in clang, although I haven't tried
it... let's deal with compiler issues when/if they turn up.)
I've added it to all structures for our current ARM SoCs for now, and I
think every new register overlay we add going forward should use them
(at least for the last member, but feel free to add more if you think
it's useful).
Change-Id: If32510e7049739ad05618d363a854dc372d64386
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179412
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit cef5fa13c31375a316ca4556c0039b17c8ea7900)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6905
Tested-by: build bot (Jenkins)
|
|
Showed up as an error when '--gc-sections' was added as a flag to the
compiler.
Change-Id: I214d3e16a72fca0becc677d7af66097464d64247
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6926
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Patch 12b121f3fef61d introduced an off-by-one error in the offsets of the
PMU register struct, which put both the newly added register and the
PSHOLD that comes after it in the wrong place. This patch corrects the
offsets (5420 had already been correct).
Change-Id: I1d9d31a6a73ee91890824e94fbd247d5feb4f6ae
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179411
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5fdc74bc18bcb1066a0ce3ba94829af1b175173b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit aa3a416705517c0a6ddfdeb19905ac8cafb33df1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The exynos directories had been moved from src/cpu to src/soc, but the name
of the chip_operations structure wasn't updated properly. That meant that the
SOCs never installed their memory resources and the ram stage would fail to
load the payload.
Change-Id: Ib60489b6d3434e3ebd13827a804452f762747f1b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172400
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9100d475ebcc4dae23184583a6cc0162577e70d1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6781
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This minor refactoring patch changes the signature of all limited cache
invalidation functions in coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
(cherry picked from commit d550bec944736dfa29fcf109e30f17a94af03576)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6623
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Exynos family and most ARM products are SoC, not just CPU.
We used to put ARM code in src/cpu to avoid polluting the code base for what was
essentially an experiment at the time. Now that it's past the experimental phase
and we're going to see more SoCs (including intel/baytrail) in coreboot.
Change-Id: I5ea1f822664244edf5f77087bc8018d7c535f81c
Reviewed-on: https://chromium-review.googlesource.com/170891
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit c8bb8fe0b20be37465f93c738d80e7e43033670a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6739
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|