andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/include/arch/aarch64/el3_common_macros.S

438 lines
16 KiB
ArmAsm
Raw Normal View History

Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
/*
Disable processor Cycle Counting in Secure state In a system with ARMv8.5-PMU implemented: - If EL3 is using AArch32, setting MDCR_EL3.SCCD to 1 disables counting in Secure state in PMCCNTR. - If EL3 is using AArch64, setting SDCR.SCCD to 1 disables counting in Secure state in PMCCNTR_EL0. So far this effect has been achieved by setting PMCR_EL0.DP (in AArch64) or PMCR.DP (in AArch32) to 1 instead, but this isn't considered secure as any EL can change that value. Change-Id: I82cbb3e48f2e5a55c44d9c4445683c5881ef1f6f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-02-18 16:55:43 +00:00
* Copyright (c) 2015-2019, ARM Limited and Contributors. All rights reserved.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
*
Use SPDX license identifiers To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-05-03 09:38:09 +01:00
* SPDX-License-Identifier: BSD-3-Clause
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
*/
Standardise header guards across codebase All identifiers, regardless of use, that start with two underscores are reserved. This means they can't be used in header guards. The style that this project is now to use the full name of the file in capital letters followed by 'H'. For example, for a file called "uart_example.h", the header guard is UART_EXAMPLE_H. The exceptions are files that are imported from other projects: - CryptoCell driver - dt-bindings folders - zlib headers Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-11-08 10:20:19 +00:00
#ifndef EL3_COMMON_MACROS_S
#define EL3_COMMON_MACROS_S
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
#include <arch.h>
#include <asm_macros.S>
/*
* Helper macro to initialise EL3 registers we care about.
*/
Workaround for CVE-2017-5715 on Cortex A57 and A72 Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling and enabling the MMU. To achieve this without performing any branch instruction, a per-cpu vbar is installed which executes the workaround and then branches off to the corresponding vector entry in the main vector table. A side effect of this change is that the main vbar is configured before any reset handling. This is to allow the per-cpu reset function to override the vbar setting. This workaround is enabled by default on the affected CPUs. Change-Id: I97788d38463a5840a410e3cea85ed297a1678265 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-11-30 14:53:53 +00:00
.macro el3_arch_init_common
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
/* ---------------------------------------------------------------------
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* SCTLR_EL3 has already been initialised - read current value before
* modifying.
*
* SCTLR_EL3.I: Enable the instruction cache.
*
Correct some typo errors in comment File: include/common/aarch64/el3_common_macros.S Change-Id: I619401e961a3f627ad8864781b5f90bc747c3ddb Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
2018-03-05 01:31:11 +00:00
* SCTLR_EL3.SA: Enable Stack Alignment check. A SP alignment fault
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* exception is generated if a load or store instruction executed at
* EL3 uses the SP as the base address and the SP is not aligned to a
* 16-byte boundary.
*
* SCTLR_EL3.A: Enable Alignment fault checking. All instructions that
* load or store one or more registers have an alignment check that the
* address being accessed is aligned to the size of the data element(s)
* being accessed.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* ---------------------------------------------------------------------
*/
mov x1, #(SCTLR_I_BIT | SCTLR_A_BIT | SCTLR_SA_BIT)
mrs x0, sctlr_el3
orr x0, x0, x1
msr sctlr_el3, x0
isb
Use #ifdef for IMAGE_BL* instead of #if One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-25 14:36:24 +00:00
#ifdef IMAGE_BL31
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
/* ---------------------------------------------------------------------
* Initialise the per-cpu cache pointer to the CPU.
* This is done early to enable crash reporting to have access to crash
* stack. Since crash reporting depends on cpu_data to report the
* unhandled exception, not doing so can lead to recursive exceptions
* due to a NULL TPIDR_EL3.
* ---------------------------------------------------------------------
*/
bl init_cpu_data_ptr
#endif /* IMAGE_BL31 */
/* ---------------------------------------------------------------------
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* Initialise SCR_EL3, setting all fields rather than relying on hw.
* All fields are architecturally UNKNOWN on reset. The following fields
* do not change during the TF lifetime. The remaining fields are set to
* zero here but are updated ahead of transitioning to a lower EL in the
* function cm_init_context_common().
*
* SCR_EL3.TWE: Set to zero so that execution of WFE instructions at
* EL2, EL1 and EL0 are not trapped to EL3.
*
* SCR_EL3.TWI: Set to zero so that execution of WFI instructions at
* EL2, EL1 and EL0 are not trapped to EL3.
*
* SCR_EL3.SIF: Set to one to disable instruction fetches from
* Non-secure memory.
*
* SCR_EL3.SMD: Set to zero to enable SMC calls at EL1 and above, from
* both Security states and both Execution states.
*
* SCR_EL3.EA: Set to one to route External Aborts and SError Interrupts
* to EL3 when executing at any EL.
AArch64: Enable lower ELs to use pointer authentication Pointer authentication is an Armv8.3 feature that introduces instructions that can be used to authenticate and verify pointers. Pointer authentication instructions are allowed to be accessed from all ELs but only when EL3 explicitly allows for it; otherwise, their usage will trap to EL3. Since EL3 doesn't have trap handling in place, this patch unconditionally disables all related traps to EL3 to avoid potential misconfiguration leading to an unhandled EL3 exception. Fixes ARM-software/tf-issues#629 Change-Id: I9bd2efe0dc714196f503713b721ffbf05672c14d Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-08-15 14:29:29 +01:00
*
* SCR_EL3.{API,APK}: For Armv8.3 pointer authentication feature,
* disable traps to EL3 when accessing key registers or using pointer
* authentication instructions from lower ELs.
Enable asynchronous abort exceptions during boot Asynchronous abort exceptions generated by the platform during cold boot are not taken in EL3 unless SCR_EL3.EA is set. Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture initialisation. Further write accesses to SCR_EL3 preserve these bits during cold boot. A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions being trapped by EL3 after cold boot or not. For further reference SError Interrupts are also known as asynchronous external aborts. On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in EL3 whatever the SCR_EL3.EA value is. Fixes arm-software/tf-issues#368 Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
2016-03-22 08:29:23 +00:00
* ---------------------------------------------------------------------
*/
Add ARMv8.3-PAuth registers to CPU context ARMv8.3-PAuth adds functionality that supports address authentication of the contents of a register before that register is used as the target of an indirect branch, or as a load. This feature is supported only in AArch64 state. This feature is mandatory in ARMv8.3 implementations. This feature adds several registers to EL1. A new option called CTX_INCLUDE_PAUTH_REGS has been added to select if the TF needs to save them during Non-secure <-> Secure world switches. This option must be enabled if the hardware has the registers or the values will be leaked during world switches. To prevent leaks, this patch also disables pointer authentication in the Secure world if CTX_INCLUDE_PAUTH_REGS is 0. Any attempt to use it will be trapped in EL3. Change-Id: I27beba9907b9a86c6df1d0c5bf6180c972830855 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-31 11:58:00 +00:00
mov_imm x0, ((SCR_RESET_VAL | SCR_EA_BIT | SCR_SIF_BIT) \
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
& ~(SCR_TWE_BIT | SCR_TWI_BIT | SCR_SMD_BIT))
Add ARMv8.3-PAuth registers to CPU context ARMv8.3-PAuth adds functionality that supports address authentication of the contents of a register before that register is used as the target of an indirect branch, or as a load. This feature is supported only in AArch64 state. This feature is mandatory in ARMv8.3 implementations. This feature adds several registers to EL1. A new option called CTX_INCLUDE_PAUTH_REGS has been added to select if the TF needs to save them during Non-secure <-> Secure world switches. This option must be enabled if the hardware has the registers or the values will be leaked during world switches. To prevent leaks, this patch also disables pointer authentication in the Secure world if CTX_INCLUDE_PAUTH_REGS is 0. Any attempt to use it will be trapped in EL3. Change-Id: I27beba9907b9a86c6df1d0c5bf6180c972830855 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-31 11:58:00 +00:00
#if CTX_INCLUDE_PAUTH_REGS
/*
* If the pointer authentication registers are saved during world
* switches, enable pointer authentication everywhere, as it is safe to
* do so.
*/
orr x0, x0, #(SCR_API_BIT | SCR_APK_BIT)
#endif
Enable asynchronous abort exceptions during boot Asynchronous abort exceptions generated by the platform during cold boot are not taken in EL3 unless SCR_EL3.EA is set. Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture initialisation. Further write accesses to SCR_EL3 preserve these bits during cold boot. A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions being trapped by EL3 after cold boot or not. For further reference SError Interrupts are also known as asynchronous external aborts. On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in EL3 whatever the SCR_EL3.EA value is. Fixes arm-software/tf-issues#368 Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
2016-03-22 08:29:23 +00:00
msr scr_el3, x0
Reset debug registers MDCR-EL3/SDCR and MDCR_EL2/HDCR In order to avoid unexpected traps into EL3/MON mode, this patch resets the debug registers, MDCR_EL3 and MDCR_EL2 for AArch64, and SDCR and HDCR for AArch32. MDCR_EL3/SDCR is zero'ed when EL3/MON mode is entered, at the start of BL1 and BL31/SMP_MIN. For MDCR_EL2/HDCR, this patch zero's the bits that are architecturally UNKNOWN values on reset. This is done when exiting from EL3/MON mode but only on platforms that support EL2/HYP mode but choose to exit to EL1/SVC mode. Fixes ARM-software/tf-issues#430 Change-Id: Idb992232163c072faa08892251b5626ae4c3a5b6 Signed-off-by: David Cunado <david.cunado@arm.com>
2016-10-31 17:37:34 +00:00
/* ---------------------------------------------------------------------
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* Initialise MDCR_EL3, setting all fields rather than relying on hw.
* Some fields are architecturally UNKNOWN on reset.
*
* MDCR_EL3.SDD: Set to one to disable AArch64 Secure self-hosted debug.
* Debug exceptions, other than Breakpoint Instruction exceptions, are
* disabled from all ELs in Secure state.
*
* MDCR_EL3.SPD32: Set to 0b10 to disable AArch32 Secure self-hosted
* privileged debug from S-EL1.
*
* MDCR_EL3.TDOSA: Set to zero so that EL2 and EL2 System register
* access to the powerdown debug registers do not trap to EL3.
*
* MDCR_EL3.TDA: Set to zero to allow EL0, EL1 and EL2 access to the
* debug registers, other than those registers that are controlled by
* MDCR_EL3.TDOSA.
*
* MDCR_EL3.TPM: Set to zero so that EL0, EL1, and EL2 System register
* accesses to all Performance Monitors registers do not trap to EL3.
Disable processor Cycle Counting in Secure state In a system with ARMv8.5-PMU implemented: - If EL3 is using AArch32, setting MDCR_EL3.SCCD to 1 disables counting in Secure state in PMCCNTR. - If EL3 is using AArch64, setting SDCR.SCCD to 1 disables counting in Secure state in PMCCNTR_EL0. So far this effect has been achieved by setting PMCR_EL0.DP (in AArch64) or PMCR.DP (in AArch32) to 1 instead, but this isn't considered secure as any EL can change that value. Change-Id: I82cbb3e48f2e5a55c44d9c4445683c5881ef1f6f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-02-18 16:55:43 +00:00
*
* MDCR_EL3.SCCD: Set to one so that cycle counting by PMCCNTR_EL0 is
* prohibited in Secure state. This bit is RES0 in versions of the
* architecture earlier than ARMv8.5, setting it to 1 doesn't have any
* effect on them.
Explicitly disable the SPME bit in MDCR_EL3 Currently the MDCR_EL3 initialisation implicitly disables MDCR_EL3.SPME by using mov_imm. This patch makes the SPME bit more visible by explicitly disabling it and documenting its use in different versions of the architecture. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: I221fdf314f01622f46ac5aa43388f59fa17a29b3
2019-10-03 17:09:08 +01:00
*
* MDCR_EL3.SPME: Set to zero so that event counting by the programmable
* counters PMEVCNTR<n>_EL0 is prohibited in Secure state. If ARMv8.2
* Debug is not implemented this bit does not have any effect on the
* counters unless there is support for the implementation defined
* authentication interface ExternalSecureNoninvasiveDebugEnabled().
Reset debug registers MDCR-EL3/SDCR and MDCR_EL2/HDCR In order to avoid unexpected traps into EL3/MON mode, this patch resets the debug registers, MDCR_EL3 and MDCR_EL2 for AArch64, and SDCR and HDCR for AArch32. MDCR_EL3/SDCR is zero'ed when EL3/MON mode is entered, at the start of BL1 and BL31/SMP_MIN. For MDCR_EL2/HDCR, this patch zero's the bits that are architecturally UNKNOWN values on reset. This is done when exiting from EL3/MON mode but only on platforms that support EL2/HYP mode but choose to exit to EL1/SVC mode. Fixes ARM-software/tf-issues#430 Change-Id: Idb992232163c072faa08892251b5626ae4c3a5b6 Signed-off-by: David Cunado <david.cunado@arm.com>
2016-10-31 17:37:34 +00:00
* ---------------------------------------------------------------------
*/
Disable processor Cycle Counting in Secure state In a system with ARMv8.5-PMU implemented: - If EL3 is using AArch32, setting MDCR_EL3.SCCD to 1 disables counting in Secure state in PMCCNTR. - If EL3 is using AArch64, setting SDCR.SCCD to 1 disables counting in Secure state in PMCCNTR_EL0. So far this effect has been achieved by setting PMCR_EL0.DP (in AArch64) or PMCR.DP (in AArch32) to 1 instead, but this isn't considered secure as any EL can change that value. Change-Id: I82cbb3e48f2e5a55c44d9c4445683c5881ef1f6f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-02-18 16:55:43 +00:00
mov_imm x0, ((MDCR_EL3_RESET_VAL | MDCR_SDD_BIT | \
AArch64: Disable Secure Cycle Counter This patch fixes an issue when secure world timing information can be leaked because Secure Cycle Counter is not disabled. For ARMv8.5 the counter gets disabled by setting MDCR_El3.SCCD bit on CPU cold/warm boot. For the earlier architectures PMCR_EL0 register is saved/restored on secure world entry/exit from/to Non-secure state, and cycle counting gets disabled by setting PMCR_EL0.DP bit. 'include\aarch64\arch.h' header file was tided up and new ARMv8.5-PMU related definitions were added. Change-Id: I6f56db6bc77504634a352388990ad925a69ebbfa Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-13 15:17:53 +01:00
MDCR_SPD32(MDCR_SPD32_DISABLE) | MDCR_SCCD_BIT) & \
Explicitly disable the SPME bit in MDCR_EL3 Currently the MDCR_EL3 initialisation implicitly disables MDCR_EL3.SPME by using mov_imm. This patch makes the SPME bit more visible by explicitly disabling it and documenting its use in different versions of the architecture. Signed-off-by: Petre-Ionut Tudor <petre-ionut.tudor@arm.com> Change-Id: I221fdf314f01622f46ac5aa43388f59fa17a29b3
2019-10-03 17:09:08 +01:00
~(MDCR_SPME_BIT | MDCR_TDOSA_BIT | MDCR_TDA_BIT | \
MDCR_TPM_BIT))
Disable processor Cycle Counting in Secure state In a system with ARMv8.5-PMU implemented: - If EL3 is using AArch32, setting MDCR_EL3.SCCD to 1 disables counting in Secure state in PMCCNTR. - If EL3 is using AArch64, setting SDCR.SCCD to 1 disables counting in Secure state in PMCCNTR_EL0. So far this effect has been achieved by setting PMCR_EL0.DP (in AArch64) or PMCR.DP (in AArch32) to 1 instead, but this isn't considered secure as any EL can change that value. Change-Id: I82cbb3e48f2e5a55c44d9c4445683c5881ef1f6f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-02-18 16:55:43 +00:00
Disable secure self-hosted debug via MDCR_EL3/SDCR Trusted Firmware currently has no support for secure self-hosted debug. To avoid unexpected exceptions, disable software debug exceptions, other than software breakpoint instruction exceptions, from all exception levels in secure state. This applies to both AArch32 and AArch64 EL3 initialization. Change-Id: Id097e54a6bbcd0ca6a2be930df5d860d8d09e777 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-02-08 11:51:50 +00:00
msr mdcr_el3, x0
Reset debug registers MDCR-EL3/SDCR and MDCR_EL2/HDCR In order to avoid unexpected traps into EL3/MON mode, this patch resets the debug registers, MDCR_EL3 and MDCR_EL2 for AArch64, and SDCR and HDCR for AArch32. MDCR_EL3/SDCR is zero'ed when EL3/MON mode is entered, at the start of BL1 and BL31/SMP_MIN. For MDCR_EL2/HDCR, this patch zero's the bits that are architecturally UNKNOWN values on reset. This is done when exiting from EL3/MON mode but only on platforms that support EL2/HYP mode but choose to exit to EL1/SVC mode. Fixes ARM-software/tf-issues#430 Change-Id: Idb992232163c072faa08892251b5626ae4c3a5b6 Signed-off-by: David Cunado <david.cunado@arm.com>
2016-10-31 17:37:34 +00:00
AArch64: Disable Secure Cycle Counter This patch fixes an issue when secure world timing information can be leaked because Secure Cycle Counter is not disabled. For ARMv8.5 the counter gets disabled by setting MDCR_El3.SCCD bit on CPU cold/warm boot. For the earlier architectures PMCR_EL0 register is saved/restored on secure world entry/exit from/to Non-secure state, and cycle counting gets disabled by setting PMCR_EL0.DP bit. 'include\aarch64\arch.h' header file was tided up and new ARMv8.5-PMU related definitions were added. Change-Id: I6f56db6bc77504634a352388990ad925a69ebbfa Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-08-13 15:17:53 +01:00
/* ---------------------------------------------------------------------
* Initialise PMCR_EL0 setting all fields rather than relying
* on hw. Some fields are architecturally UNKNOWN on reset.
*
* PMCR_EL0.LP: Set to one so that event counter overflow, that
* is recorded in PMOVSCLR_EL0[0-30], occurs on the increment
* that changes PMEVCNTR<n>_EL0[63] from 1 to 0, when ARMv8.5-PMU
* is implemented. This bit is RES0 in versions of the architecture
* earlier than ARMv8.5, setting it to 1 doesn't have any effect
* on them.
*
* PMCR_EL0.LC: Set to one so that cycle counter overflow, that
* is recorded in PMOVSCLR_EL0[31], occurs on the increment
* that changes PMCCNTR_EL0[63] from 1 to 0.
*
* PMCR_EL0.DP: Set to one so that the cycle counter,
* PMCCNTR_EL0 does not count when event counting is prohibited.
*
* PMCR_EL0.X: Set to zero to disable export of events.
*
* PMCR_EL0.D: Set to zero so that, when enabled, PMCCNTR_EL0
* counts on every clock cycle.
* ---------------------------------------------------------------------
*/
mov_imm x0, ((PMCR_EL0_RESET_VAL | PMCR_EL0_LP_BIT | \
PMCR_EL0_LC_BIT | PMCR_EL0_DP_BIT) & \
~(PMCR_EL0_X_BIT | PMCR_EL0_D_BIT))
msr pmcr_el0, x0
Enable asynchronous abort exceptions during boot Asynchronous abort exceptions generated by the platform during cold boot are not taken in EL3 unless SCR_EL3.EA is set. Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture initialisation. Further write accesses to SCR_EL3 preserve these bits during cold boot. A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions being trapped by EL3 after cold boot or not. For further reference SError Interrupts are also known as asynchronous external aborts. On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in EL3 whatever the SCR_EL3.EA value is. Fixes arm-software/tf-issues#368 Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
2016-03-22 08:29:23 +00:00
/* ---------------------------------------------------------------------
* Enable External Aborts and SError Interrupts now that the exception
* vectors have been setup.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* ---------------------------------------------------------------------
*/
msr daifclr, #DAIF_ABT_BIT
/* ---------------------------------------------------------------------
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* Initialise CPTR_EL3, setting all fields rather than relying on hw.
* All fields are architecturally UNKNOWN on reset.
*
* CPTR_EL3.TCPAC: Set to zero so that any accesses to CPACR_EL1,
* CPTR_EL2, CPACR, or HCPTR do not trap to EL3.
*
* CPTR_EL3.TTA: Set to zero so that System register accesses to the
* trace registers do not trap to EL3.
*
Enable SVE for Non-secure world This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set to one EL3 will check to see if the Scalable Vector Extension (SVE) is implemented 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 supported on AArch64 and so the build option is set to zero when the target archiecture is AArch32. This build option is not compatible with the CTX_INCLUDE_FPREGS - an assert will be raised on platforms where SVE is implemented and both ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1. Also note this change prevents secure world use of FP&SIMD registers on SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on such platforms unless ENABLE_SVE_FOR_NS is set to 0. Additionally, on the first entry into the Non-secure world the SVE functionality is enabled and the SVE Z-register length is set to the maximum size allowed by the architecture. This includes the use case where EL2 is implemented but not used. Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae Signed-off-by: David Cunado <david.cunado@arm.com>
2017-10-20 11:30:57 +01:00
* CPTR_EL3.TFP: Set to zero so that accesses to the V- or Z- registers
* by Advanced SIMD, floating-point or SVE instructions (if implemented)
* do not trap to EL3.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
*/
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
mov_imm x0, (CPTR_EL3_RESET_VAL & ~(TCPAC_BIT | TTA_BIT | TFP_BIT))
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
msr cptr_el3, x0
Enable DIT if supported This patch enables the Data Independent Timing functionality (DIT) in EL3 if supported by the platform. Change-Id: Ia527d6aa2ee88a9a9fe1c941220404b9ff5567e5 Signed-off-by: Sathees Balya <sathees.balya@arm.com>
2018-12-06 13:33:24 +00:00
/*
* If Data Independent Timing (DIT) functionality is implemented,
* always enable DIT in EL3
*/
mrs x0, id_aa64pfr0_el1
ubfx x0, x0, #ID_AA64PFR0_DIT_SHIFT, #ID_AA64PFR0_DIT_LENGTH
cmp x0, #ID_AA64PFR0_DIT_SUPPORTED
bne 1f
mov x0, #DIT_BIT
msr DIT, x0
1:
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
.endm
/* -----------------------------------------------------------------------------
* This is the super set of actions that need to be performed during a cold boot
Remove dashes from image names: 'BL3-x' --> 'BL3x' This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
2015-12-14 09:35:25 +00:00
* or a warm boot in EL3. This code is shared by BL1 and BL31.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
*
* This macro will always perform reset handling, architectural initialisations
* and stack setup. The rest of the actions are optional because they might not
* be needed, depending on the context in which this macro is called. This is
* why this macro is parameterised ; each parameter allows to enable/disable
* some actions.
*
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* _init_sctlr:
* Whether the macro needs to initialise SCTLR_EL3, including configuring
* the endianness of data accesses.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
*
* _warm_boot_mailbox:
* Whether the macro needs to detect the type of boot (cold/warm). The
* detection is based on the platform entrypoint address : if it is zero
* then it is a cold boot, otherwise it is a warm boot. In the latter case,
* this macro jumps on the platform entrypoint address.
*
* _secondary_cold_boot:
* Whether the macro needs to identify the CPU that is calling it: primary
* CPU or secondary CPU. The primary CPU will be allowed to carry on with
* the platform initialisations, while the secondaries will be put in a
* platform-specific state in the meantime.
*
* If the caller knows this macro will only be called by the primary CPU
* then this parameter can be defined to 0 to skip this step.
*
* _init_memory:
* Whether the macro needs to initialise the memory.
*
* _init_c_runtime:
* Whether the macro needs to initialise the C runtime environment.
*
* _exception_vectors:
* Address of the exception vectors to program in the VBAR_EL3 register.
PIE: make call to GDT relocation fixup generalized When a Firmware is complied as Position Independent Executable it needs to request GDT fixup by passing size of the memory region to el3_entrypoint_common macro. The Global descriptor table fixup will be done early on during cold boot process of primary core. Currently only BL31 supports PIE, but in future when BL2_AT_EL3 will be compiled as PIE, it can simply pass fixup size to the common el3 entrypoint macro to fixup GDT. The reason for this patch was to overcome the bug introduced by SHA 330ead806 which called fixup routine for each core causing re-initializing of global pointers thus overwriting any changes done by the previous core. Change-Id: I55c792cc3ea9e7eef34c2e4653afd04572c4f055 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2019-11-26 11:34:17 +00:00
*
* _pie_fixup_size:
* Size of memory region to fixup Global Descriptor Table (GDT).
*
* A non-zero value is expected when firmware needs GDT to be fixed-up.
*
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* -----------------------------------------------------------------------------
*/
.macro el3_entrypoint_common \
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
_init_sctlr, _warm_boot_mailbox, _secondary_cold_boot, \
PIE: make call to GDT relocation fixup generalized When a Firmware is complied as Position Independent Executable it needs to request GDT fixup by passing size of the memory region to el3_entrypoint_common macro. The Global descriptor table fixup will be done early on during cold boot process of primary core. Currently only BL31 supports PIE, but in future when BL2_AT_EL3 will be compiled as PIE, it can simply pass fixup size to the common el3 entrypoint macro to fixup GDT. The reason for this patch was to overcome the bug introduced by SHA 330ead806 which called fixup routine for each core causing re-initializing of global pointers thus overwriting any changes done by the previous core. Change-Id: I55c792cc3ea9e7eef34c2e4653afd04572c4f055 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2019-11-26 11:34:17 +00:00
_init_memory, _init_c_runtime, _exception_vectors, \
_pie_fixup_size
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
.if \_init_sctlr
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
/* -------------------------------------------------------------
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
* This is the initialisation of SCTLR_EL3 and so must ensure
* that all fields are explicitly set rather than relying on hw.
* Some fields reset to an IMPLEMENTATION DEFINED value and
* others are architecturally UNKNOWN on reset.
*
* SCTLR.EE: Set the CPU endianness before doing anything that
* might involve memory reads or writes. Set to zero to select
* Little Endian.
*
* SCTLR_EL3.WXN: For the EL3 translation regime, this field can
* force all memory regions that are writeable to be treated as
* XN (Execute-never). Set to zero so that this control has no
* effect on memory access permissions.
*
Correct some typo errors in comment File: include/common/aarch64/el3_common_macros.S Change-Id: I619401e961a3f627ad8864781b5f90bc747c3ddb Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
2018-03-05 01:31:11 +00:00
* SCTLR_EL3.SA: Set to zero to disable Stack Alignment check.
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
*
* SCTLR_EL3.A: Set to zero to disable Alignment fault checking.
AArch64: Use SSBS for CVE_2018_3639 mitigation The Armv8.5 extensions introduces PSTATE.SSBS (Speculation Store Bypass Safe) bit to mitigate against Variant 4 vulnerabilities. Although an Armv8.5 feature, this can be implemented by CPUs implementing earlier version of the architecture. With this patch, when both PSTATE.SSBS is implemented and DYNAMIC_WORKAROUND_CVE_2018_3639 is active, querying for SMCCC_ARCH_WORKAROUND_2 via. SMCCC_ARCH_FEATURES call would return 1 to indicate that mitigation on the PE is either permanently enabled or not required. When SSBS is implemented, SCTLR_EL3.DSSBS is initialized to 0 at reset of every BL stage. This means that EL3 always executes with mitigation applied. For Cortex A76, if the PE implements SSBS, the existing mitigation (by using a different vector table, and tweaking CPU ACTLR2) is not used. Change-Id: Ib0386c5714184144d4747951751c2fc6ba4242b6 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-11-15 11:38:03 +00:00
*
* SCTLR.DSSBS: Set to zero to disable speculation store bypass
* safe behaviour upon exception entry to EL3.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* -------------------------------------------------------------
*/
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
mov_imm x0, (SCTLR_RESET_VAL & ~(SCTLR_EE_BIT | SCTLR_WXN_BIT \
AArch64: Use SSBS for CVE_2018_3639 mitigation The Armv8.5 extensions introduces PSTATE.SSBS (Speculation Store Bypass Safe) bit to mitigate against Variant 4 vulnerabilities. Although an Armv8.5 feature, this can be implemented by CPUs implementing earlier version of the architecture. With this patch, when both PSTATE.SSBS is implemented and DYNAMIC_WORKAROUND_CVE_2018_3639 is active, querying for SMCCC_ARCH_WORKAROUND_2 via. SMCCC_ARCH_FEATURES call would return 1 to indicate that mitigation on the PE is either permanently enabled or not required. When SSBS is implemented, SCTLR_EL3.DSSBS is initialized to 0 at reset of every BL stage. This means that EL3 always executes with mitigation applied. For Cortex A76, if the PE implements SSBS, the existing mitigation (by using a different vector table, and tweaking CPU ACTLR2) is not used. Change-Id: Ib0386c5714184144d4747951751c2fc6ba4242b6 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-11-15 11:38:03 +00:00
| SCTLR_SA_BIT | SCTLR_A_BIT | SCTLR_DSSBS_BIT))
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
msr sctlr_el3, x0
isb
Fully initialise essential control registers This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-04-13 22:38:29 +01:00
.endif /* _init_sctlr */
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
.if \_warm_boot_mailbox
/* -------------------------------------------------------------
* This code will be executed for both warm and cold resets.
* Now is the time to distinguish between the two.
* Query the platform entrypoint address and if it is not zero
* then it means it is a warm boot so jump to this address.
* -------------------------------------------------------------
*/
PSCI: Migrate TF to the new platform API and CM helpers This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API. The per-cpu data framework APIs which took MPIDRs as their arguments are deleted and only the ones which take core index as parameter are retained. Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
2015-07-13 11:21:11 +01:00
bl plat_get_my_entrypoint
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
cbz x0, do_cold_boot
br x0
do_cold_boot:
.endif /* _warm_boot_mailbox */
PIE: make call to GDT relocation fixup generalized When a Firmware is complied as Position Independent Executable it needs to request GDT fixup by passing size of the memory region to el3_entrypoint_common macro. The Global descriptor table fixup will be done early on during cold boot process of primary core. Currently only BL31 supports PIE, but in future when BL2_AT_EL3 will be compiled as PIE, it can simply pass fixup size to the common el3 entrypoint macro to fixup GDT. The reason for this patch was to overcome the bug introduced by SHA 330ead806 which called fixup routine for each core causing re-initializing of global pointers thus overwriting any changes done by the previous core. Change-Id: I55c792cc3ea9e7eef34c2e4653afd04572c4f055 Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2019-11-26 11:34:17 +00:00
.if \_pie_fixup_size
#if ENABLE_PIE
/*
* ------------------------------------------------------------
* If PIE is enabled fixup the Global descriptor Table only
* once during primary core cold boot path.
*
* Compile time base address, required for fixup, is calculated
* using "pie_fixup" label present within first page.
* ------------------------------------------------------------
*/
pie_fixup:
ldr x0, =pie_fixup
and x0, x0, #~(PAGE_SIZE - 1)
mov_imm x1, \_pie_fixup_size
add x1, x1, x0
bl fixup_gdt_reloc
#endif /* ENABLE_PIE */
.endif /* _pie_fixup_size */
Workaround for CVE-2017-5715 on Cortex A57 and A72 Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling and enabling the MMU. To achieve this without performing any branch instruction, a per-cpu vbar is installed which executes the workaround and then branches off to the corresponding vector entry in the main vector table. A side effect of this change is that the main vbar is configured before any reset handling. This is to allow the per-cpu reset function to override the vbar setting. This workaround is enabled by default on the affected CPUs. Change-Id: I97788d38463a5840a410e3cea85ed297a1678265 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-11-30 14:53:53 +00:00
/* ---------------------------------------------------------------------
* Set the exception vectors.
* ---------------------------------------------------------------------
*/
adr x0, \_exception_vectors
msr vbar_el3, x0
isb
Initialize secondary CPUs during cold boot The previous reset code in BL1 performed the following steps in order: 1. Warm/Cold boot detection. If it's a warm boot, jump to warm boot entrypoint. 2. Primary/Secondary CPU detection. If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(), which doesn't return. 3. CPU initialisations (cache, TLB...). 4. Memory and C runtime initialization. For a secondary CPU, steps 3 and 4 are never reached. This shouldn't be a problem in most cases, since current implementations of plat_secondary_cold_boot_setup() either panic or power down the secondary CPUs. The main concern is the lack of secondary CPU initialization when bare metal EL3 payloads are used in case they don't take care of this initialisation themselves. This patch moves the detection of primary/secondary CPU after step 3 so that the CPU initialisations are performed per-CPU, while the memory and the C runtime initialisation are only performed on the primary CPU. The diagrams used in the ARM Trusted Firmware Reset Design documentation file have been updated to reflect the new boot flow. Platforms ports might be affected by this patch depending on the behaviour of plat_secondary_cold_boot_setup(), as the state of the platform when entering this function will be different. Fixes ARM-software/tf-issues#342 Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
2016-02-23 12:04:58 +00:00
/* ---------------------------------------------------------------------
* It is a cold boot.
* Perform any processor specific actions upon reset e.g. cache, TLB
* invalidations etc.
* ---------------------------------------------------------------------
*/
bl reset_handler
Workaround for CVE-2017-5715 on Cortex A57 and A72 Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling and enabling the MMU. To achieve this without performing any branch instruction, a per-cpu vbar is installed which executes the workaround and then branches off to the corresponding vector entry in the main vector table. A side effect of this change is that the main vbar is configured before any reset handling. This is to allow the per-cpu reset function to override the vbar setting. This workaround is enabled by default on the affected CPUs. Change-Id: I97788d38463a5840a410e3cea85ed297a1678265 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-11-30 14:53:53 +00:00
el3_arch_init_common
Initialize secondary CPUs during cold boot The previous reset code in BL1 performed the following steps in order: 1. Warm/Cold boot detection. If it's a warm boot, jump to warm boot entrypoint. 2. Primary/Secondary CPU detection. If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(), which doesn't return. 3. CPU initialisations (cache, TLB...). 4. Memory and C runtime initialization. For a secondary CPU, steps 3 and 4 are never reached. This shouldn't be a problem in most cases, since current implementations of plat_secondary_cold_boot_setup() either panic or power down the secondary CPUs. The main concern is the lack of secondary CPU initialization when bare metal EL3 payloads are used in case they don't take care of this initialisation themselves. This patch moves the detection of primary/secondary CPU after step 3 so that the CPU initialisations are performed per-CPU, while the memory and the C runtime initialisation are only performed on the primary CPU. The diagrams used in the ARM Trusted Firmware Reset Design documentation file have been updated to reflect the new boot flow. Platforms ports might be affected by this patch depending on the behaviour of plat_secondary_cold_boot_setup(), as the state of the platform when entering this function will be different. Fixes ARM-software/tf-issues#342 Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
2016-02-23 12:04:58 +00:00
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
.if \_secondary_cold_boot
/* -------------------------------------------------------------
Initialize secondary CPUs during cold boot The previous reset code in BL1 performed the following steps in order: 1. Warm/Cold boot detection. If it's a warm boot, jump to warm boot entrypoint. 2. Primary/Secondary CPU detection. If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(), which doesn't return. 3. CPU initialisations (cache, TLB...). 4. Memory and C runtime initialization. For a secondary CPU, steps 3 and 4 are never reached. This shouldn't be a problem in most cases, since current implementations of plat_secondary_cold_boot_setup() either panic or power down the secondary CPUs. The main concern is the lack of secondary CPU initialization when bare metal EL3 payloads are used in case they don't take care of this initialisation themselves. This patch moves the detection of primary/secondary CPU after step 3 so that the CPU initialisations are performed per-CPU, while the memory and the C runtime initialisation are only performed on the primary CPU. The diagrams used in the ARM Trusted Firmware Reset Design documentation file have been updated to reflect the new boot flow. Platforms ports might be affected by this patch depending on the behaviour of plat_secondary_cold_boot_setup(), as the state of the platform when entering this function will be different. Fixes ARM-software/tf-issues#342 Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
2016-02-23 12:04:58 +00:00
* Check if this is a primary or secondary CPU cold boot.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* The primary CPU will set up the platform while the
* secondaries are placed in a platform-specific state until the
* primary CPU performs the necessary actions to bring them out
* of that state and allows entry into the OS.
* -------------------------------------------------------------
*/
PSCI: Migrate TF to the new platform API and CM helpers This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API. The per-cpu data framework APIs which took MPIDRs as their arguments are deleted and only the ones which take core index as parameter are retained. Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
2015-07-13 11:21:11 +01:00
bl plat_is_my_cpu_primary
PSCI: Add documentation and fix plat_is_my_cpu_primary() This patch adds the necessary documentation updates to porting_guide.md for the changes in the platform interface mandated as a result of the new PSCI Topology and power state management frameworks. It also adds a new document `platform-migration-guide.md` to aid the migration of existing platform ports to the new API. The patch fixes the implementation and callers of plat_is_my_cpu_primary() to use w0 as the return parameter as implied by the function signature rather than x0 which was used previously. Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
2015-06-08 12:32:50 +01:00
cbnz w0, do_primary_cold_boot
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
/* This is a cold boot on a secondary CPU */
bl plat_secondary_cold_boot_setup
/* plat_secondary_cold_boot_setup() is not supposed to return */
Remove all non-configurable dead loops Added a new platform porting function plat_panic_handler, to allow platforms to handle unexpected error situations. It must be implemented in assembly as it may be called before the C environment is initialized. A default implementation is provided, which simply spins. Corrected all dead loops in generic code to call this function instead. This includes the dead loop that occurs at the end of the call to panic(). All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have been removed. Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
2016-02-01 13:57:25 +00:00
bl el3_panic
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
do_primary_cold_boot:
.endif /* _secondary_cold_boot */
/* ---------------------------------------------------------------------
Initialize secondary CPUs during cold boot The previous reset code in BL1 performed the following steps in order: 1. Warm/Cold boot detection. If it's a warm boot, jump to warm boot entrypoint. 2. Primary/Secondary CPU detection. If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(), which doesn't return. 3. CPU initialisations (cache, TLB...). 4. Memory and C runtime initialization. For a secondary CPU, steps 3 and 4 are never reached. This shouldn't be a problem in most cases, since current implementations of plat_secondary_cold_boot_setup() either panic or power down the secondary CPUs. The main concern is the lack of secondary CPU initialization when bare metal EL3 payloads are used in case they don't take care of this initialisation themselves. This patch moves the detection of primary/secondary CPU after step 3 so that the CPU initialisations are performed per-CPU, while the memory and the C runtime initialisation are only performed on the primary CPU. The diagrams used in the ARM Trusted Firmware Reset Design documentation file have been updated to reflect the new boot flow. Platforms ports might be affected by this patch depending on the behaviour of plat_secondary_cold_boot_setup(), as the state of the platform when entering this function will be different. Fixes ARM-software/tf-issues#342 Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
2016-02-23 12:04:58 +00:00
* Initialize memory now. Secondary CPU initialization won't get to this
* point.
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
* ---------------------------------------------------------------------
*/
.if \_init_memory
bl platform_mem_init
.endif /* _init_memory */
/* ---------------------------------------------------------------------
* Init C runtime environment:
* - Zero-initialise the NOBITS sections. There are 2 of them:
* - the .bss section;
* - the coherent memory section (if any).
* - Relocate the data section from ROM to RAM, if required.
* ---------------------------------------------------------------------
*/
.if \_init_c_runtime
Invalidate dcache build option for bl2 entry at EL3 Some of the platform (ie. Agilex) make use of CCU IPs which will only be initialized during bl2_el3_early_platform_setup. Any operation to the cache beforehand will crash the platform. Hence, this will provide an option to skip the data cache invalidation upon bl2 entry at EL3 Signed-off-by: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com> Change-Id: I2c924ed0589a72d0034714c31be8fe57237d1f06
2019-08-20 08:33:27 +01:00
#if defined(IMAGE_BL31) || (defined(IMAGE_BL2) && BL2_AT_EL3 && BL2_INV_DCACHE)
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +01:00
/* -------------------------------------------------------------
* Invalidate the RW memory used by the BL31 image. This
* includes the data and NOBITS sections. This is done to
* safeguard against possible corruption of this memory by
* dirty cache lines in a system cache as a result of use by
* an earlier boot loader stage.
* -------------------------------------------------------------
*/
PIE: Use PC relative adrp/adr for symbol reference This patch fixes up the AArch64 assembly code to use adrp/adr instructions instead of ldr instruction for reference to symbols. This allows these assembly sequences to be Position Independant. Note that the the reference to sizes have been replaced with calculation of size at runtime. This is because size is a constant value and does not depend on execution address and using PC relative instructions for loading them makes them relative to execution address. Also we cannot use `ldr` instruction to load size as it generates a dynamic relocation entry which must *not* be fixed up and it is difficult for a dynamic loader to differentiate which entries need to be skipped. Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-12 16:40:28 +01:00
adrp x0, __RW_START__
add x0, x0, :lo12:__RW_START__
adrp x1, __RW_END__
add x1, x1, :lo12:__RW_END__
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +01:00
sub x1, x1, x0
bl inv_dcache_range
bl2-el3: Add BL2_EL3 image This patch enables BL2 to execute at the highest exception level without any dependancy on TF BL1. This enables platforms which already have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL stages without need for BL1. This is not currently possible because BL2 executes at S-EL1 and cannot jump straight to EL3. Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-10-30 14:43:43 +00:00
#endif
PIE: Use PC relative adrp/adr for symbol reference This patch fixes up the AArch64 assembly code to use adrp/adr instructions instead of ldr instruction for reference to symbols. This allows these assembly sequences to be Position Independant. Note that the the reference to sizes have been replaced with calculation of size at runtime. This is because size is a constant value and does not depend on execution address and using PC relative instructions for loading them makes them relative to execution address. Also we cannot use `ldr` instruction to load size as it generates a dynamic relocation entry which must *not* be fixed up and it is difficult for a dynamic loader to differentiate which entries need to be skipped. Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-12 16:40:28 +01:00
adrp x0, __BSS_START__
add x0, x0, :lo12:__BSS_START__
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +01:00
PIE: Use PC relative adrp/adr for symbol reference This patch fixes up the AArch64 assembly code to use adrp/adr instructions instead of ldr instruction for reference to symbols. This allows these assembly sequences to be Position Independant. Note that the the reference to sizes have been replaced with calculation of size at runtime. This is because size is a constant value and does not depend on execution address and using PC relative instructions for loading them makes them relative to execution address. Also we cannot use `ldr` instruction to load size as it generates a dynamic relocation entry which must *not* be fixed up and it is difficult for a dynamic loader to differentiate which entries need to be skipped. Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-12 16:40:28 +01:00
adrp x1, __BSS_END__
add x1, x1, :lo12:__BSS_END__
sub x1, x1, x0
Introduce unified API to zero memory Introduce zeromem_dczva function on AArch64 that can handle unaligned addresses and make use of DC ZVA instruction to zero a whole block at a time. This zeroing takes place directly in the cache to speed it up without doing external memory access. Remove the zeromem16 function on AArch64 and replace it with an alias to zeromem. This zeromem16 function is now deprecated. Remove the 16-bytes alignment constraint on __BSS_START__ in firmware-design.md as it is now not mandatory anymore (it used to comply with zeromem16 requirements). Change the 16-bytes alignment constraints in SP min's linker script to a 8-bytes alignment constraint as the AArch32 zeromem implementation is now more efficient on 8-bytes aligned addresses. Introduce zero_normalmem and zeromem helpers in platform agnostic header that are implemented this way: * AArch32: * zero_normalmem: zero using usual data access * zeromem: alias for zero_normalmem * AArch64: * zero_normalmem: zero normal memory using DC ZVA instruction (needs MMU enabled) * zeromem: zero using usual data access Usage guidelines: in most cases, zero_normalmem should be preferred. There are 2 scenarios where zeromem (or memset) must be used instead: * Code that must run with MMU disabled (which means all memory is considered device memory for data accesses). * Code that fills device memory with null bytes. Optionally, the following rule can be applied if performance is important: * Code zeroing small areas (few bytes) that are not secrets should use memset to take advantage of compiler optimizations. Note: Code zeroing security-related critical information should use zero_normalmem/zeromem instead of memset to avoid removal by compilers' optimizations in some cases or misbehaving versions of GCC. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-12-02 13:51:54 +00:00
bl zeromem
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
#if USE_COHERENT_MEM
PIE: Use PC relative adrp/adr for symbol reference This patch fixes up the AArch64 assembly code to use adrp/adr instructions instead of ldr instruction for reference to symbols. This allows these assembly sequences to be Position Independant. Note that the the reference to sizes have been replaced with calculation of size at runtime. This is because size is a constant value and does not depend on execution address and using PC relative instructions for loading them makes them relative to execution address. Also we cannot use `ldr` instruction to load size as it generates a dynamic relocation entry which must *not* be fixed up and it is difficult for a dynamic loader to differentiate which entries need to be skipped. Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-12 16:40:28 +01:00
adrp x0, __COHERENT_RAM_START__
add x0, x0, :lo12:__COHERENT_RAM_START__
adrp x1, __COHERENT_RAM_END_UNALIGNED__
add x1, x1, :lo12: __COHERENT_RAM_END_UNALIGNED__
sub x1, x1, x0
Introduce unified API to zero memory Introduce zeromem_dczva function on AArch64 that can handle unaligned addresses and make use of DC ZVA instruction to zero a whole block at a time. This zeroing takes place directly in the cache to speed it up without doing external memory access. Remove the zeromem16 function on AArch64 and replace it with an alias to zeromem. This zeromem16 function is now deprecated. Remove the 16-bytes alignment constraint on __BSS_START__ in firmware-design.md as it is now not mandatory anymore (it used to comply with zeromem16 requirements). Change the 16-bytes alignment constraints in SP min's linker script to a 8-bytes alignment constraint as the AArch32 zeromem implementation is now more efficient on 8-bytes aligned addresses. Introduce zero_normalmem and zeromem helpers in platform agnostic header that are implemented this way: * AArch32: * zero_normalmem: zero using usual data access * zeromem: alias for zero_normalmem * AArch64: * zero_normalmem: zero normal memory using DC ZVA instruction (needs MMU enabled) * zeromem: zero using usual data access Usage guidelines: in most cases, zero_normalmem should be preferred. There are 2 scenarios where zeromem (or memset) must be used instead: * Code that must run with MMU disabled (which means all memory is considered device memory for data accesses). * Code that fills device memory with null bytes. Optionally, the following rule can be applied if performance is important: * Code zeroing small areas (few bytes) that are not secrets should use memset to take advantage of compiler optimizations. Note: Code zeroing security-related critical information should use zero_normalmem/zeromem instead of memset to avoid removal by compilers' optimizations in some cases or misbehaving versions of GCC. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2016-12-02 13:51:54 +00:00
bl zeromem
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
#endif
Add missing support for BL2_AT_EL3 in XIP memory Add the missing flag for aarch32 XIP memory mode. It was previously added in aarch64 only. Minor: Correct the aarch64 missing flag. Signed-off-by: Lionel Debieve <lionel.debieve@st.com> Change-Id: Iac0a7581a1fd580aececa75f97deb894858f776f
2019-05-27 08:32:00 +01:00
#if defined(IMAGE_BL1) || (defined(IMAGE_BL2) && BL2_AT_EL3 && BL2_IN_XIP_MEM)
PIE: Use PC relative adrp/adr for symbol reference This patch fixes up the AArch64 assembly code to use adrp/adr instructions instead of ldr instruction for reference to symbols. This allows these assembly sequences to be Position Independant. Note that the the reference to sizes have been replaced with calculation of size at runtime. This is because size is a constant value and does not depend on execution address and using PC relative instructions for loading them makes them relative to execution address. Also we cannot use `ldr` instruction to load size as it generates a dynamic relocation entry which must *not* be fixed up and it is difficult for a dynamic loader to differentiate which entries need to be skipped. Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-10-12 16:40:28 +01:00
adrp x0, __DATA_RAM_START__
add x0, x0, :lo12:__DATA_RAM_START__
adrp x1, __DATA_ROM_START__
add x1, x1, :lo12:__DATA_ROM_START__
adrp x2, __DATA_RAM_END__
add x2, x2, :lo12:__DATA_RAM_END__
sub x2, x2, x0
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
bl memcpy16
#endif
.endif /* _init_c_runtime */
/* ---------------------------------------------------------------------
* Use SP_EL0 for the C runtime stack.
* ---------------------------------------------------------------------
*/
msr spsel, #0
/* ---------------------------------------------------------------------
* Allocate a stack whose memory will be marked as Normal-IS-WBWA when
* the MMU is enabled. There is no risk of reading stale stack memory
* after enabling the MMU as only the primary CPU is running at the
* moment.
* ---------------------------------------------------------------------
*/
PSCI: Migrate TF to the new platform API and CM helpers This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API. The per-cpu data framework APIs which took MPIDRs as their arguments are deleted and only the ones which take core index as parameter are retained. Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
2015-07-13 11:21:11 +01:00
bl plat_set_my_stack
Add support for GCC stack protection Introduce new build option ENABLE_STACK_PROTECTOR. It enables compilation of all BL images with one of the GCC -fstack-protector-* options. A new platform function plat_get_stack_protector_canary() is introduced. It returns a value that is used to initialize the canary for stack corruption detection. Returning a random value will prevent an attacker from predicting the value and greatly increase the effectiveness of the protection. A message is printed at the ERROR level when a stack corruption is detected. To be effective, the global data must be stored at an address lower than the base of the stacks. Failure to do so would allow an attacker to overwrite the canary as part of an attack which would void the protection. FVP implementation of plat_get_stack_protector_canary is weak as there is no real source of entropy on the FVP. It therefore relies on a timer's value, which could be predictable. Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-02-24 18:14:15 +00:00
#if STACK_PROTECTOR_ENABLED
.if \_init_c_runtime
bl update_stack_protector_canary
.endif /* _init_c_runtime */
#endif
Rationalize reset handling code The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
2015-05-19 11:54:45 +01:00
.endm
Standardise header guards across codebase All identifiers, regardless of use, that start with two underscores are reserved. This means they can't be used in header guards. The style that this project is now to use the full name of the file in capital letters followed by 'H'. For example, for a file called "uart_example.h", the header guard is UART_EXAMPLE_H. The exceptions are files that are imported from other projects: - CryptoCell driver - dt-bindings folders - zlib headers Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-11-08 10:20:19 +00:00
#endif /* EL3_COMMON_MACROS_S */