To enable the support to load Hafnium as BL32, BL31 needs firmware
configuration info to get BL32 manifest load location. The load address
of BL32 is passed via firmware config info.
Add the support to get the address using fconf framework from dynamic
config info.
Signed-off-by: Nishant Sharma <nishant.sharma@arm.com>
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I3a2a5706789ed290dc7f4a67e62e03751b930c02
On RD-V3 platform and variants, Hafnium is used as SPMC running at
S-EL2 and manage SP running at S-EL0. Hafnium is loaded and configured
as BL32 image. SP is loaded by SP load framework and configured by
Hafnium.
Add the dts files needed to enable load and configuration of hafnium and
SP.
Signed-off-by: Nishant Sharma <nishant.sharma@arm.com>
Signed-off-by: Rohit Mathew <rohit.mathew@arm.com>
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I7de72052323ff9106d7bedbaaf5ece3272e9a6cd
ARM_SPMC_MANIFEST_BASE defines the base address of the SPMC manifest
used by BL32. In the non-RESET_TO_BL31 case, it is defined relative to
the top of Trusted SRAM. However, for RESET_TO_BL31, the
PLAT_ARM_SPMC_MANIFEST_BASE macro can be used to set it to a different
location which is then used to populate ARM_SPMC_MANIFEST_BASE.
As the RD-V3 platform and its variants have a different SRAM layout
compared to that defined in arm_def.h, define the
PLAT_ARM_SPMC_MANIFEST_BASE macro to an address suitable for this
platform and its variants.
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I36e1eb21ab3d1c68bddb52c62198fcdfc40d8993
In RESET_TO_BL31, the SPMC manifest base address that is utilized by
bl32_image_ep_info has to be statically defined as DT is not available.
Common arm code sets this to the top of SRAM using macros but it can be
different for some platforms. Hence, introduce the macro
PLAT_ARM_SPMC_MANIFEST_BASE that could be re-defined by platform as per
their use-case. Platforms that utilize arm_def.h would use the existing
value from arm common code.
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I4491749ad2b5794e06c9bd11ff61e2e64f21a948
Add and map the carveout for loading Hafnium as BL32 image. Also define
PLAT_ARM_SP_MAX_SIZE as 3 MB for secure partitions.
Signed-off-by: Rohit Mathew <rohit.mathew@arm.com>
Signed-off-by: Nishant Sharma <nishant.sharma@arm.com>
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I2845eb6807a127c9f6b92de2dabc9a58d25bd4d4
This patch introduces a handler for RD-V3 variants to handle Group0
secure interrupts. Currently, it is empty but serves as a placeholder
for future Group0 interrupt sources.
Signed-off-by: Nishant Sharma <nishant.sharma@arm.com>
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: Ifa418094f6075a6cdc33e63eec1825103bbf6d68
Larger stack size is needed when S-EL2 SPMC is enabled. This is required
because BL31 xlat map framework makes more nested calls when this
feature is enabled.
Signed-off-by: Nishant Sharma <nishant.sharma@arm.com>
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: Ib3f2abf38b576ba96402dab4ba995d8b648b4cc7
Affected platforms: RD-N2, RD-V1, RD-V1-MC, RD-V3 and their
configurations.
Previously, the SVE vector lengths for these platforms were
being taken from the default configuration. This commit updates
their respective platform.mk files to specify the correct vector
lengths.
Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I8919257e2cec5c0e819424ff44a623dc3ab1a368
Neoverse-V3 erratum 3701767 that applies to r0p0, r0p1, r0p2 is
still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2891958/latest/
Change-Id: I5be0de881f408a9e82a07b8459d79490e9065f94
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Neoverse-N3 erratum 3699563 that applies to r0p0 is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-3050973/latest/
Change-Id: I77aaf8ae0afff3adde9a85f4a1a13ac9d1daf0af
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Neoverse-N2 erratum 3701773 that applies to r0p0, r0p1, r0p2 and r0p3
is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1982442/latest/
Change-Id: If95bd67363228c8083724b31f630636fb27f3b61
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-X925 erratum 3701747 that applies to r0p0, r0p1 and is still
Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/109180/latest/
Change-Id: I080296666f89276b3260686c2bdb8de63fc174c1
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-X4 erratum 3701758 that applies to r0p0, r0p1, r0p2 and r0p3
is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/109148/latest/
Change-Id: I4ee941d1e7653de7a12d69f538ca05f7f9f9961d
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-X3 erratum 3701769 that applies to r0p0, r1p0, r1p1 and r1p2
is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2055130/latest/
Change-Id: Ifd722e1bb8616ada2ad158297a7ca80b19a3370b
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-X2 erratum 3701772 that applies to r0p0, r1p0, r2p0, r2p1
is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1775100/latest/
Change-Id: I2ffc5e7d7467f1bcff8b895fea52a1daa7d14495
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-A725 erratum 3699564 that applies to r0p0, r0p1 and is
fixed in r0p2.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2832921/latest
Change-Id: Ifad1f6c3f5b74060273f897eb5e4b79dd9f088f7
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-A720-AE erratum 3699562 that applies to r0p0 and is still
Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-3090091/latest/
Change-Id: Ib830470747822cac916750c01684a65cb5efc15b
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-A720 erratum 3699561 that applies to all revisions <= r0p2
and is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2439421/latest/
Change-Id: I7ea3aaf3e7bf6b4f3648f6872e505a41247b14ba
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-A715 erratum 3699560 that applies to all revisions <= r1p3
and is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-2148827/latest/
Change-Id: I183aa921b4b6f715d64eb6b70809de2566017d31
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Cortex-A710 erratum 3701772 that applies to all revisions <= r2p1
and is still Open.
The workaround is for EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1775101/latest/
Change-Id: I997c9cfaa75321f22b4f690c4d3f234c0b51c670
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
When ICH_VMCR_EL2.VBPR1 is written in Secure state (SCR_EL3.NS==0)
and then subsequently read in Non-secure state (SCR_EL3.NS==1), a
wrong value might be returned. The same issue exists in the opposite way.
Adding workaround in EL3 software that performs context save/restore
on a change of Security state to use a value of SCR_EL3.NS when
accessing ICH_VMCR_EL2 that reflects the Security state that owns the
data being saved or restored. For example, EL3 software should set
SCR_EL3.NS to 1 when saving or restoring the value ICH_VMCR_EL2 for
Non-secure(or Realm) state. EL3 software should clear
SCR_EL3.NS to 0 when saving or restoring the value ICH_VMCR_EL2 for
Secure state.
SDEN documentation:
https://developer.arm.com/documentation/SDEN-1775101/latest/
Change-Id: I9f0403601c6346276e925f02eab55908b009d957
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
- errata.h is using incorrect header macro ERRATA_REPORT_H fix this.
- Group errata function utilities.
Change-Id: I6a4a8ec6546adb41e24d8885cb445fa8be830148
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Booting mt8196 and grepping the logs for "errat" showed:
WARNING: BL31: cortex_a720: CPU workaround for erratum 2792132 was missing!
WARNING: BL31: cortex_a720: CPU workaround for erratum 2844092 was missing!
WARNING: BL31: cortex_a720: CPU workaround for erratum 2926083 was missing!
WARNING: BL31: cortex_a720: CPU workaround for erratum 2940794 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2726228 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2740089 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2763018 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2816013 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2897503 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 2923985 was missing!
WARNING: BL31: cortex_x4: CPU workaround for erratum 3076789 was missing!
Set defines so that all the errata are fixed. Now the above shows:
INFO: BL31: cortex_a720: CPU workaround for erratum 2792132 was applied
INFO: BL31: cortex_a720: CPU workaround for erratum 2844092 was applied
INFO: BL31: cortex_a720: CPU workaround for erratum 2926083 was applied
INFO: BL31: cortex_a720: CPU workaround for erratum 2940794 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2726228 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2740089 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2763018 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2816013 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2897503 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 2923985 was applied
INFO: BL31: cortex_x4: CPU workaround for erratum 3076789 was applied
Change-Id: I209784c2574b99c3c275ac60adf73896e0cdd078
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Enable the compiler's stack protector for detecting stack overflow
issues.
Though TC platform can generate RNG from RSE via MHU channel, the
stack protector canary is used prior to MHU channel initialization.
Thus, currently here simply returns a value of the combination of a
timer's value and a compile-time constant.
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Change-Id: I68fcc7782637b2b6b4dbbc81bc15df8c5ce0040b
This patch implements SMCCC_ARCH_WORKAROUND_4 and
allows discovery through SMCCC_ARCH_FEATURES.
This mechanism is enabled if CVE_2024_7881 [1] is enabled
by the platform. If CVE_2024_7881 mitigation
is implemented, the discovery call returns 0,
if not -1 (SMC_ARCH_CALL_NOT_SUPPORTED).
For more information about SMCCC_ARCH_WORKAROUND_4 [2], please
refer to the SMCCC Specification reference provided below.
[1]: https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
[2]: https://developer.arm.com/documentation/den0028/latest
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I1b1ffaa1f806f07472fd79d5525f81764d99bc79
This patch adds new cpu ops function extra4 and a new macro
for CVE-2024-7881 [1]. This new macro declare_cpu_ops_wa_4 allows
support for new CVE check function.
[1]: https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I417389f040c6ead7f96f9b720d29061833f43d37
