diff options
136 files changed, 3803 insertions, 3332 deletions
@@ -8,7 +8,7 @@ # Trusted Firmware Version # VERSION_MAJOR := 1 -VERSION_MINOR := 4 +VERSION_MINOR := 5 # Default goal is build all images .DEFAULT_GOAL := all @@ -374,6 +374,12 @@ ifeq ($(HW_ASSISTED_COHERENCY)-$(USE_COHERENT_MEM),1-1) $(error USE_COHERENT_MEM cannot be enabled with HW_ASSISTED_COHERENCY) endif +ifneq ($(MULTI_CONSOLE_API), 0) + ifeq (${ARCH},aarch32) + $(error "Error: MULTI_CONSOLE_API is not supported for AArch32") + endif +endif + ################################################################################ # Process platform overrideable behaviour ################################################################################ @@ -588,9 +594,9 @@ all: msg_start msg_start: @echo "Building ${PLAT}" -# Check if deprecated declarations should be treated as error or not. +# Check if deprecated declarations and cpp warnings should be treated as error or not. ifeq (${ERROR_DEPRECATED},0) - TF_CFLAGS += -Wno-error=deprecated-declarations + CPPFLAGS += -Wno-error=deprecated-declarations -Wno-error=cpp endif # Expand build macros for the different images diff --git a/bl1/aarch32/bl1_context_mgmt.c b/bl1/aarch32/bl1_context_mgmt.c index 6623dfc49..d1fd3ca00 100644 --- a/bl1/aarch32/bl1_context_mgmt.c +++ b/bl1/aarch32/bl1_context_mgmt.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -10,7 +10,7 @@ #include <context_mgmt.h> #include <debug.h> #include <platform.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include "../bl1_private.h" /* diff --git a/bl1/aarch32/bl1_entrypoint.S b/bl1/aarch32/bl1_entrypoint.S index 778062697..16b26b9f2 100644 --- a/bl1/aarch32/bl1_entrypoint.S +++ b/bl1/aarch32/bl1_entrypoint.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -9,8 +9,8 @@ #include <bl_common.h> #include <context.h> #include <el3_common_macros.S> -#include <smcc_helpers.h> -#include <smcc_macros.S> +#include <smccc_helpers.h> +#include <smccc_macros.S> .globl bl1_vector_table .globl bl1_entrypoint diff --git a/bl1/aarch32/bl1_exceptions.S b/bl1/aarch32/bl1_exceptions.S index a1e32f06f..154054245 100644 --- a/bl1/aarch32/bl1_exceptions.S +++ b/bl1/aarch32/bl1_exceptions.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -9,8 +9,8 @@ #include <bl1.h> #include <bl_common.h> #include <context.h> -#include <smcc_helpers.h> -#include <smcc_macros.S> +#include <smccc_helpers.h> +#include <smccc_macros.S> #include <xlat_tables.h> .globl bl1_aarch32_smc_handler @@ -93,7 +93,7 @@ func smc_handler * Save the GP registers. * ----------------------------------------------------- */ - smcc_save_gp_mode_regs + smccc_save_gp_mode_regs /* * `sp` still points to `smc_ctx_t`. Save it to a register diff --git a/bl1/aarch64/bl1_exceptions.S b/bl1/aarch64/bl1_exceptions.S index 92313fa31..7ac028a5c 100644 --- a/bl1/aarch64/bl1_exceptions.S +++ b/bl1/aarch64/bl1_exceptions.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -218,7 +218,7 @@ unexpected_sync_exception: smc_handler: /* ----------------------------------------------------- * Save the GP registers x0-x29. - * TODO: Revisit to store only SMCC specified registers. + * TODO: Revisit to store only SMCCC specified registers. * ----------------------------------------------------- */ bl save_gp_registers diff --git a/bl1/bl1_fwu.c b/bl1/bl1_fwu.c index 387808334..ed027abc7 100644 --- a/bl1/bl1_fwu.c +++ b/bl1/bl1_fwu.c @@ -15,7 +15,7 @@ #include <errno.h> #include <platform.h> #include <platform_def.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <string.h> #include <utils.h> #include "bl1_private.h" diff --git a/bl1/bl1_main.c b/bl1/bl1_main.c index c3332853b..9f7e2901f 100644 --- a/bl1/bl1_main.c +++ b/bl1/bl1_main.c @@ -15,7 +15,7 @@ #include <errata_report.h> #include <platform.h> #include <platform_def.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <utils.h> #include <uuid.h> #include "bl1_private.h" diff --git a/bl2/aarch32/bl2_el3_entrypoint.S b/bl2/aarch32/bl2_el3_entrypoint.S index 997b069cd..0c7b06455 100644 --- a/bl2/aarch32/bl2_el3_entrypoint.S +++ b/bl2/aarch32/bl2_el3_entrypoint.S @@ -78,6 +78,11 @@ func bl2_run_next_image ldr r1, [r8, #(ENTRY_POINT_INFO_PC_OFFSET + 4)] msr spsr, r1 + /* Some BL32 stages expect lr_svc to provide the BL33 entry address */ + cps #MODE32_svc + ldr lr, [r8, #ENTRY_POINT_INFO_LR_SVC_OFFSET] + cps #MODE32_mon + add r8, r8, #ENTRY_POINT_INFO_ARGS_OFFSET ldm r8, {r0, r1, r2, r3} eret diff --git a/bl31/bl31.mk b/bl31/bl31.mk index 886d3016f..0e47ddf68 100644 --- a/bl31/bl31.mk +++ b/bl31/bl31.mk @@ -61,8 +61,8 @@ BL31_SOURCES += lib/extensions/sve/sve.c endif ifeq (${WORKAROUND_CVE_2017_5715},1) -BL31_SOURCES += lib/cpus/aarch64/workaround_cve_2017_5715_mmu.S \ - lib/cpus/aarch64/workaround_cve_2017_5715_bpiall.S +BL31_SOURCES += lib/cpus/aarch64/workaround_cve_2017_5715_bpiall.S \ + lib/cpus/aarch64/workaround_cve_2017_5715_mmu.S endif BL31_LINKERFILE := bl31/bl31.ld.S diff --git a/bl31/bl31_context_mgmt.c b/bl31/bl31_context_mgmt.c index 123e623c5..7d2c89385 100644 --- a/bl31/bl31_context_mgmt.c +++ b/bl31/bl31_context_mgmt.c @@ -79,7 +79,13 @@ void *cm_get_context_by_mpidr(uint64_t mpidr, uint32_t security_state) { assert(sec_state_is_valid(security_state)); + /* + * Suppress deprecated declaration warning in compatibility function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" return cm_get_context_by_index(platform_get_core_pos(mpidr), security_state); +#pragma GCC diagnostic pop } /******************************************************************************* @@ -90,8 +96,14 @@ void cm_set_context_by_mpidr(uint64_t mpidr, void *context, uint32_t security_st { assert(sec_state_is_valid(security_state)); + /* + * Suppress deprecated declaration warning in compatibility function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" cm_set_context_by_index(platform_get_core_pos(mpidr), context, security_state); +#pragma GCC diagnostic pop } /******************************************************************************* @@ -104,7 +116,15 @@ void cm_init_context(uint64_t mpidr, const entry_point_info_t *ep) if ((mpidr & MPIDR_AFFINITY_MASK) == (read_mpidr_el1() & MPIDR_AFFINITY_MASK)) cm_init_my_context(ep); - else + else { + /* + * Suppress deprecated declaration warning in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" cm_init_context_by_index(platform_get_core_pos(mpidr), ep); +#pragma GCC diagnostic pop + } } -#endif +#endif /* ERROR_DEPRECATED */ diff --git a/bl32/sp_min/aarch32/entrypoint.S b/bl32/sp_min/aarch32/entrypoint.S index 3dd236962..87ef3f36e 100644 --- a/bl32/sp_min/aarch32/entrypoint.S +++ b/bl32/sp_min/aarch32/entrypoint.S @@ -10,8 +10,8 @@ #include <context.h> #include <el3_common_macros.S> #include <runtime_svc.h> -#include <smcc_helpers.h> -#include <smcc_macros.S> +#include <smccc_helpers.h> +#include <smccc_macros.S> #include <xlat_tables_defs.h> .globl sp_min_vector_table @@ -164,7 +164,7 @@ func sp_min_handle_smc /* On SMC entry, `sp` points to `smc_ctx_t`. Save `lr`. */ str lr, [sp, #SMC_CTX_LR_MON] - smcc_save_gp_mode_regs + smccc_save_gp_mode_regs clrex_on_monitor_entry @@ -222,7 +222,7 @@ func sp_min_handle_fiq /* On SMC entry, `sp` points to `smc_ctx_t`. Save `lr`. */ str lr, [sp, #SMC_CTX_LR_MON] - smcc_save_gp_mode_regs + smccc_save_gp_mode_regs clrex_on_monitor_entry diff --git a/bl32/sp_min/sp_min.mk b/bl32/sp_min/sp_min.mk index 145820e42..193b1d5ea 100644 --- a/bl32/sp_min/sp_min.mk +++ b/bl32/sp_min/sp_min.mk @@ -15,6 +15,7 @@ INCLUDES += -Iinclude/bl32/sp_min BL32_SOURCES += bl32/sp_min/sp_min_main.c \ bl32/sp_min/aarch32/entrypoint.S \ common/runtime_svc.c \ + plat/common/aarch32/plat_sp_min_common.c\ services/std_svc/std_svc_setup.c \ ${PSCI_LIB_SOURCES} diff --git a/bl32/sp_min/sp_min_main.c b/bl32/sp_min/sp_min_main.c index 4e8e685e0..8e891b757 100644 --- a/bl32/sp_min/sp_min_main.c +++ b/bl32/sp_min/sp_min_main.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -17,7 +17,7 @@ #include <platform_sp_min.h> #include <psci.h> #include <runtime_svc.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <stddef.h> #include <stdint.h> #include <string.h> @@ -32,7 +32,7 @@ static void *sp_min_cpu_ctx_ptr[PLATFORM_CORE_COUNT]; static smc_ctx_t sp_min_smc_context[PLATFORM_CORE_COUNT]; /****************************************************************************** - * Define the smcc helper library API's + * Define the smccc helper library API's *****************************************************************************/ void *smc_get_ctx(unsigned int security_state) { diff --git a/common/desc_image_load.c b/common/desc_image_load.c index 0ea247c69..28745d41d 100644 --- a/common/desc_image_load.c +++ b/common/desc_image_load.c @@ -239,14 +239,23 @@ void populate_next_bl_params_config(bl_params_t *bl2_to_next_bl_params) /* * Pass hw and tb_fw config addresses to next images. NOTE - for * EL3 runtime images (BL31 for AArch64 and BL32 for AArch32), - * arg0 is already used by generic code. + * arg0 is already used by generic code. Take care of not + * overwriting the previous initialisations. */ if (params_node == bl2_to_next_bl_params->head) { - params_node->ep_info->args.arg1 = fw_config_base; - params_node->ep_info->args.arg2 = hw_config_base; + if (params_node->ep_info->args.arg1 == 0) + params_node->ep_info->args.arg1 = + fw_config_base; + if (params_node->ep_info->args.arg2 == 0) + params_node->ep_info->args.arg2 = + hw_config_base; } else { - params_node->ep_info->args.arg0 = fw_config_base; - params_node->ep_info->args.arg1 = hw_config_base; + if (params_node->ep_info->args.arg0 == 0) + params_node->ep_info->args.arg0 = + fw_config_base; + if (params_node->ep_info->args.arg1 == 0) + params_node->ep_info->args.arg1 = + hw_config_base; } } } diff --git a/contributing.rst b/contributing.rst index cdf06201e..c3eadbb5a 100644 --- a/contributing.rst +++ b/contributing.rst @@ -1,13 +1,13 @@ -Contributing to ARM Trusted Firmware -==================================== +Contributing to Trusted Firmware-A +================================== Getting Started --------------- - Make sure you have a `GitHub account`_. - Create an `issue`_ for your work if one does not already exist. This gives - everyone visibility of whether others are working on something similar. ARM - licensees may contact ARM directly via their partner managers instead if + everyone visibility of whether others are working on something similar. Arm + licensees may contact Arm directly via their partner managers instead if they prefer. - Note that the `issue`_ tracker for this project is in a separate @@ -27,8 +27,8 @@ Making Changes - Make commits of logical units. See these general `Git guidelines`_ for contributing to a project. -- Follow the `Linux coding style`_; this style is enforced for the ARM Trusted - Firmware project (style errors only, not warnings). +- Follow the `Linux coding style`_; this style is enforced for the TF-A + project (style errors only, not warnings). - Use the checkpatch.pl script provided with the Linux source tree. A Makefile target is provided for convenience (see section 2 in the @@ -57,7 +57,7 @@ Making Changes :: - Portions copyright (c) [XXXX-]YYYY, ARM Limited and Contributors. All rights reserved. + Portions copyright (c) [XXXX-]YYYY, Arm Limited and Contributors. All rights reserved. where XXXX is the year of first contribution (if different to YYYY) and YYYY is the year of most recent contribution. @@ -108,7 +108,7 @@ Submitting Changes -------------- -*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* .. _GitHub account: https://github.com/signup/free .. _issue: https://github.com/ARM-software/tf-issues/issues diff --git a/docs/arm-sip-service.rst b/docs/arm-sip-service.rst index 6d456c7a6..9f0e26615 100644 --- a/docs/arm-sip-service.rst +++ b/docs/arm-sip-service.rst @@ -1,7 +1,7 @@ -ARM SiP Service +Arm SiP Service =============== -This document enumerates and describes the ARM SiP (Silicon Provider) services. +This document enumerates and describes the Arm SiP (Silicon Provider) services. SiP services are non-standard, platform-specific services offered by the silicon implementer or platform provider. They are accessed via. ``SMC`` ("SMC calls") @@ -13,20 +13,20 @@ services: ``0xc200ffff`` for 64-bit calls, and ``0x82000000`` - ``0x8200ffff`` for 32-bit calls. -The ARM SiP implementation offers the following services: +The Arm SiP implementation offers the following services: - Performance Measurement Framework (PMF) - Execution State Switching service -Source definitions for ARM SiP service are located in the ``arm_sip_svc.h`` header +Source definitions for Arm SiP service are located in the ``arm_sip_svc.h`` header file. Performance Measurement Framework (PMF) --------------------------------------- The `Performance Measurement Framework`_ -allows callers to retrieve timestamps captured at various paths in ARM Trusted -Firmware execution. It's described in detail in `Firmware Design document`_. +allows callers to retrieve timestamps captured at various paths in TF-A +execution. It's described in detail in `Firmware Design document`_. Execution State Switching service --------------------------------- @@ -35,8 +35,8 @@ Execution State Switching service provides a mechanism for a non-secure lower Exception Level (either EL2, or NS EL1 if EL2 isn't implemented) to request to switch its execution state (a.k.a. Register Width), either from AArch64 to AArch32, or from AArch32 to AArch64, for the calling CPU. This service is only -available when ARM Trusted Firmware is built for AArch64 (i.e. when build option -``ARCH`` is set to ``aarch64``). +available when Trusted Firmware-A (TF-A) is built for AArch64 (i.e. when build +option ``ARCH`` is set to ``aarch64``). ``ARM_SIP_SVC_EXE_STATE_SWITCH`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -79,8 +79,8 @@ The service may return the following error codes: - ``STATE_SW_E_PARAM``: If any of the parameters were deemed invalid for a specific request. -- ``STATE_SW_E_DENIED``: If the call is not successful, or when ARM Trusted - Firmware is built for AArch32. +- ``STATE_SW_E_DENIED``: If the call is not successful, or when TF-A is + built for AArch32. If the call is successful, the caller wouldn't observe the SMC returning. Instead, execution starts at the supplied entry point, with the CPU registers 0 @@ -89,7 +89,7 @@ respectively. -------------- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* .. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html .. _Performance Measurement Framework: ./firmware-design.rst#user-content-performance-measurement-framework diff --git a/docs/auth-framework.rst b/docs/auth-framework.rst index 3a054c7fb..c93482480 100644 --- a/docs/auth-framework.rst +++ b/docs/auth-framework.rst @@ -7,8 +7,9 @@ Abstracting a Chain of Trust .. contents:: -The aim of this document is to describe the authentication framework implemented -in the Trusted Firmware. This framework fulfills the following requirements: +The aim of this document is to describe the authentication framework +implemented in Trusted Firmware-A (TF-A). This framework fulfills the +following requirements: #. It should be possible for a platform port to specify the Chain of Trust in terms of certificate hierarchy and the mechanisms used to verify a @@ -152,8 +153,8 @@ performed to verify it: In Diagram 1, each component is responsible for one or more of these operations. The responsibilities are briefly described below. -TF Generic code and IO framework (GEN/IO) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +TF-A Generic code and IO framework (GEN/IO) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These components are responsible for initiating the authentication process for a particular image in BL1 or BL2. For each BL image that requires authentication, @@ -162,8 +163,8 @@ image until either an authenticated image or the ROT is reached. Then the Generic code calls the IO framewotk to load the image and calls the Authentication module to authenticate it, following the CoT from ROT to Image. -TF Platform Port (PP) -^^^^^^^^^^^^^^^^^^^^^ +TF-A Platform Port (PP) +^^^^^^^^^^^^^^^^^^^^^^^ The platform is responsible for: @@ -374,8 +375,8 @@ single parsing method. There has to be one IPL for every method used by the platform. #. Raw format: This format is effectively a nop as an image using this method - is treated as being in raw binary format e.g. boot loader images used by ARM - TF. This method should only be used by data images. + is treated as being in raw binary format e.g. boot loader images used by + TF-A. This method should only be used by data images. #. X509V3 method: This method uses industry standards like X.509 to represent PKI certificates (authentication images). It is expected that open source @@ -631,8 +632,8 @@ array of image descriptors and it is registered in the framework using the macro process to fail). The number of images participating in the boot process depends on the CoT. There -is, however, a minimum set of images that are mandatory in the Trusted Firmware -and thus all CoTs must present: +is, however, a minimum set of images that are mandatory in TF-A and thus all +CoTs must present: - ``BL2`` - ``SCP_BL2`` (platform specific) @@ -648,7 +649,7 @@ Following the `Platform Porting Guide`_, a platform must provide unique identifiers for all the images and certificates that will be loaded during the boot process. If a platform is using the TBBR as a reference for trusted boot, these identifiers can be obtained from ``include/common/tbbr/tbbr_img_def.h``. -ARM platforms include this file in ``include/plat/arm/common/arm_def.h``. Other +Arm platforms include this file in ``include/plat/arm/common/arm_def.h``. Other platforms may also include this file or provide their own identifiers. **Important**: the authentication module uses these identifiers to index the @@ -880,7 +881,7 @@ extract the authentication parameters. The number and type of parser libraries depend on the images used in the CoT. Raw images do not need a library, so only an x509v3 library is required for the TBBR CoT. -ARM platforms will use an x509v3 library based on mbed TLS. This library may be +Arm platforms will use an x509v3 library based on mbed TLS. This library may be found in ``drivers/auth/mbedtls/mbedtls_x509_parser.c``. It exports three functions: @@ -898,14 +899,14 @@ an image of type ``IMG_CERT``, it will call the corresponding function exported in this file. The build system must be updated to include the corresponding library and -mbed TLS sources. ARM platforms use the ``arm_common.mk`` file to pull the +mbed TLS sources. Arm platforms use the ``arm_common.mk`` file to pull the sources. The cryptographic library ~~~~~~~~~~~~~~~~~~~~~~~~~ The cryptographic module relies on a library to perform the required operations, -i.e. verify a hash or a digital signature. ARM platforms will use a library +i.e. verify a hash or a digital signature. Arm platforms will use a library based on mbed TLS, which can be found in ``drivers/auth/mbedtls/mbedtls_crypto.c``. This library is registered in the authentication framework using the macro ``REGISTER_CRYPTO_LIB()`` and exports @@ -934,7 +935,7 @@ of SHA-256 with smaller memory footprint (~1.5 KB less) but slower (~30%). -------------- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* .. _Trusted Board Boot: ./trusted-board-boot.rst .. _Platform Porting Guide: ./porting-guide.rst diff --git a/docs/change-log.rst b/docs/change-log.rst index f5ad56233..41e53a5ea 100644 --- a/docs/change-log.rst +++ b/docs/change-log.rst @@ -4,8 +4,294 @@ .. contents:: -ARM Trusted Firmware - version 1.4 -================================== +Trusted Firmware-A - version 1.5 +================================ + +New features +------------ + +- Added new firmware support to enable RAS (Reliability, Availability, and + Serviceability) functionality. + + - Secure Partition Manager (SPM): A Secure Partition is a software execution + environment instantiated in S-EL0 that can be used to implement simple + management and security services. The SPM is the firmware component that + is responsible for managing a Secure Partition. + + - SDEI dispatcher: Support for interrupt-based SDEI events and all + interfaces as defined by the SDEI specification v1.0, see + `SDEI Specification`_ + + - Exception Handling Framework (EHF): Framework that allows dispatching of + EL3 interrupts to their registered handlers which are registered based on + their priorities. Facilitates firmware-first error handling policy where + asynchronous exceptions may be routed to EL3. + + Integrated the TSPD with EHF. + +- Updated PSCI support: + + - Implemented PSCI v1.1 optional features `MEM_PROTECT` and `SYSTEM_RESET2`. + The supported PSCI version was updated to v1.1. + + - Improved PSCI STAT timestamp collection, including moving accounting for + retention states to be inside the locks and fixing handling of wrap-around + when calculating residency in AArch32 execution state. + + - Added optional handler for early suspend that executes when suspending to + a power-down state and with data caches enabled. + + This may provide a performance improvement on platforms where it is safe + to perform some or all of the platform actions from `pwr_domain_suspend` + with the data caches enabled. + +- Enabled build option, BL2_AT_EL3, for BL2 to allow execution at EL3 without + any dependency on TF BL1. + + This allows platforms which already have a non-TF Boot ROM to directly load + and execute BL2 and subsequent BL stages without need for BL1. This was not + previously possible because BL2 executes at S-EL1 and cannot jump straight to + EL3. + +- Implemented support for SMCCC v1.1, including `SMCCC_VERSION` and + `SMCCC_ARCH_FEATURES`. + + Additionally, added support for `SMCCC_VERSION` in PSCI features to enable + discovery of the SMCCC version via PSCI feature call. + +- Added Dynamic Configuration framework which enables each of the boot loader + stages to be dynamically configured at runtime if required by the platform. + The boot loader stage may optionally specify a firmware configuration file + and/or hardware configuration file that can then be shared with the next boot + loader stage. + + Introduced a new BL handover interface that essentially allows passing of 4 + arguments between the different BL stages. + + Updated cert_create and fip_tool to support the dynamic configuration files. + The COT also updated to support these new files. + +- Code hygiene changes and alignment with MISRA guideline: + + - Fix use of undefined macros. + + - Achieved compliance with Mandatory MISRA coding rules. + + - Achieved compliance for following Required MISRA rules for the default + build configurations on FVP and Juno platforms : 7.3, 8.3, 8.4, 8.5 and + 8.8. + +- Added support for Armv8.2-A architectural features: + + - Updated translation table set-up to set the CnP (Common not Private) bit + for secure page tables so that multiple PEs in the same Inner Shareable + domain can use the same translation table entries for a given stage of + translation in a particular translation regime. + + - Extended the supported values of ID_AA64MMFR0_EL1.PARange to include the + 52-bit Physical Address range. + + - Added support for the Scalable Vector Extension to allow Normal world + software to access SVE functionality but disable access to SVE, SIMD and + floating point functionality from the Secure world in order to prevent + corruption of the Z-registers. + +- Added support for Armv8.4-A architectural feature Activity Monitor Unit (AMU) + extensions. + + In addition to the v8.4 architectural extension, AMU support on Cortex-A75 + was implemented. + +- Enhanced OP-TEE support to enable use of pageable OP-TEE image. The Arm + standard platforms are updated to load up to 3 images for OP-TEE; header, + pager image and paged image. + + The chain of trust is extended to support the additional images. + +- Enhancements to the translation table library: + + - Introduced APIs to get and set the memory attributes of a region. + + - Added support to manage both priviledge levels in translation regimes that + describe translations for 2 Exception levels, specifically the EL1&0 + translation regime, and extended the memory map region attributes to + include specifying Non-privileged access. + + - Added support to specify the granularity of the mappings of each region, + for instance a 2MB region can be specified to be mapped with 4KB page + tables instead of a 2MB block. + + - Disabled the higher VA range to avoid unpredictable behaviour if there is + an attempt to access addresses in the higher VA range. + + - Added helpers for Device and Normal memory MAIR encodings that align with + the Arm Architecture Reference Manual for Armv8-A (Arm DDI0487B.b). + + - Code hygiene including fixing type length and signedness of constants, + refactoring of function to enable the MMU, removing all instances where + the virtual address space is hardcoded and added comments that document + alignment needed between memory attributes and attributes specified in + TCR_ELx. + +- Updated GIC support: + + - Introduce new APIs for GICv2 and GICv3 that provide the capability to + specify interrupt properties rather than list of interrupt numbers alone. + The Arm platforms and other upstream platforms are migrated to use + interrupt properties. + + - Added helpers to save / restore the GICv3 context, specifically the + Distributor and Redistributor contexts and architectural parts of the ITS + power management. The Distributor and Redistributor helpers also support + the implementation-defined part of GIC-500 and GIC-600. + + Updated the Arm FVP platform to save / restore the GICv3 context on system + suspend / resume as an example of how to use the helpers. + + Introduced a new TZC secured DDR carve-out for use by Arm platforms for + storing EL3 runtime data such as the GICv3 register context. + +- Added support for Armv7-A architecture via build option ARM_ARCH_MAJOR=7. + This includes following features: + + - Updates GICv2 driver to manage GICv1 with security extensions. + + - Software implementation for 32bit division. + + - Enabled use of generic timer for platforms that do not set + ARM_CORTEX_Ax=yes. + + - Support for Armv7-A Virtualization extensions [DDI0406C_C]. + + - Support for both Armv7-A platforms that only have 32-bit addressing and + Armv7-A platforms that support large page addressing. + + - Included support for following Armv7 CPUs: Cortex-A12, Cortex-A17, + Cortex-A7, Cortex-A5, Cortex-A9, Cortex-A15. + + - Added support in QEMU for Armv7-A/Cortex-A15. + +- Enhancements to Firmware Update feature: + + - Updated the FWU documentation to describe the additional images needed for + Firmware update, and how they are used for both the Juno platform and the + Arm FVP platforms. + +- Enhancements to Trusted Board Boot feature: + + - Added support to cert_create tool for RSA PKCS1# v1.5 and SHA384, SHA512 + and SHA256. + + - For Arm platforms added support to use ECDSA keys. + + - Enhanced the mbed TLS wrapper layer to include support for both RSA and + ECDSA to enable runtime selection between RSA and ECDSA keys. + +- Added support for secure interrupt handling in AArch32 sp_min, hardcoded to + only handle FIQs. + +- Added support to allow a platform to load images from multiple boot sources, + for example from a second flash drive. + +- Added a logging framework that allows platforms to reduce the logging level + at runtime and additionally the prefix string can be defined by the platform. + +- Further improvements to register initialisation: + + - Control register PMCR_EL0 / PMCR is set to prohibit cycle counting in the + secure world. This register is added to the list of registers that are + saved and restored during world switch. + + - When EL3 is running in AArch32 execution state, the Non-secure version of + SCTLR is explicitly initialised during the warmboot flow rather than + relying on the hardware to set the correct reset values. + +- Enhanced support for Arm platforms: + + - Introduced driver for Shared-Data-Structure (SDS) framework which is used + for communication between SCP and the AP CPU, replacing Boot-Over_MHU + (BOM) protocol. + + The Juno platform is migrated to use SDS with the SCMI support added in + v1.3 and is set as default. + + The driver can be found in the plat/arm/css/drivers folder. + + - Improved memory usage by only mapping TSP memory region when the TSPD has + been included in the build. This reduces the memory footprint and avoids + unnecessary memory being mapped. + + - Updated support for multi-threading CPUs for FVP platforms - always check + the MT field in MPDIR and access the bit fields accordingly. + + - Support building for platforms that model DynamIQ configuration by + implementing all CPUs in a single cluster. + + - Improved nor flash driver, for instance clearing status registers before + sending commands. Driver can be found plat/arm/board/common folder. + +- Enhancements to QEMU platform: + + - Added support for TBB. + + - Added support for using OP-TEE pageable image. + + - Added support for LOAD_IMAGE_V2. + + - Migrated to use translation table library v2 by default. + + - Added support for SEPARATE_CODE_AND_RODATA. + +- Applied workarounds CVE-2017-5715 on Arm Cortex-A57, -A72, -A73 and -A75, and + for Armv7-A CPUs Cortex-A9, -A15 and -A17. + +- Applied errata workaround for Arm Cortex-A57: 859972. + +- Applied errata workaround for Arm Cortex-A72: 859971. + +- Added support for Poplar 96Board platform. + +- Added support for Raspberry Pi 3 platform. + +- Added Call Frame Information (CFI) assembler directives to the vector entries + which enables debuggers to display the backtrace of functions that triggered + a synchronous abort. + +- Added ability to build dtb. + +- Added support for pre-tool (cert_create and fiptool) image processing + enabling compression of the image files before processing by cert_create and + fiptool. + + This can reduce fip size and may also speed up loading of images. The image + verification will also get faster because certificates are generated based on + compressed images. + + Imported zlib 1.2.11 to implement gunzip() for data compression. + +- Enhancements to fiptool: + + - Enabled the fiptool to be built using Visual Studio. + + - Added padding bytes at the end of the last image in the fip to be + facilitate transfer by DMA. + +Issues resolved since last release +---------------------------------- + +- TF-A can be built with optimisations disabled (-O0). + +- Memory layout updated to enable Trusted Board Boot on Juno platform when + running TF-A in AArch32 execution mode (resolving `tf-issue#501`_). + +Known Issues +------------ + +- DTB creation not supported when building on a windows host. This step in the + build process is skipped when running on a windows host. + +Trusted Firmware-A - version 1.4 +================================ New features ------------ @@ -23,13 +309,13 @@ New features - Added support for Cortex-A75 and Cortex-A55 processors. - Both Cortex-A75 and Cortex-A55 processors use the ARM DynamIQ Shared Unit + Both Cortex-A75 and Cortex-A55 processors use the Arm DynamIQ Shared Unit (DSU). The power-down and power-up sequences are therefore mostly managed in hardware, reducing complexity of the software operations. -- Introduced ARM GIC-600 driver. +- Introduced Arm GIC-600 driver. - ARM GIC-600 IP complies with ARM GICv3 architecture. For FVP platforms, the + Arm GIC-600 IP complies with Arm GICv3 architecture. For FVP platforms, the GIC-600 driver is chosen when FVP_USE_GIC_DRIVER is set to FVP_GIC600. - Updated GICv3 support: @@ -43,16 +329,16 @@ New features - GIC driver data is flushed by the primary CPU so that secondary CPU do not read stale GIC data. -- Added support for ARM System Control and Management Interface v1.0 (SCMI). +- Added support for Arm System Control and Management Interface v1.0 (SCMI). The SCMI driver implements the power domain management and system power - management protocol of the SCMI specification (ARM DEN 0056ASCMI) for + management protocol of the SCMI specification (Arm DEN 0056ASCMI) for communicating with any compliant power controller. Support is added for the Juno platform. The driver can be found in the plat/arm/css/drivers folder. -- Added support to enable pre-integration of TBB with the ARM TrustZone +- Added support to enable pre-integration of TBB with the Arm TrustZone CryptoCell product, to take advantage of its hardware Root of Trust and crypto acceleration services. @@ -84,12 +370,12 @@ New features - Fixed integer overflow which addressed TFV-1: Malformed Firmware Update SMC can result in copy of unexpectedly large data into secure memory. -- Introduced support for ARM Compiler 6 and LLVM (clang). +- Introduced support for Arm Compiler 6 and LLVM (clang). - ARM TF can now also be built with the ARM Compiler 6 or the clang compilers. + TF-A can now also be built with the Arm Compiler 6 or the clang compilers. The assembler and linker must be provided by the GNU toolchain. - Tested with ARM CC 6.7 and clang 3.9.x and 4.0.x. + Tested with Arm CC 6.7 and clang 3.9.x and 4.0.x. - Memory footprint improvements: @@ -103,30 +389,29 @@ New features additional logging options are supported via an optional platform define `PLAT_LOG_LEVEL_ASSERT`, which controls how verbose the assert output is. -- Enhancements to Trusted Firmware support when running in AArch32 execution - state: +- Enhancements to TF-A support when running in AArch32 execution state: - Support booting SP_MIN and BL33 in AArch32 execution mode on Juno. Due to hardware limitations, BL1 and BL2 boot in AArch64 state and there is additional trampoline code to warm reset into SP_MIN in AArch32 execution state. - - Added support for ARM Cortex-A53/57/72 MPCore processors including the + - Added support for Arm Cortex-A53/57/72 MPCore processors including the errata workarounds that are already implemented for AArch64 execution state. - For FVP platforms, added AArch32 Trusted Board Boot support, including the Firmware Update feature. -- Introduced ARM SiP service for use by ARM standard platforms. +- Introduced Arm SiP service for use by Arm standard platforms. - - Added new ARM SiP Service SMCs to enable the Non-secure world to read PMF + - Added new Arm SiP Service SMCs to enable the Non-secure world to read PMF timestamps. - Added PMF instrumentation points in ARM TF in order to quantify the + Added PMF instrumentation points in TF-A in order to quantify the overall time spent in the PSCI software implementation. - - Added new ARM SiP service SMC to switch execution state. + - Added new Arm SiP service SMC to switch execution state. This allows the lower exception level to change its execution state from AArch64 to AArch32, or vice verse, via a request to EL3. @@ -142,7 +427,7 @@ New features - Added version 2 of translation table library that allows different translation tables to be modified by using different 'contexts'. Version 1 - of the transalation table library only allows the current EL's translation + of the translation table library only allows the current EL's translation tables to be modified. Version 2 of the translation table also added support for dynamic @@ -172,7 +457,7 @@ New features detection. For increased effectiveness of protection platforms must provide an implementation that returns a random value. -- Enhanced support for ARM platforms: +- Enhanced support for Arm platforms: - Added support for multi-threading CPUs, indicated by `MT` field in MPDIR. A new build flag `ARM_PLAT_MT` is added, and when enabled, the functions @@ -183,13 +468,13 @@ New features enabled, returning the Processing Element count within the physical CPU corresponding to `mpidr`. - - The ARM platforms migrated to use version 2 of the translation tables. + - The Arm platforms migrated to use version 2 of the translation tables. - - Introduced a new ARM platform layer API `plat_arm_psci_override_pm_ops` - which allows ARM platforms to modify `plat_arm_psci_pm_ops` and therefore + - Introduced a new Arm platform layer API `plat_arm_psci_override_pm_ops` + which allows Arm platforms to modify `plat_arm_psci_pm_ops` and therefore dynamically define PSCI capability. - - The ARM platforms migrated to use IMAGE_LOAD_V2 by default. + - The Arm platforms migrated to use IMAGE_LOAD_V2 by default. - Enhanced reporting of errata workaround status with the following policy: @@ -206,15 +491,15 @@ New features missing. - Added build options ARM_ARCH_MAJOR and ARM_ARM_MINOR to choose the - architecture version to target ARM TF. + architecture version to target TF-A. - Updated the spin lock implementation to use the more efficient CAS (Compare And Swap) instruction when available. This instruction was introduced in - ARMv8.1-A. + Armv8.1-A. -- Applied errata workaround for ARM Cortex-A53: 855873. +- Applied errata workaround for Arm Cortex-A53: 855873. -- Applied errata workaround for ARM-Cortex-A57: 813419. +- Applied errata workaround for Arm-Cortex-A57: 813419. - Enabled all A53 and A57 errata workarounds for Juno, both in AArch64 and AArch32 execution states. @@ -248,7 +533,7 @@ New features - Essential control registers are fully initialised on EL3 start-up, when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with - the ARM ARM which states that software must initialise RES0 and RES1 + the Arm ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. - Enhanced PSCI support: @@ -268,12 +553,12 @@ New features Issues resolved since last release ---------------------------------- -- ARM TF can be built with the latest mbed TLS version (v2.4.2). The earlier - version 2.3.0 cannot be used due to build warnings that the ARM TF build +- TF-A can be built with the latest mbed TLS version (v2.4.2). The earlier + version 2.3.0 cannot be used due to build warnings that the TF-A build system interprets as errors. - TBBR, including the Firmware Update feature is now supported on FVP - platforms when running Trusted Firmware in AArch32 state. + platforms when running TF-A in AArch32 state. - The version of the AEMv8 Base FVP used in this release has resolved the issue of the model executing a reset instead of terminating in response to a @@ -282,11 +567,11 @@ Issues resolved since last release Known Issues ------------ -- Building TF with compiler optimisations disabled (-O0) fails. +- Building TF-A with compiler optimisations disabled (-O0) fails. - Trusted Board Boot currently does not work on Juno when running Trusted Firmware in AArch32 execution state due to error when loading the sp_min to - memory becasue of lack of free space available. See `tf-issue#501`_ for more + memory because of lack of free space available. See `tf-issue#501`_ for more details. - The errata workaround for A53 errata 843419 is only available from binutils @@ -294,14 +579,14 @@ Known Issues platform, please use GCC compiler version of at least 5.0. See `PR#1002`_ for more details. -ARM Trusted Firmware - version 1.3 -================================== +Trusted Firmware-A - version 1.3 +================================ New features ------------ -- Added support for running Trusted Firmware in AArch32 execution state. +- Added support for running TF-A in AArch32 execution state. The PSCI library has been refactored to allow integration with **EL3 Runtime Software**. This is software that is executing at the highest secure @@ -315,11 +600,11 @@ New features Booting to the BL1/BL2 images as well as booting straight to the Secure Payload is supported. -- Improvements to the initialization framework for the PSCI service and ARM +- Improvements to the initialization framework for the PSCI service and Arm Standard Services in general. - The PSCI service is now initialized as part of ARM Standard Service - initialization. This consolidates the initializations of any ARM Standard + The PSCI service is now initialized as part of Arm Standard Service + initialization. This consolidates the initializations of any Arm Standard Service that may be added in the future. A new function ``get_arm_std_svc_args()`` is introduced to get arguments @@ -337,7 +622,7 @@ New features (BL31, BL32, etc). The new mechanism is data-driven by a list of image descriptors provided by the platform code. - ARM platforms have been updated to support the new loading mechanism. + Arm platforms have been updated to support the new loading mechanism. The new mechanism is enabled by a build flag (``LOAD_IMAGE_V2``) which is currently off by default for the AArch64 build. @@ -345,7 +630,7 @@ New features **Note** ``TRUSTED_BOARD_BOOT`` is currently not supported when ``LOAD_IMAGE_V2`` is enabled. -- Updated requirements for making contributions to ARM TF. +- Updated requirements for making contributions to TF-A. Commits now must have a 'Signed-off-by:' field to certify that the contribution has been made under the terms of the @@ -365,13 +650,13 @@ New features - Updated PSCI support: - - Added support for PSCI NODE\_HW\_STATE API for ARM platforms. + - Added support for PSCI NODE\_HW\_STATE API for Arm platforms. - New optional platform hook, ``pwr_domain_pwr_down_wfi()``, in ``plat_psci_ops`` to enable platforms to perform platform-specific actions needed to enter powerdown, including the 'wfi' invocation. - - PSCI STAT residency and count functions have been added on ARM platforms + - PSCI STAT residency and count functions have been added on Arm platforms by using PMF. - Enhancements to the translation table library: @@ -420,13 +705,13 @@ New features convention as specified by TBBR and already used in cert\_create tool. - Refactored the TZC-400 driver to also support memory controllers that - integrate TZC functionality, for example ARM CoreLink DMC-500. Also added + integrate TZC functionality, for example Arm CoreLink DMC-500. Also added DMC-500 specific support. - Implemented generic delay timer based on the system generic counter and migrated all platforms to use it. -- Enhanced support for ARM platforms: +- Enhanced support for Arm platforms: - Updated image loading support to make SCP images (SCP\_BL2 and SCP\_BL2U) optional. @@ -441,7 +726,7 @@ New features the default secure SRAM. - Added support to use a System Security Control (SSC) Registers Unit - enabling ARM TF to be compiled to support multiple ARM platforms and + enabling TF-A to be compiled to support multiple Arm platforms and then select one at runtime. - Restricted mapping of Trusted ROM in BL1 to what is actually needed by @@ -455,26 +740,26 @@ New features - Added support for Mediatek MT6795 platform. -- Added support for QEMU virtualization ARMv8-A target. +- Added support for QEMU virtualization Armv8-A target. - Added support for Rockchip RK3368 and RK3399 platforms. - Added support for Xilinx Zynq UltraScale+ MPSoC platform. -- Added support for ARM Cortex-A73 MPCore Processor. +- Added support for Arm Cortex-A73 MPCore Processor. -- Added support for ARM Cortex-A72 processor. +- Added support for Arm Cortex-A72 processor. -- Added support for ARM Cortex-A35 processor. +- Added support for Arm Cortex-A35 processor. -- Added support for ARM Cortex-A32 MPCore Processor. +- Added support for Arm Cortex-A32 MPCore Processor. - Enabled preloaded BL33 alternative boot flow, in which BL2 does not load BL33 from non-volatile storage and BL31 hands execution over to a preloaded BL33. The User Guide has been updated with an example of how to use this option with a bootwrapped kernel. -- Added support to build ARM TF on a Windows-based host machine. +- Added support to build TF-A on a Windows-based host machine. - Updated Trusted Board Boot prototype implementation: @@ -493,7 +778,7 @@ New features - Enabled G1S or G0 interrupts to be configured independently. - Changed FVP default interrupt driver to be the GICv3-only driver. - **Note** the default build of Trusted Firmware will not be able to boot + **Note** the default build of TF-A will not be able to boot Linux kernel with GICv2 FDT blob. - Enabled wake-up from CPU\_SUSPEND to stand-by by temporarily re-routing @@ -510,26 +795,25 @@ Known issues the PSCI ``SYSTEM_OFF`` API. This issue will be fixed in a future version of the model. -- Building TF with compiler optimisations disabled (``-O0``) fails. +- Building TF-A with compiler optimisations disabled (``-O0``) fails. -- ARM TF cannot be built with mbed TLS version v2.3.0 due to build warnings - that the ARM TF build system interprets as errors. +- TF-A cannot be built with mbed TLS version v2.3.0 due to build warnings + that the TF-A build system interprets as errors. -- TBBR is not currently supported when running Trusted Firmware in AArch32 - state. +- TBBR is not currently supported when running TF-A in AArch32 state. -ARM Trusted Firmware - version 1.2 -================================== +Trusted Firmware-A - version 1.2 +================================ New features ------------ -- The Trusted Board Boot implementation on ARM platforms now conforms to the +- The Trusted Board Boot implementation on Arm platforms now conforms to the mandatory requirements of the TBBR specification. In particular, the boot process is now guarded by a Trusted Watchdog, which - will reset the system in case of an authentication or loading error. On ARM - platforms, a secure instance of ARM SP805 is used as the Trusted Watchdog. + will reset the system in case of an authentication or loading error. On Arm + platforms, a secure instance of Arm SP805 is used as the Trusted Watchdog. Also, a firmware update process has been implemented. It enables authenticated firmware to update firmware images from external interfaces to @@ -563,44 +847,44 @@ New features out, reducing the memory footprint of BL1 and BL2 by approximately 6 KB. - - On ARM development platforms, each BL stage now individually defines + - On Arm development platforms, each BL stage now individually defines the number of regions that it needs to map in the MMU. - Added the following new design documents: - `Authentication framework`_ - `Firmware Update`_ - - `TF Reset Design`_ + - `TF-A Reset Design`_ - `Power Domain Topology Design`_ - Applied the new image terminology to the code base and documentation, as - described on the `TF wiki on GitHub`_. + described on the `TF-A wiki on GitHub`_. - The build system has been reworked to improve readability and facilitate adding future extensions. -- On ARM standard platforms, BL31 uses the boot console during cold boot +- On Arm standard platforms, BL31 uses the boot console during cold boot but switches to the runtime console for any later logs at runtime. The TSP uses the runtime console for all output. -- Implemented a basic NOR flash driver for ARM platforms. It programs the +- Implemented a basic NOR flash driver for Arm platforms. It programs the device using CFI (Common Flash Interface) standard commands. -- Implemented support for booting EL3 payloads on ARM platforms, which +- Implemented support for booting EL3 payloads on Arm platforms, which reduces the complexity of developing EL3 baremetal code by doing essential baremetal initialization. - Provided separate drivers for GICv3 and GICv2. These expect the entire software stack to use either GICv2 or GICv3; hybrid GIC software systems - are no longer supported and the legacy ARM GIC driver has been deprecated. + are no longer supported and the legacy Arm GIC driver has been deprecated. -- Added support for Juno r1 and r2. A single set of Juno TF binaries can run - on Juno r0, r1 and r2 boards. Note that this TF version depends on a Linaro +- Added support for Juno r1 and r2. A single set of Juno TF-A binaries can run + on Juno r0, r1 and r2 boards. Note that this TF-A version depends on a Linaro release that does *not* contain Juno r2 support. - Added support for MediaTek mt8173 platform. -- Implemented a generic driver for ARM CCN IP. +- Implemented a generic driver for Arm CCN IP. - Major rework of the PSCI implementation. @@ -612,7 +896,7 @@ New features - Better alignment with version 1.0 of the PSCI specification. -- Added support for the SYSTEM\_SUSPEND PSCI API on ARM platforms. When invoked +- Added support for the SYSTEM\_SUSPEND PSCI API on Arm platforms. When invoked on the last running core on a supported platform, this puts the system into a low power mode with memory retention. @@ -625,17 +909,17 @@ New features - Added support for NVidia Tegra T210 and T132 SoCs. -- Reorganised ARM platforms ports to greatly improve code shareability and +- Reorganised Arm platforms ports to greatly improve code shareability and facilitate the reuse of some of this code by other platforms. -- Added support for ARM Cortex-A72 processor in the CPU specific framework. +- Added support for Arm Cortex-A72 processor in the CPU specific framework. - Provided better error handling. Platform ports can now define their own error handling, for example to perform platform specific bookkeeping or post-error actions. -- Implemented a unified driver for ARM Cache Coherent Interconnects used for - both CCI-400 & CCI-500 IPs. ARM platforms ports have been migrated to this +- Implemented a unified driver for Arm Cache Coherent Interconnects used for + both CCI-400 & CCI-500 IPs. Arm platforms ports have been migrated to this common driver. The standalone CCI-400 driver has been deprecated. Issues resolved since last release @@ -668,10 +952,10 @@ Known issues clarity and completeness. In particular, the design documentation is incomplete for PSCI, the TSP(D) and the Juno platform. -- Building TF with compiler optimisations disabled (``-O0``) fails. +- Building TF-A with compiler optimisations disabled (``-O0``) fails. -ARM Trusted Firmware - version 1.1 -================================== +Trusted Firmware-A - version 1.1 +================================ New features ------------ @@ -719,10 +1003,10 @@ New features applicable). Also, during a PSCI ``MIGRATE`` call, the SPD hook to migrate the Trusted OS is invoked. -- It is now possible to build Trusted Firmware without marking at least an - extra page of memory as coherent. The build flag ``USE_COHERENT_MEM`` can be - used to choose between the two implementations. This has been made possible - through these changes. +- It is now possible to build TF-A without marking at least an extra page of + memory as coherent. The build flag ``USE_COHERENT_MEM`` can be used to + choose between the two implementations. This has been made possible through + these changes. - An implementation of Bakery locks, where the locks are not allocated in coherent memory has been added. @@ -774,8 +1058,7 @@ New features create mappings only for areas in the memory map that it needs. - A Secure Payload Dispatcher (OPTEED) for the OP-TEE Trusted OS has been - added. Details of using it with ARM Trusted Firmware can be found in - `OP-TEE Dispatcher`_ + added. Details of using it with TF-A can be found in `OP-TEE Dispatcher`_ Issues resolved since last release ---------------------------------- @@ -789,7 +1072,7 @@ Issues resolved since last release - The top 16MB of the 2GB DDR-DRAM memory at 0x80000000 is configured using the TZC-400 controller to be accessible only to the secure world. - - The ARM GIC driver is used to configure the GIC-400 instead of using a + - The Arm GIC driver is used to configure the GIC-400 instead of using a GIC driver private to the Juno port. - PSCI ``CPU_SUSPEND`` calls that target a standby state are now supported. @@ -823,7 +1106,7 @@ Known issues the model. - GICv3 support is experimental. There are known issues with GICv3 - initialization in the ARM Trusted Firmware. + initialization in the TF-A. - While this version greatly reduces the on-chip RAM requirements, there are further RAM usage enhancements that could be made. @@ -833,8 +1116,8 @@ Known issues - The Juno-specific firmware design documentation is incomplete. -ARM Trusted Firmware - version 1.0 -================================== +Trusted Firmware-A - version 1.0 +================================ New features ------------ @@ -970,14 +1253,14 @@ Issues resolved since last release - CPU idle now works on the publicized version of the Foundation FVP. - All known issues relating to the compiler version used have now been - resolved. This TF version uses Linaro toolchain 14.07 (based on GCC 4.9). + resolved. This TF-A version uses Linaro toolchain 14.07 (based on GCC 4.9). Known issues ------------ - GICv3 support is experimental. The Linux kernel patches to support this are not widely available. There are known issues with GICv3 initialization in - the ARM Trusted Firmware. + the TF-A. - While this version greatly reduces the on-chip RAM requirements, there are further RAM usage enhancements that could be made. @@ -1013,8 +1296,8 @@ Known issues A similar change can be made to the other Cortex-A57-A53 Base FVP variants. -ARM Trusted Firmware - version 0.4 -================================== +Trusted Firmware-A - version 0.4 +================================ New features ------------ @@ -1110,41 +1393,41 @@ Issues resolved since last release 14.04) now correctly reports progress in the console. - Improved the Makefile structure to make it easier to separate out parts of - the Trusted Firmware for re-use in platform ports. Also, improved target - dependency checking. + the TF-A for re-use in platform ports. Also, improved target dependency + checking. Known issues ------------ - GICv3 support is experimental. The Linux kernel patches to support this are not widely available. There are known issues with GICv3 initialization in - the ARM Trusted Firmware. + the TF-A. - Dynamic image loading is not available yet. The current image loader implementation (used to load BL2 and all subsequent images) has some limitations. Changing BL2 or BL3-1 load addresses in certain ways can lead to loading errors, even if the images should theoretically fit in memory. -- The ARM Trusted Firmware still uses too much on-chip Trusted SRAM. A number - of RAM usage enhancements have been identified to rectify this situation. +- TF-A still uses too much on-chip Trusted SRAM. A number of RAM usage + enhancements have been identified to rectify this situation. - CPU idle does not work on the advertised version of the Foundation FVP. Some FVP fixes are required that are not available externally at the time of writing. This can be worked around by disabling CPU idle in the Linux kernel. -- Various bugs in ARM Trusted Firmware, UEFI and the Linux kernel have been - observed when using Linaro toolchain versions later than 13.11. Although - most of these have been fixed, some remain at the time of writing. These - mainly seem to relate to a subtle change in the way the compiler converts - between 64-bit and 32-bit values (e.g. during casting operations), which - reveals previously hidden bugs in client code. +- Various bugs in TF-A, UEFI and the Linux kernel have been observed when + using Linaro toolchain versions later than 13.11. Although most of these + have been fixed, some remain at the time of writing. These mainly seem to + relate to a subtle change in the way the compiler converts between 64-bit + and 32-bit values (e.g. during casting operations), which reveals + previously hidden bugs in client code. - The firmware design documentation for the Test Secure-EL1 Payload (TSP) and its dispatcher (TSPD) is incomplete. Similarly for the PSCI section. -ARM Trusted Firmware - version 0.3 -================================== +Trusted Firmware-A - version 0.3 +================================ New features ------------ @@ -1170,9 +1453,9 @@ New features - The PSCI AFFINITY\_INFO api has undergone limited testing on the Base FVPs to allow experimental use. -- Required C library and runtime header files are now included locally in ARM - Trusted Firmware instead of depending on the toolchain standard include - paths. The local implementation has been cleaned up and reduced in scope. +- Required C library and runtime header files are now included locally in + TF-A instead of depending on the toolchain standard include paths. The + local implementation has been cleaned up and reduced in scope. - Added I/O abstraction framework, primarily to allow generic code to load images in a platform-independent way. The existing image loading code has @@ -1232,28 +1515,27 @@ Issues resolved since last release - PSCI API calls ``AFFINITY_INFO`` & ``PSCI_VERSION`` have now been tested (to a limited extent). -- The ARM Trusted Firmware build artifacts are now placed in the ``./build`` - directory and sub-directories instead of being placed in the root of the - project. +- The TF-A build artifacts are now placed in the ``./build`` directory and + sub-directories instead of being placed in the root of the project. -- The ARM Trusted Firmware is now free from build warnings. Build warnings - are now treated as errors. +- TF-A is now free from build warnings. Build warnings are now treated as + errors. -- The ARM Trusted Firmware now provides C library support locally within the - project to maintain compatibility between toolchains/systems. +- TF-A now provides C library support locally within the project to maintain + compatibility between toolchains/systems. - The PSCI locking code has been reworked so it no longer takes locks in an incorrect sequence. - The RAM-disk method of loading a Linux file-system has been confirmed to - work with the ARM Trusted Firmware and Linux kernel version (based on - version 3.13) used in this release, for both Foundation and Base FVPs. + work with the TF-A and Linux kernel version (based on version 3.13) used + in this release, for both Foundation and Base FVPs. Known issues ------------ The following is a list of issues which are expected to be fixed in the future -releases of the ARM Trusted Firmware. +releases of TF-A. - The TrustZone Address Space Controller (TZC-400) is not being programmed yet. Use of model parameter ``-C bp.secure_memory=1`` is not supported. @@ -1262,28 +1544,28 @@ releases of the ARM Trusted Firmware. - GICv3 support is experimental. The Linux kernel patches to support this are not widely available. There are known issues with GICv3 initialization in - the ARM Trusted Firmware. + TF-A. - Dynamic image loading is not available yet. The current image loader implementation (used to load BL2 and all subsequent images) has some limitations. Changing BL2 or BL3-1 load addresses in certain ways can lead to loading errors, even if the images should theoretically fit in memory. -- The ARM Trusted Firmware uses too much on-chip Trusted SRAM. Currently the - Test Secure-EL1 Payload (BL3-2) executes in Trusted DRAM since there is not - enough SRAM. A number of RAM usage enhancements have been identified to - rectify this situation. +- TF-A uses too much on-chip Trusted SRAM. Currently the Test Secure-EL1 + Payload (BL3-2) executes in Trusted DRAM since there is not enough SRAM. + A number of RAM usage enhancements have been identified to rectify this + situation. - CPU idle does not work on the advertised version of the Foundation FVP. Some FVP fixes are required that are not available externally at the time of writing. -- Various bugs in ARM Trusted Firmware, UEFI and the Linux kernel have been - observed when using Linaro toolchain versions later than 13.11. Although - most of these have been fixed, some remain at the time of writing. These - mainly seem to relate to a subtle change in the way the compiler converts - between 64-bit and 32-bit values (e.g. during casting operations), which - reveals previously hidden bugs in client code. +- Various bugs in TF-A, UEFI and the Linux kernel have been observed when + using Linaro toolchain versions later than 13.11. Although most of these + have been fixed, some remain at the time of writing. These mainly seem to + relate to a subtle change in the way the compiler converts between 64-bit + and 32-bit values (e.g. during casting operations), which reveals + previously hidden bugs in client code. - The tested filesystem used for this release (Linaro AArch64 OpenEmbedded 14.01) does not report progress correctly in the console. It only seems to @@ -1292,15 +1574,14 @@ releases of the ARM Trusted Firmware. exhibit the problem. - The Makefile structure doesn't make it easy to separate out parts of the - Trusted Firmware for re-use in platform ports, for example if only BL3-1 is - required in a platform port. Also, dependency checking in the Makefile is - flawed. + TF-A for re-use in platform ports, for example if only BL3-1 is required in + a platform port. Also, dependency checking in the Makefile is flawed. - The firmware design documentation for the Test Secure-EL1 Payload (TSP) and its dispatcher (TSPD) is incomplete. Similarly for the PSCI section. -ARM Trusted Firmware - version 0.2 -================================== +Trusted Firmware-A - version 0.2 +================================ New features ------------ @@ -1320,7 +1601,7 @@ Known issues ------------ The following is a list of issues which are expected to be fixed in the future -releases of the ARM Trusted Firmware. +releases of TF-A. - The TrustZone Address Space Controller (TZC-400) is not being programmed yet. Use of model parameter ``-C bp.secure_memory=1`` is not supported. @@ -1330,7 +1611,7 @@ releases of the ARM Trusted Firmware. - GICv3 support is experimental. The Linux kernel patches to support this are not widely available. There are known issues with GICv3 initialization in - the ARM Trusted Firmware. + TF-A. - Dynamic image loading is not available yet. The current image loader implementation (used to load BL2 and all subsequent images) has some @@ -1340,42 +1621,41 @@ releases of the ARM Trusted Firmware. - Although support for PSCI ``CPU_SUSPEND`` is present, it is not yet stable and ready for use. -- PSCI API calls ``AFFINITY_INFO`` & ``PSCI_VERSION`` are implemented but have not - been tested. +- PSCI API calls ``AFFINITY_INFO`` & ``PSCI_VERSION`` are implemented but have + not been tested. -- The ARM Trusted Firmware make files result in all build artifacts being - placed in the root of the project. These should be placed in appropriate - sub-directories. +- The TF-A make files result in all build artifacts being placed in the root + of the project. These should be placed in appropriate sub-directories. -- The compilation of ARM Trusted Firmware is not free from compilation - warnings. Some of these warnings have not been investigated yet so they - could mask real bugs. +- The compilation of TF-A is not free from compilation warnings. Some of these + warnings have not been investigated yet so they could mask real bugs. -- The ARM Trusted Firmware currently uses toolchain/system include files like - stdio.h. It should provide versions of these within the project to maintain - compatibility between toolchains/systems. +- TF-A currently uses toolchain/system include files like stdio.h. It should + provide versions of these within the project to maintain compatibility + between toolchains/systems. - The PSCI code takes some locks in an incorrect sequence. This may cause problems with suspend and hotplug in certain conditions. - The Linux kernel used in this release is based on version 3.12-rc4. Using - this kernel with the ARM Trusted Firmware fails to start the file-system as - a RAM-disk. It fails to execute user-space ``init`` from the RAM-disk. As an - alternative, the VirtioBlock mechanism can be used to provide a file-system - to the kernel. + this kernel with the TF-A fails to start the file-system as a RAM-disk. It + fails to execute user-space ``init`` from the RAM-disk. As an alternative, + the VirtioBlock mechanism can be used to provide a file-system to the + kernel. -------------- -*Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* +.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf .. _PSCI Integration Guide: psci-lib-integration-guide.rst .. _Developer Certificate of Origin: ../dco.txt .. _Contribution Guide: ../contributing.rst .. _Authentication framework: auth-framework.rst .. _Firmware Update: firmware-update.rst -.. _TF Reset Design: reset-design.rst +.. _TF-A Reset Design: reset-design.rst .. _Power Domain Topology Design: psci-pd-tree.rst -.. _TF wiki on GitHub: https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Image-Terminology +.. _TF-A wiki on GitHub: https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Image-Terminology .. _Authentication Framework: auth-framework.rst .. _OP-TEE Dispatcher: optee-dispatcher.rst .. _tf-issue#501: https://github.com/ARM-software/tf-issues/issues/501 diff --git a/docs/cpu-specific-build-macros.rst b/docs/cpu-specific-build-macros.rst index 014817d39..9e11cdff6 100644 --- a/docs/cpu-specific-build-macros.rst +++ b/docs/cpu-specific-build-macros.rst @@ -1,4 +1,4 @@ -ARM CPU Specific Build Macros +Arm CPU Specific Build Macros ============================= @@ -14,8 +14,8 @@ for a specific CPU on a platform. Security Vulnerability Workarounds ---------------------------------- -ARM Trusted Firmware exports a series of build flags which control which -security vulnerability workarounds should be applied at runtime. +TF-A exports a series of build flags which control which security +vulnerability workarounds should be applied at runtime. - ``WORKAROUND_CVE_2017_5715``: Enables the security workaround for `CVE-2017-5715`_. Defaults to 1. @@ -23,10 +23,9 @@ security vulnerability workarounds should be applied at runtime. CPU Errata Workarounds ---------------------- -ARM Trusted Firmware exports a series of build flags which control the -errata workarounds that are applied to each CPU by the reset handler. The -errata details can be found in the CPU specific errata documents published -by ARM: +TF-A exports a series of build flags which control the errata workarounds that +are applied to each CPU by the reset handler. The errata details can be found +in the CPU specific errata documents published by Arm: - `Cortex-A53 MPCore Software Developers Errata Notice`_ - `Cortex-A57 MPCore Software Developers Errata Notice`_ @@ -135,8 +134,8 @@ architecture that can be enabled by the platform as desired. - ``A53_DISABLE_NON_TEMPORAL_HINT``: This flag disables the cache non-temporal hint. The LDNP/STNP instructions as implemented on Cortex-A53 do not behave in a way most programmers expect, and will most probably result in a - significant speed degradation to any code that employs them. The ARMv8-A - architecture (see ARM DDI 0487A.h, section D3.4.3) allows cores to ignore + significant speed degradation to any code that employs them. The Armv8-A + architecture (see Arm DDI 0487A.h, section D3.4.3) allows cores to ignore the non-temporal hint and treat LDNP/STNP as LDP/STP instead. Enabling this flag enforces this behaviour. This needs to be enabled only for revisions <= r0p3 of the CPU and is enabled by default. @@ -149,7 +148,7 @@ architecture that can be enabled by the platform as desired. -------------- -*Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.* .. _CVE-2017-5715: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715 .. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/Cortex_A53_MPCore_Software_Developers_Errata_Notice.pdf diff --git a/docs/firmware-design.rst b/docs/firmware-design.rst index c383c5d14..477eeaa54 100644 --- a/docs/firmware-design.rst +++ b/docs/firmware-design.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware Design -=========================== +Trusted Firmware-A design +========================= .. section-numbering:: @@ -7,30 +7,27 @@ ARM Trusted Firmware Design .. contents:: -The ARM Trusted Firmware implements a subset of the Trusted Board Boot -Requirements (TBBR) Platform Design Document (PDD) [1]_ for ARM reference +Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot +Requirements (TBBR) Platform Design Document (PDD) [1]_ for Arm reference platforms. The TBB sequence starts when the platform is powered on and runs up to the stage where it hands-off control to firmware running in the normal world in DRAM. This is the cold boot path. -The ARM Trusted Firmware also implements the Power State Coordination Interface -PDD [2]_ as a runtime service. PSCI is the interface from normal world software -to firmware implementing power management use-cases (for example, secondary CPU -boot, hotplug and idle). Normal world software can access ARM Trusted Firmware -runtime services via the ARM SMC (Secure Monitor Call) instruction. The SMC -instruction must be used as mandated by the SMC Calling Convention [3]_. +TF-A also implements the Power State Coordination Interface PDD [2]_ as a +runtime service. PSCI is the interface from normal world software to firmware +implementing power management use-cases (for example, secondary CPU boot, +hotplug and idle). Normal world software can access TF-A runtime services via +the Arm SMC (Secure Monitor Call) instruction. The SMC instruction must be +used as mandated by the SMC Calling Convention [3]_. -The ARM Trusted Firmware implements a framework for configuring and managing -interrupts generated in either security state. The details of the interrupt -management framework and its design can be found in ARM Trusted Firmware -Interrupt Management Design guide [4]_. +TF-A implements a framework for configuring and managing interrupts generated +in either security state. The details of the interrupt management framework +and its design can be found in TF-A Interrupt Management Design guide [4]_. -The ARM Trusted Firmware also implements a library for setting up and managing -the translation tables. The details of this library can be found in -`Xlat_tables design`_. +TF-A also implements a library for setting up and managing the translation +tables. The details of this library can be found in `Xlat_tables design`_. -The ARM Trusted Firmware can be built to support either AArch64 or AArch32 -execution state. +TF-A can be built to support either AArch64 or AArch32 execution state. Cold boot --------- @@ -46,9 +43,8 @@ the primary CPU has performed enough initialization to boot them. Refer to the `Reset Design`_ for more information on the effect of the ``COLD_BOOT_SINGLE_CPU`` platform build option. -The cold boot path in this implementation of the ARM Trusted Firmware, -depends on the execution state. -For AArch64, it is divided into five steps (in order of execution): +The cold boot path in this implementation of TF-A depends on the execution +state. For AArch64, it is divided into five steps (in order of execution): - Boot Loader stage 1 (BL1) *AP Trusted ROM* - Boot Loader stage 2 (BL2) *Trusted Boot Firmware* @@ -63,7 +59,7 @@ For AArch32, it is divided into four steps (in order of execution): - Boot Loader stage 3-2 (BL32) *EL3 Runtime Software* - Boot Loader stage 3-3 (BL33) *Non-trusted Firmware* -ARM development platforms (Fixed Virtual Platforms (FVPs) and Juno) implement a +Arm development platforms (Fixed Virtual Platforms (FVPs) and Juno) implement a combination of the following types of memory regions. Each bootloader stage uses one or more of these memory regions. @@ -77,11 +73,57 @@ one or more of these memory regions. The sections below provide the following details: +- dynamic configuration of Boot Loader stages - initialization and execution of the first three stages during cold boot - specification of the EL3 Runtime Software (BL31 for AArch64 and BL32 for AArch32) entrypoint requirements for use by alternative Trusted Boot Firmware in place of the provided BL1 and BL2 +Dynamic Configuration during cold boot +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Each of the Boot Loader stages may be dynamically configured if required by the +platform. The Boot Loader stage may optionally specify a firmware +configuration file and/or hardware configuration file as listed below: + +- HW_CONFIG - The hardware configuration file. Can be shared by all Boot Loader + stages and also by the Normal World Rich OS. +- TB_FW_CONFIG - Trusted Boot Firmware configuration file. Shared between BL1 + and BL2. +- SOC_FW_CONFIG - SoC Firmware configuration file. Used by BL31. +- TOS_FW_CONFIG - Trusted OS Firmware configuration file. Used by Trusted OS + (BL32). +- NT_FW_CONFIG - Non Trusted Firmware configuration file. Used by Non-trusted + firmware (BL33). + +The Arm development platforms use the Flattened Device Tree format for the +dynamic configuration files. + +Each Boot Loader stage can pass up to 4 arguments via registers to the next +stage. BL2 passes the list of the next images to execute to the *EL3 Runtime +Software* (BL31 for AArch64 and BL32 for AArch32) via `arg0`. All the other +arguments are platform defined. The Arm development platforms use the following +convention: + +- BL1 passes the address of a meminfo_t structure to BL2 via ``arg1``. This + structure contains the memory layout available to BL2. +- When dynamic configuration files are present, the firmware configuration for + the next Boot Loader stage is populated in the first available argument and + the generic hardware configuration is passed the next available argument. + For example, + + - If TB_FW_CONFIG is loaded by BL1, then its address is passed in ``arg0`` + to BL2. + - If HW_CONFIG is loaded by BL1, then its address is passed in ``arg2`` to + BL2. Note, ``arg1`` is already used for meminfo_t. + - If SOC_FW_CONFIG is loaded by BL2, then its address is passed in ``arg1`` + to BL31. Note, ``arg0`` is used to pass the list of executable images. + - Similarly, if HW_CONFIG is loaded by BL1 or BL2, then its address is + passed in ``arg2`` to BL31. + - For other BL3x images, if the firmware configuration file is loaded by + BL2, then its address is passed in ``arg0`` and if HW_CONFIG is loaded + then its address is passed in ``arg1``. + BL1 ~~~ @@ -89,7 +131,7 @@ This stage begins execution from the platform's reset vector at EL3. The reset address is platform dependent but it is usually located in a Trusted ROM area. The BL1 data section is copied to trusted SRAM at runtime. -On the ARM development platforms, BL1 code starts execution from the reset +On the Arm development platforms, BL1 code starts execution from the reset vector defined by the constant ``BL1_RO_BASE``. The BL1 data section is copied to the top of trusted SRAM as defined by the constant ``BL1_RW_BASE``. @@ -159,7 +201,7 @@ BL1 performs minimal architectural initialization as follows. 0x1b : Undefined mode 0x1f : System mode - The ``plat_report_exception()`` implementation on the ARM FVP port programs + The ``plat_report_exception()`` implementation on the Arm FVP port programs the Versatile Express System LED register in the following format to indicate the occurence of an unexpected exception: @@ -253,7 +295,7 @@ BL1 performs minimal architectural initialization as follows. Platform initialization ^^^^^^^^^^^^^^^^^^^^^^^ -On ARM platforms, BL1 performs the following platform initializations: +On Arm platforms, BL1 performs the following platform initializations: - Enable the Trusted Watchdog. - Initialize the console. @@ -261,6 +303,9 @@ On ARM platforms, BL1 performs the following platform initializations: - Enable the MMU and map the memory it needs to access. - Configure any required platform storage to load the next bootloader image (BL2). +- If the BL1 dynamic configuration file, ``TB_FW_CONFIG``, is available, then + load it to the platform defined address and make it available to BL2 via + ``arg0``. Firmware Update detection and execution ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -287,10 +332,10 @@ In the normal boot flow, BL1 execution continues as follows: "Booting Trusted Firmware" -#. BL1 determines the amount of free trusted SRAM memory available by - calculating the extent of its own data section, which also resides in - trusted SRAM. BL1 loads a BL2 raw binary image from platform storage, at a - platform-specific base address. If the BL2 image file is not present or if +#. BL1 loads a BL2 raw binary image from platform storage, at a + platform-specific base address. Prior to the load, BL1 invokes + ``bl1_plat_handle_pre_image_load()`` which allows the platform to update or + use the image information. If the BL2 image file is not present or if there is not enough free trusted SRAM the following error message is printed: @@ -298,18 +343,15 @@ In the normal boot flow, BL1 execution continues as follows: "Failed to load BL2 firmware." - BL1 calculates the amount of Trusted SRAM that can be used by the BL2 - image. The exact load location of the image is provided as a base address - in the platform header. Further description of the memory layout can be - found later in this document. +#. BL1 invokes ``bl1_plat_handle_post_image_load()`` which again is intended + for platforms to take further action after image load. This function must + populate the necessary arguments for BL2, which may also include the memory + layout. Further description of the memory layout can be found later + in this document. #. BL1 passes control to the BL2 image at Secure EL1 (for AArch64) or at Secure SVC mode (for AArch32), starting from its load address. -#. BL1 also passes information about the amount of trusted SRAM used and - available for use. This information is populated at a platform-specific - memory address. - BL2 ~~~ @@ -322,18 +364,18 @@ Architectural initialization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For AArch64, BL2 performs the minimal architectural initialization required -for subsequent stages of the ARM Trusted Firmware and normal world software. -EL1 and EL0 are given access to Floating Point and Advanced SIMD registers -by clearing the ``CPACR.FPEN`` bits. +for subsequent stages of TF-A and normal world software. EL1 and EL0 are given +access to Floating Point and Advanced SIMD registers by clearing the +``CPACR.FPEN`` bits. For AArch32, the minimal architectural initialization required for subsequent -stages of the ARM Trusted Firmware and normal world software is taken care of -in BL1 as both BL1 and BL2 execute at PL1. +stages of TF-A and normal world software is taken care of in BL1 as both BL1 +and BL2 execute at PL1. Platform initialization ^^^^^^^^^^^^^^^^^^^^^^^ -On ARM platforms, BL2 performs the following platform initializations: +On Arm platforms, BL2 performs the following platform initializations: - Initialize the console. - Configure any required platform storage to allow loading further bootloader @@ -344,6 +386,8 @@ On ARM platforms, BL2 performs the following platform initializations: EL3 Runtime Software and populate it. - Define the extents of memory available for loading each subsequent bootloader image. +- If BL1 has passed TB_FW_CONFIG dynamic configuration file in ``arg0``, + then parse it. Image loading in BL2 ^^^^^^^^^^^^^^^^^^^^ @@ -356,13 +400,19 @@ by the platform. BL2 passes the list of executable images provided by the platform to the next handover BL image. By default, this flag is disabled for AArch64 and the AArch32 build is supported only if this flag is enabled. +The list of loadable images provided by the platform may also contain +dynamic configuration files. The files are loaded and can be parsed as +needed in the ``bl2_plat_handle_post_image_load()`` function. These +configuration files can be passed to next Boot Loader stages as arguments +by updating the corresponding entrypoint information in this function. + SCP\_BL2 (System Control Processor Firmware) image load ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some systems have a separate System Control Processor (SCP) for power, clock, reset and system control. BL2 loads the optional SCP\_BL2 image from platform storage into a platform-specific region of secure memory. The subsequent -handling of SCP\_BL2 is platform specific. For example, on the Juno ARM +handling of SCP\_BL2 is platform specific. For example, on the Juno Arm development platform port the image is transferred into SCP's internal memory using the Boot Over MHU (BOM) protocol after being loaded in the trusted SRAM memory. The SCP executes SCP\_BL2 and signals to the Application Processor (AP) @@ -421,11 +471,11 @@ BL2 execution continues as follows: Running BL2 at EL3 execution level ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Some platforms have a non-TF Boot ROM that expects the next boot stage -to execute at EL3. On these platforms, TF BL1 is a waste of memory -as its only purpose is to ensure TF BL2 is entered at S-EL1. To avoid +Some platforms have a non-TF-A Boot ROM that expects the next boot stage +to execute at EL3. On these platforms, TF-A BL1 is a waste of memory +as its only purpose is to ensure TF-A BL2 is entered at S-EL1. To avoid this waste, a special mode enables BL2 to execute at EL3, which allows -a non-TF Boot ROM to load and jump directly to BL2. This mode is selected +a non-TF-A Boot ROM to load and jump directly to BL2. This mode is selected when the build flag BL2_AT_EL3 is enabled. The main differences in this mode are: @@ -512,7 +562,7 @@ Platform initialization BL31 performs detailed platform initialization, which enables normal world software to function correctly. -On ARM platforms, this consists of the following: +On Arm platforms, this consists of the following: - Initialize the console. - Configure the Interconnect to enable hardware coherency. @@ -568,9 +618,9 @@ Using alternative Trusted Boot Firmware in place of BL1 & BL2 (AArch64 only) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some platforms have existing implementations of Trusted Boot Firmware that -would like to use ARM Trusted Firmware BL31 for the EL3 Runtime Software. To -enable this firmware architecture it is important to provide a fully documented -and stable interface between the Trusted Boot Firmware and BL31. +would like to use TF-A BL31 for the EL3 Runtime Software. To enable this +firmware architecture it is important to provide a fully documented and stable +interface between the Trusted Boot Firmware and BL31. Future changes to the BL31 interface will be done in a backwards compatible way, and this enables these firmware components to be independently enhanced/ @@ -596,7 +646,7 @@ platform code in BL31: :: - X0 : Reserved for common Trusted Firmware information + X0 : Reserved for common TF-A information X1 : Platform specific information BL31 zero-init sections (e.g. ``.bss``) should not contain valid data on entry, @@ -611,10 +661,10 @@ used by the common BL31 code. The convention is that ``X0`` conveys information regarding the BL31, BL32 and BL33 images from the Trusted Boot firmware and ``X1`` can be used for other -platform specific purpose. This convention allows platforms which use ARM -Trusted Firmware's BL1 and BL2 images to transfer additional platform specific -information from Secure Boot without conflicting with future evolution of the -Trusted Firmware using ``X0`` to pass a ``bl31_params`` structure. +platform specific purpose. This convention allows platforms which use TF-A's +BL1 and BL2 images to transfer additional platform specific information from +Secure Boot without conflicting with future evolution of TF-A using ``X0`` to +pass a ``bl31_params`` structure. BL31 common and SPD initialization code depends on image and entrypoint information about BL33 and BL32, which is provided via BL31 platform APIs. @@ -626,8 +676,8 @@ Cold boot Initialization parameters. This data may need to be cleaned out of the CPU caches if it is provided by an earlier boot stage and then accessed by BL31 platform code before the caches are enabled. -ARM Trusted Firmware's BL2 implementation passes a ``bl31_params`` structure in -``X0`` and the ARM development platforms interpret this in the BL31 platform +TF-A's BL2 implementation passes a ``bl31_params`` structure in +``X0`` and the Arm development platforms interpret this in the BL31 platform code. MMU, Data caches & Coherency @@ -668,12 +718,11 @@ to simplify this action. Required CPU state for BL31 Warm boot initialization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -When requesting a CPU power-on, or suspending a running CPU, ARM Trusted -Firmware provides the platform power management code with a Warm boot -initialization entry-point, to be invoked by the CPU immediately after the -reset handler. On entry to the Warm boot initialization function the calling -CPU must be in AArch64 EL3, little-endian data access and all interrupt sources -masked: +When requesting a CPU power-on, or suspending a running CPU, TF-A provides +the platform power management code with a Warm boot initialization +entry-point, to be invoked by the CPU immediately after the reset handler. +On entry to the Warm boot initialization function the calling CPU must be in +AArch64 EL3, little-endian data access and all interrupt sources masked: :: @@ -715,7 +764,7 @@ platform code in AArch32 EL3 Runtime Software: :: - R0 : Reserved for common Trusted Firmware information + R0 : Reserved for common TF-A information R1 : Platform specific information Use of the R0 and R1 parameters @@ -724,10 +773,9 @@ Use of the R0 and R1 parameters The parameters are platform specific and the convention is that ``R0`` conveys information regarding the BL3x images from the Trusted Boot firmware and ``R1`` can be used for other platform specific purpose. This convention allows -platforms which use ARM Trusted Firmware's BL1 and BL2 images to transfer -additional platform specific information from Secure Boot without conflicting -with future evolution of the Trusted Firmware using ``R0`` to pass a ``bl_params`` -structure. +platforms which use TF-A's BL1 and BL2 images to transfer additional platform +specific information from Secure Boot without conflicting with future +evolution of TF-A using ``R0`` to pass a ``bl_params`` structure. The AArch32 EL3 Runtime Software is responsible for entry into BL33. This information can be obtained in a platform defined manner, e.g. compiled into @@ -737,7 +785,7 @@ via the Cold boot Initialization parameters. This data may need to be cleaned out of the CPU caches if it is provided by an earlier boot stage and then accessed by AArch32 EL3 Runtime Software before the caches are enabled. -When using AArch32 EL3 Runtime Software, the ARM development platforms pass a +When using AArch32 EL3 Runtime Software, the Arm development platforms pass a ``bl_params`` structure in ``R0`` from BL2 to be interpreted by AArch32 EL3 Runtime Software platform code. @@ -760,9 +808,9 @@ Required CPU state for warm boot initialization When requesting a CPU power-on, or suspending a running CPU, AArch32 EL3 Runtime Software must ensure execution of a warm boot initialization entrypoint. -If ARM Trusted Firmware BL1 is used and the PROGRAMMABLE\_RESET\_ADDRESS build -flag is false, then AArch32 EL3 Runtime Software must ensure that BL1 branches -to the warm boot entrypoint by arranging for the BL1 platform function, +If TF-A BL1 is used and the PROGRAMMABLE\_RESET\_ADDRESS build flag is false, +then AArch32 EL3 Runtime Software must ensure that BL1 branches to the warm +boot entrypoint by arranging for the BL1 platform function, plat\_get\_my\_entrypoint(), to return a non-zero value. In this case, the warm boot entrypoint must be in AArch32 EL3, little-endian @@ -773,7 +821,7 @@ data access and all interrupt sources masked: PSTATE.AIF = 0x7 SCTLR.EE = 0 -The warm boot entrypoint may be implemented by using the ARM Trusted Firmware +The warm boot entrypoint may be implemented by using TF-A ``psci_warmboot_entrypoint()`` function. In that case, the platform must fulfil the pre-requisites mentioned in the `PSCI Library integration guide`_. @@ -806,7 +854,7 @@ not all been instantiated in the current implementation. This service is for management of the entire system. The Power State Coordination Interface (`PSCI`_) is the first set of standard service calls - defined by ARM (see PSCI section later). + defined by Arm (see PSCI section later). #. Secure-EL1 Payload Dispatcher service @@ -820,12 +868,12 @@ not all been instantiated in the current implementation. The interface between the EL3 Runtime Software and the Secure-EL1 Payload is not defined by the `SMCCC`_ or any other standard. As a result, each Secure-EL1 Payload requires a specific Secure Monitor that runs as a runtime - service - within ARM Trusted Firmware this service is referred to as the - Secure-EL1 Payload Dispatcher (SPD). + service - within TF-A this service is referred to as the Secure-EL1 Payload + Dispatcher (SPD). - ARM Trusted Firmware provides a Test Secure-EL1 Payload (TSP) and its - associated Dispatcher (TSPD). Details of SPD design and TSP/TSPD operation - are described in the "Secure-EL1 Payloads and Dispatchers" section below. + TF-A provides a Test Secure-EL1 Payload (TSP) and its associated Dispatcher + (TSPD). Details of SPD design and TSP/TSPD operation are described in the + "Secure-EL1 Payloads and Dispatchers" section below. #. CPU implementation service @@ -833,7 +881,7 @@ not all been instantiated in the current implementation. services for a given platform e.g. access to processor errata workarounds. This service is currently unimplemented. -Additional services for ARM Architecture, SiP and OEM calls can be implemented. +Additional services for Arm Architecture, SiP and OEM calls can be implemented. Each implemented service handles a range of SMC function identifiers as described in the `SMCCC`_. @@ -1006,10 +1054,10 @@ registered with the generic PSCI code to be supported. \*\*Note : These PSCI APIs require appropriate Secure Payload Dispatcher hooks to be registered with the generic PSCI code to be supported. -The PSCI implementation in ARM Trusted Firmware is a library which can be -integrated with AArch64 or AArch32 EL3 Runtime Software for ARMv8-A systems. -A guide to integrating PSCI library with AArch32 EL3 Runtime Software -can be found `here`_. +The PSCI implementation in TF-A is a library which can be integrated with +AArch64 or AArch32 EL3 Runtime Software for Armv8-A systems. A guide to +integrating PSCI library with AArch32 EL3 Runtime Software can be found +`here`_. Secure-EL1 Payloads and Dispatchers ----------------------------------- @@ -1018,20 +1066,20 @@ On a production system that includes a Trusted OS running in Secure-EL1/EL0, the Trusted OS is coupled with a companion runtime service in the BL31 firmware. This service is responsible for the initialisation of the Trusted OS and all communications with it. The Trusted OS is the BL32 stage of the -boot flow in ARM Trusted Firmware. The firmware will attempt to locate, load -and execute a BL32 image. +boot flow in TF-A. The firmware will attempt to locate, load and execute a +BL32 image. -ARM Trusted Firmware uses a more general term for the BL32 software that runs -at Secure-EL1 - the *Secure-EL1 Payload* - as it is not always a Trusted OS. +TF-A uses a more general term for the BL32 software that runs at Secure-EL1 - +the *Secure-EL1 Payload* - as it is not always a Trusted OS. -The ARM Trusted Firmware provides a Test Secure-EL1 Payload (TSP) and a Test -Secure-EL1 Payload Dispatcher (TSPD) service as an example of how a Trusted OS -is supported on a production system using the Runtime Services Framework. On -such a system, the Test BL32 image and service are replaced by the Trusted OS -and its dispatcher service. The ARM Trusted Firmware build system expects that -the dispatcher will define the build flag ``NEED_BL32`` to enable it to include -the BL32 in the build either as a binary or to compile from source depending -on whether the ``BL32`` build option is specified or not. +TF-A provides a Test Secure-EL1 Payload (TSP) and a Test Secure-EL1 Payload +Dispatcher (TSPD) service as an example of how a Trusted OS is supported on a +production system using the Runtime Services Framework. On such a system, the +Test BL32 image and service are replaced by the Trusted OS and its dispatcher +service. The TF-A build system expects that the dispatcher will define the +build flag ``NEED_BL32`` to enable it to include the BL32 in the build either +as a binary or to compile from source depending on whether the ``BL32`` build +option is specified or not. The TSP runs in Secure-EL1. It is designed to demonstrate synchronous communication with the normal-world software running in EL1/EL2. Communication @@ -1079,8 +1127,8 @@ prototype: and is registered using the ``bl31_register_bl32_init()`` function. -Trusted Firmware supports two approaches for the SPD to pass control to BL32 -before returning through EL3 and running the non-trusted firmware (BL33): +TF-A supports two approaches for the SPD to pass control to BL32 before +returning through EL3 and running the non-trusted firmware (BL33): #. In the BL32 setup function, use ``bl31_set_next_image_type()`` to request that the exit from ``bl31_main()`` is to the BL32 entrypoint in @@ -1099,8 +1147,8 @@ before returning through EL3 and running the non-trusted firmware (BL33): ``bl31_register_bl32_init()`` which provides a SPD-defined mechanism to invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32 entrypoint. - NOTE: The Test SPD service included with the Trusted Firmware provides one - implementation of such a mechanism. + NOTE: The Test SPD service included with TF-A provides one implementation + of such a mechanism. On completion BL32 returns control to BL31 via a SMC, and on receipt the SPD service handler invokes the synchronous call return mechanism to return @@ -1206,11 +1254,11 @@ The sample crash output is shown below. Guidelines for Reset Handlers ----------------------------- -Trusted Firmware implements a framework that allows CPU and platform ports to -perform actions very early after a CPU is released from reset in both the cold -and warm boot paths. This is done by calling the ``reset_handler()`` function in -both the BL1 and BL31 images. It in turn calls the platform and CPU specific -reset handling functions. +TF-A implements a framework that allows CPU and platform ports to perform +actions very early after a CPU is released from reset in both the cold and warm +boot paths. This is done by calling the ``reset_handler()`` function in both +the BL1 and BL31 images. It in turn calls the platform and CPU specific reset +handling functions. Details for implementing a CPU specific reset handler can be found in Section 8. Details for implementing a platform specific reset handler can be @@ -1276,11 +1324,11 @@ There are two ways to specify secure interrupt configuration: CPU specific operations framework --------------------------------- -Certain aspects of the ARMv8 architecture are implementation defined, -that is, certain behaviours are not architecturally defined, but must be defined -and documented by individual processor implementations. The ARM Trusted -Firmware implements a framework which categorises the common implementation -defined behaviours and allows a processor to export its implementation of that +Certain aspects of the Armv8-A architecture are implementation defined, +that is, certain behaviours are not architecturally defined, but must be +defined and documented by individual processor implementations. TF-A +implements a framework which categorises the common implementation defined +behaviours and allows a processor to export its implementation of that behaviour. The categories are: #. Processor specific reset sequence. @@ -1383,11 +1431,11 @@ expected by the crash reporting framework. CPU errata status reporting ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Errata workarounds for CPUs supported in ARM Trusted Firmware are applied during -both cold and warm boots, shortly after reset. Individual Errata workarounds are -enabled as build options. Some errata workarounds have potential run-time -implications; therefore some are enabled by default, others not. Platform ports -shall override build options to enable or disable errata as appropriate. The CPU +Errata workarounds for CPUs supported in TF-A are applied during both cold and +warm boots, shortly after reset. Individual Errata workarounds are enabled as +build options. Some errata workarounds have potential run-time implications; +therefore some are enabled by default, others not. Platform ports shall +override build options to enable or disable errata as appropriate. The CPU drivers take care of applying errata workarounds that are enabled and applicable to a given CPU. Refer to the section titled *CPU Errata Workarounds* in `CPUBM`_ for more information. @@ -1421,9 +1469,9 @@ macro, the errata reporting function, if it exists, must be named ``cpux_errata_report``. This function will always be called with MMU enabled; it must follow AAPCS and may use stack. -In a debug build of ARM Trusted Firmware, on a CPU that comes out of reset, both -BL1 and the run time firmware (BL31 in AArch64, and BL32 in AArch32) will invoke -errata status reporting function, if one exists, for that type of CPU. +In a debug build of TF-A, on a CPU that comes out of reset, both BL1 and the +runtime firmware (BL31 in AArch64, and BL32 in AArch32) will invoke errata +status reporting function, if one exists, for that type of CPU. To report the status of each errata workaround, the function shall use the assembler macro ``report_errata``, passing it: @@ -1439,9 +1487,9 @@ assembler macro ``report_errata``, passing it: The errata status reporting function will be called once per CPU type/errata combination during the software's active life time. -It's expected that whenever an errata workaround is submitted to ARM Trusted -Firmware, the errata reporting function is appropriately extended to report its -status as well. +It's expected that whenever an errata workaround is submitted to TF-A, the +errata reporting function is appropriately extended to report its status as +well. Reporting the status of errata workaround is for informational purpose only; it has no functional significance. @@ -1462,22 +1510,22 @@ Each bootloader image can be divided in 2 parts: In the ELF terminology, they are called ``NOBITS`` sections. All PROGBITS sections are grouped together at the beginning of the image, -followed by all NOBITS sections. This is true for all Trusted Firmware images -and it is governed by the linker scripts. This ensures that the raw binary -images are as small as possible. If a NOBITS section was inserted in between -PROGBITS sections then the resulting binary file would contain zero bytes in -place of this NOBITS section, making the image unnecessarily bigger. Smaller -images allow faster loading from the FIP to the main memory. +followed by all NOBITS sections. This is true for all TF-A images and it is +governed by the linker scripts. This ensures that the raw binary images are +as small as possible. If a NOBITS section was inserted in between PROGBITS +sections then the resulting binary file would contain zero bytes in place of +this NOBITS section, making the image unnecessarily bigger. Smaller images +allow faster loading from the FIP to the main memory. Linker scripts and symbols ~~~~~~~~~~~~~~~~~~~~~~~~~~ Each bootloader stage image layout is described by its own linker script. The linker scripts export some symbols into the program symbol table. Their values -correspond to particular addresses. The trusted firmware code can refer to these -symbols to figure out the image memory layout. +correspond to particular addresses. TF-A code can refer to these symbols to +figure out the image memory layout. -Linker symbols follow the following naming convention in the trusted firmware. +Linker symbols follow the following naming convention in TF-A. - ``__<SECTION>_START__`` @@ -1510,10 +1558,10 @@ Linker symbols follow the following naming convention in the trusted firmware. rounding up due to some alignment constraint. In other words, ``__<SECTION>_UNALIGNED_SIZE__ = __<SECTION>_UNALIGNED_END__ - __<SECTION>_START__``. -Some of the linker symbols are mandatory as the trusted firmware code relies on -them to be defined. They are listed in the following subsections. Some of them -must be provided for each bootloader stage and some are specific to a given -bootloader stage. +Some of the linker symbols are mandatory as TF-A code relies on them to be +defined. They are listed in the following subsections. Some of them must be +provided for each bootloader stage and some are specific to a given bootloader +stage. The linker scripts define some extra, optional symbols. They are not actually used by any code but they help in understanding the bootloader images' memory @@ -1568,12 +1616,11 @@ The following additional linker symbols are defined for BL1: How to choose the right base addresses for each bootloader stage image ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -There is currently no support for dynamic image loading in the Trusted Firmware. -This means that all bootloader images need to be linked against their ultimate -runtime locations and the base addresses of each image must be chosen carefully -such that images don't overlap each other in an undesired way. As the code -grows, the base addresses might need adjustments to cope with the new memory -layout. +There is currently no support for dynamic image loading in TF-A. This means +that all bootloader images need to be linked against their ultimate runtime +locations and the base addresses of each image must be chosen carefully such +that images don't overlap each other in an undesired way. As the code grows, +the base addresses might need adjustments to cope with the new memory layout. The memory layout is completely specific to the platform and so there is no general recipe for choosing the right base addresses for each bootloader image. @@ -1601,13 +1648,13 @@ Additionally, if the platform memory layout implies some image overlaying like on FVP, BL31 and TSP need to know the limit address that their PROGBITS sections must not overstep. The platform code must provide those. -When LOAD\_IMAGE\_V2 is disabled, Trusted Firmware provides a mechanism to -verify at boot time that the memory to load a new image is free to prevent -overwriting a previously loaded image. For this mechanism to work, the platform -must specify the memory available in the system as regions, where each region -consists of base address, total size and the free area within it (as defined -in the ``meminfo_t`` structure). Trusted Firmware retrieves these memory regions -by calling the corresponding platform API: +When LOAD\_IMAGE\_V2 is disabled, TF-A provides a mechanism to verify at boot +time that the memory to load a new image is free to prevent overwriting a +previously loaded image. For this mechanism to work, the platform must specify +the memory available in the system as regions, where each region consists of +base address, total size and the free area within it (as defined in the +``meminfo_t`` structure). TF-A retrieves these memory regions by calling the +corresponding platform API: - ``meminfo_t *bl1_plat_sec_mem_layout(void)`` - ``meminfo_t *bl2_plat_sec_mem_layout(void)`` @@ -1631,7 +1678,7 @@ corresponding processor (e.g. the SCP BL2 image). To reduce fragmentation and simplify the tracking of free memory, all the free memory within a region is always located in one single buffer defined by its -base address and size. Trusted Firmware implements a top/bottom load approach: +base address and size. TF-A implements a top/bottom load approach: after a new image is loaded, it checks how much memory remains free above and below the image. The smallest area is marked as unavailable, while the larger area becomes the new free memory buffer. Platforms should take this behaviour @@ -1671,10 +1718,10 @@ And the following diagram is an example of an image loaded in the top part: | | +----------+ -When LOAD\_IMAGE\_V2 is enabled, Trusted Firmware does not provide any mechanism -to verify at boot time that the memory to load a new image is free to prevent -overwriting a previously loaded image. The platform must specify the memory -available in the system for all the relevant BL images to be loaded. +When LOAD\_IMAGE\_V2 is enabled, TF-A does not provide any mechanism to verify +at boot time that the memory to load a new image is free to prevent overwriting +a previously loaded image. The platform must specify the memory available in +the system for all the relevant BL images to be loaded. For example, in the case of BL1 loading BL2, ``bl1_plat_sec_mem_layout()`` will return the region defined by the platform where BL1 intends to load BL2. The @@ -1682,10 +1729,10 @@ return the region defined by the platform where BL1 intends to load BL2. The base and maximum image size provided by the platforms. Platforms must take this behaviour into account when defining the base/size for each of the images. -Memory layout on ARM development platforms +Memory layout on Arm development platforms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following list describes the memory layout on the ARM development platforms: +The following list describes the memory layout on the Arm development platforms: - A 4KB page of shared memory is used for communication between Trusted Firmware and the platform's power controller. This is located at the base of @@ -1745,14 +1792,13 @@ mechanism at boot time are defined as follows (shown per API): This region is an exact copy of the region defined by ``bl2_plat_sec_mem_layout()``. Being a disconnected copy means that all the - changes made to this region by the Trusted Firmware will not be propagated. - This approach is valid because the SCP BL2 image is loaded temporarily - while it is being transferred to the SCP, so this memory is reused - afterwards. + changes made to this region by the TF-A will not be propagated. This + approach is valid because the SCP BL2 image is loaded temporarily while it + is being transferred to the SCP, so this memory is reused afterwards. - ``void bl2_plat_get_bl32_meminfo(meminfo_t *bl32_meminfo)`` - This region depends on the location of the BL32 image. Currently, ARM + This region depends on the location of the BL32 image. Currently, Arm platforms support three different locations (detailed below): Trusted SRAM, Trusted DRAM and the TZC-Secured DRAM. @@ -1791,32 +1837,44 @@ layout of the other images in Trusted SRAM. | BL1 (ro) | 0x00000000 +----------+ -**FVP with TSP in Trusted DRAM:** +**FVP with TSP in Trusted DRAM with TB_FW_CONFIG and HW_CONFIG :** :: - Trusted DRAM - 0x08000000 +----------+ - | BL32 | - 0x06000000 +----------+ - - Trusted SRAM - 0x04040000 +----------+ loaded by BL2 ------------------ - | BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | - |----------| <<<<<<<<<<<<< |----------------| - | | <<<<<<<<<<<<< | BL31 PROGBITS | - |----------| ------------------ - | BL2 | - |----------| - | | - 0x04001000 +----------+ - | Shared | - 0x04000000 +----------+ - - Trusted ROM - 0x04000000 +----------+ - | BL1 (ro) | - 0x00000000 +----------+ + DRAM + 0xffffffff +--------------+ + : : + |--------------| + | HW_CONFIG | + 0x83000000 |--------------| (non-secure) + | | + 0x80000000 +--------------+ + + Trusted DRAM + 0x08000000 +--------------+ + | BL32 | + 0x06000000 +--------------+ + + Trusted SRAM + 0x04040000 +--------------+ loaded by BL2 ------------------ + | BL1 (rw) | <<<<<<<<<<<<< | BL31 NOBITS | + |--------------| <<<<<<<<<<<<< |----------------| + | | <<<<<<<<<<<<< | BL31 PROGBITS | + |--------------| ------------------ + | BL2 | + |--------------| + | | + |--------------| + | TB_FW_CONFIG | + |--------------| + 0x04001000 +--------------+ + | Shared | + 0x04000000 +--------------+ + + Trusted ROM + 0x04000000 +--------------+ + | BL1 (ro) | + 0x00000000 +--------------+ **FVP with TSP in TZC-Secured DRAM:** @@ -1824,7 +1882,7 @@ layout of the other images in Trusted SRAM. DRAM 0xffffffff +----------+ - | BL32 | (secure) + | BL32 | (secure) 0xff000000 +----------+ | | : : (non-secure) @@ -1881,7 +1939,7 @@ layout of the other images in Trusted SRAM. DRAM 0xFFE00000 +----------+ - | BL32 | (secure) + | BL32 | (secure) 0xFF000000 |----------| | | : : (non-secure) @@ -1914,11 +1972,11 @@ Firmware Image Package (FIP) ---------------------------- Using a Firmware Image Package (FIP) allows for packing bootloader images (and -potentially other payloads) into a single archive that can be loaded by the ARM -Trusted Firmware from non-volatile platform storage. A driver to load images -from a FIP has been added to the storage layer and allows a package to be read -from supported platform storage. A tool to create Firmware Image Packages is -also provided and described below. +potentially other payloads) into a single archive that can be loaded by TF-A +from non-volatile platform storage. A driver to load images from a FIP has +been added to the storage layer and allows a package to be read from supported +platform storage. A tool to create Firmware Image Packages is also provided +and described below. Firmware Image Package layout ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1953,7 +2011,7 @@ retrieved. The ToC header and entry formats are described in the header file ``include/tools_share/firmware_image_package.h``. This file is used by both the -tool and the ARM Trusted firmware. +tool and TF-A. The ToC header has the following fields: @@ -1983,10 +2041,10 @@ A ToC entry has the following fields: Firmware Image Package creation tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The FIP creation tool can be used to pack specified images into a binary package -that can be loaded by the ARM Trusted Firmware from platform storage. The tool -currently only supports packing bootloader images. Additional image definitions -can be added to the tool as required. +The FIP creation tool can be used to pack specified images into a binary +package that can be loaded by TF-A from platform storage. The tool currently +only supports packing bootloader images. Additional image definitions can be +added to the tool as required. The tool can be found in ``tools/fiptool``. @@ -1994,38 +2052,37 @@ Loading from a Firmware Image Package (FIP) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Firmware Image Package (FIP) driver can load images from a binary package on -non-volatile platform storage. For the ARM development platforms, this is +non-volatile platform storage. For the Arm development platforms, this is currently NOR FLASH. Bootloader images are loaded according to the platform policy as specified by -the function ``plat_get_image_source()``. For the ARM development platforms, this +the function ``plat_get_image_source()``. For the Arm development platforms, this means the platform will attempt to load images from a Firmware Image Package located at the start of NOR FLASH0. -The ARM development platforms' policy is to only allow loading of a known set of +The Arm development platforms' policy is to only allow loading of a known set of images. The platform policy can be modified to allow additional images. -Use of coherent memory in Trusted Firmware ------------------------------------------- +Use of coherent memory in TF-A +------------------------------ There might be loss of coherency when physical memory with mismatched shareability, cacheability and memory attributes is accessed by multiple CPUs -(refer to section B2.9 of `ARM ARM`_ for more details). This possibility occurs -in Trusted Firmware during power up/down sequences when coherency, MMU and -caches are turned on/off incrementally. +(refer to section B2.9 of `Arm ARM`_ for more details). This possibility occurs +in TF-A during power up/down sequences when coherency, MMU and caches are +turned on/off incrementally. -Trusted Firmware defines coherent memory as a region of memory with Device -nGnRE attributes in the translation tables. The translation granule size in -Trusted Firmware is 4KB. This is the smallest possible size of the coherent -memory region. +TF-A defines coherent memory as a region of memory with Device nGnRE attributes +in the translation tables. The translation granule size in TF-A is 4KB. This +is the smallest possible size of the coherent memory region. By default, all data structures which are susceptible to accesses with mismatched attributes from various CPUs are allocated in a coherent memory region (refer to section 2.1 of `Porting Guide`_). The coherent memory region accesses are Outer Shareable, non-cacheable and they can be accessed with the Device nGnRE attributes when the MMU is turned on. Hence, at the -expense of at least an extra page of memory, Trusted Firmware is able to work -around coherency issues due to mismatched memory attributes. +expense of at least an extra page of memory, TF-A is able to work around +coherency issues due to mismatched memory attributes. The alternative to the above approach is to allocate the susceptible data structures in Normal WriteBack WriteAllocate Inner shareable memory. This @@ -2033,12 +2090,12 @@ approach requires the data structures to be designed so that it is possible to work around the issue of mismatched memory attributes by performing software cache maintenance on them. -Disabling the use of coherent memory in Trusted Firmware -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Disabling the use of coherent memory in TF-A +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It might be desirable to avoid the cost of allocating coherent memory on -platforms which are memory constrained. Trusted Firmware enables inclusion of -coherent memory in firmware images through the build flag ``USE_COHERENT_MEM``. +platforms which are memory constrained. TF-A enables inclusion of coherent +memory in firmware images through the build flag ``USE_COHERENT_MEM``. This flag is enabled by default. It can be disabled to choose the second approach described above. @@ -2050,9 +2107,8 @@ Coherent memory usage in PSCI implementation The ``psci_non_cpu_pd_nodes`` data structure stores the platform's power domain tree information for state management of power domains. By default, this data -structure is allocated in the coherent memory region in the Trusted Firmware -because it can be accessed by multple CPUs, either with caches enabled or -disabled. +structure is allocated in the coherent memory region in TF-A because it can be +accessed by multple CPUs, either with caches enabled or disabled. .. code:: c @@ -2205,7 +2261,7 @@ operation on Lock\_N, the corresponding ``bakery_info_t`` in both CPU0 and CPU1 ``bakery_lock`` section need to be fetched and appropriate cache operations need to be performed for each access. -On ARM Platforms, bakery locks are used in psci (``psci_locks``) and power controller +On Arm Platforms, bakery locks are used in psci (``psci_locks``) and power controller driver (``arm_lock``). Non Functional Impact of removing coherent memory @@ -2226,7 +2282,7 @@ The implementation has been optimized to minimize this additional overhead. Measurements indicate that when bakery locks are allocated in Normal memory, the minimum latency of acquiring a lock is on an average 3-4 micro seconds whereas in Device memory the same is 2 micro seconds. The measurements were done on the -Juno ARM development platform. +Juno Arm development platform. As mentioned earlier, almost a page of memory can be saved by disabling ``USE_COHERENT_MEM``. Each platform needs to consider these trade-offs to decide @@ -2238,7 +2294,7 @@ optionally define macro ``PLAT_PERCPU_BAKERY_LOCK_SIZE`` (see the Isolating code and read-only data on separate memory pages ---------------------------------------------------------- -In the ARMv8 VMSA, translation table entries include fields that define the +In the Armv8-A VMSA, translation table entries include fields that define the properties of the target memory region, such as its access permissions. The smallest unit of memory that can be addressed by a translation table entry is a memory page. Therefore, if software needs to set different permissions on two @@ -2313,7 +2369,7 @@ With this more condensed memory layout, the separation of read-only data will add zero or one page to the memory footprint of each BL image. Each platform should consider the trade-off between memory footprint and security. -This build flag is disabled by default, minimising memory footprint. On ARM +This build flag is disabled by default, minimising memory footprint. On Arm platforms, it is enabled. Publish and Subscribe Framework @@ -2367,11 +2423,10 @@ PE only; it won't cause handlers to execute on a different PE. Note that publishing an event on a PE blocks until all the subscribed handlers finish executing on the PE. -ARM Trusted Firmware generic code publishes and subscribes to some events -within. Platform ports are discouraged from subscribing to them. These events -may be withdrawn, renamed, or have their semantics altered in the future. -Platforms may however register, publish, and subscribe to platform-specific -events. +TF-A generic code publishes and subscribes to some events within. Platform +ports are discouraged from subscribing to them. These events may be withdrawn, +renamed, or have their semantics altered in the future. Platforms may however +register, publish, and subscribe to platform-specific events. Publish and Subscribe Example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2407,9 +2462,9 @@ Performance Measurement Framework --------------------------------- The Performance Measurement Framework (PMF) facilitates collection of -timestamps by registered services and provides interfaces to retrieve -them from within the ARM Trusted Firmware. A platform can choose to -expose appropriate SMCs to retrieve these collected timestamps. +timestamps by registered services and provides interfaces to retrieve them +from within TF-A. A platform can choose to expose appropriate SMCs to +retrieve these collected timestamps. By default, the global physical counter is used for the timestamp value and is read via ``CNTPCT_EL0``. The framework allows to retrieve @@ -2454,9 +2509,8 @@ timestamps in a PMF specific linker section at build time. Additionally, it defines necessary functions to capture and retrieve a particular timestamp for the given service at runtime. -The macro ``PMF_REGISTER_SERVICE()`` only enables capturing PMF -timestamps from within ARM Trusted Firmware. In order to retrieve -timestamps from outside of ARM Trusted Firmware, the +The macro ``PMF_REGISTER_SERVICE()`` only enables capturing PMF timestamps +from within TF-A. In order to retrieve timestamps from outside of TF-A, the ``PMF_REGISTER_SERVICE_SMC()`` macro must be used instead. This macro accepts the same set of arguments as the ``PMF_REGISTER_SERVICE()`` macro but additionally supports retrieving timestamps using SMCs. @@ -2486,13 +2540,13 @@ and store it at the determined address for later retrieval. Retrieving a timestamp ~~~~~~~~~~~~~~~~~~~~~~ -From within ARM Trusted Firmware, timestamps for individual CPUs can -be retrieved using either ``PMF_GET_TIMESTAMP_BY_MPIDR()`` or -``PMF_GET_TIMESTAMP_BY_INDEX()`` macros. These macros accept the CPU's MPIDR -value, or its ordinal position, respectively. +From within TF-A, timestamps for individual CPUs can be retrieved using either +``PMF_GET_TIMESTAMP_BY_MPIDR()`` or ``PMF_GET_TIMESTAMP_BY_INDEX()`` macros. +These macros accept the CPU's MPIDR value, or its ordinal position +respectively. -From outside ARM Trusted Firmware, timestamps for individual CPUs can be -retrieved by calling into ``pmf_smc_handler()``. +From outside TF-A, timestamps for individual CPUs can be retrieved by calling +into ``pmf_smc_handler()``. .. code:: c @@ -2534,32 +2588,31 @@ PMF code structure #. ``pmf_helpers.h`` is an internal header used by ``pmf.h``. -ARMv8 Architecture Extensions ------------------------------ +Armv8-A Architecture Extensions +------------------------------- -ARM Trusted Firmware makes use of ARMv8 Architecture Extensions where -applicable. This section lists the usage of Architecture Extensions, and build -flags controlling them. +TF-A makes use of Armv8-A Architecture Extensions where applicable. This +section lists the usage of Architecture Extensions, and build flags +controlling them. In general, and unless individually mentioned, the build options ``ARM_ARCH_MAJOR`` and ``ARM_ARCH_MINOR`` selects the Architecture Extension to -target when building ARM Trusted Firmware. Subsequent ARM Architecture -Extensions are backward compatible with previous versions. +target when building TF-A. Subsequent Arm Architecture Extensions are backward +compatible with previous versions. The build system only requires that ``ARM_ARCH_MAJOR`` and ``ARM_ARCH_MINOR`` have a valid numeric value. These build options only control whether or not -Architecture Extension-specific code is included in the build. Otherwise, ARM -Trusted Firmware targets the base ARMv8.0 architecture; i.e. as if -``ARM_ARCH_MAJOR`` == 8 and ``ARM_ARCH_MINOR`` == 0, which are also their respective -default values. +Architecture Extension-specific code is included in the build. Otherwise, TF-A +targets the base Armv8.0-A architecture; i.e. as if ``ARM_ARCH_MAJOR`` == 8 +and ``ARM_ARCH_MINOR`` == 0, which are also their respective default values. See also the *Summary of build options* in `User Guide`_. For details on the Architecture Extension and available features, please refer to the respective Architecture Extension Supplement. -ARMv8.1 -~~~~~~~ +Armv8.1-A +~~~~~~~~~ This Architecture Extension is targeted when ``ARM_ARCH_MAJOR`` >= 8, or when ``ARM_ARCH_MAJOR`` == 8 and ``ARM_ARCH_MINOR`` >= 1. @@ -2567,8 +2620,8 @@ This Architecture Extension is targeted when ``ARM_ARCH_MAJOR`` >= 8, or when - The Compare and Swap instruction is used to implement spinlocks. Otherwise, the load-/store-exclusive instruction pair is used. -ARMv8.2 -~~~~~~~ +Armv8.2-A +~~~~~~~~~ This Architecture Extension is targeted when ``ARM_ARCH_MAJOR`` == 8 and ``ARM_ARCH_MINOR`` >= 2. @@ -2578,23 +2631,22 @@ This Architecture Extension is targeted when ``ARM_ARCH_MAJOR`` == 8 and translation table entries for a given stage of translation for a particular translation regime. -ARMv7 -~~~~~ +Armv7-A +~~~~~~~ This Architecture Extension is targeted when ``ARM_ARCH_MAJOR`` == 7. -There are several ARMv7 extensions available. Obviously the TrustZone -extension is mandatory to support the ARM Trusted Firmware bootloader -and runtime services. +There are several Armv7-A extensions available. Obviously the TrustZone +extension is mandatory to support the TF-A bootloader and runtime services. -Platform implementing an ARMv7 system can to define from its target +Platform implementing an Armv7-A system can to define from its target Cortex-A architecture through ``ARM_CORTEX_A<X> = yes`` in their ``plaform.mk`` script. For example ``ARM_CORTEX_A15=yes`` for a Cortex-A15 target. Platform can also set ``ARM_WITH_NEON=yes`` to enable neon support. Note that using neon at runtime has constraints on non secure wolrd context. -The trusted firmware does not yet provide VFP context management. +TF-A does not yet provide VFP context management. Directive ``ARM_CORTEX_A<x>`` and ``ARM_WITH_NEON`` are used to set the toolchain target architecture directive. @@ -2610,9 +2662,9 @@ I.e: Code Structure -------------- -Trusted Firmware code is logically divided between the three boot loader -stages mentioned in the previous sections. The code is also divided into the -following categories (present as directories in the source code): +TF-A code is logically divided between the three boot loader stages mentioned +in the previous sections. The code is also divided into the following +categories (present as directories in the source code): - **Platform specific.** Choice of architecture specific code depends upon the platform. @@ -2642,8 +2694,8 @@ categories. Based upon the above, the code layout looks like this: The build system provides a non configurable build option IMAGE\_BLx for each boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE\_BL1 will be -defined by the build system. This enables the Trusted Firmware to compile -certain code only for specific boot loader stages +defined by the build system. This enables TF-A to compile certain code only +for specific boot loader stages All assembler files have the ``.S`` extension. The linker source files for each boot stage have the extension ``.ld.S``. These are processed by GCC to create the @@ -2655,15 +2707,15 @@ kernel at boot time. These can be found in the ``fdts`` directory. References ---------- -.. [#] Trusted Board Boot Requirements CLIENT PDD (ARM DEN0006C-1). Available - under NDA through your ARM account representative. +.. [#] Trusted Board Boot Requirements CLIENT PDD (Arm DEN0006C-1). Available + under NDA through your Arm account representative. .. [#] `Power State Coordination Interface PDD`_ .. [#] `SMC Calling Convention PDD`_ -.. [#] `ARM Trusted Firmware Interrupt Management Design guide`_. +.. [#] `TF-A Interrupt Management Design guide`_. -------------- -*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* .. _Reset Design: ./reset-design.rst .. _Porting Guide: ./porting-guide.rst @@ -2677,10 +2729,10 @@ References .. _here: ./psci-lib-integration-guide.rst .. _cpu-specific-build-macros.rst: ./cpu-specific-build-macros.rst .. _CPUBM: ./cpu-specific-build-macros.rst -.. _ARM ARM: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.e/index.html +.. _Arm ARM: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.e/index.html .. _User Guide: ./user-guide.rst .. _SMC Calling Convention PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf -.. _ARM Trusted Firmware Interrupt Management Design guide: ./interrupt-framework-design.rst +.. _TF-A Interrupt Management Design guide: ./interrupt-framework-design.rst .. _Xlat_tables design: xlat-tables-lib-v2-design.rst .. |Image 1| image:: diagrams/rt-svc-descs-layout.png?raw=true diff --git a/docs/firmware-update.rst b/docs/firmware-update.rst index 829341d6d..e10e148a5 100644 --- a/docs/firmware-update.rst +++ b/docs/firmware-update.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware - Firmware Update Design Guide -=================================================== +Trusted Firmware-A - Firmware Update design guide +================================================= .. section-numbering:: @@ -21,9 +21,9 @@ is corrupt or missing; it therefore may be used as a recovery mode. It may also be complemented by other, higher level firmware update software. FWU implements a specific part of the Trusted Board Boot Requirements (TBBR) -specification, ARM DEN0006C-1. It should be used in conjunction with the +specification, Arm DEN0006C-1. It should be used in conjunction with the `Trusted Board Boot`_ design document, which describes the image authentication -parts of the Trusted Firmware (TF) TBBR implementation. +parts of the Trusted Firmware-A (TF-A) TBBR implementation. Scope ~~~~~ @@ -63,11 +63,11 @@ The primary requirements of the FWU feature are: it needs, and to enable platform specific FWU functionality. See the `Porting Guide`_ for details of this interface. -TF uses abbreviated image terminology for FWU images like for other TF images. -An overview of this terminology can be found `here`_. +TF-A uses abbreviated image terminology for FWU images like for other TF-A +images. An overview of this terminology can be found `here`_. -The following diagram shows the FWU boot flow for ARM development platforms. -ARM CSS platforms like Juno have a System Control Processor (SCP), and these +The following diagram shows the FWU boot flow for Arm development platforms. +Arm CSS platforms like Juno have a System Control Processor (SCP), and these use all defined FWU images. Other platforms may use a subset of these. |Flow Diagram| @@ -193,8 +193,8 @@ BL1\_SMC\_RUN\_IMAGE if (ep_info not EL3) synchronous exception This SMC passes execution control to an EL3 image described by the provided -``entry_point_info_t`` structure. In the normal TF boot flow, BL2 invokes this SMC -for BL1 to pass execution control to BL31. +``entry_point_info_t`` structure. In the normal TF-A boot flow, BL2 invokes +this SMC for BL1 to pass execution control to BL31. FWU\_SMC\_IMAGE\_COPY ~~~~~~~~~~~~~~~~~~~~~ @@ -400,7 +400,7 @@ This is only allowed if the image is not being executed. -------------- -*Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* .. _Trusted Board Boot: ./trusted-board-boot.rst .. _Porting Guide: ./porting-guide.rst diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst index 0eb7f54f2..b5c7d2190 100644 --- a/docs/interrupt-framework-design.rst +++ b/docs/interrupt-framework-design.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware Interrupt Management Design guide -====================================================== +Trusted Firmware-A interrupt management design guide +==================================================== .. section-numbering:: @@ -88,8 +88,8 @@ The framework considers certain routing models for each type of interrupt to be incorrect as they conflict with the requirements mentioned in Section 1. The following sub-sections describe all the possible routing models and specify which ones are valid or invalid. EL3 interrupts are currently supported only -for GIC version 3.0 (ARM GICv3) and only the Secure-EL1 and Non-secure interrupt -types are supported for GIC version 2.0 (ARM GICv2) (See 1.2). The terminology +for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt +types are supported for GIC version 2.0 (Arm GICv2) (See 1.2). The terminology used in the following sub-sections is explained below. #. **CSS**. Current Security State. ``0`` when secure and ``1`` when non-secure @@ -111,7 +111,7 @@ Secure-EL1 interrupts #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in non-secure state. This is an invalid routing model as a secure interrupt is not visible to the secure software which violates the motivation behind - the ARM Security Extensions. + the Arm Security Extensions. #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in non-secure state. This is a valid routing model as secure software in EL3 @@ -162,7 +162,7 @@ EL3 interrupts #. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in non-secure state. This is an invalid routing model as a secure interrupt is not visible to the secure software which violates the motivation behind - the ARM Security Extensions. + the Arm Security Extensions. #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in non-secure state. This is a valid routing model as secure software in EL3 @@ -179,7 +179,7 @@ uses this information to determine whether the IRQ or the FIQ bit should be programmed in ``SCR_EL3`` while applying the routing model for a type of interrupt. The platform provides this information through the ``plat_interrupt_type_to_line()`` API (described in the -`Porting Guide`_). For example, on the FVP port when the platform uses an ARM GICv2 +`Porting Guide`_). For example, on the FVP port when the platform uses an Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the FIQ signal while Non-secure interrupts are signaled through the IRQ signal. This applies when execution is in either security state. @@ -194,7 +194,7 @@ that security state. This means that all the other interrupt types using the same interrupt signal will be forced to the same routing model. This should be borne in mind when choosing the routing model for an interrupt type. -For example, in ARM GICv3, when the execution context is Secure-EL1/ +For example, in Arm GICv3, when the execution context is Secure-EL1/ Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ signal. So if either one of the interrupt type sets the routing model so that **TEL3=1** when **CSS=0**, the FIQ bit in ``SCR_EL3`` will be programmed to @@ -208,8 +208,8 @@ The framework makes the following assumptions to simplify its implementation. #. Although the framework has support for 2 types of secure interrupts (EL3 and Secure-EL1 interrupt), only interrupt controller architectures - like ARM GICv3 has architectural support for EL3 interrupts in the form of - Group 0 interrupts. In ARM GICv2, all secure interrupts are assumed to be + like Arm GICv3 has architectural support for EL3 interrupts in the form of + Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they cannot be handled in EL3. @@ -260,7 +260,7 @@ the non-secure interrupts and target them to the primary CPU. It should also export the interface described in the `Porting Guide`_ to enable handling of interrupts. -In the remainder of this document, for the sake of simplicity a ARM GICv2 system +In the remainder of this document, for the sake of simplicity a Arm GICv2 system is considered and it is assumed that the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal is used to generate non-secure interrupts in either security state. EL3 interrupts are not considered. @@ -272,8 +272,7 @@ Roles and responsibilities for interrupt management are sub-divided between the following components of software running in EL3 and Secure-EL1. Each component is briefly described below. -#. EL3 Runtime Firmware. This component is common to all ports of the ARM - Trusted Firmware. +#. EL3 Runtime Firmware. This component is common to all ports of TF-A. #. Secure Payload Dispatcher (SPD) service. This service interfaces with the Secure Payload (SP) software which runs in Secure-EL1/Secure-EL0 and is @@ -282,20 +281,20 @@ briefly described below. exported by the Context management library to implement this functionality. Switching execution between the two security states is a requirement for interrupt management as well. This results in a significant dependency on - the SPD service. ARM Trusted firmware implements an example Test Secure - Payload Dispatcher (TSPD) service. + the SPD service. TF-A implements an example Test Secure Payload Dispatcher + (TSPD) service. An SPD service plugs into the EL3 runtime firmware and could be common to - some ports of the ARM Trusted Firmware. + some ports of TF-A. #. Secure Payload (SP). On a production system, the Secure Payload corresponds to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the - SPD service to manage communication with non-secure software. ARM Trusted - Firmware implements an example secure payload called Test Secure Payload - (TSP) which runs only in Secure-EL1. + SPD service to manage communication with non-secure software. TF-A + implements an example secure payload called Test Secure Payload (TSP) + which runs only in Secure-EL1. - A Secure payload implementation could be common to some ports of the ARM - Trusted Firmware just like the SPD service. + A Secure payload implementation could be common to some ports of TF-A, + just like the SPD service. Interrupt registration ---------------------- @@ -515,7 +514,7 @@ the interrupt routing model is not known to the SPD service at compile time, then the SP should pass this information to the SPD service at runtime during its initialisation phase. -As mentioned earlier, a ARM GICv2 system is considered and it is assumed that +As mentioned earlier, an Arm GICv2 system is considered and it is assumed that the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal is used to generate non-secure interrupts in either security state. @@ -595,7 +594,7 @@ exceptions taken at the same (Secure-EL1) exception level. This table is referenced through the ``tsp_exceptions`` variable and programmed into the VBAR\_EL1. It caters for the asynchronous handling model. -The TSP also programs the Secure Physical Timer in the ARM Generic Timer block +The TSP also programs the Secure Physical Timer in the Arm Generic Timer block to raise a periodic interrupt (every half a second) for the purpose of testing interrupt management across all the software components listed in 2.1 @@ -999,7 +998,7 @@ TSP by returning ``SMC_UNK`` error. -------------- -*Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.* .. _Porting Guide: ./porting-guide.rst .. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html diff --git a/docs/plat/hikey.rst b/docs/plat/hikey.rst index 99259f3a7..5c0a9276d 100644 --- a/docs/plat/hikey.rst +++ b/docs/plat/hikey.rst @@ -11,7 +11,7 @@ How to build Code Locations -------------- -- ARM Trusted Firmware: +- Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ - OP-TEE @@ -76,13 +76,13 @@ Build Procedure export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools export EDK2_DIR=${BUILD_PATH}/edk2 EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN} - # Build fastboot for ARM Trust Firmware. It's used for recovery mode. + # Build fastboot for Trusted Firmware-A. It's used for recovery mode. cd ${BUILD_PATH}/atf-fastboot CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1 # Convert DEBUG/RELEASE to debug/release FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]') cd ${EDK2_DIR} - # Build UEFI & ARM Trust Firmware + # Build UEFI & Trusted Firmware-A ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey - Generate l-loader.bin and partition table for aosp. The eMMC capacity is either 8GB or 4GB. Just change "aosp-8g" to "linux-8g" for debian. @@ -91,6 +91,7 @@ Build Procedure cd ${BUILD_PATH}/l-loader ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin + ln -sf ${EDK2_OUTPUT_DIR}/FV/bl2.bin ln -sf ${BUILD_PATH}/atf-fastboot/build/hikey/${FASTBOOT_BUILD_OPTION}/bl1.bin fastboot.bin make hikey PTABLE_LST=aosp-8g @@ -142,17 +143,18 @@ Flash images in recovery mode $sudo apt-get purge modemmanager -- Run the command to download l-loader.bin into HiKey. +- Run the command to download recovery.bin into HiKey. .. code:: shell - $sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 l-loader.bin + $sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 recovery.bin - Update images. All aosp or debian images could be fetched from `link <https://builds.96boards.org/>`__. .. code:: shell $sudo fastboot flash ptable prm_ptable.img + $sudo fastboot flash loader l-loader.bin $sudo fastboot flash fastboot fip.bin $sudo fastboot flash boot boot.img $sudo fastboot flash cache cache.img diff --git a/docs/plat/hikey960.rst b/docs/plat/hikey960.rst index 8524b48af..7900b6dfb 100644 --- a/docs/plat/hikey960.rst +++ b/docs/plat/hikey960.rst @@ -11,7 +11,7 @@ How to build Code Locations -------------- -- ARM Trusted Firmware: +- Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ - OP-TEE: @@ -73,7 +73,7 @@ Build Procedure export EDK2_DIR=${BUILD_PATH}/edk2 EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN} cd ${EDK2_DIR} - # Build UEFI & ARM Trust Firmware + # Build UEFI & Trusted Firmware-A ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey960 - Generate l-loader.bin and partition table. @@ -83,6 +83,7 @@ Build Procedure cd ${BUILD_PATH}/l-loader ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin + ln -sf ${EDK2_OUTPUT_DIR}/FV/bl2.bin ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin ln -sf ${EDK2_OUTPUT_DIR}/FV/BL33_AP_UEFI.fd make hikey960 @@ -130,13 +131,14 @@ Boot UEFI in recovery mode - Fetch that are used in recovery mode. The code location is in below. `link <https://github.com/96boards-hikey/tools-images-hikey960>`__ -- Generate l-loader.bin. +- Prepare recovery binary. .. code:: shell $cd tools-images-hikey960 $ln -sf ${BUILD_PATH}/l-loader/l-loader.bin $ln -sf ${BUILD_PATH}/l-loader/fip.bin + $ln -sf ${BUILD_PATH}/l-loader/recovery.bin - Prepare config file. @@ -146,7 +148,7 @@ Boot UEFI in recovery mode # The content of config file ./sec_usb_xloader.img 0x00020000 ./sec_uce_boot.img 0x6A908000 - ./l-loader.bin 0x1AC00000 + ./recovery.bin 0x1AC00000 - Remove the modemmanager package. This package may causes hikey\_idt tool failure. @@ -154,7 +156,7 @@ Boot UEFI in recovery mode $sudo apt-get purge modemmanager -- Run the command to download l-loader.bin into HiKey960. +- Run the command to download recovery.bin into HiKey960. .. code:: shell diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst index 7aac7e531..56dfacfc8 100644 --- a/docs/plat/nvidia-tegra.rst +++ b/docs/plat/nvidia-tegra.rst @@ -4,10 +4,10 @@ Tegra SoCs - Overview - .. rubric:: T210 :name: t210 -T210 has Quad ARM® Cortex®-A57 cores in a switched configuration with a -companion set of quad ARM Cortex-A53 cores. The Cortex-A57 and A53 cores -support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code -including legacy ARMv7 applications. The Cortex-A57 processors each have +T210 has Quad Arm® Cortex®-A57 cores in a switched configuration with a +companion set of quad Arm Cortex-A53 cores. The Cortex-A57 and A53 cores +support Armv8-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code +including legacy Armv7-A applications. The Cortex-A57 processors each have 48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache. @@ -16,7 +16,7 @@ and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache. :name: t132 Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is -fully ARMv8 architecture compatible. Each of the two Denver cores +fully Armv8-A architecture compatible. Each of the two Denver cores implements a 7-way superscalar microarchitecture (up to 7 concurrent micro-ops can be executed per clock), and includes a 128KB 4-way L1 instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2 @@ -94,5 +94,5 @@ Tegra configs ============= - 'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity - Protection bit, for ARM Cortex-A57 CPUs, during CPU boot. This flag will + Protection bit, for Arm Cortex-A57 CPUs, during CPU boot. This flag will be enabled by Tegrs SoCs during 'Cluster power up' or 'System Suspend' exit. diff --git a/docs/plat/poplar.rst b/docs/plat/poplar.rst index 012947839..5884ed945 100644 --- a/docs/plat/poplar.rst +++ b/docs/plat/poplar.rst @@ -5,7 +5,7 @@ Poplar is the first development board compliant with the 96Boards Enterprise Edition TV Platform specification. The board features the Hi3798C V200 with an integrated quad-core 64-bit -ARM Cortex A53 processor and high performance Mali T720 GPU, making it capable +Arm Cortex A53 processor and high performance Mali T720 GPU, making it capable of running any commercial set-top solution based on Linux or Android. It supports a premium user experience with up to H.265 HEVC decoding of 4K @@ -14,7 +14,7 @@ video at 60 frames per second. :: SOC Hisilicon Hi3798CV200 - CPU Quad-core ARM Cortex-A53 64 bit + CPU Quad-core Arm Cortex-A53 64 bit DRAM DDR3/3L/4 SDRAM interface, maximum 32-bit data width 2 GB USB Two USB 2.0 ports One USB 3.0 ports CONSOLE USB-micro port for console support @@ -28,11 +28,11 @@ video at 60 frames per second. At the start of the boot sequence, the bootROM executes the so called l-loader binary whose main role is to change the processor state to 64bit mode. This -must happen prior invoking the arm trusted firmware: +must happen prior to invoking Trusted Firmware-A: :: - l-loader --> arm_trusted_firmware --> u-boot + l-loader --> Trusted Firmware-A --> u-boot How to build ============ @@ -40,7 +40,7 @@ How to build Code Locations -------------- -- ARM Trusted Firmware: +- Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ - l-loader: diff --git a/docs/plat/qemu.rst b/docs/plat/qemu.rst index 4e2cd7c5d..57ed6293d 100644 --- a/docs/plat/qemu.rst +++ b/docs/plat/qemu.rst @@ -1,8 +1,8 @@ -ARM Trusted Firmware for QEMU virt ARMv8-A -========================================== +Trusted Firmware-A for QEMU virt Armv8-A +======================================== -ARM Trusted Firmware implements the EL3 firmware layer for QEMU virt -ARMv8-A. BL1 is used as the BootROM, supplied with the -bios argument. +Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU virt +Armv8-A. BL1 is used as the BootROM, supplied with the -bios argument. When QEMU starts all CPUs are released simultaneously, BL1 selects a primary CPU to handle the boot and the secondaries are placed in a polling loop to be released by normal world via PSCI. @@ -10,7 +10,7 @@ loop to be released by normal world via PSCI. BL2 edits the Flattened Device Tree, FDT, generated by QEMU at run-time to add a node describing PSCI and also enable methods for the CPUs. -An ARM64 defonfig v4.5 Linux kernel is known to boot, FTD doesn't need to be +An ARM64 defconfig v4.5 Linux kernel is known to boot, FDT doesn't need to be provided as it's generated by QEMU. Current limitations: diff --git a/docs/plat/rpi3.rst b/docs/plat/rpi3.rst index 219faaff5..c30110ede 100644 --- a/docs/plat/rpi3.rst +++ b/docs/plat/rpi3.rst @@ -1,5 +1,5 @@ -Arm Trusted Firmware for Raspberry Pi 3 -======================================= +Trusted Firmware-A for Raspberry Pi 3 +===================================== .. section-numbering:: :suffix: . @@ -7,16 +7,16 @@ Arm Trusted Firmware for Raspberry Pi 3 .. contents:: The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four -Cortex-A53 cores, which makes it possible to have a port of the Arm Trusted -Firmware. +Arm Cortex-A53 cores, which makes it possible to have a port of Trusted +Firmware-A (TF-A). -The following instructions explain how to use this port of the Trusted Firmware -with the default distribution of `Raspbian`_ because that's the distribution -officially supported by the Raspberry Pi Foundation. At the moment of writing -this, the officially supported kernel is a AArch32 kernel. This doesn't mean -that this port of the Trusted Firmware can't boot a AArch64 kernel. The `Linux -tree fork`_ maintained by the Foundation can be compiled for AArch64 by -following the steps in `AArch64 kernel build instructions`_. +The following instructions explain how to use this port of the TF-A with the +default distribution of `Raspbian`_ because that's the distribution officially +supported by the Raspberry Pi Foundation. At the moment of writing this, the +officially supported kernel is a AArch32 kernel. This doesn't mean that this +port of TF-A can't boot a AArch64 kernel. The `Linux tree fork`_ maintained by +the Foundation can be compiled for AArch64 by following the steps in +`AArch64 kernel build instructions`_. **IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM, which is available from both the Non-secure and Secure worlds. This port @@ -46,15 +46,15 @@ The rules are simple: the cores are powered on at the same time and start at address **0x0**. This means that we can use the default AArch32 kernel provided in the official -`Raspbian`_ distribution by renaming it to ``kernel8.img``, while the Trusted -Firmware and anything else we need is in ``armstub8.bin``. This way we can -forget about the default bootstrap code. When using a AArch64 kernel, it is only -needed to make sure that the name on the SD card is ``kernel8.img``. +`Raspbian`_ distribution by renaming it to ``kernel8.img``, while TF-A and +anything else we need is in ``armstub8.bin``. This way we can forget about the +default bootstrap code. When using a AArch64 kernel, it is only needed to make +sure that the name on the SD card is ``kernel8.img``. Ideally, we want to load the kernel and have all cores available, which means that we need to make the secondary cores work in the way the kernel expects, as explained in `Secondary cores`_. In practice, a small bootstrap is needed -between the Trusted Firmware and the kernel. +between TF-A and the kernel. To get the most out of a AArch32 kernel, we want to boot it in Hypervisor mode in AArch32. This means that BL33 can't be in EL2 in AArch64 mode. The @@ -66,7 +66,7 @@ Placement of images The file ``armstub8.bin`` contains BL1 and the FIP. It is needed to add padding between them so that the addresses they are loaded to match the ones specified -when compiling the Trusted Firmware. +when compiling TF-A. The device tree block is loaded by the VideoCore loader from an appropriate file, but we can specify the address it is loaded to in ``config.txt``. @@ -87,8 +87,8 @@ There are no similar restrictions for AArch64 kernels, as specified in the file ``Documentation/arm64/booting.txt``. This means that we need to avoid the first 128 MiB of RAM when placing the -Trusted Firmware images (and specially the first 32 MiB, as they are directly -used to place the uncompressed AArch32 kernel image. This way, both AArch32 and +TF-A images (and specially the first 32 MiB, as they are directly used to +place the uncompressed AArch32 kernel image. This way, both AArch32 and AArch64 kernels can be placed at the same address. In the end, the images look like the following diagram when placed in memory. @@ -143,18 +143,17 @@ different mappings than the Arm cores in which the I/O addresses don't overlap the DRAM. The memory reserved to be used by the VideoCore is always placed at the end of the DRAM, so this space isn't wasted. -Considering the 128 MiB allocated to the GPU and the 16 MiB allocated for the -Trusted Firmware, there are 880 MiB available for Linux. +Considering the 128 MiB allocated to the GPU and the 16 MiB allocated for +TF-A, there are 880 MiB available for Linux. Boot sequence ~~~~~~~~~~~~~ -The boot sequence of the Trusted Firmware is the usual one except when booting -a AArch32 kernel. In that case, BL33 is booted in AArch32 Hypervisor mode so -that it can jump to the kernel in the same mode and let it take over that -privilege level. If BL33 was running in EL2 in AArch64 (as in the default -bootflow of the Trusted Firmware) it could only jump to the kernel in AArch32 in -Supervisor mode. +The boot sequence of TF-A is the usual one except when booting an AArch32 +kernel. In that case, BL33 is booted in AArch32 Hypervisor mode so that it +can jump to the kernel in the same mode and let it take over that privilege +level. If BL33 was running in EL2 in AArch64 (as in the default bootflow of +TF-A) it could only jump to the kernel in AArch32 in Supervisor mode. The `Linux kernel tree`_ has instructions on how to jump to the Linux kernel in ``Documentation/arm/Booting`` and ``Documentation/arm64/booting.txt``. The @@ -168,9 +167,9 @@ use mailboxes to trap the secondary cores until they are ready to jump to the kernel. This mailbox is located at a different address in the AArch32 default kernel than in the AArch64 kernel. -Also, this port of the Trusted Firmware has another Trusted Mailbox in Shared BL -RAM. During cold boot, all secondary cores wait in a loop until they are given -given an address to jump to in this Mailbox (``bl31_warm_entrypoint``). +Also, this port of TF-A has another Trusted Mailbox in Shared BL RAM. During +cold boot, all secondary cores wait in a loop until they are given given an +address to jump to in this Mailbox (``bl31_warm_entrypoint``). Once BL31 has finished and the primary core has jumped to the BL33 payload, it has to call ``PSCI_CPU_ON`` to release the secondary CPUs from the wait loop. @@ -188,11 +187,10 @@ To boot a AArch32 kernel, both AArch64 and AArch32 toolchains are required. The AArch32 toolchain is needed for the AArch32 bootstrap needed to load a 32-bit kernel. -First, clone and compile `Raspberry Pi 3 Arm Trusted Firmware bootstrap`_. -Choose the one needed for the architecture of your kernel. +First, clone and compile `Raspberry Pi 3 TF-A bootstrap`_. Choose the one +needed for the architecture of your kernel. -Then compile the Arm Trusted Firmware. For a AArch32 kernel, use the following -command line: +Then compile TF-A. For a AArch32 kernel, use the following command line: .. code:: shell @@ -219,8 +217,8 @@ by ``debug`` if you set the build option ``DEBUG=1``): cat bl1.pad.bin build/rpi3/release/fip.bin > armstub8.bin The resulting file, ``armstub8.bin``, contains BL1 and the FIP in the place they -need to be for the Trusted Firmware to boot correctly. Now, follow the -instructions in `Setup SD card`_. +need to be for TF-A to boot correctly. Now, follow the instructions in +`Setup SD card`_. The following build options are supported: @@ -235,17 +233,17 @@ The following build options are supported: is reserved by the command line passed to the kernel. - ``RPI3_BL33_IN_AARCH32``: This port can load a AArch64 or AArch32 BL33 image. - By default this option is 0, which means that the Trusted Firmware will jump - to BL33 in EL2 in AArch64 mode. If set to 1, it will jump to BL33 in - Hypervisor in AArch32 mode. + By default this option is 0, which means that TF-A will jump to BL33 in EL2 + in AArch64 mode. If set to 1, it will jump to BL33 in Hypervisor in AArch32 + mode. The following is not currently supported: -- AArch32 for the Trusted Firmware itself. +- AArch32 for TF-A itself. - ``EL3_PAYLOAD_BASE``: The reason is that you can already load anything to any address by changing the file ``armstub8.bin``, so there's no point in using - the Trusted Firmware in this case. + TF-A in this case. - ``LOAD_IMAGE_V2=0``: Only version 2 is supported. @@ -307,16 +305,16 @@ untouched). They have been tested with the image available in 2017-09-07. 1. Insert the SD card and open the ``boot`` partition. 2. Rename ``kernel7.img`` to ``kernel8.img``. This tricks the VideoCore - bootloader into booting the Arm cores in AArch64 mode, like the Trusted - Firmware needs, even though the kernel is not compiled for AArch64. + bootloader into booting the Arm cores in AArch64 mode, like TF-A needs, + even though the kernel is not compiled for AArch64. 3. Copy ``armstub8.bin`` here. When ``kernel8.img`` is available, The VideoCore bootloader will look for a file called ``armstub8.bin`` and load it at address **0x0** instead of a predefined one. 4. Open ``cmdline.txt`` and add ``memmap=256M$16M`` to prevent the kernel from - using the memory needed by the Trusted Firmware. If you want to enable the - serial port "Mini UART", make sure that this file also contains + using the memory needed by TF-A. If you want to enable the serial port + "Mini UART", make sure that this file also contains ``console=serial0,115200 console=tty1``. Note that the 16 MiB reserved this way won't be available for Linux, the same @@ -359,6 +357,6 @@ HDMI output won't show any text during boot. .. _Linux kernel tree: https://github.com/torvalds/linux .. _Linux tree fork: https://github.com/raspberrypi/linux .. _Raspberry Pi 3: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ -.. _Raspberry Pi 3 Arm Trusted Firmware bootstrap: https://github.com/AntonioND/rpi3-arm-tf-bootstrap +.. _Raspberry Pi 3 TF-A bootstrap: https://github.com/AntonioND/rpi3-arm-tf-bootstrap .. _Raspberry Pi 3 documentation: https://www.raspberrypi.org/documentation/ .. _Raspbian: https://www.raspberrypi.org/downloads/raspbian/ diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst index 590ff6253..37cab3b2a 100644 --- a/docs/plat/socionext-uniphier.rst +++ b/docs/plat/socionext-uniphier.rst @@ -1,19 +1,19 @@ -ARM Trusted Firmware for Socionext UniPhier SoCs -================================================ +Trusted Firmware-A for Socionext UniPhier SoCs +============================================== -Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world -firmware, supporting BL2 and BL31. +Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure +world firmware, supporting BL2 and BL31. UniPhier SoC family implements its internal boot ROM, which loads 64KB [1]_ image from a non-volatile storage to the on-chip SRAM, and jumps over to it. -ARM Trusted Firmware provides a special mode, BL2-AT-EL3, which enables BL2 to -execute at EL3. It is useful for platforms with non-TF boot ROM, like UniPhier. -Here, a problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ -(TBB) is enabled. To solve this issue, Socionext provides a first stage loader +TF-A provides a special mode, BL2-AT-EL3, which enables BL2 to execute at EL3. +It is useful for platforms with non-TF-A boot ROM, like UniPhier. Here, a +problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB) +is enabled. To solve this issue, Socionext provides a first stage loader called `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the DRAM, expands BL2 there, and hands the control over to it. Therefore, all images -of ARM Trusted Firmware run in DRAM. +of TF-A run in DRAM. The UniPhier platform works with/without TBB. See below for the build process of each case. The image authentication for the UniPhier platform fully @@ -46,7 +46,7 @@ Boot Flow This runs in the DRAM. It extracts more images such as BL31, BL33 (optionally SCP_BL2, BL32 as well) from Firmware Image Package (FIP). If TBB is enabled, - they are all authenticated by the standard mechanism of ARM Trusted Firmware. + they are all authenticated by the standard mechanism of TF-A. After loading all the images, it jumps to the BL31 entry. 4. BL31, BL32, and BL33 diff --git a/docs/plat/xilinx-zynqmp.rst b/docs/plat/xilinx-zynqmp.rst index b9c7825ba..428024148 100644 --- a/docs/plat/xilinx-zynqmp.rst +++ b/docs/plat/xilinx-zynqmp.rst @@ -1,12 +1,12 @@ -ARM Trusted Firmware for Xilinx Zynq UltraScale+ MPSoC -====================================================== +Trusted Firmware-A for Xilinx Zynq UltraScale+ MPSoC +==================================================== -ARM Trusted Firmware implements the EL3 firmware layer for Xilinx Zynq +Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Xilinx Zynq UltraScale + MPSoC. -The platform only uses the runtime part of ATF as ZynqMP already has a +The platform only uses the runtime part of TF-A as ZynqMP already has a BootROM (BL1) and FSBL (BL2). -BL31 is ATF. +BL31 is TF-A. BL32 is an optional Secure Payload. BL33 is the non-secure world software (U-Boot, Linux etc). @@ -35,20 +35,20 @@ ZynqMP platform specific build options - ``cadence``, ``cadence0``: Cadence UART 0 - ``cadence1`` : Cadence UART 1 -FSBL->ATF Parameter Passing +FSBL->TF-A Parameter Passing =========================== -The FSBL populates a data structure with image information for the ATF. The ATF -uses that data to hand off to the loaded images. The address of the handoff data +The FSBL populates a data structure with image information for TF-A. TF-A uses +that data to hand off to the loaded images. The address of the handoff data structure is passed in the ``PMU_GLOBAL.GLOBAL_GEN_STORAGE6`` register. The -register is free to be used by other software once the ATF is bringing up +register is free to be used by other software once TF-A has brought up further firmware images. Power Domain Tree ================= -The following power domain tree represents the power domain model used by the -ATF for ZynqMP: +The following power domain tree represents the power domain model used by TF-A +for ZynqMP: :: diff --git a/docs/platform-interrupt-controller-API.rst b/docs/platform-interrupt-controller-API.rst index c14f00530..230a99055 100644 --- a/docs/platform-interrupt-controller-API.rst +++ b/docs/platform-interrupt-controller-API.rst @@ -24,7 +24,7 @@ This API should return the priority of the interrupt the PE is currently servicing. This must be be called only after an interrupt has already been acknowledged via. ``plat_ic_acknowledge_interrupt``. -In the case of ARM standard platforms using GIC, the *Running Priority Register* +In the case of Arm standard platforms using GIC, the *Running Priority Register* is read to determine the priority of the interrupt. Function: int plat_ic_is_spi(unsigned int id); [optional] @@ -77,7 +77,7 @@ Function: unsigned int plat_ic_get_interrupt_active(unsigned int id); [optional] This API should return the *active* status of the interrupt ID specified by the first parameter, ``id``. -In case of ARM standard platforms using GIC, the implementation of the API reads +In case of Arm standard platforms using GIC, the implementation of the API reads the GIC *Set Active Register* to read and return the active status of the interrupt. @@ -92,7 +92,7 @@ Function: void plat_ic_enable_interrupt(unsigned int id); [optional] This API should enable the interrupt ID specified by the first parameter, ``id``. PEs in the system are expected to receive only enabled interrupts. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API inserts barrier to make memory updates visible before enabling interrupt, and then writes to GIC *Set Enable Register* to enable the interrupt. @@ -107,7 +107,7 @@ Function: void plat_ic_disable_interrupt(unsigned int id); [optional] This API should disable the interrupt ID specified by the first parameter, ``id``. PEs in the system are not expected to receive disabled interrupts. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API writes to GIC *Clear Enable Register* to disable the interrupt, and inserts barrier to make memory updates visible afterwards. @@ -123,7 +123,7 @@ Function: void plat_ic_set_interrupt_priority(unsigned int id, unsigned int prio This API should set the priority of the interrupt specified by first parameter ``id`` to the value set by the second parameter ``priority``. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API writes to GIC *Priority Register* set interrupt priority. Function: int plat_ic_has_interrupt_type(unsigned int type); [optional] @@ -138,10 +138,10 @@ This API should return whether the platform supports a given interrupt type. The parameter ``type`` shall be one of ``INTR_TYPE_EL3``, ``INTR_TYPE_S_EL1``, or ``INTR_TYPE_NS``. -In case of ARM standard platforms using GICv3, the implementation of the API +In case of Arm standard platforms using GICv3, the implementation of the API returns ``1`` for all interrupt types. -In case of ARM standard platforms using GICv2, the API always return ``1`` for +In case of Arm standard platforms using GICv2, the API always return ``1`` for ``INTR_TYPE_NS``. Return value for other types depends on the value of build option ``GICV2_G0_FOR_EL3``: @@ -180,7 +180,7 @@ one of: - ``INTR_TYPE_EL3``: interrupt is meant to be consumed by EL3. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API writes to the GIC *Group Register* and *Group Modifier Register* (only GICv3) to assign the interrupt to the right group. @@ -213,7 +213,7 @@ This API should raise an EL3 SGI. The first parameter, ``sgi_num``, specifies the ID of the SGI. The second parameter, ``target``, must be the MPIDR of the target PE. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API inserts barrier to make memory updates visible before raising SGI, then writes to appropriate *SGI Register* in order to raise the EL3 SGI. @@ -239,7 +239,7 @@ The ``routing_mode`` parameter can be one of: - ``INTR_ROUTING_MODE_PE`` means the interrupt is routed to the PE whose MPIDR value is specified by the parameter ``mpidr``. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API writes to the GIC *Target Register* (GICv2) or *Route Register* (GICv3) to set the routing. @@ -254,7 +254,7 @@ Function: void plat_ic_set_interrupt_pending(unsigned int id); [optional] This API should set the interrupt specified by first parameter ``id`` to *Pending*. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API inserts barrier to make memory updates visible before setting interrupt pending, and writes to the GIC *Set Pending Register* to set the interrupt pending status. @@ -270,7 +270,7 @@ Function: void plat_ic_clear_interrupt_pending(unsigned int id); [optional] This API should clear the *Pending* status of the interrupt specified by first parameter ``id``. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API writes to the GIC *Clear Pending Register* to clear the interrupt pending status, and inserts barrier to make memory updates visible afterwards. @@ -287,7 +287,7 @@ controller such that only interrupts of higher priority than the supplied one may be signalled to the PE. The API should return the current priority value that it's overwriting. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API inserts to order memory updates before updating mask, then writes to the GIC *Priority Mask Register*, and make sure memory updates are visible before potential trigger due to mask update. @@ -305,9 +305,9 @@ obtained by the acknowledging the interrupt (read using ``plat_ic_acknowledge_interrupt()``). If the interrupt ID is invalid, this API should return ``INTR_ID_UNAVAILABLE``. -In case of ARM standard platforms using GIC, the implementation of the API +In case of Arm standard platforms using GIC, the implementation of the API masks out the interrupt ID field from the acknowledged value from GIC. ---- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/platform-migration-guide.rst b/docs/platform-migration-guide.rst index ca7554693..87d35f4f8 100644 --- a/docs/platform-migration-guide.rst +++ b/docs/platform-migration-guide.rst @@ -12,8 +12,8 @@ Guide to migrate to new Platform porting interface Introduction ------------ -The PSCI implementation in Trusted Firmware has undergone a redesign because of -three requirements that the PSCI 1.0 specification introduced : +The PSCI implementation in TF-A has undergone a redesign because of three +requirements that the PSCI 1.0 specification introduced : - Removing the framework assumption about the structure of the MPIDR, and its relation to the power topology enables support for deeper and more @@ -217,7 +217,7 @@ layer and the platform layer. Refer `plat/arm/board/fvp/fvp\_pm.c`_ for the implementation details of these handlers for the FVP. The commit `38dce70f51fb83b27958ba3e2ad15f5635cb1061`_ -demonstrates the migration of ARM reference platforms to the new platform API. +demonstrates the migration of Arm reference platforms to the new platform API. Miscellaneous modifications --------------------------- @@ -271,7 +271,7 @@ within its domain. It does so by storing the core index of first core within it and number of core indexes following it. This means that core indices returned by ``platform_get_core_pos()`` for cores within a particular power domain must be consecutive. We expect that this is the case for most -platform ports including ARM reference platforms. +platform ports including Arm reference platforms. The old PSCI helpers like ``psci_get_suspend_powerstate()``, ``psci_get_suspend_stateid()``, ``psci_get_suspend_stateid_by_mpidr()``, @@ -298,7 +298,7 @@ The mandatory macros to be defined by the platform port in ``platform_def.h`` - **#define : PLATFORM\_MAX\_AFFLVL** Defines the maximum affinity level that the power management operations - should apply to. ARMv8-A has support for four affinity levels. It is likely + should apply to. Armv8-A has support for four affinity levels. It is likely that hardware will implement fewer affinity levels. This macro allows the PSCI implementation to consider only those affinity levels in the system that the platform implements. For example, the Base AEM FVP implements two @@ -329,7 +329,7 @@ to handle the condition where the core has been warm reset but there is no entrypoint to jump to. This function does not follow the Procedure Call Standard used by the -Application Binary Interface for the ARM 64-bit architecture. The caller should +Application Binary Interface for the Arm 64-bit architecture. The caller should not assume that callee saved registers are preserved across a call to this function. @@ -410,7 +410,7 @@ Modifications for Power State Coordination Interface (in BL31) -------------------------------------------------------------- The following functions must be implemented to initialize PSCI functionality in -the ARM Trusted Firmware. +TF-A. Function : plat\_get\_aff\_count() [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -595,7 +595,7 @@ PSCI specification for the CPU\_SUSPEND API. -------------- -*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf .. _Porting Guide: porting-guide.rst#user-content-function--plat_my_core_pos diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst index 21db86bde..ff5bb1225 100644 --- a/docs/porting-guide.rst +++ b/docs/porting-guide.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware Porting Guide -================================== +Trusted Firmware-A Porting Guide +================================ .. section-numbering:: @@ -16,7 +16,7 @@ Please note that this document has been updated for the new platform API as required by the PSCI v1.0 implementation. Please refer to the `Migration Guide`_ for the previous platform API. -Porting the ARM Trusted Firmware to a new platform involves making some +Porting Trusted Firmware-A (TF-A) to a new platform involves making some mandatory and optional modifications for both the cold and warm boot paths. Modifications consist of: @@ -31,20 +31,19 @@ implementations are all weakly defined; they are provided to ease the porting effort. Each platform port can override them with its own implementation if the default implementation is inadequate. -Platform ports that want to be aligned with standard ARM platforms (for example +Platform ports that want to be aligned with standard Arm platforms (for example FVP and Juno) may also use `include/plat/arm/common/plat\_arm.h`_ and the corresponding source files in ``plat/arm/common/``. These provide standard implementations for some of the required platform porting functions. However, using these functions requires the platform port to implement additional -ARM standard platform porting functions. These additional functions are not +Arm standard platform porting functions. These additional functions are not documented here. Some modifications are common to all Boot Loader (BL) stages. Section 2 discusses these in detail. The subsequent sections discuss the remaining modifications for each BL stage in detail. -This document should be read in conjunction with the ARM Trusted Firmware -`User Guide`_. +This document should be read in conjunction with the TF-A `User Guide`_. Common modifications -------------------- @@ -67,11 +66,11 @@ only for re-mapping peripheral physical addresses and allows platforms with high I/O addresses to reduce their virtual address space. All other addresses corresponding to code and data must currently use an identity mapping. -Also, the only translation granule size supported in Trusted Firmware is 4KB, as -various parts of the code assume that is the case. It is not possible to switch -to 16 KB or 64 KB granule sizes at the moment. +Also, the only translation granule size supported in TF-A is 4KB, as various +parts of the code assume that is the case. It is not possible to switch to +16 KB or 64 KB granule sizes at the moment. -In ARM standard platforms, each BL stage configures the MMU in the +In Arm standard platforms, each BL stage configures the MMU in the platform-specific architecture setup function, ``blX_plat_arch_setup()``, and uses an identity mapping for all addresses. @@ -106,14 +105,14 @@ File : platform\_def.h [mandatory] Each platform must ensure that a header file of this name is in the system include path with the following constants defined. This may require updating the -list of ``PLAT_INCLUDES`` in the ``platform.mk`` file. In the ARM development +list of ``PLAT_INCLUDES`` in the ``platform.mk`` file. In the Arm development platforms, this file is found in ``plat/arm/board/<plat_name>/include/``. Platform ports may optionally use the file `include/plat/common/common\_def.h`_, which provides typical values for some of the constants below. These values are likely to be suitable for all platform ports. -Platform ports that want to be aligned with standard ARM platforms (for example +Platform ports that want to be aligned with standard Arm platforms (for example FVP and Juno) may also use `include/plat/arm/common/arm\_def.h`_, which provides standard values for some of the constants below. However, this requires the platform port to define additional platform porting constants in @@ -293,9 +292,9 @@ also be defined: - **#define : PLAT\_CRYPTOCELL\_BASE** - This defines the base address of ARM® TrustZone® CryptoCell and must be + This defines the base address of Arm® TrustZone® CryptoCell and must be defined if CryptoCell crypto driver is used for Trusted Board Boot. For - capable ARM platforms, this driver is used if ``ARM_CRYPTOCELL_INTEG`` is + capable Arm platforms, this driver is used if ``ARM_CRYPTOCELL_INTEG`` is set. If the AP Firmware Updater Configuration image, BL2U is used, the following @@ -322,7 +321,7 @@ must also be defined: SCP\_BL2U image identifier, used by BL1 to fetch an image descriptor corresponding to SCP\_BL2U. - NOTE: TF does not provide source code for this image. + NOTE: TF-A does not provide source code for this image. If the Non-Secure Firmware Updater ROM, NS\_BL1U is used, the following must also be defined: @@ -331,7 +330,7 @@ also be defined: Defines the base address in non-secure ROM where NS\_BL1U executes. Must be aligned on a page-size boundary. - NOTE: TF does not provide source code for this image. + NOTE: TF-A does not provide source code for this image. - **#define : NS\_BL1U\_IMAGE\_ID** @@ -345,7 +344,7 @@ be defined: Defines the base address in non-secure memory where NS\_BL2U executes. Must be aligned on a page-size boundary. - NOTE: TF does not provide source code for this image. + NOTE: TF-A does not provide source code for this image. - **#define : NS\_BL2U\_IMAGE\_ID** @@ -507,7 +506,7 @@ required memory within the the per-cpu data to minimize wastage. structure for use by the platform layer. The following constants are optional. They should be defined when the platform -memory layout implies some image overlaying like in ARM standard platforms. +memory layout implies some image overlaying like in Arm standard platforms. - **#define : BL31\_PROGBITS\_LIMIT** @@ -569,7 +568,7 @@ File : plat\_macros.S [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each platform must ensure a file of this name is in the system include path with -the following macro defined. In the ARM development platforms, this file is +the following macro defined. In the Arm development platforms, this file is found in ``plat/arm/board/<plat_name>/include/plat_macros.S``. - **Macro : plat\_crash\_print\_regs** @@ -620,7 +619,7 @@ reset entrypoint point provided to ``plat_setup_psci_ops()`` during BL31 initialization. If it's a cold reset then this function must return zero. This function does not follow the Procedure Call Standard used by the -Application Binary Interface for the ARM 64-bit architecture. The caller should +Application Binary Interface for the Arm 64-bit architecture. The caller should not assume that callee saved registers are preserved across a call to this function. @@ -644,7 +643,7 @@ for placing the executing secondary CPU in a platform-specific state until the primary CPU performs the necessary actions to bring it out of that state and allow entry into the OS. This function must not return. -In the ARM FVP port, when using the normal boot flow, each secondary CPU powers +In the Arm FVP port, when using the normal boot flow, each secondary CPU powers itself off. The primary CPU is responsible for powering up the secondary CPUs when normal world software requires them. When booting an EL3 payload instead, they stay powered on and are put in a holding pen until their mailbox gets @@ -827,9 +826,9 @@ This function validates the ``MPIDR`` of a CPU and converts it to an index, which can be used as a CPU-specific linear index into blocks of memory. In case the ``MPIDR`` is invalid, this function returns -1. This function will only be invoked by BL31 after the power domain topology is initialized and can -utilize the C runtime environment. For further details about how ARM Trusted -Firmware represents the power domain topology and how this relates to the -linear CPU index, please refer `Power Domain Topology Design`_. +utilize the C runtime environment. For further details about how TF-A +represents the power domain topology and how this relates to the linear CPU +index, please refer `Power Domain Topology Design`_. Common optional modifications ----------------------------- @@ -896,8 +895,7 @@ about the way the platform displays its status information. For AArch64, this function receives the exception type as its argument. Possible values for exceptions types are listed in the `include/common/bl\_common.h`_ header file. Note that these constants are not -related to any architectural exception code; they are just an ARM Trusted -Firmware convention. +related to any architectural exception code; they are just a TF-A convention. For AArch32, this function receives the exception mode as its argument. Possible values for exception modes are listed in the @@ -954,8 +952,8 @@ Possible errors reported by the generic code are: Board Boot is enabled) - ``-ENOENT``: the requested image or certificate could not be found or an IO error was detected -- ``-ENOMEM``: resources exhausted. Trusted Firmware does not use dynamic - memory, so this error is usually an indication of an incorrect array size +- ``-ENOMEM``: resources exhausted. TF-A does not use dynamic memory, so this + error is usually an indication of an incorrect array size The default implementation simply spins. @@ -996,9 +994,9 @@ Function : plat\_get\_next\_bl\_params() Return : bl_params_t * This function returns a pointer to the shared memory that the platform has -kept aside to pass trusted firmware related information that next BL image -needs. This function is currently invoked in BL2 to pass this information to -the next BL image, when LOAD\_IMAGE\_V2 is enabled. +kept aside to pass TF-A related information that next BL image needs. This +function is currently invoked in BL2 to pass this information to the next BL +image, when LOAD\_IMAGE\_V2 is enabled. Function : plat\_get\_stack\_protector\_canary() ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1039,11 +1037,11 @@ Function : plat\_log\_get\_prefix() Return : const char * This function defines the prefix string corresponding to the `log_level` to be -prepended to all the log output from ARM Trusted Firmware. The `log_level` -(argument) will correspond to one of the standard log levels defined in -debug.h. The platform can override the common implementation to define a -different prefix string for the log output. The implementation should be -robust to future changes that increase the number of log levels. +prepended to all the log output from TF-A. The `log_level` (argument) will +correspond to one of the standard log levels defined in debug.h. The platform +can override the common implementation to define a different prefix string for +the log output. The implementation should be robust to future changes that +increase the number of log levels. Modifications specific to a Boot Loader stage --------------------------------------------- @@ -1076,20 +1074,16 @@ warm boot. For each CPU, BL1 is responsible for the following tasks: allocation to BL2 meminfo.free_size = Size of secure RAM available for allocation to BL2 - BL1 places this ``meminfo`` structure at the beginning of the free memory - available for its use. Since BL1 cannot allocate memory dynamically at the - moment, its free memory will be available for BL2's use as-is. However, this - means that BL2 must read the ``meminfo`` structure before it starts using its - free memory (this is discussed in Section 3.2). + By default, BL1 places this ``meminfo`` structure at the beginning of the + free memory available for its use. Since BL1 cannot allocate memory + dynamically at the moment, its free memory will be available for BL2's use + as-is. However, this means that BL2 must read the ``meminfo`` structure + before it starts using its free memory (this is discussed in Section 3.2). - In future releases of the ARM Trusted Firmware it will be possible for - the platform to decide where it wants to place the ``meminfo`` structure for - BL2. - - BL1 implements the ``bl1_init_bl2_mem_layout()`` function to populate the - BL2 ``meminfo`` structure. The platform may override this implementation, for - example if the platform wants to restrict the amount of memory visible to - BL2. Details of how to do this are given below. + It is possible for the platform to decide where it wants to place the + ``meminfo`` structure for BL2 or restrict the amount of memory visible to + BL2 by overriding the weak default implementation of + ``bl1_plat_handle_post_image_load`` API. The following functions need to be implemented by the platform port to enable BL1 to perform the above tasks. @@ -1105,7 +1099,7 @@ Function : bl1\_early\_platform\_setup() [mandatory] This function executes with the MMU and data caches disabled. It is only called by the primary CPU. -On ARM standard platforms, this function: +On Arm standard platforms, this function: - Enables a secure instance of SP805 to act as the Trusted Watchdog. @@ -1128,7 +1122,7 @@ This function performs any platform-specific and architectural setup that the platform requires. Platform-specific setup might include configuration of memory controllers and the interconnect. -In ARM standard platforms, this function enables the MMU. +In Arm standard platforms, this function enables the MMU. This function helps fulfill requirement 2 above. @@ -1147,7 +1141,7 @@ MMU and data cache have been enabled. if support for multiple boot sources is required, it initializes the boot sequence used by plat\_try\_next\_boot\_source(). -In ARM standard platforms, this function initializes the storage abstraction +In Arm standard platforms, this function initializes the storage abstraction layer used to load the next bootloader image. This function helps fulfill requirement 4 above. @@ -1220,7 +1214,7 @@ loaded and executed. If the platform returns ``BL2_IMAGE_ID`` then BL1 proceeds with the normal boot sequence, which loads and executes BL2. If the platform returns a different image id, BL1 assumes that Firmware Update is required. -The default implementation always returns ``BL2_IMAGE_ID``. The ARM development +The default implementation always returns ``BL2_IMAGE_ID``. The Arm development platforms override this function to detect if firmware update is required, and if so, return the first image in the firmware update process. @@ -1235,7 +1229,7 @@ Function : bl1\_plat\_get\_image\_desc() [optional] BL1 calls this function to get the image descriptor information ``image_desc_t`` for the provided ``image_id`` from the platform. -The default implementation always returns a common BL2 image descriptor. ARM +The default implementation always returns a common BL2 image descriptor. Arm standard platforms return an image descriptor corresponding to BL2 or one of the firmware update images defined in the Trusted Board Boot Requirements specification. @@ -1264,6 +1258,12 @@ This function can be used by the platforms to update/use image information corresponding to ``image_id``. This function is invoked in BL1, both in cold boot and FWU code path, after loading and authenticating the image. +The default weak implementation of this function calculates the amount of +Trusted SRAM that can be used by BL2 and allocates a ``meminfo_t`` +structure at the beginning of this free memory and populates it. The address +of ``meminfo_t`` structure is updated in ``arg1`` of the entrypoint +information to BL2. + Function : bl1\_plat\_fwu\_done() [optional] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1369,7 +1369,7 @@ variable as the original memory may be subsequently overwritten by BL2. The copied structure is made available to all BL2 code through the ``bl2_plat_sec_mem_layout()`` function. -On ARM standard platforms, this function also: +On Arm standard platforms, this function also: - Initializes a UART (PL011 console), which enables access to the ``printf`` family of functions in BL2. @@ -1392,7 +1392,7 @@ by the primary CPU. The purpose of this function is to perform any architectural initialization that varies across platforms. -On ARM standard platforms, this function enables the MMU. +On Arm standard platforms, this function enables the MMU. Function : bl2\_platform\_setup() [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1409,7 +1409,7 @@ called by the primary CPU. The purpose of this function is to perform any platform initialization specific to BL2. -In ARM standard platforms, this function performs security setup, including +In Arm standard platforms, this function performs security setup, including configuration of the TrustZone controller to allow non-secure masters access to most of DRAM. Part of DRAM is reserved for secure world use. @@ -1524,7 +1524,7 @@ BL2 platform code returns a pointer which is used to populate the entry point information for BL31 entry point. The location pointed by it should be accessible from BL1 while processing the synchronous exception to run to BL31. -In ARM standard platforms this is allocated inside a bl2\_to\_bl31\_params\_mem +In Arm standard platforms this is allocated inside a bl2\_to\_bl31\_params\_mem structure in BL2 memory. Function : bl2\_plat\_set\_bl31\_ep\_info() [mandatory] @@ -1662,8 +1662,8 @@ of this always returns 0. Boot Loader Stage 2 (BL2) at EL3 -------------------------------- -When the platform has a non-TF Boot ROM it is desirable to jump -directly to BL2 instead of TF BL1. In this case BL2 is expected to +When the platform has a non-TF-A Boot ROM it is desirable to jump +directly to BL2 instead of TF-A BL1. In this case BL2 is expected to execute at EL3 instead of executing at EL1. Refer to the `Firmware Design`_ for more information. @@ -1685,7 +1685,7 @@ This function executes with the MMU and data caches disabled. It is only called by the primary CPU. This function receives four parameters which can be used by the platform to pass any needed information from the Boot ROM to BL2. -On ARM standard platforms, this function does the following: +On Arm standard platforms, this function does the following: - Initializes a UART (PL011 console), which enables access to the ``printf`` family of functions in BL2. @@ -1709,7 +1709,7 @@ by the primary CPU. The purpose of this function is to perform any architectural initialization that varies across platforms. -On ARM standard platforms, this function enables the MMU. +On Arm standard platforms, this function enables the MMU. Function : bl2\_el3\_plat\_prepare\_exit() [optional] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1738,7 +1738,7 @@ process and is executed only by the primary CPU. BL1 passes control to BL2U at If ``SCP_BL2U_BASE`` is not defined then this step is not performed. #. Any platform specific setup required to perform the FWU process. For - example, ARM standard platforms initialize the TZC controller so that the + example, Arm standard platforms initialize the TZC controller so that the normal world can access DDR memory. The following functions must be implemented by the platform port to enable @@ -1759,7 +1759,7 @@ of the ``meminfo`` structure and platform specific info provided by BL1. The platform may copy the contents of the ``mem_info`` and ``plat_info`` into private storage as the original memory may be subsequently overwritten by BL2U. -On ARM CSS platforms ``plat_info`` is interpreted as an ``image_info_t`` structure, +On Arm CSS platforms ``plat_info`` is interpreted as an ``image_info_t`` structure, to extract SCP\_BL2U image information, which is then copied into a private variable. @@ -1793,7 +1793,7 @@ called by the primary CPU. The purpose of this function is to perform any platform initialization specific to BL2U. -In ARM standard platforms, this function performs security setup, including +In Arm standard platforms, this function performs security setup, including configuration of the TrustZone controller to allow non-secure masters access to most of DRAM. Part of DRAM is reserved for secure world use. @@ -1866,7 +1866,7 @@ sub-structures into private variables if the original memory may be subsequently overwritten by BL31 and similarly the ``void *`` pointing to the platform data also needs to be saved. -In ARM standard platforms, BL2 passes a pointer to a ``bl31_params`` structure +In Arm standard platforms, BL2 passes a pointer to a ``bl31_params`` structure in BL2 memory. BL31 copies the information in this pointer to internal data structures. It also performs the following: @@ -1891,7 +1891,7 @@ by the primary CPU. The purpose of this function is to perform any architectural initialization that varies across platforms. -On ARM standard platforms, this function enables the MMU. +On Arm standard platforms, this function enables the MMU. Function : bl31\_platform\_setup() [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1908,7 +1908,7 @@ called by the primary CPU. The purpose of this function is to complete platform initialization so that both BL31 runtime services and normal world software can function correctly. -On ARM standard platforms, this function does the following: +On Arm standard platforms, this function does the following: - Initialize the generic interrupt controller. @@ -1976,7 +1976,7 @@ Function : plat\_get\_syscnt\_freq2() [mandatory] This function is used by the architecture setup code to retrieve the counter frequency for the CPU's generic timer. This value will be programmed into the -``CNTFRQ_EL0`` register. In ARM standard platforms, it returns the base frequency +``CNTFRQ_EL0`` register. In Arm standard platforms, it returns the base frequency of the system counter, which is retrieved from the first entry in the frequency modes table. @@ -2043,7 +2043,7 @@ argument, which is the address of the handler the SDEI client requested to register. The function must return ``0`` for successful validation, or ``-1`` upon failure. -The default implementation always returns ``0``. On ARM platforms, this function +The default implementation always returns ``0``. On Arm platforms, this function is implemented to translate the entry point to physical address, and further to ensure that the address is located in Non-secure DRAM. @@ -2070,18 +2070,18 @@ The default implementation only prints out a warning message. Power State Coordination Interface (in BL31) -------------------------------------------- -The ARM Trusted Firmware's implementation of the PSCI API is based around the -concept of a *power domain*. A *power domain* is a CPU or a logical group of -CPUs which share some state on which power management operations can be -performed as specified by `PSCI`_. Each CPU in the system is assigned a cpu -index which is a unique number between ``0`` and ``PLATFORM_CORE_COUNT - 1``. -The *power domains* are arranged in a hierarchical tree structure and -each *power domain* can be identified in a system by the cpu index of any CPU -that is part of that domain and a *power domain level*. A processing element -(for example, a CPU) is at level 0. If the *power domain* node above a CPU is -a logical grouping of CPUs that share some state, then level 1 is that group -of CPUs (for example, a cluster), and level 2 is a group of clusters -(for example, the system). More details on the power domain topology and its +The TF-A implementation of the PSCI API is based around the concept of a +*power domain*. A *power domain* is a CPU or a logical group of CPUs which +share some state on which power management operations can be performed as +specified by `PSCI`_. Each CPU in the system is assigned a cpu index which is +a unique number between ``0`` and ``PLATFORM_CORE_COUNT - 1``. The +*power domains* are arranged in a hierarchical tree structure and each +*power domain* can be identified in a system by the cpu index of any CPU that +is part of that domain and a *power domain level*. A processing element (for +example, a CPU) is at level 0. If the *power domain* node above a CPU is a +logical grouping of CPUs that share some state, then level 1 is that group of +CPUs (for example, a cluster), and level 2 is a group of clusters (for +example, the system). More details on the power domain topology and its organization can be found in `Power Domain Topology Design`_. BL31's platform initialization code exports a pointer to the platform-specific @@ -2221,12 +2221,12 @@ platform-specific psci power management actions by populating the passed pointer with a pointer to BL31's private ``plat_psci_ops`` structure. A description of each member of this structure is given below. Please refer to -the ARM FVP specific implementation of these handlers in +the Arm FVP specific implementation of these handlers in `plat/arm/board/fvp/fvp\_pm.c`_ as an example. For each PSCI function that the platform wants to support, the associated operation or operations in this structure must be provided and implemented (Refer section 4 of -`Firmware Design`_ for the PSCI API supported in Trusted Firmware). To disable -a PSCI function in a platform port, the operation should be removed from this +`Firmware Design`_ for the PSCI API supported in TF-A). To disable a PSCI +function in a platform port, the operation should be removed from this structure instead of providing an empty implementation. plat\_psci\_ops.cpu\_standby() @@ -2509,14 +2509,14 @@ state or EL3/S-EL1 in the secure state. The design of this framework is described in the `IMF Design Guide`_ A platform should export the following APIs to support the IMF. The following -text briefly describes each api and its implementation in ARM standard +text briefly describes each api and its implementation in Arm standard platforms. The API implementation depends upon the type of interrupt controller -present in the platform. ARM standard platform layer supports both -`ARM Generic Interrupt Controller version 2.0 (GICv2)`_ -and `3.0 (GICv3)`_. Juno builds the ARM -Standard layer to use GICv2 and the FVP can be configured to use either GICv2 or -GICv3 depending on the build flag ``FVP_USE_GIC_DRIVER`` (See FVP platform -specific build options in `User Guide`_ for more details). +present in the platform. Arm standard platform layer supports both +`Arm Generic Interrupt Controller version 2.0 (GICv2)`_ +and `3.0 (GICv3)`_. Juno builds the Arm platform layer to use GICv2 and the +FVP can be configured to use either GICv2 or GICv3 depending on the build flag +``FVP_USE_GIC_DRIVER`` (See FVP platform specific build options in +`User Guide`_ for more details). See also: `Interrupt Controller Abstraction APIs`__. @@ -2530,7 +2530,7 @@ Function : plat\_interrupt\_type\_to\_line() [mandatory] Argument : uint32_t, uint32_t Return : uint32_t -The ARM processor signals an interrupt exception either through the IRQ or FIQ +The Arm processor signals an interrupt exception either through the IRQ or FIQ interrupt line. The specific line that is signaled depends on how the interrupt controller (IC) reports different interrupt types from an execution context in either security state. The IMF uses this API to determine which interrupt line @@ -2543,11 +2543,11 @@ security state of the originating execution context. The return result is the bit position in the ``SCR_EL3`` register of the respective interrupt trap: IRQ=1, FIQ=2. -In the case of ARM standard platforms using GICv2, S-EL1 interrupts are +In the case of Arm standard platforms using GICv2, S-EL1 interrupts are configured as FIQs and Non-secure interrupts as IRQs from either security state. -In the case of ARM standard platforms using GICv3, the interrupt line to be +In the case of Arm standard platforms using GICv3, the interrupt line to be configured depends on the security state of the execution context when the interrupt is signalled and are as follows: @@ -2572,7 +2572,7 @@ handler function. ``INTR_TYPE_INVAL`` is returned when there is no interrupt pending. The valid interrupt types that can be returned are ``INTR_TYPE_EL3``, ``INTR_TYPE_S_EL1`` and ``INTR_TYPE_NS``. This API must be invoked at EL3. -In the case of ARM standard platforms using GICv2, the *Highest Priority +In the case of Arm standard platforms using GICv2, the *Highest Priority Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of the pending interrupt. The type of interrupt depends upon the id value as follows. @@ -2581,7 +2581,7 @@ follows. #. id = 1022 is reported as a Non-secure interrupt. #. id = 1023 is reported as an invalid interrupt type. -In the case of ARM standard platforms using GICv3, the system register +In the case of Arm standard platforms using GICv3, the system register ``ICC_HPPIR0_EL1``, *Highest Priority Pending group 0 Interrupt Register*, is read to determine the id of the pending interrupt. The type of interrupt depends upon the id value as follows. @@ -2603,7 +2603,7 @@ This API returns the id of the highest priority pending interrupt at the platform IC. ``INTR_ID_UNAVAILABLE`` is returned when there is no interrupt pending. -In the case of ARM standard platforms using GICv2, the *Highest Priority +In the case of Arm standard platforms using GICv2, the *Highest Priority Pending Interrupt Register* (``GICC_HPPIR``) is read to determine the id of the pending interrupt. The id that is returned by API depends upon the value of the id read from the interrupt controller as follows. @@ -2614,7 +2614,7 @@ the id read from the interrupt controller as follows. This id is returned by the API. #. id = 1023. ``INTR_ID_UNAVAILABLE`` is returned. -In the case of ARM standard platforms using GICv3, if the API is invoked from +In the case of Arm standard platforms using GICv3, if the API is invoked from EL3, the system register ``ICC_HPPIR0_EL1``, *Highest Priority Pending Interrupt group 0 Register*, is read to determine the id of the pending interrupt. The id that is returned by API depends upon the value of the id read from the @@ -2649,12 +2649,12 @@ The actual interrupt number shall be extracted from this raw value using the API .. __: platform-interrupt-controller-API.rst#function-unsigned-int-plat-ic-get-interrupt-id-unsigned-int-raw-optional -This function in ARM standard platforms using GICv2, reads the *Interrupt +This function in Arm standard platforms using GICv2, reads the *Interrupt Acknowledge Register* (``GICC_IAR``). This changes the state of the highest priority pending interrupt from pending to active in the interrupt controller. It returns the value read from the ``GICC_IAR``, unmodified. -In the case of ARM standard platforms using GICv3, if the API is invoked +In the case of Arm standard platforms using GICv3, if the API is invoked from EL3, the function reads the system register ``ICC_IAR0_EL1``, *Interrupt Acknowledge Register group 0*. If the API is invoked from S-EL1, the function reads the system register ``ICC_IAR1_EL1``, *Interrupt Acknowledge Register @@ -2678,7 +2678,7 @@ the interrupt corresponding to the id (passed as the parameter) has finished. The id should be the same as the id returned by the ``plat_ic_acknowledge_interrupt()`` API. -ARM standard platforms write the id to the *End of Interrupt Register* +Arm standard platforms write the id to the *End of Interrupt Register* (``GICC_EOIR``) in case of GICv2, and to ``ICC_EOIR0_EL1`` or ``ICC_EOIR1_EL1`` system register in case of GICv3 depending on where the API is invoked from, EL3 or S-EL1. This deactivates the corresponding interrupt in the interrupt @@ -2701,12 +2701,12 @@ interrupt type (one of ``INTR_TYPE_EL3``, ``INTR_TYPE_S_EL1`` and ``INTR_TYPE_NS returned depending upon how the interrupt has been configured by the platform IC. This API must be invoked at EL3. -ARM standard platforms using GICv2 configures S-EL1 interrupts as Group0 interrupts +Arm standard platforms using GICv2 configures S-EL1 interrupts as Group0 interrupts and Non-secure interrupts as Group1 interrupts. It reads the group value corresponding to the interrupt id from the relevant *Interrupt Group Register* (``GICD_IGROUPRn``). It uses the group value to determine the type of interrupt. -In the case of ARM standard platforms using GICv3, both the *Interrupt Group +In the case of Arm standard platforms using GICv3, both the *Interrupt Group Register* (``GICD_IGROUPRn``) and *Interrupt Group Modifier Register* (``GICD_IGRPMODRn``) is read to figure out whether the interrupt is configured as Group 0 secure interrupt, Group 1 secure interrupt or Group 1 NS interrupt. @@ -2827,10 +2827,10 @@ C Library To avoid subtle toolchain behavioral dependencies, the header files provided by the compiler are not used. The software is built with the ``-nostdinc`` flag to ensure no headers are included from the toolchain inadvertently. Instead the -required headers are included in the ARM Trusted Firmware source tree. The -library only contains those C library definitions required by the local -implementation. If more functionality is required, the needed library functions -will need to be added to the local implementation. +required headers are included in the TF-A source tree. The library only +contains those C library definitions required by the local implementation. If +more functionality is required, the needed library functions will need to be +added to the local implementation. Versions of `FreeBSD`_ headers can be found in ``include/lib/stdlib``. Some of these headers have been cut down in order to simplify the implementation. In @@ -2871,7 +2871,7 @@ required in their respective ``blx_platform_setup()`` functions. Currently storage access is only required by BL1 and BL2 phases. The ``load_image()`` function uses the storage layer to access non-volatile platform storage. -It is mandatory to implement at least one storage driver. For the ARM +It is mandatory to implement at least one storage driver. For the Arm development platforms the Firmware Image Package (FIP) driver is provided as the default means to load data from storage (see the "Firmware Image Package" section in the `User Guide`_). The storage layer is described in the header file @@ -2911,7 +2911,7 @@ amount of open resources per driver. -------------- -*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* .. _Migration Guide: platform-migration-guide.rst .. _include/plat/common/platform.h: ../include/plat/common/platform.h @@ -2929,6 +2929,6 @@ amount of open resources per driver. .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf .. _plat/arm/board/fvp/fvp\_pm.c: ../plat/arm/board/fvp/fvp_pm.c .. _IMF Design Guide: interrupt-framework-design.rst -.. _ARM Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html +.. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html .. _3.0 (GICv3): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0069b/index.html .. _FreeBSD: http://www.freebsd.org diff --git a/docs/psci-lib-integration-guide.rst b/docs/psci-lib-integration-guide.rst index 5e788d13c..47cbfcc8d 100644 --- a/docs/psci-lib-integration-guide.rst +++ b/docs/psci-lib-integration-guide.rst @@ -1,4 +1,4 @@ -PSCI Library Integration guide for ARMv8-A AArch32 systems +PSCI Library Integration guide for Armv8-A AArch32 systems ========================================================== @@ -8,7 +8,7 @@ PSCI Library Integration guide for ARMv8-A AArch32 systems .. contents:: This document describes the PSCI library interface with a focus on how to -integrate with a suitable Trusted OS for an ARMv8-A AArch32 system. The PSCI +integrate with a suitable Trusted OS for an Armv8-A AArch32 system. The PSCI Library implements the PSCI Standard as described in `PSCI spec`_ and is meant to be integrated with EL3 Runtime Software which invokes the PSCI Library interface appropriately. **EL3 Runtime Software** refers to software executing @@ -17,9 +17,10 @@ Monitor mode in AArch32, and provides runtime services to the non-secure world. The runtime service request is made via SMC (Secure Monitor Call) and the call must adhere to `SMCCC`_. In AArch32, EL3 Runtime Software may additionally include Trusted OS functionality. A minimal AArch32 Secure Payload, SP-MIN, is -provided in ARM Trusted Firmware to illustrate the usage and integration of the -PSCI library. The description of PSCI library interface and its integration -with EL3 Runtime Software in this document is targeted towards AArch32 systems. +provided in Trusted Firmware-A (TF-A) to illustrate the usage and integration +of the PSCI library. The description of PSCI library interface and its +integration with EL3 Runtime Software in this document is targeted towards +AArch32 systems. Generic call sequence for PSCI Library interface (AArch32) ---------------------------------------------------------- @@ -260,7 +261,7 @@ argument) determines the PSCI API to be called. The ``x1`` to ``x4`` (2nd to 5th arguments), are the values of the registers r1 - r4 (in AArch32) or x1 - x4 (in AArch64) when the SMC is received. These are the arguments to PSCI API as described in `PSCI spec`_. The 'flags' (8th argument) is a bit field parameter -and is detailed in 'smcc.h' header. It includes whether the call is from the +and is detailed in 'smccc.h' header. It includes whether the call is from the secure or non-secure world. The ``cookie`` (6th argument) and the ``handle`` (7th argument) are not used and are reserved for future use. @@ -315,7 +316,7 @@ Software must provide an SMC handling framework capable of MP adhering to The EL3 Runtime Software must also export cache maintenance primitives and some helper utilities for assert, print and memory operations as listed -below. The ARM Trusted Firmware source tree provides implementations for all +below. The TF-A source tree provides implementations for all these functions but the EL3 Runtime Software may use its own implementation. **Functions : assert(), memcpy(), memset** @@ -355,10 +356,10 @@ failure that cannot be recovered from. This function **must not** return. **Function : tf\_printf()** This is printf-compatible function, but unlike printf, it does not return any -value. The ARM Trusted Firmware source tree provides an implementation which +value. The TF-A source tree provides an implementation which is optimized for stack usage and supports only a subset of format specifiers. The details of the format specifiers supported can be found in the -``tf_printf.c`` file in ARM Trusted Firmware source tree. +``tf_printf.c`` file in the TF-A source tree. CPU Context management API ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -537,7 +538,8 @@ CPU operations ~~~~~~~~~~~~~~ The CPU operations (cpu\_ops) framework implement power down sequence specific -to the CPU and the details of which can be found in the ``CPU specific operations framework`` section of `Firmware Design`_. The ARM Trusted Firmware +to the CPU and the details of which can be found in the +``CPU specific operations framework`` section of `Firmware Design`_. The TF-A tree implements the ``cpu_ops`` for various supported CPUs and the EL3 Runtime Software needs to include the required ``cpu_ops`` in its build. The start and end of the ``cpu_ops`` descriptors must be exported by the EL3 Runtime Software @@ -550,7 +552,7 @@ workarounds. -------------- -*Copyright (c) 2016, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2016-2018, Arm Limited and Contributors. All rights reserved.* .. _PSCI spec: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf .. _SMCCC: https://silver.arm.com/download/ARM_and_AMBA_Architecture/AR570-DA-80002-r0p0-00rel0/ARM_DEN0028A_SMC_Calling_Convention.pdf diff --git a/docs/psci-pd-tree.rst b/docs/psci-pd-tree.rst index 329106c50..1113abc57 100644 --- a/docs/psci-pd-tree.rst +++ b/docs/psci-pd-tree.rst @@ -1,4 +1,4 @@ -PSCI Library Integration guide for ARMv8-A AArch32 systems +PSCI Library Integration guide for Armv8-A AArch32 systems ========================================================== @@ -309,4 +309,4 @@ domain nodes do not need to be identified. -------------- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/reset-design.rst b/docs/reset-design.rst index 0b14dec85..44ab609ef 100644 --- a/docs/reset-design.rst +++ b/docs/reset-design.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware Reset Design -================================= +Trusted Firmware-A reset design +=============================== .. section-numbering:: @@ -8,9 +8,9 @@ ARM Trusted Firmware Reset Design .. contents:: This document describes the high-level design of the framework to handle CPU -resets in ARM Trusted Firmware. It also describes how the platform integrator -can tailor this code to the system configuration to some extent, resulting in a -simplified and more optimised boot flow. +resets in Trusted Firmware-A (TF-A). It also describes how the platform +integrator can tailor this code to the system configuration to some extent, +resulting in a simplified and more optimised boot flow. This document should be used in conjunction with the `Firmware Design`_, which provides greater implementation details around the reset code, specifically @@ -19,8 +19,8 @@ for the cold boot path. General reset code flow ----------------------- -The ARM Trusted Firmware (TF) reset code is implemented in BL1 by default. The -following high-level diagram illustrates this: +The TF-A reset code is implemented in BL1 by default. The following high-level +diagram illustrates this: |Default reset code flow| @@ -29,15 +29,15 @@ configuration, some of these steps might be unnecessary. The following sections guide the platform integrator by indicating which build options exclude which steps, depending on the capability of the platform. -Note: If BL31 is used as the Trusted Firmware entry point instead of BL1, the -diagram above is still relevant, as all these operations will occur in BL31 in +Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram +above is still relevant, as all these operations will occur in BL31 in this case. Please refer to section 6 "Using BL31 entrypoint as the reset address" for more information. Programmable CPU reset address ------------------------------ -By default, the TF assumes that the CPU reset address is not programmable. +By default, TF-A assumes that the CPU reset address is not programmable. Therefore, all CPUs start at the same address (typically address 0) whenever they reset. Further logic is then required to identify whether it is a cold or warm boot to direct CPUs to the right execution path. @@ -49,8 +49,8 @@ detection can be skipped, resulting in the following boot flow: |Reset code flow with programmable reset address| -To enable this boot flow, compile the TF with ``PROGRAMMABLE_RESET_ADDRESS=1``. -This option only affects the TF reset image, which is BL1 by default or BL31 if +To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``. +This option only affects the TF-A reset image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``. On both the FVP and Juno platforms, the reset vector address is not programmable @@ -59,7 +59,7 @@ so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``. Cold boot on a single CPU ------------------------- -By default, the TF assumes that several CPUs may be released out of reset. +By default, TF-A assumes that several CPUs may be released out of reset. Therefore, the cold boot code has to arbitrate access to hardware resources shared amongst CPUs. This is done by nominating one of the CPUs as the primary, which is responsible for initialising shared hardware and coordinating the boot @@ -71,8 +71,8 @@ applies. This results in the following boot flow: |Reset code flow with single CPU released out of reset| -To enable this boot flow, compile the TF with ``COLD_BOOT_SINGLE_CPU=1``. This -option only affects the TF reset image, which is BL1 by default or BL31 if +To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This +option only affects the TF-A reset image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``. On both the FVP and Juno platforms, although only one core is powered up by @@ -89,8 +89,8 @@ This results in the following boot flow: |Reset code flow with programmable reset address and single CPU released out of reset| -To enable this boot flow, compile the TF with both ``COLD_BOOT_SINGLE_CPU=1`` -and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF reset +To enable this boot flow, compile TF-A with both ``COLD_BOOT_SINGLE_CPU=1`` +and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``. Using BL31 entrypoint as the reset address @@ -102,7 +102,7 @@ on the SoC, rather than by BL1 and BL2 running on the primary application processor. For this type of SoC it is desirable for the application processor to always reset to BL31 which eliminates the need for BL1 and BL2. -TF provides a build-time option ``RESET_TO_BL31`` that includes some additional +TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional logic in the BL31 entry point to support this use case. In this configuration, the platform's Trusted Boot Firmware must ensure that @@ -112,10 +112,10 @@ Additionally, platform software is responsible for loading the other BL3x images required and providing entry point information for them to BL31. Loading these images might be done by the Trusted Boot Firmware or by platform code in BL31. -Although the ARM FVP platform does not support programming the reset base +Although the Arm FVP platform does not support programming the reset base address dynamically at run-time, it is possible to set the initial value of the ``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only. -It allows the ARM FVP port to support the ``RESET_TO_BL31`` configuration, in +It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in which case the ``bl31.bin`` image must be loaded to its run address in Trusted SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run address. See the `User Guide`_ for details of running the FVP models in this way. @@ -155,7 +155,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31. -------------- -*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* .. _Firmware Design: firmware-design.rst .. _User Guide: user-guide.rst diff --git a/docs/rt-svc-writers-guide.rst b/docs/rt-svc-writers-guide.rst index 6a64adea6..cec2ae708 100644 --- a/docs/rt-svc-writers-guide.rst +++ b/docs/rt-svc-writers-guide.rst @@ -1,5 +1,5 @@ -EL3 Runtime Service Writers Guide for ARM Trusted Firmware -========================================================== +Trusted Firmware-A EL3 runtime service writer's guide +===================================================== .. section-numbering:: @@ -13,7 +13,7 @@ Introduction ------------ This document describes how to add a runtime service to the EL3 Runtime -Firmware component of ARM Trusted Firmware (BL31). +Firmware component of Trusted Firmware-A (TF-A), BL31. Software executing in the normal world and in the trusted world at exception levels lower than EL3 will request runtime services using the Secure Monitor @@ -27,7 +27,7 @@ example a subset of the Function IDs are designated as "OEM Calls" (see `SMCCC`_ for full details). The EL3 runtime services framework in BL31 enables the independent implementation of services for each group, which are then compiled into the BL31 image. This simplifies the integration of common software from -ARM to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific +Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific software. The common runtime services framework ensures that SMC Functions are dispatched to their respective service implementation - the `Firmware Design`_ provides details of how this is achieved. @@ -53,7 +53,7 @@ legacy 32-bit software that predates the `SMCCC`_. :: Type OEN Service - Fast 0 ARM Architecture calls + Fast 0 Arm Architecture calls Fast 1 CPU Service calls Fast 2 SiP Service calls Fast 3 OEM Service calls @@ -62,7 +62,7 @@ legacy 32-bit software that predates the `SMCCC`_. Fast 48-49 Trusted Application calls Fast 50-63 Trusted OS calls - Yielding 0- 1 Reserved for existing ARMv7 calls + Yielding 0- 1 Reserved for existing Armv7-A calls Yielding 2-63 Trusted OS Standard Calls *Table 1: Service types and their corresponding Owning Entity Numbers* @@ -72,7 +72,7 @@ range as they need - it is not necessary to coordinate with other entities of the same type. For example, two SoC providers can use the same Function ID within the SiP Service calls OEN range to mean different things - as these calls should be specific to the SoC. The Standard Runtime Calls OEN is used for -services defined by ARM standards, such as `PSCI`_. +services defined by Arm standards, such as `PSCI`_. The SMC Function ID also indicates whether the call has followed the SMC32 calling convention, where all parameters are 32-bit, or the SMC64 calling @@ -87,7 +87,7 @@ handler will be responsible for all SMC Functions within a given service type. Getting started --------------- -ARM Trusted Firmware has a `services`_ directory in the source tree under which +TF-A has a `services`_ directory in the source tree under which each owning entity can place the implementation of its runtime service. The `PSCI`_ implementation is located here in the `lib/psci`_ directory. @@ -108,7 +108,7 @@ initialization and call handler functions. is also used for diagnostic purposes - ``_start`` and ``_end`` values must be based on the ``OEN_*`` values defined in - `smcc.h`_ + `smccc.h`_ - ``_type`` must be one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD`` @@ -250,8 +250,7 @@ The handler is responsible for: UID and Revision Details for each service documented in section 6 of the `SMCCC`_. - The ARM Trusted Firmware expects owning entities to follow this - recommendation. + TF-A expects owning entities to follow this recommendation. #. Returning the result to the caller. The `SMCCC`_ allows for up to 256 bits of return value in SMC64 using X0-X3 and 128 bits in SMC32 using W0-W3. The @@ -286,8 +285,8 @@ service which perform independent functions. In this situation it may be valuable to introduce a second level framework to enable independent implementation of sub-services. Such a framework might look very similar to the current runtime services framework, but using a different -part of the SMC Function ID to identify the sub-service. Trusted Firmware does -not provide such a framework at present. +part of the SMC Function ID to identify the sub-service. TF-A does not provide +such a framework at present. Secure-EL1 Payload Dispatcher service (SPD) ------------------------------------------- @@ -304,7 +303,7 @@ provide this information.... -------------- -*Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.* .. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf @@ -312,5 +311,5 @@ provide this information.... .. _services: ../services .. _lib/psci: ../lib/psci .. _runtime\_svc.h: ../include/common/runtime_svc.h -.. _smcc.h: ../include/lib/smcc.h +.. _smccc.h: ../include/lib/smccc.h .. _std\_svc\_setup.c: ../services/std_svc/std_svc_setup.c diff --git a/docs/sdei.rst b/docs/sdei.rst index a67b72486..b81e21a9a 100644 --- a/docs/sdei.rst +++ b/docs/sdei.rst @@ -8,13 +8,13 @@ Software Delegated Exception Interface .. contents:: :depth: 2 -This document provides an overview of the SDEI dispatcher implementation in ARM -Trusted Firmware. +This document provides an overview of the SDEI dispatcher implementation in +Trusted Firmware-A (TF-A). Introduction ------------ -`Software Delegated Exception Interface`_ (SDEI) is an ARM specification for +`Software Delegated Exception Interface`_ (SDEI) is an Arm specification for Non-secure world to register handlers with firmware to receive notifications about system events. Firmware will first receive the system events by way of asynchronous exceptions and, in response, arranges for the registered handler to @@ -52,8 +52,8 @@ SDEI events can be explicitly dispatched in response to other asynchronous exceptions. See `Explicit dispatch of events`_. The remainder of this document only discusses the design and implementation of -SDEI dispatcher in ARM Trusted Firmware, and assumes that the reader is familiar -with the SDEI specification, the interfaces, and their requirements. +SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI +specification, the interfaces, and their requirements. .. [#std-event] Except event 0, which is defined by the SDEI specification as a standard event. @@ -314,7 +314,7 @@ Note on writing SDEI event handlers ----------------------------------- *This section pertains to SDEI event handlers in general, not just when using -ARM Trusted Firmware SDEI dispatcher.* +the TF-A SDEI dispatcher.* The SDEI specification requires that event handlers preserve the contents of all registers except ``x0`` to ``x17``. This has significance if event handler is @@ -364,7 +364,7 @@ implemented in assembly, following a similar pattern as below: ---- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* .. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf .. _SDEI porting requirements: porting-guide.rst#sdei-porting-requirements diff --git a/docs/secure-partition-manager-design.rst b/docs/secure-partition-manager-design.rst index 05d4e8bb6..3dd1e0ca2 100644 --- a/docs/secure-partition-manager-design.rst +++ b/docs/secure-partition-manager-design.rst @@ -18,8 +18,8 @@ used by Non-secure world applications to access these services. A Trusted OS fulfils the requirements of a security service as described above. Management services are typically implemented at the highest level of privilege -in the system (i.e. EL3 in Arm Trusted Firmware). The service requirements are -fulfilled by the execution environment provided by Arm Trusted Firmware. +in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are +fulfilled by the execution environment provided by TF-A. The following diagram illustrates the corresponding software stack: @@ -41,10 +41,10 @@ Introduction 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 (i.e. Arm Trusted Firmware) to be granted access to system -and processor resources. Essentially, it is a software sandbox in the Secure -world that runs under the control of privileged software, provides one or more -services and accesses the following system resources: +privileged firmware (i.e. TF-A) to be granted access to system and processor +resources. Essentially, it is a software sandbox in the Secure world that runs +under the control of privileged software, provides one or more services and +accesses the following system resources: - Memory and device regions in the system address map. @@ -52,25 +52,24 @@ services and accesses the following system resources: - A range of synchronous exceptions (e.g. SMC function identifiers). -Note that currently the Arm Trusted Firmware only supports handling one Secure -Partition. +Note that currently TF-A only supports handling one Secure Partition. -A Secure Partition enables Arm Trusted Firmware to implement only the essential -secure services in EL3 and instantiate the rest in a partition in S-EL0. +A Secure Partition enables TF-A to implement only the essential secure +services in EL3 and instantiate the rest in a partition in S-EL0. Furthermore, multiple Secure Partitions can be used to isolate unrelated services from each other. The following diagram illustrates the place of a Secure Partition in a typical -ARMv8-A software stack. A single or multiple Secure Partitions provide secure +Armv8-A software stack. A single or multiple Secure Partitions provide secure services to software components in the Non-secure world and other Secure Partitions. |Image 2| -The Arm Trusted Firmware build system is responsible for including the Secure -Partition image in the FIP. During boot, BL2 includes support to authenticate -and load the Secure Partition image. A BL31 component called **Secure Partition -Manager (SPM)** is responsible for managing the partition. This is semantically +The TF-A build system is responsible for including the Secure Partition image +in the FIP. During boot, BL2 includes support to authenticate and load the +Secure Partition image. A BL31 component called **Secure Partition Manager +(SPM)** is responsible for managing the partition. This is semantically similar to a hypervisor managing a virtual machine. The SPM is responsible for the following actions during boot: @@ -105,8 +104,8 @@ made in the current implementation of this software architecture. Subsequent revisions of the implementation will include a richer set of features that enable a more flexible architecture. -Building Arm Trusted Firmware with Secure Partition support ------------------------------------------------------------ +Building TF-A with Secure Partition support +------------------------------------------- SPM is supported on the Arm FVP exclusively at the moment. The current implementation supports inclusion of only a single Secure Partition in which a @@ -125,7 +124,7 @@ the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core Interface). This will be referred to as the *Standalone MM Secure Partition* in the rest of this document. -To enable SPM support in the TF, the source code must be compiled with the build +To enable SPM support in TF-A, the source code must be compiled with the build flag ``ENABLE_SPM=1``. On Arm platforms the build option ``ARM_BL31_IN_DRAM`` can be used to select the location of BL31, both SRAM and DRAM are supported. Also, the location of the binary that contains the BL32 image @@ -134,7 +133,7 @@ Also, the location of the binary that contains the BL32 image First, build the Standalone MM Secure Partition. To build it, refer to the `instructions in the EDK2 repository`_. -Then build TF with SPM support and include the Standalone MM Secure Partition +Then build TF-A with SPM support and include the Standalone MM Secure Partition image in the FIP: :: @@ -145,10 +144,10 @@ image in the FIP: Describing Secure Partition resources ------------------------------------- -Arm Trusted Firmware exports a porting interface that enables a platform to -specify the system resources required by the Secure Partition. Some instructions -are given below. However, this interface is under development and it may change -as new features are implemented. +TF-A exports a porting interface that enables a platform to specify the system +resources required by the Secure Partition. Some instructions are given below. +However, this interface is under development and it may change as new features +are implemented. - A Secure Partition is considered a BL32 image, so the same defines that apply to BL32 images apply to a Secure Partition: ``BL32_BASE`` and ``BL32_LIMIT``. @@ -176,9 +175,9 @@ For an example of all the changes in context, you may refer to commit Accessing Secure Partition services ----------------------------------- -The `SMC Calling Convention`_ (*ARM DEN 0028B*) describes SMCs as a conduit for +The `SMC Calling Convention`_ (*Arm DEN 0028B*) describes SMCs as a conduit for accessing services implemented in the Secure world. The ``MM_COMMUNICATE`` -interface defined in the `Management Mode Interface Specification`_ (*ARM DEN +interface defined in the `Management Mode Interface Specification`_ (*Arm DEN 0060A*) is used to invoke a Secure Partition service as a Fast Call. The mechanism used to identify a service within the partition depends on the @@ -208,11 +207,11 @@ e.g. ACPI table or device tree. It is possible for the Non-secure world to exchange data with a partition only if it has been populated in this shared memory area. The shared memory area is implemented as per the guidelines specified in Section 3.2.3 of the `Management Mode Interface Specification`_ -(*ARM DEN 0060A*). +(*Arm DEN 0060A*). The format of data structures used to encapsulate data in the shared memory is agreed between the Non-secure world and the Secure Partition. For example, in -the `Management Mode Interface specification`_ (*ARM DEN 0060A*), Section 4 +the `Management Mode Interface specification`_ (*Arm DEN 0060A*), Section 4 describes that the communication buffer shared between the Non-secure world and the Management Mode (MM) in the Secure world must be of the type ``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4: @@ -246,7 +245,7 @@ interfaces are not accessible from the Non-secure world. Conduit ^^^^^^^ -The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the SMC +The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the SMC and HVC conduits for accessing firmware services and their availability depending on the implemented Exception levels. In S-EL0, the Supervisor Call exception (SVC) is the only architectural mechanism available for unprivileged @@ -254,16 +253,16 @@ software to make a request for an operation implemented in privileged software. Hence, the SVC conduit must be used by the Secure Partition to access interfaces implemented by the SPM. -A SVC causes an exception to be taken to S-EL1. Arm Trusted Firmware assumes -ownership of S-EL1 and installs a simple exception vector table in S-EL1 that -relays a SVC request from a Secure Partition as a SMC request to the SPM in EL3. -Upon servicing the SMC request, Arm Trusted Firmware returns control directly to -S-EL0 through an ERET instruction. +A SVC causes an exception to be taken to S-EL1. TF-A assumes ownership of S-EL1 +and installs a simple exception vector table in S-EL1 that relays a SVC request +from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the +SMC request, Arm Trusted Firmware returns control directly to S-EL0 through an +ERET instruction. Calling conventions ^^^^^^^^^^^^^^^^^^^ -The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the +The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the 32-bit and 64-bit calling conventions for the SMC and HVC conduits. The SVC conduit introduces the concept of SVC32 and SVC64 calling conventions. The SVC32 and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the @@ -285,8 +284,8 @@ Communication initiated by Secure Partition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A request is initiated from the Secure Partition by executing a SVC instruction. -An ERET instruction is used by Arm Trusted Firmware to return to S-EL0 with the -result of the request. +An ERET instruction is used by TF-A to return to S-EL0 with the result of the +request. For instance, a request to perform privileged operations on behalf of a partition (e.g. management of memory attributes in the translation tables for @@ -296,7 +295,7 @@ Interfaces ^^^^^^^^^^ The current implementation reserves function IDs for Fast Calls in the Standard -Secure Service calls range (see `SMC Calling Convention`_ (*ARM DEN 0028B*) +Secure Service calls range (see `SMC Calling Convention`_ (*Arm DEN 0028B*) specification) for each API exported by the SPM. This section defines the function prototypes for each function ID. The function IDs specify whether one or both of the SVC32 and SVC64 calling conventions can be used to invoke the @@ -461,7 +460,7 @@ This transition into S-EL0 is special since it is not in response to a previous request through a SVC instruction. This is the first entry into S-EL0. The general purpose register usage at the time of entry will be as specified in the "Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC -calls" of the `SMC Calling Convention`_ (*ARM DEN 0028B*) specification. In +calls" of the `SMC Calling Convention`_ (*Arm DEN 0028B*) specification. In addition, certain other restrictions will be applied as described below. 1. ``SP_EL0`` @@ -601,7 +600,7 @@ address map from a Secure Partition. This is done by mapping these regions in the Secure EL1&0 Translation regime with appropriate memory attributes. Attributes refer to memory type, permission, cacheability and shareability attributes used in the Translation tables. The definitions of these attributes -and their usage can be found in the `ARMv8 ARM`_ (*ARM DDI 0487*). +and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*). All memory required by the Secure Partition is allocated upfront in the SPM, even before handing over to the Secure Partition for the first time. The initial @@ -813,9 +812,9 @@ Error Codes -------------- -*Copyright (c) 2017, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* -.. _ARMv8 ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile +.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile .. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD .. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf .. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf diff --git a/docs/spd/optee-dispatcher.rst b/docs/spd/optee-dispatcher.rst index e55926b4d..63baccc56 100644 --- a/docs/spd/optee-dispatcher.rst +++ b/docs/spd/optee-dispatcher.rst @@ -8,7 +8,7 @@ To build and execute OP-TEE follow the instructions at -------------- -*Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.* .. _OP-TEE OS: https://github.com/OP-TEE/build .. _OP-TEE build.git: https://github.com/OP-TEE/build diff --git a/docs/spd/tlk-dispatcher.rst b/docs/spd/tlk-dispatcher.rst index cd37652d2..90af5faf6 100644 --- a/docs/spd/tlk-dispatcher.rst +++ b/docs/spd/tlk-dispatcher.rst @@ -1,10 +1,10 @@ Trusted Little Kernel (TLK) Dispatcher ====================================== -TLK dispatcher adds support for NVIDIA's Trusted Little Kernel (TLK) to work -with the Trusted Firmware. TLK-D can be compiled by including it in the -platform's makefile. TLK is primarily meant to work with Tegra SoCs, so until -Trusted Firmware starts supporting Tegra, the dispatcher code can only be +TLK dispatcher (TLK-D) adds support for NVIDIA's Trusted Little Kernel (TLK) +to work with Trusted Firmware-A (TF-A). TLK-D can be compiled by including it +in the platform's makefile. TLK is primarily meant to work with Tegra SoCs, +so while TF-A only supports TLK on Tegra, the dispatcher code can only be compiled for other platforms. In order to compile TLK-D, we need a BL32 image to be present. Since, TLKD @@ -20,7 +20,7 @@ Trusted Little Kernel (TLK) TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software (FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which extends technology made available with the development of the Little Kernel (LK). -You can download the LK modular embedded preemptive kernel for use on ARM, +You can download the LK modular embedded preemptive kernel for use on Arm, x86, and AVR32 systems from https://github.com/travisg/lk NVIDIA implemented its Trusted Little Kernel (TLK) technology, designed as a @@ -72,5 +72,5 @@ Example: :: bl32_ep_info->args.arg0 = TZDRAM size available for BL32 - bl32_ep_info->args.arg1 = unused (used only on ARMv7) + bl32_ep_info->args.arg1 = unused (used only on Armv7-A) bl32_ep_info->args.arg2 = pointer to boot args diff --git a/docs/spd/trusty-dispatcher.rst b/docs/spd/trusty-dispatcher.rst index f1982ea79..be085705d 100644 --- a/docs/spd/trusty-dispatcher.rst +++ b/docs/spd/trusty-dispatcher.rst @@ -8,8 +8,25 @@ Detailed information and build instructions can be found on the Android Open Source Project (AOSP) webpage for Trusty hosted at https://source.android.com/security/trusty +Boot parameters +=============== + +Custom boot parameters can be passed to Trusty by providing a platform +specific function: + +.. code:: c + + void plat_trusty_set_boot_args(aapcs64_params_t *args) + +If this function is provided ``args->arg0`` must be set to the memory +size allocated to trusty. If the platform does not provide this +function, but defines ``TSP_SEC_MEM_SIZE``, a default implementation +will pass the memory size from ``TSP_SEC_MEM_SIZE``. ``args->arg1`` +can be set to a platform specific parameter block, and ``args->arg2`` +should then be set to the size of that block. + Supported platforms =================== -Out of all the platforms supported by the ARM Trusted Firmware, Trusty is +Out of all the platforms supported by Trusted Firmware-A, Trusty is only verified and supported by NVIDIA's Tegra SoCs. diff --git a/docs/trusted-board-boot.rst b/docs/trusted-board-boot.rst index 6a28da01f..5ab32fe4c 100644 --- a/docs/trusted-board-boot.rst +++ b/docs/trusted-board-boot.rst @@ -12,16 +12,16 @@ the platform by authenticating all firmware images up to and including the normal world bootloader. It does this by establishing a Chain of Trust using Public-Key-Cryptography Standards (PKCS). -This document describes the design of ARM Trusted Firmware TBB, which is an -implementation of the Trusted Board Boot Requirements (TBBR) specification, -ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_ +This document describes the design of Trusted Firmware-A (TF-A) TBB, which is +an implementation of the Trusted Board Boot Requirements (TBBR) specification, +Arm DEN0006C-1. It should be used in conjunction with the `Firmware Update`_ design document, which implements a specific aspect of the TBBR. Chain of Trust -------------- A Chain of Trust (CoT) starts with a set of implicitly trusted components. On -the ARM development platforms, these components are: +the Arm development platforms, these components are: - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the trusted root-key storage registers. @@ -39,7 +39,7 @@ Certificate Authority (CA) because the CoT is not established by verifying the validity of a certificate's issuer but by the content of the certificate extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption signature scheme is used with a RSA key length of 2048 bits. Future version of -Trusted Firmware will support additional cryptographic algorithms. +TF-A will support additional cryptographic algorithms. The certificates are categorised as "Key" and "Content" certificates. Key certificates are used to verify public keys which have been used to sign content @@ -148,7 +148,7 @@ if any of the steps fail. registers. If they match, the BL2 hash is read from the certificate. Note: the matching operation is platform specific and is currently - unimplemented on the ARM development platforms. + unimplemented on the Arm development platforms. - BL1 loads the BL2 image. Its hash is calculated and compared with the hash read from the certificate. Control is transferred to the BL2 image if all @@ -196,7 +196,7 @@ enabled through use of specific build flags as described in the `User Guide`_. On the host machine, a tool generates the certificates, which are included in the FIP along with the boot loader images. These certificates are loaded in Trusted SRAM using the IO storage framework. They are then verified by an -Authentication module included in the Trusted Firmware. +Authentication module included in TF-A. The mechanism used for generating the FIP and the Authentication module are described in the following sections. @@ -204,9 +204,9 @@ described in the following sections. Authentication Framework ------------------------ -The authentication framework included in the Trusted Firmware provides support -to implement the desired trusted boot sequence. ARM platforms use this framework -to implement the boot requirements specified in the TBBR-client document. +The authentication framework included in TF-A provides support to implement +the desired trusted boot sequence. Arm platforms use this framework to +implement the boot requirements specified in the TBBR-client document. More information about the authentication framework can be found in the `Auth Framework`_ document. @@ -215,8 +215,8 @@ Certificate Generation Tool --------------------------- The ``cert_create`` tool is built and runs on the host machine as part of the -Trusted Firmware build process when ``GENERATE_COT=1``. It takes the boot loader -images and keys as inputs (keys must be in PEM format) and generates the +TF-A build process when ``GENERATE_COT=1``. It takes the boot loader images +and keys as inputs (keys must be in PEM format) and generates the certificates (in DER format) required to establish the CoT. New keys can be generated by the tool in case they are not provided. The certificates are then passed as inputs to the ``fiptool`` utility for creating the FIP. @@ -230,7 +230,7 @@ for building and using the tool can be found in the `User Guide`_. -------------- -*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* .. _Firmware Update: firmware-update.rst .. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt diff --git a/docs/user-guide.rst b/docs/user-guide.rst index 9e23711aa..579485546 100644 --- a/docs/user-guide.rst +++ b/docs/user-guide.rst @@ -1,5 +1,5 @@ -ARM Trusted Firmware User Guide -=============================== +Trusted Firmware-A User Guide +============================= .. section-numbering:: @@ -7,9 +7,9 @@ ARM Trusted Firmware User Guide .. contents:: -This document describes how to build ARM Trusted Firmware (TF) and run it with a +This document describes how to build Trusted Firmware-A (TF-A) and run it with a tested set of other software components using defined configurations on the Juno -ARM development platform and ARM Fixed Virtual Platform (FVP) models. It is +Arm development platform and Arm Fixed Virtual Platform (FVP) models. It is possible to use other software components, configurations and platforms but that is outside the scope of this document. @@ -38,7 +38,7 @@ running the FVP models is a dual-core processor running at 2GHz with 12GB of RAM. For best performance, use a machine with a quad-core processor running at 2.6GHz with 16GB of RAM. -The software has been tested on Ubuntu 14.04 LTS (64-bit). Packages used for +The software has been tested on Ubuntu 16.04 LTS (64-bit). Packages used for building the software were installed from that distribution unless otherwise specified. @@ -48,14 +48,13 @@ Cygwin, and Msys (MinGW) shells, using version 5.3.1 of the GNU toolchain. Tools ----- -Install the required packages to build Trusted Firmware with the following -command: +Install the required packages to build TF-A with the following command: :: sudo apt-get install build-essential gcc make git libssl-dev -ARM TF has been tested with `Linaro Release 17.10`_. +TF-A has been tested with `Linaro Release 17.10`_. Download and install the AArch32 or AArch64 little-endian GCC cross compiler. The `Linaro Release Notes`_ documents which version of the compiler to use for a @@ -63,7 +62,7 @@ given Linaro Release. Also, these `Linaro instructions`_ provide further guidance and a script, which can be used to download Linaro deliverables automatically. -Optionally, Trusted Firmware can be built using clang or ARM Compiler 6. +Optionally, TF-A can be built using clang or Arm Compiler 6. See instructions below on how to switch the default compiler. In addition, the following optional packages and tools may be needed: @@ -71,26 +70,26 @@ In addition, the following optional packages and tools may be needed: - ``device-tree-compiler`` package if you need to rebuild the Flattened Device Tree (FDT) source files (``.dts`` files) provided with this software. -- For debugging, ARM `Development Studio 5 (DS-5)`_. +- For debugging, Arm `Development Studio 5 (DS-5)`_. - To create and modify the diagram files included in the documentation, `Dia`_. This tool can be found in most Linux distributions. Inkscape is needed to generate the actual *.png files. -Getting the Trusted Firmware source code ----------------------------------------- +Getting the TF-A source code +---------------------------- -Download the Trusted Firmware source code from Github: +Download the TF-A source code from Github: :: git clone https://github.com/ARM-software/arm-trusted-firmware.git -Building the Trusted Firmware ------------------------------ +Building TF-A +------------- -- Before building Trusted Firmware, the environment variable ``CROSS_COMPILE`` - must point to the Linaro cross compiler. +- Before building TF-A, the environment variable ``CROSS_COMPILE`` must point + to the Linaro cross compiler. For AArch64: @@ -104,15 +103,15 @@ Building the Trusted Firmware export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf- - It is possible to build Trusted Firmware using clang or ARM Compiler 6. - To do so ``CC`` needs to point to the clang or armclang binary. Only the - compiler is switched; the assembler and linker need to be provided by - the GNU toolchain, thus ``CROSS_COMPILE`` should be set as described above. + It is possible to build TF-A using clang or Arm Compiler 6. To do so + ``CC`` needs to point to the clang or armclang binary. Only the compiler + is switched; the assembler and linker need to be provided by the GNU + toolchain, thus ``CROSS_COMPILE`` should be set as described above. - ARM Compiler 6 will be selected when the base name of the path assigned + Arm Compiler 6 will be selected when the base name of the path assigned to ``CC`` matches the string 'armclang'. - For AArch64 using ARM Compiler 6: + For AArch64 using Arm Compiler 6: :: @@ -130,7 +129,7 @@ Building the Trusted Firmware export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu- make CC=<path-to-clang>/bin/clang PLAT=<platform> all -- Change to the root directory of the Trusted Firmware source tree and build. +- Change to the root directory of the TF-A source tree and build. For AArch64: @@ -154,11 +153,11 @@ Building the Trusted Firmware - (AArch32 only) ``AARCH32_SP`` is the AArch32 EL3 Runtime Software and it corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp\_min, is - provided by ARM Trusted Firmware to demonstrate how PSCI Library can - be integrated with an AArch32 EL3 Runtime Software. Some AArch32 EL3 - Runtime Software may include other runtime services, for example - Trusted OS services. A guide to integrate PSCI library with AArch32 - EL3 Runtime Software can be found `here`_. + provided by TF-A to demonstrate how PSCI Library can be integrated with + an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may + include other runtime services, for example Trusted OS services. A guide + to integrate PSCI library with AArch32 EL3 Runtime Software can be found + `here`_. - (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32 image, is not compiled in by default. Refer to the @@ -198,11 +197,11 @@ Building the Trusted Firmware Summary of build options ~~~~~~~~~~~~~~~~~~~~~~~~ -ARM Trusted Firmware build system supports the following build options. Unless -mentioned otherwise, these options are expected to be specified at the build -command line and are not to be modified in any component makefiles. Note that -the build system doesn't track dependency for build options. Therefore, if any -of the build options are changed from a previous build, a clean build must be +The TF-A build system supports the following build options. Unless mentioned +otherwise, these options are expected to be specified at the build command +line and are not to be modified in any component makefiles. Note that the +build system doesn't track dependency for build options. Therefore, if any of +the build options are changed from a previous build, a clean build must be performed. Common build options @@ -213,52 +212,51 @@ Common build options directory containing the SP source, relative to the ``bl32/``; the directory is expected to contain a makefile called ``<aarch32_sp-value>.mk``. -- ``ARCH`` : Choose the target build architecture for ARM Trusted Firmware. - It can take either ``aarch64`` or ``aarch32`` as values. By default, it is - defined to ``aarch64``. +- ``ARCH`` : Choose the target build architecture for TF-A. It can take either + ``aarch64`` or ``aarch32`` as values. By default, it is defined to + ``aarch64``. -- ``ARM_ARCH_MAJOR``: The major version of ARM Architecture to target when - compiling ARM Trusted Firmware. Its value must be numeric, and defaults to - 8 . See also, *ARMv8 Architecture Extensions* and - *ARMv7 Architecture Extensions* in `Firmware Design`_. +- ``ARM_ARCH_MAJOR``: The major version of Arm Architecture to target when + compiling TF-A. Its value must be numeric, and defaults to 8 . See also, + *Armv8 Architecture Extensions* and *Armv7 Architecture Extensions* in + `Firmware Design`_. -- ``ARM_ARCH_MINOR``: The minor version of ARM Architecture to target when - compiling ARM Trusted Firmware. Its value must be a numeric, and defaults - to 0. See also, *ARMv8 Architecture Extensions* in `Firmware Design`_. +- ``ARM_ARCH_MINOR``: The minor version of Arm Architecture to target when + compiling TF-A. Its value must be a numeric, and defaults to 0. See also, + *Armv8 Architecture Extensions* in `Firmware Design`_. -- ``ARM_GIC_ARCH``: Choice of ARM GIC architecture version used by the ARM +- ``ARM_GIC_ARCH``: Choice of Arm GIC architecture version used by the Arm Legacy GIC driver for implementing the platform GIC API. This API is used by the interrupt management framework. Default is 2 (that is, version 2.0). This build option is deprecated. -- ``ARM_PLAT_MT``: This flag determines whether the ARM platform layer has to +- ``ARM_PLAT_MT``: This flag determines whether the Arm platform layer has to cater for the multi-threading ``MT`` bit when accessing MPIDR. When this flag is set, the functions which deal with MPIDR assume that the ``MT`` bit in MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of this flag is 0. Note that this option is not used on FVP platforms. - ``BL2``: This is an optional build option which specifies the path to BL2 - image for the ``fip`` target. In this case, the BL2 in the ARM Trusted - Firmware will not be built. + image for the ``fip`` target. In this case, the BL2 in the TF-A will not be + built. - ``BL2U``: This is an optional build option which specifies the path to - BL2U image. In this case, the BL2U in the ARM Trusted Firmware will not - be built. + BL2U image. In this case, the BL2U in TF-A will not be built. - ``BL2_AT_EL3``: This is an optional build option that enables the use of BL2 at EL3 execution level. - ``BL31``: This is an optional build option which specifies the path to - BL31 image for the ``fip`` target. In this case, the BL31 in the ARM - Trusted Firmware will not be built. + BL31 image for the ``fip`` target. In this case, the BL31 in TF-A will not + be built. - ``BL31_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the file that contains the BL31 private key in PEM format. If ``SAVE_KEYS=1``, this file name will be used to save the key. - ``BL32``: This is an optional build option which specifies the path to - BL32 image for the ``fip`` target. In this case, the BL32 in the ARM - Trusted Firmware will not be built. + BL32 image for the ``fip`` target. In this case, the BL32 in TF-A will not + be built. - ``BL32_EXTRA1``: This is an optional build option which specifies the path to Trusted OS Extra1 image for the ``fip`` target. @@ -271,7 +269,7 @@ Common build options this file name will be used to save the key. - ``BL33``: Path to BL33 image in the host file system. This is mandatory for - ``fip`` target in case the BL2 from ARM Trusted Firmware is used. + ``fip`` target in case TF-A BL2 is used. - ``BL33_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the file that contains the BL33 private key in PEM format. If ``SAVE_KEYS=1``, @@ -282,8 +280,8 @@ Common build options where applicable). Defaults to a string that contains the time and date of the compilation. -- ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF build - to be uniquely identified. Defaults to the current git commit id. +- ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF-A + build to be uniquely identified. Defaults to the current git commit id. - ``CFLAGS``: Extra user options appended on the compiler's command line in addition to the options set by the build system. @@ -347,10 +345,10 @@ Common build options software. - ``ENABLE_RUNTIME_INSTRUMENTATION``: Boolean option to enable runtime - instrumentation which injects timestamp collection points into - Trusted Firmware to allow runtime performance to be measured. - Currently, only PSCI is instrumented. Enabling this option enables - the ``ENABLE_PMF`` build option as well. Default is 0. + instrumentation which injects timestamp collection points into TF-A to + allow runtime performance to be measured. Currently, only PSCI is + instrumented. Enabling this option enables the ``ENABLE_PMF`` build option + as well. Default is 0. - ``ENABLE_SPE_FOR_LOWER_ELS`` : Boolean option to enable Statistical Profiling extensions. This is an optional architectural feature for AArch64. @@ -427,15 +425,15 @@ Common build options - ``HANDLE_EA_EL3_FIRST``: When defined External Aborts and SError Interrupts will be always trapped in EL3 i.e. in BL31 at runtime. -- ``HW_ASSISTED_COHERENCY``: On most ARM systems to-date, platform-specific +- ``HW_ASSISTED_COHERENCY``: On most Arm systems to-date, platform-specific software operations are required for CPUs to enter and exit coherency. However, there exists newer systems where CPUs' entry to and exit from coherency is managed in hardware. Such systems require software to only initiate the operations, and the rest is managed in hardware, minimizing - active software management. In such systems, this boolean option enables ARM - Trusted Firmware to carry out build and run-time optimizations during boot - and power management operations. This option defaults to 0 and if it is - enabled, then it implies ``WARMBOOT_ENABLE_DCACHE_EARLY`` is also enabled. + active software management. In such systems, this boolean option enables + TF-A to carry out build and run-time optimizations during boot and power + management operations. This option defaults to 0 and if it is enabled, + then it implies ``WARMBOOT_ENABLE_DCACHE_EARLY`` is also enabled. - ``JUNO_AARCH32_EL3_RUNTIME``: This build flag enables you to execute EL3 runtime software in AArch32 mode, which is required to run AArch32 on Juno. @@ -497,10 +495,10 @@ Common build options any register that is not part of the SBSA generic UART specification. Default value is 0 (a full PL011 compliant UART is present). -- ``PLAT``: Choose a platform to build ARM Trusted Firmware for. The chosen - platform name must be subdirectory of any depth under ``plat/``, and must - contain a platform makefile named ``platform.mk``. For example to build ARM - Trusted Firmware for ARM Juno board select PLAT=juno. +- ``PLAT``: Choose a platform to build TF-A for. The chosen platform name + must be subdirectory of any depth under ``plat/``, and must contain a + platform makefile named ``platform.mk``. For example, to build TF-A for the + Arm Juno board, select PLAT=juno. - ``PRELOADED_BL33_BASE``: This option enables booting a preloaded BL33 image instead of the normal boot flow. When defined, it must specify the entry @@ -524,7 +522,7 @@ Common build options means by default the original power-state format is used by the PSCI implementation. This flag should be specified by the platform makefile and it governs the return value of PSCI\_FEATURES API for CPU\_SUSPEND - smc function id. When this option is enabled on ARM platforms, the + smc function id. When this option is enabled on Arm platforms, the option ``ARM_RECOM_STATE_ID_ENC`` needs to be set to 1 as well. - ``RESET_TO_BL31``: Enable BL31 entrypoint as the CPU reset vector instead @@ -532,11 +530,10 @@ Common build options entrypoint) or 1 (CPU reset to BL31 entrypoint). The default value is 0. -- ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided in - ARM Trusted Firmware. This flag configures SP\_MIN entrypoint as the CPU - reset vector instead of the BL1 entrypoint. It can take the value 0 (CPU - reset to BL1 entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default - value is 0. +- ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided + in TF-A. This flag configures SP\_MIN entrypoint as the CPU reset vector + instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1 + entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default value is 0. - ``ROT_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the file that contains the ROT private key in PEM format. If ``SAVE_KEYS=1``, this @@ -570,11 +567,11 @@ Common build options pages" section in `Firmware Design`_. This flag is disabled by default and affects all BL images. -- ``SPD``: Choose a Secure Payload Dispatcher component to be built into the - Trusted Firmware. This build option is only valid if ``ARCH=aarch64``. The - value should be the path to the directory containing the SPD source, - relative to ``services/spd/``; the directory is expected to - contain a makefile called ``<spd-value>.mk``. +- ``SPD``: Choose a Secure Payload Dispatcher component to be built into TF-A. + This build option is only valid if ``ARCH=aarch64``. The value should be + the path to the directory containing the SPD source, relative to + ``services/spd/``; the directory is expected to contain a makefile called + ``<spd-value>.mk``. - ``SPIN_ON_BL1_EXIT``: This option introduces an infinite loop in BL1. It can take either 0 (no loop) or 1 (add a loop). 0 is the default. This loop stops @@ -622,16 +619,16 @@ Common build options - ``USE_COHERENT_MEM``: This flag determines whether to include the coherent memory region in the BL memory map or not (see "Use of Coherent memory in - Trusted Firmware" section in `Firmware Design`_). It can take the value 1 + TF-A" section in `Firmware Design`_). It can take the value 1 (Coherent memory region is included) or 0 (Coherent memory region is excluded). Default is 1. - ``V``: Verbose build. If assigned anything other than 0, the build commands are printed. Default is 0. -- ``VERSION_STRING``: String used in the log output for each TF image. Defaults - to a string formed by concatenating the version number, build type and build - string. +- ``VERSION_STRING``: String used in the log output for each TF-A image. + Defaults to a string formed by concatenating the version number, build type + and build string. - ``WARMBOOT_ENABLE_DCACHE_EARLY`` : Boolean option to enable D-cache early on the CPU after warm boot. This is applicable for platforms which do not @@ -639,7 +636,7 @@ Common build options cluster platforms). If this option is enabled, then warm boot path enables D-caches immediately after enabling MMU. This option defaults to 0. -ARM development platform specific build options +Arm development platform specific build options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - ``ARM_BL31_IN_DRAM``: Boolean option to select loading of BL31 in TZC secured @@ -652,7 +649,7 @@ ARM development platform specific build options of the memory reserved for each image. This affects the maximum size of each BL image as well as the number of allocated memory regions and translation tables. By default this flag is 0, which means it uses the default - unoptimised values for these macros. ARM development platforms that wish to + unoptimised values for these macros. Arm development platforms that wish to optimise memory usage need to set this flag to 1 and must override the related macros. @@ -663,7 +660,7 @@ ARM development platform specific build options Default is true (access to the frame is allowed). - ``ARM_DISABLE_TRUSTED_WDOG``: boolean option to disable the Trusted Watchdog. - By default, ARM platforms use a watchdog to trigger a system reset in case + By default, Arm platforms use a watchdog to trigger a system reset in case an error is encountered during the boot process (for example, when an image could not be loaded or authenticated). The watchdog is enabled in the early platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The @@ -680,7 +677,7 @@ ARM development platform specific build options - ``ARM_ROTPK_LOCATION``: used when ``TRUSTED_BOARD_BOOT=1``. It specifies the location of the ROTPK hash returned by the function ``plat_get_rotpk_info()`` - for ARM platforms. Depending on the selected option, the proper private key + for Arm platforms. Depending on the selected option, the proper private key must be specified using the ``ROT_KEY`` option when building the Trusted Firmware. This private key will be used by the certificate generation tool to sign the BL2 and Trusted Key certificates. Available options for @@ -707,27 +704,26 @@ ARM development platform specific build options - ``dram`` : Secure region in DRAM (default option when TBB is enabled, configured by the TrustZone controller) -- ``ARM_XLAT_TABLES_LIB_V1``: boolean option to compile the Trusted Firmware - with version 1 of the translation tables library instead of version 2. It is - set to 0 by default, which selects version 2. +- ``ARM_XLAT_TABLES_LIB_V1``: boolean option to compile TF-A with version 1 + of the translation tables library instead of version 2. It is set to 0 by + default, which selects version 2. -- ``ARM_CRYPTOCELL_INTEG`` : bool option to enable Trusted Firmware to invoke - ARM® TrustZone® CryptoCell functionality for Trusted Board Boot on capable - ARM platforms. If this option is specified, then the path to the CryptoCell +- ``ARM_CRYPTOCELL_INTEG`` : bool option to enable TF-A to invoke Arm® + TrustZone® CryptoCell functionality for Trusted Board Boot on capable Arm + platforms. If this option is specified, then the path to the CryptoCell SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag. -For a better understanding of these options, the ARM development platform memory +For a better understanding of these options, the Arm development platform memory map is explained in the `Firmware Design`_. -ARM CSS platform specific build options +Arm CSS platform specific build options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - ``CSS_DETECT_PRE_1_7_0_SCP``: Boolean flag to detect SCP version incompatibility. Version 1.7.0 of the SCP firmware made a non-backwards compatible change to the MTL protocol, used for AP/SCP communication. - Trusted Firmware no longer supports earlier SCP versions. If this option is - set to 1 then Trusted Firmware will detect if an earlier version is in use. - Default is 1. + TF-A no longer supports earlier SCP versions. If this option is set to 1 + then TF-A will detect if an earlier version is in use. Default is 1. - ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP\_BL2 and SCP\_BL2U to the FIP and FWU\_FIP respectively, and enables them to be loaded @@ -738,13 +734,12 @@ ARM CSS platform specific build options management operations and for SCP RAM Firmware transfer. If this option is set to 1, then SCMI/SDS drivers will be used. Default is 0. -ARM FVP platform specific build options +Arm FVP platform specific build options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - ``FVP_CLUSTER_COUNT`` : Configures the cluster count to be used to - build the topology tree within Trusted Firmware. By default the - Trusted Firmware is configured for dual cluster topology and this option - can be used to override the default value. + build the topology tree within TF-A. By default TF-A is configured for dual + cluster topology and this option can be used to override the default value. - ``FVP_INTERCONNECT_DRIVER``: Selects the interconnect driver to be built. The default interconnect driver depends on the value of ``FVP_CLUSTER_COUNT`` as @@ -768,14 +763,26 @@ ARM FVP platform specific build options - ``FVP_GICV2`` : The GICv2 only driver is selected - ``FVP_GICV3`` : The GICv3 only driver is selected (default option) - ``FVP_GICV3_LEGACY``: The Legacy GICv3 driver is selected (deprecated) - Note: If Trusted Firmware is compiled with this option on FVPs with - GICv3 hardware, then it configures the hardware to run in GICv2 - emulation mode + Note: If TF-A is compiled with this option on FVPs with GICv3 hardware, + then it configures the hardware to run in GICv2 emulation mode - ``FVP_USE_SP804_TIMER`` : Use the SP804 timer instead of the Generic Timer for functions that wait for an arbitrary time length (udelay and mdelay). The default value is 0. +- ``FVP_HW_CONFIG_DTS`` : Specify the path to the DTS file to be compiled + to DTB and packaged in FIP as the HW_CONFIG. See `Firmware Design`_ for + details on HW_CONFIG. By default, this is initialized to a sensible DTS + file in ``fdts/`` folder depending on other build options. But some cases, + like shifted affinity format for MPIDR, cannot be detected at build time + and this option is needed to specify the appropriate DTS file. + +- ``FVP_HW_CONFIG`` : Specify the path to the HW_CONFIG blob to be packaged in + FIP. See `Firmware Design`_ for details on HW_CONFIG. This option is + similar to the ``FVP_HW_CONFIG_DTS`` option, but it directly specifies the + HW_CONFIG blob instead of the DTS file. This option is useful to override + the default HW_CONFIG selected by the build system. + Debugging options ~~~~~~~~~~~~~~~~~ @@ -795,7 +802,7 @@ When debugging logic problems it might also be useful to disable all compiler optimizations by using ``-O0``. NOTE: Using ``-O0`` could cause output images to be larger and base addresses -might need to be recalculated (see the **Memory layout on ARM development +might need to be recalculated (see the **Memory layout on Arm development platforms** section in the `Firmware Design`_). Extra debug options can be passed to the build system by setting ``CFLAGS`` or @@ -810,8 +817,8 @@ Note that using ``-Wl,`` style compilation driver options in ``CFLAGS`` will be ignored as the linker is called directly. It is also possible to introduce an infinite loop to help in debugging the -post-BL2 phase of the Trusted Firmware. This can be done by rebuilding BL1 with -the ``SPIN_ON_BL1_EXIT=1`` build flag. Refer to the `Summary of build options`_ +post-BL2 phase of TF-A. This can be done by rebuilding BL1 with the +``SPIN_ON_BL1_EXIT=1`` build flag. Refer to the `Summary of build options`_ section. In this case, the developer may take control of the target using a debugger when indicated by the console output. When using DS-5, the following commands can be used: @@ -839,8 +846,8 @@ called the TSPD. Therefore, if you intend to use the TSP, the BL31 image must be recompiled as well. For more information on SPs and SPDs, see the `Secure-EL1 Payloads and Dispatchers`_ section in the `Firmware Design`_. -First clean the Trusted Firmware build directory to get rid of any previous -BL31 binary. Then to build the TSP image use: +First clean the TF-A build directory to get rid of any previous BL31 binary. +Then to build the TSP image use: :: @@ -860,9 +867,12 @@ must be in compliance with the Linux style guide, and to assist with this check the project Makefile contains two targets, which both utilise the ``checkpatch.pl`` script that ships with the Linux source tree. -To check the entire source tree, you must first download a copy of -``checkpatch.pl`` (or the full Linux source), set the ``CHECKPATCH`` environment -variable to point to the script and build the target checkcodebase: +To check the entire source tree, you must first download copies of +``checkpatch.pl``, ``spelling.txt`` and ``const_structs.checkpatch`` available +in the `Linux master tree`_ scripts directory, then set the ``CHECKPATCH`` +environment variable to point to ``checkpatch.pl`` (with the other 2 files in +the same directory) and build the target +checkcodebase: :: @@ -882,17 +892,17 @@ is set to ``origin/master``. Building and using the FIP tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Firmware Image Package (FIP) is a packaging format used by the Trusted Firmware -project to package firmware images in a single binary. The number and type of -images that should be packed in a FIP is platform specific and may include TF -images and other firmware images required by the platform. For example, most -platforms require a BL33 image which corresponds to the normal world bootloader -(e.g. UEFI or U-Boot). +Firmware Image Package (FIP) is a packaging format used by TF-A to package +firmware images in a single binary. The number and type of images that should +be packed in a FIP is platform specific and may include TF-A images and other +firmware images required by the platform. For example, most platforms require +a BL33 image which corresponds to the normal world bootloader (e.g. UEFI or +U-Boot). -The TF build system provides the make target ``fip`` to create a FIP file for the -specified platform using the FIP creation tool included in the TF project. -Examples below show how to build a FIP file for FVP, packaging TF images and a -BL33 image. +The TF-A build system provides the make target ``fip`` to create a FIP file +for the specified platform using the FIP creation tool included in the TF-A +project. Examples below show how to build a FIP file for FVP, packaging TF-A +and BL33 images. For AArch64: @@ -1013,9 +1023,10 @@ images with support for these features: #. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser modules by checking out a recent version of the `mbed TLS Repository`_. It - is important to use a version that is compatible with TF and fixes any + is important to use a version that is compatible with TF-A and fixes any known security vulnerabilities. See `mbed TLS Security Center`_ for more - information. The latest version of TF is tested with tag ``mbedtls-2.6.0``. + information. The latest version of TF-A is tested with tag + ``mbedtls-2.6.0``. The ``drivers/auth/mbedtls/mbedtls_*.mk`` files contain the list of mbed TLS source files the modules depend upon. @@ -1023,17 +1034,17 @@ images with support for these features: options required to build the mbed TLS sources. Note that the mbed TLS library is licensed under the Apache version 2.0 - license. Using mbed TLS source code will affect the licensing of - Trusted Firmware binaries that are built using this library. + license. Using mbed TLS source code will affect the licensing of TF-A + binaries that are built using this library. #. To build the FIP image, ensure the following command line variables are set - while invoking ``make`` to build Trusted Firmware: + while invoking ``make`` to build TF-A: - ``MBEDTLS_DIR=<path of the directory containing mbed TLS sources>`` - ``TRUSTED_BOARD_BOOT=1`` - ``GENERATE_COT=1`` - In the case of ARM platforms, the location of the ROTPK hash must also be + In the case of Arm platforms, the location of the ROTPK hash must also be specified at build time. Two locations are currently supported (see ``ARM_ROTPK_LOCATION`` build option): @@ -1047,11 +1058,11 @@ images with support for these features: available. - ``ARM_ROTPK_LOCATION=devel_rsa``: use the ROTPK hash that is hardcoded - in the ARM platform port. The private/public RSA key pair may be + in the Arm platform port. The private/public RSA key pair may be found in ``plat/arm/board/common/rotpk``. - ``ARM_ROTPK_LOCATION=devel_ecdsa``: use the ROTPK hash that is hardcoded - in the ARM platform port. The private/public ECDSA key pair may be + in the Arm platform port. The private/public ECDSA key pair may be found in ``plat/arm/board/common/rotpk``. Example of command line using RSA development keys: @@ -1073,7 +1084,7 @@ images with support for these features: #. The optional FWU\_FIP contains any additional images to be loaded from Non-Volatile storage during the `Firmware Update`_ process. To build the FWU\_FIP, any FWU images required by the platform must be specified on the - command line. On ARM development platforms like Juno, these are: + command line. On Arm development platforms like Juno, these are: - NS\_BL2U. The AP non-secure Firmware Updater image. - SCP\_BL2U. The SCP Firmware Update Configuration image. @@ -1108,9 +1119,10 @@ images with support for these features: Building the Certificate Generation Tool ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The ``cert_create`` tool is built as part of the TF build process when the ``fip`` -make target is specified and TBB is enabled (as described in the previous -section), but it can also be built separately with the following command: +The ``cert_create`` tool is built as part of the TF-A build process when the +``fip`` make target is specified and TBB is enabled (as described in the +previous section), but it can also be built separately with the following +command: :: @@ -1140,10 +1152,15 @@ a single FIP binary. It assumes that a `Linaro Release`_ has been installed. Note: Pre-built binaries for AArch32 are available from Linaro Release 16.12 onwards. Before that release, pre-built binaries are only available for AArch64. -Note: follow the full instructions for one platform before switching to a +Note: Follow the full instructions for one platform before switching to a different one. Mixing instructions for different platforms may result in corrupted binaries. +Note: The uboot image downloaded by the Linaro workspace script does not always +match the uboot image packaged as BL33 in the corresponding fip file. It is +recommended to use the version that is packaged in the fip file using the +instructions below. + #. Clean the working directory :: @@ -1168,14 +1185,14 @@ corrupted binaries. current working directory. The SCP\_BL2 image corresponds to ``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``. - Note: the fiptool will complain if the images to be unpacked already + Note: The fiptool will complain if the images to be unpacked already exist in the current directory. If that is the case, either delete those files or use the ``--force`` option to overwrite. - Note for AArch32, the instructions below assume that nt-fw.bin is a custom + Note: For AArch32, the instructions below assume that nt-fw.bin is a custom Normal world boot loader that supports AArch32. -#. Build TF images and create a new FIP for FVP +#. Build TF-A images and create a new FIP for FVP :: @@ -1185,7 +1202,7 @@ corrupted binaries. # AArch32 make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=nt-fw.bin all fip -#. Build TF images and create a new FIP for Juno +#. Build TF-A images and create a new FIP for Juno For AArch64: @@ -1309,16 +1326,16 @@ scratch, this is a complex task on some platforms, depending on the level of configuration required to put the system in the expected state. Rather than booting a baremetal application, a possible compromise is to boot -``EL3 payloads`` through the Trusted Firmware instead. This is implemented as an -alternative boot flow, where a modified BL2 boots an EL3 payload, instead of -loading the other BL images and passing control to BL31. It reduces the -complexity of developing EL3 baremetal code by: +``EL3 payloads`` through TF-A instead. This is implemented as an alternative +boot flow, where a modified BL2 boots an EL3 payload, instead of loading the +other BL images and passing control to BL31. It reduces the complexity of +developing EL3 baremetal code by: - putting the system into a known architectural state; - taking care of platform secure world initialization; - loading the SCP\_BL2 image if required by the platform. -When booting an EL3 payload on ARM standard platforms, the configuration of the +When booting an EL3 payload on Arm standard platforms, the configuration of the TrustZone controller is simplified such that only region 0 is enabled and is configured to permit secure access only. This gives full access to the whole DRAM to the EL3 payload. @@ -1337,11 +1354,11 @@ Booting an EL3 payload ~~~~~~~~~~~~~~~~~~~~~~ The EL3 payload image is a standalone image and is not part of the FIP. It is -not loaded by the Trusted Firmware. Therefore, there are 2 possible scenarios: +not loaded by TF-A. Therefore, there are 2 possible scenarios: - The EL3 payload may reside in non-volatile memory (NVM) and execute in place. In this case, booting it is just a matter of specifying the right - address in NVM through ``EL3_PAYLOAD_BASE`` when building the TF. + address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A. - The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at run-time. @@ -1410,7 +1427,7 @@ used: --data="/path/to/el3-payload"@address [Foundation FVP] The address provided to the FVP must match the ``EL3_PAYLOAD_BASE`` address - used when building the Trusted Firmware. + used when building TF-A. Booting an EL3 payload on Juno ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1428,15 +1445,14 @@ Preloaded BL33 alternative boot flow ------------------------------------ Some platforms have the ability to preload BL33 into memory instead of relying -on Trusted Firmware to load it. This may simplify packaging of the normal world -code and improve performance in a development environment. When secure world -cold boot is complete, Trusted Firmware simply jumps to a BL33 base address -provided at build time. +on TF-A to load it. This may simplify packaging of the normal world code and +improve performance in a development environment. When secure world cold boot +is complete, TF-A simply jumps to a BL33 base address provided at build time. For this option to be used, the ``PRELOADED_BL33_BASE`` build option has to be -used when compiling the Trusted Firmware. For example, the following command -will create a FIP without a BL33 and prepare to jump to a BL33 image loaded at -address 0x80000000: +used when compiling TF-A. For example, the following command will create a FIP +without a BL33 and prepare to jump to a BL33 image loaded at address +0x80000000: :: @@ -1446,8 +1462,8 @@ Boot of a preloaded bootwrapped kernel image on Base FVP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following example uses the AArch64 boot wrapper. This simplifies normal -world booting while also making use of TF features. It can be obtained from its -repository with: +world booting while also making use of TF-A features. It can be obtained from +its repository with: :: @@ -1481,13 +1497,14 @@ to load the ELF file over JTAG on Juno. Running the software on FVP --------------------------- -The latest version of the AArch64 build of ARM Trusted Firmware has been tested -on the following ARM FVPs (64-bit host machine only). +The latest version of the AArch64 build of TF-A has been tested on the following +Arm FVPs without shifted affinities, and that do not support threaded CPU cores +(64-bit host machine only). NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33. - ``Foundation_Platform`` -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) +- ``FVP_Base_AEMv8A-AEMv8A`` (and also Version 9.0, Build 0.8.9005) - ``FVP_Base_Cortex-A35x4`` - ``FVP_Base_Cortex-A53x4`` - ``FVP_Base_Cortex-A57x4-A53x4`` @@ -1497,12 +1514,25 @@ NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33. - ``FVP_Base_Cortex-A73x4-A53x4`` - ``FVP_Base_Cortex-A73x4`` -The latest version of the AArch32 build of ARM Trusted Firmware has been tested -on the following ARM FVPs (64-bit host machine only). +Additionally, the AArch64 build was tested on the following Arm FVPs with +shifted affinities, supporting threaded CPU cores (64-bit host machine only). + +- ``FVP_Base_Cortex-A55x4-A75x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_Cortex-A55x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_Cortex-A75x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_RevC-2xAEMv8A`` -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) +The latest version of the AArch32 build of TF-A has been tested on the following +Arm FVPs without shifted affinities, and that do not support threaded CPU cores +(64-bit host machine only). + +- ``FVP_Base_AEMv8A-AEMv8A`` - ``FVP_Base_Cortex-A32x4`` +NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which +is not compatible with legacy GIC configurations. Therefore this FVP does not +support these legacy GIC configurations. + NOTE: The build numbers quoted above are those reported by launching the FVP with the ``--version`` parameter. @@ -1516,7 +1546,7 @@ NOTE: The software will not work on Version 1.0 of the Foundation FVP. The commands below would report an ``unhandled argument`` error in this case. NOTE: FVPs can be launched with ``--cadi-server`` option such that a -CADI-compliant debugger (for example, ARM DS-5) can connect to and control its +CADI-compliant debugger (for example, Arm DS-5) can connect to and control its execution. NOTE: Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202 @@ -1525,46 +1555,59 @@ models. The models can be launched with ``-Q 100`` option if they are required to match the run time characteristics of the older versions. The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be -downloaded for free from `ARM's website`_. +downloaded for free from `Arm's website`_. The Cortex-A models listed above are also available to download from -`ARM's website`_. +`Arm's website`_. Please refer to the FVP documentation for a detailed description of the model -parameter options. A brief description of the important ones that affect the ARM -Trusted Firmware and normal world software behavior is provided below. +parameter options. A brief description of the important ones that affect TF-A +and normal world software behavior is provided below. Obtaining the Flattened Device Trees ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Depending on the FVP configuration and Linux configuration used, different FDT files are required. FDTs for the Foundation and Base FVPs can be found in -the Trusted Firmware source directory under ``fdts/``. The Foundation FVP has a -subset of the Base FVP components. For example, the Foundation FVP lacks CLCD -and MMC support, and has only one CPU cluster. +the TF-A source directory under ``fdts/``. The Foundation FVP has a subset of +the Base FVP components. For example, the Foundation FVP lacks CLCD and MMC +support, and has only one CPU cluster. Note: It is not recommended to use the FDTs built along the kernel because not all FDTs are available from there. - ``fvp-base-gicv2-psci.dtb`` - For use with both AEMv8 and Cortex-A57-A53 Base FVPs with - Base memory map configuration. + For use with models such as the Cortex-A57-A53 Base FVPs without shifted + affinities and with Base memory map configuration. - ``fvp-base-gicv2-psci-aarch32.dtb`` - For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state - with Base memory map configuration. + For use with models such as the Cortex-A32 Base FVPs without shifted + affinities and running Linux in AArch32 state with Base memory map + configuration. - ``fvp-base-gicv3-psci.dtb`` - (Default) For use with both AEMv8 and Cortex-A57-A53 Base FVPs with Base - memory map configuration and Linux GICv3 support. + For use with models such as the Cortex-A57-A53 Base FVPs without shifted + affinities and with Base memory map configuration and Linux GICv3 support. + +- ``fvp-base-gicv3-psci-1t.dtb`` + + For use with models such as the AEMv8-RevC Base FVP with shifted affinities, + single threaded CPUs, Base memory map configuration and Linux GICv3 support. + +- ``fvp-base-gicv3-psci-dynamiq.dtb`` + + For use with models as the Cortex-A55-A75 Base FVPs with shifted affinities, + single cluster, single threaded CPUs, Base memory map configuration and Linux + GICv3 support. - ``fvp-base-gicv3-psci-aarch32.dtb`` - For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state - with Base memory map configuration and Linux GICv3 support. + For use with models such as the Cortex-A32 Base FVPs without shifted + affinities and running Linux in AArch32 state with Base memory map + configuration and Linux GICv3 support. - ``fvp-foundation-gicv2-psci.dtb`` @@ -1579,7 +1622,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``Foundation_Platform`` parameters should be used to boot Linux with -4 CPUs using the AArch64 build of ARM Trusted Firmware. +4 CPUs using the AArch64 build of TF-A. :: @@ -1603,23 +1646,23 @@ Notes: - The default use-case for the Foundation FVP is to use the ``--gicv3`` option and enable the GICv3 device in the model. Note that without this option, the Foundation FVP defaults to legacy (Versatile Express) memory map which - is not supported by ARM Trusted Firmware. -- In order for the Arm Trusted Firmware to run correctly on the Foundation - Model the architecture versions must match. The Foundation FVP defaults to - the highest v8.x version it supports but the default build for Arm Trusted - Firmware is for v8.0. To avoid issues either start the Foundation Model to - use v8.0 architecture using the ``--arm-v8.0`` option or build Arm Trusted - Firmware with an appropriate value for ``ARM_ARCH_MINOR``. + is not supported by TF-A. +- In order for TF-A to run correctly on the Foundation FVP, the architecture + versions must match. The Foundation FVP defaults to the highest v8.x + version it supports but the default build for TF-A is for v8.0. To avoid + issues either start the Foundation FVP to use v8.0 architecture using the + ``--arm-v8.0`` option, or build TF-A with an appropriate value for + ``ARM_ARCH_MINOR``. Running on the AEMv8 Base FVP with reset to BL1 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux -with 8 CPUs using the AArch64 build of ARM Trusted Firmware. +The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch64 build of TF-A. :: - <path-to>/FVP_Base_AEMv8A-AEMv8A \ + <path-to>/FVP_Base_RevC-2xAEMv8A \ -C pctl.startup=0.0.0.0 \ -C bp.secure_memory=1 \ -C bp.tzc_400.diagnostics=1 \ @@ -1636,7 +1679,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux -with 8 CPUs using the AArch32 build of ARM Trusted Firmware. +with 8 CPUs using the AArch32 build of TF-A. :: @@ -1665,7 +1708,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to -boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. +boot Linux with 8 CPUs using the AArch64 build of TF-A. :: @@ -1684,7 +1727,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to -boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. +boot Linux with 4 CPUs using the AArch32 build of TF-A. :: @@ -1702,12 +1745,12 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. Running on the AEMv8 Base FVP with reset to BL31 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux -with 8 CPUs using the AArch64 build of ARM Trusted Firmware. +The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch64 build of TF-A. :: - <path-to>/FVP_Base_AEMv8A-AEMv8A \ + <path-to>/FVP_Base_RevC-2xAEMv8A \ -C pctl.startup=0.0.0.0 \ -C bp.secure_memory=1 \ -C bp.tzc_400.diagnostics=1 \ @@ -1750,7 +1793,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP\_MIN entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux -with 8 CPUs using the AArch32 build of ARM Trusted Firmware. +with 8 CPUs using the AArch32 build of TF-A. :: @@ -1790,7 +1833,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to -boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. +boot Linux with 8 CPUs using the AArch64 build of TF-A. :: @@ -1818,7 +1861,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP\_MIN entrypoint ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to -boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. +boot Linux with 4 CPUs using the AArch32 build of TF-A. :: @@ -1840,8 +1883,7 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. Running the software on Juno ---------------------------- -This version of the ARM Trusted Firmware has been tested on variants r0, r1 and -r2 of Juno. +This version of TF-A has been tested on variants r0, r1 and r2 of Juno. To execute the software stack on Juno, the version of the Juno board recovery image indicated in the `Linaro Release Notes`_ must be installed. If you have an @@ -1849,18 +1891,18 @@ earlier version installed or are unsure which version is installed, please re-install the recovery image by following the `Instructions for using Linaro's deliverables on Juno`_. -Preparing Trusted Firmware images -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Preparing TF-A images +~~~~~~~~~~~~~~~~~~~~~ -After building Trusted Firmware, the files ``bl1.bin`` and ``fip.bin`` need copying -to the ``SOFTWARE/`` directory of the Juno SD card. +After building TF-A, the files ``bl1.bin`` and ``fip.bin`` need copying to the +``SOFTWARE/`` directory of the Juno SD card. Other Juno software information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Please visit the `ARM Platforms Portal`_ to get support and obtain any other Juno +Please visit the `Arm Platforms Portal`_ to get support and obtain any other Juno software information. Please also refer to the `Juno Getting Started Guide`_ to -get more detailed information about the Juno ARM development platform and how to +get more detailed information about the Juno Arm development platform and how to configure it. Testing SYSTEM SUSPEND on Juno @@ -1880,7 +1922,7 @@ wakeup interrupt from RTC. -------------- -*Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* .. _Linaro: `Linaro Release Notes`_ .. _Linaro Release: `Linaro Release Notes`_ @@ -1888,8 +1930,9 @@ wakeup interrupt from RTC. .. _Linaro Release 17.10: https://community.arm.com/dev-platforms/w/docs/226/old-linaro-release-notes#1710 .. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/linaro-software-deliverables .. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno -.. _ARM Platforms Portal: https://community.arm.com/dev-platforms/ +.. _Arm Platforms Portal: https://community.arm.com/dev-platforms/ .. _Development Studio 5 (DS-5): http://www.arm.com/products/tools/software-tools/ds-5/index.php +.. _Linux master tree: <https://github.com/torvalds/linux/tree/master/> .. _Dia: https://wiki.gnome.org/Apps/Dia/Download .. _here: psci-lib-integration-guide.rst .. _Trusted Board Boot: trusted-board-boot.rst @@ -1898,7 +1941,7 @@ wakeup interrupt from RTC. .. _Firmware Design: firmware-design.rst .. _mbed TLS Repository: https://github.com/ARMmbed/mbedtls.git .. _mbed TLS Security Center: https://tls.mbed.org/security -.. _ARM's website: `FVP models`_ +.. _Arm's website: `FVP models`_ .. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms .. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf diff --git a/docs/xlat-tables-lib-v2-design.rst b/docs/xlat-tables-lib-v2-design.rst index 07cbf86c1..d256b6b57 100644 --- a/docs/xlat-tables-lib-v2-design.rst +++ b/docs/xlat-tables-lib-v2-design.rst @@ -9,7 +9,7 @@ Translation Tables Library Design This document describes the design of the translation tables library (version 2) -used by the ARM Trusted Firmware. This library provides APIs to create page +used by Trusted Firmware-A (TF-A). This library provides APIs to create page tables based on a description of the memory layout, as well as setting up system registers related to the Memory Management Unit (MMU) and performing the required Translation Lookaside Buffer (TLB) maintenance operations. @@ -329,7 +329,7 @@ The memory mapping algorithm ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The mapping function is implemented as a recursive algorithm. It is however -bound by the level of depth of the translation tables (the ARMv8-A architecture +bound by the level of depth of the translation tables (the Armv8-A architecture allows up to 4 lookup levels). By default [#granularity-ref]_, the algorithm will attempt to minimize the @@ -376,7 +376,7 @@ changes are visible to subsequent execution, including speculative execution, that uses the changed translation table entries. A counter-example is the initialization of translation tables. In this case, -explicit TLB maintenance is not required. The ARMv8-A architecture guarantees +explicit TLB maintenance is not required. The Armv8-A architecture guarantees that all TLBs are disabled from reset and their contents have no effect on address translation at reset [#tlb-reset-ref]_. Therefore, the TLBs invalidation is deferred to the ``enable_mmu*()`` family of functions, just before the MMU is @@ -391,9 +391,9 @@ descriptor. Given that the TLBs are not architecturally permitted to hold any invalid translation table entry [#tlb-no-invalid-entry]_, this means that this mapping cannot be cached in the TLBs. -.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in ARMv8-A, rev B.a. +.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in Armv8-A, rev B.a. -.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in ARMv8-A, rev B.a. +.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in Armv8-A, rev B.a. Architectural module ~~~~~~~~~~~~~~~~~~~~ @@ -405,7 +405,7 @@ translation context to work on. -------------- -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.* .. _lib/xlat\_tables\_v2: ../lib/xlat_tables_v2 .. _lib/xlat\_tables: ../lib/xlat_tables diff --git a/drivers/arm/gic/v2/gicv2_main.c b/drivers/arm/gic/v2/gicv2_main.c index c65f972d0..7e2c7a7b0 100644 --- a/drivers/arm/gic/v2/gicv2_main.c +++ b/drivers/arm/gic/v2/gicv2_main.c @@ -85,10 +85,17 @@ void gicv2_pcpu_distif_init(void) driver_data->interrupt_props_num); #if !ERROR_DEPRECATED } else { + /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" assert(driver_data->g0_interrupt_array); gicv2_secure_ppi_sgi_setup(driver_data->gicd_base, driver_data->g0_interrupt_num, driver_data->g0_interrupt_array); +#pragma GCC diagnostic pop } #endif @@ -128,12 +135,20 @@ void gicv2_distif_init(void) driver_data->interrupt_props_num); #if !ERROR_DEPRECATED } else { + /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" + assert(driver_data->g0_interrupt_array); /* Configure the G0 SPIs */ gicv2_secure_spis_configure(driver_data->gicd_base, driver_data->g0_interrupt_num, driver_data->g0_interrupt_array); +#pragma GCC diagnostic pop } #endif @@ -156,6 +171,13 @@ void gicv2_driver_init(const gicv2_driver_data_t *plat_driver_data) /* Interrupt properties array size must be 0 */ assert(plat_driver_data->interrupt_props_num == 0); + /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" + /* The platform should provide a list of secure interrupts */ assert(plat_driver_data->g0_interrupt_array); @@ -166,6 +188,11 @@ void gicv2_driver_init(const gicv2_driver_data_t *plat_driver_data) assert(plat_driver_data->g0_interrupt_array ? plat_driver_data->g0_interrupt_num : plat_driver_data->g0_interrupt_num == 0); +#pragma GCC diagnostic pop + + WARN("Using deprecated integer interrupt array in " + "gicv2_driver_data_t\n"); + WARN("Please migrate to using an interrupt_prop_t array\n"); } #else assert(plat_driver_data->interrupt_props != NULL); diff --git a/drivers/arm/gic/v3/gicv3_main.c b/drivers/arm/gic/v3/gicv3_main.c index 45a2e5bca..f4a3ef81f 100644 --- a/drivers/arm/gic/v3/gicv3_main.c +++ b/drivers/arm/gic/v3/gicv3_main.c @@ -73,6 +73,13 @@ void gicv3_driver_init(const gicv3_driver_data_t *plat_driver_data) assert(plat_driver_data->interrupt_props_num == 0); /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" + + /* * The platform should provide a list of at least one type of * interrupt. */ @@ -89,6 +96,11 @@ void gicv3_driver_init(const gicv3_driver_data_t *plat_driver_data) assert(plat_driver_data->g1s_interrupt_array ? plat_driver_data->g1s_interrupt_num : plat_driver_data->g1s_interrupt_num == 0); +#pragma GCC diagnostic pop + + WARN("Using deprecated integer interrupt arrays in " + "gicv3_driver_data_t\n"); + WARN("Please migrate to using interrupt_prop_t arrays\n"); } #else assert(plat_driver_data->interrupt_props != NULL); @@ -189,6 +201,13 @@ void gicv3_distif_init(void) gicv3_driver_data->interrupt_props_num); #if !ERROR_DEPRECATED } else { + /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" + assert(gicv3_driver_data->g1s_interrupt_array || gicv3_driver_data->g0_interrupt_array); @@ -209,6 +228,7 @@ void gicv3_distif_init(void) INTR_GROUP0); bitmap |= CTLR_ENABLE_G0_BIT; } +#pragma GCC diagnostic pop } #endif @@ -253,6 +273,13 @@ void gicv3_rdistif_init(unsigned int proc_num) gicv3_driver_data->interrupt_props_num); #if !ERROR_DEPRECATED } else { + /* + * Suppress deprecated declaration warnings in compatibility + * function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" + assert(gicv3_driver_data->g1s_interrupt_array || gicv3_driver_data->g0_interrupt_array); @@ -273,6 +300,7 @@ void gicv3_rdistif_init(unsigned int proc_num) INTR_GROUP0); bitmap |= CTLR_ENABLE_G0_BIT; } +#pragma GCC diagnostic pop } #endif diff --git a/drivers/console/aarch64/deprecated_console.S b/drivers/console/aarch64/deprecated_console.S index c83e2467b..d6ecc4df2 100644 --- a/drivers/console/aarch64/deprecated_console.S +++ b/drivers/console/aarch64/deprecated_console.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -9,6 +9,7 @@ * This is the common console core code for the deprecated single-console API. * New platforms should set MULTI_CONSOLE_API=1 and not use this file. */ +#warning "Using deprecated console implementation. Please migrate to MULTI_CONSOLE_API" .globl console_init .globl console_uninit diff --git a/include/common/runtime_svc.h b/include/common/runtime_svc.h index 6150b3227..d12af227e 100644 --- a/include/common/runtime_svc.h +++ b/include/common/runtime_svc.h @@ -8,7 +8,7 @@ #define __RUNTIME_SVC_H__ #include <bl_common.h> /* to include exception types */ -#include <smcc_helpers.h> /* to include SMCC definitions */ +#include <smccc_helpers.h> /* to include SMCCC definitions */ /******************************************************************************* diff --git a/include/drivers/arm/gicv2.h b/include/drivers/arm/gicv2.h index 6e8322e1b..39c73027e 100644 --- a/include/drivers/arm/gicv2.h +++ b/include/drivers/arm/gicv2.h @@ -155,8 +155,8 @@ typedef struct gicv2_driver_data { uintptr_t gicd_base; uintptr_t gicc_base; #if !ERROR_DEPRECATED - unsigned int g0_interrupt_num; - const unsigned int *g0_interrupt_array; + unsigned int g0_interrupt_num __deprecated; + const unsigned int *g0_interrupt_array __deprecated; #endif unsigned int *target_masks; unsigned int target_masks_num; diff --git a/include/drivers/arm/gicv3.h b/include/drivers/arm/gicv3.h index 5f265c6e4..37c92e4f8 100644 --- a/include/drivers/arm/gicv3.h +++ b/include/drivers/arm/gicv3.h @@ -310,10 +310,10 @@ typedef struct gicv3_driver_data { uintptr_t gicd_base; uintptr_t gicr_base; #if !ERROR_DEPRECATED - unsigned int g0_interrupt_num; - unsigned int g1s_interrupt_num; - const unsigned int *g0_interrupt_array; - const unsigned int *g1s_interrupt_array; + unsigned int g0_interrupt_num __deprecated; + unsigned int g1s_interrupt_num __deprecated; + const unsigned int *g0_interrupt_array __deprecated; + const unsigned int *g1s_interrupt_array __deprecated; #endif const interrupt_prop_t *interrupt_props; unsigned int interrupt_props_num; diff --git a/include/drivers/console.h b/include/drivers/console.h index 0629f5717..f8ec83d2f 100644 --- a/include/drivers/console.h +++ b/include/drivers/console.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -63,10 +63,10 @@ int console_getc(void); int console_flush(void); #if !MULTI_CONSOLE_API -/* DEPRECATED on AArch64 -- use console_<driver>_register() instead! */ +/* REMOVED on AArch64 -- use console_<driver>_register() instead! */ int console_init(uintptr_t base_addr, - unsigned int uart_clk, unsigned int baud_rate) __deprecated; -void console_uninit(void) __deprecated; + unsigned int uart_clk, unsigned int baud_rate); +void console_uninit(void); #endif #endif /* __ASSEMBLY__ */ diff --git a/include/lib/aarch32/smcc_helpers.h b/include/lib/aarch32/smcc_helpers.h index ed3b722fe..7f79f8fa2 100644 --- a/include/lib/aarch32/smcc_helpers.h +++ b/include/lib/aarch32/smcc_helpers.h @@ -7,159 +7,8 @@ #ifndef __SMCC_HELPERS_H__ #define __SMCC_HELPERS_H__ -#include <smcc.h> +#if !ERROR_DEPRECATED +#include <smccc_helpers.h> +#endif -/* These are offsets to registers in smc_ctx_t */ -#define SMC_CTX_GPREG_R0 0x0 -#define SMC_CTX_GPREG_R1 0x4 -#define SMC_CTX_GPREG_R2 0x8 -#define SMC_CTX_GPREG_R3 0xC -#define SMC_CTX_GPREG_R4 0x10 -#define SMC_CTX_GPREG_R5 0x14 -#define SMC_CTX_SP_USR 0x34 -#define SMC_CTX_SPSR_MON 0x78 -#define SMC_CTX_SP_MON 0x7C -#define SMC_CTX_LR_MON 0x80 -#define SMC_CTX_SCR 0x84 -#define SMC_CTX_PMCR 0x88 -#define SMC_CTX_SIZE 0x90 - -#ifndef __ASSEMBLY__ -#include <cassert.h> -#include <types.h> - -/* - * The generic structure to save arguments and callee saved registers during - * an SMC. Also this structure is used to store the result return values after - * the completion of SMC service. - */ -typedef struct smc_ctx { - u_register_t r0; - u_register_t r1; - u_register_t r2; - u_register_t r3; - u_register_t r4; - u_register_t r5; - u_register_t r6; - u_register_t r7; - u_register_t r8; - u_register_t r9; - u_register_t r10; - u_register_t r11; - u_register_t r12; - /* spsr_usr doesn't exist */ - u_register_t sp_usr; - u_register_t lr_usr; - u_register_t spsr_irq; - u_register_t sp_irq; - u_register_t lr_irq; - u_register_t spsr_fiq; - u_register_t sp_fiq; - u_register_t lr_fiq; - u_register_t spsr_svc; - u_register_t sp_svc; - u_register_t lr_svc; - u_register_t spsr_abt; - u_register_t sp_abt; - u_register_t lr_abt; - u_register_t spsr_und; - u_register_t sp_und; - u_register_t lr_und; - u_register_t spsr_mon; - /* - * `sp_mon` will point to the C runtime stack in monitor mode. But prior - * to exit from SMC, this will point to the `smc_ctx_t` so that - * on next entry due to SMC, the `smc_ctx_t` can be easily accessed. - */ - u_register_t sp_mon; - u_register_t lr_mon; - u_register_t scr; - u_register_t pmcr; - /* - * The workaround for CVE-2017-5715 requires storing information in - * the bottom 3 bits of the stack pointer. Add a padding field to - * force the size of the struct to be a multiple of 8. - */ - u_register_t pad; -} smc_ctx_t __aligned(8); - -/* - * Compile time assertions related to the 'smc_context' structure to - * ensure that the assembler and the compiler view of the offsets of - * the structure members is the same. - */ -CASSERT(SMC_CTX_GPREG_R0 == __builtin_offsetof(smc_ctx_t, r0), \ - assert_smc_ctx_greg_r0_offset_mismatch); -CASSERT(SMC_CTX_GPREG_R1 == __builtin_offsetof(smc_ctx_t, r1), \ - assert_smc_ctx_greg_r1_offset_mismatch); -CASSERT(SMC_CTX_GPREG_R2 == __builtin_offsetof(smc_ctx_t, r2), \ - assert_smc_ctx_greg_r2_offset_mismatch); -CASSERT(SMC_CTX_GPREG_R3 == __builtin_offsetof(smc_ctx_t, r3), \ - assert_smc_ctx_greg_r3_offset_mismatch); -CASSERT(SMC_CTX_GPREG_R4 == __builtin_offsetof(smc_ctx_t, r4), \ - assert_smc_ctx_greg_r4_offset_mismatch); -CASSERT(SMC_CTX_SP_USR == __builtin_offsetof(smc_ctx_t, sp_usr), \ - assert_smc_ctx_sp_usr_offset_mismatch); -CASSERT(SMC_CTX_LR_MON == __builtin_offsetof(smc_ctx_t, lr_mon), \ - assert_smc_ctx_lr_mon_offset_mismatch); -CASSERT(SMC_CTX_SPSR_MON == __builtin_offsetof(smc_ctx_t, spsr_mon), \ - assert_smc_ctx_spsr_mon_offset_mismatch); - -CASSERT((sizeof(smc_ctx_t) & 0x7) == 0, assert_smc_ctx_not_aligned); -CASSERT(SMC_CTX_SIZE == sizeof(smc_ctx_t), assert_smc_ctx_size_mismatch); - -/* Convenience macros to return from SMC handler */ -#define SMC_RET0(_h) { \ - return (uintptr_t)(_h); \ -} -#define SMC_RET1(_h, _r0) { \ - ((smc_ctx_t *)(_h))->r0 = (_r0); \ - SMC_RET0(_h); \ -} -#define SMC_RET2(_h, _r0, _r1) { \ - ((smc_ctx_t *)(_h))->r1 = (_r1); \ - SMC_RET1(_h, (_r0)); \ -} -#define SMC_RET3(_h, _r0, _r1, _r2) { \ - ((smc_ctx_t *)(_h))->r2 = (_r2); \ - SMC_RET2(_h, (_r0), (_r1)); \ -} -#define SMC_RET4(_h, _r0, _r1, _r2, _r3) { \ - ((smc_ctx_t *)(_h))->r3 = (_r3); \ - SMC_RET3(_h, (_r0), (_r1), (_r2)); \ -} - -/* Return a UUID in the SMC return registers */ -#define SMC_UUID_RET(_h, _uuid) \ - SMC_RET4(handle, ((const uint32_t *) &(_uuid))[0], \ - ((const uint32_t *) &(_uuid))[1], \ - ((const uint32_t *) &(_uuid))[2], \ - ((const uint32_t *) &(_uuid))[3]) - -/* - * Helper macro to retrieve the SMC parameters from smc_ctx_t. - */ -#define get_smc_params_from_ctx(_hdl, _r1, _r2, _r3, _r4) { \ - _r1 = ((smc_ctx_t *)_hdl)->r1; \ - _r2 = ((smc_ctx_t *)_hdl)->r2; \ - _r3 = ((smc_ctx_t *)_hdl)->r3; \ - _r4 = ((smc_ctx_t *)_hdl)->r4; \ - } - -/* ------------------------------------------------------------------------ - * Helper APIs for setting and retrieving appropriate `smc_ctx_t`. - * These functions need to implemented by the BL including this library. - * ------------------------------------------------------------------------ - */ - -/* Get the pointer to `smc_ctx_t` corresponding to the security state. */ -void *smc_get_ctx(unsigned int security_state); - -/* Set the next `smc_ctx_t` corresponding to the security state. */ -void smc_set_next_ctx(unsigned int security_state); - -/* Get the pointer to next `smc_ctx_t` already set by `smc_set_next_ctx()`. */ -void *smc_get_next_ctx(void); - -#endif /*__ASSEMBLY__*/ #endif /* __SMCC_HELPERS_H__ */ diff --git a/include/lib/aarch32/smcc_macros.S b/include/lib/aarch32/smcc_macros.S index 93f211f7a..66f3d0ea4 100644 --- a/include/lib/aarch32/smcc_macros.S +++ b/include/lib/aarch32/smcc_macros.S @@ -1,199 +1,15 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #ifndef __SMCC_MACROS_S__ #define __SMCC_MACROS_S__ -#include <arch.h> +#if !ERROR_DEPRECATED +#include <smccc_macros.S> -/* - * Macro to save the General purpose registers (r0 - r12), the banked - * spsr, lr, sp registers and the `scr` register to the SMC context on entry - * due a SMC call. The `lr` of the current mode (monitor) is expected to be - * already saved. The `sp` must point to the `smc_ctx_t` to save to. - * Additionally, also save the 'pmcr' register as this is updated whilst - * executing in the secure world. - */ - .macro smcc_save_gp_mode_regs - /* Save r0 - r12 in the SMC context */ - stm sp, {r0-r12} - mov r0, sp - add r0, r0, #SMC_CTX_SP_USR - -#if ARM_ARCH_MAJOR == 7 && !defined(ARMV7_SUPPORTS_VIRTUALIZATION) - /* Must be in secure state to restore Monitor mode */ - ldcopr r4, SCR - bic r2, r4, #SCR_NS_BIT - stcopr r2, SCR - isb - - cps #MODE32_sys - stm r0!, {sp, lr} - - cps #MODE32_irq - mrs r2, spsr - stm r0!, {r2, sp, lr} - - cps #MODE32_fiq - mrs r2, spsr - stm r0!, {r2, sp, lr} - - cps #MODE32_svc - mrs r2, spsr - stm r0!, {r2, sp, lr} - - cps #MODE32_abt - mrs r2, spsr - stm r0!, {r2, sp, lr} - - cps #MODE32_und - mrs r2, spsr - stm r0!, {r2, sp, lr} - - /* lr_mon is already saved by caller */ - cps #MODE32_mon - mrs r2, spsr - stm r0!, {r2} - - stcopr r4, SCR - isb -#else - /* Save the banked registers including the current SPSR and LR */ - mrs r4, sp_usr - mrs r5, lr_usr - mrs r6, spsr_irq - mrs r7, sp_irq - mrs r8, lr_irq - mrs r9, spsr_fiq - mrs r10, sp_fiq - mrs r11, lr_fiq - mrs r12, spsr_svc - stm r0!, {r4-r12} - - mrs r4, sp_svc - mrs r5, lr_svc - mrs r6, spsr_abt - mrs r7, sp_abt - mrs r8, lr_abt - mrs r9, spsr_und - mrs r10, sp_und - mrs r11, lr_und - mrs r12, spsr - stm r0!, {r4-r12} - /* lr_mon is already saved by caller */ - - ldcopr r4, SCR -#endif - str r4, [sp, #SMC_CTX_SCR] - ldcopr r4, PMCR - str r4, [sp, #SMC_CTX_PMCR] - .endm - -/* - * Macro to restore the `smc_ctx_t`, which includes the General purpose - * registers and banked mode registers, and exit from the monitor mode. - * r0 must point to the `smc_ctx_t` to restore from. - */ - .macro monitor_exit - /* - * Save the current sp and restore the smc context - * pointer to sp which will be used for handling the - * next SMC. - */ - str sp, [r0, #SMC_CTX_SP_MON] - mov sp, r0 - - /* - * Restore SCR first so that we access the right banked register - * when the other mode registers are restored. - */ - ldr r1, [r0, #SMC_CTX_SCR] - stcopr r1, SCR - isb - - /* - * Restore the PMCR register. - */ - ldr r1, [r0, #SMC_CTX_PMCR] - stcopr r1, PMCR - - /* Restore the banked registers including the current SPSR */ - add r1, r0, #SMC_CTX_SP_USR - -#if ARM_ARCH_MAJOR == 7 && !defined(ARMV7_SUPPORTS_VIRTUALIZATION) - /* Must be in secure state to restore Monitor mode */ - ldcopr r4, SCR - bic r2, r4, #SCR_NS_BIT - stcopr r2, SCR - isb - - cps #MODE32_sys - ldm r1!, {sp, lr} - - cps #MODE32_irq - ldm r1!, {r2, sp, lr} - msr spsr_fsxc, r2 - - cps #MODE32_fiq - ldm r1!, {r2, sp, lr} - msr spsr_fsxc, r2 - - cps #MODE32_svc - ldm r1!, {r2, sp, lr} - msr spsr_fsxc, r2 - - cps #MODE32_abt - ldm r1!, {r2, sp, lr} - msr spsr_fsxc, r2 - - cps #MODE32_und - ldm r1!, {r2, sp, lr} - msr spsr_fsxc, r2 - - cps #MODE32_mon - ldm r1!, {r2} - msr spsr_fsxc, r2 - - stcopr r4, SCR - isb -#else - ldm r1!, {r4-r12} - msr sp_usr, r4 - msr lr_usr, r5 - msr spsr_irq, r6 - msr sp_irq, r7 - msr lr_irq, r8 - msr spsr_fiq, r9 - msr sp_fiq, r10 - msr lr_fiq, r11 - msr spsr_svc, r12 - - ldm r1!, {r4-r12} - msr sp_svc, r4 - msr lr_svc, r5 - msr spsr_abt, r6 - msr sp_abt, r7 - msr lr_abt, r8 - msr spsr_und, r9 - msr sp_und, r10 - msr lr_und, r11 - /* - * Use the `_fsxc` suffix explicitly to instruct the assembler - * to update all the 32 bits of SPSR. Else, by default, the - * assembler assumes `_fc` suffix which only modifies - * f->[31:24] and c->[7:0] bits of SPSR. - */ - msr spsr_fsxc, r12 +#define smcc_save_gp_mode_regs smccc_save_gp_mode_regs #endif - /* Restore the LR */ - ldr lr, [r0, #SMC_CTX_LR_MON] - - /* Restore the rest of the general purpose registers */ - ldm r0, {r0-r12} - eret - .endm - #endif /* __SMCC_MACROS_S__ */ diff --git a/include/lib/aarch32/smccc_helpers.h b/include/lib/aarch32/smccc_helpers.h new file mode 100644 index 000000000..240dd13fb --- /dev/null +++ b/include/lib/aarch32/smccc_helpers.h @@ -0,0 +1,166 @@ +/* + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef __SMCCC_HELPERS_H__ +#define __SMCCC_HELPERS_H__ + +#include <smccc.h> + +/* These are offsets to registers in smc_ctx_t */ +#define SMC_CTX_GPREG_R0 0x0 +#define SMC_CTX_GPREG_R1 0x4 +#define SMC_CTX_GPREG_R2 0x8 +#define SMC_CTX_GPREG_R3 0xC +#define SMC_CTX_GPREG_R4 0x10 +#define SMC_CTX_GPREG_R5 0x14 +#define SMC_CTX_SP_USR 0x34 +#define SMC_CTX_SPSR_MON 0x78 +#define SMC_CTX_SP_MON 0x7C +#define SMC_CTX_LR_MON 0x80 +#define SMC_CTX_SCR 0x84 +#define SMC_CTX_PMCR 0x88 +#define SMC_CTX_SIZE 0x90 + +#ifndef __ASSEMBLY__ +#include <cassert.h> +#include <types.h> + +/* + * The generic structure to save arguments and callee saved registers during + * an SMC. Also this structure is used to store the result return values after + * the completion of SMC service. + */ +typedef struct smc_ctx { + u_register_t r0; + u_register_t r1; + u_register_t r2; + u_register_t r3; + u_register_t r4; + u_register_t r5; + u_register_t r6; + u_register_t r7; + u_register_t r8; + u_register_t r9; + u_register_t r10; + u_register_t r11; + u_register_t r12; + /* spsr_usr doesn't exist */ + u_register_t sp_usr; + u_register_t lr_usr; + u_register_t spsr_irq; + u_register_t sp_irq; + u_register_t lr_irq; + u_register_t spsr_fiq; + u_register_t sp_fiq; + u_register_t lr_fiq; + u_register_t spsr_svc; + u_register_t sp_svc; + u_register_t lr_svc; + u_register_t spsr_abt; + u_register_t sp_abt; + u_register_t lr_abt; + u_register_t spsr_und; + u_register_t sp_und; + u_register_t lr_und; + u_register_t spsr_mon; + /* + * `sp_mon` will point to the C runtime stack in monitor mode. But prior + * to exit from SMC, this will point to the `smc_ctx_t` so that + * on next entry due to SMC, the `smc_ctx_t` can be easily accessed. + */ + u_register_t sp_mon; + u_register_t lr_mon; + u_register_t scr; + u_register_t pmcr; + /* + * The workaround for CVE-2017-5715 requires storing information in + * the bottom 3 bits of the stack pointer. Add a padding field to + * force the size of the struct to be a multiple of 8. + */ + u_register_t pad; +} smc_ctx_t __aligned(8); + +/* + * Compile time assertions related to the 'smc_context' structure to + * ensure that the assembler and the compiler view of the offsets of + * the structure members is the same. + */ +CASSERT(SMC_CTX_GPREG_R0 == __builtin_offsetof(smc_ctx_t, r0), \ + assert_smc_ctx_greg_r0_offset_mismatch); +CASSERT(SMC_CTX_GPREG_R1 == __builtin_offsetof(smc_ctx_t, r1), \ + assert_smc_ctx_greg_r1_offset_mismatch); +CASSERT(SMC_CTX_GPREG_R2 == __builtin_offsetof(smc_ctx_t, r2), \ + assert_smc_ctx_greg_r2_offset_mismatch); +CASSERT(SMC_CTX_GPREG_R3 == __builtin_offsetof(smc_ctx_t, r3), \ + assert_smc_ctx_greg_r3_offset_mismatch); +CASSERT(SMC_CTX_GPREG_R4 == __builtin_offsetof(smc_ctx_t, r4), \ + assert_smc_ctx_greg_r4_offset_mismatch); +CASSERT(SMC_CTX_SP_USR == __builtin_offsetof(smc_ctx_t, sp_usr), \ + assert_smc_ctx_sp_usr_offset_mismatch); +CASSERT(SMC_CTX_LR_MON == __builtin_offsetof(smc_ctx_t, lr_mon), \ + assert_smc_ctx_lr_mon_offset_mismatch); +CASSERT(SMC_CTX_SPSR_MON == __builtin_offsetof(smc_ctx_t, spsr_mon), \ + assert_smc_ctx_spsr_mon_offset_mismatch); + +CASSERT((sizeof(smc_ctx_t) & 0x7) == 0, assert_smc_ctx_not_aligned); +CASSERT(SMC_CTX_SIZE == sizeof(smc_ctx_t), assert_smc_ctx_size_mismatch); + +/* Convenience macros to return from SMC handler */ +#define SMC_RET0(_h) { \ + return (uintptr_t)(_h); \ +} +#define SMC_RET1(_h, _r0) { \ + ((smc_ctx_t *)(_h))->r0 = (_r0); \ + SMC_RET0(_h); \ +} +#define SMC_RET2(_h, _r0, _r1) { \ + ((smc_ctx_t *)(_h))->r1 = (_r1); \ + SMC_RET1(_h, (_r0)); \ +} +#define SMC_RET3(_h, _r0, _r1, _r2) { \ + ((smc_ctx_t *)(_h))->r2 = (_r2); \ + SMC_RET2(_h, (_r0), (_r1)); \ +} +#define SMC_RET4(_h, _r0, _r1, _r2, _r3) { \ + ((smc_ctx_t *)(_h))->r3 = (_r3); \ + SMC_RET3(_h, (_r0), (_r1), (_r2)); \ +} + +/* Return a UUID in the SMC return registers */ +#define SMC_UUID_RET(_h, _uuid) \ + SMC_RET4(handle, ((const uint32_t *) &(_uuid))[0], \ + ((const uint32_t *) &(_uuid))[1], \ + ((const uint32_t *) &(_uuid))[2], \ + ((const uint32_t *) &(_uuid))[3]) + +/* + * Helper macro to retrieve the SMC parameters from smc_ctx_t. + */ +#define get_smc_params_from_ctx(_hdl, _r1, _r2, _r3, _r4) { \ + _r1 = ((smc_ctx_t *)_hdl)->r1; \ + _r2 = ((smc_ctx_t *)_hdl)->r2; \ + _r3 = ((smc_ctx_t *)_hdl)->r3; \ + _r4 = ((smc_ctx_t *)_hdl)->r4; \ + } + +/* ------------------------------------------------------------------------ + * Helper APIs for setting and retrieving appropriate `smc_ctx_t`. + * These functions need to implemented by the BL including this library. + * ------------------------------------------------------------------------ + */ + +/* Get the pointer to `smc_ctx_t` corresponding to the security state. */ +void *smc_get_ctx(unsigned int security_state); + +/* Set the next `smc_ctx_t` corresponding to the security state. */ +void smc_set_next_ctx(unsigned int security_state); + +/* Get the pointer to next `smc_ctx_t` already set by `smc_set_next_ctx()`. */ +void *smc_get_next_ctx(void); + +#endif /*__ASSEMBLY__*/ + +#endif /* __SMCCC_HELPERS_H__ */ diff --git a/include/lib/aarch32/smccc_macros.S b/include/lib/aarch32/smccc_macros.S new file mode 100644 index 000000000..fdb65e80a --- /dev/null +++ b/include/lib/aarch32/smccc_macros.S @@ -0,0 +1,199 @@ +/* + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ +#ifndef __SMCCC_MACROS_S__ +#define __SMCCC_MACROS_S__ + +#include <arch.h> + +/* + * Macro to save the General purpose registers (r0 - r12), the banked + * spsr, lr, sp registers and the `scr` register to the SMC context on entry + * due a SMC call. The `lr` of the current mode (monitor) is expected to be + * already saved. The `sp` must point to the `smc_ctx_t` to save to. + * Additionally, also save the 'pmcr' register as this is updated whilst + * executing in the secure world. + */ + .macro smccc_save_gp_mode_regs + /* Save r0 - r12 in the SMC context */ + stm sp, {r0-r12} + mov r0, sp + add r0, r0, #SMC_CTX_SP_USR + +#if ARM_ARCH_MAJOR == 7 && !defined(ARMV7_SUPPORTS_VIRTUALIZATION) + /* Must be in secure state to restore Monitor mode */ + ldcopr r4, SCR + bic r2, r4, #SCR_NS_BIT + stcopr r2, SCR + isb + + cps #MODE32_sys + stm r0!, {sp, lr} + + cps #MODE32_irq + mrs r2, spsr + stm r0!, {r2, sp, lr} + + cps #MODE32_fiq + mrs r2, spsr + stm r0!, {r2, sp, lr} + + cps #MODE32_svc + mrs r2, spsr + stm r0!, {r2, sp, lr} + + cps #MODE32_abt + mrs r2, spsr + stm r0!, {r2, sp, lr} + + cps #MODE32_und + mrs r2, spsr + stm r0!, {r2, sp, lr} + + /* lr_mon is already saved by caller */ + cps #MODE32_mon + mrs r2, spsr + stm r0!, {r2} + + stcopr r4, SCR + isb +#else + /* Save the banked registers including the current SPSR and LR */ + mrs r4, sp_usr + mrs r5, lr_usr + mrs r6, spsr_irq + mrs r7, sp_irq + mrs r8, lr_irq + mrs r9, spsr_fiq + mrs r10, sp_fiq + mrs r11, lr_fiq + mrs r12, spsr_svc + stm r0!, {r4-r12} + + mrs r4, sp_svc + mrs r5, lr_svc + mrs r6, spsr_abt + mrs r7, sp_abt + mrs r8, lr_abt + mrs r9, spsr_und + mrs r10, sp_und + mrs r11, lr_und + mrs r12, spsr + stm r0!, {r4-r12} + /* lr_mon is already saved by caller */ + + ldcopr r4, SCR +#endif + str r4, [sp, #SMC_CTX_SCR] + ldcopr r4, PMCR + str r4, [sp, #SMC_CTX_PMCR] + .endm + +/* + * Macro to restore the `smc_ctx_t`, which includes the General purpose + * registers and banked mode registers, and exit from the monitor mode. + * r0 must point to the `smc_ctx_t` to restore from. + */ + .macro monitor_exit + /* + * Save the current sp and restore the smc context + * pointer to sp which will be used for handling the + * next SMC. + */ + str sp, [r0, #SMC_CTX_SP_MON] + mov sp, r0 + + /* + * Restore SCR first so that we access the right banked register + * when the other mode registers are restored. + */ + ldr r1, [r0, #SMC_CTX_SCR] + stcopr r1, SCR + isb + + /* + * Restore the PMCR register. + */ + ldr r1, [r0, #SMC_CTX_PMCR] + stcopr r1, PMCR + + /* Restore the banked registers including the current SPSR */ + add r1, r0, #SMC_CTX_SP_USR + +#if ARM_ARCH_MAJOR == 7 && !defined(ARMV7_SUPPORTS_VIRTUALIZATION) + /* Must be in secure state to restore Monitor mode */ + ldcopr r4, SCR + bic r2, r4, #SCR_NS_BIT + stcopr r2, SCR + isb + + cps #MODE32_sys + ldm r1!, {sp, lr} + + cps #MODE32_irq + ldm r1!, {r2, sp, lr} + msr spsr_fsxc, r2 + + cps #MODE32_fiq + ldm r1!, {r2, sp, lr} + msr spsr_fsxc, r2 + + cps #MODE32_svc + ldm r1!, {r2, sp, lr} + msr spsr_fsxc, r2 + + cps #MODE32_abt + ldm r1!, {r2, sp, lr} + msr spsr_fsxc, r2 + + cps #MODE32_und + ldm r1!, {r2, sp, lr} + msr spsr_fsxc, r2 + + cps #MODE32_mon + ldm r1!, {r2} + msr spsr_fsxc, r2 + + stcopr r4, SCR + isb +#else + ldm r1!, {r4-r12} + msr sp_usr, r4 + msr lr_usr, r5 + msr spsr_irq, r6 + msr sp_irq, r7 + msr lr_irq, r8 + msr spsr_fiq, r9 + msr sp_fiq, r10 + msr lr_fiq, r11 + msr spsr_svc, r12 + + ldm r1!, {r4-r12} + msr sp_svc, r4 + msr lr_svc, r5 + msr spsr_abt, r6 + msr sp_abt, r7 + msr lr_abt, r8 + msr spsr_und, r9 + msr sp_und, r10 + msr lr_und, r11 + /* + * Use the `_fsxc` suffix explicitly to instruct the assembler + * to update all the 32 bits of SPSR. Else, by default, the + * assembler assumes `_fc` suffix which only modifies + * f->[31:24] and c->[7:0] bits of SPSR. + */ + msr spsr_fsxc, r12 +#endif + + /* Restore the LR */ + ldr lr, [r0, #SMC_CTX_LR_MON] + + /* Restore the rest of the general purpose registers */ + ldm r0, {r0-r12} + eret + .endm + +#endif /* __SMCCC_MACROS_S__ */ diff --git a/include/lib/aarch64/smcc_helpers.h b/include/lib/aarch64/smcc_helpers.h index 62294d049..11300b7eb 100644 --- a/include/lib/aarch64/smcc_helpers.h +++ b/include/lib/aarch64/smcc_helpers.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -7,84 +7,8 @@ #ifndef __SMCC_HELPERS_H__ #define __SMCC_HELPERS_H__ -#include <smcc.h> +#if !ERROR_DEPRECATED +#include <smccc_helpers.h> +#endif -#ifndef __ASSEMBLY__ -#include <context.h> - -/* Convenience macros to return from SMC handler */ -#define SMC_RET0(_h) { \ - return (uint64_t) (_h); \ -} -#define SMC_RET1(_h, _x0) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X0), (_x0)); \ - SMC_RET0(_h); \ -} -#define SMC_RET2(_h, _x0, _x1) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X1), (_x1)); \ - SMC_RET1(_h, (_x0)); \ -} -#define SMC_RET3(_h, _x0, _x1, _x2) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X2), (_x2)); \ - SMC_RET2(_h, (_x0), (_x1)); \ -} -#define SMC_RET4(_h, _x0, _x1, _x2, _x3) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X3), (_x3)); \ - SMC_RET3(_h, (_x0), (_x1), (_x2)); \ -} -#define SMC_RET5(_h, _x0, _x1, _x2, _x3, _x4) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X4), (_x4)); \ - SMC_RET4(_h, (_x0), (_x1), (_x2), (_x3)); \ -} -#define SMC_RET6(_h, _x0, _x1, _x2, _x3, _x4, _x5) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X5), (_x5)); \ - SMC_RET5(_h, (_x0), (_x1), (_x2), (_x3), (_x4)); \ -} -#define SMC_RET7(_h, _x0, _x1, _x2, _x3, _x4, _x5, _x6) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X6), (_x6)); \ - SMC_RET6(_h, (_x0), (_x1), (_x2), (_x3), (_x4), (_x5)); \ -} -#define SMC_RET8(_h, _x0, _x1, _x2, _x3, _x4, _x5, _x6, _x7) { \ - write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X7), (_x7)); \ - SMC_RET7(_h, (_x0), (_x1), (_x2), (_x3), (_x4), (_x5), (_x6)); \ -} - -/* - * Convenience macros to access general purpose registers using handle provided - * to SMC handler. These take the offset values defined in context.h - */ -#define SMC_GET_GP(_h, _g) \ - read_ctx_reg((get_gpregs_ctx(_h)), (_g)) -#define SMC_SET_GP(_h, _g, _v) \ - write_ctx_reg((get_gpregs_ctx(_h)), (_g), (_v)) - -/* - * Convenience macros to access EL3 context registers using handle provided to - * SMC handler. These take the offset values defined in context.h - */ -#define SMC_GET_EL3(_h, _e) \ - read_ctx_reg((get_el3state_ctx(_h)), (_e)) -#define SMC_SET_EL3(_h, _e, _v) \ - write_ctx_reg((get_el3state_ctx(_h)), (_e), (_v)) - -/* Return a UUID in the SMC return registers */ -#define SMC_UUID_RET(_h, _uuid) \ - SMC_RET4(handle, ((const uint32_t *) &(_uuid))[0], \ - ((const uint32_t *) &(_uuid))[1], \ - ((const uint32_t *) &(_uuid))[2], \ - ((const uint32_t *) &(_uuid))[3]) - -/* - * Helper macro to retrieve the SMC parameters from cpu_context_t. - */ -#define get_smc_params_from_ctx(_hdl, _x1, _x2, _x3, _x4) \ - do { \ - const gp_regs_t *regs = get_gpregs_ctx(_hdl); \ - _x1 = read_ctx_reg(regs, CTX_GPREG_X1); \ - _x2 = read_ctx_reg(regs, CTX_GPREG_X2); \ - _x3 = read_ctx_reg(regs, CTX_GPREG_X3); \ - _x4 = read_ctx_reg(regs, CTX_GPREG_X4); \ - } while (0) - -#endif /*__ASSEMBLY__*/ #endif /* __SMCC_HELPERS_H__ */ diff --git a/include/lib/aarch64/smccc_helpers.h b/include/lib/aarch64/smccc_helpers.h new file mode 100644 index 000000000..1b33a0d15 --- /dev/null +++ b/include/lib/aarch64/smccc_helpers.h @@ -0,0 +1,91 @@ +/* + * Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef __SMCCC_HELPERS_H__ +#define __SMCCC_HELPERS_H__ + +#include <smccc.h> + +#ifndef __ASSEMBLY__ +#include <context.h> + +/* Convenience macros to return from SMC handler */ +#define SMC_RET0(_h) { \ + return (uint64_t) (_h); \ +} +#define SMC_RET1(_h, _x0) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X0), (_x0)); \ + SMC_RET0(_h); \ +} +#define SMC_RET2(_h, _x0, _x1) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X1), (_x1)); \ + SMC_RET1(_h, (_x0)); \ +} +#define SMC_RET3(_h, _x0, _x1, _x2) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X2), (_x2)); \ + SMC_RET2(_h, (_x0), (_x1)); \ +} +#define SMC_RET4(_h, _x0, _x1, _x2, _x3) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X3), (_x3)); \ + SMC_RET3(_h, (_x0), (_x1), (_x2)); \ +} +#define SMC_RET5(_h, _x0, _x1, _x2, _x3, _x4) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X4), (_x4)); \ + SMC_RET4(_h, (_x0), (_x1), (_x2), (_x3)); \ +} +#define SMC_RET6(_h, _x0, _x1, _x2, _x3, _x4, _x5) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X5), (_x5)); \ + SMC_RET5(_h, (_x0), (_x1), (_x2), (_x3), (_x4)); \ +} +#define SMC_RET7(_h, _x0, _x1, _x2, _x3, _x4, _x5, _x6) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X6), (_x6)); \ + SMC_RET6(_h, (_x0), (_x1), (_x2), (_x3), (_x4), (_x5)); \ +} +#define SMC_RET8(_h, _x0, _x1, _x2, _x3, _x4, _x5, _x6, _x7) { \ + write_ctx_reg((get_gpregs_ctx(_h)), (CTX_GPREG_X7), (_x7)); \ + SMC_RET7(_h, (_x0), (_x1), (_x2), (_x3), (_x4), (_x5), (_x6)); \ +} + +/* + * Convenience macros to access general purpose registers using handle provided + * to SMC handler. These take the offset values defined in context.h + */ +#define SMC_GET_GP(_h, _g) \ + read_ctx_reg((get_gpregs_ctx(_h)), (_g)) +#define SMC_SET_GP(_h, _g, _v) \ + write_ctx_reg((get_gpregs_ctx(_h)), (_g), (_v)) + +/* + * Convenience macros to access EL3 context registers using handle provided to + * SMC handler. These take the offset values defined in context.h + */ +#define SMC_GET_EL3(_h, _e) \ + read_ctx_reg((get_el3state_ctx(_h)), (_e)) +#define SMC_SET_EL3(_h, _e, _v) \ + write_ctx_reg((get_el3state_ctx(_h)), (_e), (_v)) + +/* Return a UUID in the SMC return registers */ +#define SMC_UUID_RET(_h, _uuid) \ + SMC_RET4(handle, ((const uint32_t *) &(_uuid))[0], \ + ((const uint32_t *) &(_uuid))[1], \ + ((const uint32_t *) &(_uuid))[2], \ + ((const uint32_t *) &(_uuid))[3]) + +/* + * Helper macro to retrieve the SMC parameters from cpu_context_t. + */ +#define get_smc_params_from_ctx(_hdl, _x1, _x2, _x3, _x4) \ + do { \ + const gp_regs_t *regs = get_gpregs_ctx(_hdl); \ + _x1 = read_ctx_reg(regs, CTX_GPREG_X1); \ + _x2 = read_ctx_reg(regs, CTX_GPREG_X2); \ + _x3 = read_ctx_reg(regs, CTX_GPREG_X3); \ + _x4 = read_ctx_reg(regs, CTX_GPREG_X4); \ + } while (0) + +#endif /*__ASSEMBLY__*/ + +#endif /* __SMCCC_HELPERS_H__ */ diff --git a/include/lib/cpus/aarch64/cpu_macros.S b/include/lib/cpus/aarch64/cpu_macros.S index ccf530663..8f0a74f0a 100644 --- a/include/lib/cpus/aarch64/cpu_macros.S +++ b/include/lib/cpus/aarch64/cpu_macros.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -46,6 +46,8 @@ CPU_MIDR: /* cpu_ops midr */ CPU_RESET_FUNC: /* cpu_ops reset_func */ .space 8 #endif +CPU_EXTRA1_FUNC: + .space 8 #ifdef IMAGE_BL31 /* The power down core and cluster is needed only in BL31 */ CPU_PWR_DWN_OPS: /* cpu_ops power down functions */ .space (8 * CPU_MAX_PWR_DWN_OPS) @@ -113,6 +115,10 @@ CPU_OPS_SIZE = . * _resetfunc: * Reset function for the CPU. If there's no CPU reset function, * specify CPU_NO_RESET_FUNC + * _extra1: + * This is a placeholder for future per CPU operations. Currently, + * some CPUs use this entry to set a test function to determine if + * the workaround for CVE-2017-5715 needs to be applied or not. * _power_down_ops: * Comma-separated list of functions to perform power-down * operatios on the CPU. At least one, and up to @@ -122,8 +128,8 @@ CPU_OPS_SIZE = . * CPU_MAX_PWR_DWN_OPS functions, the last specified one will be * used to handle power down at subsequent levels */ - .macro declare_cpu_ops _name:req, _midr:req, _resetfunc:req, \ - _power_down_ops:vararg + .macro declare_cpu_ops_base _name:req, _midr:req, _resetfunc:req, \ + _extra1:req, _power_down_ops:vararg .section cpu_ops, "a" .align 3 .type cpu_ops_\_name, %object @@ -131,6 +137,7 @@ CPU_OPS_SIZE = . #if defined(IMAGE_AT_EL3) .quad \_resetfunc #endif + .quad \_extra1 #ifdef IMAGE_BL31 1: /* Insert list of functions */ @@ -187,6 +194,18 @@ CPU_OPS_SIZE = . #endif .endm + .macro declare_cpu_ops _name:req, _midr:req, _resetfunc:req, \ + _power_down_ops:vararg + declare_cpu_ops_base \_name, \_midr, \_resetfunc, 0, \ + \_power_down_ops + .endm + + .macro declare_cpu_ops_workaround_cve_2017_5715 _name:req, _midr:req, \ + _resetfunc:req, _extra1:req, _power_down_ops:vararg + declare_cpu_ops_base \_name, \_midr, \_resetfunc, \ + \_extra1, \_power_down_ops + .endm + #if REPORT_ERRATA /* * Print status of a CPU errata @@ -229,3 +248,18 @@ CPU_OPS_SIZE = . #endif #endif /* __CPU_MACROS_S__ */ + + /* + * This macro is used on some CPUs to detect if they are vulnerable + * to CVE-2017-5715. + */ + .macro cpu_check_csv2 _reg _label + mrs \_reg, id_aa64pfr0_el1 + ubfx \_reg, \_reg, #ID_AA64PFR0_CSV2_SHIFT, #ID_AA64PFR0_CSV2_LENGTH + /* + * If the field equals to 1 then branch targets trained in one + * context cannot affect speculative execution in a different context. + */ + cmp \_reg, #1 + beq \_label + .endm diff --git a/include/lib/cpus/workaround_cve_2017_5715.h b/include/lib/cpus/workaround_cve_2017_5715.h new file mode 100644 index 000000000..e837a673a --- /dev/null +++ b/include/lib/cpus/workaround_cve_2017_5715.h @@ -0,0 +1,12 @@ +/* + * Copyright (c) 2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef __WORKAROUND_CVE_2017_5715_H__ +#define __WORKAROUND_CVE_2017_5715_H__ + +int check_workaround_cve_2017_5715(void); + +#endif /* __WORKAROUND_CVE_2017_5715_H__ */ diff --git a/include/lib/smcc.h b/include/lib/smcc.h index 0a2d9277e..ed1da2cfb 100644 --- a/include/lib/smcc.h +++ b/include/lib/smcc.h @@ -7,103 +7,8 @@ #ifndef __SMCC_H__ #define __SMCC_H__ -#include <utils_def.h> - -/******************************************************************************* - * Bit definitions inside the function id as per the SMC calling convention - ******************************************************************************/ -#define FUNCID_TYPE_SHIFT U(31) -#define FUNCID_CC_SHIFT U(30) -#define FUNCID_OEN_SHIFT U(24) -#define FUNCID_NUM_SHIFT U(0) - -#define FUNCID_TYPE_MASK U(0x1) -#define FUNCID_CC_MASK U(0x1) -#define FUNCID_OEN_MASK U(0x3f) -#define FUNCID_NUM_MASK U(0xffff) - -#define FUNCID_TYPE_WIDTH U(1) -#define FUNCID_CC_WIDTH U(1) -#define FUNCID_OEN_WIDTH U(6) -#define FUNCID_NUM_WIDTH U(16) - -#define GET_SMC_CC(id) ((id >> FUNCID_CC_SHIFT) & \ - FUNCID_CC_MASK) -#define GET_SMC_TYPE(id) ((id >> FUNCID_TYPE_SHIFT) & \ - FUNCID_TYPE_MASK) - -#define SMC_64 U(1) -#define SMC_32 U(0) -#define SMC_OK U(0) -#define SMC_UNK -1 -#define SMC_TYPE_FAST ULL(1) #if !ERROR_DEPRECATED -#define SMC_TYPE_STD ULL(0) +#include <smccc.h> #endif -#define SMC_TYPE_YIELD U(0) -#define SMC_PREEMPTED -2 -/******************************************************************************* - * Owning entity number definitions inside the function id as per the SMC - * calling convention - ******************************************************************************/ -#define OEN_ARM_START U(0) -#define OEN_ARM_END U(0) -#define OEN_CPU_START U(1) -#define OEN_CPU_END U(1) -#define OEN_SIP_START U(2) -#define OEN_SIP_END U(2) -#define OEN_OEM_START U(3) -#define OEN_OEM_END U(3) -#define OEN_STD_START U(4) /* Standard Service Calls */ -#define OEN_STD_END U(4) -#define OEN_TAP_START U(48) /* Trusted Applications */ -#define OEN_TAP_END U(49) -#define OEN_TOS_START U(50) /* Trusted OS */ -#define OEN_TOS_END U(63) -#define OEN_LIMIT U(64) - -#ifndef __ASSEMBLY__ - -#include <cassert.h> -#include <stdint.h> - -#define SMCCC_MAJOR_VERSION U(1) -#define SMCCC_MINOR_VERSION U(1) - -#define MAKE_SMCCC_VERSION(_major, _minor) (((_major) << 16) | (_minor)) - -/* Various flags passed to SMC handlers */ -#define SMC_FROM_SECURE (U(0) << 0) -#define SMC_FROM_NON_SECURE (U(1) << 0) - -#define is_caller_non_secure(_f) (!!(_f & SMC_FROM_NON_SECURE)) -#define is_caller_secure(_f) (!(is_caller_non_secure(_f))) - -/* The macro below is used to identify a Standard Service SMC call */ -#define is_std_svc_call(_fid) ((((_fid) >> FUNCID_OEN_SHIFT) & \ - FUNCID_OEN_MASK) == OEN_STD_START) - -/* The macro below is used to identify a Arm Architectural Service SMC call */ -#define is_arm_arch_svc_call(_fid) ((((_fid) >> FUNCID_OEN_SHIFT) & \ - FUNCID_OEN_MASK) == OEN_ARM_START) - -/* The macro below is used to identify a valid Fast SMC call */ -#define is_valid_fast_smc(_fid) ((!(((_fid) >> 16) & U(0xff))) && \ - (GET_SMC_TYPE(_fid) == SMC_TYPE_FAST)) - -/* - * Macro to define UUID for services. Apart from defining and initializing a - * uuid_t structure, this macro verifies that the first word of the defined UUID - * does not equal SMC_UNK. This is to ensure that the caller won't mistake the - * returned UUID in x0 for an invalid SMC error return - */ -#define DEFINE_SVC_UUID(_name, _tl, _tm, _th, _cl, _ch, \ - _n0, _n1, _n2, _n3, _n4, _n5) \ - CASSERT((uint32_t)(_tl) != (uint32_t) SMC_UNK, invalid_svc_uuid);\ - static const uuid_t _name = { \ - _tl, _tm, _th, _cl, _ch, \ - { _n0, _n1, _n2, _n3, _n4, _n5 } \ - } -#endif /*__ASSEMBLY__*/ #endif /* __SMCC_H__ */ diff --git a/include/lib/smccc.h b/include/lib/smccc.h new file mode 100644 index 000000000..d68342032 --- /dev/null +++ b/include/lib/smccc.h @@ -0,0 +1,109 @@ +/* + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#ifndef __SMCCC_H__ +#define __SMCCC_H__ + +#include <utils_def.h> + +/******************************************************************************* + * Bit definitions inside the function id as per the SMC calling convention + ******************************************************************************/ +#define FUNCID_TYPE_SHIFT U(31) +#define FUNCID_CC_SHIFT U(30) +#define FUNCID_OEN_SHIFT U(24) +#define FUNCID_NUM_SHIFT U(0) + +#define FUNCID_TYPE_MASK U(0x1) +#define FUNCID_CC_MASK U(0x1) +#define FUNCID_OEN_MASK U(0x3f) +#define FUNCID_NUM_MASK U(0xffff) + +#define FUNCID_TYPE_WIDTH U(1) +#define FUNCID_CC_WIDTH U(1) +#define FUNCID_OEN_WIDTH U(6) +#define FUNCID_NUM_WIDTH U(16) + +#define GET_SMC_CC(id) ((id >> FUNCID_CC_SHIFT) & \ + FUNCID_CC_MASK) +#define GET_SMC_TYPE(id) ((id >> FUNCID_TYPE_SHIFT) & \ + FUNCID_TYPE_MASK) + +#define SMC_64 U(1) +#define SMC_32 U(0) +#define SMC_OK U(0) +#define SMC_UNK -1 +#define SMC_TYPE_FAST ULL(1) +#if !ERROR_DEPRECATED +#define SMC_TYPE_STD ULL(0) +#endif +#define SMC_TYPE_YIELD U(0) +#define SMC_PREEMPTED -2 +/******************************************************************************* + * Owning entity number definitions inside the function id as per the SMC + * calling convention + ******************************************************************************/ +#define OEN_ARM_START U(0) +#define OEN_ARM_END U(0) +#define OEN_CPU_START U(1) +#define OEN_CPU_END U(1) +#define OEN_SIP_START U(2) +#define OEN_SIP_END U(2) +#define OEN_OEM_START U(3) +#define OEN_OEM_END U(3) +#define OEN_STD_START U(4) /* Standard Service Calls */ +#define OEN_STD_END U(4) +#define OEN_TAP_START U(48) /* Trusted Applications */ +#define OEN_TAP_END U(49) +#define OEN_TOS_START U(50) /* Trusted OS */ +#define OEN_TOS_END U(63) +#define OEN_LIMIT U(64) + +#ifndef __ASSEMBLY__ + +#include <cassert.h> +#include <stdint.h> + +#define SMCCC_MAJOR_VERSION U(1) +#define SMCCC_MINOR_VERSION U(1) + +#define MAKE_SMCCC_VERSION(_major, _minor) (((_major) << 16) | (_minor)) + +/* Various flags passed to SMC handlers */ +#define SMC_FROM_SECURE (U(0) << 0) +#define SMC_FROM_NON_SECURE (U(1) << 0) + +#define is_caller_non_secure(_f) (!!(_f & SMC_FROM_NON_SECURE)) +#define is_caller_secure(_f) (!(is_caller_non_secure(_f))) + +/* The macro below is used to identify a Standard Service SMC call */ +#define is_std_svc_call(_fid) ((((_fid) >> FUNCID_OEN_SHIFT) & \ + FUNCID_OEN_MASK) == OEN_STD_START) + +/* The macro below is used to identify a Arm Architectural Service SMC call */ +#define is_arm_arch_svc_call(_fid) ((((_fid) >> FUNCID_OEN_SHIFT) & \ + FUNCID_OEN_MASK) == OEN_ARM_START) + +/* The macro below is used to identify a valid Fast SMC call */ +#define is_valid_fast_smc(_fid) ((!(((_fid) >> 16) & U(0xff))) && \ + (GET_SMC_TYPE(_fid) == SMC_TYPE_FAST)) + +/* + * Macro to define UUID for services. Apart from defining and initializing a + * uuid_t structure, this macro verifies that the first word of the defined UUID + * does not equal SMC_UNK. This is to ensure that the caller won't mistake the + * returned UUID in x0 for an invalid SMC error return + */ +#define DEFINE_SVC_UUID(_name, _tl, _tm, _th, _cl, _ch, \ + _n0, _n1, _n2, _n3, _n4, _n5) \ + CASSERT((uint32_t)(_tl) != (uint32_t) SMC_UNK, invalid_svc_uuid);\ + static const uuid_t _name = { \ + _tl, _tm, _th, _cl, _ch, \ + { _n0, _n1, _n2, _n3, _n4, _n5 } \ + } + +#endif /*__ASSEMBLY__*/ +#endif /* __SMCCC_H__ */ diff --git a/include/plat/arm/common/plat_arm.h b/include/plat/arm/common/plat_arm.h index 0a80814cd..b0db8f08f 100644 --- a/include/plat/arm/common/plat_arm.h +++ b/include/plat/arm/common/plat_arm.h @@ -237,6 +237,10 @@ int arm_execution_state_switch(unsigned int smc_fid, uint32_t cookie_lo, void *handle); +/* Optional functions for SP_MIN */ +void plat_arm_sp_min_early_platform_setup(u_register_t arg0, u_register_t arg1, + u_register_t arg2, u_register_t arg3); + /* global variables */ extern plat_psci_ops_t plat_arm_psci_pm_ops; extern const mmap_region_t plat_arm_mmap[]; diff --git a/lib/cpus/aarch64/cortex_a57.S b/lib/cpus/aarch64/cortex_a57.S index c82ebfc95..4d072e11c 100644 --- a/lib/cpus/aarch64/cortex_a57.S +++ b/lib/cpus/aarch64/cortex_a57.S @@ -555,8 +555,8 @@ func cortex_a57_cpu_reg_dump ret endfunc cortex_a57_cpu_reg_dump - -declare_cpu_ops cortex_a57, CORTEX_A57_MIDR, \ +declare_cpu_ops_workaround_cve_2017_5715 cortex_a57, CORTEX_A57_MIDR, \ cortex_a57_reset_func, \ + check_errata_cve_2017_5715, \ cortex_a57_core_pwr_dwn, \ cortex_a57_cluster_pwr_dwn diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S index 9633aa8f5..29fa77b90 100644 --- a/lib/cpus/aarch64/cortex_a72.S +++ b/lib/cpus/aarch64/cortex_a72.S @@ -98,12 +98,16 @@ func check_errata_859971 endfunc check_errata_859971 func check_errata_cve_2017_5715 + cpu_check_csv2 x0, 1f #if WORKAROUND_CVE_2017_5715 mov x0, #ERRATA_APPLIES #else mov x0, #ERRATA_MISSING #endif ret +1: + mov x0, #ERRATA_NOT_APPLIES + ret endfunc check_errata_cve_2017_5715 /* ------------------------------------------------- @@ -121,8 +125,10 @@ func cortex_a72_reset_func #endif #if IMAGE_BL31 && WORKAROUND_CVE_2017_5715 + cpu_check_csv2 x0, 1f adr x0, workaround_mmu_runtime_exceptions msr vbar_el3, x0 +1: #endif /* --------------------------------------------- @@ -286,8 +292,8 @@ func cortex_a72_cpu_reg_dump ret endfunc cortex_a72_cpu_reg_dump - -declare_cpu_ops cortex_a72, CORTEX_A72_MIDR, \ +declare_cpu_ops_workaround_cve_2017_5715 cortex_a72, CORTEX_A72_MIDR, \ cortex_a72_reset_func, \ + check_errata_cve_2017_5715, \ cortex_a72_core_pwr_dwn, \ cortex_a72_cluster_pwr_dwn diff --git a/lib/cpus/aarch64/cortex_a73.S b/lib/cpus/aarch64/cortex_a73.S index 11680a09d..0a961ea33 100644 --- a/lib/cpus/aarch64/cortex_a73.S +++ b/lib/cpus/aarch64/cortex_a73.S @@ -37,8 +37,10 @@ endfunc cortex_a73_disable_smp func cortex_a73_reset_func #if IMAGE_BL31 && WORKAROUND_CVE_2017_5715 + cpu_check_csv2 x0, 1f adr x0, workaround_bpiall_vbar0_runtime_exceptions msr vbar_el3, x0 +1: #endif /* --------------------------------------------- @@ -115,12 +117,16 @@ func cortex_a73_cluster_pwr_dwn endfunc cortex_a73_cluster_pwr_dwn func check_errata_cve_2017_5715 + cpu_check_csv2 x0, 1f #if WORKAROUND_CVE_2017_5715 mov x0, #ERRATA_APPLIES #else mov x0, #ERRATA_MISSING #endif ret +1: + mov x0, #ERRATA_NOT_APPLIES + ret endfunc check_errata_cve_2017_5715 #if REPORT_ERRATA @@ -164,7 +170,8 @@ func cortex_a73_cpu_reg_dump ret endfunc cortex_a73_cpu_reg_dump -declare_cpu_ops cortex_a73, CORTEX_A73_MIDR, \ +declare_cpu_ops_workaround_cve_2017_5715 cortex_a73, CORTEX_A73_MIDR, \ cortex_a73_reset_func, \ + check_errata_cve_2017_5715, \ cortex_a73_core_pwr_dwn, \ cortex_a73_cluster_pwr_dwn diff --git a/lib/cpus/aarch64/cortex_a75.S b/lib/cpus/aarch64/cortex_a75.S index 12ea304d0..288f5afed 100644 --- a/lib/cpus/aarch64/cortex_a75.S +++ b/lib/cpus/aarch64/cortex_a75.S @@ -12,15 +12,7 @@ func cortex_a75_reset_func #if IMAGE_BL31 && WORKAROUND_CVE_2017_5715 - mrs x0, id_aa64pfr0_el1 - ubfx x0, x0, #ID_AA64PFR0_CSV2_SHIFT, #ID_AA64PFR0_CSV2_LENGTH - /* - * If the field equals to 1 then branch targets trained in one - * context cannot affect speculative execution in a different context. - */ - cmp x0, #1 - beq 1f - + cpu_check_csv2 x0, 1f adr x0, workaround_bpiall_vbar0_runtime_exceptions msr vbar_el3, x0 1: @@ -53,15 +45,7 @@ func cortex_a75_reset_func endfunc cortex_a75_reset_func func check_errata_cve_2017_5715 - mrs x0, id_aa64pfr0_el1 - ubfx x0, x0, #ID_AA64PFR0_CSV2_SHIFT, #ID_AA64PFR0_CSV2_LENGTH - /* - * If the field equals to 1 then branch targets trained in one - * context cannot affect speculative execution in a different context. - */ - cmp x0, #1 - beq 1f - + cpu_check_csv2 x0, 1f #if WORKAROUND_CVE_2017_5715 mov x0, #ERRATA_APPLIES #else @@ -129,6 +113,7 @@ func cortex_a75_cpu_reg_dump ret endfunc cortex_a75_cpu_reg_dump -declare_cpu_ops cortex_a75, CORTEX_A75_MIDR, \ +declare_cpu_ops_workaround_cve_2017_5715 cortex_a75, CORTEX_A75_MIDR, \ cortex_a75_reset_func, \ + check_errata_cve_2017_5715, \ cortex_a75_core_pwr_dwn diff --git a/lib/cpus/aarch64/cpu_helpers.S b/lib/cpus/aarch64/cpu_helpers.S index ae1c3c252..5a9226d83 100644 --- a/lib/cpus/aarch64/cpu_helpers.S +++ b/lib/cpus/aarch64/cpu_helpers.S @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -7,9 +7,7 @@ #include <arch.h> #include <asm_macros.S> #include <assert_macros.S> -#if defined(IMAGE_BL31) || (defined(IMAGE_BL2) && BL2_AT_EL3) #include <cpu_data.h> -#endif #include <cpu_macros.S> #include <debug.h> #include <errata_report.h> @@ -281,3 +279,36 @@ func print_errata_status br x1 endfunc print_errata_status #endif + +/* + * int check_workaround_cve_2017_5715(void); + * + * This function returns: + * - ERRATA_APPLIES when firmware mitigation is required. + * - ERRATA_NOT_APPLIES when firmware mitigation is _not_ required. + * - ERRATA_MISSING when firmware mitigation would be required but + * is not compiled in. + * + * NOTE: Must be called only after cpu_ops have been initialized + * in per-CPU data. + */ + .globl check_workaround_cve_2017_5715 +func check_workaround_cve_2017_5715 + mrs x0, tpidr_el3 +#if ENABLE_ASSERTIONS + cmp x0, #0 + ASM_ASSERT(ne) +#endif + ldr x0, [x0, #CPU_DATA_CPU_OPS_PTR] + ldr x0, [x0, #CPU_EXTRA1_FUNC] + /* + * If the reserved function pointer is NULL, this CPU + * is unaffected by CVE-2017-5715 so bail out. + */ + cmp x0, #0 + beq 1f + br x0 +1: + mov x0, #ERRATA_NOT_APPLIES + ret +endfunc check_workaround_cve_2017_5715 diff --git a/lib/el3_runtime/aarch32/context_mgmt.c b/lib/el3_runtime/aarch32/context_mgmt.c index 76e440e3d..c784c225a 100644 --- a/lib/el3_runtime/aarch32/context_mgmt.c +++ b/lib/el3_runtime/aarch32/context_mgmt.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -13,7 +13,7 @@ #include <context_mgmt.h> #include <platform.h> #include <platform_def.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <string.h> #include <utils.h> diff --git a/lib/el3_runtime/aarch64/context_mgmt.c b/lib/el3_runtime/aarch64/context_mgmt.c index c6c2249a4..2608d1fcc 100644 --- a/lib/el3_runtime/aarch64/context_mgmt.c +++ b/lib/el3_runtime/aarch64/context_mgmt.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -15,7 +15,7 @@ #include <platform.h> #include <platform_def.h> #include <pubsub_events.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <spe.h> #include <string.h> #include <sve.h> diff --git a/lib/pmf/pmf_smc.c b/lib/pmf/pmf_smc.c index 248c1fac6..5cf193e21 100644 --- a/lib/pmf/pmf_smc.c +++ b/lib/pmf/pmf_smc.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -7,7 +7,7 @@ #include <debug.h> #include <platform.h> #include <pmf.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> /* * This function is responsible for handling all PMF SMC calls. diff --git a/lib/psci/psci_main.c b/lib/psci/psci_main.c index 88cf5cbe4..d25d1775c 100644 --- a/lib/psci/psci_main.c +++ b/lib/psci/psci_main.c @@ -12,7 +12,7 @@ #include <platform.h> #include <pmf.h> #include <runtime_instr.h> -#include <smcc.h> +#include <smccc.h> #include <string.h> #include "psci_private.h" diff --git a/license.rst b/license.rst index c51e595ac..a4464d9ad 100644 --- a/license.rst +++ b/license.rst @@ -1,4 +1,4 @@ -Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved. +Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: @@ -10,7 +10,7 @@ are permitted provided that the following conditions are met: list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. -- Neither the name of ARM nor the names of its contributors may be used to +- Neither the name of Arm nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. diff --git a/maintainers.rst b/maintainers.rst index 72a11a5a1..77b851e95 100644 --- a/maintainers.rst +++ b/maintainers.rst @@ -1,7 +1,7 @@ -ARM Trusted Firmware Maintainers -================================ +Trusted Firmware-A maintainers +============================== -ARM Trusted Firmware is an ARM maintained project. All contributions are +Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are ultimately merged by the maintainers listed below. Technical ownership of some parts of the codebase is delegated to the sub-maintainers listed below. An acknowledgement from these sub-maintainers may be required before the @@ -123,8 +123,8 @@ Files: - docs/plat/xilinx-zynqmp.rst - plat/xilinx/\* -ARMv7 architecture sub-maintainer ---------------------------------- +Armv7-A architecture sub-maintainer +----------------------------------- Etienne Carriere (etienne.carriere@linaro.org, `etienne-lms`_) diff --git a/make_helpers/defaults.mk b/make_helpers/defaults.mk index a80a4915a..751f8343c 100644 --- a/make_helpers/defaults.mk +++ b/make_helpers/defaults.mk @@ -1,5 +1,5 @@ # -# Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. +# Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. # # SPDX-License-Identifier: BSD-3-Clause # @@ -98,9 +98,9 @@ KEY_ALG := rsa # Flag to enable new version of image loading LOAD_IMAGE_V2 := 0 -# Use the new console API that allows registering more than one console instance -# at once. Use = instead of := to dynamically default to ERROR_DEPRECATED. -MULTI_CONSOLE_API = $(ERROR_DEPRECATED) +# Enable use of the console API allowing multiple consoles to be registered +# at the same time. +MULTI_CONSOLE_API := 0 # NS timer register save and restore NS_TIMER_SWITCH := 0 diff --git a/make_helpers/plat_helpers.mk b/make_helpers/plat_helpers.mk index a2f383a51..a7ae9a279 100644 --- a/make_helpers/plat_helpers.mk +++ b/make_helpers/plat_helpers.mk @@ -15,14 +15,14 @@ ifndef PLAT_HELPERS_MK $(error "Error: Unknown platform. Please use PLAT=<platform name> to specify the platform") endif - # PLATFORM_ROOT can be overridden for when building tools directly - PLATFORM_ROOT ?= plat/ + # TF_PLATFORM_ROOT can be overridden for when building tools directly + TF_PLATFORM_ROOT ?= plat/ PLAT_MAKEFILE := platform.mk # Generate the platforms list by recursively searching for all directories # under /plat containing a PLAT_MAKEFILE. Append each platform with a `|` # char and strip out the final '|'. - ALL_PLATFORM_MK_FILES := $(call rwildcard,${PLATFORM_ROOT},${PLAT_MAKEFILE}) + ALL_PLATFORM_MK_FILES := $(call rwildcard,${TF_PLATFORM_ROOT},${PLAT_MAKEFILE}) ALL_PLATFORM_DIRS := $(patsubst %/,%,$(dir ${ALL_PLATFORM_MK_FILES})) ALL_PLATFORMS := $(sort $(notdir ${ALL_PLATFORM_DIRS})) diff --git a/plat/arm/board/common/board_css_common.c b/plat/arm/board/common/board_css_common.c index 032ebdf7e..c1c3e66a6 100644 --- a/plat/arm/board/common/board_css_common.c +++ b/plat/arm/board/common/board_css_common.c @@ -14,7 +14,7 @@ #ifdef IMAGE_BL1 const mmap_region_t plat_arm_mmap[] = { ARM_MAP_SHARED_RAM, - V2M_MAP_FLASH0_RO, + V2M_MAP_FLASH0_RW, V2M_MAP_IOFPGA, CSS_MAP_DEVICE, SOC_CSS_MAP_DEVICE, @@ -28,7 +28,7 @@ const mmap_region_t plat_arm_mmap[] = { #ifdef IMAGE_BL2 const mmap_region_t plat_arm_mmap[] = { ARM_MAP_SHARED_RAM, - V2M_MAP_FLASH0_RO, + V2M_MAP_FLASH0_RW, #ifdef PLAT_ARM_MEM_PROT_ADDR ARM_V2M_MAP_MEM_PROTECT, #endif diff --git a/plat/arm/board/fvp/fvp_bl1_setup.c b/plat/arm/board/fvp/fvp_bl1_setup.c index d50c20a1d..4b2a340b0 100644 --- a/plat/arm/board/fvp/fvp_bl1_setup.c +++ b/plat/arm/board/fvp/fvp_bl1_setup.c @@ -30,16 +30,3 @@ void bl1_early_platform_setup(void) */ fvp_interconnect_enable(); } - -/******************************************************************************* - * The following function checks if Firmware update is needed, - * by checking if TOC in FIP image is valid or not. - ******************************************************************************/ -unsigned int bl1_plat_get_next_image_id(void) -{ - if (!arm_io_is_toc_valid()) - return NS_BL1U_IMAGE_ID; - - return BL2_IMAGE_ID; -} - diff --git a/plat/arm/board/fvp/fvp_common.c b/plat/arm/board/fvp/fvp_common.c index 2df11d653..af258b060 100644 --- a/plat/arm/board/fvp/fvp_common.c +++ b/plat/arm/board/fvp/fvp_common.c @@ -145,6 +145,7 @@ const mmap_region_t plat_arm_secure_partition_mmap[] = { const mmap_region_t plat_arm_mmap[] = { #ifdef AARCH32 ARM_MAP_SHARED_RAM, + ARM_V2M_MAP_MEM_PROTECT, #endif V2M_MAP_IOFPGA, MAP_DEVICE0, diff --git a/plat/arm/board/fvp/include/platform_def.h b/plat/arm/board/fvp/include/platform_def.h index 4ac08504c..2d0149034 100644 --- a/plat/arm/board/fvp/include/platform_def.h +++ b/plat/arm/board/fvp/include/platform_def.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -43,7 +43,7 @@ /* No SCP in FVP */ #define PLAT_ARM_SCP_TZC_DRAM1_SIZE ULL(0x0) -#define PLAT_ARM_DRAM2_SIZE ULL(0x780000000) +#define PLAT_ARM_DRAM2_SIZE ULL(0x80000000) /* * Load address of BL33 for this platform port diff --git a/plat/arm/board/fvp/platform.mk b/plat/arm/board/fvp/platform.mk index 3dca4c2ac..bb7753822 100644 --- a/plat/arm/board/fvp/platform.mk +++ b/plat/arm/board/fvp/platform.mk @@ -124,7 +124,6 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ lib/semihosting/${ARCH}/semihosting_call.S \ plat/arm/board/fvp/${ARCH}/fvp_helpers.S \ plat/arm/board/fvp/fvp_bl1_setup.c \ - plat/arm/board/fvp/fvp_err.c \ plat/arm/board/fvp/fvp_io_storage.c \ plat/arm/board/fvp/fvp_trusted_boot.c \ ${FVP_CPU_LIBS} \ @@ -135,7 +134,6 @@ BL2_SOURCES += drivers/io/io_semihosting.c \ lib/semihosting/semihosting.c \ lib/semihosting/${ARCH}/semihosting_call.S \ plat/arm/board/fvp/fvp_bl2_setup.c \ - plat/arm/board/fvp/fvp_err.c \ plat/arm/board/fvp/fvp_io_storage.c \ plat/arm/board/fvp/fvp_trusted_boot.c \ ${FVP_SECURITY_SOURCES} diff --git a/plat/arm/board/fvp/sp_min/fvp_sp_min_setup.c b/plat/arm/board/fvp/sp_min/fvp_sp_min_setup.c index 6cced4ddb..7c89c27e3 100644 --- a/plat/arm/board/fvp/sp_min/fvp_sp_min_setup.c +++ b/plat/arm/board/fvp/sp_min/fvp_sp_min_setup.c @@ -7,7 +7,7 @@ #include <plat_arm.h> #include "../fvp_private.h" -void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, +void plat_arm_sp_min_early_platform_setup(u_register_t arg0, u_register_t arg1, u_register_t arg2, u_register_t arg3) { arm_sp_min_early_platform_setup((void *)arg0, arg1, arg2, (void *)arg3); diff --git a/plat/arm/board/juno/juno_bl1_setup.c b/plat/arm/board/juno/juno_bl1_setup.c index 7c026bcb7..836a67255 100644 --- a/plat/arm/board/juno/juno_bl1_setup.c +++ b/plat/arm/board/juno/juno_bl1_setup.c @@ -12,31 +12,8 @@ #include <tbbr_img_def.h> #include <v2m_def.h> -#define RESET_REASON_WDOG_RESET (0x2) - void juno_reset_to_aarch32_state(void); - -/******************************************************************************* - * The following function checks if Firmware update is needed, - * by checking if TOC in FIP image is valid or watchdog reset happened. - ******************************************************************************/ -unsigned int bl1_plat_get_next_image_id(void) -{ - unsigned int *reset_flags_ptr = (unsigned int *)SSC_GPRETN; - unsigned int *nv_flags_ptr = (unsigned int *) - (V2M_SYSREGS_BASE + V2M_SYS_NVFLAGS); - /* - * Check if TOC is invalid or watchdog reset happened. - */ - if ((arm_io_is_toc_valid() != 1) || - ((*reset_flags_ptr & RESET_REASON_WDOG_RESET) && - ((*nv_flags_ptr == -EAUTH) || (*nv_flags_ptr == -ENOENT)))) - return NS_BL1U_IMAGE_ID; - - return BL2_IMAGE_ID; -} - /******************************************************************************* * On JUNO update the arg2 with address of SCP_BL2U image info. ******************************************************************************/ diff --git a/plat/arm/board/juno/juno_err.c b/plat/arm/board/juno/juno_err.c deleted file mode 100644 index 0fe701675..000000000 --- a/plat/arm/board/juno/juno_err.c +++ /dev/null @@ -1,27 +0,0 @@ -/* - * Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved. - * - * SPDX-License-Identifier: BSD-3-Clause - */ - -#include <arch_helpers.h> -#include <errno.h> -#include <platform.h> -#include <v2m_def.h> - -#define V2M_SYS_NVFLAGS_ADDR (V2M_SYSREGS_BASE + V2M_SYS_NVFLAGS) - -/* - * Juno error handler - */ -void plat_error_handler(int err) -{ - uint32_t *flags_ptr = (uint32_t *)V2M_SYS_NVFLAGS_ADDR; - - /* Propagate the err code in the NV-flags register */ - *flags_ptr = err; - - /* Loop until the watchdog resets the system */ - for (;;) - wfi(); -} diff --git a/plat/arm/board/juno/platform.mk b/plat/arm/board/juno/platform.mk index 70d690922..656fc14c7 100644 --- a/plat/arm/board/juno/platform.mk +++ b/plat/arm/board/juno/platform.mk @@ -49,12 +49,10 @@ BL1_SOURCES += lib/cpus/aarch64/cortex_a53.S \ lib/cpus/aarch64/cortex_a57.S \ lib/cpus/aarch64/cortex_a72.S \ plat/arm/board/juno/juno_bl1_setup.c \ - plat/arm/board/juno/juno_err.c \ ${JUNO_INTERCONNECT_SOURCES} \ ${JUNO_SECURITY_SOURCES} -BL2_SOURCES += plat/arm/board/juno/juno_err.c \ - plat/arm/board/juno/juno_bl2_setup.c \ +BL2_SOURCES += plat/arm/board/juno/juno_bl2_setup.c \ ${JUNO_SECURITY_SOURCES} BL2U_SOURCES += ${JUNO_SECURITY_SOURCES} diff --git a/plat/arm/common/arm_bl1_setup.c b/plat/arm/common/arm_bl1_setup.c index 3a30eca67..379e87df2 100644 --- a/plat/arm/common/arm_bl1_setup.c +++ b/plat/arm/common/arm_bl1_setup.c @@ -145,3 +145,15 @@ void bl1_plat_prepare_exit(entry_point_info_t *ep_info) sev(); #endif } + +/******************************************************************************* + * The following function checks if Firmware update is needed, + * by checking if TOC in FIP image is valid or not. + ******************************************************************************/ +unsigned int bl1_plat_get_next_image_id(void) +{ + if (!arm_io_is_toc_valid()) + return NS_BL1U_IMAGE_ID; + + return BL2_IMAGE_ID; +} diff --git a/plat/arm/common/arm_bl2u_setup.c b/plat/arm/common/arm_bl2u_setup.c index cc291fc90..3b8e4aa46 100644 --- a/plat/arm/common/arm_bl2u_setup.c +++ b/plat/arm/common/arm_bl2u_setup.c @@ -8,6 +8,7 @@ #include <arm_def.h> #include <bl_common.h> #include <console.h> +#include <generic_delay_timer.h> #include <plat_arm.h> #include <platform_def.h> #include <platform.h> @@ -37,6 +38,7 @@ void arm_bl2u_early_platform_setup(meminfo_t *mem_layout, void *plat_info) /* Initialize the console to provide early debug support */ console_init(PLAT_ARM_BOOT_UART_BASE, PLAT_ARM_BOOT_UART_CLK_IN_HZ, ARM_CONSOLE_BAUDRATE); + generic_delay_timer_init(); } /******************************************************************************* diff --git a/plat/arm/common/arm_common.mk b/plat/arm/common/arm_common.mk index b3462ab8a..015e454a1 100644 --- a/plat/arm/common/arm_common.mk +++ b/plat/arm/common/arm_common.mk @@ -137,6 +137,7 @@ BL1_SOURCES += drivers/arm/sp805/sp805.c \ drivers/io/io_storage.c \ plat/arm/common/arm_bl1_setup.c \ plat/arm/common/arm_dyn_cfg.c \ + plat/arm/common/arm_err.c \ plat/arm/common/arm_io_storage.c ifdef EL3_PAYLOAD_BASE # Need the arm_program_trusted_mailbox() function to release secondary CPUs from @@ -150,6 +151,7 @@ BL2_SOURCES += drivers/delay_timer/delay_timer.c \ drivers/io/io_memmap.c \ drivers/io/io_storage.c \ plat/arm/common/arm_bl2_setup.c \ + plat/arm/common/arm_err.c \ plat/arm/common/arm_io_storage.c # Add `libfdt` and Arm common helpers required for Dynamic Config diff --git a/plat/arm/board/fvp/fvp_err.c b/plat/arm/common/arm_err.c index d9ad5175b..59c586181 100644 --- a/plat/arm/board/fvp/fvp_err.c +++ b/plat/arm/common/arm_err.c @@ -6,6 +6,7 @@ #include <arch_helpers.h> #include <board_arm_def.h> +#include <console.h> #include <debug.h> #include <errno.h> #include <norflash.h> @@ -13,7 +14,7 @@ #include <stdint.h> /* - * FVP error handler + * ARM common implementation for error handler */ void plat_error_handler(int err) { @@ -26,7 +27,7 @@ void plat_error_handler(int err) INFO("Erasing FIP ToC from flash...\n"); nor_unlock(PLAT_ARM_FIP_BASE); ret = nor_word_program(PLAT_ARM_FIP_BASE, 0); - if (ret) { + if (ret != 0) { ERROR("Cannot erase ToC\n"); } else { INFO("Done\n"); @@ -37,6 +38,8 @@ void plat_error_handler(int err) break; } + (void)console_flush(); + /* Loop until the watchdog resets the system */ for (;;) wfi(); diff --git a/plat/arm/common/execution_state_switch.c b/plat/arm/common/execution_state_switch.c index 8499db074..22d552ad9 100644 --- a/plat/arm/common/execution_state_switch.c +++ b/plat/arm/common/execution_state_switch.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -10,7 +10,7 @@ #include <context_mgmt.h> #include <plat_arm.h> #include <psci.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <string.h> #include <utils.h> diff --git a/plat/arm/common/sp_min/arm_sp_min_setup.c b/plat/arm/common/sp_min/arm_sp_min_setup.c index 1776d46a7..7b5477ec3 100644 --- a/plat/arm/common/sp_min/arm_sp_min_setup.c +++ b/plat/arm/common/sp_min/arm_sp_min_setup.c @@ -18,9 +18,9 @@ static entry_point_info_t bl33_image_ep_info; /* Weak definitions may be overridden in specific ARM standard platform */ -#pragma weak sp_min_early_platform_setup2 #pragma weak sp_min_platform_setup #pragma weak sp_min_plat_arch_setup +#pragma weak plat_arm_sp_min_early_platform_setup /******************************************************************************* @@ -46,7 +46,7 @@ entry_point_info_t *sp_min_plat_get_bl33_ep_info(void) } /******************************************************************************* - * Perform early platform setup. + * Utility function to perform early platform setup. ******************************************************************************/ void arm_sp_min_early_platform_setup(void *from_bl2, uintptr_t tos_fw_config, uintptr_t hw_config, void *plat_params_from_bl2) @@ -105,7 +105,10 @@ void arm_sp_min_early_platform_setup(void *from_bl2, uintptr_t tos_fw_config, } -void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, +/******************************************************************************* + * Default implementation for sp_min_platform_setup2() for ARM platforms + ******************************************************************************/ +void plat_arm_sp_min_early_platform_setup(u_register_t arg0, u_register_t arg1, u_register_t arg2, u_register_t arg3) { arm_sp_min_early_platform_setup((void *)arg0, arg1, arg2, (void *)arg3); @@ -127,6 +130,12 @@ void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, plat_arm_interconnect_enter_coherency(); } +void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, + u_register_t arg2, u_register_t arg3) +{ + plat_arm_sp_min_early_platform_setup(arg0, arg1, arg2, arg3); +} + /******************************************************************************* * Perform any SP_MIN platform runtime setup prior to SP_MIN exit. * Common to ARM standard platforms. diff --git a/plat/common/aarch32/plat_common.c b/plat/common/aarch32/plat_common.c index c02386983..4f2714902 100644 --- a/plat/common/aarch32/plat_common.c +++ b/plat/common/aarch32/plat_common.c @@ -4,9 +4,7 @@ * SPDX-License-Identifier: BSD-3-Clause */ -#include <console.h> #include <platform.h> -#include <platform_sp_min.h> #include <xlat_mmu_helpers.h> /* @@ -15,29 +13,9 @@ * platforms but may also be overridden by a platform if required. */ #pragma weak bl32_plat_enable_mmu -#pragma weak sp_min_plat_runtime_setup + void bl32_plat_enable_mmu(uint32_t flags) { enable_mmu_secure(flags); } - -void sp_min_plat_runtime_setup(void) -{ - /* - * Finish the use of console driver in SP_MIN so that any runtime logs - * from SP_MIN will be suppressed. - */ - console_uninit(); -} - -#if !ERROR_DEPRECATED - -#pragma weak sp_min_early_platform_setup2 - -void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, - u_register_t arg2, u_register_t arg3) -{ - sp_min_early_platform_setup((void *) arg0, (void *)arg1); -} -#endif diff --git a/plat/common/aarch32/plat_sp_min_common.c b/plat/common/aarch32/plat_sp_min_common.c new file mode 100644 index 000000000..67ae817e6 --- /dev/null +++ b/plat/common/aarch32/plat_sp_min_common.c @@ -0,0 +1,36 @@ +/* + * Copyright (c) 2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#include <console.h> +#include <platform.h> +#include <platform_sp_min.h> + +/* + * The following platform setup functions are weakly defined. They + * provide typical implementations that may be re-used by multiple + * platforms but may also be overridden by a platform if required. + */ +#pragma weak sp_min_plat_runtime_setup + +void sp_min_plat_runtime_setup(void) +{ + /* + * Finish the use of console driver in SP_MIN so that any runtime logs + * from SP_MIN will be suppressed. + */ + console_uninit(); +} + +#if !ERROR_DEPRECATED + +#pragma weak sp_min_early_platform_setup2 + +void sp_min_early_platform_setup2(u_register_t arg0, u_register_t arg1, + u_register_t arg2, u_register_t arg3) +{ + sp_min_early_platform_setup((void *)arg0, (void *)arg1); +} +#endif diff --git a/plat/common/aarch64/plat_common.c b/plat/common/aarch64/plat_common.c index 080d35698..ddd29f29b 100644 --- a/plat/common/aarch64/plat_common.c +++ b/plat/common/aarch64/plat_common.c @@ -65,7 +65,15 @@ unsigned int platform_core_pos_helper(unsigned long mpidr) #if !ERROR_DEPRECATED unsigned int plat_get_syscnt_freq2(void) { + WARN("plat_get_syscnt_freq() is deprecated\n"); + WARN("Please define plat_get_syscnt_freq2()\n"); + /* + * Suppress deprecated declaration warning in compatibility function + */ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wdeprecated-declarations" unsigned long long freq = plat_get_syscnt_freq(); +#pragma GCC diagnostic pop assert(freq >> 32 == 0); diff --git a/plat/hisilicon/hikey/aarch64/hikey_common.c b/plat/hisilicon/hikey/aarch64/hikey_common.c index d5b63cc6e..f95af5870 100644 --- a/plat/hisilicon/hikey/aarch64/hikey_common.c +++ b/plat/hisilicon/hikey/aarch64/hikey_common.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -17,7 +17,7 @@ #include "../hikey_def.h" #define MAP_DDR MAP_REGION_FLAT(DDR_BASE, \ - DDR_SIZE, \ + DDR_SIZE - DDR_SEC_SIZE, \ MT_DEVICE | MT_RW | MT_NS) #define MAP_DEVICE MAP_REGION_FLAT(DEVICE_BASE, \ @@ -28,15 +28,6 @@ TSP_SEC_MEM_SIZE, \ MT_MEMORY | MT_RW | MT_SECURE) -#if LOAD_IMAGE_V2 -#ifdef SPD_opteed -#define MAP_OPTEE_PAGEABLE MAP_REGION_FLAT( \ - HIKEY_OPTEE_PAGEABLE_LOAD_BASE, \ - HIKEY_OPTEE_PAGEABLE_LOAD_SIZE, \ - MT_MEMORY | MT_RW | MT_SECURE) -#endif -#endif - #define MAP_ROM_PARAM MAP_REGION_FLAT(XG2RAM0_BASE, \ BL1_XG2RAM0_OFFSET, \ MT_DEVICE | MT_RO | MT_SECURE) @@ -73,11 +64,7 @@ static const mmap_region_t hikey_mmap[] = { MAP_DDR, MAP_DEVICE, MAP_TSP_MEM, -#if LOAD_IMAGE_V2 -#ifdef SPD_opteed - MAP_OPTEE_PAGEABLE, -#endif -#endif + MAP_SRAM, {0} }; #endif diff --git a/plat/hisilicon/hikey/hikey_bl1_setup.c b/plat/hisilicon/hikey/hikey_bl1_setup.c index df0ad8e03..69b194a53 100644 --- a/plat/hisilicon/hikey/hikey_bl1_setup.c +++ b/plat/hisilicon/hikey/hikey_bl1_setup.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -12,14 +12,10 @@ #include <dw_mmc.h> #include <emmc.h> #include <errno.h> -#include <gpio.h> #include <hi6220.h> -#include <hi6553.h> #include <mmio.h> -#include <pl061_gpio.h> #include <platform.h> #include <platform_def.h> -#include <sp804_delay_timer.h> #include <string.h> #include <tbbr/tbbr_img_desc.h> @@ -58,7 +54,6 @@ meminfo_t *bl1_plat_sec_mem_layout(void) return &bl1_tzram_layout; } -#if LOAD_IMAGE_V2 /******************************************************************************* * Function that takes a memory layout into which BL2 has been loaded and * populates a new memory layout for BL2 that ensures that BL1's data sections @@ -80,7 +75,6 @@ void bl1_init_bl2_mem_layout(const meminfo_t *bl1_mem_layout, flush_dcache_range((unsigned long)bl2_mem_layout, sizeof(meminfo_t)); } -#endif /* LOAD_IMAGE_V2 */ /* * Perform any BL1 specific platform actions. @@ -94,16 +88,6 @@ void bl1_early_platform_setup(void) bl1_tzram_layout.total_base = BL1_RW_BASE; bl1_tzram_layout.total_size = BL1_RW_SIZE; -#if !LOAD_IMAGE_V2 - /* Calculate how much RAM BL1 is using and how much remains free */ - bl1_tzram_layout.free_base = BL1_RW_BASE; - bl1_tzram_layout.free_size = BL1_RW_SIZE; - reserve_mem(&bl1_tzram_layout.free_base, - &bl1_tzram_layout.free_size, - BL1_RAM_BASE, - BL1_RAM_LIMIT - BL1_RAM_BASE); /* bl1_size */ -#endif - INFO("BL1: 0x%lx - 0x%lx [size = %lu]\n", BL1_RAM_BASE, BL1_RAM_LIMIT, BL1_RAM_LIMIT - BL1_RAM_BASE); /* bl1_size */ } @@ -123,381 +107,6 @@ void bl1_plat_arch_setup(void) BL1_COHERENT_RAM_LIMIT); } -static void hikey_sp804_init(void) -{ - uint32_t data; - - /* select the clock of dual timer0 */ - data = mmio_read_32(AO_SC_TIMER_EN0); - while (data & 3) { - data &= ~3; - data |= 3 << 16; - mmio_write_32(AO_SC_TIMER_EN0, data); - data = mmio_read_32(AO_SC_TIMER_EN0); - } - /* enable the pclk of dual timer0 */ - data = mmio_read_32(AO_SC_PERIPH_CLKSTAT4); - while (!(data & PCLK_TIMER1) || !(data & PCLK_TIMER0)) { - mmio_write_32(AO_SC_PERIPH_CLKEN4, PCLK_TIMER1 | PCLK_TIMER0); - data = mmio_read_32(AO_SC_PERIPH_CLKSTAT4); - } - /* reset dual timer0 */ - data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); - mmio_write_32(AO_SC_PERIPH_RSTEN4, PCLK_TIMER1 | PCLK_TIMER0); - do { - data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); - } while (!(data & PCLK_TIMER1) || !(data & PCLK_TIMER0)); - /* unreset dual timer0 */ - mmio_write_32(AO_SC_PERIPH_RSTDIS4, PCLK_TIMER1 | PCLK_TIMER0); - do { - data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); - } while ((data & PCLK_TIMER1) || (data & PCLK_TIMER0)); - - sp804_timer_init(SP804_TIMER0_BASE, 10, 192); -} - -static void hikey_gpio_init(void) -{ - pl061_gpio_init(); - pl061_gpio_register(GPIO0_BASE, 0); - pl061_gpio_register(GPIO1_BASE, 1); - pl061_gpio_register(GPIO2_BASE, 2); - pl061_gpio_register(GPIO3_BASE, 3); - pl061_gpio_register(GPIO4_BASE, 4); - pl061_gpio_register(GPIO5_BASE, 5); - pl061_gpio_register(GPIO6_BASE, 6); - pl061_gpio_register(GPIO7_BASE, 7); - pl061_gpio_register(GPIO8_BASE, 8); - pl061_gpio_register(GPIO9_BASE, 9); - pl061_gpio_register(GPIO10_BASE, 10); - pl061_gpio_register(GPIO11_BASE, 11); - pl061_gpio_register(GPIO12_BASE, 12); - pl061_gpio_register(GPIO13_BASE, 13); - pl061_gpio_register(GPIO14_BASE, 14); - pl061_gpio_register(GPIO15_BASE, 15); - pl061_gpio_register(GPIO16_BASE, 16); - pl061_gpio_register(GPIO17_BASE, 17); - pl061_gpio_register(GPIO18_BASE, 18); - pl061_gpio_register(GPIO19_BASE, 19); - - /* Power on indicator LED (USER_LED1). */ - gpio_set_direction(32, GPIO_DIR_OUT); /* LED1 */ - gpio_set_value(32, GPIO_LEVEL_HIGH); - gpio_set_direction(33, GPIO_DIR_OUT); /* LED2 */ - gpio_set_value(33, GPIO_LEVEL_LOW); - gpio_set_direction(34, GPIO_DIR_OUT); /* LED3 */ - gpio_set_direction(35, GPIO_DIR_OUT); /* LED4 */ -} - -static void hikey_pmussi_init(void) -{ - uint32_t data; - - /* Initialize PWR_HOLD GPIO */ - gpio_set_direction(0, GPIO_DIR_OUT); - gpio_set_value(0, GPIO_LEVEL_LOW); - - /* - * After reset, PMUSSI stays in reset mode. - * Now make it out of reset. - */ - mmio_write_32(AO_SC_PERIPH_RSTDIS4, - AO_SC_PERIPH_RSTDIS4_PRESET_PMUSSI_N); - do { - data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); - } while (data & AO_SC_PERIPH_RSTDIS4_PRESET_PMUSSI_N); - - /* Set PMUSSI clock latency for read operation. */ - data = mmio_read_32(AO_SC_MCU_SUBSYS_CTRL3); - data &= ~AO_SC_MCU_SUBSYS_CTRL3_RCLK_MASK; - data |= AO_SC_MCU_SUBSYS_CTRL3_RCLK_3; - mmio_write_32(AO_SC_MCU_SUBSYS_CTRL3, data); - - /* enable PMUSSI clock */ - data = AO_SC_PERIPH_CLKEN5_PCLK_PMUSSI_CCPU | - AO_SC_PERIPH_CLKEN5_PCLK_PMUSSI_MCU; - mmio_write_32(AO_SC_PERIPH_CLKEN5, data); - data = AO_SC_PERIPH_CLKEN4_PCLK_PMUSSI; - mmio_write_32(AO_SC_PERIPH_CLKEN4, data); - - gpio_set_value(0, GPIO_LEVEL_HIGH); -} - -static void hikey_hi6553_init(void) -{ - uint8_t data; - - mmio_write_8(HI6553_PERI_EN_MARK, 0x1e); - mmio_write_8(HI6553_NP_REG_ADJ1, 0); - data = DISABLE6_XO_CLK_CONN | DISABLE6_XO_CLK_NFC | - DISABLE6_XO_CLK_RF1 | DISABLE6_XO_CLK_RF2; - mmio_write_8(HI6553_DISABLE6_XO_CLK, data); - - /* configure BUCK0 & BUCK1 */ - mmio_write_8(HI6553_BUCK01_CTRL2, 0x5e); - mmio_write_8(HI6553_BUCK0_CTRL7, 0x10); - mmio_write_8(HI6553_BUCK1_CTRL7, 0x10); - mmio_write_8(HI6553_BUCK0_CTRL5, 0x1e); - mmio_write_8(HI6553_BUCK1_CTRL5, 0x1e); - mmio_write_8(HI6553_BUCK0_CTRL1, 0xfc); - mmio_write_8(HI6553_BUCK1_CTRL1, 0xfc); - - /* configure BUCK2 */ - mmio_write_8(HI6553_BUCK2_REG1, 0x4f); - mmio_write_8(HI6553_BUCK2_REG5, 0x99); - mmio_write_8(HI6553_BUCK2_REG6, 0x45); - mdelay(1); - mmio_write_8(HI6553_VSET_BUCK2_ADJ, 0x22); - mdelay(1); - - /* configure BUCK3 */ - mmio_write_8(HI6553_BUCK3_REG3, 0x02); - mmio_write_8(HI6553_BUCK3_REG5, 0x99); - mmio_write_8(HI6553_BUCK3_REG6, 0x41); - mmio_write_8(HI6553_VSET_BUCK3_ADJ, 0x02); - mdelay(1); - - /* configure BUCK4 */ - mmio_write_8(HI6553_BUCK4_REG2, 0x9a); - mmio_write_8(HI6553_BUCK4_REG5, 0x99); - mmio_write_8(HI6553_BUCK4_REG6, 0x45); - - /* configure LDO20 */ - mmio_write_8(HI6553_LDO20_REG_ADJ, 0x50); - - mmio_write_8(HI6553_NP_REG_CHG, 0x0f); - mmio_write_8(HI6553_CLK_TOP0, 0x06); - mmio_write_8(HI6553_CLK_TOP3, 0xc0); - mmio_write_8(HI6553_CLK_TOP4, 0x00); - - /* configure LDO7 & LDO10 for SD slot */ - /* enable LDO7 */ - data = mmio_read_8(HI6553_LDO7_REG_ADJ); - data = (data & 0xf8) | 0x2; - mmio_write_8(HI6553_LDO7_REG_ADJ, data); - mdelay(5); - mmio_write_8(HI6553_ENABLE2_LDO1_8, 1 << 6); - mdelay(5); - /* enable LDO10 */ - data = mmio_read_8(HI6553_LDO10_REG_ADJ); - data = (data & 0xf8) | 0x5; - mmio_write_8(HI6553_LDO10_REG_ADJ, data); - mdelay(5); - mmio_write_8(HI6553_ENABLE3_LDO9_16, 1 << 1); - mdelay(5); - /* enable LDO15 */ - data = mmio_read_8(HI6553_LDO15_REG_ADJ); - data = (data & 0xf8) | 0x4; - mmio_write_8(HI6553_LDO15_REG_ADJ, data); - mmio_write_8(HI6553_ENABLE3_LDO9_16, 1 << 6); - mdelay(5); - /* enable LDO19 */ - data = mmio_read_8(HI6553_LDO19_REG_ADJ); - data |= 0x7; - mmio_write_8(HI6553_LDO19_REG_ADJ, data); - mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 2); - mdelay(5); - /* enable LDO21 */ - data = mmio_read_8(HI6553_LDO21_REG_ADJ); - data = (data & 0xf8) | 0x3; - mmio_write_8(HI6553_LDO21_REG_ADJ, data); - mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 4); - mdelay(5); - /* enable LDO22 */ - data = mmio_read_8(HI6553_LDO22_REG_ADJ); - data = (data & 0xf8) | 0x7; - mmio_write_8(HI6553_LDO22_REG_ADJ, data); - mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 5); - mdelay(5); - - /* select 32.764KHz */ - mmio_write_8(HI6553_CLK19M2_600_586_EN, 0x01); - - /* Disable vbus_det interrupts */ - data = mmio_read_8(HI6553_IRQ2_MASK); - data = data | 0x3; - mmio_write_8(HI6553_IRQ2_MASK, data); -} - -static void init_mmc0_pll(void) -{ - unsigned int data; - - /* select SYSPLL as the source of MMC0 */ - /* select SYSPLL as the source of MUX1 (SC_CLK_SEL0) */ - mmio_write_32(PERI_SC_CLK_SEL0, 1 << 5 | 1 << 21); - do { - data = mmio_read_32(PERI_SC_CLK_SEL0); - } while (!(data & (1 << 5))); - /* select MUX1 as the source of MUX2 (SC_CLK_SEL0) */ - mmio_write_32(PERI_SC_CLK_SEL0, 1 << 29); - do { - data = mmio_read_32(PERI_SC_CLK_SEL0); - } while (data & (1 << 13)); - - mmio_write_32(PERI_SC_PERIPH_CLKEN0, (1 << 0)); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (!(data & (1 << 0))); - - data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); - data |= 1 << 1; - mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); - - do { - mmio_write_32(PERI_SC_CLKCFG8BIT1, (1 << 7) | 0xb); - data = mmio_read_32(PERI_SC_CLKCFG8BIT1); - } while ((data & 0xb) != 0xb); -} - -static void reset_mmc0_clk(void) -{ - unsigned int data; - - /* disable mmc0 bus clock */ - mmio_write_32(PERI_SC_PERIPH_CLKDIS0, PERI_CLK0_MMC0); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (data & PERI_CLK0_MMC0); - /* enable mmc0 bus clock */ - mmio_write_32(PERI_SC_PERIPH_CLKEN0, PERI_CLK0_MMC0); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (!(data & PERI_CLK0_MMC0)); - /* reset mmc0 clock domain */ - mmio_write_32(PERI_SC_PERIPH_RSTEN0, PERI_RST0_MMC0); - - /* bypass mmc0 clock phase */ - data = mmio_read_32(PERI_SC_PERIPH_CTRL2); - data |= 3; - mmio_write_32(PERI_SC_PERIPH_CTRL2, data); - - /* disable low power */ - data = mmio_read_32(PERI_SC_PERIPH_CTRL13); - data |= 1 << 3; - mmio_write_32(PERI_SC_PERIPH_CTRL13, data); - do { - data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); - } while (!(data & PERI_RST0_MMC0)); - - /* unreset mmc0 clock domain */ - mmio_write_32(PERI_SC_PERIPH_RSTDIS0, PERI_RST0_MMC0); - do { - data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); - } while (data & PERI_RST0_MMC0); -} - -static void init_media_clk(void) -{ - unsigned int data, value; - - data = mmio_read_32(PMCTRL_MEDPLLCTRL); - data |= 1; - mmio_write_32(PMCTRL_MEDPLLCTRL, data); - - for (;;) { - data = mmio_read_32(PMCTRL_MEDPLLCTRL); - value = 1 << 28; - if ((data & value) == value) - break; - } - - data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); - data = 1 << 10; - mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); -} - -static void init_mmc1_pll(void) -{ - uint32_t data; - - /* select SYSPLL as the source of MMC1 */ - /* select SYSPLL as the source of MUX1 (SC_CLK_SEL0) */ - mmio_write_32(PERI_SC_CLK_SEL0, 1 << 11 | 1 << 27); - do { - data = mmio_read_32(PERI_SC_CLK_SEL0); - } while (!(data & (1 << 11))); - /* select MUX1 as the source of MUX2 (SC_CLK_SEL0) */ - mmio_write_32(PERI_SC_CLK_SEL0, 1 << 30); - do { - data = mmio_read_32(PERI_SC_CLK_SEL0); - } while (data & (1 << 14)); - - mmio_write_32(PERI_SC_PERIPH_CLKEN0, (1 << 1)); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (!(data & (1 << 1))); - - data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); - data |= 1 << 2; - mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); - - do { - /* 1.2GHz / 50 = 24MHz */ - mmio_write_32(PERI_SC_CLKCFG8BIT2, 0x31 | (1 << 7)); - data = mmio_read_32(PERI_SC_CLKCFG8BIT2); - } while ((data & 0x31) != 0x31); -} - -static void reset_mmc1_clk(void) -{ - unsigned int data; - - /* disable mmc1 bus clock */ - mmio_write_32(PERI_SC_PERIPH_CLKDIS0, PERI_CLK0_MMC1); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (data & PERI_CLK0_MMC1); - /* enable mmc1 bus clock */ - mmio_write_32(PERI_SC_PERIPH_CLKEN0, PERI_CLK0_MMC1); - do { - data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); - } while (!(data & PERI_CLK0_MMC1)); - /* reset mmc1 clock domain */ - mmio_write_32(PERI_SC_PERIPH_RSTEN0, PERI_RST0_MMC1); - - /* bypass mmc1 clock phase */ - data = mmio_read_32(PERI_SC_PERIPH_CTRL2); - data |= 3 << 2; - mmio_write_32(PERI_SC_PERIPH_CTRL2, data); - - /* disable low power */ - data = mmio_read_32(PERI_SC_PERIPH_CTRL13); - data |= 1 << 4; - mmio_write_32(PERI_SC_PERIPH_CTRL13, data); - do { - data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); - } while (!(data & PERI_RST0_MMC1)); - - /* unreset mmc0 clock domain */ - mmio_write_32(PERI_SC_PERIPH_RSTDIS0, PERI_RST0_MMC1); - do { - data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); - } while (data & PERI_RST0_MMC1); -} - -/* Initialize PLL of both eMMC and SD controllers. */ -static void hikey_mmc_pll_init(void) -{ - init_mmc0_pll(); - reset_mmc0_clk(); - init_media_clk(); - - dsb(); - - init_mmc1_pll(); - reset_mmc1_clk(); -} - -static void hikey_rtc_init(void) -{ - uint32_t data; - - data = mmio_read_32(AO_SC_PERIPH_CLKEN4); - data |= AO_SC_PERIPH_RSTDIS4_RESET_RTC0_N; - mmio_write_32(AO_SC_PERIPH_CLKEN4, data); -} - /* * Function which will perform any remaining platform-specific setup that can * occur after the MMU and data cache have been enabled. @@ -541,9 +150,6 @@ unsigned int bl1_plat_get_next_image_id(void) boot_mode = mmio_read_32(ONCHIPROM_PARAM_BASE); switch (boot_mode) { - case BOOT_NORMAL: - ret = BL2_IMAGE_ID; - break; case BOOT_USB_DOWNLOAD: case BOOT_UART_DOWNLOAD: ret = NS_BL1U_IMAGE_ID; @@ -572,10 +178,10 @@ image_desc_t *bl1_plat_get_image_desc(unsigned int image_id) void bl1_plat_set_ep_info(unsigned int image_id, entry_point_info_t *ep_info) { - unsigned int data = 0; + uint64_t data = 0; if (image_id == BL2_IMAGE_ID) - return; + panic(); inv_dcache_range(NS_BL1U_BASE, NS_BL1U_SIZE); __asm__ volatile ("mrs %0, cpacr_el1" : "=r"(data)); do { @@ -583,7 +189,7 @@ void bl1_plat_set_ep_info(unsigned int image_id, __asm__ volatile ("msr cpacr_el1, %0" : : "r"(data)); __asm__ volatile ("mrs %0, cpacr_el1" : "=r"(data)); } while ((data & (3 << 20)) != (3 << 20)); - INFO("cpacr_el1:0x%x\n", data); + INFO("cpacr_el1:0x%lx\n", data); ep_info->args.arg0 = 0xffff & read_mpidr(); ep_info->spsr = SPSR_64(MODE_EL1, MODE_SP_ELX, diff --git a/plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c b/plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c index 50ca01573..7c025c34d 100644 --- a/plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c +++ b/plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -28,7 +28,7 @@ static bl_mem_params_node_t bl2_mem_params_descs[] = { VERSION_2, entry_point_info_t, SECURE | NON_EXECUTABLE), SET_STATIC_PARAM_HEAD(image_info, PARAM_IMAGE_BINARY, - VERSION_2, image_info_t, 0), + VERSION_2, image_info_t, IMAGE_ATTRIB_PLAT_SETUP), .image_info.image_base = SCP_BL2_BASE, .image_info.image_max_size = SCP_BL2_SIZE, diff --git a/plat/hisilicon/hikey/hikey_bl2_setup.c b/plat/hisilicon/hikey/hikey_bl2_setup.c index 3f5e48607..20bb7527e 100644 --- a/plat/hisilicon/hikey/hikey_bl2_setup.c +++ b/plat/hisilicon/hikey/hikey_bl2_setup.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -17,13 +17,11 @@ #include <hisi_mcu.h> #include <hisi_sram_map.h> #include <mmio.h> -#if LOAD_IMAGE_V2 #ifdef SPD_opteed #include <optee_utils.h> #endif -#endif +#include <platform.h> #include <platform_def.h> -#include <sp804_delay_timer.h> #include <string.h> #include "hikey_def.h" @@ -38,6 +36,8 @@ #define BL2_RO_BASE (unsigned long)(&__RO_START__) #define BL2_RO_LIMIT (unsigned long)(&__RO_END__) +#define BL2_RW_BASE (BL2_RO_LIMIT) + /* * The next 2 constants identify the extents of the coherent memory region. * These addresses are used by the MMU setup code and therefore they must be @@ -48,50 +48,19 @@ #define BL2_COHERENT_RAM_BASE (unsigned long)(&__COHERENT_RAM_START__) #define BL2_COHERENT_RAM_LIMIT (unsigned long)(&__COHERENT_RAM_END__) -static meminfo_t bl2_tzram_layout __aligned(CACHE_WRITEBACK_GRANULE); +static meminfo_t bl2_el3_tzram_layout; -#if !LOAD_IMAGE_V2 - -/******************************************************************************* - * This structure represents the superset of information that is passed to - * BL31, e.g. while passing control to it from BL2, bl31_params - * and other platform specific params - ******************************************************************************/ -typedef struct bl2_to_bl31_params_mem { - bl31_params_t bl31_params; - image_info_t bl31_image_info; - image_info_t bl32_image_info; - image_info_t bl33_image_info; - entry_point_info_t bl33_ep_info; - entry_point_info_t bl32_ep_info; - entry_point_info_t bl31_ep_info; -} bl2_to_bl31_params_mem_t; - -static bl2_to_bl31_params_mem_t bl31_params_mem; - -meminfo_t *bl2_plat_sec_mem_layout(void) -{ - return &bl2_tzram_layout; -} - -void bl2_plat_get_scp_bl2_meminfo(meminfo_t *scp_bl2_meminfo) -{ - scp_bl2_meminfo->total_base = SCP_BL2_BASE; - scp_bl2_meminfo->total_size = SCP_BL2_SIZE; - scp_bl2_meminfo->free_base = SCP_BL2_BASE; - scp_bl2_meminfo->free_size = SCP_BL2_SIZE; -} -#endif /* LOAD_IMAGE_V2 */ +enum { + BOOT_MODE_RECOVERY = 0, + BOOT_MODE_NORMAL, + BOOT_MODE_MASK = 1, +}; /******************************************************************************* * Transfer SCP_BL2 from Trusted RAM using the SCP Download protocol. * Return 0 on success, -1 otherwise. ******************************************************************************/ -#if LOAD_IMAGE_V2 int plat_hikey_bl2_handle_scp_bl2(image_info_t *scp_bl2_image_info) -#else -int bl2_plat_handle_scp_bl2(struct image_info *scp_bl2_image_info) -#endif { /* Enable MCU SRAM */ hisi_mcu_enable_sram(); @@ -161,7 +130,6 @@ uint32_t hikey_get_spsr_for_bl33_entry(void) } #endif /* AARCH32 */ -#if LOAD_IMAGE_V2 int hikey_bl2_handle_post_image_load(unsigned int image_id) { int err = 0; @@ -222,144 +190,6 @@ int bl2_plat_handle_post_image_load(unsigned int image_id) return hikey_bl2_handle_post_image_load(image_id); } -#else /* LOAD_IMAGE_V2 */ - -bl31_params_t *bl2_plat_get_bl31_params(void) -{ - bl31_params_t *bl2_to_bl31_params = NULL; - - /* - * Initialise the memory for all the arguments that needs to - * be passed to BL3-1 - */ - memset(&bl31_params_mem, 0, sizeof(bl2_to_bl31_params_mem_t)); - - /* Assign memory for TF related information */ - bl2_to_bl31_params = &bl31_params_mem.bl31_params; - SET_PARAM_HEAD(bl2_to_bl31_params, PARAM_BL31, VERSION_1, 0); - - /* Fill BL3-1 related information */ - bl2_to_bl31_params->bl31_image_info = &bl31_params_mem.bl31_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); - - /* Fill BL3-2 related information if it exists */ -#ifdef BL32_BASE - bl2_to_bl31_params->bl32_ep_info = &bl31_params_mem.bl32_ep_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl32_ep_info, PARAM_EP, - VERSION_1, 0); - bl2_to_bl31_params->bl32_image_info = &bl31_params_mem.bl32_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl32_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); -#endif - - /* Fill BL3-3 related information */ - bl2_to_bl31_params->bl33_ep_info = &bl31_params_mem.bl33_ep_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl33_ep_info, - PARAM_EP, VERSION_1, 0); - - /* BL3-3 expects to receive the primary CPU MPID (through x0) */ - bl2_to_bl31_params->bl33_ep_info->args.arg0 = 0xffff & read_mpidr(); - - bl2_to_bl31_params->bl33_image_info = &bl31_params_mem.bl33_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl33_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); - - return bl2_to_bl31_params; -} - -struct entry_point_info *bl2_plat_get_bl31_ep_info(void) -{ -#if DEBUG - bl31_params_mem.bl31_ep_info.args.arg1 = HIKEY_BL31_PLAT_PARAM_VAL; -#endif - - return &bl31_params_mem.bl31_ep_info; -} - -void bl2_plat_set_bl31_ep_info(image_info_t *image, - entry_point_info_t *bl31_ep_info) -{ - SET_SECURITY_STATE(bl31_ep_info->h.attr, SECURE); - bl31_ep_info->spsr = SPSR_64(MODE_EL3, MODE_SP_ELX, - DISABLE_ALL_EXCEPTIONS); -} - -/******************************************************************************* - * Before calling this function BL32 is loaded in memory and its entrypoint - * is set by load_image. This is a placeholder for the platform to change - * the entrypoint of BL32 and set SPSR and security state. - * On Hikey we only set the security state of the entrypoint - ******************************************************************************/ -#ifdef BL32_BASE -void bl2_plat_set_bl32_ep_info(image_info_t *bl32_image_info, - entry_point_info_t *bl32_ep_info) -{ - SET_SECURITY_STATE(bl32_ep_info->h.attr, SECURE); - /* - * The Secure Payload Dispatcher service is responsible for - * setting the SPSR prior to entry into the BL32 image. - */ - bl32_ep_info->spsr = 0; -} - -/******************************************************************************* - * Populate the extents of memory available for loading BL32 - ******************************************************************************/ -void bl2_plat_get_bl32_meminfo(meminfo_t *bl32_meminfo) -{ - /* - * Populate the extents of memory available for loading BL32. - */ - bl32_meminfo->total_base = BL32_BASE; - bl32_meminfo->free_base = BL32_BASE; - bl32_meminfo->total_size = - (TSP_SEC_MEM_BASE + TSP_SEC_MEM_SIZE) - BL32_BASE; - bl32_meminfo->free_size = - (TSP_SEC_MEM_BASE + TSP_SEC_MEM_SIZE) - BL32_BASE; -} -#endif /* BL32_BASE */ - -void bl2_plat_set_bl33_ep_info(image_info_t *image, - entry_point_info_t *bl33_ep_info) -{ - unsigned long el_status; - unsigned int mode; - - /* Figure out what mode we enter the non-secure world in */ - el_status = read_id_aa64pfr0_el1() >> ID_AA64PFR0_EL2_SHIFT; - el_status &= ID_AA64PFR0_ELX_MASK; - - if (el_status) - mode = MODE_EL2; - else - mode = MODE_EL1; - - /* - * TODO: Consider the possibility of specifying the SPSR in - * the FIP ToC and allowing the platform to have a say as - * well. - */ - bl33_ep_info->spsr = SPSR_64(mode, MODE_SP_ELX, - DISABLE_ALL_EXCEPTIONS); - SET_SECURITY_STATE(bl33_ep_info->h.attr, NON_SECURE); -} - -void bl2_plat_flush_bl31_params(void) -{ - flush_dcache_range((unsigned long)&bl31_params_mem, - sizeof(bl2_to_bl31_params_mem_t)); -} - -void bl2_plat_get_bl33_meminfo(meminfo_t *bl33_meminfo) -{ - bl33_meminfo->total_base = DDR_BASE; - bl33_meminfo->total_size = DDR_SIZE; - bl33_meminfo->free_base = DDR_BASE; - bl33_meminfo->free_size = DDR_SIZE; -} -#endif /* LOAD_IMAGE_V2 */ - static void reset_dwmmc_clk(void) { unsigned int data; @@ -442,28 +272,53 @@ static void hikey_jumper_init(void) mmio_write_32(IOMG_GPIO24, IOMG_MUX_FUNC0); } -void bl2_early_platform_setup(meminfo_t *mem_layout) +void bl2_el3_early_platform_setup(u_register_t arg1, u_register_t arg2, + u_register_t arg3, u_register_t arg4) { - dw_mmc_params_t params; - /* Initialize the console to provide early debug support */ console_init(CONSOLE_BASE, PL011_UART_CLK_IN_HZ, PL011_BAUDRATE); + /* + * Allow BL2 to see the whole Trusted RAM. + */ + bl2_el3_tzram_layout.total_base = BL2_RW_BASE; + bl2_el3_tzram_layout.total_size = BL31_LIMIT - BL2_RW_BASE; +} + +void bl2_el3_plat_arch_setup(void) +{ + hikey_init_mmu_el3(bl2_el3_tzram_layout.total_base, + bl2_el3_tzram_layout.total_size, + BL2_RO_BASE, + BL2_RO_LIMIT, + BL2_COHERENT_RAM_BASE, + BL2_COHERENT_RAM_LIMIT); +} - /* Setup the BL2 memory layout */ - bl2_tzram_layout = *mem_layout; +void bl2_platform_setup(void) +{ + dw_mmc_params_t params; - /* Clear SRAM since it'll be used by MCU right now. */ - memset((void *)SRAM_BASE, 0, SRAM_SIZE); + hikey_sp804_init(); + hikey_gpio_init(); + hikey_pmussi_init(); + hikey_hi6553_init(); - sp804_timer_init(SP804_TIMER0_BASE, 10, 192); dsb(); hikey_ddr_init(); + hikey_security_setup(); + + /* Clear SRAM since it'll be used by MCU right now. */ + memset((void *)SRAM_BASE, 0, SRAM_SIZE); + clean_dcache_range(SRAM_BASE, SRAM_SIZE); hikey_boardid_init(); init_acpu_dvfs(); + hikey_rtc_init(); hikey_sd_init(); hikey_jumper_init(); + hikey_mmc_pll_init(); + reset_dwmmc_clk(); memset(¶ms, 0, sizeof(dw_mmc_params_t)); params.reg_base = DWMMC0_BASE; @@ -476,18 +331,3 @@ void bl2_early_platform_setup(meminfo_t *mem_layout) hikey_io_setup(); } - -void bl2_plat_arch_setup(void) -{ - hikey_init_mmu_el1(bl2_tzram_layout.total_base, - bl2_tzram_layout.total_size, - BL2_RO_BASE, - BL2_RO_LIMIT, - BL2_COHERENT_RAM_BASE, - BL2_COHERENT_RAM_LIMIT); -} - -void bl2_platform_setup(void) -{ - hikey_security_setup(); -} diff --git a/plat/hisilicon/hikey/hikey_bl31_setup.c b/plat/hisilicon/hikey/hikey_bl31_setup.c index 412b59355..e13ecf675 100644 --- a/plat/hisilicon/hikey/hikey_bl31_setup.c +++ b/plat/hisilicon/hikey/hikey_bl31_setup.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -82,13 +82,8 @@ entry_point_info_t *bl31_plat_get_next_image_ep_info(uint32_t type) return NULL; } -#if LOAD_IMAGE_V2 void bl31_early_platform_setup(void *from_bl2, void *plat_params_from_bl2) -#else -void bl31_early_platform_setup(bl31_params_t *from_bl2, - void *plat_params_from_bl2) -#endif { /* Initialize the console to provide early debug support */ console_init(CONSOLE_BASE, PL011_UART_CLK_IN_HZ, PL011_BAUDRATE); @@ -97,7 +92,6 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, cci_init(CCI400_BASE, cci_map, ARRAY_SIZE(cci_map)); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); -#if LOAD_IMAGE_V2 /* * Check params passed from BL2 should not be NULL, */ @@ -124,23 +118,6 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, if (bl33_ep_info.pc == 0) panic(); - -#else /* LOAD_IMAGE_V2 */ - - /* - * Check params passed from BL2 should not be NULL, - */ - assert(from_bl2 != NULL); - assert(from_bl2->h.type == PARAM_BL31); - assert(from_bl2->h.version >= VERSION_1); - - /* - * Copy BL3-2 and BL3-3 entry point information. - * They are stored in Secure RAM, in BL2's address space. - */ - bl32_ep_info = *from_bl2->bl32_ep_info; - bl33_ep_info = *from_bl2->bl33_ep_info; -#endif /* LOAD_IMAGE_V2 */ } void bl31_plat_arch_setup(void) diff --git a/plat/hisilicon/hikey/hikey_bl_common.c b/plat/hisilicon/hikey/hikey_bl_common.c new file mode 100644 index 000000000..b254a900d --- /dev/null +++ b/plat/hisilicon/hikey/hikey_bl_common.c @@ -0,0 +1,390 @@ +/* + * Copyright (c) 2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#include <arch_helpers.h> +#include <gpio.h> +#include <hi6220.h> +#include <hi6553.h> +#include <mmio.h> +#include <pl061_gpio.h> +#include <sp804_delay_timer.h> + +#include "hikey_private.h" + +void hikey_sp804_init(void) +{ + uint32_t data; + + /* select the clock of dual timer0 */ + data = mmio_read_32(AO_SC_TIMER_EN0); + while (data & 3) { + data &= ~3; + data |= 3 << 16; + mmio_write_32(AO_SC_TIMER_EN0, data); + data = mmio_read_32(AO_SC_TIMER_EN0); + } + /* enable the pclk of dual timer0 */ + data = mmio_read_32(AO_SC_PERIPH_CLKSTAT4); + while (!(data & PCLK_TIMER1) || !(data & PCLK_TIMER0)) { + mmio_write_32(AO_SC_PERIPH_CLKEN4, PCLK_TIMER1 | PCLK_TIMER0); + data = mmio_read_32(AO_SC_PERIPH_CLKSTAT4); + } + /* reset dual timer0 */ + data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); + mmio_write_32(AO_SC_PERIPH_RSTEN4, PCLK_TIMER1 | PCLK_TIMER0); + do { + data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); + } while (!(data & PCLK_TIMER1) || !(data & PCLK_TIMER0)); + /* unreset dual timer0 */ + mmio_write_32(AO_SC_PERIPH_RSTDIS4, PCLK_TIMER1 | PCLK_TIMER0); + do { + data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); + } while ((data & PCLK_TIMER1) || (data & PCLK_TIMER0)); + + sp804_timer_init(SP804_TIMER0_BASE, 10, 192); +} + +void hikey_gpio_init(void) +{ + pl061_gpio_init(); + pl061_gpio_register(GPIO0_BASE, 0); + pl061_gpio_register(GPIO1_BASE, 1); + pl061_gpio_register(GPIO2_BASE, 2); + pl061_gpio_register(GPIO3_BASE, 3); + pl061_gpio_register(GPIO4_BASE, 4); + pl061_gpio_register(GPIO5_BASE, 5); + pl061_gpio_register(GPIO6_BASE, 6); + pl061_gpio_register(GPIO7_BASE, 7); + pl061_gpio_register(GPIO8_BASE, 8); + pl061_gpio_register(GPIO9_BASE, 9); + pl061_gpio_register(GPIO10_BASE, 10); + pl061_gpio_register(GPIO11_BASE, 11); + pl061_gpio_register(GPIO12_BASE, 12); + pl061_gpio_register(GPIO13_BASE, 13); + pl061_gpio_register(GPIO14_BASE, 14); + pl061_gpio_register(GPIO15_BASE, 15); + pl061_gpio_register(GPIO16_BASE, 16); + pl061_gpio_register(GPIO17_BASE, 17); + pl061_gpio_register(GPIO18_BASE, 18); + pl061_gpio_register(GPIO19_BASE, 19); + + /* Power on indicator LED (USER_LED1). */ + gpio_set_direction(32, GPIO_DIR_OUT); /* LED1 */ + gpio_set_value(32, GPIO_LEVEL_HIGH); + gpio_set_direction(33, GPIO_DIR_OUT); /* LED2 */ + gpio_set_value(33, GPIO_LEVEL_LOW); + gpio_set_direction(34, GPIO_DIR_OUT); /* LED3 */ + gpio_set_direction(35, GPIO_DIR_OUT); /* LED4 */ +} + +void hikey_pmussi_init(void) +{ + uint32_t data; + + /* Initialize PWR_HOLD GPIO */ + gpio_set_direction(0, GPIO_DIR_OUT); + gpio_set_value(0, GPIO_LEVEL_LOW); + + /* + * After reset, PMUSSI stays in reset mode. + * Now make it out of reset. + */ + mmio_write_32(AO_SC_PERIPH_RSTDIS4, + AO_SC_PERIPH_RSTDIS4_PRESET_PMUSSI_N); + do { + data = mmio_read_32(AO_SC_PERIPH_RSTSTAT4); + } while (data & AO_SC_PERIPH_RSTDIS4_PRESET_PMUSSI_N); + + /* Set PMUSSI clock latency for read operation. */ + data = mmio_read_32(AO_SC_MCU_SUBSYS_CTRL3); + data &= ~AO_SC_MCU_SUBSYS_CTRL3_RCLK_MASK; + data |= AO_SC_MCU_SUBSYS_CTRL3_RCLK_3; + mmio_write_32(AO_SC_MCU_SUBSYS_CTRL3, data); + + /* enable PMUSSI clock */ + data = AO_SC_PERIPH_CLKEN5_PCLK_PMUSSI_CCPU | + AO_SC_PERIPH_CLKEN5_PCLK_PMUSSI_MCU; + mmio_write_32(AO_SC_PERIPH_CLKEN5, data); + data = AO_SC_PERIPH_CLKEN4_PCLK_PMUSSI; + mmio_write_32(AO_SC_PERIPH_CLKEN4, data); + + gpio_set_value(0, GPIO_LEVEL_HIGH); +} + +void hikey_hi6553_init(void) +{ + uint8_t data; + + mmio_write_8(HI6553_PERI_EN_MARK, 0x1e); + mmio_write_8(HI6553_NP_REG_ADJ1, 0); + data = DISABLE6_XO_CLK_CONN | DISABLE6_XO_CLK_NFC | + DISABLE6_XO_CLK_RF1 | DISABLE6_XO_CLK_RF2; + mmio_write_8(HI6553_DISABLE6_XO_CLK, data); + + /* configure BUCK0 & BUCK1 */ + mmio_write_8(HI6553_BUCK01_CTRL2, 0x5e); + mmio_write_8(HI6553_BUCK0_CTRL7, 0x10); + mmio_write_8(HI6553_BUCK1_CTRL7, 0x10); + mmio_write_8(HI6553_BUCK0_CTRL5, 0x1e); + mmio_write_8(HI6553_BUCK1_CTRL5, 0x1e); + mmio_write_8(HI6553_BUCK0_CTRL1, 0xfc); + mmio_write_8(HI6553_BUCK1_CTRL1, 0xfc); + + /* configure BUCK2 */ + mmio_write_8(HI6553_BUCK2_REG1, 0x4f); + mmio_write_8(HI6553_BUCK2_REG5, 0x99); + mmio_write_8(HI6553_BUCK2_REG6, 0x45); + mdelay(1); + mmio_write_8(HI6553_VSET_BUCK2_ADJ, 0x22); + mdelay(1); + + /* configure BUCK3 */ + mmio_write_8(HI6553_BUCK3_REG3, 0x02); + mmio_write_8(HI6553_BUCK3_REG5, 0x99); + mmio_write_8(HI6553_BUCK3_REG6, 0x41); + mmio_write_8(HI6553_VSET_BUCK3_ADJ, 0x02); + mdelay(1); + + /* configure BUCK4 */ + mmio_write_8(HI6553_BUCK4_REG2, 0x9a); + mmio_write_8(HI6553_BUCK4_REG5, 0x99); + mmio_write_8(HI6553_BUCK4_REG6, 0x45); + + /* configure LDO20 */ + mmio_write_8(HI6553_LDO20_REG_ADJ, 0x50); + + mmio_write_8(HI6553_NP_REG_CHG, 0x0f); + mmio_write_8(HI6553_CLK_TOP0, 0x06); + mmio_write_8(HI6553_CLK_TOP3, 0xc0); + mmio_write_8(HI6553_CLK_TOP4, 0x00); + + /* configure LDO7 & LDO10 for SD slot */ + /* enable LDO7 */ + data = mmio_read_8(HI6553_LDO7_REG_ADJ); + data = (data & 0xf8) | 0x2; + mmio_write_8(HI6553_LDO7_REG_ADJ, data); + mdelay(5); + mmio_write_8(HI6553_ENABLE2_LDO1_8, 1 << 6); + mdelay(5); + /* enable LDO10 */ + data = mmio_read_8(HI6553_LDO10_REG_ADJ); + data = (data & 0xf8) | 0x5; + mmio_write_8(HI6553_LDO10_REG_ADJ, data); + mdelay(5); + mmio_write_8(HI6553_ENABLE3_LDO9_16, 1 << 1); + mdelay(5); + /* enable LDO15 */ + data = mmio_read_8(HI6553_LDO15_REG_ADJ); + data = (data & 0xf8) | 0x4; + mmio_write_8(HI6553_LDO15_REG_ADJ, data); + mmio_write_8(HI6553_ENABLE3_LDO9_16, 1 << 6); + mdelay(5); + /* enable LDO19 */ + data = mmio_read_8(HI6553_LDO19_REG_ADJ); + data |= 0x7; + mmio_write_8(HI6553_LDO19_REG_ADJ, data); + mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 2); + mdelay(5); + /* enable LDO21 */ + data = mmio_read_8(HI6553_LDO21_REG_ADJ); + data = (data & 0xf8) | 0x3; + mmio_write_8(HI6553_LDO21_REG_ADJ, data); + mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 4); + mdelay(5); + /* enable LDO22 */ + data = mmio_read_8(HI6553_LDO22_REG_ADJ); + data = (data & 0xf8) | 0x7; + mmio_write_8(HI6553_LDO22_REG_ADJ, data); + mmio_write_8(HI6553_ENABLE4_LDO17_22, 1 << 5); + mdelay(5); + + /* select 32.764KHz */ + mmio_write_8(HI6553_CLK19M2_600_586_EN, 0x01); + + /* Disable vbus_det interrupts */ + data = mmio_read_8(HI6553_IRQ2_MASK); + data = data | 0x3; + mmio_write_8(HI6553_IRQ2_MASK, data); +} + +void init_mmc0_pll(void) +{ + unsigned int data; + + /* select SYSPLL as the source of MMC0 */ + /* select SYSPLL as the source of MUX1 (SC_CLK_SEL0) */ + mmio_write_32(PERI_SC_CLK_SEL0, 1 << 5 | 1 << 21); + do { + data = mmio_read_32(PERI_SC_CLK_SEL0); + } while (!(data & (1 << 5))); + /* select MUX1 as the source of MUX2 (SC_CLK_SEL0) */ + mmio_write_32(PERI_SC_CLK_SEL0, 1 << 29); + do { + data = mmio_read_32(PERI_SC_CLK_SEL0); + } while (data & (1 << 13)); + + mmio_write_32(PERI_SC_PERIPH_CLKEN0, (1 << 0)); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (!(data & (1 << 0))); + + data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); + data |= 1 << 1; + mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); + + do { + mmio_write_32(PERI_SC_CLKCFG8BIT1, (1 << 7) | 0xb); + data = mmio_read_32(PERI_SC_CLKCFG8BIT1); + } while ((data & 0xb) != 0xb); +} + +void reset_mmc0_clk(void) +{ + unsigned int data; + + /* disable mmc0 bus clock */ + mmio_write_32(PERI_SC_PERIPH_CLKDIS0, PERI_CLK0_MMC0); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (data & PERI_CLK0_MMC0); + /* enable mmc0 bus clock */ + mmio_write_32(PERI_SC_PERIPH_CLKEN0, PERI_CLK0_MMC0); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (!(data & PERI_CLK0_MMC0)); + /* reset mmc0 clock domain */ + mmio_write_32(PERI_SC_PERIPH_RSTEN0, PERI_RST0_MMC0); + + /* bypass mmc0 clock phase */ + data = mmio_read_32(PERI_SC_PERIPH_CTRL2); + data |= 3; + mmio_write_32(PERI_SC_PERIPH_CTRL2, data); + + /* disable low power */ + data = mmio_read_32(PERI_SC_PERIPH_CTRL13); + data |= 1 << 3; + mmio_write_32(PERI_SC_PERIPH_CTRL13, data); + do { + data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); + } while (!(data & PERI_RST0_MMC0)); + + /* unreset mmc0 clock domain */ + mmio_write_32(PERI_SC_PERIPH_RSTDIS0, PERI_RST0_MMC0); + do { + data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); + } while (data & PERI_RST0_MMC0); +} + +void init_media_clk(void) +{ + unsigned int data, value; + + data = mmio_read_32(PMCTRL_MEDPLLCTRL); + data |= 1; + mmio_write_32(PMCTRL_MEDPLLCTRL, data); + + for (;;) { + data = mmio_read_32(PMCTRL_MEDPLLCTRL); + value = 1 << 28; + if ((data & value) == value) + break; + } + + data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); + data = 1 << 10; + mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); +} + +void init_mmc1_pll(void) +{ + uint32_t data; + + /* select SYSPLL as the source of MMC1 */ + /* select SYSPLL as the source of MUX1 (SC_CLK_SEL0) */ + mmio_write_32(PERI_SC_CLK_SEL0, 1 << 11 | 1 << 27); + do { + data = mmio_read_32(PERI_SC_CLK_SEL0); + } while (!(data & (1 << 11))); + /* select MUX1 as the source of MUX2 (SC_CLK_SEL0) */ + mmio_write_32(PERI_SC_CLK_SEL0, 1 << 30); + do { + data = mmio_read_32(PERI_SC_CLK_SEL0); + } while (data & (1 << 14)); + + mmio_write_32(PERI_SC_PERIPH_CLKEN0, (1 << 1)); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (!(data & (1 << 1))); + + data = mmio_read_32(PERI_SC_PERIPH_CLKEN12); + data |= 1 << 2; + mmio_write_32(PERI_SC_PERIPH_CLKEN12, data); + + do { + /* 1.2GHz / 50 = 24MHz */ + mmio_write_32(PERI_SC_CLKCFG8BIT2, 0x31 | (1 << 7)); + data = mmio_read_32(PERI_SC_CLKCFG8BIT2); + } while ((data & 0x31) != 0x31); +} + +void reset_mmc1_clk(void) +{ + unsigned int data; + + /* disable mmc1 bus clock */ + mmio_write_32(PERI_SC_PERIPH_CLKDIS0, PERI_CLK0_MMC1); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (data & PERI_CLK0_MMC1); + /* enable mmc1 bus clock */ + mmio_write_32(PERI_SC_PERIPH_CLKEN0, PERI_CLK0_MMC1); + do { + data = mmio_read_32(PERI_SC_PERIPH_CLKSTAT0); + } while (!(data & PERI_CLK0_MMC1)); + /* reset mmc1 clock domain */ + mmio_write_32(PERI_SC_PERIPH_RSTEN0, PERI_RST0_MMC1); + + /* bypass mmc1 clock phase */ + data = mmio_read_32(PERI_SC_PERIPH_CTRL2); + data |= 3 << 2; + mmio_write_32(PERI_SC_PERIPH_CTRL2, data); + + /* disable low power */ + data = mmio_read_32(PERI_SC_PERIPH_CTRL13); + data |= 1 << 4; + mmio_write_32(PERI_SC_PERIPH_CTRL13, data); + do { + data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); + } while (!(data & PERI_RST0_MMC1)); + + /* unreset mmc0 clock domain */ + mmio_write_32(PERI_SC_PERIPH_RSTDIS0, PERI_RST0_MMC1); + do { + data = mmio_read_32(PERI_SC_PERIPH_RSTSTAT0); + } while (data & PERI_RST0_MMC1); +} + +/* Initialize PLL of both eMMC and SD controllers. */ +void hikey_mmc_pll_init(void) +{ + init_mmc0_pll(); + reset_mmc0_clk(); + init_media_clk(); + + dsb(); + + init_mmc1_pll(); + reset_mmc1_clk(); +} + +void hikey_rtc_init(void) +{ + uint32_t data; + + data = mmio_read_32(AO_SC_PERIPH_CLKEN4); + data |= AO_SC_PERIPH_RSTDIS4_RESET_RTC0_N; + mmio_write_32(AO_SC_PERIPH_CLKEN4, data); +} diff --git a/plat/hisilicon/hikey/hikey_io_storage.c b/plat/hisilicon/hikey/hikey_io_storage.c index 57c66d501..90c2f8165 100644 --- a/plat/hisilicon/hikey/hikey_io_storage.c +++ b/plat/hisilicon/hikey/hikey_io_storage.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -65,10 +65,6 @@ static const io_block_dev_spec_t emmc_dev_spec = { .block_size = EMMC_BLOCK_SIZE, }; -static const io_uuid_spec_t bl2_uuid_spec = { - .uuid = UUID_TRUSTED_BOOT_FIRMWARE_BL2, -}; - static const io_uuid_spec_t bl31_uuid_spec = { .uuid = UUID_EL3_RUNTIME_FIRMWARE_BL31, }; @@ -99,11 +95,6 @@ static const struct plat_io_policy policies[] = { (uintptr_t)&emmc_fip_spec, check_emmc }, - [BL2_IMAGE_ID] = { - &fip_dev_handle, - (uintptr_t)&bl2_uuid_spec, - check_fip - }, [SCP_BL2_IMAGE_ID] = { &fip_dev_handle, (uintptr_t)&scp_bl2_uuid_spec, diff --git a/plat/hisilicon/hikey/hikey_private.h b/plat/hisilicon/hikey/hikey_private.h index da9873495..7654921d6 100644 --- a/plat/hisilicon/hikey/hikey_private.h +++ b/plat/hisilicon/hikey/hikey_private.h @@ -37,6 +37,18 @@ void hikey_init_mmu_el3(unsigned long total_base, void hikey_ddr_init(void); void hikey_io_setup(void); +void hikey_sp804_init(void); +void hikey_gpio_init(void); +void hikey_pmussi_init(void); +void hikey_hi6553_init(void); +void init_mmc0_pll(void); +void reset_mmc0_clk(void); +void init_media_clk(void); +void init_mmc1_pll(void); +void reset_mmc1_clk(void); +void hikey_mmc_pll_init(void); +void hikey_rtc_init(void); + int hikey_get_partition_size(const char *arg, int left, char *response); int hikey_get_partition_type(const char *arg, int left, char *response); diff --git a/plat/hisilicon/hikey/include/platform_def.h b/plat/hisilicon/hikey/include/platform_def.h index 02b756292..9b4f4631c 100644 --- a/plat/hisilicon/hikey/include/platform_def.h +++ b/plat/hisilicon/hikey/include/platform_def.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -80,9 +80,18 @@ /* * BL2 specific defines. + * + * Both loader and BL2 region stay in SRAM. + * Loader is used to switch Hi6220 SoC from 32-bit to 64-bit mode. + * + * ++++++++++ 0xF980_0000 + * + loader + + * ++++++++++ 0xF980_1000 + * + BL2 + + * ++++++++++ 0xF981_8000 */ -#define BL2_BASE (BL1_RW_BASE + 0x8000) /* 0xf981_8000 */ -#define BL2_LIMIT (BL2_BASE + 0x40000) +#define BL2_BASE (BL1_RO_BASE) /* 0xf980_1000 */ +#define BL2_LIMIT (0xF9818000) /* 0xf981_8000 */ /* * SCP_BL2 specific defines. @@ -97,8 +106,8 @@ /* * BL31 specific defines. */ -#define BL31_BASE BL2_LIMIT /* 0xf985_8000 */ -#define BL31_LIMIT 0xF9898000 +#define BL31_BASE (0xF9858000) /* 0xf985_8000 */ +#define BL31_LIMIT (0xF9898000) /* * BL3-2 specific defines. @@ -113,13 +122,11 @@ #define BL32_DRAM_BASE DDR_SEC_BASE #define BL32_DRAM_LIMIT (DDR_SEC_BASE+DDR_SEC_SIZE) -#if LOAD_IMAGE_V2 #ifdef SPD_opteed /* Load pageable part of OP-TEE at end of allocated DRAM space for BL32 */ #define HIKEY_OPTEE_PAGEABLE_LOAD_BASE (BL32_DRAM_LIMIT - HIKEY_OPTEE_PAGEABLE_LOAD_SIZE) /* 0x3FC0_0000 */ #define HIKEY_OPTEE_PAGEABLE_LOAD_SIZE 0x400000 /* 4MB */ #endif -#endif #if (HIKEY_TSP_RAM_LOCATION_ID == HIKEY_DRAM_ID) #define TSP_SEC_MEM_BASE BL32_DRAM_BASE @@ -142,7 +149,7 @@ #endif /* SPD_none */ #endif -#define NS_BL1U_BASE (BL2_BASE) +#define NS_BL1U_BASE (0xf9818000) #define NS_BL1U_SIZE (0x00010000) #define NS_BL1U_LIMIT (NS_BL1U_BASE + NS_BL1U_SIZE) @@ -160,15 +167,7 @@ #endif #ifdef IMAGE_BL2 -#if LOAD_IMAGE_V2 -#ifdef SPD_opteed #define MAX_XLAT_TABLES 4 -#else -#define MAX_XLAT_TABLES 3 -#endif -#else -#define MAX_XLAT_TABLES 3 -#endif #endif #define MAX_MMAP_REGIONS 16 diff --git a/plat/hisilicon/hikey/platform.mk b/plat/hisilicon/hikey/platform.mk index 366291405..38eb148cf 100644 --- a/plat/hisilicon/hikey/platform.mk +++ b/plat/hisilicon/hikey/platform.mk @@ -7,6 +7,9 @@ # Enable version2 of image loading LOAD_IMAGE_V2 := 1 +# Non-TF Boot ROM +BL2_AT_EL3 := 1 + # On Hikey, the TSP can execute from TZC secure area in DRAM (default) # or SRAM. HIKEY_TSP_RAM_LOCATION ?= dram @@ -67,32 +70,34 @@ BL1_SOURCES += bl1/tbbr/tbbr_img_desc.c \ lib/cpus/aarch64/cortex_a53.S \ plat/hisilicon/hikey/aarch64/hikey_helpers.S \ plat/hisilicon/hikey/hikey_bl1_setup.c \ + plat/hisilicon/hikey/hikey_bl_common.c \ plat/hisilicon/hikey/hikey_io_storage.c -BL2_SOURCES += drivers/arm/sp804/sp804_delay_timer.c \ +BL2_SOURCES += common/desc_image_load.c \ + drivers/arm/pl061/pl061_gpio.c \ + drivers/arm/sp804/sp804_delay_timer.c \ drivers/delay_timer/delay_timer.c \ + drivers/gpio/gpio.c \ drivers/io/io_block.c \ drivers/io/io_fip.c \ drivers/io/io_storage.c \ drivers/emmc/emmc.c \ drivers/synopsys/emmc/dw_mmc.c \ + lib/cpus/aarch64/cortex_a53.S \ plat/hisilicon/hikey/aarch64/hikey_helpers.S \ + plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c \ plat/hisilicon/hikey/hikey_bl2_setup.c \ + plat/hisilicon/hikey/hikey_bl_common.c \ plat/hisilicon/hikey/hikey_security.c \ plat/hisilicon/hikey/hikey_ddr.c \ + plat/hisilicon/hikey/hikey_image_load.c \ plat/hisilicon/hikey/hikey_io_storage.c \ plat/hisilicon/hikey/hisi_dvfs.c \ plat/hisilicon/hikey/hisi_mcu.c -ifeq (${LOAD_IMAGE_V2},1) -BL2_SOURCES += plat/hisilicon/hikey/hikey_bl2_mem_params_desc.c \ - plat/hisilicon/hikey/hikey_image_load.c \ - common/desc_image_load.c - ifeq (${SPD},opteed) BL2_SOURCES += lib/optee/optee_utils.c endif -endif HIKEY_GIC_SOURCES := drivers/arm/gic/common/gic_common.c \ drivers/arm/gic/v2/gicv2_main.c \ diff --git a/plat/hisilicon/hikey960/aarch64/hikey960_common.c b/plat/hisilicon/hikey960/aarch64/hikey960_common.c index b1020a683..67571ff8a 100644 --- a/plat/hisilicon/hikey960/aarch64/hikey960_common.c +++ b/plat/hisilicon/hikey960/aarch64/hikey960_common.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -18,7 +18,7 @@ #include "../hikey960_private.h" #define MAP_DDR MAP_REGION_FLAT(DDR_BASE, \ - DDR_SIZE, \ + DDR_SIZE - DDR_SEC_SIZE, \ MT_MEMORY | MT_RW | MT_NS) #define MAP_DEVICE MAP_REGION_FLAT(DEVICE_BASE, \ @@ -41,15 +41,6 @@ TSP_SEC_MEM_SIZE, \ MT_MEMORY | MT_RW | MT_SECURE) -#if LOAD_IMAGE_V2 -#ifdef SPD_opteed -#define MAP_OPTEE_PAGEABLE MAP_REGION_FLAT( \ - HIKEY960_OPTEE_PAGEABLE_LOAD_BASE, \ - HIKEY960_OPTEE_PAGEABLE_LOAD_SIZE, \ - MT_MEMORY | MT_RW | MT_SECURE) -#endif -#endif - /* * Table of regions for different BL stages to map using the MMU. * This doesn't include Trusted RAM as the 'mem_layout' argument passed to @@ -70,11 +61,6 @@ static const mmap_region_t hikey960_mmap[] = { MAP_DDR, MAP_DEVICE, MAP_TSP_MEM, -#if LOAD_IMAGE_V2 -#ifdef SPD_opteed - MAP_OPTEE_PAGEABLE, -#endif -#endif {0} }; #endif diff --git a/plat/hisilicon/hikey960/drivers/pwrc/hisi_pwrc.c b/plat/hisilicon/hikey960/drivers/pwrc/hisi_pwrc.c index 9fdc3e746..45fcd42b4 100644 --- a/plat/hisilicon/hikey960/drivers/pwrc/hisi_pwrc.c +++ b/plat/hisilicon/hikey960/drivers/pwrc/hisi_pwrc.c @@ -287,9 +287,9 @@ void hisi_enable_pdc(unsigned int cluster) mmio_write_32((uintptr_t)pdc_base_addr, 0x1); } -static inline void hisi_pdc_set_intmask(void *pdc_base_addr, - unsigned int core, - enum pdc_finish_int_mask intmask) +void hisi_pdc_set_intmask(void *pdc_base_addr, + unsigned int core, + enum pdc_finish_int_mask intmask) { unsigned int val; diff --git a/plat/hisilicon/hikey960/hikey960_bl1_setup.c b/plat/hisilicon/hikey960/hikey960_bl1_setup.c index 11f143a82..9cadba0bb 100644 --- a/plat/hisilicon/hikey960/hikey960_bl1_setup.c +++ b/plat/hisilicon/hikey960/hikey960_bl1_setup.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -74,7 +74,6 @@ meminfo_t *bl1_plat_sec_mem_layout(void) return &bl1_tzram_layout; } -#if LOAD_IMAGE_V2 /******************************************************************************* * Function that takes a memory layout into which BL2 has been loaded and * populates a new memory layout for BL2 that ensures that BL1's data sections @@ -96,7 +95,6 @@ void bl1_init_bl2_mem_layout(const meminfo_t *bl1_mem_layout, flush_dcache_range((unsigned long)bl2_mem_layout, sizeof(meminfo_t)); } -#endif /* LOAD_IMAGE_V2 */ /* * Perform any BL1 specific platform actions. @@ -118,16 +116,6 @@ void bl1_early_platform_setup(void) bl1_tzram_layout.total_base = BL1_RW_BASE; bl1_tzram_layout.total_size = BL1_RW_SIZE; -#if !LOAD_IMAGE_V2 - /* Calculate how much RAM BL1 is using and how much remains free */ - bl1_tzram_layout.free_base = BL1_RW_BASE; - bl1_tzram_layout.free_size = BL1_RW_SIZE; - reserve_mem(&bl1_tzram_layout.free_base, - &bl1_tzram_layout.free_size, - BL1_RAM_BASE, - BL1_RAM_LIMIT - BL1_RAM_BASE); /* bl1_size */ -#endif /* LOAD_IMAGE_V2 */ - INFO("BL1: 0x%lx - 0x%lx [size = %lu]\n", BL1_RAM_BASE, BL1_RAM_LIMIT, BL1_RAM_LIMIT - BL1_RAM_BASE); /* bl1_size */ } @@ -147,385 +135,6 @@ void bl1_plat_arch_setup(void) BL1_COHERENT_RAM_LIMIT); } -static void hikey960_clk_init(void) -{ - /* change ldi0 sel to ppll2 */ - mmio_write_32(0xfff350b4, 0xf0002000); - /* ldi0 20' */ - mmio_write_32(0xfff350bc, 0xfc004c00); -} - -static void hikey960_pmu_init(void) -{ - /* clear np_xo_abb_dig_START bit in PMIC_CLK_TOP_CTRL7 register */ - mmio_clrbits_32(PMU_SSI0_CLK_TOP_CTRL7_REG, NP_XO_ABB_DIG); -} - -static void hikey960_enable_ppll3(void) -{ - /* enable ppll3 */ - mmio_write_32(PMC_PPLL3_CTRL0_REG, 0x4904305); - mmio_write_32(PMC_PPLL3_CTRL1_REG, 0x2300000); - mmio_write_32(PMC_PPLL3_CTRL1_REG, 0x6300000); -} - -static void bus_idle_clear(unsigned int value) -{ - unsigned int pmc_value, value1, value2; - int timeout = 100; - - pmc_value = value << 16; - pmc_value &= ~value; - mmio_write_32(PMC_NOC_POWER_IDLEREQ_REG, pmc_value); - - for (;;) { - value1 = (unsigned int)mmio_read_32(PMC_NOC_POWER_IDLEACK_REG); - value2 = (unsigned int)mmio_read_32(PMC_NOC_POWER_IDLE_REG); - if (((value1 & value) == 0) && ((value2 & value) == 0)) - break; - udelay(1); - timeout--; - if (timeout <= 0) { - WARN("%s timeout\n", __func__); - break; - } - } -} - -static void set_vivobus_power_up(void) -{ - /* clk enable */ - mmio_write_32(CRG_CLKDIV20_REG, 0x00020002); - mmio_write_32(CRG_PEREN0_REG, 0x00001000); -} - -static void set_dss_power_up(void) -{ - /* set edc0 133MHz = 1600MHz / 12 */ - mmio_write_32(CRG_CLKDIV5_REG, 0x003f000b); - /* set ldi0 ppl0 */ - mmio_write_32(CRG_CLKDIV3_REG, 0xf0001000); - /* set ldi0 133MHz, 1600MHz / 12 */ - mmio_write_32(CRG_CLKDIV5_REG, 0xfc002c00); - /* mtcmos on */ - mmio_write_32(CRG_PERPWREN_REG, 0x00000020); - udelay(100); - /* DISP CRG */ - mmio_write_32(CRG_PERRSTDIS4_REG, 0x00000010); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x01400140); - mmio_write_32(CRG_PEREN0_REG, 0x00002000); - mmio_write_32(CRG_PEREN3_REG, 0x0003b000); - udelay(1); - /* clk disable */ - mmio_write_32(CRG_PERDIS3_REG, 0x0003b000); - mmio_write_32(CRG_PERDIS0_REG, 0x00002000); - mmio_write_32(CRG_CLKDIV18_REG, 0x01400000); - udelay(1); - /* iso disable */ - mmio_write_32(CRG_ISODIS_REG, 0x00000040); - /* unreset */ - mmio_write_32(CRG_PERRSTDIS4_REG, 0x00000006); - mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000c00); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x01400140); - mmio_write_32(CRG_PEREN0_REG, 0x00002000); - mmio_write_32(CRG_PEREN3_REG, 0x0003b000); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_DSS); - /* set edc0 400MHz for 2K 1600MHz / 4 */ - mmio_write_32(CRG_CLKDIV5_REG, 0x003f0003); - /* set ldi 266MHz, 1600MHz / 6 */ - mmio_write_32(CRG_CLKDIV5_REG, 0xfc001400); -} - -static void set_vcodec_power_up(void) -{ - /* clk enable */ - mmio_write_32(CRG_CLKDIV20_REG, 0x00040004); - mmio_write_32(CRG_PEREN0_REG, 0x00000060); - mmio_write_32(CRG_PEREN2_REG, 0x10000000); - /* unreset */ - mmio_write_32(CRG_PERRSTDIS0_REG, 0x00000018); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VCODEC); -} - -static void set_vdec_power_up(void) -{ - /* mtcmos on */ - mmio_write_32(CRG_PERPWREN_REG, 0x00000004); - udelay(100); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x80008000); - mmio_write_32(CRG_PEREN2_REG, 0x20080000); - mmio_write_32(CRG_PEREN3_REG, 0x00000800); - udelay(1); - /* clk disable */ - mmio_write_32(CRG_PERDIS3_REG, 0x00000800); - mmio_write_32(CRG_PERDIS2_REG, 0x20080000); - mmio_write_32(CRG_CLKDIV18_REG, 0x80000000); - udelay(1); - /* iso disable */ - mmio_write_32(CRG_ISODIS_REG, 0x00000004); - /* unreset */ - mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000200); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x80008000); - mmio_write_32(CRG_PEREN2_REG, 0x20080000); - mmio_write_32(CRG_PEREN3_REG, 0x00000800); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VDEC); -} - -static void set_venc_power_up(void) -{ - /* set venc ppll3 */ - mmio_write_32(CRG_CLKDIV8_REG, 0x18001000); - /* set venc 258MHz, 1290MHz / 5 */ - mmio_write_32(CRG_CLKDIV8_REG, 0x07c00100); - /* mtcmos on */ - mmio_write_32(CRG_PERPWREN_REG, 0x00000002); - udelay(100); - /* clk enable */ - mmio_write_32(CRG_CLKDIV19_REG, 0x00010001); - mmio_write_32(CRG_PEREN2_REG, 0x40000100); - mmio_write_32(CRG_PEREN3_REG, 0x00000400); - udelay(1); - /* clk disable */ - mmio_write_32(CRG_PERDIS3_REG, 0x00000400); - mmio_write_32(CRG_PERDIS2_REG, 0x40000100); - mmio_write_32(CRG_CLKDIV19_REG, 0x00010000); - udelay(1); - /* iso disable */ - mmio_write_32(CRG_ISODIS_REG, 0x00000002); - /* unreset */ - mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000100); - /* clk enable */ - mmio_write_32(CRG_CLKDIV19_REG, 0x00010001); - mmio_write_32(CRG_PEREN2_REG, 0x40000100); - mmio_write_32(CRG_PEREN3_REG, 0x00000400); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VENC); - /* set venc 645MHz, 1290MHz / 2 */ - mmio_write_32(CRG_CLKDIV8_REG, 0x07c00040); -} - -static void set_isp_power_up(void) -{ - /* mtcmos on */ - mmio_write_32(CRG_PERPWREN_REG, 0x00000001); - udelay(100); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x70007000); - mmio_write_32(CRG_CLKDIV20_REG, 0x00100010); - mmio_write_32(CRG_PEREN5_REG, 0x01000010); - mmio_write_32(CRG_PEREN3_REG, 0x0bf00000); - udelay(1); - /* clk disable */ - mmio_write_32(CRG_PERDIS5_REG, 0x01000010); - mmio_write_32(CRG_PERDIS3_REG, 0x0bf00000); - mmio_write_32(CRG_CLKDIV18_REG, 0x70000000); - mmio_write_32(CRG_CLKDIV20_REG, 0x00100000); - udelay(1); - /* iso disable */ - mmio_write_32(CRG_ISODIS_REG, 0x00000001); - /* unreset */ - mmio_write_32(CRG_ISP_SEC_RSTDIS_REG, 0x0000002f); - /* clk enable */ - mmio_write_32(CRG_CLKDIV18_REG, 0x70007000); - mmio_write_32(CRG_CLKDIV20_REG, 0x00100010); - mmio_write_32(CRG_PEREN5_REG, 0x01000010); - mmio_write_32(CRG_PEREN3_REG, 0x0bf00000); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_ISP); - /* csi clk enable */ - mmio_write_32(CRG_PEREN3_REG, 0x00700000); -} - -static void set_ivp_power_up(void) -{ - /* set ivp ppll0 */ - mmio_write_32(CRG_CLKDIV0_REG, 0xc0000000); - /* set ivp 267MHz, 1600MHz / 6 */ - mmio_write_32(CRG_CLKDIV0_REG, 0x3c001400); - /* mtcmos on */ - mmio_write_32(CRG_PERPWREN_REG, 0x00200000); - udelay(100); - /* IVP CRG unreset */ - mmio_write_32(CRG_IVP_SEC_RSTDIS_REG, 0x00000001); - /* clk enable */ - mmio_write_32(CRG_CLKDIV20_REG, 0x02000200); - mmio_write_32(CRG_PEREN4_REG, 0x000000a8); - udelay(1); - /* clk disable */ - mmio_write_32(CRG_PERDIS4_REG, 0x000000a8); - mmio_write_32(CRG_CLKDIV20_REG, 0x02000000); - udelay(1); - /* iso disable */ - mmio_write_32(CRG_ISODIS_REG, 0x01000000); - /* unreset */ - mmio_write_32(CRG_IVP_SEC_RSTDIS_REG, 0x00000002); - /* clk enable */ - mmio_write_32(CRG_CLKDIV20_REG, 0x02000200); - mmio_write_32(CRG_PEREN4_REG, 0x000000a8); - /* bus idle clear */ - bus_idle_clear(PMC_NOC_POWER_IDLEREQ_IVP); - /* set ivp 533MHz, 1600MHz / 3 */ - mmio_write_32(CRG_CLKDIV0_REG, 0x3c000800); -} - -static void set_audio_power_up(void) -{ - unsigned int ret; - int timeout = 100; - /* mtcmos on */ - mmio_write_32(SCTRL_SCPWREN_REG, 0x00000001); - udelay(100); - /* clk enable */ - mmio_write_32(CRG_CLKDIV19_REG, 0x80108010); - mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010001); - mmio_write_32(SCTRL_SCPEREN0_REG, 0x0c000000); - mmio_write_32(CRG_PEREN0_REG, 0x04000000); - mmio_write_32(CRG_PEREN5_REG, 0x00000080); - mmio_write_32(SCTRL_SCPEREN1_REG, 0x0000000f); - udelay(1); - /* clk disable */ - mmio_write_32(SCTRL_SCPERDIS1_REG, 0x0000000f); - mmio_write_32(SCTRL_SCPERDIS0_REG, 0x0c000000); - mmio_write_32(CRG_PERDIS5_REG, 0x00000080); - mmio_write_32(CRG_PERDIS0_REG, 0x04000000); - mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010000); - mmio_write_32(CRG_CLKDIV19_REG, 0x80100000); - udelay(1); - /* iso disable */ - mmio_write_32(SCTRL_SCISODIS_REG, 0x00000001); - udelay(1); - /* unreset */ - mmio_write_32(SCTRL_PERRSTDIS1_SEC_REG, 0x00000001); - mmio_write_32(SCTRL_SCPERRSTDIS0_REG, 0x00000780); - /* clk enable */ - mmio_write_32(CRG_CLKDIV19_REG, 0x80108010); - mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010001); - mmio_write_32(SCTRL_SCPEREN0_REG, 0x0c000000); - mmio_write_32(CRG_PEREN0_REG, 0x04000000); - mmio_write_32(CRG_PEREN5_REG, 0x00000080); - mmio_write_32(SCTRL_SCPEREN1_REG, 0x0000000f); - /* bus idle clear */ - mmio_write_32(SCTRL_SCPERCTRL7_REG, 0x00040000); - for (;;) { - ret = mmio_read_32(SCTRL_SCPERSTAT6_REG); - if (((ret & (1 << 5)) == 0) && ((ret & (1 << 8)) == 0)) - break; - udelay(1); - timeout--; - if (timeout <= 0) { - WARN("%s timeout\n", __func__); - break; - } - } - mmio_write_32(ASP_CFG_MMBUF_CTRL_REG, 0x00ff0000); -} - -static void set_pcie_power_up(void) -{ - /* mtcmos on */ - mmio_write_32(SCTRL_SCPWREN_REG, 0x00000010); - udelay(100); - /* clk enable */ - mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000800); - mmio_write_32(SCTRL_SCPEREN2_REG, 0x00104000); - mmio_write_32(CRG_PEREN7_REG, 0x000003a0); - udelay(1); - /* clk disable */ - mmio_write_32(SCTRL_SCPERDIS2_REG, 0x00104000); - mmio_write_32(CRG_PERDIS7_REG, 0x000003a0); - mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000000); - udelay(1); - /* iso disable */ - mmio_write_32(SCTRL_SCISODIS_REG, 0x00000030); - /* unreset */ - mmio_write_32(CRG_PERRSTDIS3_REG, 0x8c000000); - /* clk enable */ - mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000800); - mmio_write_32(SCTRL_SCPEREN2_REG, 0x00104000); - mmio_write_32(CRG_PEREN7_REG, 0x000003a0); -} - -static void ispfunc_enable(void) -{ - /* enable ispfunc. Otherwise powerup isp_srt causes exception. */ - mmio_write_32(0xfff35000, 0x00000008); - mmio_write_32(0xfff35460, 0xc004ffff); - mmio_write_32(0xfff35030, 0x02000000); - mdelay(10); -} - -static void isps_control_clock(int flag) -{ - unsigned int ret; - - /* flag: 0 -- disable clock, 1 -- enable clock */ - if (flag) { - ret = mmio_read_32(0xe8420364); - ret |= 1; - mmio_write_32(0xe8420364, ret); - } else { - ret = mmio_read_32(0xe8420364); - ret &= ~1; - mmio_write_32(0xe8420364, ret); - } -} - -static void set_isp_srt_power_up(void) -{ - unsigned int ret; - - ispfunc_enable(); - /* reset */ - mmio_write_32(0xe8420374, 0x00000001); - mmio_write_32(0xe8420350, 0x00000000); - mmio_write_32(0xe8420358, 0x00000000); - /* mtcmos on */ - mmio_write_32(0xfff35150, 0x00400000); - udelay(100); - /* clk enable */ - isps_control_clock(1); - udelay(1); - isps_control_clock(0); - udelay(1); - /* iso disable */ - mmio_write_32(0xfff35148, 0x08000000); - /* unreset */ - ret = mmio_read_32(0xe8420374); - ret &= ~0x1; - mmio_write_32(0xe8420374, ret); - /* clk enable */ - isps_control_clock(1); - /* enable clock gating for accessing csi registers */ - mmio_write_32(0xe8420010, ~0); -} - -static void hikey960_regulator_enable(void) -{ - set_vivobus_power_up(); - hikey960_enable_ppll3(); - set_dss_power_up(); - set_vcodec_power_up(); - set_vdec_power_up(); - set_venc_power_up(); - set_isp_power_up(); - set_ivp_power_up(); - set_audio_power_up(); - set_pcie_power_up(); - set_isp_srt_power_up(); - - /* set ISP_CORE_CTRL_S to unsecure mode */ - mmio_write_32(0xe8583800, 0x7); - /* set ISP_SUB_CTRL_S to unsecure mode */ - mmio_write_32(0xe8583804, 0xf); -} - static void hikey960_ufs_reset(void) { unsigned int data, mask; @@ -601,56 +210,6 @@ static void hikey960_ufs_init(void) dw_ufs_init(&ufs_params); } -static void hikey960_tzc_init(void) -{ - mmio_write_32(TZC_EN0_REG, 0x7fbff066); - mmio_write_32(TZC_EN1_REG, 0xfffff5fc); - mmio_write_32(TZC_EN2_REG, 0x0007005c); - mmio_write_32(TZC_EN3_REG, 0x37030700); - mmio_write_32(TZC_EN4_REG, 0xf63fefae); - mmio_write_32(TZC_EN5_REG, 0x000410fd); - mmio_write_32(TZC_EN6_REG, 0x0063ff68); - mmio_write_32(TZC_EN7_REG, 0x030000f3); - mmio_write_32(TZC_EN8_REG, 0x00000007); -} - -static void hikey960_peri_init(void) -{ - /* unreset */ - mmio_setbits_32(CRG_PERRSTDIS4_REG, 1); -} - -static void hikey960_pinmux_init(void) -{ - unsigned int id; - - hikey960_read_boardid(&id); - if (id == 5301) { - /* hikey960 hardware v2 */ - /* GPIO150: LED */ - mmio_write_32(IOMG_FIX_006_REG, 0); - /* GPIO151: LED */ - mmio_write_32(IOMG_FIX_007_REG, 0); - /* GPIO189: LED */ - mmio_write_32(IOMG_AO_011_REG, 0); - /* GPIO190: LED */ - mmio_write_32(IOMG_AO_012_REG, 0); - /* GPIO46 */ - mmio_write_32(IOMG_044_REG, 0); - /* GPIO202 */ - mmio_write_32(IOMG_AO_023_REG, 0); - /* GPIO206 */ - mmio_write_32(IOMG_AO_026_REG, 0); - /* GPIO219 - PD pullup */ - mmio_write_32(IOMG_AO_039_REG, 0); - mmio_write_32(IOCG_AO_043_REG, 1 << 0); - } - /* GPIO005 - PMU SSI, 10mA */ - mmio_write_32(IOCG_006_REG, 2 << 4); - /* GPIO213 - PCIE_CLKREQ_N */ - mmio_write_32(IOMG_AO_033_REG, 1); -} - /* * Function which will perform any remaining platform-specific setup that can * occur after the MMU and data cache have been enabled. @@ -680,9 +239,6 @@ unsigned int bl1_plat_get_next_image_id(void) case BOOT_MODE_RECOVERY: ret = NS_BL1U_IMAGE_ID; break; - case BOOT_MODE_NORMAL: - ret = BL2_IMAGE_ID; - break; default: WARN("Invalid boot mode is found:%d\n", mode); panic(); @@ -709,8 +265,8 @@ void bl1_plat_set_ep_info(unsigned int image_id, unsigned int data = 0; uintptr_t tmp = HIKEY960_NS_TMP_OFFSET; - if (image_id == BL2_IMAGE_ID) - return; + if (image_id != NS_BL1U_IMAGE_ID) + panic(); /* Copy NS BL1U from 0x1AC1_8000 to 0x1AC9_8000 */ memcpy((void *)tmp, (void *)HIKEY960_NS_IMAGE_OFFSET, NS_BL1U_SIZE); diff --git a/plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c b/plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c index b59f89708..2944b1f7c 100644 --- a/plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c +++ b/plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016-2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -28,7 +28,7 @@ static bl_mem_params_node_t bl2_mem_params_descs[] = { VERSION_2, entry_point_info_t, SECURE | NON_EXECUTABLE), SET_STATIC_PARAM_HEAD(image_info, PARAM_IMAGE_BINARY, - VERSION_2, image_info_t, 0), + VERSION_2, image_info_t, IMAGE_ATTRIB_PLAT_SETUP), .image_info.image_base = SCP_BL2_BASE, .image_info.image_max_size = SCP_BL2_SIZE, diff --git a/plat/hisilicon/hikey960/hikey960_bl2_setup.c b/plat/hisilicon/hikey960/hikey960_bl2_setup.c index b50ed87f0..11bbf9e15 100644 --- a/plat/hisilicon/hikey960/hikey960_bl2_setup.c +++ b/plat/hisilicon/hikey960/hikey960_bl2_setup.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -9,16 +9,16 @@ #include <bl_common.h> #include <console.h> #include <debug.h> +#include <delay_timer.h> #include <desc_image_load.h> +#include <dw_ufs.h> #include <errno.h> #include <generic_delay_timer.h> #include <hi3660.h> #include <mmio.h> -#if LOAD_IMAGE_V2 #ifdef SPD_opteed #include <optee_utils.h> #endif -#endif #include <platform_def.h> #include <string.h> #include <ufs.h> @@ -35,6 +35,8 @@ #define BL2_RO_BASE (unsigned long)(&__RO_START__) #define BL2_RO_LIMIT (unsigned long)(&__RO_END__) +#define BL2_RW_BASE (BL2_RO_LIMIT) + /* * The next 2 constants identify the extents of the coherent memory region. * These addresses are used by the MMU setup code and therefore they must be @@ -45,100 +47,20 @@ #define BL2_COHERENT_RAM_BASE (unsigned long)(&__COHERENT_RAM_START__) #define BL2_COHERENT_RAM_LIMIT (unsigned long)(&__COHERENT_RAM_END__) -static meminfo_t bl2_tzram_layout __aligned(CACHE_WRITEBACK_GRANULE); - -#if !LOAD_IMAGE_V2 - -/******************************************************************************* - * This structure represents the superset of information that is passed to - * BL31, e.g. while passing control to it from BL2, bl31_params - * and other platform specific params - ******************************************************************************/ -typedef struct bl2_to_bl31_params_mem { - bl31_params_t bl31_params; - image_info_t bl31_image_info; - image_info_t bl32_image_info; - image_info_t bl33_image_info; - entry_point_info_t bl33_ep_info; - entry_point_info_t bl32_ep_info; - entry_point_info_t bl31_ep_info; -} bl2_to_bl31_params_mem_t; - -static bl2_to_bl31_params_mem_t bl31_params_mem; - -meminfo_t *bl2_plat_sec_mem_layout(void) -{ - return &bl2_tzram_layout; -} - -bl31_params_t *bl2_plat_get_bl31_params(void) -{ - bl31_params_t *bl2_to_bl31_params = NULL; - - /* - * Initialise the memory for all the arguments that needs to - * be passed to BL3-1 - */ - memset(&bl31_params_mem, 0, sizeof(bl2_to_bl31_params_mem_t)); - - /* Assign memory for TF related information */ - bl2_to_bl31_params = &bl31_params_mem.bl31_params; - SET_PARAM_HEAD(bl2_to_bl31_params, PARAM_BL31, VERSION_1, 0); - - /* Fill BL3-1 related information */ - bl2_to_bl31_params->bl31_image_info = &bl31_params_mem.bl31_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl31_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); - - /* Fill BL3-2 related information if it exists */ -#ifdef BL32_BASE - bl2_to_bl31_params->bl32_ep_info = &bl31_params_mem.bl32_ep_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl32_ep_info, PARAM_EP, - VERSION_1, 0); - bl2_to_bl31_params->bl32_image_info = &bl31_params_mem.bl32_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl32_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); -#endif - - /* Fill BL3-3 related information */ - bl2_to_bl31_params->bl33_ep_info = &bl31_params_mem.bl33_ep_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl33_ep_info, - PARAM_EP, VERSION_1, 0); - - /* BL3-3 expects to receive the primary CPU MPID (through x0) */ - bl2_to_bl31_params->bl33_ep_info->args.arg0 = 0xffff & read_mpidr(); - - bl2_to_bl31_params->bl33_image_info = &bl31_params_mem.bl33_image_info; - SET_PARAM_HEAD(bl2_to_bl31_params->bl33_image_info, PARAM_IMAGE_BINARY, - VERSION_1, 0); - - return bl2_to_bl31_params; -} - -/******************************************************************************* - * Populate the extents of memory available for loading SCP_BL2 (if used), - * i.e. anywhere in trusted RAM as long as it doesn't overwrite BL2. - ******************************************************************************/ -void bl2_plat_get_scp_bl2_meminfo(meminfo_t *scp_bl2_meminfo) -{ - hikey960_init_ufs(); - hikey960_io_setup(); - - *scp_bl2_meminfo = bl2_tzram_layout; -} -#endif /* LOAD_IMAGE_V2 */ - +static meminfo_t bl2_el3_tzram_layout; extern int load_lpm3(void); +enum { + BOOT_MODE_RECOVERY = 0, + BOOT_MODE_NORMAL, + BOOT_MODE_MASK = 1, +}; + /******************************************************************************* * Transfer SCP_BL2 from Trusted RAM using the SCP Download protocol. * Return 0 on success, -1 otherwise. ******************************************************************************/ -#if LOAD_IMAGE_V2 int plat_hikey960_bl2_handle_scp_bl2(image_info_t *scp_bl2_image_info) -#else -int bl2_plat_handle_scp_bl2(image_info_t *scp_bl2_image_info) -#endif { int i; int *buf; @@ -174,16 +96,77 @@ int bl2_plat_handle_scp_bl2(image_info_t *scp_bl2_image_info) return 0; } -void hikey960_init_ufs(void) +static void hikey960_ufs_reset(void) { - ufs_params_t ufs_params; + unsigned int data, mask; + + mmio_write_32(CRG_PERDIS7_REG, 1 << 14); + mmio_clrbits_32(UFS_SYS_PHY_CLK_CTRL_REG, BIT_SYSCTRL_REF_CLOCK_EN); + do { + data = mmio_read_32(UFS_SYS_PHY_CLK_CTRL_REG); + } while (data & BIT_SYSCTRL_REF_CLOCK_EN); + /* use abb clk */ + mmio_clrbits_32(UFS_SYS_UFS_SYSCTRL_REG, BIT_UFS_REFCLK_SRC_SE1); + mmio_clrbits_32(UFS_SYS_PHY_ISO_EN_REG, BIT_UFS_REFCLK_ISO_EN); + mmio_write_32(PCTRL_PERI_CTRL3_REG, (1 << 0) | (1 << 16)); + mdelay(1); + mmio_write_32(CRG_PEREN7_REG, 1 << 14); + mmio_setbits_32(UFS_SYS_PHY_CLK_CTRL_REG, BIT_SYSCTRL_REF_CLOCK_EN); + + mmio_write_32(CRG_PERRSTEN3_REG, PERI_UFS_BIT); + do { + data = mmio_read_32(CRG_PERRSTSTAT3_REG); + } while ((data & PERI_UFS_BIT) == 0); + mmio_setbits_32(UFS_SYS_PSW_POWER_CTRL_REG, BIT_UFS_PSW_MTCMOS_EN); + mdelay(1); + mmio_setbits_32(UFS_SYS_HC_LP_CTRL_REG, BIT_SYSCTRL_PWR_READY); + mmio_write_32(UFS_SYS_UFS_DEVICE_RESET_CTRL_REG, + MASK_UFS_DEVICE_RESET); + /* clear SC_DIV_UFS_PERIBUS */ + mask = SC_DIV_UFS_PERIBUS << 16; + mmio_write_32(CRG_CLKDIV17_REG, mask); + /* set SC_DIV_UFSPHY_CFG(3) */ + mask = SC_DIV_UFSPHY_CFG_MASK << 16; + data = SC_DIV_UFSPHY_CFG(3); + mmio_write_32(CRG_CLKDIV16_REG, mask | data); + data = mmio_read_32(UFS_SYS_PHY_CLK_CTRL_REG); + data &= ~MASK_SYSCTRL_CFG_CLOCK_FREQ; + data |= 0x39; + mmio_write_32(UFS_SYS_PHY_CLK_CTRL_REG, data); + mmio_clrbits_32(UFS_SYS_PHY_CLK_CTRL_REG, MASK_SYSCTRL_REF_CLOCK_SEL); + mmio_setbits_32(UFS_SYS_CLOCK_GATE_BYPASS_REG, + MASK_UFS_CLK_GATE_BYPASS); + mmio_setbits_32(UFS_SYS_UFS_SYSCTRL_REG, MASK_UFS_SYSCTRL_BYPASS); + + mmio_setbits_32(UFS_SYS_PSW_CLK_CTRL_REG, BIT_SYSCTRL_PSW_CLK_EN); + mmio_clrbits_32(UFS_SYS_PSW_POWER_CTRL_REG, BIT_UFS_PSW_ISO_CTRL); + mmio_clrbits_32(UFS_SYS_PHY_ISO_EN_REG, BIT_UFS_PHY_ISO_CTRL); + mmio_clrbits_32(UFS_SYS_HC_LP_CTRL_REG, BIT_SYSCTRL_LP_ISOL_EN); + mmio_write_32(CRG_PERRSTDIS3_REG, PERI_ARST_UFS_BIT); + mmio_setbits_32(UFS_SYS_RESET_CTRL_EN_REG, BIT_SYSCTRL_LP_RESET_N); + mdelay(1); + mmio_write_32(UFS_SYS_UFS_DEVICE_RESET_CTRL_REG, + MASK_UFS_DEVICE_RESET | BIT_UFS_DEVICE_RESET); + mdelay(20); + mmio_write_32(UFS_SYS_UFS_DEVICE_RESET_CTRL_REG, + 0x03300330); + + mmio_write_32(CRG_PERRSTDIS3_REG, PERI_UFS_BIT); + do { + data = mmio_read_32(CRG_PERRSTSTAT3_REG); + } while (data & PERI_UFS_BIT); +} + +static void hikey960_init_ufs(void) +{ + dw_ufs_params_t ufs_params; memset(&ufs_params, 0, sizeof(ufs_params_t)); ufs_params.reg_base = UFS_REG_BASE; ufs_params.desc_base = HIKEY960_UFS_DESC_BASE; ufs_params.desc_size = HIKEY960_UFS_DESC_SIZE; - ufs_params.flags = UFS_FLAGS_SKIPINIT; - ufs_init(NULL, &ufs_params); + hikey960_ufs_reset(); + dw_ufs_init(&ufs_params); } /******************************************************************************* @@ -238,7 +221,6 @@ uint32_t hikey960_get_spsr_for_bl33_entry(void) } #endif /* AARCH32 */ -#if LOAD_IMAGE_V2 int hikey960_bl2_handle_post_image_load(unsigned int image_id) { int err = 0; @@ -299,101 +281,8 @@ int bl2_plat_handle_post_image_load(unsigned int image_id) return hikey960_bl2_handle_post_image_load(image_id); } -#else /* LOAD_IMAGE_V2 */ - -struct entry_point_info *bl2_plat_get_bl31_ep_info(void) -{ -#if DEBUG - bl31_params_mem.bl31_ep_info.args.arg1 = HIKEY960_BL31_PLAT_PARAM_VAL; -#endif - - return &bl31_params_mem.bl31_ep_info; -} - -void bl2_plat_set_bl31_ep_info(image_info_t *image, - entry_point_info_t *bl31_ep_info) -{ - SET_SECURITY_STATE(bl31_ep_info->h.attr, SECURE); - bl31_ep_info->spsr = SPSR_64(MODE_EL3, MODE_SP_ELX, - DISABLE_ALL_EXCEPTIONS); -} - -/******************************************************************************* - * Before calling this function BL32 is loaded in memory and its entrypoint - * is set by load_image. This is a placeholder for the platform to change - * the entrypoint of BL32 and set SPSR and security state. - * On Hikey we only set the security state of the entrypoint - ******************************************************************************/ -#ifdef BL32_BASE -void bl2_plat_set_bl32_ep_info(image_info_t *bl32_image_info, - entry_point_info_t *bl32_ep_info) -{ - SET_SECURITY_STATE(bl32_ep_info->h.attr, SECURE); - /* - * The Secure Payload Dispatcher service is responsible for - * setting the SPSR prior to entry into the BL32 image. - */ - bl32_ep_info->spsr = 0; -} - -/******************************************************************************* - * Populate the extents of memory available for loading BL32 - ******************************************************************************/ -void bl2_plat_get_bl32_meminfo(meminfo_t *bl32_meminfo) -{ - /* - * Populate the extents of memory available for loading BL32. - */ - bl32_meminfo->total_base = BL32_BASE; - bl32_meminfo->free_base = BL32_BASE; - bl32_meminfo->total_size = - (TSP_SEC_MEM_BASE + TSP_SEC_MEM_SIZE) - BL32_BASE; - bl32_meminfo->free_size = - (TSP_SEC_MEM_BASE + TSP_SEC_MEM_SIZE) - BL32_BASE; -} -#endif /* BL32_BASE */ - -void bl2_plat_set_bl33_ep_info(image_info_t *image, - entry_point_info_t *bl33_ep_info) -{ - unsigned long el_status; - unsigned int mode; - - /* Figure out what mode we enter the non-secure world in */ - el_status = read_id_aa64pfr0_el1() >> ID_AA64PFR0_EL2_SHIFT; - el_status &= ID_AA64PFR0_ELX_MASK; - - if (el_status) - mode = MODE_EL2; - else - mode = MODE_EL1; - - /* - * TODO: Consider the possibility of specifying the SPSR in - * the FIP ToC and allowing the platform to have a say as - * well. - */ - bl33_ep_info->spsr = SPSR_64(mode, MODE_SP_ELX, - DISABLE_ALL_EXCEPTIONS); - SET_SECURITY_STATE(bl33_ep_info->h.attr, NON_SECURE); -} - -void bl2_plat_flush_bl31_params(void) -{ - flush_dcache_range((unsigned long)&bl31_params_mem, - sizeof(bl2_to_bl31_params_mem_t)); -} - -void bl2_plat_get_bl33_meminfo(meminfo_t *bl33_meminfo) -{ - bl33_meminfo->total_base = DDR_BASE; - bl33_meminfo->total_size = DDR_SIZE; - bl33_meminfo->free_base = DDR_BASE; - bl33_meminfo->free_size = DDR_SIZE; -} -#endif /* LOAD_IMAGE_V2 */ - -void bl2_early_platform_setup(meminfo_t *mem_layout) +void bl2_el3_early_platform_setup(u_register_t arg1, u_register_t arg2, + u_register_t arg3, u_register_t arg4) { unsigned int id, uart_base; @@ -403,18 +292,19 @@ void bl2_early_platform_setup(meminfo_t *mem_layout) uart_base = PL011_UART5_BASE; else uart_base = PL011_UART6_BASE; - /* Initialize the console to provide early debug support */ console_init(uart_base, PL011_UART_CLK_IN_HZ, PL011_BAUDRATE); - - /* Setup the BL2 memory layout */ - bl2_tzram_layout = *mem_layout; + /* + * Allow BL2 to see the whole Trusted RAM. + */ + bl2_el3_tzram_layout.total_base = BL2_RW_BASE; + bl2_el3_tzram_layout.total_size = BL31_LIMIT - BL2_RW_BASE; } -void bl2_plat_arch_setup(void) +void bl2_el3_plat_arch_setup(void) { - hikey960_init_mmu_el1(bl2_tzram_layout.total_base, - bl2_tzram_layout.total_size, + hikey960_init_mmu_el3(bl2_el3_tzram_layout.total_base, + bl2_el3_tzram_layout.total_size, BL2_RO_BASE, BL2_RO_LIMIT, BL2_COHERENT_RAM_BASE, @@ -429,4 +319,12 @@ void bl2_platform_setup(void) mmio_write_32(WDT0_REG_BASE + WDT_CONTROL_OFFSET, 0); mmio_write_32(WDT0_REG_BASE + WDT_LOCK_OFFSET, 0); } + hikey960_clk_init(); + hikey960_pmu_init(); + hikey960_regulator_enable(); + hikey960_tzc_init(); + hikey960_peri_init(); + hikey960_pinmux_init(); + hikey960_init_ufs(); + hikey960_io_setup(); } diff --git a/plat/hisilicon/hikey960/hikey960_bl31_setup.c b/plat/hisilicon/hikey960/hikey960_bl31_setup.c index f0d15a358..f8921f270 100644 --- a/plat/hisilicon/hikey960/hikey960_bl31_setup.c +++ b/plat/hisilicon/hikey960/hikey960_bl31_setup.c @@ -78,13 +78,8 @@ entry_point_info_t *bl31_plat_get_next_image_ep_info(uint32_t type) return NULL; } -#if LOAD_IMAGE_V2 void bl31_early_platform_setup(void *from_bl2, void *plat_params_from_bl2) -#else -void bl31_early_platform_setup(bl31_params_t *from_bl2, - void *plat_params_from_bl2) -#endif { unsigned int id, uart_base; @@ -102,7 +97,6 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, cci_init(CCI400_REG_BASE, cci_map, ARRAY_SIZE(cci_map)); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); -#if LOAD_IMAGE_V2 /* * Check params passed from BL2 should not be NULL, */ @@ -129,23 +123,6 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, if (bl33_ep_info.pc == 0) panic(); - -#else /* LOAD_IMAGE_V2 */ - - /* - * Check params passed from BL2 should not be NULL, - */ - assert(from_bl2 != NULL); - assert(from_bl2->h.type == PARAM_BL31); - assert(from_bl2->h.version >= VERSION_1); - - /* - * Copy BL3-2 and BL3-3 entry point information. - * They are stored in Secure RAM, in BL2's address space. - */ - bl32_ep_info = *from_bl2->bl32_ep_info; - bl33_ep_info = *from_bl2->bl33_ep_info; -#endif /* LOAD_IMAGE_V2 */ } void bl31_plat_arch_setup(void) diff --git a/plat/hisilicon/hikey960/hikey960_bl_common.c b/plat/hisilicon/hikey960/hikey960_bl_common.c new file mode 100644 index 000000000..f192c1e0e --- /dev/null +++ b/plat/hisilicon/hikey960/hikey960_bl_common.c @@ -0,0 +1,441 @@ +/* + * Copyright (c) 2018, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#include <debug.h> +#include <delay_timer.h> +#include <hi3660.h> +#include <mmio.h> + +#include "hikey960_private.h" + +void hikey960_clk_init(void) +{ + /* change ldi0 sel to ppll2 */ + mmio_write_32(0xfff350b4, 0xf0002000); + /* ldi0 20' */ + mmio_write_32(0xfff350bc, 0xfc004c00); +} + +void hikey960_pmu_init(void) +{ + /* clear np_xo_abb_dig_START bit in PMIC_CLK_TOP_CTRL7 register */ + mmio_clrbits_32(PMU_SSI0_CLK_TOP_CTRL7_REG, NP_XO_ABB_DIG); +} + +static void hikey960_enable_ppll3(void) +{ + /* enable ppll3 */ + mmio_write_32(PMC_PPLL3_CTRL0_REG, 0x4904305); + mmio_write_32(PMC_PPLL3_CTRL1_REG, 0x2300000); + mmio_write_32(PMC_PPLL3_CTRL1_REG, 0x6300000); +} + +static void bus_idle_clear(unsigned int value) +{ + unsigned int pmc_value, value1, value2; + int timeout = 100; + + pmc_value = value << 16; + pmc_value &= ~value; + mmio_write_32(PMC_NOC_POWER_IDLEREQ_REG, pmc_value); + + for (;;) { + value1 = (unsigned int)mmio_read_32(PMC_NOC_POWER_IDLEACK_REG); + value2 = (unsigned int)mmio_read_32(PMC_NOC_POWER_IDLE_REG); + if (((value1 & value) == 0) && ((value2 & value) == 0)) + break; + udelay(1); + timeout--; + if (timeout <= 0) { + WARN("%s timeout\n", __func__); + break; + } + } +} + +static void set_vivobus_power_up(void) +{ + /* clk enable */ + mmio_write_32(CRG_CLKDIV20_REG, 0x00020002); + mmio_write_32(CRG_PEREN0_REG, 0x00001000); +} + +static void set_dss_power_up(void) +{ + /* set edc0 133MHz = 1600MHz / 12 */ + mmio_write_32(CRG_CLKDIV5_REG, 0x003f000b); + /* set ldi0 ppl0 */ + mmio_write_32(CRG_CLKDIV3_REG, 0xf0001000); + /* set ldi0 133MHz, 1600MHz / 12 */ + mmio_write_32(CRG_CLKDIV5_REG, 0xfc002c00); + /* mtcmos on */ + mmio_write_32(CRG_PERPWREN_REG, 0x00000020); + udelay(100); + /* DISP CRG */ + mmio_write_32(CRG_PERRSTDIS4_REG, 0x00000010); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x01400140); + mmio_write_32(CRG_PEREN0_REG, 0x00002000); + mmio_write_32(CRG_PEREN3_REG, 0x0003b000); + udelay(1); + /* clk disable */ + mmio_write_32(CRG_PERDIS3_REG, 0x0003b000); + mmio_write_32(CRG_PERDIS0_REG, 0x00002000); + mmio_write_32(CRG_CLKDIV18_REG, 0x01400000); + udelay(1); + /* iso disable */ + mmio_write_32(CRG_ISODIS_REG, 0x00000040); + /* unreset */ + mmio_write_32(CRG_PERRSTDIS4_REG, 0x00000006); + mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000c00); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x01400140); + mmio_write_32(CRG_PEREN0_REG, 0x00002000); + mmio_write_32(CRG_PEREN3_REG, 0x0003b000); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_DSS); + /* set edc0 400MHz for 2K 1600MHz / 4 */ + mmio_write_32(CRG_CLKDIV5_REG, 0x003f0003); + /* set ldi 266MHz, 1600MHz / 6 */ + mmio_write_32(CRG_CLKDIV5_REG, 0xfc001400); +} + +static void set_vcodec_power_up(void) +{ + /* clk enable */ + mmio_write_32(CRG_CLKDIV20_REG, 0x00040004); + mmio_write_32(CRG_PEREN0_REG, 0x00000060); + mmio_write_32(CRG_PEREN2_REG, 0x10000000); + /* unreset */ + mmio_write_32(CRG_PERRSTDIS0_REG, 0x00000018); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VCODEC); +} + +static void set_vdec_power_up(void) +{ + /* mtcmos on */ + mmio_write_32(CRG_PERPWREN_REG, 0x00000004); + udelay(100); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x80008000); + mmio_write_32(CRG_PEREN2_REG, 0x20080000); + mmio_write_32(CRG_PEREN3_REG, 0x00000800); + udelay(1); + /* clk disable */ + mmio_write_32(CRG_PERDIS3_REG, 0x00000800); + mmio_write_32(CRG_PERDIS2_REG, 0x20080000); + mmio_write_32(CRG_CLKDIV18_REG, 0x80000000); + udelay(1); + /* iso disable */ + mmio_write_32(CRG_ISODIS_REG, 0x00000004); + /* unreset */ + mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000200); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x80008000); + mmio_write_32(CRG_PEREN2_REG, 0x20080000); + mmio_write_32(CRG_PEREN3_REG, 0x00000800); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VDEC); +} + +static void set_venc_power_up(void) +{ + /* set venc ppll3 */ + mmio_write_32(CRG_CLKDIV8_REG, 0x18001000); + /* set venc 258MHz, 1290MHz / 5 */ + mmio_write_32(CRG_CLKDIV8_REG, 0x07c00100); + /* mtcmos on */ + mmio_write_32(CRG_PERPWREN_REG, 0x00000002); + udelay(100); + /* clk enable */ + mmio_write_32(CRG_CLKDIV19_REG, 0x00010001); + mmio_write_32(CRG_PEREN2_REG, 0x40000100); + mmio_write_32(CRG_PEREN3_REG, 0x00000400); + udelay(1); + /* clk disable */ + mmio_write_32(CRG_PERDIS3_REG, 0x00000400); + mmio_write_32(CRG_PERDIS2_REG, 0x40000100); + mmio_write_32(CRG_CLKDIV19_REG, 0x00010000); + udelay(1); + /* iso disable */ + mmio_write_32(CRG_ISODIS_REG, 0x00000002); + /* unreset */ + mmio_write_32(CRG_PERRSTDIS3_REG, 0x00000100); + /* clk enable */ + mmio_write_32(CRG_CLKDIV19_REG, 0x00010001); + mmio_write_32(CRG_PEREN2_REG, 0x40000100); + mmio_write_32(CRG_PEREN3_REG, 0x00000400); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_VENC); + /* set venc 645MHz, 1290MHz / 2 */ + mmio_write_32(CRG_CLKDIV8_REG, 0x07c00040); +} + +static void set_isp_power_up(void) +{ + /* mtcmos on */ + mmio_write_32(CRG_PERPWREN_REG, 0x00000001); + udelay(100); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x70007000); + mmio_write_32(CRG_CLKDIV20_REG, 0x00100010); + mmio_write_32(CRG_PEREN5_REG, 0x01000010); + mmio_write_32(CRG_PEREN3_REG, 0x0bf00000); + udelay(1); + /* clk disable */ + mmio_write_32(CRG_PERDIS5_REG, 0x01000010); + mmio_write_32(CRG_PERDIS3_REG, 0x0bf00000); + mmio_write_32(CRG_CLKDIV18_REG, 0x70000000); + mmio_write_32(CRG_CLKDIV20_REG, 0x00100000); + udelay(1); + /* iso disable */ + mmio_write_32(CRG_ISODIS_REG, 0x00000001); + /* unreset */ + mmio_write_32(CRG_ISP_SEC_RSTDIS_REG, 0x0000002f); + /* clk enable */ + mmio_write_32(CRG_CLKDIV18_REG, 0x70007000); + mmio_write_32(CRG_CLKDIV20_REG, 0x00100010); + mmio_write_32(CRG_PEREN5_REG, 0x01000010); + mmio_write_32(CRG_PEREN3_REG, 0x0bf00000); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_ISP); + /* csi clk enable */ + mmio_write_32(CRG_PEREN3_REG, 0x00700000); +} + +static void set_ivp_power_up(void) +{ + /* set ivp ppll0 */ + mmio_write_32(CRG_CLKDIV0_REG, 0xc0000000); + /* set ivp 267MHz, 1600MHz / 6 */ + mmio_write_32(CRG_CLKDIV0_REG, 0x3c001400); + /* mtcmos on */ + mmio_write_32(CRG_PERPWREN_REG, 0x00200000); + udelay(100); + /* IVP CRG unreset */ + mmio_write_32(CRG_IVP_SEC_RSTDIS_REG, 0x00000001); + /* clk enable */ + mmio_write_32(CRG_CLKDIV20_REG, 0x02000200); + mmio_write_32(CRG_PEREN4_REG, 0x000000a8); + udelay(1); + /* clk disable */ + mmio_write_32(CRG_PERDIS4_REG, 0x000000a8); + mmio_write_32(CRG_CLKDIV20_REG, 0x02000000); + udelay(1); + /* iso disable */ + mmio_write_32(CRG_ISODIS_REG, 0x01000000); + /* unreset */ + mmio_write_32(CRG_IVP_SEC_RSTDIS_REG, 0x00000002); + /* clk enable */ + mmio_write_32(CRG_CLKDIV20_REG, 0x02000200); + mmio_write_32(CRG_PEREN4_REG, 0x000000a8); + /* bus idle clear */ + bus_idle_clear(PMC_NOC_POWER_IDLEREQ_IVP); + /* set ivp 533MHz, 1600MHz / 3 */ + mmio_write_32(CRG_CLKDIV0_REG, 0x3c000800); +} + +static void set_audio_power_up(void) +{ + unsigned int ret; + int timeout = 100; + /* mtcmos on */ + mmio_write_32(SCTRL_SCPWREN_REG, 0x00000001); + udelay(100); + /* clk enable */ + mmio_write_32(CRG_CLKDIV19_REG, 0x80108010); + mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010001); + mmio_write_32(SCTRL_SCPEREN0_REG, 0x0c000000); + mmio_write_32(CRG_PEREN0_REG, 0x04000000); + mmio_write_32(CRG_PEREN5_REG, 0x00000080); + mmio_write_32(SCTRL_SCPEREN1_REG, 0x0000000f); + udelay(1); + /* clk disable */ + mmio_write_32(SCTRL_SCPERDIS1_REG, 0x0000000f); + mmio_write_32(SCTRL_SCPERDIS0_REG, 0x0c000000); + mmio_write_32(CRG_PERDIS5_REG, 0x00000080); + mmio_write_32(CRG_PERDIS0_REG, 0x04000000); + mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010000); + mmio_write_32(CRG_CLKDIV19_REG, 0x80100000); + udelay(1); + /* iso disable */ + mmio_write_32(SCTRL_SCISODIS_REG, 0x00000001); + udelay(1); + /* unreset */ + mmio_write_32(SCTRL_PERRSTDIS1_SEC_REG, 0x00000001); + mmio_write_32(SCTRL_SCPERRSTDIS0_REG, 0x00000780); + /* clk enable */ + mmio_write_32(CRG_CLKDIV19_REG, 0x80108010); + mmio_write_32(SCTRL_SCCLKDIV2_REG, 0x00010001); + mmio_write_32(SCTRL_SCPEREN0_REG, 0x0c000000); + mmio_write_32(CRG_PEREN0_REG, 0x04000000); + mmio_write_32(CRG_PEREN5_REG, 0x00000080); + mmio_write_32(SCTRL_SCPEREN1_REG, 0x0000000f); + /* bus idle clear */ + mmio_write_32(SCTRL_SCPERCTRL7_REG, 0x00040000); + for (;;) { + ret = mmio_read_32(SCTRL_SCPERSTAT6_REG); + if (((ret & (1 << 5)) == 0) && ((ret & (1 << 8)) == 0)) + break; + udelay(1); + timeout--; + if (timeout <= 0) { + WARN("%s timeout\n", __func__); + break; + } + } + mmio_write_32(ASP_CFG_MMBUF_CTRL_REG, 0x00ff0000); +} + +static void set_pcie_power_up(void) +{ + /* mtcmos on */ + mmio_write_32(SCTRL_SCPWREN_REG, 0x00000010); + udelay(100); + /* clk enable */ + mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000800); + mmio_write_32(SCTRL_SCPEREN2_REG, 0x00104000); + mmio_write_32(CRG_PEREN7_REG, 0x000003a0); + udelay(1); + /* clk disable */ + mmio_write_32(SCTRL_SCPERDIS2_REG, 0x00104000); + mmio_write_32(CRG_PERDIS7_REG, 0x000003a0); + mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000000); + udelay(1); + /* iso disable */ + mmio_write_32(SCTRL_SCISODIS_REG, 0x00000030); + /* unreset */ + mmio_write_32(CRG_PERRSTDIS3_REG, 0x8c000000); + /* clk enable */ + mmio_write_32(SCTRL_SCCLKDIV6_REG, 0x08000800); + mmio_write_32(SCTRL_SCPEREN2_REG, 0x00104000); + mmio_write_32(CRG_PEREN7_REG, 0x000003a0); +} + +static void ispfunc_enable(void) +{ + /* enable ispfunc. Otherwise powerup isp_srt causes exception. */ + mmio_write_32(0xfff35000, 0x00000008); + mmio_write_32(0xfff35460, 0xc004ffff); + mmio_write_32(0xfff35030, 0x02000000); + mdelay(10); +} + +static void isps_control_clock(int flag) +{ + unsigned int ret; + + /* flag: 0 -- disable clock, 1 -- enable clock */ + if (flag) { + ret = mmio_read_32(0xe8420364); + ret |= 1; + mmio_write_32(0xe8420364, ret); + } else { + ret = mmio_read_32(0xe8420364); + ret &= ~1; + mmio_write_32(0xe8420364, ret); + } +} + +static void set_isp_srt_power_up(void) +{ + unsigned int ret; + + ispfunc_enable(); + /* reset */ + mmio_write_32(0xe8420374, 0x00000001); + mmio_write_32(0xe8420350, 0x00000000); + mmio_write_32(0xe8420358, 0x00000000); + /* mtcmos on */ + mmio_write_32(0xfff35150, 0x00400000); + udelay(100); + /* clk enable */ + isps_control_clock(1); + udelay(1); + isps_control_clock(0); + udelay(1); + /* iso disable */ + mmio_write_32(0xfff35148, 0x08000000); + /* unreset */ + ret = mmio_read_32(0xe8420374); + ret &= ~0x1; + mmio_write_32(0xe8420374, ret); + /* clk enable */ + isps_control_clock(1); + /* enable clock gating for accessing csi registers */ + mmio_write_32(0xe8420010, ~0); +} + +void hikey960_regulator_enable(void) +{ + set_vivobus_power_up(); + hikey960_enable_ppll3(); + set_dss_power_up(); + set_vcodec_power_up(); + set_vdec_power_up(); + set_venc_power_up(); + set_isp_power_up(); + set_ivp_power_up(); + set_audio_power_up(); + set_pcie_power_up(); + set_isp_srt_power_up(); + + /* set ISP_CORE_CTRL_S to unsecure mode */ + mmio_write_32(0xe8583800, 0x7); + /* set ISP_SUB_CTRL_S to unsecure mode */ + mmio_write_32(0xe8583804, 0xf); +} + +void hikey960_tzc_init(void) +{ + mmio_write_32(TZC_EN0_REG, 0x7fbff066); + mmio_write_32(TZC_EN1_REG, 0xfffff5fc); + mmio_write_32(TZC_EN2_REG, 0x0007005c); + mmio_write_32(TZC_EN3_REG, 0x37030700); + mmio_write_32(TZC_EN4_REG, 0xf63fefae); + mmio_write_32(TZC_EN5_REG, 0x000410fd); + mmio_write_32(TZC_EN6_REG, 0x0063ff68); + mmio_write_32(TZC_EN7_REG, 0x030000f3); + mmio_write_32(TZC_EN8_REG, 0x00000007); +} + +void hikey960_peri_init(void) +{ + /* unreset */ + mmio_setbits_32(CRG_PERRSTDIS4_REG, 1); +} + +void hikey960_pinmux_init(void) +{ + unsigned int id; + + hikey960_read_boardid(&id); + if (id == 5301) { + /* hikey960 hardware v2 */ + /* GPIO150: LED */ + mmio_write_32(IOMG_FIX_006_REG, 0); + /* GPIO151: LED */ + mmio_write_32(IOMG_FIX_007_REG, 0); + /* GPIO189: LED */ + mmio_write_32(IOMG_AO_011_REG, 0); + /* GPIO190: LED */ + mmio_write_32(IOMG_AO_012_REG, 0); + /* GPIO46 */ + mmio_write_32(IOMG_044_REG, 0); + /* GPIO202 */ + mmio_write_32(IOMG_AO_023_REG, 0); + /* GPIO206 */ + mmio_write_32(IOMG_AO_026_REG, 0); + /* GPIO219 - PD pullup */ + mmio_write_32(IOMG_AO_039_REG, 0); + mmio_write_32(IOCG_AO_043_REG, 1 << 0); + } + /* GPIO005 - PMU SSI, 10mA */ + mmio_write_32(IOCG_006_REG, 2 << 4); + /* GPIO213 - PCIE_CLKREQ_N */ + mmio_write_32(IOMG_AO_033_REG, 1); +} diff --git a/plat/hisilicon/hikey960/hikey960_boardid.c b/plat/hisilicon/hikey960/hikey960_boardid.c index 90faa9d30..f39c15385 100644 --- a/plat/hisilicon/hikey960/hikey960_boardid.c +++ b/plat/hisilicon/hikey960/hikey960_boardid.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -148,23 +148,19 @@ int hikey960_read_boardid(unsigned int *id) /* read ADC channel0 data */ get_value(ADC_ADCIN0, &adcin0); adcin0_remap = adcin_data_remap(adcin0); - INFO("[BDID]adcin0:%d adcin0_remap:%d\n", adcin0, adcin0_remap); if (adcin0_remap == BOARDID_UNKNOWN) return -EINVAL; /* read ADC channel1 data */ get_value(ADC_ADCIN1, &adcin1); adcin1_remap = adcin_data_remap(adcin1); - INFO("[BDID]adcin1:%d adcin1_remap:%d\n", adcin1, adcin1_remap); if (adcin1_remap == BOARDID_UNKNOWN) return -EINVAL; /* read ADC channel2 data */ get_value(ADC_ADCIN2, &adcin2); adcin2_remap = adcin_data_remap(adcin2); - INFO("[BDID]adcin2:%d adcin2_remap:%d\n", adcin2, adcin2_remap); if (adcin2_remap == BOARDID_UNKNOWN) return -EINVAL; *id = BOARDID3_BASE * 1000 + (adcin2_remap * 100) + (adcin1_remap * 10) + adcin0_remap; - INFO("[BDID]boardid: %d\n", *id); return 0; } diff --git a/plat/hisilicon/hikey960/hikey960_image_load.c b/plat/hisilicon/hikey960/hikey960_image_load.c index 8e91adbf2..ad7be5081 100644 --- a/plat/hisilicon/hikey960/hikey960_image_load.c +++ b/plat/hisilicon/hikey960/hikey960_image_load.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -8,8 +8,6 @@ #include <desc_image_load.h> #include <platform.h> -#include "hikey960_private.h" - /******************************************************************************* * This function flushes the data structures so that they are visible * in memory for the next BL image. @@ -24,10 +22,6 @@ void plat_flush_next_bl_params(void) ******************************************************************************/ bl_load_info_t *plat_get_bl_image_load_info(void) { - /* Required before loading scp_bl2 */ - hikey960_init_ufs(); - hikey960_io_setup(); - return get_bl_load_info_from_mem_params_desc(); } diff --git a/plat/hisilicon/hikey960/hikey960_io_storage.c b/plat/hisilicon/hikey960/hikey960_io_storage.c index 1a1d84604..be7c941ff 100644 --- a/plat/hisilicon/hikey960/hikey960_io_storage.c +++ b/plat/hisilicon/hikey960/hikey960_io_storage.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -39,11 +39,6 @@ static const io_block_spec_t ufs_fip_spec = { .length = HIKEY960_FIP_MAX_SIZE, }; -static const io_block_spec_t ufs_data_spec = { - .offset = 0, - .length = 256 << 20, -}; - static const io_block_dev_spec_t ufs_dev_spec = { /* It's used as temp buffer in block driver. */ .buffer = { @@ -57,10 +52,6 @@ static const io_block_dev_spec_t ufs_dev_spec = { .block_size = UFS_BLOCK_SIZE, }; -static const io_uuid_spec_t bl2_uuid_spec = { - .uuid = UUID_TRUSTED_BOOT_FIRMWARE_BL2, -}; - static const io_uuid_spec_t scp_bl2_uuid_spec = { .uuid = UUID_SCP_FIRMWARE_SCP_BL2, }; @@ -91,11 +82,6 @@ static const struct plat_io_policy policies[] = { (uintptr_t)&ufs_fip_spec, check_ufs }, - [BL2_IMAGE_ID] = { - &fip_dev_handle, - (uintptr_t)&bl2_uuid_spec, - check_fip - }, [SCP_BL2_IMAGE_ID] = { &fip_dev_handle, (uintptr_t)&scp_bl2_uuid_spec, @@ -125,11 +111,6 @@ static const struct plat_io_policy policies[] = { &fip_dev_handle, (uintptr_t)&bl33_uuid_spec, check_fip - }, - [BL2U_IMAGE_ID] = { - &ufs_dev_handle, - (uintptr_t)&ufs_data_spec, - check_ufs } }; diff --git a/plat/hisilicon/hikey960/hikey960_private.h b/plat/hisilicon/hikey960/hikey960_private.h index e3c9d2153..30166e56d 100644 --- a/plat/hisilicon/hikey960/hikey960_private.h +++ b/plat/hisilicon/hikey960/hikey960_private.h @@ -24,9 +24,14 @@ void hikey960_init_mmu_el3(unsigned long total_base, unsigned long ro_limit, unsigned long coh_start, unsigned long coh_limit); -void hikey960_init_ufs(void); void hikey960_io_setup(void); int hikey960_read_boardid(unsigned int *id); +void hikey960_clk_init(void); +void hikey960_pmu_init(void); +void hikey960_regulator_enable(void); +void hikey960_tzc_init(void); +void hikey960_peri_init(void); +void hikey960_pinmux_init(void); void set_retention_ticks(unsigned int val); void clr_retention_ticks(unsigned int val); void clr_ex(void); diff --git a/plat/hisilicon/hikey960/include/platform_def.h b/plat/hisilicon/hikey960/include/platform_def.h index 36fd3b531..beff47c0e 100644 --- a/plat/hisilicon/hikey960/include/platform_def.h +++ b/plat/hisilicon/hikey960/include/platform_def.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ @@ -56,8 +56,8 @@ /* * BL2 specific defines. */ -#define BL2_BASE (BL1_RW_BASE + 0x8000) /* 1AC1_8000 */ -#define BL2_LIMIT (BL2_BASE + 0x40000) /* 1AC5_8000 */ +#define BL2_BASE (0x1AC00000) +#define BL2_LIMIT (BL2_BASE + 0x58000) /* 1AC5_8000 */ /* * BL31 specific defines. @@ -75,13 +75,11 @@ #define BL32_DRAM_BASE DDR_SEC_BASE #define BL32_DRAM_LIMIT (DDR_SEC_BASE+DDR_SEC_SIZE) -#if LOAD_IMAGE_V2 #ifdef SPD_opteed /* Load pageable part of OP-TEE at end of allocated DRAM space for BL32 */ #define HIKEY960_OPTEE_PAGEABLE_LOAD_BASE (BL32_DRAM_LIMIT - HIKEY960_OPTEE_PAGEABLE_LOAD_SIZE) /* 0x3FC0_0000 */ #define HIKEY960_OPTEE_PAGEABLE_LOAD_SIZE 0x400000 /* 4MB */ #endif -#endif #if (HIKEY960_TSP_RAM_LOCATION_ID == HIKEY960_DRAM_ID) #define TSP_SEC_MEM_BASE BL32_DRAM_BASE @@ -121,15 +119,11 @@ #endif #ifdef IMAGE_BL2 -#if LOAD_IMAGE_V2 #ifdef SPD_opteed #define MAX_XLAT_TABLES 4 #else #define MAX_XLAT_TABLES 3 #endif -#else -#define MAX_XLAT_TABLES 3 -#endif #endif #define MAX_MMAP_REGIONS 16 diff --git a/plat/hisilicon/hikey960/platform.mk b/plat/hisilicon/hikey960/platform.mk index ffe10738f..8b03e555d 100644 --- a/plat/hisilicon/hikey960/platform.mk +++ b/plat/hisilicon/hikey960/platform.mk @@ -7,6 +7,9 @@ # Enable version2 of image loading LOAD_IMAGE_V2 := 1 +# Non-TF Boot ROM +BL2_AT_EL3 := 1 + # On Hikey960, the TSP can execute from TZC secure area in DRAM. HIKEY960_TSP_RAM_LOCATION ?= dram ifeq (${HIKEY960_TSP_RAM_LOCATION}, dram) @@ -62,27 +65,29 @@ BL1_SOURCES += bl1/tbbr/tbbr_img_desc.c \ drivers/ufs/ufs.c \ lib/cpus/aarch64/cortex_a53.S \ plat/hisilicon/hikey960/aarch64/hikey960_helpers.S \ - plat/hisilicon/hikey960/hikey960_bl1_setup.c \ + plat/hisilicon/hikey960/hikey960_bl1_setup.c \ + plat/hisilicon/hikey960/hikey960_bl_common.c \ plat/hisilicon/hikey960/hikey960_io_storage.c \ ${HIKEY960_GIC_SOURCES} -BL2_SOURCES += drivers/io/io_block.c \ +BL2_SOURCES += common/desc_image_load.c \ + drivers/io/io_block.c \ drivers/io/io_fip.c \ drivers/io/io_storage.c \ + drivers/synopsys/ufs/dw_ufs.c \ drivers/ufs/ufs.c \ + lib/cpus/aarch64/cortex_a53.S \ + plat/hisilicon/hikey960/aarch64/hikey960_helpers.S \ + plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c \ plat/hisilicon/hikey960/hikey960_bl2_setup.c \ + plat/hisilicon/hikey960/hikey960_bl_common.c \ + plat/hisilicon/hikey960/hikey960_image_load.c \ plat/hisilicon/hikey960/hikey960_io_storage.c \ plat/hisilicon/hikey960/hikey960_mcu_load.c -ifeq (${LOAD_IMAGE_V2},1) -BL2_SOURCES += plat/hisilicon/hikey960/hikey960_bl2_mem_params_desc.c \ - plat/hisilicon/hikey960/hikey960_image_load.c \ - common/desc_image_load.c - ifeq (${SPD},opteed) BL2_SOURCES += lib/optee/optee_utils.c endif -endif BL31_SOURCES += drivers/arm/cci/cci.c \ lib/cpus/aarch64/cortex_a53.S \ diff --git a/plat/nvidia/tegra/common/tegra_bl31_setup.c b/plat/nvidia/tegra/common/tegra_bl31_setup.c index d5d3d530d..d89ad7b94 100644 --- a/plat/nvidia/tegra/common/tegra_bl31_setup.c +++ b/plat/nvidia/tegra/common/tegra_bl31_setup.c @@ -24,6 +24,9 @@ #include <tegra_def.h> #include <tegra_private.h> +/* length of Trusty's input parameters (in bytes) */ +#define TRUSTY_PARAMS_LEN_BYTES (4096*2) + extern void zeromem16(void *mem, unsigned int length); /******************************************************************************* @@ -58,6 +61,8 @@ static entry_point_info_t bl33_image_ep_info, bl32_image_ep_info; static plat_params_from_bl2_t plat_bl31_params_from_bl2 = { .tzdram_size = (uint64_t)TZDRAM_SIZE }; +static unsigned long bl32_mem_size; +static unsigned long bl32_boot_params; /******************************************************************************* * This variable holds the non-secure image entry address @@ -147,8 +152,11 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, assert(from_bl2->bl33_ep_info); bl33_image_ep_info = *from_bl2->bl33_ep_info; - if (from_bl2->bl32_ep_info) + if (from_bl2->bl32_ep_info) { bl32_image_ep_info = *from_bl2->bl32_ep_info; + bl32_mem_size = from_bl2->bl32_ep_info->args.arg0; + bl32_boot_params = from_bl2->bl32_ep_info->args.arg2; + } /* * Parse platform specific parameters - TZDRAM aperture base and size @@ -234,6 +242,15 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, "Denver" : "ARM", read_mpidr()); } +#ifdef SPD_trusty +void plat_trusty_set_boot_args(aapcs64_params_t *args) +{ + args->arg0 = bl32_mem_size; + args->arg1 = bl32_boot_params; + args->arg2 = TRUSTY_PARAMS_LEN_BYTES; +} +#endif + /******************************************************************************* * Initialize the gic, configure the SCR. ******************************************************************************/ diff --git a/plat/nvidia/tegra/soc/t186/plat_smmu.c b/plat/nvidia/tegra/soc/t186/plat_smmu.c index 4a8e1bee4..ead4c22b8 100644 --- a/plat/nvidia/tegra/soc/t186/plat_smmu.c +++ b/plat/nvidia/tegra/soc/t186/plat_smmu.c @@ -1,23 +1,7 @@ /* - * Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved. + * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. + * SPDX-License-Identifier: BSD-3-Clause */ #include <bl_common.h> diff --git a/plat/qemu/include/platform_def.h b/plat/qemu/include/platform_def.h index afda4f8e6..f8764fbfe 100644 --- a/plat/qemu/include/platform_def.h +++ b/plat/qemu/include/platform_def.h @@ -168,7 +168,7 @@ #define PLAT_PHY_ADDR_SPACE_SIZE (1ULL << 32) #define PLAT_VIRT_ADDR_SPACE_SIZE (1ULL << 32) -#define MAX_MMAP_REGIONS 8 +#define MAX_MMAP_REGIONS 10 #define MAX_XLAT_TABLES 6 #define MAX_IO_DEVICES 3 #define MAX_IO_HANDLES 4 @@ -198,7 +198,7 @@ #define DEVICE0_BASE 0x08000000 #define DEVICE0_SIZE 0x00021000 #define DEVICE1_BASE 0x09000000 -#define DEVICE1_SIZE 0x00011000 +#define DEVICE1_SIZE 0x00041000 /* * GIC related constants diff --git a/plat/qemu/platform.mk b/plat/qemu/platform.mk index 26633c24c..5bfd48afc 100644 --- a/plat/qemu/platform.mk +++ b/plat/qemu/platform.mk @@ -167,6 +167,8 @@ ifneq ($(BL32_EXTRA2),) $(eval $(call TOOL_ADD_IMG,bl32_extra2,--tos-fw-extra2)) endif +SEPARATE_CODE_AND_RODATA := 1 + # Disable the PSCI platform compatibility layer ENABLE_PLAT_COMPAT := 0 diff --git a/plat/qemu/qemu_bl1_setup.c b/plat/qemu/qemu_bl1_setup.c index 7c820fd1a..3f617e240 100644 --- a/plat/qemu/qemu_bl1_setup.c +++ b/plat/qemu/qemu_bl1_setup.c @@ -12,15 +12,6 @@ #include <platform_def.h> #include "qemu_private.h" -/******************************************************************************* - * Declarations of linker defined symbols which will tell us where BL1 lives - * in Trusted RAM - ******************************************************************************/ -extern uint64_t __BL1_RAM_START__; -extern uint64_t __BL1_RAM_END__; -#define BL1_RAM_BASE (uint64_t)(&__BL1_RAM_START__) -#define BL1_RAM_LIMIT (uint64_t)(&__BL1_RAM_END__) - /* Data structure which holds the extents of the trusted SRAM for BL1*/ static meminfo_t bl1_tzram_layout; @@ -67,7 +58,8 @@ void bl1_plat_arch_setup(void) { QEMU_CONFIGURE_BL1_MMU(bl1_tzram_layout.total_base, bl1_tzram_layout.total_size, - BL1_RO_BASE, BL1_RO_LIMIT, + BL_CODE_BASE, BL1_CODE_END, + BL1_RO_DATA_BASE, BL1_RO_DATA_END, BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END); } diff --git a/plat/qemu/qemu_bl2_setup.c b/plat/qemu/qemu_bl2_setup.c index 9e4a4a0e7..987c6028c 100644 --- a/plat/qemu/qemu_bl2_setup.c +++ b/plat/qemu/qemu_bl2_setup.c @@ -17,14 +17,6 @@ #include <utils.h> #include "qemu_private.h" -/* - * The next 2 constants identify the extents of the code & RO data region. - * These addresses are used by the MMU setup code and therefore they must be - * page-aligned. It is the responsibility of the linker script to ensure that - * __RO_START__ and __RO_END__ linker symbols refer to page-aligned addresses. - */ -#define BL2_RO_BASE (unsigned long)(&__RO_START__) -#define BL2_RO_LIMIT (unsigned long)(&__RO_END__) /* Data structure which holds the extents of the trusted SRAM for BL2 */ static meminfo_t bl2_tzram_layout __aligned(CACHE_WRITEBACK_GRANULE); @@ -192,7 +184,8 @@ void bl2_plat_arch_setup(void) { QEMU_CONFIGURE_BL2_MMU(bl2_tzram_layout.total_base, bl2_tzram_layout.total_size, - BL2_RO_BASE, BL2_RO_LIMIT, + BL_CODE_BASE, BL_CODE_END, + BL_RO_DATA_BASE, BL_RO_DATA_END, BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END); } diff --git a/plat/qemu/qemu_bl31_setup.c b/plat/qemu/qemu_bl31_setup.c index f79a88545..6ded92959 100644 --- a/plat/qemu/qemu_bl31_setup.c +++ b/plat/qemu/qemu_bl31_setup.c @@ -19,8 +19,6 @@ * script to ensure that __RO_START__, __RO_END__ & __BL31_END__ linker symbols * refer to page-aligned addresses. */ -#define BL31_RO_BASE (unsigned long)(&__RO_START__) -#define BL31_RO_LIMIT (unsigned long)(&__RO_END__) #define BL31_END (unsigned long)(&__BL31_END__) /* @@ -108,8 +106,9 @@ void bl31_early_platform_setup(bl31_params_t *from_bl2, void bl31_plat_arch_setup(void) { - qemu_configure_mmu_el3(BL31_RO_BASE, (BL31_END - BL31_RO_BASE), - BL31_RO_BASE, BL31_RO_LIMIT, + qemu_configure_mmu_el3(BL31_BASE, (BL31_END - BL31_BASE), + BL_CODE_BASE, BL_CODE_END, + BL_RO_DATA_BASE, BL_RO_DATA_END, BL_COHERENT_RAM_BASE, BL_COHERENT_RAM_END); } diff --git a/plat/qemu/qemu_common.c b/plat/qemu/qemu_common.c index 6f9fcc60a..2d4198b7d 100644 --- a/plat/qemu/qemu_common.c +++ b/plat/qemu/qemu_common.c @@ -104,6 +104,8 @@ static const mmap_region_t plat_qemu_mmap[] = { #define DEFINE_CONFIGURE_MMU_EL(_el) \ void qemu_configure_mmu_##_el(unsigned long total_base, \ unsigned long total_size, \ + unsigned long code_start, \ + unsigned long code_limit, \ unsigned long ro_start, \ unsigned long ro_limit, \ unsigned long coh_start, \ @@ -112,9 +114,12 @@ static const mmap_region_t plat_qemu_mmap[] = { mmap_add_region(total_base, total_base, \ total_size, \ MT_MEMORY | MT_RW | MT_SECURE); \ + mmap_add_region(code_start, code_start, \ + code_limit - code_start, \ + MT_CODE | MT_SECURE); \ mmap_add_region(ro_start, ro_start, \ ro_limit - ro_start, \ - MT_MEMORY | MT_RO | MT_SECURE); \ + MT_RO_DATA | MT_SECURE); \ mmap_add_region(coh_start, coh_start, \ coh_limit - coh_start, \ MT_DEVICE | MT_RW | MT_SECURE); \ diff --git a/plat/qemu/qemu_private.h b/plat/qemu/qemu_private.h index 202d604da..716440fb7 100644 --- a/plat/qemu/qemu_private.h +++ b/plat/qemu/qemu_private.h @@ -9,16 +9,22 @@ #include <sys/types.h> +#include <xlat_tables_defs.h> +#include "../../bl1/bl1_private.h" + void qemu_configure_mmu_secure(unsigned long total_base, unsigned long total_size, + unsigned long code_start, unsigned long code_limit, unsigned long ro_start, unsigned long ro_limit, unsigned long coh_start, unsigned long coh_limit); void qemu_configure_mmu_el1(unsigned long total_base, unsigned long total_size, + unsigned long code_start, unsigned long code_limit, unsigned long ro_start, unsigned long ro_limit, unsigned long coh_start, unsigned long coh_limit); void qemu_configure_mmu_el3(unsigned long total_base, unsigned long total_size, + unsigned long code_start, unsigned long code_limit, unsigned long ro_start, unsigned long ro_limit, unsigned long coh_start, unsigned long coh_limit); diff --git a/plat/rockchip/rk3399/drivers/dp/cdn_dp.c b/plat/rockchip/rk3399/drivers/dp/cdn_dp.c index d0e598610..f1a5e2b7a 100644 --- a/plat/rockchip/rk3399/drivers/dp/cdn_dp.c +++ b/plat/rockchip/rk3399/drivers/dp/cdn_dp.c @@ -1,11 +1,11 @@ /* - * Copyright (c) 2017, ARM Limited and Contributors. All rights reserved. + * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #include <cdn_dp.h> -#include <smcc.h> +#include <smccc.h> #include <stdlib.h> #include <string.h> diff --git a/readme.rst b/readme.rst index c3c0319e1..94b1e6383 100644 --- a/readme.rst +++ b/readme.rst @@ -1,21 +1,24 @@ -ARM Trusted Firmware - version 1.4 -================================== +Trusted Firmware-A - version 1.5 +================================ -ARM Trusted Firmware provides a reference implementation of secure world -software for `ARMv8-A`_, including a `Secure Monitor`_ executing at -Exception Level 3 (EL3). It implements various ARM interface standards, such as: +Trusted Firmware-A (TF-A) provides a reference implementation of secure world +software for `Armv7-A and Armv8-A`_, including a `Secure Monitor`_ executing +at Exception Level 3 (EL3). It implements various Arm interface standards, +such as: - The `Power State Coordination Interface (PSCI)`_ -- Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1) +- Trusted Board Boot Requirements (TBBR, Arm DEN0006C-1) - `SMC Calling Convention`_ - `System Control and Management Interface`_ +- `Software Delegated Exception Interface (SDEI)`_ -As far as possible the code is designed for reuse or porting to other ARMv8-A -model and hardware platforms. +Where possible, the code is designed for reuse or porting to other Armv7-A and +Armv8-A model and hardware platforms. -ARM will continue development in collaboration with interested parties to -provide a full reference implementation of Secure Monitor code and ARM standards -to the benefit of all developers working with ARMv8-A TrustZone technology. +Arm will continue development in collaboration with interested parties to +provide a full reference implementation of Secure Monitor code and Arm standards +to the benefit of all developers working with Armv7-A and Armv8-A TrustZone +technology. License ------- @@ -37,7 +40,10 @@ license text is included in those source files. project under the terms of the NCSA license (also known as the University of Illinois/NCSA Open Source License). -This Release +- The zlib source code is licensed under the Zlib license, which is a + permissive license compatible with BSD-3-Clause. + +This release ------------ This release provides a suitable starting point for productization of secure @@ -45,7 +51,7 @@ world boot and runtime firmware, in either the AArch32 or AArch64 execution state. Users are encouraged to do their own security validation, including penetration -testing, on any secure world code derived from ARM Trusted Firmware. +testing, on any secure world code derived from TF-A. Functionality ~~~~~~~~~~~~~ @@ -54,15 +60,15 @@ Functionality registers and interrupts for the platform. - Library support for CPU specific reset and power down sequences. This - includes support for errata workarounds and the latest ARM DynamIQ CPUs. + includes support for errata workarounds and the latest Arm DynamIQ CPUs. -- Drivers to enable standard initialization of ARM System IP, for example +- Drivers to enable standard initialization of Arm System IP, for example Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI), Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone Controller (TZC). - A generic `SCMI`_ driver to interface with conforming power controllers, for - example the ARM System Control Processor (SCP). + example the Arm System Control Processor (SCP). - SMC (Secure Monitor Call) handling, conforming to the `SMC Calling Convention`_ using an EL3 runtime services framework. @@ -93,14 +99,32 @@ Functionality recovery mode), and packaging of the various firmware images into a Firmware Image Package (FIP). -- Pre-integration of TBB with the ARM TrustZone CryptoCell product, to take - advantage of its hardware Root of Trust and crypto acceleration services. +- Pre-integration of TBB with the Arm CryptoCell product, to take advantage of + its hardware Root of Trust and crypto acceleration services. + +- Reliability, Availability, and Serviceability (RAS) functionality, including + + - A Secure Partition Manager (SPM) to manage Secure Partitions in + Secure-EL0, which can be used to implement simple management and + security services. + + - An SDEI dispatcher to route interrupt-based SDEI events. + + - An Exception Handling Framework (EHF) that allows dispatching of EL3 + interrupts to their registered handlers, to facilitate firmware-first + error handling. + +- A dynamic configuration framework that enables each of the firmware images + to be configured at runtime if required by the platform. It also enables + loading of a hardware configuration (for example, a kernel device tree) + as part of the FIP, to be passed through the firmware stages. - Support for alternative boot flows, for example to support platforms where the EL3 Runtime Software is loaded using other firmware or a separate - secure system processor. + secure system processor, or where a non-TF-A ROM expects BL2 to be loaded + at EL3. -- Support for the GCC, LLVM and ARM Compiler 6 toolchains. +- Support for the GCC, LLVM and Arm Compiler 6 toolchains. For a full description of functionality and implementation details, please see the `Firmware Design`_ and supporting documentation. The `Change Log`_ @@ -110,15 +134,16 @@ Platforms ~~~~~~~~~ Various AArch32 and AArch64 builds of this release has been tested on variants -r0, r1 and r2 of the `Juno ARM Development Platform`_. +r0, r1 and r2 of the `Juno Arm Development Platform`_. -Various AArch64 builds of this release have been tested on the following ARM -`FVP`_\ s (64-bit host machine only): +Various AArch64 builds of this release have been tested on the following Arm +Fixed Virtual Platforms (`FVP`_) without shifted affinities, and that do not +support threaded CPU cores (64-bit host machine only): -NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34. +NOTE: Unless otherwise stated, the FVP Version is 11.2 Build 11.2.33. - ``Foundation_Platform`` -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502) +- ``FVP_Base_AEMv8A-AEMv8A`` (and also Version 9.0, Build 0.8.9005) - ``FVP_Base_Cortex-A35x4`` - ``FVP_Base_Cortex-A53x4`` - ``FVP_Base_Cortex-A57x4-A53x4`` @@ -127,55 +152,67 @@ NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34. - ``FVP_Base_Cortex-A72x4`` - ``FVP_Base_Cortex-A73x4-A53x4`` - ``FVP_Base_Cortex-A73x4`` -- ``FVP_CSS_SGM-775`` (Version 11.0, Build 11.0.36) -Various AArch32 builds of this release has been tested on the following ARM -`FVP`_\ s (64-bit host machine only): +Additionally, various AArch64 builds were tested on the following Arm `FVP`_ s +with shifted affinities, supporting threaded CPU cores (64-bit host machine +only). + +- ``FVP_Base_Cortex-A55x4-A75x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_Cortex-A55x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_Cortex-A75x4`` (Version 0.0, build 0.0.4395) +- ``FVP_Base_RevC-2xAEMv8A`` -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502) +Various AArch32 builds of this release has been tested on the following Arm +`FVP`_\ s without shifted affinities, and that do not support threaded CPU cores +(64-bit host machine only): + +- ``FVP_Base_AEMv8A-AEMv8A`` - ``FVP_Base_Cortex-A32x4`` The Foundation FVP can be downloaded free of charge. The Base FVPs can be -licensed from ARM. See the `ARM FVP website`_. +licensed from Arm. See the `Arm FVP website`_. -All the above platforms have been tested with `Linaro Release 17.04`_. +All the above platforms have been tested with `Linaro Release 17.10`_. This release also contains the following platform support: -- HiKey and HiKey960 boards +- HiKey, HiKey960 and Poplar boards - MediaTek MT6795 and MT8173 SoCs - NVidia T132, T186 and T210 SoCs - QEMU emulator +- Raspberry Pi 3 board - RockChip RK3328, RK3368 and RK3399 SoCs - Socionext UniPhier SoC family - Xilinx Zynq UltraScale + MPSoC -Still to Come +Still to come ~~~~~~~~~~~~~ - More platform support. +- Improved dynamic configuration support. + - Ongoing support for new architectural features, CPUs and System IP. -- Ongoing support for new `PSCI`_, `SCMI`_ and TBBR features. +- Ongoing support for new Arm system architecture specifications. - Ongoing security hardening, optimization and quality improvements. For a full list of detailed issues in the current code, please see the `Change Log`_ and the `GitHub issue tracker`_. -Getting Started +Getting started --------------- -Get the Trusted Firmware source code from `GitHub`_. +Get the TF-A source code from `GitHub`_. See the `User Guide`_ for instructions on how to install, build and use -the Trusted Firmware with the ARM `FVP`_\ s. +the TF-A with the Arm `FVP`_\ s. -See the `Firmware Design`_ for information on how the Trusted Firmware works. +See the `Firmware Design`_ for information on how the TF-A works. See the `Porting Guide`_ as well for information about how to use this -software on another ARMv8-A platform. +software on another Armv7-A or Armv8-A platform. See the `Contributing Guidelines`_ for information on how to contribute to this project and the `Acknowledgments`_ file for a list of contributors to the @@ -184,28 +221,30 @@ project. Feedback and support ~~~~~~~~~~~~~~~~~~~~ -ARM welcomes any feedback on Trusted Firmware. If you think you have found a -security vulnerability, please report this using the process defined in the -Trusted Firmware `Security Centre`_. For all other feedback, please use the +Arm welcomes any feedback on TF-A. If you think you have found a security +vulnerability, please report this using the process defined in the TF-A +`Security Centre`_. For all other feedback, please use the `GitHub issue tracker`_. -ARM licensees may contact ARM directly via their partner managers. +Arm licensees may contact Arm directly via their partner managers. -------------- -*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.* -.. _ARMv8-A: http://www.arm.com/products/processors/armv8-architecture.php +.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php .. _Power State Coordination Interface (PSCI): PSCI_ .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf .. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf .. _System Control and Management Interface: SCMI_ .. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf -.. _Juno ARM Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php -.. _ARM FVP website: FVP_ +.. _Software Delegated Exception Interface (SDEI): SDEI_ +.. _SDEI: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf +.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php +.. _Arm FVP website: FVP_ .. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms -.. _Linaro Release 17.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease17.04 +.. _Linaro Release 17.10: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease17.10 .. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os .. _NVidia Trusted Little Kernel: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary .. _Trusty Secure OS: https://source.android.com/security/trusty diff --git a/services/arm_arch_svc/arm_arch_svc_setup.c b/services/arm_arch_svc/arm_arch_svc_setup.c index a809c429a..83d3625f9 100644 --- a/services/arm_arch_svc/arm_arch_svc_setup.c +++ b/services/arm_arch_svc/arm_arch_svc_setup.c @@ -6,9 +6,11 @@ #include <arm_arch_svc.h> #include <debug.h> +#include <errata_report.h> #include <runtime_svc.h> -#include <smcc.h> -#include <smcc_helpers.h> +#include <smccc.h> +#include <smccc_helpers.h> +#include <workaround_cve_2017_5715.h> static int32_t smccc_version(void) { @@ -17,14 +19,19 @@ static int32_t smccc_version(void) static int32_t smccc_arch_features(u_register_t arg) { + int ret; + switch (arg) { case SMCCC_VERSION: case SMCCC_ARCH_FEATURES: return SMC_OK; -#if WORKAROUND_CVE_2017_5715 case SMCCC_ARCH_WORKAROUND_1: - return SMC_OK; -#endif + ret = check_workaround_cve_2017_5715(); + if (ret == ERRATA_APPLIES) + return 0; + else if (ret == ERRATA_NOT_APPLIES) + return 1; + return -1; /* ERRATA_MISSING */ default: return SMC_UNK; } diff --git a/services/spd/trusty/generic-arm64-smcall.c b/services/spd/trusty/generic-arm64-smcall.c new file mode 100644 index 000000000..38da279e4 --- /dev/null +++ b/services/spd/trusty/generic-arm64-smcall.c @@ -0,0 +1,94 @@ +/* + * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#include <debug.h> +#include <runtime_svc.h> + +#include "generic-arm64-smcall.h" + +int trusty_disable_serial_debug; + +struct dputc_state { + char linebuf[128]; + unsigned l; +}; + +static struct dputc_state dputc_state[2]; + +static void trusty_dputc(char ch, int secure) +{ + unsigned i; + struct dputc_state *s = &dputc_state[!secure]; + + if (trusty_disable_serial_debug) + return; + + s->linebuf[s->l++] = ch; + if (s->l == sizeof(s->linebuf) || ch == '\n') { + if (secure) + printf("secure os: "); + else + printf("non-secure os: "); + for (i = 0; i < s->l; i++) { + putchar(s->linebuf[i]); + } + if (ch != '\n') { + printf(" <...>\n"); + } + s->l = 0; + } +} + +static uint64_t trusty_get_reg_base(uint32_t reg) +{ + switch (reg) { + case 0: + return PLAT_ARM_GICD_BASE; + + case 1: + return PLAT_ARM_GICC_BASE; + + default: + NOTICE("%s(0x%x) unknown reg\n", __func__, reg); + return SMC_UNK; + } +} + +static uint64_t trusty_generic_platform_smc(uint32_t smc_fid, + uint64_t x1, + uint64_t x2, + uint64_t x3, + uint64_t x4, + void *cookie, + void *handle, + uint64_t flags) +{ + switch (smc_fid) { + case SMC_FC_DEBUG_PUTC: + trusty_dputc(x1, is_caller_secure(flags)); + SMC_RET1(handle, 0); + + case SMC_FC_GET_REG_BASE: + case SMC_FC64_GET_REG_BASE: + SMC_RET1(handle, trusty_get_reg_base(x1)); + + default: + NOTICE("%s(0x%x, 0x%lx) unknown smc\n", __func__, smc_fid, x1); + SMC_RET1(handle, SMC_UNK); + } +} + +/* Define a SPD runtime service descriptor for fast SMC calls */ +DECLARE_RT_SVC( + trusty_fast, + + SMC_ENTITY_PLATFORM_MONITOR, + SMC_ENTITY_PLATFORM_MONITOR, + SMC_TYPE_FAST, + NULL, + trusty_generic_platform_smc +); + diff --git a/services/spd/trusty/generic-arm64-smcall.h b/services/spd/trusty/generic-arm64-smcall.h new file mode 100644 index 000000000..06efc722f --- /dev/null +++ b/services/spd/trusty/generic-arm64-smcall.h @@ -0,0 +1,27 @@ +/* + * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + +#include "smcall.h" + +#define SMC_ENTITY_PLATFORM_MONITOR 61 + +/* + * SMC calls implemented by EL3 monitor + */ + +/* + * Write character in r1 to debug console + */ +#define SMC_FC_DEBUG_PUTC SMC_FASTCALL_NR(SMC_ENTITY_PLATFORM_MONITOR, 0x0) + +/* + * Get register base address + * r1: SMC_GET_GIC_BASE_GICD or SMC_GET_GIC_BASE_GICC + */ +#define SMC_GET_GIC_BASE_GICD 0 +#define SMC_GET_GIC_BASE_GICC 1 +#define SMC_FC_GET_REG_BASE SMC_FASTCALL_NR(SMC_ENTITY_PLATFORM_MONITOR, 0x1) +#define SMC_FC64_GET_REG_BASE SMC_FASTCALL64_NR(SMC_ENTITY_PLATFORM_MONITOR, 0x1) diff --git a/services/spd/trusty/trusty.c b/services/spd/trusty/trusty.c index ecbcfaeab..d6e572679 100644 --- a/services/spd/trusty/trusty.c +++ b/services/spd/trusty/trusty.c @@ -13,6 +13,7 @@ #include <interrupt_mgmt.h> #include <platform.h> #include <runtime_svc.h> +#include <stdbool.h> #include <string.h> #include "sm_err.h" @@ -21,9 +22,6 @@ /* macro to check if Hypervisor is enabled in the HCR_EL2 register */ #define HYP_ENABLE_FLAG 0x286001 -/* length of Trusty's input parameters (in bytes) */ -#define TRUSTY_PARAMS_LEN_BYTES (4096*2) - struct trusty_stack { uint8_t space[PLATFORM_STACK_SIZE] __aligned(16); uint32_t end; @@ -105,10 +103,8 @@ static struct args trusty_context_switch(uint32_t security_state, uint64_t r0, * when it's needed the PSCI caller has preserved FP context before * going here. */ -#if CTX_INCLUDE_FPREGS if (r0 != SMC_FC_CPU_SUSPEND && r0 != SMC_FC_CPU_RESUME) fpregs_context_save(get_fpregs_ctx(cm_get_context(security_state))); -#endif cm_el1_sysregs_context_save(security_state); ctx->saved_security_state = security_state; @@ -117,10 +113,8 @@ static struct args trusty_context_switch(uint32_t security_state, uint64_t r0, assert(ctx->saved_security_state == !security_state); cm_el1_sysregs_context_restore(security_state); -#if CTX_INCLUDE_FPREGS if (r0 != SMC_FC_CPU_SUSPEND && r0 != SMC_FC_CPU_RESUME) fpregs_context_restore(get_fpregs_ctx(cm_get_context(security_state))); -#endif cm_set_next_eret_context(security_state); @@ -299,6 +293,7 @@ static int32_t trusty_init(void) ep_info = bl31_plat_get_next_image_ep_info(SECURE); assert(ep_info); + fpregs_context_save(get_fpregs_ctx(cm_get_context(NON_SECURE))); cm_el1_sysregs_context_save(NON_SECURE); cm_set_context(&ctx->cpu_ctx, SECURE); @@ -315,6 +310,7 @@ static int32_t trusty_init(void) } cm_el1_sysregs_context_restore(SECURE); + fpregs_context_restore(get_fpregs_ctx(cm_get_context(SECURE))); cm_set_next_eret_context(SECURE); ctx->saved_security_state = ~0; /* initial saved state is invalid */ @@ -323,27 +319,28 @@ static int32_t trusty_init(void) trusty_context_switch_helper(&ctx->saved_sp, &zero_args); cm_el1_sysregs_context_restore(NON_SECURE); + fpregs_context_restore(get_fpregs_ctx(cm_get_context(NON_SECURE))); cm_set_next_eret_context(NON_SECURE); return 0; } -static void trusty_cpu_suspend(void) +static void trusty_cpu_suspend(uint32_t off) { struct args ret; - ret = trusty_context_switch(NON_SECURE, SMC_FC_CPU_SUSPEND, 0, 0, 0); + ret = trusty_context_switch(NON_SECURE, SMC_FC_CPU_SUSPEND, off, 0, 0); if (ret.r0 != 0) { INFO("%s: cpu %d, SMC_FC_CPU_SUSPEND returned unexpected value, %ld\n", __func__, plat_my_core_pos(), ret.r0); } } -static void trusty_cpu_resume(void) +static void trusty_cpu_resume(uint32_t on) { struct args ret; - ret = trusty_context_switch(NON_SECURE, SMC_FC_CPU_RESUME, 0, 0, 0); + ret = trusty_context_switch(NON_SECURE, SMC_FC_CPU_RESUME, on, 0, 0); if (ret.r0 != 0) { INFO("%s: cpu %d, SMC_FC_CPU_RESUME returned unexpected value, %ld\n", __func__, plat_my_core_pos(), ret.r0); @@ -352,7 +349,7 @@ static void trusty_cpu_resume(void) static int32_t trusty_cpu_off_handler(uint64_t unused) { - trusty_cpu_suspend(); + trusty_cpu_suspend(1); return 0; } @@ -364,18 +361,18 @@ static void trusty_cpu_on_finish_handler(uint64_t unused) if (!ctx->saved_sp) { trusty_init(); } else { - trusty_cpu_resume(); + trusty_cpu_resume(1); } } static void trusty_cpu_suspend_handler(uint64_t unused) { - trusty_cpu_suspend(); + trusty_cpu_suspend(0); } static void trusty_cpu_suspend_finish_handler(uint64_t unused) { - trusty_cpu_resume(); + trusty_cpu_resume(0); } static const spd_pm_ops_t trusty_pm = { @@ -385,11 +382,23 @@ static const spd_pm_ops_t trusty_pm = { .svc_suspend_finish = trusty_cpu_suspend_finish_handler, }; +void plat_trusty_set_boot_args(aapcs64_params_t *args); + +#ifdef TSP_SEC_MEM_SIZE +#pragma weak plat_trusty_set_boot_args +void plat_trusty_set_boot_args(aapcs64_params_t *args) +{ + args->arg0 = TSP_SEC_MEM_SIZE; +} +#endif + static int32_t trusty_setup(void) { entry_point_info_t *ep_info; + uint32_t instr; uint32_t flags; int ret; + bool aarch32 = false; /* Get trusty's entry point info */ ep_info = bl31_plat_get_next_image_ep_info(SECURE); @@ -398,17 +407,29 @@ static int32_t trusty_setup(void) return -1; } - /* Trusty runs in AARCH64 mode */ - SET_PARAM_HEAD(ep_info, PARAM_EP, VERSION_1, SECURE | EP_ST_ENABLE); - ep_info->spsr = SPSR_64(MODE_EL1, MODE_SP_ELX, DISABLE_ALL_EXCEPTIONS); + instr = *(uint32_t *)ep_info->pc; - /* - * arg0 = TZDRAM aperture available for BL32 - * arg1 = BL32 boot params - * arg2 = BL32 boot params length - */ - ep_info->args.arg1 = ep_info->args.arg2; - ep_info->args.arg2 = TRUSTY_PARAMS_LEN_BYTES; + if (instr >> 24 == 0xeaU) { + INFO("trusty: Found 32 bit image\n"); + aarch32 = true; + } else if (instr >> 8 == 0xd53810U || instr >> 16 == 0x9400U) { + INFO("trusty: Found 64 bit image\n"); + } else { + NOTICE("trusty: Found unknown image, 0x%x\n", instr); + } + + SET_PARAM_HEAD(ep_info, PARAM_EP, VERSION_1, SECURE | EP_ST_ENABLE); + if (!aarch32) + ep_info->spsr = SPSR_64(MODE_EL1, MODE_SP_ELX, + DISABLE_ALL_EXCEPTIONS); + else + ep_info->spsr = SPSR_MODE32(MODE32_svc, SPSR_T_ARM, + SPSR_E_LITTLE, + DAIF_FIQ_BIT | + DAIF_IRQ_BIT | + DAIF_ABT_BIT); + (void)memset(&ep_info->args, 0, sizeof(ep_info->args)); + plat_trusty_set_boot_args(&ep_info->args); /* register init handler */ bl31_register_bl32_init(trusty_init); @@ -425,6 +446,31 @@ static int32_t trusty_setup(void) if (ret) ERROR("trusty: failed to register fiq handler, ret = %d\n", ret); + if (aarch32) { + entry_point_info_t *ns_ep_info; + uint32_t spsr; + + ns_ep_info = bl31_plat_get_next_image_ep_info(NON_SECURE); + if (!ep_info) { + NOTICE("Trusty: non-secure image missing.\n"); + return -1; + } + spsr = ns_ep_info->spsr; + if (GET_RW(spsr) == MODE_RW_64 && GET_EL(spsr) == MODE_EL2) { + spsr &= ~(MODE_EL_MASK << MODE_EL_SHIFT); + spsr |= MODE_EL1 << MODE_EL_SHIFT; + } + if (GET_RW(spsr) == MODE_RW_32 && GET_M32(spsr) == MODE32_hyp) { + spsr &= ~(MODE32_MASK << MODE32_SHIFT); + spsr |= MODE32_svc << MODE32_SHIFT; + } + if (spsr != ns_ep_info->spsr) { + NOTICE("Trusty: Switch bl33 from EL2 to EL1 (spsr 0x%x -> 0x%x)\n", + ns_ep_info->spsr, spsr); + ns_ep_info->spsr = spsr; + } + } + return 0; } diff --git a/services/spd/trusty/trusty.mk b/services/spd/trusty/trusty.mk index beca875ea..a571fa2cd 100644 --- a/services/spd/trusty/trusty.mk +++ b/services/spd/trusty/trusty.mk @@ -8,3 +8,11 @@ SPD_INCLUDES := SPD_SOURCES := services/spd/trusty/trusty.c \ services/spd/trusty/trusty_helpers.S + +ifeq (${TRUSTY_SPD_WITH_GENERIC_SERVICES},1) +SPD_SOURCES += services/spd/trusty/generic-arm64-smcall.c +endif + +NEED_BL32 := yes + +CTX_INCLUDE_FPREGS := 1 diff --git a/services/std_svc/spm/spm_main.c b/services/std_svc/spm/spm_main.c index d31fad67e..6c4e1f0f7 100644 --- a/services/std_svc/spm/spm_main.c +++ b/services/std_svc/spm/spm_main.c @@ -14,8 +14,8 @@ #include <platform.h> #include <runtime_svc.h> #include <secure_partition.h> -#include <smcc.h> -#include <smcc_helpers.h> +#include <smccc.h> +#include <smccc_helpers.h> #include <spinlock.h> #include <spm_svc.h> #include <utils.h> diff --git a/services/std_svc/std_svc_setup.c b/services/std_svc/std_svc_setup.c index eae078ed8..41befe5b2 100644 --- a/services/std_svc/std_svc_setup.c +++ b/services/std_svc/std_svc_setup.c @@ -12,7 +12,7 @@ #include <runtime_instr.h> #include <runtime_svc.h> #include <sdei.h> -#include <smcc_helpers.h> +#include <smccc_helpers.h> #include <spm_svc.h> #include <std_svc.h> #include <stdint.h> diff --git a/tools/cert_create/Makefile b/tools/cert_create/Makefile index 437b69278..b0994b8ca 100644 --- a/tools/cert_create/Makefile +++ b/tools/cert_create/Makefile @@ -35,7 +35,7 @@ PLAT_INCLUDE := ../../include/tools_share else PLAT_MSG := ${PLAT} -PLATFORM_ROOT := ../../plat/ +TF_PLATFORM_ROOT := ../../plat/ include ${MAKE_HELPERS_DIRECTORY}plat_helpers.mk PLAT_INCLUDE := $(wildcard ${PLAT_DIR}include) |