github
/
arm-trusted-firmware
mirror of https://github.com/ARM-software/arm-trusted-firmware.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
11995 Commits
5 Branches
114 Tags
55 MiB
Tree: f90fe02f06
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f90fe02f06'
${ noResults }
arm-trusted-firmware/bl31/bl31.mk

181 lines
4.4 KiB
Raw Normal View History

ARMv8 Trusted Firmware release v0.2
11 years ago
#
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro "FEATURE_DETECTION", which is currently being disabled by default. The "FEATURE_DETECTION" macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this "FEATURE_DETECTION" flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
# Copyright (c) 2013-2022, ARM Limited and Contributors. All rights reserved.
ARMv8 Trusted Firmware release v0.2
11 years ago
#
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>
8 years ago
# SPDX-License-Identifier: BSD-3-Clause
ARMv8 Trusted Firmware release v0.2
11 years ago
#
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>
7 years ago
################################################################################
spm: Remove SPM Alpha 1 prototype and support files The Secure Partition Manager (SPM) prototype implementation is being removed. This is preparatory work for putting in place a dispatcher component that, in turn, enables partition managers at S-EL2 / S-EL1. This patch removes: - The core service files (std_svc/spm) - The Resource Descriptor headers (include/services) - SPRT protocol support and service definitions - SPCI protocol support and service definitions Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426 Signed-off-by: Paul Beesley <paul.beesley@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
5 years ago
# Include Makefile for the SPM-MM implementation
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>
7 years ago
################################################################################
arm_fpga: Add support for unknown MPIDs This patch allows the system to fallback to a default CPU library in case the MPID does not match with any of the supported ones. This feature can be enabled by setting SUPPORT_UNKNOWN_MPID build option to 1 (enabled by default only on arm_fpga platform). This feature can be very dangerous on a production image and therefore it MUST be disabled for Release images. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I0df7ef2b012d7d60a4fd5de44dea1fbbb46881ba
4 years ago
ifeq (${SUPPORT_UNKNOWN_MPID},1)
ifeq (${DEBUG},0)
$(warning WARNING: SUPPORT_UNKNOWN_MPID enabled)
endif
endif
Remove dependency between SPM_MM and ENABLE_SPM build flags There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the other is based on the Secure Partition Client Interface (SPCI) specification. Currently there is a dependency between their build flags that shouldn't exist, making further development harder than it should be. This patch removes that dependency, making the two flags function independently. Before: ENABLE_SPM=1 is required for using either implementation. By default, the SPCI-based implementation is enabled and this is overridden if SPM_MM=1. After: ENABLE_SPM=1 enables the SPCI-based implementation. SPM_MM=1 enables the MM-based implementation. The two build flags are mutually exclusive. Note that the name of the ENABLE_SPM flag remains a bit ambiguous - this will be improved in a subsequent patch. For this patch the intention was to leave the name as-is so that it is easier to track the changes that were made. Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a Signed-off-by: Paul Beesley <paul.beesley@arm.com>
5 years ago
ifeq (${SPM_MM},1)
ifeq (${EL3_EXCEPTION_HANDLING},0)
spm: Remove SPM Alpha 1 prototype and support files The Secure Partition Manager (SPM) prototype implementation is being removed. This is preparatory work for putting in place a dispatcher component that, in turn, enables partition managers at S-EL2 / S-EL1. This patch removes: - The core service files (std_svc/spm) - The Resource Descriptor headers (include/services) - SPRT protocol support and service definitions - SPCI protocol support and service definitions Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426 Signed-off-by: Paul Beesley <paul.beesley@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com>
5 years ago
$(error EL3_EXCEPTION_HANDLING must be 1 for SPM-MM support)
SPM: Deprecate the current implementation The current SPM is a prototype that only supports one secure partition in EL0. The objective of SPM is to have multiple partitions. The current MM interface isn't adequate for this, so it is needed to modify heavily the code to add proper support for it. However, there are platforms which are already using this (like SGI) and removing the code would break it. For this reason, the current SPM code has been duplicated in order to temporarily preserve compatibility. All new improvements/changes to SPM will be done in the non-deprecated copy, that may change without notice. The new build option SPM_DEPRECATED has been introduced to select the SPM implementation. It defaults to 1, that selects the deprecated SPM. Change-Id: Ic9f80b53b450e97b4d3f47e4ef4a138ee8d87443 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
6 years ago
else
Remove dependency between SPM_MM and ENABLE_SPM build flags There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the other is based on the Secure Partition Client Interface (SPCI) specification. Currently there is a dependency between their build flags that shouldn't exist, making further development harder than it should be. This patch removes that dependency, making the two flags function independently. Before: ENABLE_SPM=1 is required for using either implementation. By default, the SPCI-based implementation is enabled and this is overridden if SPM_MM=1. After: ENABLE_SPM=1 enables the SPCI-based implementation. SPM_MM=1 enables the MM-based implementation. The two build flags are mutually exclusive. Note that the name of the ENABLE_SPM flag remains a bit ambiguous - this will be improved in a subsequent patch. For this patch the intention was to leave the name as-is so that it is easier to track the changes that were made. Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a Signed-off-by: Paul Beesley <paul.beesley@arm.com>
5 years ago
$(info Including SPM Management Mode (MM) makefile)
refactor(spm_mm): reorganize secure partition manager code In preparation for adding the EL3 SPMC configuration as defined in the FF-A specification, restructure the existing SPM_MM code. With this restructuring of the code, the 'spm_mm' directory is renamed as 'spm' and the code inside has been split into two sub-directories named 'common' and 'spm_mm'. The code in 'spm_mm' directory contains the code that implements the MM interface. In subsequent patches, the 'spmc' directory will be introduced under the 'spm' directory providing the code that implements the 'FF-A' interface. Currently the common functionality for S-EL1 partitions is limited to assembler functions to enter and exit an SP synchronously. Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Change-Id: I37739b9b53bc68e151ab5c1c0c6a15b3ee362241
3 years ago
include services/std_svc/spm/common/spm.mk
include services/std_svc/spm/spm_mm/spm_mm.mk
SPM: Deprecate the current implementation The current SPM is a prototype that only supports one secure partition in EL0. The objective of SPM is to have multiple partitions. The current MM interface isn't adequate for this, so it is needed to modify heavily the code to add proper support for it. However, there are platforms which are already using this (like SGI) and removing the code would break it. For this reason, the current SPM code has been duplicated in order to temporarily preserve compatibility. All new improvements/changes to SPM will be done in the non-deprecated copy, that may change without notice. The new build option SPM_DEPRECATED has been introduced to select the SPM implementation. It defaults to 1, that selects the deprecated SPM. Change-Id: Ic9f80b53b450e97b4d3f47e4ef4a138ee8d87443 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
6 years ago
endif
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>
7 years ago
endif
build(amu): introduce `amu.mk` This change introduces the `amu.mk` Makefile, used to remove the need to manually include AMU sources into the various build images. Makefiles requiring the list of AMU sources are expected to include this file and use `${AMU_SOURCES}` to retrieve them. Change-Id: I3d174033ecdce6439a110d776f0c064c67abcfe0 Signed-off-by: Chris Kay <chris.kay@arm.com>
4 years ago
include lib/extensions/amu/amu.mk
feat(mpmm): add support for MPMM MPMM - the Maximum Power Mitigation Mechanism - is an optional microarchitectural feature present on some Armv9-A cores, introduced with the Cortex-X2, Cortex-A710 and Cortex-A510 cores. MPMM allows the SoC firmware to detect and limit high activity events to assist in SoC processor power domain dynamic power budgeting and limit the triggering of whole-rail (i.e. clock chopping) responses to overcurrent conditions. This feature is enabled via the `ENABLE_MPMM` build option. Configuration can be done via FCONF by enabling `ENABLE_MPMM_FCONF`, or by via the plaform-implemented `plat_mpmm_topology` function. Change-Id: I77da82808ad4744ece8263f0bf215c5a091c3167 Signed-off-by: Chris Kay <chris.kay@arm.com>
4 years ago
include lib/mpmm/mpmm.mk
feat(spmc): enable building of the SPMC at EL3 Introduce build flag for enabling the secure partition manager core, SPMC_AT_EL3. When enabled, the SPMC module will be included into the BL31 image. By default the flag is disabled. Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Change-Id: I5ea1b953e5880a07ffc91c4dea876a375850cf2a
3 years ago
ifeq (${SPMC_AT_EL3},1)
$(warning "EL3 SPMC is an experimental feature")
$(info Including EL3 SPMC makefile)
include services/std_svc/spm/common/spm.mk
include services/std_svc/spm/el3_spmc/spmc.mk
endif
Introduce `el3_runtime` and `PSCI` libraries This patch moves the PSCI services and BL31 frameworks like context management and per-cpu data into new library components `PSCI` and `el3_runtime` respectively. This enables PSCI to be built independently from BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant PSCI library sources and gets included by `bl31.mk`. Other changes which are done as part of this patch are: * The runtime services framework is now moved to the `common/` folder to enable reuse. * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture specific folder. * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder to `plat/common` folder. The original file location now has a stub which just includes the file from new location to maintain platform compatibility. Most of the changes wouldn't affect platform builds as they just involve changes to the generic bl1.mk and bl31.mk makefiles. NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION. Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
9 years ago
include lib/psci/psci_lib.mk
Remove vpath usage in makefiles Remove all usage of the vpath keyword in makefiles as it was prone to mistakes. Specify the relative paths to source files instead. Also reorder source files in makefiles alphabetically. Fixes ARM-software/tf-issues#121 Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
11 years ago
BL31_SOURCES += bl31/bl31_main.c \
Introduce interrupt registration framework in BL3-1 This patch introduces a framework for registering interrupts routed to EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and FIQ bits and the security state an interrupt is generated in. The framework recognizes three type of interrupts depending upon which exception level and security state they should be handled in i.e. Secure EL1 interrupts, Non-secure interrupts and EL3 interrupts. It provides an API and macros that allow a runtime service to register an handler for a type of interrupt and specify the routing model. The framework validates the routing model and uses the context management framework to ensure that it is applied to the SCR_EL3 prior to entry into the target security state. It saves the handler in internal data structures. An API is provided to retrieve the handler when an interrupt of a particular type is asserted. Registration is expected to be done once by the primary CPU. The same handler and routing model is used for all CPUs. Support for EL3 interrupts will be added to the framework in the future. A makefile flag has been added to allow the FVP port choose between ARM GIC v2 and v3 support in EL3. The latter version is currently unsupported. A framework for handling interrupts in BL3-1 will be introduced in subsequent patches. The default routing model in the absence of any handlers expects no interrupts to be routed to EL3. Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
11 years ago
bl31/interrupt_mgmt.c \
Remove vpath usage in makefiles Remove all usage of the vpath keyword in makefiles as it was prone to mistakes. Specify the relative paths to source files instead. Also reorder source files in makefiles alphabetically. Fixes ARM-software/tf-issues#121 Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
11 years ago
bl31/aarch64/bl31_entrypoint.S \
Remove early_exceptions from BL3-1 The crash reporting support and early initialisation of the cpu_data allow the runtime_exception vectors to be used from the start in BL3-1, removing the need for the additional early_exception vectors and 2KB of code from BL3-1. Change-Id: I5f8997dabbaafd8935a7455910b7db174a25d871
11 years ago
bl31/aarch64/crash_reporting.S \
RAS: Move EA handling to a separate file A new file ea_delegate.S is introduced, and all EA-related functions are moved into it. This makes runtime_exceptions.S less crowded and reads better. No functional changes. Change-Id: I64b653b3931984cffd420563f8e8d1ba263f329f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
6 years ago
bl31/aarch64/ea_delegate.S \
BL31: Introduce jump primitives This patch introduces setjmp() and ongjmp() primitives to enable standard setjmp/longjmp style execution. Both APIs parameters take a pointer to struct jmpbuf type, which hosts CPU registers saved/restored during jump. As per the standard usage: - setjmp() return 0 when a jump is setup; and a non-zero value when returning from jump. - The caller of setjmp() must not return, or otherwise update stack pointer since. Change-Id: I4af1d32e490cfa547979631b762b4cba188d0551 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
bl31/aarch64/runtime_exceptions.S \
Move context management code to common location The upcoming Firmware Update feature needs transitioning across Secure/Normal worlds to complete the FWU process and hence requires context management code to perform this task. Currently context management code is part of BL31 stage only. This patch moves the code from (include)/bl31 to (include)/common. Some function declarations/definitions and macros have also moved to different files to help code sharing. Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
9 years ago
bl31/bl31_context_mgmt.c \
feat(el3-runtime): introduce system register trap handler At the moment we only handle SMC traps from lower ELs, but ignore any other synchronous traps and just panic. To cope with system register traps, which we might need to emulate, introduce a C function to handle those traps, and wire that up in the exception handler to be called. We provide a dispatcher function (in C), that will call platform specific implementation for certain (classes of) system registers. For now this is empty. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Change-Id: If147bcb49472eb02791498700300926afbcf75ff
2 years ago
bl31/bl31_traps.c \
Introduce `el3_runtime` and `PSCI` libraries This patch moves the PSCI services and BL31 frameworks like context management and per-cpu data into new library components `PSCI` and `el3_runtime` respectively. This enables PSCI to be built independently from BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant PSCI library sources and gets included by `bl31.mk`. Other changes which are done as part of this patch are: * The runtime services framework is now moved to the `common/` folder to enable reuse. * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture specific folder. * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder to `plat/common` folder. The original file location now has a stub which just includes the file from new location to maintain platform compatibility. Most of the changes wouldn't affect platform builds as they just involve changes to the generic bl1.mk and bl31.mk makefiles. NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION. Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
9 years ago
common/runtime_svc.c \
DSU erratum 936184 workaround If the system is in near idle conditions, this erratum could cause a deadlock or data corruption. This patch applies the workaround that prevents this. This DSU erratum affects only the DSUs that contain the ACP interface and it was fixed in r2p0. The workaround is applied only to the DSUs that are actually affected. Link to respective Arm documentation: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.epm138168/index.html Change-Id: I033213b3077685130fc1e3f4f79c4d15d7483ec9 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
6 years ago
lib/cpus/aarch64/dsu_helpers.S \
Move plat/common source file definitions to generic Makefiles These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
8 years ago
plat/common/aarch64/platform_mp_stack.S \
Implement support for SMCCC v1.1 SMCCC v1.1 comes with a relaxed calling convention for AArch64 callers. The caller only needs to save x0-x3 before doing an SMC call. This patch adds support for SMCCC_VERSION and SMCCC_ARCH_FEATURES. Refer to "Firmware Interfaces for mitigating CVE_2017_5715 System Software on Arm Systems"[0] for more information. [0] https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf Change-Id: If5b1c55c17d6c5c7cb9c2c3ed355d3a91cdad0a9 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
7 years ago
services/arm_arch_svc/arm_arch_svc_setup.c \
Remove vpath usage in makefiles Remove all usage of the vpath keyword in makefiles as it was prone to mistakes. Specify the relative paths to source files instead. Also reorder source files in makefiles alphabetically. Fixes ARM-software/tf-issues#121 Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
11 years ago
services/std_svc/std_svc_setup.c \
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>
7 years ago
${PSCI_LIB_SOURCES} \
SPMD: enable SPM dispatcher support This patch adds support to the build system to include support for the SPM dispatcher when the SPD configuration option is spmd. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Ic1ae50ecd7403fcbcf1d318abdbd6ebdc642f732
5 years ago
${SPMD_SOURCES} \
refactor(spm_mm): reorganize secure partition manager code In preparation for adding the EL3 SPMC configuration as defined in the FF-A specification, restructure the existing SPM_MM code. With this restructuring of the code, the 'spm_mm' directory is renamed as 'spm' and the code inside has been split into two sub-directories named 'common' and 'spm_mm'. The code in 'spm_mm' directory contains the code that implements the MM interface. In subsequent patches, the 'spmc' directory will be introduced under the 'spm' directory providing the code that implements the 'FF-A' interface. Currently the common functionality for S-EL1 partitions is limited to assembler functions to enter and exit an SP synchronously. Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Change-Id: I37739b9b53bc68e151ab5c1c0c6a15b3ee362241
3 years ago
${SPM_MM_SOURCES} \
feat(spmc): enable building of the SPMC at EL3 Introduce build flag for enabling the secure partition manager core, SPMC_AT_EL3. When enabled, the SPMC module will be included into the BL31 image. By default the flag is disabled. Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Change-Id: I5ea1b953e5880a07ffc91c4dea876a375850cf2a
3 years ago
${SPMC_SOURCES} \
BL31: Introduce jump primitives This patch introduces setjmp() and ongjmp() primitives to enable standard setjmp/longjmp style execution. Both APIs parameters take a pointer to struct jmpbuf type, which hosts CPU registers saved/restored during jump. As per the standard usage: - setjmp() return 0 when a jump is setup; and a non-zero value when returning from jump. - The caller of setjmp() must not return, or otherwise update stack pointer since. Change-Id: I4af1d32e490cfa547979631b762b4cba188d0551 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
${SPM_SOURCES}
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>
7 years ago
Add support for FEAT_MTPMU for Armv8.6 If FEAT_PMUv3 is implemented and PMEVTYPER<n>(_EL0).MT bit is implemented as well, it is possible to control whether PMU counters take into account events happening on other threads. If FEAT_MTPMU is implemented, EL3 (or EL2) can override the MT bit leaving it to effective state of 0 regardless of any write to it. This patch introduces the DISABLE_MTPMU flag, which allows to diable multithread event count from EL3 (or EL2). The flag is disabled by default so the behavior is consistent with those architectures that do not implement FEAT_MTPMU. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: Iee3a8470ae8ba13316af1bd40c8d4aa86e0cb85e
4 years ago
ifeq (${DISABLE_MTPMU},1)
BL31_SOURCES += lib/extensions/mtpmu/aarch64/mtpmu.S
endif
Move bakery algorithm implementation out of coherent memory This patch moves the bakery locks out of coherent memory to normal memory. This implies that the lock information needs to be placed on a separate cache line for each cpu. Hence the bakery_lock_info_t structure is allocated in the per-cpu data so as to minimize memory wastage. A similar platform per-cpu data is introduced for the platform locks. As a result of the above changes, the bakery lock api is completely changed. Earlier, a reference to the lock structure was passed to the lock implementation. Now a unique-id (essentially an index into the per-cpu data array) and an offset into the per-cpu data for bakery_info_t needs to be passed to the lock implementation. Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
10 years ago
Add Performance Measurement Framework(PMF) This patch adds Performance Measurement Framework(PMF) in the ARM Trusted Firmware. PMF is implemented as a library and the SMC interface is provided through ARM SiP service. The PMF provides capturing, storing, dumping and retrieving the time-stamps, by enabling the development of services by different providers, that can be easily integrated into ARM Trusted Firmware. The PMF capture and retrieval APIs can also do appropriate cache maintenance operations to the timestamp memory when the caller indicates so. `pmf_main.c` consists of core functions that implement service registration, initialization, storing, dumping and retrieving the time-stamp. `pmf_smc.c` consists SMC handling for registered PMF services. `pmf.h` consists of the macros that can be used by the PMF service providers to register service and declare time-stamp functions. `pmf_helpers.h` consists of internal macros that are used by `pmf.h` By default this feature is disabled in the ARM trusted firmware. To enable it set the boolean flag `ENABLE_PMF` to 1. NOTE: The caller is responsible for specifying the appropriate cache maintenance flags and for acquiring/releasing appropriate locks before/after capturing/retrieving the time-stamps. Change-Id: Ib45219ac07c2a81b9726ef6bd9c190cc55e81854
9 years ago
ifeq (${ENABLE_PMF}, 1)
BL31_SOURCES += lib/pmf/pmf_main.c
endif
debugfs: add 9p device interface The 9p interface provides abstraction layers allowing the software that uses devices to be independent from the hardware. This patch provides a file system abstraction to link drivers to their devices and propose a common interface to expose driver operations to higher layers. This file system can be used to access and configure a device by doing read/write operations. Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Change-Id: Ia9662393baf489855dc0c8f389fe4a0afbc9c255
5 years ago
include lib/debugfs/debugfs.mk
ifeq (${USE_DEBUGFS},1)
BL31_SOURCES += $(DEBUGFS_SRCS)
endif
BL31: Introduce Exception Handling Framework EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3. This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs. The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller. This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns. Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1. Documentation to follow. NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later). Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
ifeq (${EL3_EXCEPTION_HANDLING},1)
BL31_SOURCES += bl31/ehf.c
endif
BL31: Add SDEI dispatcher The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
ifeq (${SDEI_SUPPORT},1)
ifeq (${EL3_EXCEPTION_HANDLING},0)
$(error EL3_EXCEPTION_HANDLING must be 1 for SDEI support)
endif
SDEI: Make dispatches synchronous SDEI event dispatches currently only sets up the Non-secure context before returning to the caller. The actual dispatch only happens upon exiting EL3 next time. However, for various error handling scenarios, it's beneficial to have the dispatch happen synchronously. I.e. when receiving SDEI interrupt, or for a successful sdei_dispatch_event() call, the event handler is executed; and upon the event completion, dispatcher execution resumes after the point of dispatch. The jump primitives introduced in the earlier patch facilitates this feature. With this patch: - SDEI interrupts and calls to sdei_dispatch_event prepares the NS context for event dispatch, then sets a jump point, and immediately exits EL3. This results in the client handler executing in Non-secure. - When the SDEI client completes the dispatched event, the SDEI dispatcher does a longjmp to the jump pointer created earlier. For the caller of the sdei_dispatch_event() in particular, this would appear as if call returned successfully. The dynamic workaround for CVE_2018_3639 is slightly shifted around as part of related minor refactoring. It doesn't affect the workaround functionality. Documentation updated. NOTE: This breaks the semantics of the explicit dispatch API, and any exiting usages should be carefully reviewed. Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
BL31_SOURCES += services/std_svc/sdei/sdei_dispatch.S \
services/std_svc/sdei/sdei_event.c \
BL31: Add SDEI dispatcher The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
7 years ago
services/std_svc/sdei/sdei_intr_mgmt.c \
services/std_svc/sdei/sdei_main.c \
services/std_svc/sdei/sdei_state.c
endif
Add TRNG Firmware Interface service This adds the TRNG Firmware Interface Service to the standard service dispatcher. This includes a method for dispatching entropy requests to platforms and includes an entropy pool implementation to avoid dropping any entropy requested from the platform. Change-Id: I71cadb3cb377a507652eca9e0d68714c973026e9 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
4 years ago
ifeq (${TRNG_SUPPORT},1)
BL31_SOURCES += services/std_svc/trng/trng_main.c \
services/std_svc/trng/trng_entropy_pool.c
endif
Refactor Statistical Profiling Extensions implementation Factor out SPE operations in a separate file. Use the publish subscribe framework to drain the SPE buffers before entering secure world. Additionally, enable SPE before entering normal world. A side effect of this change is that the profiling buffers are now only drained when a transition from normal world to secure world happens. Previously they were drained also on return from secure world, which is unnecessary as SPE is not supported in S-EL1. Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
7 years ago
ifeq (${ENABLE_SPE_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/spe/spe.c
endif
AMU: Implement support for aarch64 The `ENABLE_AMU` build option can be used to enable the architecturally defined AMU counters. At present, there is no support for the auxiliary counter group. Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
7 years ago
ifeq (${ENABLE_AMU},1)
build(amu): introduce `amu.mk` This change introduces the `amu.mk` Makefile, used to remove the need to manually include AMU sources into the various build images. Makefiles requiring the list of AMU sources are expected to include this file and use `${AMU_SOURCES}` to retrieve them. Change-Id: I3d174033ecdce6439a110d776f0c064c67abcfe0 Signed-off-by: Chris Kay <chris.kay@arm.com>
4 years ago
BL31_SOURCES += ${AMU_SOURCES}
AMU: Implement support for aarch64 The `ENABLE_AMU` build option can be used to enable the architecturally defined AMU counters. At present, there is no support for the auxiliary counter group. Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
7 years ago
endif
feat(mpmm): add support for MPMM MPMM - the Maximum Power Mitigation Mechanism - is an optional microarchitectural feature present on some Armv9-A cores, introduced with the Cortex-X2, Cortex-A710 and Cortex-A510 cores. MPMM allows the SoC firmware to detect and limit high activity events to assist in SoC processor power domain dynamic power budgeting and limit the triggering of whole-rail (i.e. clock chopping) responses to overcurrent conditions. This feature is enabled via the `ENABLE_MPMM` build option. Configuration can be done via FCONF by enabling `ENABLE_MPMM_FCONF`, or by via the plaform-implemented `plat_mpmm_topology` function. Change-Id: I77da82808ad4744ece8263f0bf215c5a091c3167 Signed-off-by: Chris Kay <chris.kay@arm.com>
4 years ago
ifeq (${ENABLE_MPMM},1)
BL31_SOURCES += ${MPMM_SOURCES}
endif
feat(sme): enable SME functionality This patch adds two new compile time options to enable SME in TF-A: ENABLE_SME_FOR_NS and ENABLE_SME_FOR_SWD for use in non-secure and secure worlds respectively. Setting ENABLE_SME_FOR_NS=1 will enable SME for non-secure worlds and trap SME, SVE, and FPU/SIMD instructions in secure context. Setting ENABLE_SME_FOR_SWD=1 will disable these traps, but support for SME context management does not yet exist in SPM so building with SPD=spmd will fail. The existing ENABLE_SVE_FOR_NS and ENABLE_SVE_FOR_SWD options cannot be used with SME as it is a superset of SVE and will enable SVE and FPU/SIMD along with SME. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: Iaaac9d22fe37b4a92315207891da848a8fd0ed73
3 years ago
ifeq (${ENABLE_SME_FOR_NS},1)
BL31_SOURCES += lib/extensions/sme/sme.c
BL31_SOURCES += lib/extensions/sve/sve.c
else
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>
7 years ago
ifeq (${ENABLE_SVE_FOR_NS},1)
BL31_SOURCES += lib/extensions/sve/sve.c
endif
feat(sme): enable SME functionality This patch adds two new compile time options to enable SME in TF-A: ENABLE_SME_FOR_NS and ENABLE_SME_FOR_SWD for use in non-secure and secure worlds respectively. Setting ENABLE_SME_FOR_NS=1 will enable SME for non-secure worlds and trap SME, SVE, and FPU/SIMD instructions in secure context. Setting ENABLE_SME_FOR_SWD=1 will disable these traps, but support for SME context management does not yet exist in SPM so building with SPD=spmd will fail. The existing ENABLE_SVE_FOR_NS and ENABLE_SVE_FOR_SWD options cannot be used with SME as it is a superset of SVE and will enable SVE and FPU/SIMD along with SME. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: Iaaac9d22fe37b4a92315207891da848a8fd0ed73
3 years ago
endif
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>
7 years ago
AArch64: Enable MPAM for lower ELs Memory Partitioning And Monitoring is an Armv8.4 feature that enables various memory system components and resources to define partitions. Software running at various ELs can then assign themselves to the desired partition to control their performance aspects. With this patch, when ENABLE_MPAM_FOR_LOWER_ELS is set to 1, EL3 allows lower ELs to access their own MPAM registers without trapping to EL3. This patch however doesn't make use of partitioning in EL3; platform initialisation code should configure and use partitions in EL3 if required. Change-Id: I5a55b6771ccaa0c1cffc05543d2116b60cbbcdcd Co-authored-by: James Morse <james.morse@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
6 years ago
ifeq (${ENABLE_MPAM_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/mpam/mpam.c
endif
feat(trbe): enable access to trace buffer control registers from lower NS EL Introduced a build flag 'ENABLE_TRBE_FOR_NS' to enable trace buffer control registers access in NS-EL2, or NS-EL1 (when NS-EL2 is implemented but unused). Change-Id: I285a672ccd395eebd377714c992bb21062a729cc Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
3 years ago
ifeq (${ENABLE_TRBE_FOR_NS},1)
BL31_SOURCES += lib/extensions/trbe/trbe.c
endif
feat(brbe): add BRBE support for NS world This patch enables access to the branch record buffer control registers in non-secure EL2 and EL1 using the new build option ENABLE_BRBE_FOR_NS. It is disabled for all secure world, and cannot be used with ENABLE_RME. This option is disabled by default, however, the FVP platform makefile enables it for FVP builds. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I576a49d446a8a73286ea6417c16bd0b8de71fca0
3 years ago
ifeq (${ENABLE_BRBE_FOR_NS},1)
BL31_SOURCES += lib/extensions/brbe/brbe.c
endif
feat(sys_reg_trace): enable trace system registers access from lower NS ELs Introduced a build flag 'ENABLE_SYS_REG_TRACE_FOR_NS' to enable trace system registers access in NS-EL2, or NS-EL1 (when NS-EL2 is implemented but unused). Change-Id: Idc1acede4186e101758cbf7bed5af7b634d7d18d Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
3 years ago
ifeq (${ENABLE_SYS_REG_TRACE_FOR_NS},1)
BL31_SOURCES += lib/extensions/sys_reg_trace/aarch64/sys_reg_trace.c
endif
feat(trf): enable trace filter control register access from lower NS EL Introduced a build flag 'ENABLE_TRF_FOR_NS' to enable trace filter control registers access in NS-EL2, or NS-EL1 (when NS-EL2 is implemented but unused). Change-Id: If3f53b8173a5573424b9a405a4bd8c206ffdeb8c Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
3 years ago
ifeq (${ENABLE_TRF_FOR_NS},1)
BL31_SOURCES += lib/extensions/trf/aarch64/trf.c
endif
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>
7 years ago
ifeq (${WORKAROUND_CVE_2017_5715},1)
Rename symbols and files relating to CVE-2017-5715 This patch renames symbols and files relating to CVE-2017-5715 to make it easier to introduce new symbols and files for new CVE mitigations. Change-Id: I24c23822862ca73648c772885f1690bed043dbc7 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
7 years ago
BL31_SOURCES += lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S \
lib/cpus/aarch64/wa_cve_2017_5715_mmu.S
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>
7 years ago
endif
SMCCC/PCI: Handle std svc boilerplate Add SMC wrappers for handshaking the existence and basic parameter validation for the SMCCC/PCI API. The actual read/write/segment validation is implemented by a given platform which will enable the API by defining SMC_PCI_SUPPORT. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Change-Id: I4485ad0fe6003cec6f5eedef688914d100513c21
4 years ago
ifeq ($(SMC_PCI_SUPPORT),1)
BL31_SOURCES += services/std_svc/pci_svc.c
endif
feat(rme): add RMM dispatcher (RMMD) This patch introduces the RMM dispatcher into BL31. This will be the mechanism that will enable communication to take place between the Realm and non-secure world. Currently gives the capability for granules to be transitioned from non-secure type to realm and vice versa. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Signed-off-by: Subhasish Ghosh <subhasish.ghosh@arm.com> Change-Id: I1fdc99a4bdd42bc14911aa0c6954b131de309511
3 years ago
ifeq (${ENABLE_RME},1)
refactor(gpt): productize and refactor GPT library This patch updates and refactors the GPT library and fixes bugs. - Support all combinations of PGS, PPS, and L0GPTSZ parameters. - PPS and PGS are set at runtime, L0GPTSZ is read from GPCCR_EL3. - Use compiler definitions to simplify code. - Renaming functions to better suit intended uses. - MMU enabled before GPT APIs called. - Add comments to make function usage more clear in GPT library. - Added _rme suffix to file names to differentiate better from the GPT file system code. - Renamed gpt_defs.h to gpt_rme_private.h to better separate private and public code. - Renamed gpt_core.c to gpt_rme.c to better conform to TF-A precedent. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I4cbb23b0f81e697baa9fb23ba458aa3f7d1ed919
3 years ago
include lib/gpt_rme/gpt_rme.mk
feat(rme): add GPT Library This patch introduces the Granule Protection Table (GPT) library code. This implementation will be updated later to be more flexible, as the current implementation is very rigid. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I3af824a28c6e9a5d36459c0c51d2d9bebfba1505
3 years ago
BL31_SOURCES += ${GPT_LIB_SRCS} \
${RMMD_SOURCES}
feat(rme): add RMM dispatcher (RMMD) This patch introduces the RMM dispatcher into BL31. This will be the mechanism that will enable communication to take place between the Realm and non-secure world. Currently gives the capability for granules to be transitioned from non-secure type to realm and vice versa. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Signed-off-by: Subhasish Ghosh <subhasish.ghosh@arm.com> Change-Id: I1fdc99a4bdd42bc14911aa0c6954b131de309511
3 years ago
endif
refactor(el3-runtime): add arch-features detection mechanism This patch adds architectural features detection procedure to ensure features enabled are present in the given hardware implementation. It verifies whether the architecture build flags passed during compilation match the respective features by reading their ID registers. It reads through all the enabled feature specific ID registers at once and panics in case of mismatch(feature enabled but not implemented in PE). Feature flags are used at sections (context_management, save and restore routines of registers) during context switch. If the enabled feature flag is not supported by the PE, it causes an exception while saving or restoring the registers guarded by them. With this mechanism, the build flags are validated at an early phase prior to their usage, thereby preventing any undefined action under their control. This implementation is based on tristate approach for each feature and currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this patch. FEAT_STATE=2 is planned for phase-2 implementation and will be taken care separately. The patch has been explicitly tested, by adding a new test_config with build config enabling majority of the features and detected all of them under FVP launched with parameters enabling v8.7 features. Note: This is an experimental procedure and the mechanism itself is guarded by a macro "FEATURE_DETECTION", which is currently being disabled by default. The "FEATURE_DETECTION" macro is documented and the platforms are encouraged to make use of this diagnostic tool by enabling this "FEATURE_DETECTION" flag explicitly and get used to its behaviour during booting before the procedure gets mandated. Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
3 years ago
ifeq ($(FEATURE_DETECTION),1)
BL31_SOURCES += common/feat_detect.c
endif
feat(drtm): add standard DRTM service Added a dummy DRTM setup function and also, introduced DRTM SMCs handling as per DRTM spec [1]. Few basic SMCs are handled in this change such as ARM_DRTM_SVC_VERSION and ARM_DRTM_SVC_FEATURES that returns DRTM version and functions ids supported respectively, and others are dummy for now. [1]: https://developer.arm.com/documentation/den0113/latest Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com> Signed-off-by: Lucian Paul-Trifu <lucian.paultrifu@gmail.com> Change-Id: I8c7afe920c78e064cbab2298f59e6837c70ba8ff
3 years ago
ifeq (${DRTM_SUPPORT},1)
feat(drtm): add platform functions for DRTM Added platform hooks to retrieve DRTM features and address map. Additionally, implemented these hooks for the FVP platform. Signed-off-by: John Powell <john.powell@arm.com> Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I5621cc9807ffff8139ae8876250147f7b2c76759
3 years ago
BL31_SOURCES += services/std_svc/drtm/drtm_main.c \
services/std_svc/drtm/drtm_dma_prot.c \
services/std_svc/drtm/drtm_res_address_map.c \
feat(drtm): add Event Log driver support for DRTM Added Event Log driver support for DRTM. This driver is responsible for the doing the hash measurement of various DRTM components as per [1], and putting these measurements in the Event Log buffer. [1]: https://developer.arm.com/documentation/den0113/a, section 3.16 Change-Id: I9892c313cf6640b82e261738116fe00f7975ee12 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2 years ago
services/std_svc/drtm/drtm_measurements.c \
feat(drtm): add remediation driver support in DRTM Added remediation driver for DRTM to set/get the error from non-volatile memory Change-Id: I8f0873dcef4936693e0f39a3c95096cb689c04b7 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Signed-off-by: Lucian Paul-Trifu <lucian.paultrifu@gmail.com>
2 years ago
services/std_svc/drtm/drtm_remediation.c \
feat(mbedtls): update mbedTLS driver for DRTM support Updated mbedTLS driver to include mbedTLS functions necessary for a DRTM supported build. Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com> Change-Id: If0120374a971519cf84f93e0c59e1a320a72cd97
3 years ago
${MBEDTLS_SOURCES}
feat(drtm): add standard DRTM service Added a dummy DRTM setup function and also, introduced DRTM SMCs handling as per DRTM spec [1]. Few basic SMCs are handled in this change such as ARM_DRTM_SVC_VERSION and ARM_DRTM_SVC_FEATURES that returns DRTM version and functions ids supported respectively, and others are dummy for now. [1]: https://developer.arm.com/documentation/den0113/latest Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com> Signed-off-by: Lucian Paul-Trifu <lucian.paultrifu@gmail.com> Change-Id: I8c7afe920c78e064cbab2298f59e6837c70ba8ff
3 years ago
endif
Remove vpath usage in makefiles Remove all usage of the vpath keyword in makefiles as it was prone to mistakes. Specify the relative paths to source files instead. Also reorder source files in makefiles alphabetically. Fixes ARM-software/tf-issues#121 Change-Id: Id15f60655444bae60e0e2165259efac71a50928b
11 years ago
BL31_LINKERFILE := bl31/bl31.ld.S
Introduce interrupt handling framework in BL3-1 This patch adds a common handler for FIQ and IRQ exceptions in the BL3-1 runtime exception vector table. This function determines the interrupt type and calls its handler. A crash is reported if an inconsistency in the interrupt management framework is detected. In the event of a spurious interrupt, execution resumes from the instruction where the interrupt was generated. This patch also removes 'cm_macros.S' as its contents have been moved to 'runtime_exceptions.S' Change-Id: I3c85ecf8eaf43a3fac429b119ed0bd706d2e2093
11 years ago
Miscellaneous doc fixes for v1.2 Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b
9 years ago
# Flag used to indicate if Crash reporting via console should be included
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
9 years ago
# in BL31. This defaults to being present in DEBUG builds only
Make the BL3-1 crash reporting optional This patch makes the console crash dump of processor register state optional based on the CRASH_REPORTING make variable. This defaults to only being enabled for DEBUG builds. This can be overridden by setting a different value in the platform makefile or on the make command line. Change-Id: Icfa1b2d7ff0145cf0a85e8ad732f9cee7e7e993f
11 years ago
ifndef CRASH_REPORTING
CRASH_REPORTING := $(DEBUG)
endif
build_macros.mk: include assert and define loop macros Loop macros make it easier for developers to include new variables to assert or define and also help code code readability on makefiles. Change-Id: I0d21d6e67b3eca8976c4d856ac8ccc02c8bb5ffa Signed-off-by: Leonardo Sandoval <leonardo.sandoval@linaro.org>
4 years ago
$(eval $(call assert_booleans,\
$(sort \
CRASH_REPORTING \
EL3_EXCEPTION_HANDLING \
SDEI_SUPPORT \
)))
$(eval $(call add_defines,\
$(sort \
CRASH_REPORTING \
EL3_EXCEPTION_HANDLING \
SDEI_SUPPORT \
)))