History log of /rk3399_ARM-atf/make_helpers/build_macros.mk (Results 1 – 25 of 205)
Revision Date Author Comments
# beedfb93 04-Nov-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "little-build-fixes" into integration

* changes:
fix(build): don't rely on Event Log build tree
fix(build): link Event Log library directly
fix(build): scan symbols un

Merge changes from topic "little-build-fixes" into integration

* changes:
fix(build): don't rely on Event Log build tree
fix(build): link Event Log library directly
fix(build): scan symbols until all are resolved
fix(build): add include directory dependencies

show more ...


# bba54a3f 30-Oct-2025 Chris Kay <chris.kay@arm.com>

fix(build): scan symbols until all are resolved

This small change ensures that unresolved references between object
files are resolved regardless of the order that they are provided to the
linker. T

fix(build): scan symbols until all are resolved

This small change ensures that unresolved references between object
files are resolved regardless of the order that they are provided to the
linker. This is beneficial for us, because it allows us to append
libraries to variables like `BLx_LIBS` without concern for ordering.

No update is necessary for armlink, which already implements this
behaviour by default.

Change-Id: I2fd2aa04f5911a1d45162c065dfe2a5049b5b14f
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...


# 19f4e199 30-Oct-2025 Chris Kay <chris.kay@arm.com>

fix(build): add include directory dependencies

The bootloader images and their sources are missing dependencies on
their include directories. This can trigger errors and/or race
conditions when a ta

fix(build): add include directory dependencies

The bootloader images and their sources are missing dependencies on
their include directories. This can trigger errors and/or race
conditions when a target is dependent on generated headers.

Change-Id: I71a65669aa0107445d5dda1bd237b87c99c9c8fd
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...


# b5deac9a 27-Oct-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "comp_build_macro" into integration

* changes:
feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT
feat(build): set CRYPTO_SUPPORT macro per BL
feat(build): create defi

Merge changes from topic "comp_build_macro" into integration

* changes:
feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT
feat(build): set CRYPTO_SUPPORT macro per BL
feat(build): create define macro to be used by BL

show more ...


# cd92fb24 28-Jul-2025 Lauren Wehrmeister <lauren.wehrmeister@arm.com>

feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT

Setting CRYPTO_LIB based on CRYPTO_SUPPORT via the
CRYPTO_SUPPORT macro to be called by component-specific makefiles.

Signed-off-by: Lauren Wehrme

feat(build): setting CRYPTO_LIB via CRYPTO_SUPPORT

Setting CRYPTO_LIB based on CRYPTO_SUPPORT via the
CRYPTO_SUPPORT macro to be called by component-specific makefiles.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ib400e4668c60c24bb4399de6a320b5c16205affb

show more ...


# 6e2fe623 06-Jun-2025 Lauren Wehrmeister <lauren.wehrmeister@arm.com>

feat(build): set CRYPTO_SUPPORT macro per BL

Moving the setting of CRYPTO_SUPPORT from the main Makefile to
individual component makefiles using the new build macro
make_defines for each BL-specific

feat(build): set CRYPTO_SUPPORT macro per BL

Moving the setting of CRYPTO_SUPPORT from the main Makefile to
individual component makefiles using the new build macro
make_defines for each BL-specific CPPFLAGS.

Rework romlib build command to use CRYPTO_LIB to determine mbedtls need
instead of CRYPTO_SUPPORT. If CRYPTO_SUPPORT is set for any component,
then CRYPTO_LIB will be filled, romlib can use this instead.

Add a convenience makefile macro for setting CRYPTO_SUPPORT from
component specific makefiles, have components call the macro based on
whether authenication verification (NEED_AUTH) and/or hash calculation
(NEED_HASH) is required for the specific boot stage.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I7e81fede74fb9c04694b022e8eebed460616565c

show more ...


# 116d2c09 06-Jun-2025 Lauren Wehrmeister <lauren.wehrmeister@arm.com>

feat(build): create define macro to be used by BL

Adding make_defines that creates defines using make_define to be used
per the specified boot loader. This can be used for many build flags
with the

feat(build): create define macro to be used by BL

Adding make_defines that creates defines using make_define to be used
per the specified boot loader. This can be used for many build flags
with the intention to separate by BL. First, specifically for use of
CRYPTO_SUPPORT to be set separately by BL through the CPPFLAGS build
option.

This can be called per component makefile to specify build
configurations per BL, i.e. for BL1,
BL1_CPPFLAGS += $(call make_defines,CRYPTO_SUPPORT)

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Iee40c1e673f04c83534bdbfafe8b1c1dd4898e23

show more ...


# 7e8b7096 14-Oct-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
fe

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
feat(build): allow full LTO builds with clang
refactor(build): make sorting of sections generic
feat(build): use clang as a linker
fix(build): correctly detect that an option is missing with ld_option
feat(build): pass cflags to the linker when LTO is enabled

show more ...


# bded41d9 14-Oct-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes I769ac07f,Ia52ad5ed,I5d22ff86,Iea14d49c into integration

* changes:
fix(build): prevent races on the build directory
refactor(build): make it standard to request a custom linker sc

Merge changes I769ac07f,Ia52ad5ed,I5d22ff86,Iea14d49c into integration

* changes:
fix(build): prevent races on the build directory
refactor(build): make it standard to request a custom linker script
perf(bl32): don't call cm_get_context() unnecessarily
refactor(bl1): simplify context getting and setting

show more ...


# 774fb379 15-Sep-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(build): prevent races on the build directory

The tools (eg fiptool) don't depend on the build directory so it's
possible that make tries to build them before it exists. Doing that
leads to rando

fix(build): prevent races on the build directory

The tools (eg fiptool) don't depend on the build directory so it's
possible that make tries to build them before it exists. Doing that
leads to random and unpredictable errors. Almost always, they are built
after a BL image which always has a build directory dependency, but
when building MANY tf-a builds over MANY threads concurrently this could
be observed (I suspect the high load of the system increases latency
just enough that this race is lost).

The fix is simple - have an explicit dependency on the build directory.

This is the same problem as 9855568cc and 25cde5f81.

Change-Id: I769ac07f8882f82ea9d72f3b976337284d697310
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 7cdbbea4 11-Sep-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS

WRAPPER_FLAGS is this awkward exception to linker related flags that is
defined in the build_macros file which is only meant to provide macros.
It

refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS

WRAPPER_FLAGS is this awkward exception to linker related flags that is
defined in the build_macros file which is only meant to provide macros.
It also relies on being lazily evaluated as at the time of its expansion
BUILD_PLAT is not defined yet. It's also another variable in the myriad
of others.

So absorb it into ldflags-common in cflags.mk. This brings it in line
with all the rest and gets rid of its weird quirkiness.

Change-Id: Id711e38774a22fd0f20a26c827a505e40de18e50
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 6c2e5bf6 11-Apr-2025 Boyan Karatotev <boyan.karatotev@arm.com>

feat(build): use clang as a linker

To support LTO, the gcc binary is used as a compiler, assembler, and
linker. Do the same for clang and enable LTO builds with it as a side
effect.

This simplifies

feat(build): use clang as a linker

To support LTO, the gcc binary is used as a compiler, assembler, and
linker. Do the same for clang and enable LTO builds with it as a side
effect.

This simplifies code quite a bit as the gcc/clang different is much
smaller. Support for ld/lld (if overriden with LD) is maintained.

This is a good time to convert tabs to spaces to conform to make's
expectations on syntax.

Change-Id: I6c529c1393f7e9e8046ed537f871fc3ad91d599a
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# b45fc164 13-May-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for bo

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for both styles
of invocation. However, the gcc one is incorrect - gcc returns `0` even
when it has printed an error saying that it doesn't recognise the
option. Add a discovery function for each linker we expect and
dynamically dispatch to the correct one.

While we're at it, also add a little bit of code to return the -Wl
prefix for gcc and not for ld.

All of the above is also true for clang and lld, although they don't
suffer from the problem that gcc does.

Change-Id: I4f7bdf40c01f4c5df9c177f5048f5e349bc2b9c9
Co-authored-by: Chris Kay <chris.kay@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 2d8e4481 26-Sep-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge "fix(build): fix lib cflags use in build macros" into integration


# d8a23ecd 25-Sep-2025 Slava Andrianov <slava.andrianov@arm.com>

fix(build): fix lib cflags use in build macros

Adjust the MAKE_C_LIB build macro so that it correctly finds and
includes any library added compilation flags.

Change-Id: I7c0613adc3c7dc7db88cb2f9425

fix(build): fix lib cflags use in build macros

Adjust the MAKE_C_LIB build macro so that it correctly finds and
includes any library added compilation flags.

Change-Id: I7c0613adc3c7dc7db88cb2f94252944e46d8d9c1
Signed-off-by: Slava Andrianov <slava.andrianov@arm.com>

show more ...


# 81445dd1 22-Jul-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes I801cea04,I4abb6c9d,I3c1cc0ec,I1b6f69ad,Ic4086a1f into integration

* changes:
refactor(build): pass TF_CFLAGS to the assembler
refactor(build): absorb CFLAGS into TF_CFLAGS
refac

Merge changes I801cea04,I4abb6c9d,I3c1cc0ec,I1b6f69ad,Ic4086a1f into integration

* changes:
refactor(build): pass TF_CFLAGS to the assembler
refactor(build): absorb CFLAGS into TF_CFLAGS
refactor(build): use a standard rule to run the preprocessor
refactor(build): place all cflags setting in one place
refactor(build): simplify ENABLE_LTO checking

show more ...


# 7416eb2f 11-Apr-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(build): pass TF_CFLAGS to the assembler

The assembler is already invoked through the gcc/llvm wrapper so will
understand the TF_CFLAGS out of the box. TF_CFLAGS are also quite
comprehensive

refactor(build): pass TF_CFLAGS to the assembler

The assembler is already invoked through the gcc/llvm wrapper so will
understand the TF_CFLAGS out of the box. TF_CFLAGS are also quite
comprehensive. So don't duplicate the definitions and use it directly.
This also allows to absorb TF_CFLAGS_$(ARCH) and CPPFLAGS and reduce
the number of permutations of flags we pass.

Change-Id: I801cea0421dab5a07bf720be9693dce3ef220dcf
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 6bb9f053 25-Apr-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(build): absorb CFLAGS into TF_CFLAGS

CFLAGS is the standard and expected variable for passing flags to the
compiler. The build system also uses TF_CFLAGS to define its own flags.
But the bu

refactor(build): absorb CFLAGS into TF_CFLAGS

CFLAGS is the standard and expected variable for passing flags to the
compiler. The build system also uses TF_CFLAGS to define its own flags.
But the build rules need to specify both. So append CFLAGS to TF_CFLAGS
so that only the latter needs to be passed.

Change-Id: I4abb6c9dfc252a805063691e8a100f0ec0c785ad
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 1e8b5354 29-Apr-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(build): use a standard rule to run the preprocessor

There are a few, functionally identical, ways to call the preprocessor
on a non-C file, depending on the file. They differ in subtle, not

refactor(build): use a standard rule to run the preprocessor

There are a few, functionally identical, ways to call the preprocessor
on a non-C file, depending on the file. They differ in subtle, not
entirely correct, ways - one is missing a dependency to the makefiles,
another generates its .d inline, and the prints are different. That has
resulted in platforms reimplementing this functionality, making the
build brittle - a change to the overall build system doesn't propagate.
So add a MAKE_PRE macro that will make a rule with all the bells and
whistles to run the preprocessor on an arbitrary file.

This patch converts the arm platforms' cot_descriptors DTS rules. The
files are renamed to fit with the build rule and all extra flags are
dropped. Those flags are only necessary for building BL2 c files, which
will be passed to the output C file. Only the DTS flags are needed for
the preprocessing step, which will be passed automatically.

Change-Id: I3c1cc0ecf93b87d828f868214928c1bc9bcb5758
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 69520877 07-Jul-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes from topic "bk/multibuild" into integration

* changes:
fix(lx2160a): put cert_create_tbbr.mk in the standard location
feat(build): put crttool in the build directory
feat(build):

Merge changes from topic "bk/multibuild" into integration

* changes:
fix(lx2160a): put cert_create_tbbr.mk in the standard location
feat(build): put crttool in the build directory
feat(build): put enctool in the build directory
feat(build): put fiptool in the build directory
build(marvell): avoid using recursive expansion for BLE_INCLUDES

show more ...


# cbd6cec3 02-May-2025 Boyan Karatotev <boyan.karatotev@arm.com>

feat(build): put fiptool in the build directory

For some reason, tools are not built in the build directory, but rather
in the source directory, regardless of what BUILD_BASE might say. This
is espe

feat(build): put fiptool in the build directory

For some reason, tools are not built in the build directory, but rather
in the source directory, regardless of what BUILD_BASE might say. This
is especially annoying when trying to have a few builds going at the
same time (like in a CI). For example, run A may check if a file X
exists. Seeing that it does not, it will start building the file. At the
same time, run B may also check if file X exists but before A has
written it, starting a build again. Then it is possible for A to use the
file it believes to have built right at the moment B begins writing to
it (and truncating it beforehand). This results in gcc failing to read a
fail and a failed build. The more parallel runs there are, the more
likely this is to happen, and this is virtually guaranteed to happen
with just a handful onwards.

So move fiptool and all of its build artefacts to the build directory.
Since there are platform differences between the various fiptool
incarnations, this goes in the plat build rather than a more top-level
location.

This patch adds the build macro MAKE_TOOL to do this generically for any
kind of tool since the other tools suffer from the same shortfall. This
macro takes care to use unique names for every type of argument that
building a tool might need. The fiptool makefile and platform add-ons
are updated accordingly.

This should have never been allowed in the first place, but downstream
scripts almost certainly depend on this behaviour now. So add a symlink
in the place of the old fiptool so these continue working. With any
luck, this will be removed in the future.

Change-Id: I3d4d87dab0f53deab5b43fbc6652146f0e4e7e81
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# adb219f0 07-Jul-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge changes I9bc7b609,Ie56dc965,Ic57d46bf,I3f2ab549,I3ad715fa, ... into integration

* changes:
refactor(build): initialise `arch-features` closer to where it is needed
refactor(build): define

Merge changes I9bc7b609,Ie56dc965,Ic57d46bf,I3f2ab549,I3ad715fa, ... into integration

* changes:
refactor(build): initialise `arch-features` closer to where it is needed
refactor(build): define the W and DEBUG flags in the standard way
refactor(build): put the cross referencing of options together
fix: use LDLIBS instead of LDFLAGS for library search paths
fix(build): remove redundant variables
fix(intel): fix variable may be used uninitialized error

show more ...


# 500927ef 29-Apr-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(build): remove redundant variables

The PLAT_BL_* family of variables were intended as the platform
interface to the build system. Unfortunately, only
PLAT_BL_COMMON_SOURCES has caught on and the

fix(build): remove redundant variables

The PLAT_BL_* family of variables were intended as the platform
interface to the build system. Unfortunately, only
PLAT_BL_COMMON_SOURCES has caught on and the rest remain totally
unused. As there is no ongoing effort to change that, those flags are
only noise in the makefiles. Remove them to simplify.

Change-Id: I3ad715fa7859a28cf92d3897421f7b88cdea23cc
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 183f2ea2 04-Mar-2025 Manish Pandey <manish.pandey2@arm.com>

Merge changes I0396b597,I326f920f,I0437eec8,Ieadf01fc,I4e1d8c24, ... into integration

* changes:
feat(fvp): set defaults for build commandline
docs(arm): enable Linux boot from fip as BL33
fea

Merge changes I0396b597,I326f920f,I0437eec8,Ieadf01fc,I4e1d8c24, ... into integration

* changes:
feat(fvp): set defaults for build commandline
docs(arm): enable Linux boot from fip as BL33
feat(arm): enable Linux boot from fip as BL33
docs(fvp): update fvp build time options
docs(arm): add initrd props to dtb at build time
feat(arm): add initrd props to dtb at build time

show more ...


# 1c08ff32 12-Dec-2024 Salman Nabi <salman.nabi@arm.com>

feat(arm): add initrd props to dtb at build time

Add initrd properties to the device tree blob at build time, giving
users the ability to run a linux kernel and successfully boot it to
the terminal.

feat(arm): add initrd props to dtb at build time

Add initrd properties to the device tree blob at build time, giving
users the ability to run a linux kernel and successfully boot it to
the terminal. Users can boot a linux kernel in a normal flow as well
as in RESET_TO_BL31. This function is an extension of the build time
option "ARM_LINUX_KERNEL_AS_BL33=1".

The build time options INITRD_SIZE or INITRD_PATH will trigger the
insertion of initrd properties in to the DTB. If both options are
provided then the INITRD_SIZE will take precedence.

The available options are:
INITRD_SIZE: Provide the initrd size in dec or hex (hex format must
precede with '0x'.
Example: INITRD_SIZE=0x1000000

INITRD_PATH: Provide an initrd path for the build time to find its
exact size.

INITRD_BASE: A required build time option that sets the initrd base
address in hex format. A default value can be set by the platform.
Example: INITRD_BASE=0x90000000

Change-Id: Ief8de5f00c453509bcc6e978e0a95d768f1f509c
Signed-off-by: Salman Nabi <salman.nabi@arm.com>

show more ...


123456789