arm-trusted-firmware/bl31/bl31.mk

171 lines
4.1 KiB
Makefile
Raw Permalink Normal View History

2013-10-25 09:08:21 +01:00
#
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
2022-01-17 18:57:17 +00:00
# Copyright (c) 2013-2022, ARM Limited and Contributors. All rights reserved.
2013-10-25 09:08:21 +01:00
#
# SPDX-License-Identifier: BSD-3-Clause
2013-10-25 09:08:21 +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
################################################################################
# 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>
2017-10-24 10:07:35 +01:00
################################################################################
ifeq (${SUPPORT_UNKNOWN_MPID},1)
ifeq (${DEBUG},0)
$(warning WARNING: SUPPORT_UNKNOWN_MPID enabled)
endif
endif
ifeq (${SPM_MM},1)
ifeq (${EL3_EXCEPTION_HANDLING},0)
$(error EL3_EXCEPTION_HANDLING must be 1 for SPM-MM support)
else
$(info Including SPM Management Mode (MM) makefile)
include services/std_svc/spm/common/spm.mk
include services/std_svc/spm/spm_mm/spm_mm.mk
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>
2017-10-24 10:07:35 +01:00
endif
include lib/extensions/amu/amu.mk
include lib/mpmm/mpmm.mk
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
include lib/psci/psci_lib.mk
BL31_SOURCES += bl31/bl31_main.c \
2014-05-09 10:03:15 +01:00
bl31/interrupt_mgmt.c \
bl31/aarch64/bl31_entrypoint.S \
bl31/aarch64/crash_reporting.S \
bl31/aarch64/ea_delegate.S \
bl31/aarch64/runtime_exceptions.S \
bl31/bl31_context_mgmt.c \
common/runtime_svc.c \
lib/cpus/aarch64/dsu_helpers.S \
plat/common/aarch64/platform_mp_stack.S \
services/arm_arch_svc/arm_arch_svc_setup.c \
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>
2017-10-24 10:07:35 +01:00
${PSCI_LIB_SOURCES} \
${SPMD_SOURCES} \
${SPM_MM_SOURCES} \
${SPMC_SOURCES} \
${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>
2017-10-24 10:07:35 +01:00
ifeq (${DISABLE_MTPMU},1)
BL31_SOURCES += lib/extensions/mtpmu/aarch64/mtpmu.S
endif
ifeq (${ENABLE_PMF}, 1)
BL31_SOURCES += lib/pmf/pmf_main.c
endif
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>
2017-09-22 08:32:10 +01:00
ifeq (${EL3_EXCEPTION_HANDLING},1)
BL31_SOURCES += bl31/ehf.c
endif
ifeq (${SDEI_SUPPORT},1)
ifeq (${EL3_EXCEPTION_HANDLING},0)
$(error EL3_EXCEPTION_HANDLING must be 1 for SDEI support)
endif
BL31_SOURCES += services/std_svc/sdei/sdei_dispatch.S \
services/std_svc/sdei/sdei_event.c \
services/std_svc/sdei/sdei_intr_mgmt.c \
services/std_svc/sdei/sdei_main.c \
services/std_svc/sdei/sdei_state.c
endif
ifeq (${TRNG_SUPPORT},1)
BL31_SOURCES += services/std_svc/trng/trng_main.c \
services/std_svc/trng/trng_entropy_pool.c
endif
ifeq (${ENABLE_SPE_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/spe/spe.c
endif
ifeq (${ENABLE_AMU},1)
BL31_SOURCES += ${AMU_SOURCES}
endif
ifeq (${ENABLE_MPMM},1)
BL31_SOURCES += ${MPMM_SOURCES}
endif
ifeq (${ENABLE_SME_FOR_NS},1)
BL31_SOURCES += lib/extensions/sme/sme.c
BL31_SOURCES += lib/extensions/sve/sve.c
else
ifeq (${ENABLE_SVE_FOR_NS},1)
BL31_SOURCES += lib/extensions/sve/sve.c
endif
endif
ifeq (${ENABLE_MPAM_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/mpam/mpam.c
endif
ifeq (${ENABLE_TRBE_FOR_NS},1)
BL31_SOURCES += lib/extensions/trbe/trbe.c
endif
ifeq (${ENABLE_BRBE_FOR_NS},1)
BL31_SOURCES += lib/extensions/brbe/brbe.c
endif
ifeq (${ENABLE_SYS_REG_TRACE_FOR_NS},1)
BL31_SOURCES += lib/extensions/sys_reg_trace/aarch64/sys_reg_trace.c
endif
ifeq (${ENABLE_TRF_FOR_NS},1)
BL31_SOURCES += lib/extensions/trf/aarch64/trf.c
endif
ifeq (${WORKAROUND_CVE_2017_5715},1)
BL31_SOURCES += lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S \
lib/cpus/aarch64/wa_cve_2017_5715_mmu.S
endif
ifeq ($(SMC_PCI_SUPPORT),1)
BL31_SOURCES += services/std_svc/pci_svc.c
endif
ifeq (${ENABLE_RME},1)
include lib/gpt_rme/gpt_rme.mk
BL31_SOURCES += ${GPT_LIB_SRCS} \
${RMMD_SOURCES}
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
2022-01-17 18:57:17 +00:00
ifeq ($(FEATURE_DETECTION),1)
BL31_SOURCES += common/feat_detect.c
endif
BL31_LINKERFILE := bl31/bl31.ld.S
# Flag used to indicate if Crash reporting via console should be included
# in BL31. This defaults to being present in DEBUG builds only
ifndef CRASH_REPORTING
CRASH_REPORTING := $(DEBUG)
endif
$(eval $(call assert_booleans,\
$(sort \
CRASH_REPORTING \
EL3_EXCEPTION_HANDLING \
SDEI_SUPPORT \
)))
$(eval $(call add_defines,\
$(sort \
CRASH_REPORTING \
EL3_EXCEPTION_HANDLING \
SDEI_SUPPORT \
)))