fix(bl1): use per-world context correctlyCurrently, the configuration with BL1 and BL2 at SEL1 will transitionvia el3_exit which will restore per-world context. However, that contextis never writ
fix(bl1): use per-world context correctlyCurrently, the configuration with BL1 and BL2 at SEL1 will transitionvia el3_exit which will restore per-world context. However, that contextis never written to and so zeroes end up in registers, which is notnecessarily correct.This patch gets BL1 to call cm_manage_extensions_per_world() wheneverBL2 runs in a lower EL. This allows the per-world registers to have thereset values we intend. An accompanying call tocm_manage_extensions_el3() is also added for completeness.Doing this shows a small deficiency in cptr_el3 - bits TFP and TCPACchange a lot. This patch makes them consistent by always setting TCPACand TFP to 0 which unconditionally enable access to CPTR_EL2 and FPCR bydefault as they are always accessible. Other places that manipulate theTFP bit are removed.A nice side effect of all of this is that we're now in a position toenable and use any architectural extension in BL2.Change-Id: I070d62bbf8e9d9b472caf7e2c931c303523be308Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
fix(cpufeat): configure CPTR_EL2.ZEN and CPTR_EL2.TZ to match LinuxLinux Documentation/arch/arm64/booting.rst states that:"For CPUs with the Scalable Vector Extension (FEAT_SVE) present:... -
fix(cpufeat): configure CPTR_EL2.ZEN and CPTR_EL2.TZ to match LinuxLinux Documentation/arch/arm64/booting.rst states that:"For CPUs with the Scalable Vector Extension (FEAT_SVE) present:... - If the kernel is entered at EL1 and EL2 is present: - CPTR_EL2.TZ (bit 8) must be initialised to 0b0. - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11."Without these settings, Linux kernel hangs on boot when tryingto use SVE. Adjust the register settings to match Linux kernelexpectations.Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>Change-Id: I9a72810dd902b08f9c61f157cc31e603aad2f73a
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root contextSVE and SME aren't enabled symmetrically for all worlds, but EL3 needsto context switch them nonetheless. Previously,
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root contextSVE and SME aren't enabled symmetrically for all worlds, but EL3 needsto context switch them nonetheless. Previously, this had to happen bywriting the enable bits just before reading/writing the relevantcontext. But since the introduction of root context, this need not bethe case. We can have these enables always be present for EL3 and saveon some work (and ISBs!) on every context switch.We can also hoist ZCR_EL3 to a never changing register, as we set itsvalue to be identical for every world, which happens to be the one wewant for EL3 too.Change-Id: I3d950e72049a298008205ba32f230d5a5c02f8b0Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
refactor(cm): move EL3 registers to global contextCurrently, EL3 context registers are duplicated per-world per-cpu.Some registers have the same value across all CPUs, so this patchmoves these re
refactor(cm): move EL3 registers to global contextCurrently, EL3 context registers are duplicated per-world per-cpu.Some registers have the same value across all CPUs, so this patchmoves these registers out into a per-world context to reducememory usage.Change-Id: I91294e3d5f4af21a58c23599af2bdbd2a747c54aSigned-off-by: Elizabeth Ho <elizabeth.ho@arm.com>Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
refactor(cpufeat): separate the EL2 and EL3 enablement codeCombining the EL2 and EL3 enablement code necessitates that it must becalled at el3_exit, which is the only place with enough context to
refactor(cpufeat): separate the EL2 and EL3 enablement codeCombining the EL2 and EL3 enablement code necessitates that it must becalled at el3_exit, which is the only place with enough context to makethe decision of what needs to be set.Decouple them to allow them to be called from elsewhere.Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>Change-Id: I147764c42771e7d4100699ec8fae98dac0a505c0
feat(cpufeat): enable FEAT_SVE for FEAT_STATE_CHECKEDAdd support for runtime detection (ENABLE_SVE_FOR_NS=2), by splittingsve_supported() into an ID register reading function and asecond function
feat(cpufeat): enable FEAT_SVE for FEAT_STATE_CHECKEDAdd support for runtime detection (ENABLE_SVE_FOR_NS=2), by splittingsve_supported() into an ID register reading function and asecond function to report the support status. That function considersboth build time settings and runtime information (if needed), and isused before we do SVE specific setup.Change the FVP platform default to the now supported dynamicoption (=2), so the right decision can be made by the code at runtime.Change-Id: I1caaba2216e8e2a651452254944a003607503216Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
feat(sve): support full SVE vector lengthCurrently the SVE code hard codes a maximum vector length of 512 bitswhen configuring SVE rather than the architecture supported maximum.While this is fin
feat(sve): support full SVE vector lengthCurrently the SVE code hard codes a maximum vector length of 512 bitswhen configuring SVE rather than the architecture supported maximum.While this is fine for current physical implementations the architectureallows for vector lengths up to 2048 bits and emulated implementationsgenerally allow any length up to this maximum.Since there may be system specific reasons to limit the maximum vectorlength make the limit configurable, defaulting to the architecturemaximum. The default should be suitable for most implementations sincethe hardware will limit the actual vector length selected to what isphysically supported in the system.Signed-off-by: Mark Brown <broonie@kernel.org>Change-Id: I22c32c98a81c0cf9562411189d8a610a5b61ca12
feat(sme): enable SME functionalityThis patch adds two new compile time options to enable SME in TF-A:ENABLE_SME_FOR_NS and ENABLE_SME_FOR_SWD for use in non-secure andsecure worlds respectively.
feat(sme): enable SME functionalityThis patch adds two new compile time options to enable SME in TF-A:ENABLE_SME_FOR_NS and ENABLE_SME_FOR_SWD for use in non-secure andsecure worlds respectively. Setting ENABLE_SME_FOR_NS=1 will enableSME for non-secure worlds and trap SME, SVE, and FPU/SIMD instructionsin secure context. Setting ENABLE_SME_FOR_SWD=1 will disable thesetraps, but support for SME context management does not yet exist inSPM so building with SPD=spmd will fail.The existing ENABLE_SVE_FOR_NS and ENABLE_SVE_FOR_SWD options cannotbe used with SME as it is a superset of SVE and will enable SVE andFPU/SIMD along with SME.Signed-off-by: John Powell <john.powell@arm.com>Change-Id: Iaaac9d22fe37b4a92315207891da848a8fd0ed73
fix(el3_runtime): fix SVE and AMU extension enablement flagsIf SVE are enabled for both Non-secure and Secure world along with AMUextension, then it causes the TAM_BIT in CPTR_EL3 to be set upon e
fix(el3_runtime): fix SVE and AMU extension enablement flagsIf SVE are enabled for both Non-secure and Secure world along with AMUextension, then it causes the TAM_BIT in CPTR_EL3 to be set upon exitfrom bl31. This restricts access to the AMU register set in normalworld. This fix maintains consistency in both TAM_BIT and CPTR_EZ_BITby saving and restoring CPTR_EL3 register from EL3 context.Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>Change-Id: Id76ce1d27ee48bed65eb32392036377716aff087
feat(sve): enable SVE for the secure worldEnables SVE support for the secure world via ENABLE_SVE_FOR_SWD.ENABLE_SVE_FOR_SWD defaults to 0 and has to be explicitly set by theplatform. SVE is conf
feat(sve): enable SVE for the secure worldEnables SVE support for the secure world via ENABLE_SVE_FOR_SWD.ENABLE_SVE_FOR_SWD defaults to 0 and has to be explicitly set by theplatform. SVE is configured during initial setup and then uses EL3context save/restore routine to switch between SVE configurations fordifferent contexts.Reset value of CPTR_EL3 changed to be most restrictive by default.Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>Change-Id: I889fbbc2e435435d66779b73a2d90d1188bf4116
Sanitise includes across codebaseEnforce full include path for includes. Deprecate old paths.The following folders inside include/lib have been left unchanged:- include/lib/cpus/${ARCH}- inclu
Sanitise includes across codebaseEnforce full include path for includes. Deprecate old paths.The following folders inside include/lib have been left unchanged:- include/lib/cpus/${ARCH}- include/lib/el3_runtime/${ARCH}The reason for this change is that having a global namespace forincludes isn't a good idea. It defeats one of the advantages of havingfolders and it introduces problems that are sometimes subtle (becauseyou may not know the header you are actually including if there are twoof them).For example, this patch had to be created because two headers werecalled the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platformto avoid collision."). More recently, this patch has had similarproblems: 46f9b2c3a282 ("drivers: add tzc380 support").This problem was introduced in commit 4ecca33988b9 ("Move include andsource files to logical locations"). At that time, there weren't toomany headers so it wasn't a real issue. However, time has shown thatthis creates problems.Platforms that want to preserve the way they include headers may add theremoved paths to PLAT_INCLUDES, but this is discouraged.Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8fSigned-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Fix MISRA defects in extension libsNo functional changes.Change-Id: I2f28f20944f552447ac4e9e755493cd7c0ea1192Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
MISRA fixes for AMU/SPE and SVEChange-Id: I38470528111410cf12b187eb1397d87b812c9416Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
Implement {spe,sve}_supported() helpers and refactor codeImplement helpers to test if the core supports SPE/SVE. We have asimilar helper for AMU and this patch makes all extensions consistentin
Implement {spe,sve}_supported() helpers and refactor codeImplement helpers to test if the core supports SPE/SVE. We have asimilar helper for AMU and this patch makes all extensions consistentin their implementation.Change-Id: I3e6f7522535ca358259ad142550b19fcb883ca67Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
Enable SVE for Non-secure worldThis patch adds a new build option, ENABLE_SVE_FOR_NS, which when setto one EL3 will check to see if the Scalable Vector Extension (SVE) isimplemented when entering
Enable SVE for Non-secure worldThis patch adds a new build option, ENABLE_SVE_FOR_NS, which when setto one EL3 will check to see if the Scalable Vector Extension (SVE) isimplemented when entering and exiting the Non-secure world.If SVE is implemented, EL3 will do the following:- Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.- Exit from Non-secure world: SIMD, FP and SVE functionality is disabled. As SIMD and FP registers are part of the SVE Z-registers then any use of SIMD / FP functionality would corrupt the SVE registers.The build option default is 1. The SVE functionality is only supportedon AArch64 and so the build option is set to zero when the targetarchiecture is AArch32.This build option is not compatible with the CTX_INCLUDE_FPREGS - anassert will be raised on platforms where SVE is implemented and bothENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.Also note this change prevents secure world use of FP&SIMD registers onSVE-enabled platforms. Existing Secure-EL1 Payloads will not work onsuch platforms unless ENABLE_SVE_FOR_NS is set to 0.Additionally, on the first entry into the Non-secure world the SVEfunctionality is enabled and the SVE Z-register length is set to themaximum size allowed by the architecture. This includes the use casewhere EL2 is implemented but not used.Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7daeSigned-off-by: David Cunado <david.cunado@arm.com>