| 83a4dae1 | 16-Feb-2023 |
Boyan Karatotev <boyan.karatotev@arm.com> |
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 ...
|
| e57ca899 | 23-May-2023 |
Andre Przywara <andre.przywara@arm.com> |
fix(qemu): fix 32-bit builds with stack protector
When using the ENABLE_STACK_PROTECTOR=strong build option, the QEMU code will try to use the RNDR CPU instructions to initialise the stack canary. S
fix(qemu): fix 32-bit builds with stack protector
When using the ENABLE_STACK_PROTECTOR=strong build option, the QEMU code will try to use the RNDR CPU instructions to initialise the stack canary. Since the instructions are defined for AArch64 only, this will fail to build for AArch32.
And even though we now always return "false" when asked about the availability of the RNDR instruction, the compiler will still leave the reference to read_rdnr() in, if optimisations are turned off (-O0).
Avoid this by providing a dummy read_rndr() implementation, that makes the linker happy in any case.
This fixes the QEMU build for AArch32 with ENABLE_STACK_PROTECTOR=strong
Change-Id: Ibf450ba4a46167fdf3a14a527d338350ced8b5ba Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| 733d112f | 23-May-2023 |
Andre Przywara <andre.przywara@arm.com> |
feat(cpufeat): deny AArch64-only features when building for AArch32
Many newer architecture features are defined for AArch64 only, so cannot be used in an AArch32 build.
To avoid #ifdef-ing every s
feat(cpufeat): deny AArch64-only features when building for AArch32
Many newer architecture features are defined for AArch64 only, so cannot be used in an AArch32 build.
To avoid #ifdef-ing every single user, just provide trivial implementations of the feature check functions is_feat_xxx_supported(), which always return "false" in AArch32. The compiler will then optimise out the dependent code automatically.
Change-Id: I1e7d653fca0e676a11858efd953c2d623f2d5c9e Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| fc8d2d39 | 17-Nov-2022 |
Andre Przywara <andre.przywara@arm.com> |
refactor(trf): enable FEAT_TRF for FEAT_STATE_CHECKED
At the moment we only support FEAT_TRF to be either unconditionally compiled in, or to be not supported at all.
Add support for runtime detecti
refactor(trf): enable FEAT_TRF for FEAT_STATE_CHECKED
At the moment we only support FEAT_TRF to be either unconditionally compiled in, or to be not supported at all.
Add support for runtime detection (ENABLE_TRF_FOR_NS=2), by splitting is_feat_trf_present() into an ID register reading function and a second function to report the support status. That function considers both build time settings and runtime information (if needed), and is used before we access TRF related registers. Also move the context saving code from assembly to C, and use the new is_feat_trf_supported() function to guard its execution.
The FVP platform decided to compile in support unconditionally (=1), even though FEAT_TRF is an ARMv8.4 feature, so is not available with the FVP model's default command line. Change that to the now supported dynamic option (=2), so the right decision can be made by the code at runtime.
Change-Id: Ia97b01adbe24970a4d837afd463dc5506b7295a3 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|