feat(rmmd): enable SME for RMM

This patch enables Scalable Matrix Extension (SME) for RMM. RMM will
save/restore required registers that are shared with SVE/FPU register
state so that Realm can use

feat(rmmd): enable SME for RMM

This patch enables Scalable Matrix Extension (SME) for RMM. RMM will
save/restore required registers that are shared with SVE/FPU register
state so that Realm can use FPU or SVE.

The Relevant RMM support can be found here :
https://github.com/TF-RMM/tf-rmm/commit/0ccd7ae58b00

Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Change-Id: I3bbdb840e7736dec00b71c85fcec3d5719413ffd

show more ...

Merge changes from topic "rm/handoff" into integration

* changes:
feat(qemu): implement firmware handoff on qemu
feat(handoff): introduce firmware handoff library

feat(handoff): introduce firmware handoff library

Add transfer list APIs and firmware handoff build option.

Change-Id: I68a0ace22c7e50fcdacd101eb76b271d7b76d8ff
Signed-off-by: Raymond Mao <raymond.

feat(handoff): introduce firmware handoff library

Add transfer list APIs and firmware handoff build option.

Change-Id: I68a0ace22c7e50fcdacd101eb76b271d7b76d8ff
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

show more ...

Merge "refactor(cpufeat): refactor arch feature build options" into integration

refactor(cpufeat): refactor arch feature build options

Current build infra defaults all cpufeats in defaults.mk and some
mandatory features are enabled in arch_features.mk and optional
arch features

refactor(cpufeat): refactor arch feature build options

Current build infra defaults all cpufeats in defaults.mk and some
mandatory features are enabled in arch_features.mk and optional
arch features are enabled in platform specific makefile.
This fragmentation is sometime confusing to figure out which feature
is tied to which ARCH_MAJOR.ARCH_MINOR.

So, consolidating and grouping them for tracking and enabling makes
more sense. With this change we consolidate all ARCH feature handling
within arch_features.mk and disable all optional features that need
to be enabled to platform makefile.

This is an ongoing series of effort to consolidate and going forward
platform makefile should just specify ARCH_MAJOR and ARCH MINOR and
all mandatory feature should be selected based on arch_features.mk
any optional feature needed by the platform support can be enabled
by platform makefile.

It also makes it easier for platform ports to look upto arch_features.mk
and enable any optional feature that platform may need which are
supported from TF-A.

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

show more ...

Merge "build(bl32): added check for AARCH32_SP" into integration

build(bl32): added check for AARCH32_SP

If AACRH32_SP is not specified, it causes the DEFAULT_LINKER_SCRIPT
variable to be empty, and then the linker takes the variable following
it as if it was the

build(bl32): added check for AARCH32_SP

If AACRH32_SP is not specified, it causes the DEFAULT_LINKER_SCRIPT
variable to be empty, and then the linker takes the variable following
it as if it was the linker script, which is not one. This patch
addresses that issue by requiring the AARCH32_SP variable to be set
before continuing.

Change-Id: I21db7d5bd86b98faaa1a1cd3f985daa592556a2d
Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com>

show more ...

Merge changes from topic "el3_direct_msg" into integration

* changes:
docs(spm): document new build option
feat(fvp): spmd logical partition smc handler
feat(fvp): add spmd logical partition

Merge changes from topic "el3_direct_msg" into integration

* changes:
docs(spm): document new build option
feat(fvp): spmd logical partition smc handler
feat(fvp): add spmd logical partition
feat(spmd): get logical partitions info
feat(spmd): add partition info get regs
refactor(ff-a): move structure definitions
feat(spmd): el3 direct message API
feat(spmd): add spmd logical partitions

show more ...

Merge "feat(sptool): generate `ARM_BL2_SP_LIST_DTS` file from `sp_layout.json`" into integration

feat(sptool): generate `ARM_BL2_SP_LIST_DTS` file from `sp_layout.json`

TF-A makefile accepts a device-tree snippet to override hardcoded SP
nodes, via the `ARM_BL2_SP_LIST_DTS` variable. However th

feat(sptool): generate `ARM_BL2_SP_LIST_DTS` file from `sp_layout.json`

TF-A makefile accepts a device-tree snippet to override hardcoded SP
nodes, via the `ARM_BL2_SP_LIST_DTS` variable. However the SPs declared
in `ARM_BL2_SP_LIST_DTS` must be in the same order as they are in the
FIP image, otherwise hash authentication will fail when loaded by BL2.

This patch generates the `ARM_BL2_SP_LIST_DTS` file from the
`sp_layout.json` file. The SPs in the FIP image are also generated from
`sp_layout.json`, so this ensures that there is only one source of truth
for the SP list, removing the possibility to have the lists disagree
with each other.

Signed-off-by: Karl Meakin <karl.meakin@arm.com>
Change-Id: I7d76715135c596605c6a02aad5196d967dfeb1ce

show more ...

feat(spmd): add spmd logical partitions

Add header file to help with creation of SPMD logical partitions. Also
update linker files to create sections to record SPMD logical partitions
declared. This

feat(spmd): add spmd logical partitions

Add header file to help with creation of SPMD logical partitions. Also
update linker files to create sections to record SPMD logical partitions
declared. This follows the same pattern as the EL3 SPMC's logical
partitions. This patch also adds initialization of SPMD logical
partitions when the SPMD comes up.
ENABLE_SPMD_LP is a build flag that is used to enable support for
SPMD logical partitions.
Note that the approach chosen is to keep SPMD and SPMC logical
partition support separate, as opposed to extend the existing SPMC
logical partition support since the code would need to have a number of
ifdefs and the interactions with various build options such as
SPMC_AT_EL3 needs to be accounted for, which would make code more
complicated.

Signed-off-by: Raghu Krishnamurthy <raghu.ncstate@gmail.com>
Change-Id: I9642ddbf6ea26dd3f4a283baec598d61c07e3661

show more ...

Merge "feat(mte): adds feature detection for MTE_PERM" into integration

feat(mte): adds feature detection for MTE_PERM

Adds feature detection for v8.9 feature FEAT_MTE_PERM. Adds respective
ID_AA64PFR2_EL1 definitions and ENABLE_FEAT_MTE_PERM define.

Change-Id: If24b42

feat(mte): adds feature detection for MTE_PERM

Adds feature detection for v8.9 feature FEAT_MTE_PERM. Adds respective
ID_AA64PFR2_EL1 definitions and ENABLE_FEAT_MTE_PERM define.

Change-Id: If24b42f1207154e639016b0b840b2d91c6ee13d4
Signed-off-by: Maksims Svecovs <maksims.svecovs@arm.com>
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

Merge "feat(build): march option selection" into integration

feat(build): march option selection

Current build infra uses ARM_ARCH_MAJOR/MINOR to come up with march
version and uses that march version with the compiler.

However in certain situations this is

feat(build): march option selection

Current build infra uses ARM_ARCH_MAJOR/MINOR to come up with march
version and uses that march version with the compiler.

However in certain situations this is not ideal, like for example when
we build with gcc-11 which supports only till march=armv8.5 but
we need to build for 8.8 build, this means we need to bump down
MAJOR/MINOR and we can't rely on major and minor values from the
platform to select march value and build infra doesn't even try
to compile and fails with not supported MAJOR/MINOR.

By adding a march build helper we try to check if compiler supports
given march value from MAJOR/MINOR values from platform, if compiler
doesn't support then we try to check what's the max or best supported
march version by compiler and choose that march value and try to
compile with that.

This is a supportive mechanism which will decouple march reliance on
MAJOR/MINOR values from platform and will pave way for setting up
enabling of features based on MAJOR/MINOR without worrying about the
compiler not supporting given MAJOR/MINOR.

Also in TF-A we use generic instructions without much reliance or need
for exact march necessity. So enabling and building features from
armv-8.8 using an armv-8.5 march value is still going to be fine.

Please note: Platforms are free to freeze their march values using
`MARCH_DIRECTIVE`. In absence of this define we are going to poke
the compiler and come up with a potential march value.

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

show more ...

Merge changes from topic "bk/context_refactor" into integration

* changes:
refactor(pmu): convert FEAT_MTPMU to C and move to persistent register init
feat(pmu): introduce pmuv3 lib/extensions f

Merge changes from topic "bk/context_refactor" into integration

* changes:
refactor(pmu): convert FEAT_MTPMU to C and move to persistent register init
feat(pmu): introduce pmuv3 lib/extensions folder
fix(pmu): make MDCR_EL3.MTPME=1 out of reset
refactor(cm): introduce a real manage_extensions_nonsecure()

show more ...

refactor(pmu): convert FEAT_MTPMU to C and move to persistent register init

The FEAT_MTPMU feature disable runs very early after reset. This means,
it needs to be written in assembly, since the C ru

refactor(pmu): convert FEAT_MTPMU to C and move to persistent register init

The FEAT_MTPMU feature disable runs very early after reset. This means,
it needs to be written in assembly, since the C runtime has not been
initialised yet.

However, there is no need for it to be initialised so soon. The PMU
state is only relevant after TF-A has relinquished control. The code
to do this is also very verbose and difficult to read. Delaying the
initialisation allows for it to happen with the rest of the PMU. Align
with FEAT_STATE in the process.

BREAKING CHANGE: This patch explicitly breaks the EL2 entry path. It is
currently unsupported.

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

show more ...

feat(pmu): introduce pmuv3 lib/extensions folder

The enablement code for the PMU is scattered and difficult to track
down. Factor out the feature into its own lib/extensions folder and
consolidate t

feat(pmu): introduce pmuv3 lib/extensions folder

The enablement code for the PMU is scattered and difficult to track
down. Factor out the feature into its own lib/extensions folder and
consolidate the implementation. Treat it is as an architecturally
mandatory feature as it is currently.

Additionally, do some cleanup on AArch64. Setting overflow bits in
PMCR_EL0 is irrelevant for firmware so don't do it. Then delay the PMU
initialisation until the context management stage which simplifies the
early environment assembly. One side effect is that the PMU might count
before this happens so reset all counters to 0 to prevent any leakage.

Finally, add an enable to manage_extensions_realm() as realm world uses
the pmu. This introduces the HPMN fixup to realm world.

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

show more ...

Merge "refactor(build): merge march32/64 directives" into integration

refactor(build): merge march32/64 directives

Both march32-directive and march64-directive eventually generate the
same march option that will passed to compiler.

Merge this two separate directives

refactor(build): merge march32/64 directives

Both march32-directive and march64-directive eventually generate the
same march option that will passed to compiler.

Merge this two separate directives to a common one as march-directive.

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

show more ...

Merge changes from topic "jc/refact_Makefile" into integration

* changes:
refactor(build): move SVE_VECTOR_LEN flag to add_defines section
refactor(build): cleanup Makefile to handle build flags

Merge changes from topic "jc/refact_Makefile" into integration

* changes:
refactor(build): move SVE_VECTOR_LEN flag to add_defines section
refactor(build): cleanup Makefile to handle build flags precisely

show more ...

refactor(build): move SVE_VECTOR_LEN flag to add_defines section

Presently, we have an explicit section to add definitions, wherein
we evaluate the definitions after being overwritten by the platfor

refactor(build): move SVE_VECTOR_LEN flag to add_defines section

Presently, we have an explicit section to add definitions, wherein
we evaluate the definitions after being overwritten by the platform.

To keep it aligned with this pattern, SVE_VECTOR_LEN is moved here.

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

show more ...

refactor(build): cleanup Makefile to handle build flags precisely

Presently, Makefile is unsystematic with no precise ordering
of configuration and commands.
This patch addresses this issue, by sort

refactor(build): cleanup Makefile to handle build flags precisely

Presently, Makefile is unsystematic with no precise ordering
of configuration and commands.
This patch addresses this issue, by sorting and arranging the related
sections in an order, which helps in maintaining it precisely.
Further, this assists developers in identifying the concerned section
and add related changes appropriately with ease.

Additionally, SIMICS build option linked to Intel platform, has been
removed, as there is no platform specific support to utilise it.
[https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16737]

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

show more ...

Merge changes from topic "bk/clearups" into integration

* changes:
chore(rme): add make rule for SPD=spmd
chore(bl1): remove redundant bl1_arch_next_el_setup
chore(docs): remove control regist

Merge changes from topic "bk/clearups" into integration

* changes:
chore(rme): add make rule for SPD=spmd
chore(bl1): remove redundant bl1_arch_next_el_setup
chore(docs): remove control register setup section
chore(pauth): remove redundant pauth_disable_el3() call

show more ...

Merge changes from topic "hm/memmap-feat" into integration

* changes:
build(bl32): add symbols for memory layout
build(bl31): add symbols for memory layout
build(bl2): add symbols for memory l

Merge changes from topic "hm/memmap-feat" into integration

* changes:
build(bl32): add symbols for memory layout
build(bl31): add symbols for memory layout
build(bl2): add symbols for memory layout
build(bl1): add symbols for memory layout
refactor: improve readability of symbol table

show more ...