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

222 lines
5.3 KiB
ArmAsm
Raw Normal View History

ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
/*
Add support for Branch Target Identification This patch adds the functionality needed for platforms to provide Branch Target Identification (BTI) extension, introduced to AArch64 in Armv8.5-A by adding BTI instruction used to mark valid targets for indirect branches. The patch sets new GP bit [50] to the stage 1 Translation Table Block and Page entries to denote guarded EL3 code pages which will cause processor to trap instructions in protected pages trying to perform an indirect branch to any instruction other than BTI. BTI feature is selected by BRANCH_PROTECTION option which supersedes the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication and is disabled by default. Enabling BTI requires compiler support and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0. The assembly macros and helpers are modified to accommodate the BTI instruction. This is an experimental feature. Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3 is now made as an internal flag and BRANCH_PROTECTION flag should be used instead to enable Pointer Authentication. Note. USE_LIBROM=1 option is currently not supported. Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-05-24 12:17:09 +01:00
* Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +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
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +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 ASM_MACROS_S
#define ASM_MACROS_S
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
Reduce deep nesting of header files Reduce the number of header files included from other header files as much as possible without splitting the files. Use forward declarations where possible. This allows removal of some unnecessary "#ifndef __ASSEMBLY__" statements. Also, review the .c and .S files for which header files really need including and reorder the #include statements alphabetically. Fixes ARM-software/tf-issues#31 Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
2014-04-09 13:14:54 +01:00
#include <arch.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <common/asm_macros_common.S>
#include <lib/spinlock.h>
Reduce deep nesting of header files Reduce the number of header files included from other header files as much as possible without splitting the files. Use forward declarations where possible. This allows removal of some unnecessary "#ifndef __ASSEMBLY__" statements. Also, review the .c and .S files for which header files really need including and reorder the #include statements alphabetically. Fixes ARM-software/tf-issues#31 Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
2014-04-09 13:14:54 +01:00
Add support for Branch Target Identification This patch adds the functionality needed for platforms to provide Branch Target Identification (BTI) extension, introduced to AArch64 in Armv8.5-A by adding BTI instruction used to mark valid targets for indirect branches. The patch sets new GP bit [50] to the stage 1 Translation Table Block and Page entries to denote guarded EL3 code pages which will cause processor to trap instructions in protected pages trying to perform an indirect branch to any instruction other than BTI. BTI feature is selected by BRANCH_PROTECTION option which supersedes the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication and is disabled by default. Enabling BTI requires compiler support and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0. The assembly macros and helpers are modified to accommodate the BTI instruction. This is an experimental feature. Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3 is now made as an internal flag and BRANCH_PROTECTION flag should be used instead to enable Pointer Authentication. Note. USE_LIBROM=1 option is currently not supported. Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-05-24 12:17:09 +01:00
#if ENABLE_BTI && !ARM_ARCH_AT_LEAST(8, 5)
#error Branch Target Identification requires ARM_ARCH_MINOR >= 5
#endif
xlat v2: Split MMU setup and enable At present, the function provided by the translation library to enable MMU constructs appropriate values for translation library, and programs them to the right registers. The construction of initial values, however, is only required once as both the primary and secondaries program the same values. Additionally, the MMU-enabling function is written in C, which means there's an active stack at the time of enabling MMU. On some systems, like Arm DynamIQ, having active stack while enabling MMU during warm boot might lead to coherency problems. This patch addresses both the above problems by: - Splitting the MMU-enabling function into two: one that sets up values to be programmed into the registers, and another one that takes the pre-computed values and writes to the appropriate registers. With this, the primary effectively calls both functions to have the MMU enabled, but secondaries only need to call the latter. - Rewriting the function that enables MMU in assembly so that it doesn't use stack. This patch fixes a bunch of MISRA issues on the way. Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-04-27 15:06:57 +01:00
/*
* TLBI instruction with type specifier that implements the workaround for
Workaround for cortex-A76 errata 1286807 The workaround for Cortex-A76 errata #1286807 is implemented in this patch. Change-Id: I6c15af962ac99ce223e009f6d299cefb41043bed Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2019-05-03 13:17:56 +01:00
* errata 813419 of Cortex-A57 or errata 1286807 of Cortex-A76.
xlat v2: Split MMU setup and enable At present, the function provided by the translation library to enable MMU constructs appropriate values for translation library, and programs them to the right registers. The construction of initial values, however, is only required once as both the primary and secondaries program the same values. Additionally, the MMU-enabling function is written in C, which means there's an active stack at the time of enabling MMU. On some systems, like Arm DynamIQ, having active stack while enabling MMU during warm boot might lead to coherency problems. This patch addresses both the above problems by: - Splitting the MMU-enabling function into two: one that sets up values to be programmed into the registers, and another one that takes the pre-computed values and writes to the appropriate registers. With this, the primary effectively calls both functions to have the MMU enabled, but secondaries only need to call the latter. - Rewriting the function that enables MMU in assembly so that it doesn't use stack. This patch fixes a bunch of MISRA issues on the way. Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-04-27 15:06:57 +01:00
*/
Workaround for cortex-A76 errata 1286807 The workaround for Cortex-A76 errata #1286807 is implemented in this patch. Change-Id: I6c15af962ac99ce223e009f6d299cefb41043bed Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2019-05-03 13:17:56 +01:00
#if ERRATA_A57_813419 || ERRATA_A76_1286807
xlat v2: Split MMU setup and enable At present, the function provided by the translation library to enable MMU constructs appropriate values for translation library, and programs them to the right registers. The construction of initial values, however, is only required once as both the primary and secondaries program the same values. Additionally, the MMU-enabling function is written in C, which means there's an active stack at the time of enabling MMU. On some systems, like Arm DynamIQ, having active stack while enabling MMU during warm boot might lead to coherency problems. This patch addresses both the above problems by: - Splitting the MMU-enabling function into two: one that sets up values to be programmed into the registers, and another one that takes the pre-computed values and writes to the appropriate registers. With this, the primary effectively calls both functions to have the MMU enabled, but secondaries only need to call the latter. - Rewriting the function that enables MMU in assembly so that it doesn't use stack. This patch fixes a bunch of MISRA issues on the way. Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-04-27 15:06:57 +01:00
#define TLB_INVALIDATE(_type) \
tlbi _type; \
dsb ish; \
tlbi _type
#else
#define TLB_INVALIDATE(_type) \
tlbi _type
#endif
Reduce deep nesting of header files Reduce the number of header files included from other header files as much as possible without splitting the files. Use forward declarations where possible. This allows removal of some unnecessary "#ifndef __ASSEMBLY__" statements. Also, review the .c and .S files for which header files really need including and reorder the #include statements alphabetically. Fixes ARM-software/tf-issues#31 Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
2014-04-09 13:14:54 +01:00
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
.macro func_prologue
stp x29, x30, [sp, #-0x10]!
mov x29,sp
.endm
.macro func_epilogue
ldp x29, x30, [sp], #0x10
.endm
.macro dcache_line_size reg, tmp
Introduce new exception handling framework This patch introduces the reworked exception handling logic which lays the foundation for accessing runtime services in later patches. The type of an exception has a greater say in the way it is handled. SP_EL3 is used as the stack pointer for: 1. Determining the type of exception and handling the unexpected ones on the exception stack 2. Saving and restoring the essential general purpose and system register state after exception entry and prior to exception exit. SP_EL0 is used as the stack pointer for handling runtime service requests e.g. SMCs. A new structure for preserving general purpose register state has been added to the 'cpu_context' structure. All assembler ensures that it does not use callee saved registers (x19-x29). The C runtime preserves them across functions calls. Hence EL3 code does not have to save and restore them explicitly. Since the exception handling framework has undergone substantial change, the changes have been kept in separate files to aid readability. These files will replace the existing ones in subsequent patches. Change-Id: Ice418686592990ff7a4260771e8d6676e6c8c5ef
2014-02-02 12:02:23 +00:00
mrs \tmp, ctr_el0
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
ubfx \tmp, \tmp, #16, #4
Introduce new exception handling framework This patch introduces the reworked exception handling logic which lays the foundation for accessing runtime services in later patches. The type of an exception has a greater say in the way it is handled. SP_EL3 is used as the stack pointer for: 1. Determining the type of exception and handling the unexpected ones on the exception stack 2. Saving and restoring the essential general purpose and system register state after exception entry and prior to exception exit. SP_EL0 is used as the stack pointer for handling runtime service requests e.g. SMCs. A new structure for preserving general purpose register state has been added to the 'cpu_context' structure. All assembler ensures that it does not use callee saved registers (x19-x29). The C runtime preserves them across functions calls. Hence EL3 code does not have to save and restore them explicitly. Since the exception handling framework has undergone substantial change, the changes have been kept in separate files to aid readability. These files will replace the existing ones in subsequent patches. Change-Id: Ice418686592990ff7a4260771e8d6676e6c8c5ef
2014-02-02 12:02:23 +00:00
mov \reg, #4
lsl \reg, \reg, \tmp
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
.endm
.macro icache_line_size reg, tmp
Introduce new exception handling framework This patch introduces the reworked exception handling logic which lays the foundation for accessing runtime services in later patches. The type of an exception has a greater say in the way it is handled. SP_EL3 is used as the stack pointer for: 1. Determining the type of exception and handling the unexpected ones on the exception stack 2. Saving and restoring the essential general purpose and system register state after exception entry and prior to exception exit. SP_EL0 is used as the stack pointer for handling runtime service requests e.g. SMCs. A new structure for preserving general purpose register state has been added to the 'cpu_context' structure. All assembler ensures that it does not use callee saved registers (x19-x29). The C runtime preserves them across functions calls. Hence EL3 code does not have to save and restore them explicitly. Since the exception handling framework has undergone substantial change, the changes have been kept in separate files to aid readability. These files will replace the existing ones in subsequent patches. Change-Id: Ice418686592990ff7a4260771e8d6676e6c8c5ef
2014-02-02 12:02:23 +00:00
mrs \tmp, ctr_el0
and \tmp, \tmp, #0xf
mov \reg, #4
lsl \reg, \reg, \tmp
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
.endm
.macro smc_check label
Access system registers directly in assembler Instead of using the system register helper functions to read or write system registers, assembler coded functions should use MRS/MSR instructions. This results in faster and more compact code. This change replaces all usage of the helper functions with direct register accesses. Change-Id: I791d5f11f257010bb3e6a72c6c5ab8779f1982b3
2014-04-28 12:32:02 +01:00
mrs x0, esr_el3
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
ubfx x0, x0, #ESR_EC_SHIFT, #ESR_EC_LENGTH
cmp x0, #EC_AARCH64_SMC
b.ne $label
.endm
Introduce some helper macros for exception vectors This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
2016-05-24 16:56:03 +01:00
/*
* Declare the exception vector table, enforcing it is aligned on a
* 2KB boundary, as required by the ARMv8 architecture.
Fill exception vectors with zero bytes The documentation of the GNU assembler specifies the following about the .align assembler directive: "the padding bytes are normally zero. However, on some systems, if the section is marked as containing code and the fill value is omitted, the space is filled with no-op instructions." (see https://sourceware.org/binutils/docs/as/Align.html) When building Trusted Firmware, the AArch64 GNU assembler uses a mix of zero bytes and no-op instructions as the padding bytes to align exception vectors. This patch mandates to use zero bytes to be stored in the padding bytes in the exception vectors. In the AArch64 instruction set, no valid instruction encodes as zero so this effectively inserts illegal instructions. Should this code end up being executed for any reason, it would crash immediately. This gives us an extra protection against misbehaving code at no extra cost. Change-Id: I4f2abb39d0320ca0f9d467fc5af0cb92ae297351
2016-05-24 16:22:59 +01:00
* Use zero bytes as the fill value to be stored in the padding bytes
* so that it inserts illegal AArch64 instructions. This increases
* security, robustness and potentially facilitates debugging.
Introduce some helper macros for exception vectors This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
2016-05-24 16:56:03 +01:00
*/
SPM: Introduce Secure Partition Manager A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-10-24 10:07:35 +01:00
.macro vector_base label, section_name=.vectors
.section \section_name, "ax"
Fill exception vectors with zero bytes The documentation of the GNU assembler specifies the following about the .align assembler directive: "the padding bytes are normally zero. However, on some systems, if the section is marked as containing code and the fill value is omitted, the space is filled with no-op instructions." (see https://sourceware.org/binutils/docs/as/Align.html) When building Trusted Firmware, the AArch64 GNU assembler uses a mix of zero bytes and no-op instructions as the padding bytes to align exception vectors. This patch mandates to use zero bytes to be stored in the padding bytes in the exception vectors. In the AArch64 instruction set, no valid instruction encodes as zero so this effectively inserts illegal instructions. Should this code end up being executed for any reason, it would crash immediately. This gives us an extra protection against misbehaving code at no extra cost. Change-Id: I4f2abb39d0320ca0f9d467fc5af0cb92ae297351
2016-05-24 16:22:59 +01:00
.align 11, 0
Introduce some helper macros for exception vectors This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
2016-05-24 16:56:03 +01:00
\label:
.endm
/*
* Create an entry in the exception vector table, enforcing it is
* aligned on a 128-byte boundary, as required by the ARMv8 architecture.
Fill exception vectors with zero bytes The documentation of the GNU assembler specifies the following about the .align assembler directive: "the padding bytes are normally zero. However, on some systems, if the section is marked as containing code and the fill value is omitted, the space is filled with no-op instructions." (see https://sourceware.org/binutils/docs/as/Align.html) When building Trusted Firmware, the AArch64 GNU assembler uses a mix of zero bytes and no-op instructions as the padding bytes to align exception vectors. This patch mandates to use zero bytes to be stored in the padding bytes in the exception vectors. In the AArch64 instruction set, no valid instruction encodes as zero so this effectively inserts illegal instructions. Should this code end up being executed for any reason, it would crash immediately. This gives us an extra protection against misbehaving code at no extra cost. Change-Id: I4f2abb39d0320ca0f9d467fc5af0cb92ae297351
2016-05-24 16:22:59 +01:00
* Use zero bytes as the fill value to be stored in the padding bytes
* so that it inserts illegal AArch64 instructions. This increases
* security, robustness and potentially facilitates debugging.
Introduce some helper macros for exception vectors This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
2016-05-24 16:56:03 +01:00
*/
SPM: Introduce Secure Partition Manager A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-10-24 10:07:35 +01:00
.macro vector_entry label, section_name=.vectors
Add CFI debug info to vector entries Add Call Frame Information assembler directives to vector entries so that debuggers display the backtrace of functions that triggered a synchronous exception. For example, a function triggering a data abort will be easier to debug if the backtrace can be displayed from a breakpoint at the beginning of the synchronous exception vector. DS-5 needs CFI otherwise it will not attempt to display the backtrace. Other debuggers might have other needs. These debug information are stored in the ELF file but not in the final binary. Change-Id: I32dc4e4b7af02546c93c1a45c71a1f6d710d36b1 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-08-07 16:20:46 +01:00
.cfi_sections .debug_frame
SPM: Introduce Secure Partition Manager A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-10-24 10:07:35 +01:00
.section \section_name, "ax"
Fill exception vectors with zero bytes The documentation of the GNU assembler specifies the following about the .align assembler directive: "the padding bytes are normally zero. However, on some systems, if the section is marked as containing code and the fill value is omitted, the space is filled with no-op instructions." (see https://sourceware.org/binutils/docs/as/Align.html) When building Trusted Firmware, the AArch64 GNU assembler uses a mix of zero bytes and no-op instructions as the padding bytes to align exception vectors. This patch mandates to use zero bytes to be stored in the padding bytes in the exception vectors. In the AArch64 instruction set, no valid instruction encodes as zero so this effectively inserts illegal instructions. Should this code end up being executed for any reason, it would crash immediately. This gives us an extra protection against misbehaving code at no extra cost. Change-Id: I4f2abb39d0320ca0f9d467fc5af0cb92ae297351
2016-05-24 16:22:59 +01:00
.align 7, 0
Add CFI debug info to vector entries Add Call Frame Information assembler directives to vector entries so that debuggers display the backtrace of functions that triggered a synchronous exception. For example, a function triggering a data abort will be easier to debug if the backtrace can be displayed from a breakpoint at the beginning of the synchronous exception vector. DS-5 needs CFI otherwise it will not attempt to display the backtrace. Other debuggers might have other needs. These debug information are stored in the ELF file but not in the final binary. Change-Id: I32dc4e4b7af02546c93c1a45c71a1f6d710d36b1 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
2017-08-07 16:20:46 +01:00
.type \label, %function
.cfi_startproc
Introduce some helper macros for exception vectors This patch introduces some assembler macros to simplify the declaration of the exception vectors. It abstracts the section the exception code is put into as well as the alignments constraints mandated by the ARMv8 architecture. For all TF images, the exception code has been updated to make use of these macros. This patch also updates some invalid comments in the exception vector code. Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95
2016-05-24 16:56:03 +01:00
\label:
.endm
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
Add end_vector_entry assembler macro Check_vector_size checks if the size of the vector fits in the size reserved for it. This check creates problems in the Clang assembler. A new macro, end_vector_entry, is added and check_vector_size is deprecated. This new macro fills the current exception vector until the next exception vector. If the size of the current vector is bigger than 32 instructions then it gives an error. Change-Id: Ie8545cf1003a1e31656a1018dd6b4c28a4eaf671 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-04-17 11:31:43 +01:00
/*
* Add the bytes until fill the full exception vector, whose size is always
* 32 instructions. If there are more than 32 instructions in the
* exception vector then an error is emitted.
*/
.macro end_vector_entry label
.cfi_endproc
.fill \label + (32 * 4) - .
.endm
PSCI: Introduce new platform and CM helper APIs This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This framework will be introduced in the follwoing patch and it removes the assumption that the MPIDR based affinity levels map directly to levels in a power domain tree. The new platforms APIs and context management helpers based on core position are as described below: * plat_my_core_pos() and plat_core_pos_by_mpidr() These 2 new mandatory platform APIs are meant to replace the existing 'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the linear index of the calling core and 'plat_core_pos_by_mpidr()' returns the linear index of a core specified by its MPIDR. The latter API will also validate the MPIDR passed as an argument and will return an error code (-1) if an invalid MPIDR is passed as the argument. This enables the caller to safely convert an MPIDR of another core to its linear index without querying the PSCI topology tree e.g. during a call to PSCI CPU_ON. Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always platform specific, it is no longer possible to maintain a default implementation of this API. Also it might not be possible for a platform port to verify an MPIDR before the C runtime has been setup or the topology has been initialized. This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to topology setup. As a result, the generic Trusted Firmware code does not call this API before the topology setup has been done. The 'plat_my_core_pos' API should be able to run without a C runtime. Since this API needs to return a core position which is equal to the one returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR, this too cannot have default implementation and is a mandatory API for platform ports. These APIs will be implemented by the ARM reference platform ports later in the patch stack. * plat_get_my_stack() and plat_set_my_stack() These APIs are the stack management APIs which set/return stack addresses appropriate for the calling core. These replace the 'platform_get_stack()' and 'platform_set_stack()' APIs. A default weak MP version and a global UP version of these APIs are provided for the platforms. * Context management helpers based on linear core position A set of new context management(CM) helpers viz cm_get_context_by_index(), cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index() are defined which are meant to replace the old helpers which took MPIDR as argument. The old CM helpers are implemented based on the new helpers to allow for code consolidation and will be deprecated once the switch to the new framework is done. Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
2015-04-09 13:40:55 +01:00
/*
* This macro calculates the base address of the current CPU's MP stack
* using the plat_my_core_pos() index, the name of the stack storage
* and the size of each stack
* Out: X0 = physical address of stack base
* Clobber: X30, X1, X2
*/
.macro get_my_mp_stack _name, _size
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
bl plat_my_core_pos
adrp x2, (\_name + \_size)
add x2, x2, :lo12:(\_name + \_size)
PSCI: Introduce new platform and CM helper APIs This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This framework will be introduced in the follwoing patch and it removes the assumption that the MPIDR based affinity levels map directly to levels in a power domain tree. The new platforms APIs and context management helpers based on core position are as described below: * plat_my_core_pos() and plat_core_pos_by_mpidr() These 2 new mandatory platform APIs are meant to replace the existing 'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the linear index of the calling core and 'plat_core_pos_by_mpidr()' returns the linear index of a core specified by its MPIDR. The latter API will also validate the MPIDR passed as an argument and will return an error code (-1) if an invalid MPIDR is passed as the argument. This enables the caller to safely convert an MPIDR of another core to its linear index without querying the PSCI topology tree e.g. during a call to PSCI CPU_ON. Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always platform specific, it is no longer possible to maintain a default implementation of this API. Also it might not be possible for a platform port to verify an MPIDR before the C runtime has been setup or the topology has been initialized. This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to topology setup. As a result, the generic Trusted Firmware code does not call this API before the topology setup has been done. The 'plat_my_core_pos' API should be able to run without a C runtime. Since this API needs to return a core position which is equal to the one returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR, this too cannot have default implementation and is a mandatory API for platform ports. These APIs will be implemented by the ARM reference platform ports later in the patch stack. * plat_get_my_stack() and plat_set_my_stack() These APIs are the stack management APIs which set/return stack addresses appropriate for the calling core. These replace the 'platform_get_stack()' and 'platform_set_stack()' APIs. A default weak MP version and a global UP version of these APIs are provided for the platforms. * Context management helpers based on linear core position A set of new context management(CM) helpers viz cm_get_context_by_index(), cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index() are defined which are meant to replace the old helpers which took MPIDR as argument. The old CM helpers are implemented based on the new helpers to allow for code consolidation and will be deprecated once the switch to the new framework is done. Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
2015-04-09 13:40:55 +01:00
mov x1, #\_size
madd x0, x0, x1, x2
.endm
Allocate single stacks for BL1 and BL2 The BL images share common stack management code which provides one coherent and one cacheable stack for every CPU. BL1 and BL2 just execute on the primary CPU during boot and do not require the additional CPU stacks. This patch provides separate stack support code for UP and MP images, substantially reducing the RAM usage for BL1 and BL2 for the FVP platform. This patch also provides macros for declaring stacks and calculating stack base addresses to improve consistency where this has to be done in the firmware. The stack allocation source files are now included via platform.mk rather than the common BLx makefiles. This allows each platform to select the appropriate MP/UP stack support for each BL image. Each platform makefile must be updated when including this commit. Fixes ARM-software/tf-issues#76 Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
2014-03-20 10:48:23 +00:00
/*
* This macro calculates the base address of a UP stack using the
* name of the stack storage and the size of the stack
* Out: X0 = physical address of stack base
*/
.macro get_up_stack _name, _size
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, (\_name + \_size)
add x0, x0, :lo12:(\_name + \_size)
Allocate single stacks for BL1 and BL2 The BL images share common stack management code which provides one coherent and one cacheable stack for every CPU. BL1 and BL2 just execute on the primary CPU during boot and do not require the additional CPU stacks. This patch provides separate stack support code for UP and MP images, substantially reducing the RAM usage for BL1 and BL2 for the FVP platform. This patch also provides macros for declaring stacks and calculating stack base addresses to improve consistency where this has to be done in the firmware. The stack allocation source files are now included via platform.mk rather than the common BLx makefiles. This allows each platform to select the appropriate MP/UP stack support for each BL image. Each platform makefile must be updated when including this commit. Fixes ARM-software/tf-issues#76 Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
2014-03-20 10:48:23 +00:00
.endm
Introduce crash console APIs for crash reporting This patch introduces platform APIs to initialise and print a character on a designated crash console. For the FVP platform, PL011_UART0 is the designated crash console. The platform porting guide is also updated to document the new APIs. Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66
2014-07-14 16:57:23 +01:00
/*
* Helper macro to generate the best mov/movk combinations according
* the value to be moved. The 16 bits from '_shift' are tested and
* if not zero, they are moved into '_reg' without affecting
* other bits.
*/
.macro _mov_imm16 _reg, _val, _shift
.if (\_val >> \_shift) & 0xffff
.if (\_val & (1 << \_shift - 1))
movk \_reg, (\_val >> \_shift) & 0xffff, LSL \_shift
.else
mov \_reg, \_val & (0xffff << \_shift)
.endif
.endif
.endm
/*
* Helper macro to load arbitrary values into 32 or 64-bit registers
* which generates the best mov/movk combinations. Many base addresses
* are 64KB aligned the macro will eliminate updating bits 15:0 in
* that case
*/
.macro mov_imm _reg, _val
.if (\_val) == 0
mov \_reg, #0
.else
_mov_imm16 \_reg, (\_val), 0
_mov_imm16 \_reg, (\_val), 16
_mov_imm16 \_reg, (\_val), 32
_mov_imm16 \_reg, (\_val), 48
.endif
.endm
Add header guards to asm macro files Some assembly files containing macros are included like header files into other assembly files. This will cause assembler errors if they are included multiple times. Add header guards to assembly macro files to avoid assembler errors. Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69
2015-04-01 17:34:24 +01:00
Define and use no_ret macro where no return is expected There are many instances in ARM Trusted Firmware where control is transferred to functions from which return isn't expected. Such jumps are made using 'bl' instruction to provide the callee with the location from which it was jumped to. Additionally, debuggers infer the caller by examining where 'lr' register points to. If a 'bl' of the nature described above falls at the end of an assembly function, 'lr' will be left pointing to a location outside of the function range. This misleads the debugger back trace. This patch defines a 'no_ret' macro to be used when jumping to functions from which return isn't expected. The macro ensures to use 'bl' instruction for the jump, and also, for debug builds, places a 'nop' instruction immediately thereafter (unless instructed otherwise) so as to leave 'lr' pointing within the function range. Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0 Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-11-30 15:21:11 +00:00
/*
* Macro to mark instances where we're jumping to a function and don't
* expect a return. To provide the function being jumped to with
* additional information, we use 'bl' instruction to jump rather than
* 'b'.
*
* Debuggers infer the location of a call from where LR points to, which
* is usually the instruction after 'bl'. If this macro expansion
* happens to be the last location in a function, that'll cause the LR
* to point a location beyond the function, thereby misleading debugger
* back trace. We therefore insert a 'nop' after the function call for
* debug builds, unless 'skip_nop' parameter is non-zero.
*/
.macro no_ret _func:req, skip_nop=0
bl \_func
#if DEBUG
.ifeq \skip_nop
nop
.endif
#endif
.endm
Allow spin locks to be defined from assembly At present, spin locks can only defined from C files. Add some macros such that they can be defined from assembly files too. Change-Id: I64f0c214062f5c15b3c8b412c7f25c908e87d970 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-01-19 14:23:36 +00:00
/*
* Reserve space for a spin lock in assembly file.
*/
.macro define_asm_spinlock _name:req
.align SPINLOCK_ASM_ALIGN
\_name:
.space SPINLOCK_ASM_SIZE
.endm
AArch64: Introduce RAS handling RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-04-04 16:07:11 +01:00
#if RAS_EXTENSION
.macro esb
.inst 0xd503221f
.endm
#endif
Add support for Branch Target Identification This patch adds the functionality needed for platforms to provide Branch Target Identification (BTI) extension, introduced to AArch64 in Armv8.5-A by adding BTI instruction used to mark valid targets for indirect branches. The patch sets new GP bit [50] to the stage 1 Translation Table Block and Page entries to denote guarded EL3 code pages which will cause processor to trap instructions in protected pages trying to perform an indirect branch to any instruction other than BTI. BTI feature is selected by BRANCH_PROTECTION option which supersedes the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication and is disabled by default. Enabling BTI requires compiler support and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0. The assembly macros and helpers are modified to accommodate the BTI instruction. This is an experimental feature. Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3 is now made as an internal flag and BRANCH_PROTECTION flag should be used instead to enable Pointer Authentication. Note. USE_LIBROM=1 option is currently not supported. Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
2019-05-24 12:17:09 +01:00
/*
* Helper macro to read system register value into x0
*/
.macro read reg:req
#if ENABLE_BTI
bti j
#endif
mrs x0, \reg
ret
.endm
/*
* Helper macro to write value from x1 to system register
*/
.macro write reg:req
#if ENABLE_BTI
bti j
#endif
msr \reg, x1
ret
.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 /* ASM_MACROS_S */