Warn for obsolescent usages, according to the C Standard, in a
declaration. For example, warn if storage-class specifiers like static
are not the first things in a declaration.
Change-Id: Ida3fa59edb07e4105ef3cfb6a20cb29680699586
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71892
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The end-of-build targets weren't very granular previously, so warnings
could be lost instead of being printed at the end of the build.
This separates the end-of-build targets into 4 different groups, in this
order:
- build_complete: The coreboot build itself is done
- files_added: All files have been added to CBFS
- show_coreboot: Display any normal coreboot build messages
- show_notices: Display any warnings or notes
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia67446f164b8e66415a1a8c196999316fdf39f1e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79382
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This reverts commit 7713a2f295.
Reason for revert: breaks main branch
Change-Id: I2749bea9369c222e510b838e278c7797d5dce56e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78852
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The JPEG decoder, that was added many years ago to display a boot-
splash in coreboot, has a few quirks. People used to do some voodoo
with GIMP to convert images to the right format, but we can also
achieve the same with ImageMagick's `convert`. The currently known
constraints are:
* The framebuffer's color format is ignored,
* only YCC 4:2:0 color sampling is supported, and
* width and height have to be a multiple of 16 pixels.
Beside that, we can only display the bootsplash if it completely
fits into the framebuffer. As the latter's size is often decided
at runtime, we can't do much more than offering an option to set
a specific size.
Change-Id: I564e0d89fb46503ff4c11e095726616700009968
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76564
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The original default, minimum abbreviated hash length was 7. It dif-
fers on newer systems, however. This breaks reproducibility, so set
an explicit length. 12 hex digits should be good enough.
Note: This sets only a minimum. With a high enough number of commit
objects in the repository, Git could still decide to use a longer
hash, again breaking reproducibility. 12 digits will hopefully pro-
vide enough margin.
Change-Id: Ia86e9cc41e27a0a57d498dcb13aec954c4ea0f04
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Add a new apcb edit tool, apcb_v3a_edit.py, that injects SPDs into
an APCB for phoenix platform.
The tool makes several assumptions:
* Each SPD only uses blocks 0, 1, 3 and 5. All other blocks are zero.
* Each block is 64 bytes.
* Dimm and socket are always 0
* Unused SPD entries are zero'd
BUG=b:281983434
BRANCH=None
TEST=build, flash, boot myst
Change-Id: Ifb50287de77138170714a702ab87d56427aacfef
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76188
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move this function to the root Makefile.inc since other Makefiles use
the exact same function call. Will allow for deduplication in AMD SoC
Makefiles in a follow-on commit.
Change-Id: I56a50e21b27a4cd6ce1a08a3aea338c63322a6b2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76167
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in
the SPI flash. New flashmap region is created for that purpose. The
goal of caching is to reduce the dependency on CSME and the HECI IP
LOAD command which may fail when the CSME is disabled, e.g. soft
disabled by HECI command or HAP disabled. This change allows to
keep PCIe 5.0 root ports functioning even if CSME/HECI is not
functional.
TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port
is functional after loading the HSPHY from cache.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Starting with ccache 4.4 it is possible to collect statistics about
cache miss/hit rates in a separate file.
Add the info of the build at end of created make.log file or on stdout.
Change-Id: I1bab712712f4d6379ec6733fdc55b234e3845da7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75087
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function can be called to more easily add a file to CBFS.
Additional file attributes can be added later:
cbfs-files-y += pagetables
pagetables-file := $(objcbfs)/pt
pagetables-type := raw
pagetables-compression := none
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
becomes
$(call add-cbfs-file-simple, pagetables, $(objcbfs)/pt, raw, none )
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
This is especially useful inside macros where you may want to add
an unknown number of entries.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I72bb2f21fb22f650b7970c7a37a48c10a4af0ed5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Clang was already warning about this. Synchronize the behaviour between
both compilers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I3331a7437b17ab5ac97cef94511bb29c020bdff0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75032
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
For compilation units that should be built for all stages that run on
the x86 cores in a newer AMD SoC, but can't be built for verstage on PSP
which is an ARM core, the 'all' target can't be used, since that would
result in the compilation unit also being added to the verstage target
in the verstage on PSP case. In order to not need to add a compilation
unit to the 'bootblock', 'verstage_x86', 'romstage', and 'ramstage'
targets in separate lines in the Makefile, introduce the 'all_x86'
target that adds a file to 'bootblock', 'verstage_x86', 'romstage',
'postcar', and 'ramstage'. The compilation units also need to be added
to the 'postcar' stage which is only present on the pre-Zen SoCs to be
able to also use the 'all_x86' target in common AMD code that is also
used in those pre-Zen SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9d0184182b931185990094d0874b49c0b5cb9f7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74150
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
On systems that do not provide their own *.fmd (Flashmap) file, we
fall back to a default flashmap file. That file however does not contain
the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap.
It can therefore easily happen that the placement of the blobs collides
with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough).
The fmaptool can't catch that, since it does not know of the blobs
placement.
This patch basically maps the regions described in the IFD (Intel
Firmware Descriptor) to the default Flashmap.
Test: Build and see that build/fmap.fmd contains all blobs now (on intel
systems that are supported by the ifdtool)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I82cb252fff456773af69943e188480a4998736fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Certain C source files for coreboot stages require fmap_config.h to
be present. When building coreboot using multiple jobs the dependency
is not always satisfied due to race condition and results in make
error. Work around it by adding fmap_config.h to stage C deps.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3a70beedf2eb1c018c5ff98163904253f9a87a61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69819
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
If we need to put a CBFS chunk into a specific region, add a line in
any Makefile.inc
regions-for-file-xxx=region_name
TODO:Do a complete binary identical test for all the mainboards.
Change-Id: Ie37a8a9230dc8b8e5664be8806f047afb94fba69
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Get string of hex value of a given number.
Change-Id: I6d3525db19089938897b9d19ad9875bb07e0eecf
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This is to warn if a user add to Makefile a path to nonexistent
directory.
Change-Id: I5a30c3830f30509deaaadc6eaeab0e17bc08565c
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70251
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes the build failure with 'make -j' where the build
fails at "$(MAKE)... savedefconfig" as that rule doesn't have the
dependency on kconfig/conf.
Normally make takes care of all dependencies, so parallel builds
work well. However if you have recursive make calls, i.e. make
calling make like in these recipes, there is no single make with a
global view of the dependencies anymore, and then multiple "makes"
can try to build the same file concurrently. Adding that explicit
dependency on build/util/kconfig/conf makes sure the recursive make
is only called later when the top-level make already finished
building build/util/kconfig/conf.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Id44ab44618b0ddfb3c2472c469499429118bf76d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72070
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
When ramstage is loaded asynchronously, as on the skyrim boards, the
faster decompression of LZ4 allows for faster boot times than the
tighter compression of LZMA.
To make this change, the name of the existing ramstage_compression
option needs to be updated.
BUG=b:264409477
TEST=Boot skyrim, look at boot speed
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I27dd1a8def024e0efd466cef9ffd9ca71717486a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71673
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The intention of CB:69710 was that the expanded config file introduced
there would be a strict superset of the old version and could be used in
all the same cases. This is generally true except for a small oversight:
if a boolean Kconfig is `default y`, but was manually set to `n` by the
user, the new `config` file does not include a line for it. Running
`make olddefconfig` on such a file will again introduce the option as
`y`. It turns out that `make olddefconfig` actually parses those
"load-bearing comments" in that case.
This patch fixes the problem by also generating the minimal defconfig
(like before CB:69710), and then just appending the non-comment lines
from the full config that don't appear in it already. This ensures that
any "load-bearing comments" in the defconfig remain in the file and the
result of Kconfig utilities regenerating a full config from there will
again be the same as before CB:69710. In addition, it clearly separates
the "minimal defconfig" part of the file from the rest, making it easy
for people to extract that if they need it; while also keeping all the
config values in one file to make it easy to grep for a certain value.
Also eliminate that random backslash in the recipe that doesn't seem to
have any good reason to exist and was probably a typo to begin with.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I52ba5d20d3536498fae79d529acf7135f97ef1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch creates initial common code structure for board_id
implementation for intel rvp platforms. Board_id helps in
identifying the platform with respect to CHROME_EC and INTEL_EC
(Windows_EC). Changes include
1. Create initial board_id.c and board_id.h
2. Modify the Makefile to include src/ec/intel directory
BUG=b:260654043
TEST=Able to build with the patch and boot the mtlrvp platform with the
subsequent patches in the train
Signed-off-by: Harsha B R <harsha.b.r@intel.com>
Change-Id: If133f6a72b8c3e1d8811a11f91e4556beb8c16e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Usha P <usha.p@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Warn when a definition is using '()' instead of '(void)'.
Use of ‘()’ is considered an old-style definition in C1x standards,
but probably not in C2x.
Change-Id: I734cfffe3e89996ab13e846cc08e13753f24f742
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The coreboot build system automatically adds a `config` file to CBFS
that lists the exact Kconfig configuration that this image was built
with. This is useful to reproduce a build after the fact or to check
whether support for a specific feature is enabled in the image.
However, the file is currently generated using the `savedefconfig`
command to Kconfig, which generates the minimal .config file that is
needed to produce the required config in a coreboot build. This is fine
for reproduction, but bad when you want to check if a certain config was
enabled, since many configs get enabled by default or pulled in through
another config's `select` statement and thus don't show up in the
defconfig.
This patch tries to fix that second use case by instead including the
full .config instead. In order to save some space, we can remove all
comments (e.g. `# CONFIG_XXX is not set`) from the file, which still
makes it easy to test for a specific config (if it's in the file you can
extract the right value, if not you can assume it was set to `n`). We
can also LZMA compress it since this file is never read by firmware
itself and only intended for later re-extraction via cbfstool, which
always has LZMA support included.
On a sample Trogdor device the existing (uncompressed) `config` file
takes up 519 bytes in CBFS, whereas the new (compressed) file after this
patch will take up 1832 bytes -- still a small amount that should
hopefully not break the bank for anyone.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5259ec6f932cdc5780b8843f46dd476da9d19728
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
No boards now have a missing dependency so remove the workaround.
Change-Id: I787f6aa588175ba620a068918c42edc9d257c3ef
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69514
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add build rules to build amdfwread tool. Also mark this as a dependency
either while building tools or amdfw.rom.
BUG=None
TEST=Build and boot to OS in Skyrim with CBFS verification enabled.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I3fee4e4c77f62bb2840270b3eaaa58b894780d75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66939
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Elyes Haouas