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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
