Extend to include most used components, e.g. FSP, ME, IFD, microcode,
edk2, AGESA, EC.
Upstream-Status: Pending
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Add the BOOTSPLASH region logo.bmp file from within the buildsystem,
instead of having to patch it afterwards in build.sh or elsewhere.
Upstream-Status: Inappropriate [Dasharo downstream]
Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
If make is ran a second time after an initial clean compile, the entire
rom will be rebuilt. Subsequent calls to make will not rebuild the rom.
This initial rebuild was due to build/util/kconfig/conf being newer than
config.h, and the subsequent rebuild of the header marked everything
else as out of date. The reason conf was newer than config.h is because
it was being treated as an intermediate file [1]. In the rule for
config.h, conf is a prerequisite, but since it is treated as an
intermediate, its rule will not be run if config.h exists and all the
prerequisites of conf (i.e. its source files) are also up to date.
On a clean build after a make menuconfig, config.h exists, satisfying
these conditions. In this case, config.h is treated as being up to date
even though conf does not exist. However, if another target does not
exist and also has conf as a prerequisite, conf will then be built so
that the target can be built. This caused conf to be newer than
config.h, but by default GNU Make deletes intermediate files after a
build which would prevent conf from affecting config.h on subsequent
rebuilds.
However, commit dd6efce934 ("Makefile: Add .SECONDARY") adds the
.SECONDARY special target, which prevents intermediate files from being
deleted after the build [2]. Thus, conf persists to the first no-op
build, making config.h out of date. Since config.h is updated during
this first rebuild, conf is no longer newer than it, and thus subsequent
no-op builds behave as expected.
Fix this by preventing conf from being treated as an intermediate file
by adding it as a prerequisite of the .NOTINTERMEDIATE special target,
which causes conf to always be rebuilt if it does not exist. Thus, on
the initial clean compile, config.h will be updated after building conf
as a prerequisite, preventing config.h from being marked out of date on
a subsequent rebuild.
[1] https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html
[2] https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
Change-Id: I98c49d47f811e5cceebce7b7d54b282c773734e3
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Generated files such as static.h are currently added as prerequisites
for all compilation units to ensure that they exist and are up to date
before anything that might need them is compiled. However, this has the
side effect of forcing every compilation unit out of date when such
files are regenerated, even if the object has no dependency on the
generated file. GNU Make has order-only prerequisites [1] which are used
to define prerequisites that must be updated before a given target, but
which don't force the target out of date.
Add a new argument to create_cc_template, similar to the "additional
dependencies" argument, which allows dependencies on such generated
files for a specified object class and source suffix to be defined. This
new functionality will be utilized in subsequent commits to fix up the
dependencies on generated files.
Objects that do depend on generated headers will still be handled
correctly due to the .d dependency files that are generated by the
compiler during the build, which declare normal prerequisites to any
headers an object directly or indirectly includes. As per the GNU Make
documentation, normal prerequisites take precedence over order-only
prerequisites, so the header dependencies declared in the .d files will
override the order-only one declared through create_cc_template.
This does mean that a necessary rebuild of an object due to a generated
file may be missed if the dependency file from the compiler is missing,
but this is an unusual situation that is unlikely to occur during normal
incremental builds.
[1] https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
Change-Id: I50d87b3d9012967eefb197be12b2e0f096b0b67c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This almost completely replaces the original clean-symlink target to
remove links from site-local into the coreboot tree. Changes include:
- Symbolic links removed are based on the EXTERNAL_SYMLINKS value of
symlink.txt files under site-local.
- Verify that there are site-local symlink.txt files to work on before
doing anything.
- Verify that the symlink.txt files reference links inside the coreboot
directory.
- Print out whether or not there are remaining symbolic links in the
tree.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ife0e7cf1b856b7394cd5e1de9b35856bd984663c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This target looks for symbolic links in the coreboot directory,
excluding the 3rdparty and crossgcc directories, which both typically
have numerous symbolic links, and deletes anything that is found.
All possible links are verified as symbolic links before being removed.
Any removed links show where they were linked from in case they need to
be restored.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8a56e7c628701e4a0471833443b08ab2bcceb27e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83123
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This almost completely replaces the original symlink target for creating
symbolic links from site-local into the coreboot tree. Changes include:
- A comment about the format of the symlink.txt file
- Verify that there are symlink.txt files before doing anything.
- Note that symbolic links that already exist are being skipped.
- Only use the first line of the symlink.txt file
- Make sure the symbolic link to be created is inside the coreboot dir.
- Output errors to STDERR
- echo -e isn't supported by posix shells, so replace /t with two spaces
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9b0d1b5bc19556bc41ca98519390e69ea104bd1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <ericllai@google.com>
This was added in commit 963bed546f (Make: Use unaltered object list for
dependency inclusion) to fix an issue caused by ramstage-postprocess.
The logic for handling dependency inclusion changed in commit db273065f6
(build system: extend src-to-obj for non-.c/.S files), causing the
variable to become unused.
Change-Id: I011ff2070bc31ab9ddf2536873555d0157f91fce
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
The rest of the Makefiles will be renamed in following commits.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idaf69c6871d0bc1ee5e2e53157b8631c55eb3db9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80063
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The "config" targets exist to edit the .config file, and so they
should be more forgiving with invalid configs (that they'll convert
into valid configs on save). They will still emit warnings about
invalid symbols, but not exit with an error.
The regular build process still fails if the .config looks unexpected
(for example when there's an unknown config flag).
Change-Id: If427e075766c68d493dd406609f21b6bb27d1d74
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79298
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Upstream reimplemented KCONFIG_STRICT, just calling it KCONFIG_WERROR.
Therefore, adapt our build system and documentation. Upstream is less
strict at this time, but there's a proposed patch that got imported.
TEST=`util/abuild/abuild -C` output (config.h and
config.build) remains the same. Also, the failure type fixed in
https://review.coreboot.org/c/coreboot/+/11272 can be detected,
which I tested by manually breaking our Kconfig in a similar way.
Change-Id: I322fb08a2f7308b93cff71a5dd4136f1a998773b
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This patch saves the output of the IWYU build into $(obj)/iwyu.txt. It
will also automatically adds -k to the MAKEFLAFGS when IWYU is selected,
so that the build doesn't halt after the first operation.
When IWYU is not selected, there is no change to the build.
This will allow us to create an automated IWYU build on jenkins.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0ea300d4c64bb923e9f7cc0e595885c3006ec3ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77192
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
When wildcards are used in toplevel Makefile.inc it ends up appending
all items including regular files into subdirs-y which then are treated
as directories in "evaluate_subdirs" with "Makefile.inc" appended to
them. Check for a valid path (existing Makefiles.inc) before attempting
to process it.
Change-Id: I368b5b9a7ece3c675674fcb24303276a87c15668
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The ctags tool (called by ctags-project target) currently complains
about not finding certain files.
The project_filelist.txt generation includes the compiler
generated "*.d" files, except for files found in build/util. Most file
paths in these "*.d" files are file paths relative to the root
directory of coreboot. Some projects though are compiled separately from
coreboot (e.g. payload, vboot, util). Some of these (e.g. util, vboot)
are also put into the build directory of coreboot and relative file
paths are relative to these projects instead of coreboot. This has the
uncanning side effect that the ctags Makefile target can't find these
files, since they are not relative to the coreboot root directory.
This patch also excludes the build/external directory from those files,
since they contain 'separately' compiled projects like 3rdparty/vboot.
That fixes the ctags-project Makefile target.
Change-Id: I16294171c29a0d5fd25a31018846f1013e130ee0
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71517
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
If selected, libgnat is linked into romstage. In addition, a call to
romstage_adainit() is added to support Ada program data
initialization.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=Ada code compiles for romstage and loads successfully
Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Filip Lewiński
Nicholas Chin
Martin Roth
Patrick Georgi
Felix Singer
roccochen@chromium.com
Nico Huber
Nikolai Vyssotski
Kyösti Mälkki
Arthur Heymans
Maximilian Brune
Jeremy Compostella