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

fix(build): simplify the -target options

It turns out that there are a lot of ways to specify the target
triplets, some of which are identical in meaning. This allows us to use
a single unambiguous

fix(build): simplify the -target options

It turns out that there are a lot of ways to specify the target
triplets, some of which are identical in meaning. This allows us to use
a single unambiguous triplet regardless of build flags.

This was spotted in
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/36980/comment/ced50479_a1e937c0/

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

show more ...

feat(build): allow full LTO builds with clang

GCC doesn't like LTOing __builtins. This has been broken for time
immemorial (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215) and
there is no fi

feat(build): allow full LTO builds with clang

GCC doesn't like LTOing __builtins. This has been broken for time
immemorial (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215) and
there is no fix coming. Prior to GCC 14 a build of the libc with LTO
will simply not work. From GCC14 a workaround is possible passing
-ffat-lto-objects. The underlying issue is that the linker "forgets"
about builtin symbols it added during LTO. The non-LTO copies make these
forgotten functions available during final resolution. However, this
still does not LTO the libc, it just allows for it to build with -flto.

Since GCC is our main compiler, and we do not differentiate the libc
from any other lib we build, we have simply not built libs with LTO so
far. However, there is no need to kneecap clang for GCC's failings, so
LTO all libs on clang when enabled.

When GCC14 becomes the oldest reasonable compiler we support, this can
be done for GCC too, although with the workaround above. This still
won't LTO the libc, but it will at least LTO other libs.

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

show more ...

refactor(build): make sorting of sections generic

All BLs define essentially the same sequence for sorting of sections.
Make that generic so it applies more easily.

Change-Id: I81f5f6635232bd43d999

refactor(build): make sorting of sections generic

All BLs define essentially the same sequence for sorting of sections.
Make that generic so it applies more easily.

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

show more ...

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

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

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pa

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pass the same flags to the compilation and linking stages when we enable
LTO. This is crucial for things like the undefined behaviour sanitiser.
Anecdotally, in working on this, there have been a fair few errors that
the compiler has only been able to catch due to warning flags being
passed to the linker and building with LTO.

This patch puts the contents of TF_CFLAGS into TF_LDFLAGS when LTO is
enabled. This is easier said than done, however, as we support building
with clang and linking with gcc (or vice versa), so CFLAGS that are
discovered for one will not work for the other. This patch works around
this by splitting all flags into a per-compiler variable. Then CFLAGS
and LDFLAGS get the contents of the correct one.

Some notable side effects: CPPFLAGS and TF_CFLAGS_$(ARCH) become empty
and are removed, although expanding them is kept as platforms set them.
Some flags become duplicate and are removed form TF_LDFLAGS (eg -O1).

The errata (--fix) flags are kept as-is but moved to cpu-ops.mk for
consistency. This is because they currently don't work with LTO and will
be addressed in a later patch.

Finally, ERROR_DEPRECATED's flags are also identical on all compilers so
don't maintain a difference.

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

show more ...

feat(cpufeat): enable FEAT_AIE support

Implement support for FEAT_AIE, which introduces the AMAIR2_ELx and
MAIR2_ELx system registers, extending the memory attributes described
by {A}MAIR_ELx.
Those

feat(cpufeat): enable FEAT_AIE support

Implement support for FEAT_AIE, which introduces the AMAIR2_ELx and
MAIR2_ELx system registers, extending the memory attributes described
by {A}MAIR_ELx.
Those system registers are trapped by the SCR_EL3.AIEn bit, so set the
bit for the non-secure world context to allow OSes to use the feature.

This is controlled by the ENABLE_FEAT_AIE build flag, which follows the
usual semantics of 2 meaning the feature being runtime detected.
Let the default for this flag be 0, but set it to 2 for the FVP.

Change-Id: Iba2011719013a89f9cb3a4317bde18254f45cd25
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

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

Merge "refactor(el3-runtime): extract cpu_data limitations to top-level constraints" into integration

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

feat(cpufeat): enable FEAT_CPA2 for EL3

FEAT_CPA2 enables checked pointer arithmetic, which in the event
of an arithmetic overflow in pointer generation will result in a
non-canonical pointer being

feat(cpufeat): enable FEAT_CPA2 for EL3

FEAT_CPA2 enables checked pointer arithmetic, which in the event
of an arithmetic overflow in pointer generation will result in a
non-canonical pointer being generated and subsequent address fault.

Note that FEAT_CPA is a trivial implementation that exists in
some hardware purely so it can run CPA2-enabled instructions
without crashing but they don't actually have checked arithmetic,
so FEAT_CPA is not explicitly enabled in TF-A.

Change-Id: I6d2ca7a7e4b986bb9e917aa8baf8091a271c168b
Signed-off-by: John Powell <john.powell@arm.com>

show more ...

refactor(el3-runtime): extract cpu_data limitations to top-level constraints

CRASH_REPORTING is checked via an `#error` statement in the header,
while EL3_EXCEPTION_HANDLING is carefully carved out

refactor(el3-runtime): extract cpu_data limitations to top-level constraints

CRASH_REPORTING is checked via an `#error` statement in the header,
while EL3_EXCEPTION_HANDLING is carefully carved out when not supported.
However, both are only used on AArch64 builds and never on AArch32. We
can promote both to proper make constraints and keep the cpu_data
implementation a little bit simpler.

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

show more ...

fix(cm): deprecate use of NS_TIMER_SWITCH

On AArch64, secure world has it's own EL3 physical timer registers
accessible to secure EL1 in absence of S-EL2. With S-EL2 there is
virtualized view availa

fix(cm): deprecate use of NS_TIMER_SWITCH

On AArch64, secure world has it's own EL3 physical timer registers
accessible to secure EL1 in absence of S-EL2. With S-EL2 there is
virtualized view available for EL1 timer registers. So it is
unreasonable for secure world to use non-secure EL1 physical timer
registers. Moreover, the non-secure operating system (Linux in our case)
relies heavily on these EL1 physical timer registers for scheduling
decisions. If NS_TIMER_SWITCH is enabled, it simply breaks the preemption
model of the non-secure world by disabling non-secure timer interrupts
leading to RCU stalls being observed on long running secure world tasks.

The only arch timer register which will benefit from context management
is cntkctl_el1: Counter-timer Kernel Control Register. This enables the
secure and non-secure worlds to independently control accesses to EL0
for counter-timer registers. This is something that OP-TEE uses to
enable ftrace feature for Trusted Applications and SPM_MM uses for EL0
access as well.

Lets enable context management of cntkctl_el1 by default and deprecate
conditional context management of non-secure EL1 physical timer
registers for whom there isn't any upstream user. With that deprecate
this NS_TIMER_SWITCH build option which just adds confusion for the
platform maintainers. It will be eventually dropped following
deprecation policy of TF-A.

Reported-by: Stauffer Thomas MTANA <thomas.stauffer@mt.com>
Reported-by: Andrew Davis <afd@ti.com>
Change-Id: Ifb3a919dc0bf8c05c38895352de5fe94b4f4387e
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

show more ...

feat(build): add utilities for modifying includes

Add Makefile helpers to manipulate and extract include directories.
Introduce strip-quotes, include-dirs, and include-dirs-realpath
utilities for fl

feat(build): add utilities for modifying includes

Add Makefile helpers to manipulate and extract include directories.
Introduce strip-quotes, include-dirs, and include-dirs-realpath
utilities for flexible processing of -I flags.

Change-Id: Ic8051d299b43e7efeca4cccd8c36115bc8393bcf
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Co-authored-by: Chris Kay <Chris.Kay@arm.com>

show more ...

Merge changes from topic "xl/separate-bl2" into integration

* changes:
feat(fwu): documentation for BL2 separation
feat(fwu): separate bl2 image from rest of the FIP
feat(fwu): create flag for

Merge changes from topic "xl/separate-bl2" into integration

* changes:
feat(fwu): documentation for BL2 separation
feat(fwu): separate bl2 image from rest of the FIP
feat(fwu): create flag for BL2 separation

show more ...

feat(fwu): separate bl2 image from rest of the FIP

Create a separate partition for BL2 image in the GPT.
Modify the makefile to package BL2 image and its certificates
into a different FIP image.

Ch

feat(fwu): separate bl2 image from rest of the FIP

Create a separate partition for BL2 image in the GPT.
Modify the makefile to package BL2 image and its certificates
into a different FIP image.

Change-Id: I950883ea0c393a2a063ad9e51bb963cbac742705
Signed-off-by: Xialin Liu <xialin.liu@arm.com>

show more ...

feat(cpufeat): enable FEAT_MPAM_PE_BW_CTRL support

Implement support for FEAT_MPAM_PE_BW_CTRL, allowing lower
Exception Levels to access MPAM_PE_BW_CTRL control registers
by disabling their traps to

feat(cpufeat): enable FEAT_MPAM_PE_BW_CTRL support

Implement support for FEAT_MPAM_PE_BW_CTRL, allowing lower
Exception Levels to access MPAM_PE_BW_CTRL control registers
by disabling their traps to EL3.

When INIT_UNUSED_NS_EL2=1, configure MPAMBW2_EL2 in EL3 so
that MPAM_PE_BW_CTRL accesses from EL0/EL1 do not trap to EL2.

At this stage, PE-side MPAM bandwidth controls remain disabled
in EL3.

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

show more ...

feat(fwu): create flag for BL2 separation

Adding a flag for BL2 separation in common
Makefile, for the usage of non FVP platform

Change-Id: I45ecb6833cdbc4873ffe460fd448814d81d6fa4d
Signed-off-by:

feat(fwu): create flag for BL2 separation

Adding a flag for BL2 separation in common
Makefile, for the usage of non FVP platform

Change-Id: I45ecb6833cdbc4873ffe460fd448814d81d6fa4d
Signed-off-by: Xialin Liu <xialin.liu@arm.com>

show more ...

fix(simd): enforce FP regs context mgmt when SVE regs are enabled

Due to architectural dependency, FP register context management
needs to be enabled when SVE register context management is enabled.

fix(simd): enforce FP regs context mgmt when SVE regs are enabled

Due to architectural dependency, FP register context management
needs to be enabled when SVE register context management is enabled.
This patch adds a make-time constraint for the same.

Change-Id: I8ae52edcb10085105c6e0c5504f427093059f50d
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@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 ...

fix(build): fix Makefile syntax in constraints helpers

Make is notoriously picky about tabs vs. spaces at the beginning of a
line, and some error paths in our Makefile helpers are suffering from
thi

fix(build): fix Makefile syntax in constraints helpers

Make is notoriously picky about tabs vs. spaces at the beginning of a
line, and some error paths in our Makefile helpers are suffering from
this.

Replace the indentation by tabs with spaces when it's not a (shell)
recipe, to fix the error reporting in some cases:

$ make PLAT=fvp ENABLE_SPMD_LP=1 SPMC_AT_EL3=1
make_helpers/constraints.mk:54: *** recipe commences before first target. Stop.

Change-Id: Ie8c49c8535e4b9b968d808113aa72b9dafeef906
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

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

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