- 08 Apr, 2016 1 commit
-
-
Antonio Nino Diaz authored
Previously, when building TF without SPD support, BL2 tried to load a BL32 image from the FIP and fails to find one, which resulted on warning messages on the console. Even if there is a BL32 image in the FIP it shouldn't be loaded because there is no way to transfer control to the Secure Payload without SPD support. The Makefile has been modified to pass a define of the form SPD_${SPD} to the source code the same way it's done for PLAT. The define SPD_none is then used to undefine BL32_BASE when BL32 is not used to prevent BL2 from trying to load a BL32 image and failing, thus removing the warning messages mentioned above. Fixes ARM-software/tf-issues#287 Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
-
- 01 Apr, 2016 1 commit
-
-
Soby Mathew authored
This patch modifies the return type of the platform API `plat_get_ns_image_entrypoint()` from `unsigned long` to `uintptr_t` in accordance with the coding guidelines. Change-Id: Icb4510ca98b706aa4d535fe27e203394184fb4ca
-
- 31 Mar, 2016 1 commit
-
-
David Wang authored
This patch adds an option to the ARM common platforms to load BL31 in the TZC secured DRAM instead of the default secure SRAM. To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options. If TSP is present, then setting this option also sets the TSP location to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag. To use this feature, BL2 platform code must map in the DRAM used by BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose. Currently, only the FVP BL2 platform code maps in this DRAM. Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
-
- 14 Mar, 2016 1 commit
-
-
Antonio Nino Diaz authored
Added a new platform porting function plat_panic_handler, to allow platforms to handle unexpected error situations. It must be implemented in assembly as it may be called before the C environment is initialized. A default implementation is provided, which simply spins. Corrected all dead loops in generic code to call this function instead. This includes the dead loop that occurs at the end of the call to panic(). All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have been removed. Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
-
- 22 Feb, 2016 2 commits
-
-
Yatharth Kochar authored
This patch fixes inconsistencies in bl1_tbbr_image_descs[] and miscellaneous fixes in Firmware Update code. Following are the changes: * As part of the original FWU changes, a `copied_size` field was added to `image_info_t`. This was a subtle binary compatibility break because it changed the size of the `bl31_params_t` struct, which could cause problems if somebody used different versions of BL2 or BL31, one with the old `image_info_t` and one with the new version. This patch put the `copied_size` within the `image_desc_t`. * EXECUTABLE flag is now stored in `ep_info.h.attr` in place of `image_info.h.attr`, associating it to an entrypoint. * The `image_info.image_base` is only relevant for secure images that are copied from non-secure memory into secure memory. This patch removes initializing `image_base` for non secure images in the bl1_tbbr_image_descs[]. * A new macro `SET_STATIC_PARAM_HEAD` is added for populating bl1_tbbr_image_descs[].ep_info/image_info.h members statically. The version, image_type and image attributes are now populated using this new macro. * Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c. * Refactoring of code/macros related to SECURE and EXECUTABLE flags. NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t` OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr` OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY. Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
-
Vikram Kanigiri authored
`board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
-
- 19 Feb, 2016 1 commit
-
-
Soby Mathew authored
The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
-
- 18 Feb, 2016 1 commit
-
-
Juan Castillo authored
The shared memory region on ARM platforms contains the mailboxes and, on Juno, the payload area for communication with the SCP. This shared memory may be configured as normal memory or device memory at build time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED'). When set as normal memory, the platform port performs the corresponding cache maintenance operations. From a functional point of view, this is the equivalent of setting the shared memory as device memory, so there is no need to maintain both options. This patch removes the option to specify the shared memory as normal memory on ARM platforms. Shared memory is always treated as device memory. Cache maintenance operations are no longer needed and have been replaced by data memory barriers to guarantee that payload and MHU are accessed in the right order. Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
-
- 16 Feb, 2016 2 commits
-
-
Vikram Kanigiri authored
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
-
Vikram Kanigiri authored
Current code mandates loading of SCP_BL2/SCP_BL2U images for all CSS platforms. On future ARM CSS platforms, the Application Processor (AP) might not need to load these images. So, these items can be removed from the FIP on those platforms. BL2 tries to load SCP_BL2/SCP_BL2U images if their base addresses are defined causing boot error if the images are not found in FIP. This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set to `1` does: 1. Adds SCP_BL2, SCP_BL2U images to FIP. 2. Defines the base addresses of these images so that AP loads them. And vice-versa if it is set to `0`. The default value is set to `1`. Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
-
- 15 Feb, 2016 3 commits
-
-
Vikram Kanigiri authored
Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
-
Vikram Kanigiri authored
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
-
Vikram Kanigiri authored
Functions to configure the MMU in S-EL1 and EL3 on ARM platforms expect each platform to export its memory map in the `plat_arm_mmap` data structure. This approach does not scale well in case the memory map cannot be determined until runtime. To cater for this possibility, this patch introduces the plat_arm_get_mmap() API. It returns a reference to the `plat_arm_mmap` by default but can be overridden by a platform if required. Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74
-
- 11 Feb, 2016 2 commits
-
-
Vikram Kanigiri authored
Each ARM Compute Subsystem based platform implements a System Security Control (SSC) Registers Unit. The SSC_VERSION register inside it carries information to identify the platform. This enables ARM Trusted Firmware to compile in support for multiple ARM platforms and choose one at runtime. This patch adds macros to enable access to this register. Each platform is expected to export its PART_NUMBER separately. Additionally, it also adds juno part number. Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
-
Vikram Kanigiri authored
This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
-
- 05 Feb, 2016 1 commit
-
-
Antonio Nino Diaz authored
Replaced a long dash in a comment by the ASCII character '-'. Support for multibyte character in the source character set is not enforced by the C99 standard. To maximize compatibility with C processing tools (e.g. compilers or static code analysis tools), they should be removed. Change-Id: Ie318e380d3b44755109f042a76ebfd2229f42ae3
-
- 21 Jan, 2016 1 commit
-
-
Juan Castillo authored
The PL011 TRM (ARM DDI 0183G) specifies that the UART must be disabled before any of the control registers are programmed. The PL011 driver included in TF does not disable the UART, so the initialization in BL2 and BL31 is violating this requirement (and potentially in BL1 if the UART is enabled after reset). This patch modifies the initialization function in the PL011 console driver to disable the UART before programming the control registers. Register clobber list and documentation updated. Fixes ARM-software/tf-issues#300 Change-Id: I839b2d681d48b03f821ac53663a6a78e8b30a1a1
-
- 20 Jan, 2016 1 commit
-
-
Juan Castillo authored
Currently, Trusted Firmware on ARM platforms unlocks access to the timer frame registers that will be used by the Non-Secure world. This unlock operation should be done by the Non-Secure software itself, instead of relying on secure firmware settings. This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR' to unlock access to the timer frame by setting the corresponding bits in the CNTACR<N> register. The frame id <N> is defined by 'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer access). Documentation updated accordingly. Fixes ARM-software/tf-issues#170 Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
-
- 14 Jan, 2016 1 commit
-
-
Soren Brinkmann authored
Migrate all direct usage of __attribute__ to usage of their corresponding macros from cdefs.h. e.g.: - __attribute__((unused)) -> __unused Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
-
- 13 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP. This allows the same TF binaries to run on a Cortex-A72 based FVP without recompiling them. Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
-
- 12 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch adds support for ARM Cortex-A35 processor in the CPU specific framework, as described in the Cortex-A35 TRM (r0p0). Change-Id: Ief930a0bdf6cd82f6cb1c3b106f591a71c883464
-
- 05 Jan, 2016 1 commit
-
-
Juan Castillo authored
The fip_create tool specifies images in the command line using the ARM TF naming convention (--bl2, --bl31, etc), while the cert_create tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double convention is confusing and should be aligned. This patch updates the fip_create command line options to follow the TBBR naming convention. Usage examples in the User Guide have been also updated. NOTE: users that build the FIP by calling the fip_create tool directly from the command line must update the command line options in their scripts. Users that build the FIP by invoking the main ARM TF Makefile should not notice any difference. Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
-
- 21 Dec, 2015 2 commits
-
-
Sandrine Bailleux authored
Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b
-
Sandrine Bailleux authored
fvp_pwr_domain_on() used to program the CPUs mailbox. This changed with commit 804040d1 but the comment documenting this code still refers to the mailbox programming. This patch removes this out-dated information. Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c
-
- 15 Dec, 2015 1 commit
-
-
Dan Handley authored
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes an unused framework cookie through to the 1st argument in the platform function `bl1_plat_fwu_done`. The intent is to allow the SMC caller to pass a cookie through to this function. This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller through to `bl1_plat_fwu_done`. The argument names are updated for clarity. Upstream platforms currently do not use this argument so no impact is expected. Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
-
- 14 Dec, 2015 3 commits
-
-
Juan Castillo authored
This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
-
Juan Castillo authored
This patch replaces all references to the SCP Firmware (BL0, BL30, BL3-0, bl30) with the image terminology detailed in the TF wiki (https://github.com/ARM-software/arm-trusted-firmware/wiki): BL0 --> SCP_BL1 BL30, BL3-0 --> SCP_BL2 bl30 --> scp_bl2 This change affects code, documentation, build system, tools and platform ports that load SCP firmware. ARM plaforms have been updated to the new porting API. IMPORTANT: build option to specify the SCP FW image has changed: BL30 --> SCP_BL2 IMPORTANT: This patch breaks compatibility for platforms that use BL2 to load SCP firmware. Affected platforms must be updated as follows: BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID BL30_BASE --> SCP_BL2_BASE bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo() bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2() Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
-
Juan Castillo authored
This patch applies the TBBR naming convention to the certificates and the corresponding extensions defined by the CoT: * Certificate UUID names * Certificate identifier names * OID names Changes apply to: * Generic code (variables and defines) * The default certificate identifiers provided in the generic code * Build system * ARM platforms port * cert_create tool internal definitions * fip_create and cert_create tools command line options * Documentation IMPORTANT: this change breaks the compatibility with platforms that use TBBR. The platform will need to adapt the identifiers and OIDs to the TBBR naming convention introduced by this patch: Certificate UUIDs: UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT Certificate identifiers: BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID OIDs: TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID BL30_HASH_OID --> SCP_FW_HASH_OID BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID BL31_HASH_OID --> SOC_AP_FW_HASH_OID BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID NS_BL2U_HASH_OID --> FWU_HASH_OID Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
-
- 09 Dec, 2015 8 commits
-
-
Yatharth Kochar authored
Firmware update feature needs a new FIP called `fwu_fip.bin` that includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images along with the FWU_CERT certificate in order for NS_BL1U to load the images and help the Firmware update process to complete. This patch adds the capability to support the new target `fwu_fip` which includes above mentioned FWU images in the make files. The new target of `fwu_fip` and its dependencies are included for compilation only when `TRUSTED_BOARD_BOOT` is defined. Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc
-
Yatharth Kochar authored
This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
-
Yatharth Kochar authored
This patch adds Firmware Update support for ARM platforms. New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide platform specific Firmware update code. BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for authenticating NS_BL2U image(For both FVP and JUNO platform). Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
-
Yatharth Kochar authored
As of now BL1 loads and execute BL2 based on hard coded information provided in BL1. But due to addition of support for upcoming Firmware Update feature, BL1 now require more flexible approach to load and run different images using information provided by the platform. This patch adds new mechanism to load and execute images based on platform provided image id's. BL1 now queries the platform to fetch the image id of the next image to be loaded and executed. In order to achieve this, a new struct image_desc_t was added which holds the information about images, such as: ep_info and image_info. This patch introduces following platform porting functions: unsigned int bl1_plat_get_next_image_id(void); This is used to identify the next image to be loaded and executed by BL1. struct image_desc *bl1_plat_get_image_desc(unsigned int image_id); This is used to retrieve the image_desc for given image_id. void bl1_plat_set_ep_info(unsigned int image_id, struct entry_point_info *ep_info); This function allows platforms to update ep_info for given image_id. The plat_bl1_common.c file provides default weak implementations of all above functions, the `bl1_plat_get_image_desc()` always return BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns. These functions gets compiled into all BL1 platforms by default. Platform setup in BL1, using `bl1_platform_setup()`, is now done _after_ the initialization of authentication module. This change provides the opportunity to use authentication while doing the platform setup in BL1. In order to store secure/non-secure context, BL31 uses percpu_data[] to store context pointer for each core. In case of BL1 only the primary CPU will be active hence percpu_data[] is not required to store the context pointer. This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to store the context and context pointers respectively. It also also re-defines cm_get_context() and cm_set_context() for BL1 in bl1/bl1_context_mgmt.c. BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime environment, to support resuming execution from a previously saved context. NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()` INSTEAD TO MAINTAIN EXISTING BEHAVIOUR. Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
-
Yatharth Kochar authored
This patch adds support for secure setup of the SoC on CSS platforms in BL1. This change is required to provide memory access to normal world images that take part in upcoming Firmware Update feature. Change-Id: Ib202fb6cb82622c1874b700637d82ea72575e6fe
-
Soby Mathew authored
This patch overrides the default weak definition of `bl31_plat_runtime_setup()` for ARM Standard platforms to specify a BL31 runtime console. ARM Standard platforms are now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required by `arm_bl31_plat_runtime_setup()` to initialize the runtime console. The system suspend resume helper `arm_system_pwr_domain_resume()` is fixed to initialize the runtime console rather than the boot console on resumption from system suspend. Fixes ARM-software/tf-issues#220 Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
-
Achin Gupta authored
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
-
Soby Mathew authored
This patch adds platform helpers for the new GICv2 and GICv3 drivers in plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate file in their build according to the GIC driver to be used. The existing plat_gic.c is only meant for the legacy GIC driver. In the case of ARM platforms, the major changes are as follows: 1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU interface register values has been modified to detect the type of CPU interface being used (System register or memory mappped interface) before using the right interface to print the registers. 2. The power management helper function that is called after a core is powered up has been further refactored. This is to highlight that the per-cpu distributor interface should be initialised only when the core was originally powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API was used. 3. In the case of CSS platforms, the system power domain restore helper `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish` handler as the system power domain is always expected to be initialized when the `on_finish` handler is invoked. Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
-
- 04 Dec, 2015 1 commit
-
-
Juan Castillo authored
This patch fixes several issues with the SP804 delay timer on FVP: * By default, the SP804 dual timer on FVP runs at 32 KHz. In order to run the timer at 35 MHz (as specified in the FVP user manual) the Overwrite bit in the SP810 control register must be set. * The CLKMULT and CLKDIV definitions are mixed up: delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz) From the delay function: delta_us = (delta * ops->clk_mult) / ops->clk_div; Matching both expressions: 1 / f(MHz) = ops->clk_mult / ops->clk_div And consequently: f(MHz) = ops->clk_div / ops->clk_mult Which, for a 35 MHz timer, translates to: ops->clk_div = 35 ops->clk_mult = 1 * The comment in the delay timer header file has been corrected: The ratio of the multiplier and the divider is the clock period in microseconds, not the frequency. Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
-
- 02 Dec, 2015 1 commit
-
-
Juan Castillo authored
This patch adds watchdog support on ARM platforms (FVP and Juno). A secure instance of SP805 is used as Trusted Watchdog. It is entirely managed in BL1, being enabled in the early platform setup hook and disabled in the exit hook. By default, the watchdog is enabled in every build (even when TBB is disabled). A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG` has been introduced to allow the user to disable the watchdog at build time. This feature may be used for testing or debugging purposes. Specific error handlers for Juno and FVP are also provided in this patch. These handlers will be called after an image load or authentication error. On FVP, the Table of Contents (ToC) in the FIP is erased. On Juno, the corresponding error code is stored in the V2M Non-Volatile flags register. In both cases, the CPU spins until a watchdog reset is generated after 256 seconds (as specified in the TBBR document). Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
-
- 27 Nov, 2015 1 commit
-
-
Juan Castillo authored
FVP and Juno platforms include a NOR flash memory to store and load the FIP, the kernel or a ramdisk. This NOR flash is arranged as 2 x 16 bit flash devices and can be programmed using CFI standard commands. This patch provides a basic API to write single 32 bit words of data into the NOR flash. Functions to lock/unlock blocks against erase or write operations are also provided. Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
-
- 26 Nov, 2015 1 commit
-
-
Sandrine Bailleux authored
Normally, in the FVP port, secondary CPUs are immediately powered down if they are powered on at reset. However, when booting an EL3 payload, we need to keep them powered on as the requirement is for all CPUs to enter the EL3 payload image. This patch puts them in a holding pen instead of powering them off. Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
-