Issue fixed in commit d152837 so don't allow use of _HID and _ADR at same time.
Change-Id: I52beba66230a3542a7039f496b51be0aa4bdcce4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50384
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There seems to be a bug[1] in the GNU linker for the RISC-V architecture
triggered by symbols that are more than 2GB offset from the program
counter. My next patch is introducing symbols like that and stuck on
this problem. The code path that runs into the issue is only taken when
passing the --emit-relocs flag, which is really only needed for building
rmodules. Since RISC-V platforms don't use any rmodules at the moment,
let's disable the flag on RISC-V until the issue can be fixed in the
toolchain.
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27180
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I784a506034325c0ba937589416acaafbf80080e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49449
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They all operate on that file, so just add it globally.
Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Target added to INTERMEDIATE all operate on coreboot.pre, each modifying
the file in some way. When running them in parallel, coreboot.pre can be
read from and written to in parallel which can corrupt the result.
Add a function to create those rules that also adds existing
INTERMEDIATE targets to enforce an order (as established by evaluation
order of Makefile.inc files).
While at it, also add the addition to the PHONY target so we don't
forget it.
BUG=chromium:1154313, b:174585424
TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2
timeout and sercon) and saw that they were executed.
Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When building as part of the coreboot build system, use the same
mechanism as other tools (cbfstool, amdfwtool, ...) so that abuild
builds ifdtool once into sharedutils instead of once per board (while
avoiding other race conditions, too).
Change-Id: I42c7b43cc0859916174d59cba6b62630e70287fd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently, use of the VPD driver to read VPD tables from flash
requires the use of a custom FMAP with one or more VPD regions.
Extend this funtionality to boards using the default FMAP by
creating a dedicated VPD region when the driver is selected.
Test: build qemu target with CONFIG_VPD selected, verify entry
added to build/fmap.fmd.
Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This file was being written to the root src directory. It is the only
file being written to src during a normal build, while all others are
being written to $(obj). I added a new variable to allow specifying the
xcompile path. This allows generating a single file if building multiple
boards. I also moved the default location into $(obj) so we don't
pollute the src directory by default.
I also cleaned up the generation of xcompile by removing the unnecessary
eval and NOCOMPILE check.
I also left .xcompile in distclean so it cleans up stale files.
Since .xcompile is written into $(obj), `make clean` will now remove it.
The tegra Makefiles are outside of the normal build process, so I just
updated those Makefiles to point to the default xcompile location of a
normal build. The what-jenkins-does target had to be updated to support
these special targets. We generate an xcompile specifically for these
targets and pass it into the Makefile. Ideally we should get these
targets added to the main build.
BUG=b:112267918
TEST=ran `emerge-grunt coreboot` and `make what-jenkins-does`
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia83f234447b977efa824751c9674154b77d606b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/28101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
For arch/arm[64], the offsets to board identification strings and
CONFIG_ROM_SIZE inside .id were never really used; it was only a
convenience to have the strings appear near the start of image.
Add the same strings in an uncompressed file in CBFS.
Change-Id: I35d3312336e9c66d657d2ca619cf30fd79e18fd4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47602
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the option to cache DIMM SPD data in an FMAP region
is closely coupled to a single board (google/hatch) and requires
a custom FMAP to utilize.
Loosen this coupling by introducing a Kconfig option which adds
a correctly sized and aligned RW_SPD_CACHE region to the default FMAP.
Add a Kconfig option for the region name, replacing the existing hard-
coded instance in spd_cache.h. Change the inclusion of spd_cache.c to
use this new Kconfig, rather than the board-specific one currently used.
Lastly, have google/hatch select the new Kconfig when appropriate to
ensure no change in current functionality.
Test: build/boot WYVERN google/hatch variant with default FMAP, verify
FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log.
Also tested on an out-of-tree Purism board.
Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
At the moment this was only used for aligning the bootblock to 64
bytes. At the moment this automatically done with
CONFIG_C_ENV_BOOTBLOCK_SIZE.
Change-Id: I0c879119e525b512eebe3f4c5ff9b2f426c6b6ff
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48468
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
When passing $(@) to eval command, $(@) is replaced by empty string,
Also, the $(@) in cbfs-files-processor-struct is a temporary file name,
so we should quote it by an extra '$' or use the arg ($1 or $2)
directly.
For example:
cbfs-files-processor-struct= \
$(eval $(2): $(1) $(obj)/build.h $(KCONFIG_AUTOHEADER); \
# ** $(@) is empty string instead of $(2) **
printf " CC+STRIP $(@) \n"; \
# ** $(1) contains the name of source file **
printf " CC+STRIP $(1) \n"; \
......)
Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: Id6a66e25d7dfe8fe6410e517593ed22a438d2f82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48201
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds optional CBFSTOOL_ADD_CMD_OPTIONS that can be used by
arch/SoC/mainboard Makefiles to supply any additional arguments that
need to be passed into cbfstool when using cbfstool add command.
This is useful when platform wants to add these parameters depending
upon some arch/SoC/mainboard specific configs. Immediate use case is
the fast SPI controller on Intel platforms adding arguments for
extended window base and size.
BUG=b:171534504
Change-Id: I2f48bc3f494d9a5da7e99b530a39d6078b4a881c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47884
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When the global variable of a "struct" CBFS file is zero (for example,
CB:47696), the binary will appear in the .bss* section in the ELF file
(instead of .data). This results in an empty binary file added to CBFS,
so that file size check will fail when reading it at runtime.
BUG=b:173751635
TEST=emerge-asurada coreboot
TEST=Check sdram-lpddr4x-KMDP6001DA-B425-4GB is non-empty in CBFS
BRANCH=none
Change-Id: Idfd17d10101a948de0eb0522a672afd5c2f83b04
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47903
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This can be done using in the INTERMEDIATE target in the proper place.
Change-Id: I28a7764205e0510be89c131058ec56861a479699
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The idea is to split the “mainboard” category into “variants” and
“carrierboards”, in the case when we use the COMe module together
with the Carrier Board instead of a single monolithic motherboard.
Previously, the “variants” category defined the type of motherboard,
which has a number of differences from the base one, for example, it
differed in the size or type of memory, and in the configuration of
the interfaces. Thus, there is no need to create a separate directory
in src/mainboard for a board that is similar in configuration to the
base board. But for a COMe module, “variants” contains different
variants of only this module, and the entire Carrier Board configuration
is allocated to a separate category - “carrierboards”, and each of the
variants can be used with one of the many boards in “carrierboards”.
For example, in the case of the Kontron mAL10 COMe module, variant
refers to the COMe-mAL10 or COMe-m4AL10 module type. They differ in the
type of memory (DDR3L or DDR4), and maybe they differ in some chips (see
more in https://www.kontron.com/products). However, all variants contain
the same type of processor/SoC.
The "carrierboards" directory can be able contain both the Kontron's
Evalution carrier boards (such as Eval Carrier2 T10 and COMe
Ref.Carrier-i T10 TNI) and third party vendor backplanes that are
compatible with the COMe modules from “variants”.
Thus, the src/mainboard/<module-name> directory contains the common
configuration code for all variants from src/mainboard/<module-name>/
variants, which can be supplemented/redefined with a configuration from
src/mainboard/<module-name>/carrierboard/<vendor-carrierboard-name>.
This architectural solution will be able to systematize and simplify
understanding of the code structure for COMe modules and will allow
vendors to add/maintain their code in a separate directory.
This work is also the first step towards to union of all carrierboards
into the global category in src/carrierboard on a par with all boards
from src/mainboard.
The patch takes this into account in the build system and adds
CARRIER_DIR component to use the “carrierboards” category, as it has
done for VARIANT_DIR.
TEST = Build ROM image for Kontron mAL10 COMe module together with T10
TNI carrier board (https://review.coreboot.org/c/coreboot/+/39133).
Change-Id: Ic6b2f8994b1293ae6f5bda8c9cc95128ba0abf7a
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42609
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using the INTERMEDIATE target this can be done in the proper dir.
Change-Id: Ie105231655ef4b49234f0944f638545fe79f07cb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Actual support CBnT will be added later on.
Change-Id: Icc35c5e6c74d002efee43cc05ecc8023e00631e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add some mechanics to automatically have a `qemu` make target for
supported configurations. So with a QEMU target selected in Kconfig,
one would ideally only have to run `make qemu` to test things.
There are some notable variables that can be set or adapted in
`Makefile.inc` files, the make command line or the environment.
Primarily for `Makefile.inc` use:
QEMU-y the QEMU executable
QEMU_CFG-y a QEMU config that sets the available default devices,
used to run more comprehensive tests by default,
e.g. many more PCI devices
For general use:
QEMU_ARGS additional command line arguments (default: -serial stdio)
QEMU_EXTRA_CFGS additional config files that can add devices
QEMU_CFG_ARGS gathers config file related arguments,
can be used to override a default config (QEMU_CFG-y)
Examples:
$ # Run coreboot's default config with additional command line args
$ make qemu QEMU_ARGS="-cdrom site-local/grml64-small_2018.12.iso"
$ # Force QEMU's built-in config
$ make qemu QEMU_CFG_ARGS=
Change-Id: I658f86e05df416ae09be6d432f9a80f7f71f9f75
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently sconfig generates a `static.h` to accompany
`static.c`. However, some payloads may decide they would like to consume
the FW_CONFIG macros as well. The current state of `static.h` makes this
impossible (relying on `device/device.h`).
This patch splits up `static.h` into 3 files: `static.h,
`static_devices.h`, and `static_fw_config.h`. `static.h` simply includes
the other two `.h` files to ensure no changes are needed to other
code. `static_devices.h` contains the extern'd definitions of the device
names recently introduced to sconfig. `static_fw_config.h` contains the
FW_CONFIG_FIELD_* macros only, which makes it easily consumable by a
payload which wishes to use FW_CONFIG.
Also refactor the generation of all these output files, as the code was
getting messy.
Change-Id: Ie0f4520ee055528c7be84d1d1e2dcea113ea8b5f
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The USB4 retimer device needs to declare a _DSM with specific functions
that allow for GPIO control to turn off the power when an external
device is not connected. This driver allows the mainboard to provide
the GPIO that is connected to the power control.
BUG=b:156957424
Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change extends the devicetree override one more layer and allows
the chipset to provide the base devicetree. This allows the chipset to
assign alias names to devices as well as set default register values.
This works for both the baseboard devicetree.cb as well as variant
overridetree.cb.
chipset.cb:
device pci 15.0 alias i2c0 off end
devicetree.cb:
device ref i2c0 on end
BUG=b:156957424
Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add Makefile.inc to compliant with other tools.
Makefile is kept for building amdfwtool by typing make
in the folder.
Change-Id: I3688d93de4459f5f838955892086b4b9bf30a9b8
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45286
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Instead of positional arguments switch sconfig to use getopt and pass
the arguments as options in the build system. This will make it easier
to add additional options.
Change-Id: I431633781e80362e086c000b7108191b5b01aa9d
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44035
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
- Use a new variable to store the list of warning types;
- print this list when building an image.
TEST = build image on Kontron mAL-10 COMe module:
IASL 3150 2158 3133 warning types were ignored!
IASL build/dsdt.aml disassembled correctly.
Change-Id: I46f761612254b400563f8567be9bd61601f23467
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
'-Wstrict-aliasing' is turned on by '-Wall'.
'-Wstrict-aliasing' is only active when -fstrict-aliasing is active, so add it.
'BUILD_TIMELESS=1' on gigabyte/ga-945gcm-s2l gives the same binary.
Change-Id: I51eb8241389f13d2659aef0a3b4b376ce9c651cf
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44216
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When refactoring, one can move code around quite a bit while preserving
reproducibility, unless there is an assert-style macro somewhere... As
these macros use __FILE__ and __LINE__, just moving them is enough to
change the resulting binary, making timeless builds rather useless.
To improve reproducibility, do not use __FILE__ nor __LINE__ inside the
assert-style macros. Instead, use hardcoded values. Plus, mention that
timeless builds lack such information in place of the file name, so that
grepping for the printed string directs one towards this commit. And for
the immutable line number, we can use 404: line number not found :-)
Change-Id: Id42d7121b6864759c042f8e4e438ee77a8ac0b41
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a separate blobs repository for Qualcomm blobs,
analogous to the existing AMD blobs. Qualcomm's binary licenses allow
files to be redistributed and used by anyone, but they explicitly
require the user to agree to the license terms when just *downloading*
the binary (even if they're not using them to build any firmware). Some
community members do not like to have to agree to licenses for files
they're not actually using, so we are keeping these files separate from
the main blobs repository and adding an extra Kconfig to make sure the
user is aware of and must explicitly agree to this before downloading
these files.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I247746c1b633343064c9f32ef1556000475d6c4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The assumption up to this point was that if the system had an x86
processor, verstage would be running on the x86 processor. With running
verstage on the PSP, that assumption no longer holds true, so exclude
pieces of code that cause problems for verstage on the PSP.
This change will add these files to verstage only if the verstage
architecture is X86 - either 32 or 64 bit.
BUG=b:158124527
TEST=Build and boot on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I797b67394825172bd44ad1ee693a0c509289486b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42062
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When adding XIP stages on x86, the -P parameter was used to
pass a page size that covers the entire file to add. The same
can now be achieved with --pow2page and we no longer need to
define a static Konfig for the purpose.
TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and
inspect the generated make.log files. The effective pagesize is
reduced from 64kB to 16kB for asus/p2b giving more freedom
for the stage placement inside CBFS. Pagesize remained at 64kB
for lenovo/x60.
Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Apparently I missed adding this variable definition.
BUG=b:157140753
TEST=Build APCBs with clean tree :)
Fixes: cbaa835f21 ("soc/amd/picasso/Makefile: Use apcb_tool to generate APCBs from SPDs")
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia9055ed3507996cbf78687a97599aab3b0b39d6f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41738
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a target to the top level Makefile that allows
building sconfig and generating static.c/static.h without building
the rest of coreboot.
It also adds $(DEVICETREE_STATIC_C) to the c-deps for each stage so
the files are generated before the build runs.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I4320288422230d8913dfa7cc7b7512775a1a797b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41439
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates FMAP_FMAP_SIZE for non-x86 boards using default
fmd file to be 0x200 just like for x86 boards.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3f58696b26fbb5363d67bec4056653da83485776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When using default fmd files, base of the fmap region is currently
calculated based on the size and base of previous fmap regions. Since
the existence of any fmap region is dependent on the selection of
certain CONFIG_* parameters, these calculations get complicated. Every
time base is calculated for a region, there need to be checks to see
which of the previous regions really exist. As the regions in default
fmd file are increased, these calculations and the conditional checks
get even more complicated.
This change introduces a Makefile variable FMAP_CURRENT_BASE which is
updated every time a new region is allocated space. This allows using
the same steps for determining the base of any fmap region
irrespective of the state of previous regions.
The way the code is organized it should be possible in the future to
also add a macro to perform the same steps (in case that is possible).
TEST=Verified that coreboot image generated remains unchanged for x86
and ARM boards using the default fmd files.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I2a109462928b6e8b7930bbcc1a1ba45fa85de6ac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since SeaBIOS rel-1.7.5 CONFIG_THREAD_OPTIONROMS is not present in its
config. The threaded hardware initialization during optionrom execution
is now controlled with a CBFS file. Add appropriate integer to CBFS when
threaded hardware initialization is selected in coreboot's Kconfig.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I9b5a532b609c6addf31ccdb6be03ff2e937ad326
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The dependency for `ifittool` was missing in the CONFIG_UPDATE_IMAGE
case. Which led us to the question: Why run `ifittool` in this case?
The idea of CONFIG_UPDATE_IMAGE is to update everything _but_ the
bootblock.
Change-Id: I7fd3bd1b56f495b16beb1e1f4b35b8cfcf25b2ba
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39803
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GNU Make 4.3 is more picky about the $(spc) definition. It seems, the
variable ends up empty. The old definition worked for nearly 8 years,
RIP.
Tested with GNU Make 4.2.1 and 4.3.
Change-Id: I7981e0066b550251ae4a98d7b50e83049fc5586a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38790
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The body contains a `#` and GNU make 4.3 disagrees with earlier versions
if it should be treated as a comment. Turn it into a `define` which has
clearer semantics regarding comments (interpretation is supposed to be
deferred until the variable is expanded).
Change-Id: I589542abbd14082c3ecc4a2456ebd809fb6911ea
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38793
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We haven't been able to update IASL in 8 months because of this
conflict. Ignoring it doesn't make things any worse than they are now.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Iced2e55e9f2aa7a262a5c1ffeff32af78acfa35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
According to the C standard, accessing the NULL pointer (memory at
address zero) is undefined behaviour, and so GCC is allowed to optimize
it out. Of course, accessing this memory location is sometimes
necessary, so this optimization can be disabled using
-fno-delete-null-pointer-checks. This is already done in coreboot, but
adding it to xcompile will also disable it for all the payloads. For
example, coreinfo compiled with LTO libpayload crashes when this flag
isn't set, presumably because the compiler is optimizing something out
that it shouldn't.
Change-Id: I4492277f02418ade3fe7a75304e8e0611f49ef36
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38289
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a new commonlib/bsd subdirectory with a similar
purpose to the existing commonlib, with the difference that all files
under this subdirectory shall be licensed under the BSD-3-Clause license
(or compatible permissive license). The goal is to allow more code to be
shared with libpayload in the future.
Initially, I'm going to move a few files there that have already been
BSD-licensed in the existing commonlib. I am also exracting most
contents of the often-needed <commonlib/helpers.h> as long as they have
either been written by me (and are hereby relicensed) or have an
existing equivalent in BSD-licensed libpayload code. I am also
relicensing <commonlib/compression.h> (written by me) and
<commonlib/compiler.h> (same stuff exists in libpayload).
Finally, I am extracting the cb_err error code definitions from
<types.h> into a new BSD-licensed header so that future commonlib/bsd
code can build upon a common set of error values. I am making the
assumption here that the enum constants and the half-sentence fragments
of documentation next to them by themselves do not meet the threshold of
copyrightability.
Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Build the smcbiosinfo tool with other tools.
Fixes possible race condition on jenkins.
Change-Id: I38f7ee2fdef2818ad685b3de53ad74f7da50600f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The BMC and tools interacting with it depend on metadata placed inside
the ROM in order the flash the BIOS.
Add a new tool smcbiosinfo, integrate it into the build system, and
generate a 128byte metadata file called smcbiosinfo.bin on build.
You need to provide the BoardID for every SMC mainboard through a new
Kconfig symbol: SUPERMICRO_BOARDID
Some fields are unknown, but it's sufficient to flash it using SMC
vendor tools.
Tested on Supermicro X11SSH:
* Flashing using the WebUI works
* Flashing using SMCIPMITool works
No further validation is done on the firmware.
Change-Id: Id608c2ce78614b45a2fd0b26d97d666f02223998
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
All cases of testing for __PRE_RAM__ have been converted
to equivalent ENV_xxx definitions from <rules.h>.
Change-Id: Ib6cd598f17109cc1072818cebe4791f7410c3428
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
After removing urara no board still uses this SoC, and there are no
plans to add any in the future (I'm not sure if the chip really exists
tbh...).
Change-Id: Ic4628fdfacc9fb19b6210394d96431fdb5f8e8f1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36491
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some types of Undefined Behavior can be determined statically at compile
time and gcc now has a set of flags that make it emit warnings in that
case instead of doing the __builtin_trap() / optimize / UD2-opcode dance
that silently breaks the resulting binary.
BUG=chromium:958270
BRANCH=none
TEST=abuild passes (probably not)
Change-Id: I3aa5ca00c9838cc7517160069310a1ef85372027
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32814
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IASL reports unnecessary/redundant use of offset operator. These
messages are only masking usefull messages.
Add -vw 2158 so this message isn't reported.
BUG=N/A
TEST=build
Change-Id: Ie8507d3b3cb6f2e75cb87cd3e4bcc4280df27f77
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36857
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an optional pre-RAM cache for the FMAP which most
platforms should be able to use, complementing the recently added
post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP
about half a dozen times from flash in verstage, which will all be
coalesced into a single read with this patch. It will also help
future vboot improvements since when FMAP reads become "free" vboot
doesn't need to keep track of so much information separately.
In order to make sure we have a single, well-defined point where the new
cache is first initialized, eliminate the build-time hardcoding of the
CBFS section offsets, so that all CBFS accesses explicitly read the
FMAP.
Add FMAP_CACHEs to all platforms that can afford it (other than the
RISC-V things where I have no idea how they work), trying to take the
space from things that look like they were oversized anyway (pre-RAM
consoles and CBFS caches).
Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Add support for x86_64 bootblock on qemu.
Introduce a new approach to long mode support. The previous patch set
generated page tables at runtime and placed them in heap. The new
approach places the page tables in memory mapped ROM.
Introduce a new tool called pgtblgen that creates x86 long mode compatible
page tables and writes those to a file. The file is included into the CBFS
and placed at a predefined offset.
Add assembly code to load the page tables, based on a Kconfig symbol and
enter long in bootblock.
The code can be easily ported to real hardware bootblock.
Tested on qemu q35.
Change-Id: Iec92c6cea464c97c18a0811e2e91bc22133ace42
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a Kconfig option for indicating agreement to use the contents of
amd_blobs. Users should only download the repo after implicitely
agreeing to AMD's License text. No formal documented agreement
is required.
Update Makfile.inc, similar to other submodules, to initialize and
checkout the submodule once the Kconfig option is selected.
Change-Id: I4ae807659db16756453dc3db2c51848291c681b8
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reduce duplicated comments explaining that submodules' settings in
.gitmodules are update=none, and that --checkout is required. This
prepares for another submodule, and makes adding a third set of
comments unnecessary.
Change-Id: I7721333a61122284ed9975ecd2adc3271a879728
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* Add cbfsoption --ibb to mark files as IBB
* Will be used by "Legacy FIT TXT" boot
Change-Id: I83313f035e7fb7e1eb484b323862522e28cb73d4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Let `sconfig` output a C header file with the symbol names that we
generate since 5e2a2cd5e7 (util/sconfig: Expose usable PCI and PNP
device names).
We add another command line argument for the path to the header
file. As the file is similar in nature to our `config.h` we simply
put it in $(obj)/ too.
Change-Id: I8f87288c82f2844b61eba6534797a42b978b47bb
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35488
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This was causing a failure when building platforms with no bootblock
when building with make -jXX
Change-Id: Ic4cd4fe8ac82bd1e9ce114dbd53763538d125af3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
I'm moving the .xcompile file into the $(obj) directory so we can leave
the source pristine. We need to pass the location of .xcompile into
genbuild_h.sh.
BUG=b:112267918
TEST=Ran genbuild_h with and without an .xcompile and verified it was
passed.
Change-Id: I8b3a75b478fad92a0b09246f0a00b0580f8c4aef
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Without this, we're lacking a serialization point in abuild when doing
parallel builds. This manifests in parallel attempts to write the toada
binary, which fails.
Change-Id: Id6ebbb3750284225670608e4927d80c4eea96afb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Variable length arrays are dangerous, so let's make sure they don't
sneak back into coreboot or any of the payloads.
Change-Id: Idf2488cf0efab51c9569a3789ae953368b61880c
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33846
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With HAVE_BOOTBLOCK=n build of bootblock-class is skipped.
Inserts an empty 64-byte bootblock-region to coreboot.rom file,
cbfstool will fill in the CBFS master header relative location
at the end.
Change-Id: Iaee9200f72f31175aca597865e3c74fc68bec8a6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Add a utility to generate a compressed BIOS image for AMD Family 17h.
If the input is an elf file, the utility extracts the program portion
for compression. Otherwise the file is compressed as-is.
In modern AMD systems, the PSP brings up DRAM then uncompresses the
BIOS image into memory prior to x86 beginning execution. The PSP
supports a zlib engine, and interprets the first 256 bytes as a
header, where offset 0x14 containing the uncompressed size. For
further details, see AMD Platform Security Processor BIOS Architecture
Design Guide for AMD Family 17h Processors (NDA only, #55758).
BUG=b:127766506
TEST=Use with WIP Picasso
Change-Id: Id1c54e0a6dae9e4a0362c6635fe8b8aa48a369d8
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Depend on ifittool and use it to update FIT instead cbfstool FIT code.
Move the TOPSWAP / microcode handling out of cbfstool and implement it
in the Makefile.
The new FIT looks like the old one and has been tested on Broadwell-DE.
The TOPSWAP / microcode code path needs test on real hardware.
Change-Id: I687469d62557f81e9d88398cfc93182164fdac95
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Clang doesn't know `-Wlogical-op`, so let's move it into xcompile where
we can easily distinguish between the two. However, this requires us to
split out `GCC_ADAFLAGS*` from `GCC_CFLAGS*`.
Change-Id: I6a50de0bc5372f61337f237383d32645ba86b0fd
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33579
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes all possible dependencies in order to build platform
with CONFIG_RAMPAYLOAD enable(without ramstage).
A. Create coreboot separate stage kconfigs
This patch creates seperate stage configs as below
1. HAVE_BOOTBLOCK
2. HAVE_VERSTAGE
3. HAVE_ROMSTAGE
4. HAVE_POSTCAR
5. HAVE_RAMSTAGE
B. Also ensures below kconfigs are aligned with correct stage configs
1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if
CONFIG_HAVE_RAMSTAGE is selected.
2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set
3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE
|| CONFIG_HAVE_ROMSTAGE is selected.
C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE
On x86 platform:
Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1
>> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0
>> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select
CONFIG_HAVE_RAMSTAGE.
Also add option to create sipi_vector.manual based on $(TARGET_STAGE)
variable.
$(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE
$(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD
Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the version string "TIMELESS", binaries are slightly smaller than
for a regular build. This may lead to false positive build tests if the
space is limited (e.g. bootblock). So let's make the string a little
longer.
Change-Id: I3bbf6f71d5bcd74728a3fe39734312690901d0ec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32986
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 99e836c843.
This relands commit c4ab50cdde.
The issues with -Wtype-limits in the vboot submodule have been resolved
now, so we can enable this flag again.
Change-Id: I32e8cc88e69072e7ee66cf443b578a9a8ea0ebe2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
This reverts commit c4ab50cdde.
Reason for revert:
vboot recently was changed so that -Wtype-limits fails, and that
was just brought upstream. Since vboot internals are more likely
to be used elsewhere while -Wtype-limits is less critical, revert
this until vboot is resolved, then bring -Wtype-limits back again.
Change-Id: I9cce10462b9e57189513fa49e11fd27ebe35ba51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32670
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables -Wtype-limits for the whole repository, which
disallows checking for a condition that must be always true or always
false based on type width (e.g. checking whether an unsigned variable is
negative or whether a 32-bit integer is larger than 4G). This helps
avoid easy to make and hard to find (because they often only affect
error paths) mistakes like
size_t size = fmap_read_area(...);
if (size < 0)
die("If only the compiler could've told me to use ssize_t instead");
Change-Id: I19edabfd092d09dad720e3fc47b44838163bfe25
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32536
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rather than selectively update the fsp submodule based on
FSP version or platform selection, update it when building
for any FSP-enabled platform, so all have latest version available.
Change-Id: If07d55828a1863623e04a4ecdd1514c3cb6d9c11
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We only grep'ed for "ACPI Warning" resulting in an actual more severe
"ACPI Error" being ignored.
Change-Id: I9cec8a388f5558b1ffc383cc2fc69405252cbb37
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We used .aml as the file extension for preprocessed ASL code. That
file gets overwritten with the compilation results, fix that.
Change-Id: I11a03dfbcebb0fd762da7b27862a7bdb9a581b92
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/31523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If a non aligned CONFIG_CBFS_SIZE is used the region RW_MRC_CACHE and
CONSOLE could end up non aligned. Currently this is only possible if
the user messes with CONFIG_CBFS_SIZE in menuconfig, but better be
safe than sorry.
Change-Id: Ieb7e3c7112bd4b3f9733c36af21b1d59b3836811
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30420
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Put the FMAP FMAP region right above the coreboot CBFS region.
The other regions like RW_MRC_CACHE and CONSOLE often have alignment
requirements so it makes sense to put those on top. This also
simplifies the code the generate the default fmap a little.
Change-Id: I24fa6c89ecf85fb9002c0357f14aa970ee51b1df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30419
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We generate a $(obj)/cb-config.ads once and copy it per stage that uses
it to $(obj)/<stage>/cb-config.ads (to simplify the gnat-bind step). The
Ada package is called `CB.Config`. As there was no `CB` package yet, add
that too.
Change-Id: I963a6517ef4bcf84f2c8e9ae8d24a0d6b971d2b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Default to FSP binary and headers shiped in 3rdparty/fsp.
* Drop headers and code from vendorcode/intel/fsp1_0/broadwell_de
* Select HAVE_FSP_BIN to build test the platform
* Fetch FSP repo as submodule
* Make FSP_HEADER_PATH known from FSP2.0 useable on FSP1.0
* Introduce FSP_SRC_PATH for FSP source file
* Add sane defaults for FSP_FILE
Tested on wedge100s.
Change-Id: I46f201218d19cf34c43a04f57458f474d8c3340d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/30742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
The option to specify a binary file name was added later for platforms
that do not provide microcode updates in our blobs repository. Alas,
it wasn't visible what platforms these are. And if you specified a file
for a platform that already had one, they were all included together.
Make it visible which platforms don't provide binaries with the new con-
figs MICROCODE_BLOB_NOT_IN_BLOB_REPO, MICROCODE_BLOB_NOT_HOOKED_UP and
MICROCODE_BLOB_UNDISCLOSED. Based on that we can decide if we want to
include binaries by default or explicitly show that no files are inclu-
ded (default to CPU_MICROCODE_CBFS_NONE).
Also split CPU_MICROCODE_CBFS_GENERATE into the more explicit
CPU_MICROCODE_CBFS_DEFAULT_BINS and CPU_MICROCODE_CBFS_EXTERNAL_BINS.
And clean up the visibility of options: Don't show CBFS related options
on platforms that don't support it and don't show external file options
if the platform uses special rules for multiple files (CPU_MICROCODE_
MULTIPLE_FILES).
Change-Id: Ib403402e240d3531640a62ce93b7a93b4ef6ca5e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/29934
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the `git-format' tool to sanitise coreboot commits such that
they conform to coreboot's coding style.
This fancy piece of machinary allows one to have LibFormat from
Clang to automatically check your commit conforms to coreboot's
coding style, fix any issues automatically and provides you a
diff you may review and apply at your convenience.
N.B. When the `clang-format' binary is not found we issue a warning
that the test was skipped and carry on as usual. Hence, this is
strictly non-enforcing at this current time. You may use it at your
leisure.
Change-Id: If49017ea82f0707efd47cae5978a286a9af8f3b7
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/c/8037
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When building coreboot from scratch with 'make -j4', I sometimes see
this error:
CREATE build/mainboard/emulation/qemu-riscv/cbfs-file.wblRgZ.out (from /.../coreboot/.config)
HOSTCC cbfstool/cbfstool (link)
make[1]: execvp: build/util/kconfig/conf: Permission denied
make[1]: *** [/.../coreboot/util/kconfig/Makefile:92: savedefconfig] Error 127
It happens, I think, because the rule generated by
cbfs-files-processor-defconfig runs 'make savedefconfig', which builds
build/util/kconfig/conf, and something also builds it, at the same time.
Fix this case, by making this rule depend on $(objutil)/kconfig/conf.
The same fix is also precautiously applied to the rule for
$(KCONFIG_AUTOHEADER) in Makefile.
Change-Id: Ie93eda567f88ca08c97df7e70cdff5b07442747d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/29984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The reason for this code cleanup is the legacy
Google Purin board which isn't available anymore
and AFAIK never made it into the stores.
* Remove broadcom cygnus SoC support
* Remove /util/broadcom tool
* Remove Google Purin mainboard
* Remove MAINTAINERS entries
Change-Id: I148dd7eb0192d396cb69bc26c4062f88a764771a
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29905
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check for PLATFORM_USES_FSP2_0 instead of MAINBOARD_USES_FSP2_0. The
latter is only valid for Skylake where we decide per mainboard if FSP2.0
is used. PLATFORM_USES_FSP2_0 is the one that actually enables the
FSP2.0 integration.
Change-Id: I3f16e5f4454c0bf02d51db5d1c267a921917f377
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
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>
GNU make is too smart (or too stupid?) for empty recipes. In the case of
empty recipes, GNU make doesn't consider the target as updated even if
its prerequisites are. So if we told make to rebuild `build/romstage/
lib/cbfs.o` for instance, and the FMAP changed, it rerun the fmaptool
recipe (as a prerequisite) but only considered `cbfs.o` to be updated
by chance.
Just not leaving the recipes empty seems to help here. I seeemed to
remember that it wasn't that easy, but it fixes the issue for me...
Change-Id: Ic7ecb88cf7df7f2488defd47ea02255fc10a67e9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It only happens if both USE_BLOBS and MAINBOARD_USES_FSP2_0 are enabled.
Change-Id: I46843c61d3ddf398a3c058bb571d285b596bf5c1
Signed-off-by: Patrick Georgi <patrick@georgi.software>
Reviewed-on: https://review.coreboot.org/28304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since ifdfake has been deprecated in favor of better alternatives, there
is no need to support it any further. Remove it from the build system.
Change-Id: Id62e95ba72004a1e15453e3eb75f09cb8194feb2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/28233
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There were so many pitfalls that I wrote my own version of this even-
tually. This version is inspired by the procedure of Alex Thiessen[1].
Instead of generating a `build.h` on demand, we always generate a tem-
porary version that, if it differs from the current one, is added as
a dependency.
As we use .SECONDEXPANSION on the prerequisites, special care is taken
that we won't generate the file twice. As it would be too late to add
the dependency if we'd run `genbuild_h.sh` inside a recipe, we have
to run it through the `$(shell)` function. But that brings us to the
next issue: The make variables used by `genbuild_h.sh` are not expor-
ted to this shell like they would be in a recipe. So we export them
manually. We could also make these variables explicit parameters of
`genbuild_h.sh` instead.
An alternative to always creating the temporary `build.h` would be
to add a phony target as dependency instead, and finally calling
`genbuild_h.sh` again in case we need an update. But, um, we create
so many files anyway...
[1] https://review.coreboot.org/25685
Change-Id: I311cf610eabae873c70f2985fc7a09acec8061f0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Elyes HAOUAS