build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used

build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used for the build at the initialization of the build
system.

This incurs a large cost to the build every time - for every toolchain
that has been requested by the current makefile, we try to identify each
tool in the list of known tool classes, even if that tool doesn't
actually see any use.

For the clean and check-like targets we worked around this by disabling
most of the toolchains if we detect these targets, but this is
inflexible and not very reliable, and it still means that when building
normal targets we are incurring that cost for all tools whether they are
used or not.

This change instead modifies the toolchain detection framework to only
initialize a tool for a given toolchain when it is first used. This does
mean that we can no longer warn about an incorrectly-configured
toolchain at the beginning of build system invocation, but it has the
advantage of substantially reducing build time and the complexity of
*using* the framework (at the cost of an increase in complexity in the
framework itself).

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

show more ...

Merge "fix(arm): add extra hash config to validate ROTPK" into integration

fix(arm): add extra hash config to validate ROTPK

The default mbedTLS configuration enables hash algorithms based on
the HASH_ALG or MBOOT_EL_HASH_ALG selected. However, the Arm ROTPK
is always embe

fix(arm): add extra hash config to validate ROTPK

The default mbedTLS configuration enables hash algorithms based on
the HASH_ALG or MBOOT_EL_HASH_ALG selected. However, the Arm ROTPK
is always embedded as a SHA256 hash in BL1 and BL2. In the future,
we may need to adjust this to use the HASH_ALG algorithm for
embedding the ROTPK hash.

As a temporary workaround, a separate mbedTLS configuration has
been created for Arm platforms to explicitly set SHA256 defines,
rather than relying on the default configuration. This adjustment
is reflected in the mbedTLS configuration file for the TC platform
as well as in the PSA Crypto configuration file.

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

show more ...

Merge "feat(versal2): implement USB_SET_STATE dummy IOCTL" into integration

feat(st): manage BL31 FCONF load_info struct

As the file is common with STM32MP1, which is AARCH32, the BL31 entry
is put under __aarch64__ flag.

Change-Id: I1efc406717842235264dc6cc3605229659364b0

feat(st): manage BL31 FCONF load_info struct

As the file is common with STM32MP1, which is AARCH32, the BL31 entry
is put under __aarch64__ flag.

Change-Id: I1efc406717842235264dc6cc3605229659364b02
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Signed-off-by: Maxime Méré <maxime.mere@foss.st.com>

show more ...

feat(tc): make TCR2 feature asymmetric

Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I6209dc46ddecaa09cc1220fe9488b3771ea6dc38

feat(versal2): implement USB_SET_STATE dummy IOCTL

USB DWC3 driver calls firmware API to set USB D0/D3 power states.
In absence of firmware driver probe these PM APIs return -ENODEV
and DWC3 driver

feat(versal2): implement USB_SET_STATE dummy IOCTL

USB DWC3 driver calls firmware API to set USB D0/D3 power states.
In absence of firmware driver probe these PM APIs return -ENODEV
and DWC3 driver probe fails. Till PLM implement these PM APIs as
a temporary workaround add dummy PM implementation in TFA.

Change-Id: I8768301524ffdc2f275221296feaa2a3ad0ad4f6
Signed-off-by: Maheedhar Bollapalli <MaheedharSai.Bollapalli@amd.com>

show more ...

Merge "fix(xilinx): optimize logic to read IPI response" into integration

Merge changes from topic "mbedtls-config-cleanup" into integration

* changes:
chore(qemu): remove duplicate define
chore(imx): remove duplicate define
chore(arm): remove duplicate defines
ch

Merge changes from topic "mbedtls-config-cleanup" into integration

* changes:
chore(qemu): remove duplicate define
chore(imx): remove duplicate define
chore(arm): remove duplicate defines
chore(mbedtls): remove hash configs

show more ...

chore(qemu): remove duplicate define

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Change-Id: Id18abe80ab56fd51a9c2c1206b22d87f1e3871eb

chore(imx): remove duplicate define

Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
Change-Id: If55d4e2777ca2cdcf55da3b2a60d99f694a2c94d

chore(arm): remove duplicate defines

Change-Id: I9eea1610660bfa92f7781deab60e29eae11c4ba6
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>

Merge "fix(stm32mp2): remove mapping of BL2 DT area" into integration

fix(stm32mp2): remove mapping of BL2 DT area

To prevent from coding issues that could overwrite DT area, we were
mapping this area as read-only on STM32MP1. But on STM32MP2, we need
this area to put

fix(stm32mp2): remove mapping of BL2 DT area

To prevent from coding issues that could overwrite DT area, we were
mapping this area as read-only on STM32MP1. But on STM32MP2, we need
this area to put BL31 binary. We were then using dynamic mapping. But
the area is included in the whole SYSRAM memory mapping. This is not
allowed with dynamic mapping. As no other code is running at this step,
and we know what code is running in BL2, just remove this extra
read-only protection for STM32MP2. A message is added after the post
load process of FW-CONFIG file, as BL2 DT area will be overwritten
after that.
And remove the now useless macros DTB_BASE & DTB_LIMIT.
This corrects Coverity issue: CID 443168.

Change-Id: Ic01d6a443ecf7721380ef39dc570e2d1627008d0
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>

show more ...

Merge "fix(fdt): reserved memory: detect existing region" into integration

fix(xilinx): optimize logic to read IPI response

Optimize logic to read IPI response from firmware and avoid using
temporary buffer. Also, use pointer instead of array as per standard
format to pass

fix(xilinx): optimize logic to read IPI response

Optimize logic to read IPI response from firmware and avoid using
temporary buffer. Also, use pointer instead of array as per standard
format to pass by reference in function.

Change-Id: I45ebaeacc932a11bbfd4b7d9b9c43b4ee8ee7df2
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>

show more ...

Merge "fix(intel): update memcpy to memcpy_s" into integration

fix(fdt): reserved memory: detect existing region

When fdt_add_reserved_memory() is called to add a memory region, we
unconditionally add a node for that region. However there might be an
existing r

fix(fdt): reserved memory: detect existing region

When fdt_add_reserved_memory() is called to add a memory region, we
unconditionally add a node for that region. However there might be an
existing region node in the DT already, or there might be an overlapping
region. The Linux kernel will complain in those cases.

Cover the simple case of the region already existing in the DT, as this
is what we actually see on the Allwinner H616: The mainline DT contains
a node reserving the memory for TF-A, in case the DT changed by TF-A
itself is not given to the kernel. Our code always adds a region, making
the kernel complain - albeit without further consequences.

Covering all cases of overlapping regions would blow up the generic DT
code too much, so just add a simple check for an existing region
completely containing the to-be-added region, simply bailing out in this
case.

This prevents the kernel warning for the Allwinner H616.

This code requires a function from fdt_wrappers.c, so we have to include
that file for platforms that use the fdt_add_reserved_memory() function
(rpi4 and versal2).

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

show more ...

feat(rdv3): set CTX_INCLUDE_SVE_REGS build flag for RD-V3 variants

Commit 4242262(feat(simd):add sve state to simd ctxt struct)
introduced the CTX_INCLUDE_SVE_REGS build flag that needs to be set
if

feat(rdv3): set CTX_INCLUDE_SVE_REGS build flag for RD-V3 variants

Commit 4242262(feat(simd):add sve state to simd ctxt struct)
introduced the CTX_INCLUDE_SVE_REGS build flag that needs to be set
if SVE is enabled for more than one world, which is the case for
RD-V3. This build flag enables SVE registers to be included when
saving and restoring the CPU context.

Change-Id: Ic491939061e42e8c87a805ded99e271308f90352
Signed-off-by: Gautham Ravichandran <gautham.ravichandran@arm.com>

show more ...

Merge changes from topic "us_tc4_rebase_v2" into integration

* changes:
feat(tc): bind DPU SMMU on TC4
feat(tc): bind GPU SMMU on TC4
feat(tc): update DT for Drage GPU
feat(tc): enable SME a

Merge changes from topic "us_tc4_rebase_v2" into integration

* changes:
feat(tc): bind DPU SMMU on TC4
feat(tc): bind GPU SMMU on TC4
feat(tc): update DT for Drage GPU
feat(tc): enable SME and SME2 options for TC4
feat(tc): add new TC4 RoS definitions
feat(tc): add system generic timer register definition for TC4
feat(tc): allow TARGET_VERSION=4
feat(tc): add MHUv3 register addresses for TC4
feat(tc): add device tree binding for TC4

show more ...

feat(tc): enable SME and SME2 options for TC4

Set the Make flags for TF-A to be able to enable SME and SME2 features.
Note that we enable these architectural features for both the secure and
non-sec

feat(tc): enable SME and SME2 options for TC4

Set the Make flags for TF-A to be able to enable SME and SME2 features.
Note that we enable these architectural features for both the secure and
non-secure worlds, which is required on TC4.

In the case of the non-secure world, we specify a value of 2 for the
flag which specifies that TF-A should check the feature register to
ensure that the feature is present before enabling it. This allows these
flags to be compatible with all platforms and stops TF-A doing anything
different if it does not detect that the feature is present.

Change-Id: I51f8c7e3eb1cf06767f4b155c93269e1f129f730
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

feat(tc): add system generic timer register definition for TC4

Add new include (specific to TC4) to the TC platform file which
specifies the system generic timer base address and is used by the TF-a

feat(tc): add system generic timer register definition for TC4

Add new include (specific to TC4) to the TC platform file which
specifies the system generic timer base address and is used by the TF-a
for use as system counters.

Note that this include must come before arm_def.h. This is required
as it checks if ARM_SYS_CNTCTL macros are defined before defining
its own macros.

Change-Id: I56861e5737271b29f09c75d962533be620766b52
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

feat(tc): allow TARGET_VERSION=4

Add basic support for TARGET_VERSION=4. It extends the existing 'if'
statements in the Makefile and the header to allow them to take the
value of 4 and also specifie

feat(tc): allow TARGET_VERSION=4

Add basic support for TARGET_VERSION=4. It extends the existing 'if'
statements in the Makefile and the header to allow them to take the
value of 4 and also specifies the SCMI platform info to use for TC4.

Change-Id: I8d8257671314277a133e88ef65fae8fada93d00e
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

feat(tc): add MHUv3 register addresses for TC4

Change-Id: I06351fc048d792943f338291f8f64827339e8e1c
Signed-off-by: Leo Yan <leo.yan@arm.com>

Merge changes from topic "mb/cot-fixes" into integration

* changes:
fix(cot-dt2c): fix various breakages
fix(cot-dt2c): use processed Device Tree source file as input