Merge "fix(docs): obey the build directory" into integration

fix(docs): obey the build directory

Like everything else, BUILD_BASE should be the canonical place to put
all output of a build.

Change-Id: Ibab9992550bb70fc0b71453ada37cdc94858f6fc
Signed-off-by:

fix(docs): obey the build directory

Like everything else, BUILD_BASE should be the canonical place to put
all output of a build.

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

show more ...

Merge "feat(common): add support for kernel DT handoff convention" into integration

feat(common): add support for kernel DT handoff convention

TF-A currently supports multiple DT handoff conventions:

1. Firmware Handoff (FH): DT passed in x0, with x1–x3 carrying
additional data

feat(common): add support for kernel DT handoff convention

TF-A currently supports multiple DT handoff conventions:

1. Firmware Handoff (FH): DT passed in x0, with x1–x3 carrying
additional data.
2. Kernel-compatible handoff (ARM_LINUX_KERNEL_AS_BL33): DT passed in
x0, x1–x3 zeroed.
3. Legacy TF-A convention: DT passed in x1, with x0 used for MPIDR or
NT_FW_CONFIG.

After discussions with folks in EDK2 and U-Boot, it's clear that there
is no strict requirement for placing the DT in x1. Both projects support
x0 for Arm platforms. To standardize behavior and support firmware
handoff migration, this patch introduces USE_KERNEL_DT_CONVENTION as a
configurable build flag. When enabled, the DT will be passed in x0 for
BL33.

This aligns TF-A’s behavior with Linux boot expectations and simplifies
integration across bootloaders.

Change-Id: I6bd7154fe07cb2e16e25c058f7cf862f9ae007e7
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

Merge "build: fix incorrect `memory summary` command" into integration

build: fix incorrect `memory summary` command

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

Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that

Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that CPUs handled a pabandon
feat(psci): make pabandon support generic
refactor(psci): unify coherency exit between AArch64 and AArch32
refactor(psci): absorb psci_power_down_wfi() into common code
refactor(platforms): remove usage of psci_power_down_wfi
fix(cm): disable SPE/TRBE correctly

show more ...

feat(psci): make pabandon support generic

Support for aborted powerdowns does not require much dedicated code.
Rather, it is largely a matter of orchestrating things to happen in the
right order.

T

feat(psci): make pabandon support generic

Support for aborted powerdowns does not require much dedicated code.
Rather, it is largely a matter of orchestrating things to happen in the
right order.

The only exception to this are older secure world dispatchers, which
assume that a CPU_SUSPEND call will be terminal and therefore can
clobber context. This was patched over in common code and hidden behind
a flag. This patch moves this to the dispatchers themselves.

Dispatchers that don't register svc_suspend{_finish} are unaffected.
Those that do must save the NS context before clobbering it and
restoring in only in case of a pabandon. Due to this operation being
non-trivial, this patch makes the assumption that these dispatchers will
only be present on hardware that does not support pabandon and therefore
does not add any contexting for them. In case this assumption ever
changes, asserts are added that should alert us of this change.

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

show more ...

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 ...

refactor(build): place all cflags setting in one place

The top-level Makefile has to come up with a list of flags to pass to
the compiler. It has to do so while considering a variety of options and

refactor(build): place all cflags setting in one place

The top-level Makefile has to come up with a list of flags to pass to
the compiler. It has to do so while considering a variety of options and
constraints. This has generally done in the most convenient place in the
file. However, it causes problems with evaluation - options may be set
after they are used, there may be platform dependencies, DEFINES, etc.
As a result flags must be lazily evaluated and they lack any cohesive
design.

To enable a solution to this, extract all CFLAGS/LDFLAGS/ASFLAGS
configuration to a new file. Reorder rules slightly to put related rules
closer together and call the entire thing as late as possible - after
platform.mk and after the DEFINES are known.

There is a small number of libraries that set flags in their own sub
makefiles. As these contain the entire feature, do not move their flags
to keep them self-contained. This is okay as these makefile will be
evaluated before the cflags.

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

show more ...

refactor(build): simplify ENABLE_LTO checking

We do not support LTO with AArch32. The standard way to enforce this is
by having a rule to fail the build when this happens. There are no
AArch32 platf

refactor(build): simplify ENABLE_LTO checking

We do not support LTO with AArch32. The standard way to enforce this is
by having a rule to fail the build when this happens. There are no
AArch32 platforms which (incorrectly) try to enable LTO, so add this
rule. The benefit is that we no longer have to check the ENABLE_LTO with
ARCH whenever it is used.

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

show more ...

Merge "feat(cpufeat): add support for FEAT_FGWTE3" into integration

feat(cpufeat): add support for FEAT_FGWTE3

Enable write traps for key EL3 system registers as per FEAT_FGWTE3,
ensuring their values remain unchanged after boot.

Excluded Registers:
MDCR_EL3 and MP

feat(cpufeat): add support for FEAT_FGWTE3

Enable write traps for key EL3 system registers as per FEAT_FGWTE3,
ensuring their values remain unchanged after boot.

Excluded Registers:
MDCR_EL3 and MPAM3_EL3: Not trapped as they are part of the EL3 context.
SCTLR_EL3: Not trapped since it is overwritten during
powerdown sequence(Included when HW_ASSISTED_COHERENCY=1)

TPIDR_EL3: Excluded due to its use in crash reporting(It is included
when CRASH_REPORTING=0)

Reference:
https://developer.arm.com/documentation/ddi0601/2025-06/AArch64-Registers/FGWTE3-EL3--Fine-Grained-Write-Traps-EL3

Change-Id: Idcb32aaac7d65a0b0e5c90571af00e01a4e9edb1
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>

show more ...

Merge "fix(build): add DTB dependency for certificate generation" into integration

fix(build): add DTB dependency for certificate generation

When building ARM Trusted Firmware with Trusted Board Boot enabled
(TRUSTED_BOARD_BOOT=1 and GENERATE_COT=1) using parallel builds
(make -j)

fix(build): add DTB dependency for certificate generation

When building ARM Trusted Firmware with Trusted Board Boot enabled
(TRUSTED_BOARD_BOOT=1 and GENERATE_COT=1) using parallel builds
(make -j), the build fails with a dependency error where
certificate generation starts before Device Tree Blob (DTB)
files are built, even though certificates depend on DTB files.

Change-Id: I51bfe6c99406c77addb8f680351cbae6cf10edc6
Signed-off-by: Fabien Lehoussel <fabien.lehoussel@smile.fr>

show more ...

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 ...

feat(build): put crttool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Leave
a symli

feat(build): put crttool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Leave
a symlink for the final binary in case someone depends on it.

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

show more ...

feat(build): put enctool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Only
differen

feat(build): put enctool in the build directory

Same as fiptool. Move all artefacts to the platform build directory and
convert to the standard build macro to make things more generic. Only
difference is that there is no symlink as the tool is only used
internally and is not exported.

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

show more ...

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 ...

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 ...

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

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

refactor(build): define the W and DEBUG flags in the standard way

We have the assert_boolean section where DEBUG belongs and W should have
an initial value (of 0) and only be allowed to be a number.

refactor(build): define the W and DEBUG flags in the standard way

We have the assert_boolean section where DEBUG belongs and W should have
an initial value (of 0) and only be allowed to be a number.

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

show more ...

refactor(build): put the cross referencing of options together

We have an immense number of incompatible options and several places to
check them, making things hard to follow and leading to some
du

refactor(build): put the cross referencing of options together

We have an immense number of incompatible options and several places to
check them, making things hard to follow and leading to some
duplication. Previous attempts at reordering helped in the short term
but things have slowly deteriorated again.

Tackle this by introducing a single file to do all cross referencing of
all options. This should remove any ambiguity as to where these go.

No functional change besides relative ordering in the top-level Makefile.

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

show more ...

Merge changes from topic "mb/lfa-core-work" into integration

* changes:
docs(maintainers): add myself as code owner for LFA service
docs(lfa): update porting guide with LFA platform APIs
feat(

Merge changes from topic "mb/lfa-core-work" into integration

* changes:
docs(maintainers): add myself as code owner for LFA service
docs(lfa): update porting guide with LFA platform APIs
feat(lfa): add LFA holding pen logic
feat(lfa): add initial implementation for LFA_ACTIVATE
feat(lfa): add initial implementation for LFA_PRIME
feat(fvp): implement platform API for load and auth image
feat(lfa): implement LFA_CANCEL SMC
feat(fvp): implement platform API for LFA cancel operation
feat(lfa): implement LFA_GET_INVENTORY SMC
feat(fvp): implement platform API for LFA activation pending check
feat(lfa): implement LFA_GET_INFO SMC and integrate LFA build
feat(fvp): initialize LFA component activators in platform layer
feat(rmm): add placeholder activator callbacks for LFA
feat(bl31): add placeholder activator implementation for LFA
feat(lfa): add activation handler interface for component activation
feat(fvp): implement LFA get components API
feat(lfa): create LFA SMC handler template

show more ...

feat(lfa): create LFA SMC handler template

As per the specification v1.0[1], added all Live Firmware Activation
(LFA) SMCs, including their Function IDs (FIDs) and associated error
codes.
A dummy ha

feat(lfa): create LFA SMC handler template

As per the specification v1.0[1], added all Live Firmware Activation
(LFA) SMCs, including their Function IDs (FIDs) and associated error
codes.
A dummy handler function has been created as a template. Subsequent
patches will implement the handling of these SMCs.

[1]: https://developer.arm.com/documentation/den0147/latest/

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I5d6500dcff35aa4a438cd5f97f349cd57406ddce

show more ...