feat(build): redirect stdin to nul during toolchain detection

It's common for Makefiles to use variables like CC, AS or LD instead of
hardcoding the name of binaries. These can be defined by the use

feat(build): redirect stdin to nul during toolchain detection

It's common for Makefiles to use variables like CC, AS or LD instead of
hardcoding the name of binaries. These can be defined by the user to
use a differnet toolchain or even as a crutch to enable cross-compilation.

In TF-A, this is not needed, as support for cross-compilation is baked
in via the CROSS_COMPILE option. TF-A still defined AS for its internal
use, but unlike most other projects, the default was setting it to the C
compiler. Overriding it wasn't possible from the environment though,
only as a make argument, so this didn't cause much issue.

With commit cc277de81692 ("build: refactor toolchain detection"), AS can
now also be set from the environment. This breaks any scripts that
supply make with a cross environment that sets AS to an assembler.

Doing so was without effect before, but now leads to a quite ugly failure
mode: As TF-A now tries to detect the toolchain, it will call AS with the
option -v, which for GNU as(1) prints the version, but doesn't exit.

Thus, as(1) will continue waiting on stdin input and the build hangs
without much indication what's wrong.

Avoid this failure mode by ensuring any tool that attempts to read stdin
during toolchain detection will immediately get EOF and exit, leading to
an error message later on instead of the build hang.

Change-Id: I79a84961f5a69250292caa7f9e879a65be4bd9f2
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

show more ...

Merge "build: use GCC to link by default" into integration

Merge "fix(build): don't rely on that gcc-ar is in the same directory as gcc" into integration

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to support LTO, which can only be done when linking
is done via the C compiler, and we cannot change the linker later on if
some other part of the build system wants to enable LTO.

This change migrates the default choice of linker to GCC if the C
compiler is GCC, in order to enable this use-case. This should have no
impact on anything outside of the build system, as by default GCC merely
acts as a wrapper around BFD.

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

show more ...

refactor(mte): remove mte, mte_perm

Currently both FEAT_MTE and FEAT_MTE_PERM aren't used for enabling
of any feature bits in EL3. So remove both FEAT handling.

All mte regs that are currently cont

refactor(mte): remove mte, mte_perm

Currently both FEAT_MTE and FEAT_MTE_PERM aren't used for enabling
of any feature bits in EL3. So remove both FEAT handling.

All mte regs that are currently context saved/restored are needed
only when FEAT_MTE2 is enabled, so move to usage of FEAT_MTE2 and
remove FEAT_MTE usage.

BREAKING CHANGE: Any platform or downstream code trying to use
SCR_EL3.ATA bit(26) will see failures as this is now moved to be
used only with FEAT_MTE2 with
commit@ef0d0e5478a3f19cbe70a378b9b184036db38fe2

Change-Id: Id01e154156571f7792135639e17dc5c8d0e17cf8
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

feat(tc): add DPE backend to the measured boot framework

The client platform relies on the DICE attestation
scheme. RSS provides the DICE Protection Environment
(DPE) service. TF-A measured boot fra

feat(tc): add DPE backend to the measured boot framework

The client platform relies on the DICE attestation
scheme. RSS provides the DICE Protection Environment
(DPE) service. TF-A measured boot framework supports
multiple backends. A given platform always enables
the corresponding backend which is required by the
attestation scheme.

Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Idc3360d0d7216e4859e99b5db3d377407e0aeee5

show more ...

fix(build): don't rely on that gcc-ar is in the same directory as gcc

ccache - a fast C/C++ compiler cache.
ccache wraps gcc and g++ compilers, but not other tools like ar.
If ccache is installed, t

fix(build): don't rely on that gcc-ar is in the same directory as gcc

ccache - a fast C/C++ compiler cache.
ccache wraps gcc and g++ compilers, but not other tools like ar.
If ccache is installed, then build fails with

```
make: /usr/lib/ccache/aarch64-linux-gnu-gcc-ar: No such file or directory
```

Change-Id: I555c178aeaa0cf411cdf67b4a81e7952be762d0f
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

feat(fwu): add a config flag for including image info in the FWU metadata

The version 2 of the FWU metadata structure is designed such that the
information on the updatable images can be omitted fro

feat(fwu): add a config flag for including image info in the FWU metadata

The version 2 of the FWU metadata structure is designed such that the
information on the updatable images can be omitted from the metadata
structure. Add a configuration flag, PSA_FWU_METADATA_FW_STORE_DESC,
which is used to select whether the metadata structure has this
information included or not. It's value is set to 1 by default.

Change-Id: I4463a20c94d2c745ddb0b2cc8932c12d418fbd42
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

show more ...

build: correct minor toolchain documentation error

Default values for toolchain tools are instead provided by the main
toolchain makefile, rather than a parent makefile. This was an oversight
from a

build: correct minor toolchain documentation error

Default values for toolchain tools are instead provided by the main
toolchain makefile, rather than a parent makefile. This was an oversight
from a previous version of the original toolchain refactor patch.

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

show more ...

Merge "build: use toolchain identifiers in conditions" into integration

Merge "build: use new toolchain variables for tools" into integration

Merge "build: refactor toolchain detection" into integration

feat(mte): add mte2 feat

Add support for feat mte2. tfsr_el2 is available only with mte2,
however currently its context_save/restore is done with mte rather than
mte2, so introduce 'is_feat_mte2_sup

feat(mte): add mte2 feat

Add support for feat mte2. tfsr_el2 is available only with mte2,
however currently its context_save/restore is done with mte rather than
mte2, so introduce 'is_feat_mte2_supported' to check mte2.

Change-Id: I108d9989a8f5b4d1d2f3b9865a914056fa566cf2
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the build system. This change replaces the various conditions that
are in use to identify these tools based on the path with a standard set
of comparisons against these new identifier variables.

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

show more ...

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by the toolchain refactor patch. These variables should be
equivalent to the values that they're replacing.

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

show more ...

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default to

build: refactor toolchain detection

This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default tools, identify the tools in use, and configure
toolchain flags.

To do this, we introduce three new concepts in this change:

- Toolchain identifiers,
- Tool class identifiers, and
- Tool identifiers.

Toolchain identifiers identify a configurable chain of tools targeting
one platform/machine/architecture. Today, these are:

- The host machine, which receives the `host` identifier,
- The AArch32 architecture, which receives the `aarch32` identifier, and
- The AArch64 architecture, which receivs the `aarch64` identifier.

The tools in a toolchain may come from different vendors, and are not
necessarily expected to come from one single toolchain distribution. In
most cases it is perfectly valid to mix tools from different toolchain
distributions, with some exceptions (notably, link-time optimization
generally requires the compiler and the linker to be aligned).

Tool class identifiers identify a class (or "role") of a tool. C
compilers, assemblers and linkers are all examples of tool classes.

Tool identifiers identify a specific tool recognized and supported by
the build system. Every tool that can make up a part of a toolchain must
receive a tool identifier.

These new identifiers can be used to retrieve information about the
toolchain in a more standardized fashion.

For example, logic in a Makefile that should only execute when the C
compiler is GNU GCC can now check the tool identifier for the C compiler
in the relevant toolchain:

ifeq ($($(ARCH)-cc-id),gnu-gcc)
...
endif

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

show more ...

refactor(build): minor updates

Move RME to 9.2 optional features and add minor updates to comments.

Change-Id: I12a4940e82ca5df72af5421ddab43bc6a1628e95
Signed-off-by: Govindraj Raja <govindraj.raj

refactor(build): minor updates

Move RME to 9.2 optional features and add minor updates to comments.

Change-Id: I12a4940e82ca5df72af5421ddab43bc6a1628e95
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

fix(build): march handling with arch-features

Currently all march compiler option handling is moved to build
utility in march.mk.

We pass arch-features to build which appends to march options,
so t

fix(build): march handling with arch-features

Currently all march compiler option handling is moved to build
utility in march.mk.

We pass arch-features to build which appends to march options,
so this should be done once we decide march options and moving
it to march.mk file.

Change-Id: Ifaf99af5f371fd28db376a12657ccf4f363295c2
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(build): refactor mandatory options

Currently we enable all mandatory options for a current MAJOR.MINOR
number without considering architecturally to what version the current
arch should be

refactor(build): refactor mandatory options

Currently we enable all mandatory options for a current MAJOR.MINOR
number without considering architecturally to what version the current
arch should be compliant with.

For example Arch v9 should be compliant with 8.5 and shouldn't
consider being compliant with 8.9, so refactor FEAT_* handling to
ensure we capture and handle compliance correctly.

So refactor to use a list and add FEAT_* which are only compliant
with a given arch rather than relying on all the FEAT_* from previous
should be enabled for given arch version.

Change-Id: I8b0dd076c168a647de43b8618fbbe607412f7cab
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge "refactor(build): allow mandatory feats disabling" into integration

refactor(build): allow mandatory feats disabling

Currently any arch FEAT_* can be enabled from:
- command line build options
- platform makefile
- from arch_features.mk

These are in order. Howev

refactor(build): allow mandatory feats disabling

Currently any arch FEAT_* can be enabled from:
- command line build options
- platform makefile
- from arch_features.mk

These are in order. However, mandatory features are enforced from
arch_features.mk and platform makefile can't override them.

Allow command line options or platforms makefile to disable any
mandatory features.

Change-Id: I6fdca1a3d0b405a88cd7a20309e0c1eecd57a650
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

feat(cpufeat): add feature detection for FEAT_CSV2_3

This feature provides support to context save the
SCXTNUM_ELx register. FEAT_CSV2_3 implies the implementation
of FEAT_CSV2_2. FEAT_CSV2_3 is sup

feat(cpufeat): add feature detection for FEAT_CSV2_3

This feature provides support to context save the
SCXTNUM_ELx register. FEAT_CSV2_3 implies the implementation
of FEAT_CSV2_2. FEAT_CSV2_3 is supported in AArch64 state only
and is an optional feature in Arm v8.0 implementations.

This patch adds feature detection for v8.9 feature FEAT_CSV2_3,
adds macros for ID_AA64PFR0_EL1.CSV2 bits [59:56] for detecting
FEAT_CSV2_3 and macro for ENABLE_FEAT_CSV2_3.

Change-Id: Ida9f31e832b5f11bd89eebd6cc9f10ddad755c14
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>

show more ...

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments`

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments` when linking with GCC
build: always use the C compiler to assemble
build: always use the C compiler to preprocess
fix(rcar): fix implicit rule invocations in tools

show more ...

refactor(mte): deprecate CTX_INCLUDE_MTE_REGS

Currently CTX_INCLUDE_MTE_REGS is used for dual purpose,
to enable allocation tags register and to context save and restore
them and also to check if mt

refactor(mte): deprecate CTX_INCLUDE_MTE_REGS

Currently CTX_INCLUDE_MTE_REGS is used for dual purpose,
to enable allocation tags register and to context save and restore
them and also to check if mte feature is available.

To make it more meaningful, remove CTX_INCLUDE_MTE_REGS
and introduce FEAT_MTE. This would enable allocation tags register
when FEAT_MTE is enabled and also supported from platform.

Also arch features can be conditionally enabled disabled based on
arch version from `make_helpers/arch_features.mk`

Change-Id: Ibdd2d43874634ad7ddff93c7edad6044ae1631ed
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

build: add `--no-warn-rwx-segments` when linking with GCC

This flag is currently not included when linking with BFD via GCC.
Without it, builds can fail when linking via GCC.

Change-Id: Id37e05f6fb

build: add `--no-warn-rwx-segments` when linking with GCC

This flag is currently not included when linking with BFD via GCC.
Without it, builds can fail when linking via GCC.

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

show more ...