refactor(memmap): migrate to Poetry

This change refactors the memmap tool into a Poetry project, with its
own dependencies. You can continue to run it manually with:

poetry run memory <args>

C

refactor(memmap): migrate to Poetry

This change refactors the memmap tool into a Poetry project, with its
own dependencies. You can continue to run it manually with:

poetry run memory <args>

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

show more ...

fix(build): handle invalid spd build options

Currently the top level Makefile checks any invalid SPD build flags
before parsing platform makefile thus any invalid combination enabled
in platform mak

fix(build): handle invalid spd build options

Currently the top level Makefile checks any invalid SPD build flags
before parsing platform makefile thus any invalid combination enabled
in platform makefile will go unnoticed.

Move handling of all invalid SPD build option checks after platform level makefile is parsed.

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

show more ...

Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration

* changes:
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context
perf(psci): get PMF timestamps wi

Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration

* changes:
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context
perf(psci): get PMF timestamps with no cache flushes if possible
perf(amu): greatly simplify AMU context management
perf(mpmm): greatly simplify MPMM enablement

show more ...

perf(amu): greatly simplify AMU context management

The current code is incredibly resilient to updates to the spec and
has worked quite well so far. However, recent implementations expose a
weakness

perf(amu): greatly simplify AMU context management

The current code is incredibly resilient to updates to the spec and
has worked quite well so far. However, recent implementations expose a
weakness in that this is rather slow. A large part of it is written in
assembly, making it opaque to the compiler for optimisations. The
future proofness requires reading registers that are effectively
`volatile`, making it even harder for the compiler, as well as adding
lots of implicit barriers, making it hard for the microarchitecutre to
optimise as well.

We can make a few assumptions, checked by a few well placed asserts, and
remove a lot of this burden. For a start, at the moment there are 4
group 0 counters with static assignments. Contexting them is a trivial
affair that doesn't need a loop. Similarly, there can only be up to 16
group 1 counters. Contexting them is a bit harder, but we can do with a
single branch with a falling through switch. If/when both of these
change, we have a pair of asserts and the feature detection mechanism to
guard us against pretending that we support something we don't.

We can drop contexting of the offset registers. They are fully
accessible by EL2 and as such are its responsibility to preserve on
powerdown.

Another small thing we can do, is pass the core_pos into the hook.
The caller already knows which core we're running on, we don't need to
call this non-trivial function again.

Finally, knowing this, we don't really need the auxiliary AMUs to be
described by the device tree. Linux doesn't care at the moment, and any
information we need for EL3 can be neatly placed in a simple array.

All of this, combined with lifting the actual saving out of assembly,
reduces the instructions to save the context from 180 to 40, including a
lot fewer branches. The code is also much shorter and easier to read.

Also propagate to aarch32 so that the two don't diverge too much.

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

show more ...

perf(mpmm): greatly simplify MPMM enablement

MPMM is a core-specific microarchitectural feature. It has been present
in every Arm core since the Cortex-A510 and has been implemented in
exactly the s

perf(mpmm): greatly simplify MPMM enablement

MPMM is a core-specific microarchitectural feature. It has been present
in every Arm core since the Cortex-A510 and has been implemented in
exactly the same way. Despite that, it is enabled more like an
architectural feature with a top level enable flag. This utilised the
identical implementation.

This duality has left MPMM in an awkward place, where its enablement
should be generic, like an architectural feature, but since it is not,
it should also be core-specific if it ever changes. One choice to do
this has been through the device tree.

This has worked just fine so far, however, recent implementations expose
a weakness in that this is rather slow - the device tree has to be read,
there's a long call stack of functions with many branches, and system
registers are read. In the hot path of PSCI CPU powerdown, this has a
significant and measurable impact. Besides it being a rather large
amount of code that is difficult to understand.

Since MPMM is a microarchitectural feature, its correct placement is in
the reset function. The essence of the current enablement is to write
CPUPPMCR_EL3.MPMM_EN if CPUPPMCR_EL3.MPMMPINCTL == 0. Replacing the C
enablement with an assembly macro in each CPU's reset function achieves
the same effect with just a single close branch and a grand total of 6
instructions (versus the old 2 branches and 32 instructions).

Having done this, the device tree entry becomes redundant. Should a core
that doesn't support MPMM arise, this can cleanly be handled in the
reset function. As such, the whole ENABLE_MPMM_FCONF and platform hooks
mechanisms become obsolete and are removed.

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

show more ...

fix(build): update clang target for aarch64

With the LLVM toolchain delivered by Arm [1], the target aarch64-elf
which is defaulting to aarch64-unknown-unknown-elf is now unknown.
Replace it with aa

fix(build): update clang target for aarch64

With the LLVM toolchain delivered by Arm [1], the target aarch64-elf
which is defaulting to aarch64-unknown-unknown-elf is now unknown.
Replace it with aarch64-unknown-none-elf.

[1]: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/releases/tag/release-19.1.5

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

show more ...

Merge changes I765a7fa0,Ic33f0b6d,I8d1a88c7,I381f96be,I698fa849, ... into integration

* changes:
fix(cpus): clear CPUPWRCTLR_EL1.CORE_PWRDN_EN_BIT on reset
chore(docs): drop the "wfi" from `pwr_

Merge changes I765a7fa0,Ic33f0b6d,I8d1a88c7,I381f96be,I698fa849, ... into integration

* changes:
fix(cpus): clear CPUPWRCTLR_EL1.CORE_PWRDN_EN_BIT on reset
chore(docs): drop the "wfi" from `pwr_domain_pwr_down_wfi`
chore(psci): drop skip_wfi variable
feat(arm): convert arm platforms to expect a wakeup
fix(cpus): avoid SME related loss of context on powerdown
feat(psci): allow cores to wake up from powerdown
refactor: panic after calling psci_power_down_wfi()
refactor(cpus): undo errata mitigations
feat(cpus): add sysreg_bit_toggle

show more ...

Merge "feat(cpus): add ENABLE_ERRATA_ALL flag" into integration

feat(cpus): add ENABLE_ERRATA_ALL flag

Now that all errata flags are all conveniently in a single list we can
make sweeping decisions about their values. The first use-case is to
enable all errata i

feat(cpus): add ENABLE_ERRATA_ALL flag

Now that all errata flags are all conveniently in a single list we can
make sweeping decisions about their values. The first use-case is to
enable all errata in TF-A. This is useful for CI runs where it is
impractical to list every single one. This should help with the long
standing issue of errata not being built or tested.

Also add missing CPUs with errata to `ENABLE_ERRATA_ALL` to enable all
errata builds in CI.

Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I2b456d304d7bf3215c7c4f4fd70b56ecbcb09979

show more ...

Merge "feat(sptool): transfer list to replace SP Pkg" into integration

fix(cpus): avoid SME related loss of context on powerdown

Travis' and Gelas' TRMs tell us to disable SME (set PSTATE.{ZA, SM} to
0) when we're attempting to power down. What they don't tell us is th

fix(cpus): avoid SME related loss of context on powerdown

Travis' and Gelas' TRMs tell us to disable SME (set PSTATE.{ZA, SM} to
0) when we're attempting to power down. What they don't tell us is that
if this isn't done, the powerdown request will be rejected. On the
CPU_OFF path that's not a problem - we can force SVCR to 0 and be
certain the core will power off.

On the suspend to powerdown path, however, we cannot do this. The TRM
also tells us that the sequence could also be aborted on eg. GIC
interrupts. If this were to happen when we have overwritten SVCR to 0,
upon a return to the caller they would experience a loss of context. We
know that at least Linux may call into PSCI with SVCR != 0. One option
is to save the entire SME context which would be quite expensive just to
work around. Another option is to downgrade the request to a normal
suspend when SME was left on. This option is better as this is expected
to happen rarely enough to ignore the wasted power and we don't want to
burden the generic (correct) path with needless context management.

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

show more ...

feat(psci): allow cores to wake up from powerdown

The simplistic view of a core's powerdown sequence is that power is
atomically cut upon calling `wfi`. However, it turns out that it has
lots to do

feat(psci): allow cores to wake up from powerdown

The simplistic view of a core's powerdown sequence is that power is
atomically cut upon calling `wfi`. However, it turns out that it has
lots to do - it has to talk to the interconnect to exit coherency, clean
caches, check for RAS errors, etc. These take significant amounts of
time and are certainly not atomic. As such there is a significant window
of opportunity for external events to happen. Many of these steps are
not destructive to context, so theoretically, the core can just "give
up" half way (or roll certain actions back) and carry on running. The
point in this sequence after which roll back is not possible is called
the point of no return.

One of these actions is the checking for RAS errors. It is possible for
one to happen during this lengthy sequence, or at least remain
undiscovered until that point. If the core were to continue powerdown
when that happens, there would be no (easy) way to inform anyone about
it. Rejecting the powerdown and letting software handle the error is the
best way to implement this.

Arm cores since at least the a510 have included this exact feature. So
far it hasn't been deemed necessary to account for it in firmware due to
the low likelihood of this happening. However, events like GIC wakeup
requests are much more probable. Older cores will powerdown and
immediately power back up when this happens. Travis and Gelas include a
feature similar to the RAS case above, called powerdown abandon. The
idea is that this will improve the latency to service the interrupt by
saving on work which the core and software need to do.

So far firmware has relied on the `wfi` being the point of no return and
if it doesn't explicitly detect a pending interrupt quite early on, it
will embark onto a sequence that it expects to end with shutdown. To
accommodate for it not being a point of no return, we must undo all of
the system management we did, just like in the warm boot entrypoint.

To achieve that, the pwr_domain_pwr_down_wfi hook must not be terminal.
Most recent platforms do some platform management and finish on the
standard `wfi`, followed by a panic or an endless loop as this is
expected to not return. To make this generic, any platform that wishes
to support wakeups must instead let common code call
`psci_power_down_wfi()` right after. Besides wakeups, this lets common
code handle powerdown errata better as well.

Then, the CPU_OFF case is simple - PSCI does not allow it to return. So
the best that can be done is to attempt the `wfi` a few times (the
choice of 32 is arbitrary) in the hope that the wakeup is transient. If
it isn't, the only choice is to panic, as the system is likely to be in
a bad state, eg. interrupts weren't routed away. The same applies for
SYSTEM_OFF, SYSTEM_RESET, and SYSTEM_RESET2. There the panic won't
matter as the system is going offline one way or another. The RAS case
will be considered in a separate patch.

Now, the CPU_SUSPEND case is more involved. First, to powerdown it must
wipe its context as it is not written on warm boot. But it cannot be
overwritten in case of a wakeup. To avoid the catch 22, save a copy that
will only be used if powerdown fails. That is about 500 bytes on the
stack so it hopefully doesn't tip anyone over any limits. In future that
can be avoided by having a core manage its own context.

Second, when the core wakes up, it must undo anything it did to prepare
for poweroff, which for the cores we care about, is writing
CPUPWRCTLR_EL1.CORE_PWRDN_EN. The least intrusive for the cpu library
way of doing this is to simply call the power off hook again and have
the hook toggle the bit. If in the future there need to be more complex
sequences, their direction can be advised on the value of this bit.

Third, do the actual "resume". Most of the logic is already there for
the retention suspend, so that only needs a small touch up to apply to
the powerdown case as well. The missing bit is the powerdown specific
state management. Luckily, the warmboot entrypoint does exactly that
already too, so steal that and we're done.

All of this is hidden behind a FEAT_PABANDON flag since it has a large
memory and runtime cost that we don't want to burden non pabandon cores
with.

Finally, do some function renaming to better reflect their purpose and
make names a little bit more consistent.

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

show more ...

Merge "fix(build): do not force PLAT in plat_helpers.mk" into integration

feat(sptool): transfer list to replace SP Pkg

Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A mani

feat(sptool): transfer list to replace SP Pkg

Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A manifest, and 0x106 for
FF-A SP binary.

Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I1941e3e8f43d8dad33cdd0dea0571cf4a0d5e8f3

show more ...

fix(build): do not force PLAT in plat_helpers.mk

After the change to allow overriding platform specific defaults [1],
the PLAT macro is forced to DEFAULT_PLAT in plat_helpers.mk. But this
makefile i

fix(build): do not force PLAT in plat_helpers.mk

After the change to allow overriding platform specific defaults [1],
the PLAT macro is forced to DEFAULT_PLAT in plat_helpers.mk. But this
makefile is also called for tools. For example in fiptool makefile, as
PLAT is reset to default plat (fvp), we cannot use specific platforms
plat_fiptool.mk files. Put back the setting of PLAT macro in Makefile.

[1]: 1b2fb6adb5 feat(build): add ability to define platform specific
defaults

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

show more ...

Merge "build: remove Windows compatibility layer" into integration

Merge "feat(mops): enable FEAT_MOPS in EL3 when INIT_UNUSED_NS_EL2=1" into integration

feat(mops): enable FEAT_MOPS in EL3 when INIT_UNUSED_NS_EL2=1

FEAT_MOPS, mandatory from Arm v8.8, is typically managed in EL2.
However, in configurations where NS_EL2 is not enabled,
EL3 must set th

feat(mops): enable FEAT_MOPS in EL3 when INIT_UNUSED_NS_EL2=1

FEAT_MOPS, mandatory from Arm v8.8, is typically managed in EL2.
However, in configurations where NS_EL2 is not enabled,
EL3 must set the HCRX_EL2.MSCEn bit to 1 to enable the feature.

This patch ensures FEAT_MOPS is enabled by setting HCRX_EL2.MSCEn to 1.

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

show more ...

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulat

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.

This change removes the remainder of the OS compatibility layer
entirely, and migrates the build system over to explicitly relying on a
POSIX environment.

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

show more ...

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change own

Merge changes from topic "bk/smccc_feature" into integration

* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change owning security state when a feature is disabled

show more ...

Merge changes I1f662f82,I59a3b297 into integration

* changes:
fix(build): include platform mk earlier
fix(arm): use EL3_PAS in MAP_BL2_TOTAL definition

fix(build): include platform mk earlier

Move platform.mk inclusion in top level Makefile to permit a platform
specifying BRANCH_PROTECTION option.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.

fix(build): include platform mk earlier

Move platform.mk inclusion in top level Makefile to permit a platform
specifying BRANCH_PROTECTION option.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I1f662f82cd949eedfdbb61b9f66de15c46fb3106

show more ...

Merge "fix(rme): remove ENABLE_PIE restriction" into integration

feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY

SMCCC_ARCH_FEATURE_AVAILABILITY [1] is a call to query firmware about
the features it is aware of and enables. This is useful when a feature
is

feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY

SMCCC_ARCH_FEATURE_AVAILABILITY [1] is a call to query firmware about
the features it is aware of and enables. This is useful when a feature
is not enabled at EL3, eg due to an older FW image, but it is present in
hardware. In those cases, the EL1 ID registers do not reflect the usable
feature set and this call should provide the necessary information to
remedy that.

The call itself is very lightweight - effectively a sanitised read of
the relevant system register. Bits that are not relevant to feature
enablement are masked out and active low bits are converted to active
high.

The implementation is also very simple. All relevant, irrelevant, and
inverted bits combined into bitmasks at build time. Then at runtime the
masks are unconditionally applied to produce the right result. This
assumes that context managers will make sure that disabled features
do not have their bits set and the registers are context switched if
any fields in them make enablement ambiguous.

Features that are not yet supported in TF-A have not been added. On
debug builds, calling this function will fail an assert if any bits that
are not expected are set. In combination with CI this should allow for
this feature to to stay up to date as new architectural features are
added.

If a call for MPAM3_EL3 is made when MPAM is not enabled, the call
will return INVALID_PARAM, while if it is FEAT_STATE_CHECK, it will
return zero. This should be fairly consistent with feature detection.

The bitmask is meant to be interpreted as the logical AND of the
relevant ID registers. It would be permissible for this to return 1
while the ID returns 0. Despite this, this implementation takes steps
not to. In the general case, the two should match exactly.

Finally, it is not entirely clear whether this call replies to SMC32
requests. However, it will not, as the return values are all 64 bits.

[1]: https://developer.arm.com/documentation/den0028/galp1/?lang=en

Co-developed-by: Charlie Bareham <charlie.bareham@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I1a74e7d0b3459b1396961b8fa27f84e3f0ad6a6f

show more ...

fix(rme): remove ENABLE_PIE restriction

The combination of ENABLE_RME=1 + ENABLE_PIE=1 build options is
prevented currently for no good reason. ENABLE_PIE in a 4 worlds
configuration is mostly for b

fix(rme): remove ENABLE_PIE restriction

The combination of ENABLE_RME=1 + ENABLE_PIE=1 build options is
prevented currently for no good reason. ENABLE_PIE in a 4 worlds
configuration is mostly for building BL31 with PIE support.
BL1 / BL2 (BL2_RUNS_AT_EL3=1) remain non-PIE. BL32 (TSP) is PIE capable
but typically unused in this configuration. TRP doesn't support PIE
but is loaded in place so isn't affected by this option.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Ia60e295534a92cb1b4e3eb88b3e240aea4f4fe1d

show more ...