| 745c129a | 09-Jul-2024 |
Andre Przywara <andre.przywara@arm.com> |
feat(rmmd): add RMM_RESERVE_MEMORY SMC handler
At the moment any memory required by an R-EL2 manager (RMM) needs to
be known at compile time: that sets the size of the .data and .bss
segments. Some
feat(rmmd): add RMM_RESERVE_MEMORY SMC handler
At the moment any memory required by an R-EL2 manager (RMM) needs to
be known at compile time: that sets the size of the .data and .bss
segments. Some resources depend on the particular machine this will be
running on, the prime example is TF-RMM's granule array, which needs to
know the maximum memory supported beforehand. Other data structures
might depend on the number of CPU cores.
To provide more flexibility, but keep the memory footprint as small as
possible, let's introduce some memory reservation SMC. Any RMM
implementation can ask EL3 for some memory, and would get the physical
address of a usable chunk of memory back. This must happen at RMM boot
time, so before the RMM concluded the boot phase with the
RMM_BOOT_COMPLETE SMC call. Also there is no provision to free memory
again, this would not be needed for the use case of sizing platform
resources, and avoids the complexity of a full-fledged memory allocator.
Add the new RMM_RESERVE_MEMORY command to the implementation defined
RMM-EL3 SMC interface, both in code and documentation. The actual memory
reservation is made a platform implementation, but a simple
implementation is provided, which is used for the FVP platform already:
it will just pick the next matching chunk of memory from the top end of
the RMM carveout. This way the memory reservation will grow down from
the end of the carveout, in a stack-like fashion, until it reaches the
end of the RMM payload, located at the beginning of the carveout. Since
secondary cores might also reserve memory at boot time, there is a
spinlock to protect the simple allocation algorithm.
Other platforms can choose to provide a more sophisticated reservation
algorithm, for instance one taking NUMA locality into account.
This patch just provides the call, at this point there is no obligation
to use the feature, although future TF-RMM versions would rely on it.
Change-Id: I096ac8870ee38f44e18850779fcae829a43a8fd1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| 89d979ce | 12-Jun-2025 |
Andre Przywara <andre.przywara@arm.com> |
feat(rmmd): add per-CPU activation token
To accommodate Live Firmware Activation (LFA), the RMM needs to preserve
some state, between an old and the new copy of itself.
The state which needs to be p
feat(rmmd): add per-CPU activation token
To accommodate Live Firmware Activation (LFA), the RMM needs to preserve
some state, between an old and the new copy of itself.
The state which needs to be preserved and its organisation would be
completely under control of the RMM; it will be different between
different RMM implementations and even between releases.
To keep the interface small, generic and robust, introduce an
"activation token", which is an opaque 64-bit value to gets passed to
each RMM as part of the boot/init phase. On the first initialisation,
after a cold boot, this value would be initialised to 0. The RMM is
expected to pass the actual value (for instance a pointer to a
persistent data structure) back to BL31 as an additional argument of the
RMM_BOOT_COMPLETE SMC call. On subsequent live activations, this updated
token value gets passed to the (updated) RMM init routines, using the
respective CPU registers.
Add an activation_token member to the (per-CPU) RMM context, and update
its value with the value passed via the x2 register, at the
RMM_BOOT_COMPLETE SMC call. Then pass that value into RMM either via x4
(on the primary core) or via x1 (on secondary cores). How the value is
used or updated on the RMM side is of no further concern to BL31, it
just passes the opaque value around.
The TRP seems to be very jealous about the values in the first three
registers, so let it ignore the value of x1 on a warmboot, to avoid a
panic.
Change-Id: Ie8d96a046b74adb00e2ca5ce3b8458465bacf2b2
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| 30bbc4fa | 14-Aug-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(drtm): remove plat_system_reset()
The name plat_system_reset() has been in use for some time by a mediatek
platform (in plat/mediatek/mt8173/plat_pm.c). However, DRTM added a
global hook, that i
fix(drtm): remove plat_system_reset()
The name plat_system_reset() has been in use for some time by a mediatek
platform (in plat/mediatek/mt8173/plat_pm.c). However, DRTM added a
global hook, that is only implemented on FVP, that conflicts with it.
This sometimes results in failed builds.
DRTM remediation ends with a platform reset. However, there is currently
an error message printed that this is not supported. In this case, the
correct thing to do is to panic and as such this hook is not needed.
Further, the correct sequence to reset the system is different and is
only fully implemented by psci_system_reset(). This is a portable
implementation supported by a wide variety of platform.
So remove plat_system_reset(). Once DRTM remediation properly supports
resetting, the psci_system_reset() function should be used to achieve
reset correctly and portably.
Change-Id: Ia4e150c51aeec613838464fbb0e1d0542f19ccab
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 9232d3f2 | 24-Jul-2025 |
Xialin Liu <xialin.liu@arm.com> |
feat(drtm): remove todo that is implemented
The PE state is set in compliance with the PSCI specification.
The general purpose registers are reset, the PC is set to the
entry point, the SPSR registe
feat(drtm): remove todo that is implemented
The PE state is set in compliance with the PSCI specification.
The general purpose registers are reset, the PC is set to the
entry point, the SPSR register is set. The todo can be removed
as the PE state is set appropriately.
Change-Id: Ib41bbf119e6175a11b37f07fe3df9e81fe10b5f6
Signed-off-by: Xialin Liu <xialin.liu@arm.com>
show more ...
|
| f2db4ebc | 13-Aug-2025 |
Jamie Fox <jamiefox@google.com> |
fix(trng): avoid undefined behaviour in pack_entropy
When nbits is a multiple of the word size, the pack_entropy function
right shifts the mask by the type width, which is undefined. In
practice, th
fix(trng): avoid undefined behaviour in pack_entropy
When nbits is a multiple of the word size, the pack_entropy function
right shifts the mask by the type width, which is undefined. In
practice, the 64-bit shift compiles to a no-op and the implementation
depends on this behaviour, so this patch changes the function to skip
the masking if nbits is multiple of the word size.
Change-Id: I478b8102aae0a1d49182e7a8a55f70fd9438b9f9
Signed-off-by: Jamie Fox <jamiefox@google.com>
show more ...
|
| 4e5247c1 | 08-Apr-2025 |
Yeoreum Yun <yeoreum.yun@arm.com> |
feat(el3-spmc): deliver TPM event log via hob list
Add MM_TPM_EVENT_LOG hob type and deliver tpm meaured event logs
passed via secure transfer list to secure partition with hob list in
SPMC_AT_EL3.
feat(el3-spmc): deliver TPM event log via hob list
Add MM_TPM_EVENT_LOG hob type and deliver tpm meaured event logs
passed via secure transfer list to secure partition with hob list in
SPMC_AT_EL3.
So that secure partition could get the meausred event log by TF-A.
Change-Id: I14f7f8cb8f8f54e07a13f40748ca551bcd265a51
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
show more ...
|
| cb4ee3e4 | 11-Jul-2025 |
Arvind Ram Prakash <arvind.ramprakash@arm.com> |
feat(smccc): add SoC name support to SMCCC_ARCH_SOC_ID
This patch adds support for getting the SoC name string
using the SMCCC_ARCH_SOC_ID interface. The SoC name query
was introduced in SMCCC versi
feat(smccc): add SoC name support to SMCCC_ARCH_SOC_ID
This patch adds support for getting the SoC name string
using the SMCCC_ARCH_SOC_ID interface. The SoC name query
was introduced in SMCCC version 1.6. It is available only
through SMC64 calls.
A new function ID, SMCCC_GET_SOC_NAME, is added. It returns
the SoC name as a null-terminated ASCII string, spread across
registers X1 to X17 in little endian order.
The total length is 136 bytes, including the null byte.
Any space after the null terminator is filled
with zeros.
A platform hook plat_get_soc_name() is added to return the
SoC name. A weak default version is also provided that returns
SMC_ARCH_CALL_NOT_SUPPORTED for platforms that do not support
this feature.
The name should follow the SMCCC rule that it must not expose
any information that is not already reported
by the SoC version and revision calls.
Reference: https://developer.arm.com/documentation/den0028/latest/
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: Idc69997c509bcbfb1cecb38ed1003b29627ade4b
show more ...
|