Currently, if for some reason, the file-size command is called on an
empty string, the build will hang waiting for stdin input to cat.
Since wc accepts a file, this cat was unnecessary anyway. Put the file
name in quotes so an empty string will result in calling wc on an
actual null file instead of just leaving the filename blank. This
results in an error, and will probably halt the build.
BUG=214790407
TEST=Build default build.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I3dacf1968ed897a8ebd00f95583c2f254a7fb55a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Firmware is typically delivered as one large binary image that gets
flashed. Since this final image consists of binaries and data from
a vast number of different people and companies, it's hard to
determine what all the small parts included in it are. The goal of
the software bill of materials (SBOM) is to take a firmware image
and make it easy to find out what it consists of and where those
pieces came from. Basically, this answers the question, who supplied
the code that's running on my system right now? For example, buyers
of a system can use an SBOM to perform an automated vulnerability
check or license analysis, both of which can be used to evaluate
risk in a product. Furthermore, one can quickly check to see if the
firmware is subject to a new vulnerability included in one of the
software parts (with the specified version) of the firmware.
Further reference:
https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
- Add Makefile.inc to generate and build coswid tags
- Add templates for most payloads, coreboot, intel-microcode,
amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
intel ME and compiler (gcc,clang,other)
- Add Kconfig entries to optionally supply a path to CoSWID tags
instead of using the default CoSWID tags
- Add CBFS entry called SBOM to each build via Makefile.inc
- Add goswid utility tool to generate SBOM data
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
gcc 12 fails the build with the warning below:
CC romstage/lib/cbfs.o
src/lib/cbfs.c: In function 'switch_to_postram_cache':
src/lib/cbfs.c:31:32: error: comparison between two arrays [-Werror=array-compare]
31 | if (_preram_cbfs_cache != _postram_cbfs_cache)
| ^~
src/lib/cbfs.c:31:32: note: use '&_preram_cbfs_cache[0] != &_postram_cbfs_cache[0]' to compare the addresses
Instead of following gcc’s suggestion, disable the warning for gcc as
requested by Julius [1]:
> Can we just set -Wno-array-compare instead? There's nothing illegal
> about that expression and as we can see in this case, there are
> perfectly reasonable cases where you might want to do something like
> that. On the other hand, I don't really see a realistic scenario where
> this warning could prevent a real problem (anyone who doesn't know
> that array1 == array2 doesn't compare the array elements in C
> shouldn't have any business submitting code to coreboot).
[1]: https://review.coreboot.org/c/coreboot/+/62827/1
Found-by: gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2]
Found-by: gcc (Debian 12.1.0-7) 12.1.0
Change-Id: I322f7cc57dcca713141bddaaaed9ec034898754d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit 75226bb879 ("Makefile.inc: Generate master header and pointer
as C structs") may cause objcopy to copy a wrong section of object file
resulting in miscompiled image with missing CBFS master header. This
makes the usage of secondary payloads impossible.
For example a wrong section for CONFIG_ANY_TOOLCHAIN +
objcopy 2.38-slack151 will copy ".note.gnu.property".
This patch constraints the sections to .data and .bss only.
Signed-off-by: Petr Cvek <petrcvekcz@gmail.com>
Change-Id: I1b9a73ece7067c9c5100cb294775078f838e263b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of trying to update the submodules, then skipping each update if
git is not present, just don't try to update the submodules at all.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I83ef48a21820c0983e38823331c9ba0fe0fc277f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
There is no longer any information printed when updating submodules, so
on the initial build, this can lead to a long delay without explaining
what's going on.
Just add an information line that the submodules are being updated so
that the user can see what's happening.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I987e50b99e39b976bc8367525549153e1eba69cd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This patch adds a new line to `cbfstool print -v` output that records
the overall CBFS verification health of the image. While this info was
already visible from individual fields before, it's nice to have a
one-stop location to see "this is a good image" without having to
carefully parse a lot of output manually.
Also add a few lines to the Makefile that check whether this field is
valid for the final image (it always should be, but hopefully this check
will allow us to catch regressions like the one fixed by CB:64547 sooner
in the future).
BUG=b:233263447
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1b74b01a55b22294556007aaee835d0fdb9e1c63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
With CBFS verification, cbfstool (CB:41121) needs bootblock to be
present in coreboot.pre in order to locate the metadata hash stored in
it. Therefore we have to ensure that bootblock is added to CBFS before
other CBFS files are added.
To solve the problem, create the 'add_bootblock' function, and call it
in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite
of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n.
BUG=b:233263447
TEST=emerge-guybrush coreboot
TEST=emerge-corsola coreboot chromeos-bootimage
TEST=cbfstool image-kingler.bin print -v
TEST=Kingler booted successfully
BRANCH=none
Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some platforms don't need a top aligned bootblock in cbfs like Intel
APL or modern AMD platforms as the bootblock is loaded differently.
So they don't need the top aligned cbfs bootblock.
To not clutter the main make file move out adding the bootblock.
Change-Id: I4de9d7fedf1ae5a37a3310dd42eb07b44c030930
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This can be done in a separate Makefile target.
Change-Id: I50eae4f00d171d26a221ca969086f4f294fa524b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The makefiles don't like cbfs file names with spaces in them so update
the file name with '_' instead of spaces. To keep the master header at
the top of cbfs, add a placeholder.
This removes the need to handle the cbfs master header in cbfstool.
This functionality will be dropped in a later CL.
On x86 reserve some space in the linker script to add the pointer.
On non-x86 generate a pointer inside a C struct file.
As a bonus this would actually fix the master header pointer mechanism
on Intel/APL as only the bootblock inside IFWI gets memory mapped.
TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master
header.
Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
There is no easy way to add dependencies to cbfs-structs objects and
fmap_config.h is a generated file. Follow-up commits depend on it being
available so add it in the cbfs-struct makefile function.
Change-Id: I7067ff144d38c1ff058825819419b2a2e7801e17
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Warning for _SRS includes _SRS.
Warning for _DIS includes must have _SRS twice.
Remove requirement _SRS for _SRS is present.
Removed second _SRS for _DIS is present.
BUG=N/A
TEST=Verify correct message on built of facebook FBG1701
Change-Id: I1be740354b159e931e41323aef14e160cc09af19
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>´
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63250
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
"REDUNDANT_OFFSET_REMARK" to ignore redundant offset remarks is
not needed any more as it’s included upstream.
Changes: https://acpica.org/node/199
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ice7f9a10051f7f62c53098161fd2f498d724c17d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Some of these targets seem to come from a long time ago. Now just
rm -rf $(obj) is all that is needed for a clean.
Change-Id: Iccc62b3c54ee2a074c25674715403c1457f6aad3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin Roth <martinroth@google.com>
coreboot.pre doesn't follow the standard Make conventions. It gets
modified by multiple rules, and thus we can't compute the dependencies
correctly. This means we need to manually delete it before starting the
dependency calculations.
i.e., Building firmware with the seabios payload now works correctly.
Fixes: dd6efce934 ("Makefile: Add .SECONDARY")
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If5fa3f0b8d314369a044658e452bd75bc7709397
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Putting
src/soc/*/common before src/soc/*/*, and
src/superio/common before src/superio/*,(which is already moved but
with duplicated folder "common")
can make the variables in
common Makefile get the expected value before they are used in other
subdirs.
The later "*" also contains "common", which needs to be eliminated by
"filter-out".
Then we can put some common variables from all the subdir Makefile.inc
to the common Makefile.inc to reduce code redundancy.
Change-Id: I99597af22cac6d12aaef348789664cd7db02ba06
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We don't currently have a build target defined for .map files. This
means they can't be used as a dependency. This change splits the .map
creation into its own rule.
BUG=b:221231786
TEST=Build guybrush and verify .map still exists
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1ce21902e97390aa9520670299ef08debf4458db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin Roth <martinroth@google.com>
IASL compiler check for usage of _CRS, _DIS, _PRS, and _SRS objects:
1) If _PRS is present, must have _CRS and _SRS
2) If _SRS is present, must have _PRS (_PRS requires _CRS and _SRS)
3) If _DIS is present, must have _SRS (_SRS requires _PRS, _PRS requires _CRS and _SRS)
4) If _SRS is present, probably should have a _DIS (Remark only)
IASL will issue a warning for each missing dependency.
Ignore this warnings for existing ASL code and issue a message when the build is complete.
Change-Id: I28b437194f08232727623009372327fec15215dd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Intel Lynx Point ASL code is fixed. So don't ignore
"Multiple types (Device object requires either a _HID or _ADR, but not both)"
warning.
Change-Id: Ie9398879a76ad3d36454772a1c23da083af14b59
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Building libgfxinit with Debian’s toolchain – latest test with *gnat-11*
11.2.0-13 from Debian sid/unstable – the build fails with the error
below.
E: Invalid reloc type: 10
E: Unable to create rmodule from 'build/cbfs/fallback/ramstage.debug'.
Debian’s toolchain is built without enabling PIE by default.
So, explicitly pass `-fno-pie` to `ADAFLAGS_common` to be independent
from how the toolchain was built.
TEST=*gnat* 11.2.0-13 successfully. builds
purism/librem_cnl/variants/librem_mini with libgfxint.
With the coreboot toolchain `make BUILD_TIMELESS=1` produces the
same `build/coreboot.rom` for `BOARD_PURISM_LIBREM_MINI_V2=y` on
top of commit 50251400d2 (sb/intel/common/firmware: Reword
me_cleaner warning) with and without the change.
Change-Id: I6661937906d95c130c6099f598d61b21e958fd85
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Currently, git prints out the submodules that are being skipped twice
on many builds. This patch hides that output unless the build is set
to show it with `make V=1`. This is the normal way of showing the extra
information during the build.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7b5c7f1f79dcc88793a9a21f2e92e7accc5de1e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59511
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This will enable preloading ramstage. By preloading the file into
cbfs_cache we reduce boot time.
BUG=b:179699789
TEST=Boot guybrush to OS and see 12ms reduction in boot time.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ibe12de806449da25bc0033b02fcb97c3384eddc1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This change adds a new tool `cse_serger` which can be used to print,
dump and stitch together different components for the CSE region.
BUG=b:189177186
Change-Id: I90dd809b47fd16afdc80e66431312721082496aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a new tool `cse_fpt` which can be used to print and
dump CSE partitions in Flash Partition Table (FPT) format.
BUG=b:189167923
Change-Id: I93c8d33e9baa327cbdab918a14f2f7a039953be6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds src/soc/* to subdirs before src/soc/*/* to allow
Makefile in src/soc/* to provide any common helpers that will be
useful for any src/soc/*/*. This is done to primarily ensure that the
helpers are defined before being invoked by the SoC Makefile.inc. This
is utilized by Intel CSE stitching mechanism in following changes.
BUG=b:189177580
Change-Id: I91579a87016fdc2b9ca2d798b81969c21c18b4a3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
New binutils versions automatically resolve references to debug symbol
files and parse their content as well when objdump'ing data. This leads
to multiple mentions of symbols, so deduplicate references.
Change-Id: I5d597399c515904313ba36d7aab9178bc0dade14
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
While the gcc(1) driver has the `-nostartfiles` option, ld(1), the
program the coreboot toolchain uses to link the object files, doesn't
have it.
In binutils before 2.36, this option is interpreted as `-n -o
startfiles`, in which the `-o` option is overridden by a later `-o`
option, so only the `-n` option has effect, which is the `--nmagic`
long option of ld(1). So the correct linker option in this place is
`--nmagic`.
It is tested that without `--nmagic`, ld can generate a much bigger
x86_64 romstage, so this option is still needed.
This error is found when trying to update binutils to 2.36 and later
versions, where ld(1) is unable to disambiguate options and reports an
error.
Change-Id: I27dc2209abdc6fec866716a252736c5cf236a347
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The pointer to the header has a x86 top mmaped address even though the
boot medium is not mapped that way. If no pointer is used to find the
header FMAP is needed. If FMAP is used anyway there is no need for a
cbfs master header.
Change-Id: I6d693bdd4ddaf4c9b3cffb4ea9879c761200aca9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add IFITTOOL as a dependency where needed and remove where it is
unneeded.
Change-Id: I88c9fc19cca0c72e80d3218dbcc76b89b04feacf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is already handled in $(prebuild-files).
Change-Id: I648f97198772d30d6d267ab9d6f7fa8d1d5d0e91
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Mainboards with variants may not always use the same cmos.layout file.
Turn the hardcoded path into a Kconfig symbol to allow changing it.
Tested with BUILD_TIMELESS=1: Without including the config file in the
coreboot.rom and with `USE_OPTION_TABLE` selected, building for the Asus
P8H61-M PRO produces an identical coreboot image.
Change-Id: I4cc622dcb70855c06cb8a816c34406f8421180df
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54366
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
VSA (Virtual System Architecture) is specific to AMD Geode CPUs, which
are no longer supported in current coreboot. Drop this remnant.
Change-Id: I28bf61cb953e3352b59aa91059341e4de8f84f23
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
cmocka is currently ignoring the UPDATED_SUBMODULES flag. Move the
cmocka checkout with the other submodule checkouts.
BUG=none
TEST=Make sure cmocka is not checked out if UPDATED_SUBMODULES=1
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2a1db809368a77d2c0f9c9a796d62555ec476dc7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
We use `additional-dirs` for a single `mkdir -p` invocation for all
directiories. I don't see why these two, $(objcbfs) and $(objgenerated),
should be an exception.
Fixes clean builds for targets that don't include the phony `coreboot`
target, e.g. `make qemu`.
Change-Id: I85abaa74cddefd2bd669e2b5c8934352775070fe
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This messes up the bare structs.
Change-Id: I5a13bd9f4b11530a6dd5f572059fed851db44757
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Building with LLVM/clang (`COMPILER_LLVM_CLANG=y`), Debian clang version
11.0.1-2 fails due to unknown warning options.
error: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'? [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wduplicated-cond' [-Werror,-Wunknown-warning-option]
As these are GCC specific, only add them, when building with GCC (and
not scan-build).
Fixes: 04e0712f46 ("Treewide: Add some gcc's warning options")
Change-Id: I6190c1f3df97fb0be51f8dab7e1f5f2a033f5d86
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
Martin Roth