| 4779becd | 06-Aug-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C
refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 34a22a02 | 05-Aug-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor(el3-runtime): move context security states to context.h
The three security states (S, NS, RL) are architecturally quite
consistent - anything that uses them has the same numerical assignmen
refactor(el3-runtime): move context security states to context.h
The three security states (S, NS, RL) are architecturally quite
consistent - anything that uses them has the same numerical assignments
(0, 1, 2) and they are quite convenient for indexing. However, we're not
as consistent in tf-a and this is defined in a few places. Since
cpu_data has a dependency on the context management library, use its
security state convention in a few more places and take away this
responsibility from cpu_data.
Change-Id: Iec73b2be2eef91975554767557de72424d0031f1
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| af1fa796 | 29-Aug-2025 |
John Powell <john.powell@arm.com> |
fix(cpus): workaround for Cortex-A510 erratum 3672349
Cortex-A510 erratum 3672349 is a Cat B erratum that applies to
revisions r0p0, r0p1, r0p2, r0p3, r1p0, r1p1, r1p2 and r1p3, and
is still open.
fix(cpus): workaround for Cortex-A510 erratum 3672349
Cortex-A510 erratum 3672349 is a Cat B erratum that applies to
revisions r0p0, r0p1, r0p2, r0p3, r1p0, r1p1, r1p2 and r1p3, and
is still open.
The workaround is to clear the WFE_RET_CTRL and WFI_RET_CTRL fields
in CPUPWRCTLR_EL1 to disable full retention.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1873361/latest/
Change-Id: I9786ab8843a2eab45e650c6af50b6933481527ec
Signed-off-by: John Powell <john.powell@arm.com>
show more ...
|
| 4fb7090e | 29-Aug-2025 |
John Powell <john.powell@arm.com> |
fix(cpus): workaround for Cortex-A510 erratum 2420992
Cortex-A510 erratum 2420992 is a Cat B erratum that applies only to
revisions r1p0 and r1p1, and is fixed in r1p1.
The workaround is to set bit
fix(cpus): workaround for Cortex-A510 erratum 2420992
Cortex-A510 erratum 2420992 is a Cat B erratum that applies only to
revisions r1p0 and r1p1, and is fixed in r1p1.
The workaround is to set bit 3 in CPUACTLR3_EL1 which will have no
performance impact, but will increase power consumption by 0.3-0.5%.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1873361/latest/
Change-Id: Ia76ba2431d76f14c08b95a998806986190d682c3
Signed-off-by: John Powell <john.powell@arm.com>
show more ...
|
| 63900851 | 11-Sep-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor(aarch64): move BL31 specific setup out of the PSCI entrypoint
We've charged the PSCI entrypoint with doing BL31 specific things like
setting up the EL3 context and doing feature detection.
refactor(aarch64): move BL31 specific setup out of the PSCI entrypoint
We've charged the PSCI entrypoint with doing BL31 specific things like
setting up the EL3 context and doing feature detection. Well, this is
irrelevant for sp_min and not really appropriate for PSCI. So move it to
the bl31_warmboot() function to reflect this correctly and bring the
feature detection a bit earlier, hopefully spotting more errors.
This allows for a pair of minor cleanups - we can pass the core_pos to
psci_warmboot_entrypoint() without having to refetch it, and we can put
the pauth enablement in cm_manage_extensions_el3() along with all
others. The call of that function is kept after the MMU is turned on so
that we have nicer (coherent) access to cpu_data.
Change-Id: Id031cfa0e1d8fe98919a14f9db73eb5bc9e00f67
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| 759ed946 | 13-Aug-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
fix(cpus): inform the compiler that struct cpu_ops is aligned
The only way to access a cpu_ops structure is through a pointer returned
from assembly so the compiler can't know its alignment and it m
fix(cpus): inform the compiler that struct cpu_ops is aligned
The only way to access a cpu_ops structure is through a pointer returned
from assembly so the compiler can't know its alignment and it must
assume the worst. As a result, it's scared to do 64 bit loads and must
do 8 single byte loads that it then can combine together.
Well, the cpu assembly macros take care to align the cpu_ops entries to
a word boundary so we can propagate that information to the structure
definition as well and removed the compiler's paranoia.
Change-Id: Id38d6f1b92527b8a414cfbb856a5a82c76a1b1a8
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|