- 12 Feb, 2015 1 commit
-
-
Soby Mathew authored
This patch defines MAX_MMAP_REGIONS separately for each BL stage as per its requirements. This minimizes the size of the mmap[] array. Fixes ARM-Software/tf-issues#201 Change-Id: I19b15e1a91a8365b2ecf24e2cd71937cb73916b2
-
- 28 Jan, 2015 3 commits
-
-
Juan Castillo authored
This patch adds support to authenticate the Trusted Key certificate and the BL3-x certificates and images at BL2. Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd
-
Juan Castillo authored
This patch adds support to authenticate the BL2 content certificate and image using the authentication module in BL1. The FIP driver has been extended to include the BL2 certificate UUID. FVP and Juno ports include the BL2 certificate FIP file definition. Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
-
Juan Castillo authored
This patch implements an authentication module based on the PolarSSL library (v1.3.9) to verify the Chain of Trust when Trusted Boot is enabled. PolarSSL sources must be fetched separately. The POLARSSL_DIR build option may be used to indicate the path to the PolarSSL main directory (this directory must contain the 'include' and 'library' subdirectories). To be able to build PolarSSL sources as a part of the Trusted Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk will tell the build system to remove the -pedantic option from the CFLAGS. Inclusion of PolarSSL increases the memory requirements of the BL1 and BL2 images. The following are the changes made to the FVP and Juno platforms to cater for this when TRUSTED_BOARD_BOOT is defined: Changes on FVP: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - BL2 memory region has been increased to 112 KB Changes on Juno: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - Trusted ROM region in Flash has been increased to 128 KB. - BL2 memory region has been increased to 116 KB Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
-
- 26 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch allows the secure payload (BL3-2) to be loaded in the DRAM region secured by the TrustZone controller (top 16 MB of DRAM1). The location of BL3-2 can be selected at build time by setting the build flag FVP_TSP_RAM_LOCATION to one of the following options: - 'tsram' : Trusted SRAM (this is the default option) - 'tdram' : Trusted DRAM - 'dram' : Secure region in DRAM1 (top 16MB configured by the TrustZone controller) The number of MMU tables in BL3-2 depends on its location in memory: 3 in case it is loaded in DRAM, 2 otherwise. Documentation updated accordingly. Fixes ARM-software/tf-issues#212 Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
-
- 22 Jan, 2015 1 commit
-
-
Soby Mathew authored
This patch moves the bakery locks out of coherent memory to normal memory. This implies that the lock information needs to be placed on a separate cache line for each cpu. Hence the bakery_lock_info_t structure is allocated in the per-cpu data so as to minimize memory wastage. A similar platform per-cpu data is introduced for the platform locks. As a result of the above changes, the bakery lock api is completely changed. Earlier, a reference to the lock structure was passed to the lock implementation. Now a unique-id (essentially an index into the per-cpu data array) and an offset into the per-cpu data for bakery_info_t needs to be passed to the lock implementation. Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
-
- 21 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch maps the non-secure region of DRAM1 in the MMU. The non-secure region comprises the whole DRAM1 (0x80000000 - 0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff). The TrustZone controller configures this 16 MB region as secure memory, so it can not be accessed in non-secure mode. The number of MMU tables in BL2 has been increased to 3 because the new size of the non-secure region in DRAM requires an extra L2 table. Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
-
- 22 Oct, 2014 1 commit
-
-
Juan Castillo authored
This patch deprecates the build option to relocate the shared data into Trusted DRAM in FVP. After this change, shared data is always located at the base of Trusted SRAM. This reduces the complexity of the memory map and the number of combinations in the build options. Fixes ARM-software/tf-issues#257 Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
-
- 19 Aug, 2014 1 commit
-
-
Dan Handley authored
* Move TSP platform porting functions to new file: include/bl32/tsp/platform_tsp.h. * Create new TSP_IRQ_SEC_PHY_TIMER definition for use by the generic TSP interrupt handling code, instead of depending on the FVP specific definition IRQ_SEC_PHY_TIMER. * Rename TSP platform porting functions from bl32_* to tsp_*, and definitions from BL32_* to TSP_*. * Update generic TSP code to use new platform porting function names and definitions. * Update FVP port accordingly and move all TSP source files to: plat/fvp/tsp/. * Update porting guide with above changes. Note: THIS CHANGE REQUIRES ALL PLATFORM PORTS OF THE TSP TO BE UPDATED Fixes ARM-software/tf-issues#167 Change-Id: Ic0ff8caf72aebb378d378193d2f017599fc6b78f
-
- 14 Aug, 2014 2 commits
-
-
Dan Handley authored
* Create cci_init() function in CCI-400 driver to allow platform to provide arguments needed by the driver (i.e. base address and cluster indices for the ACE slave interfaces). * Rename cci_(en|dis)able_coherency to cci_(en|dis)able_cluster_coherency to make it clear that the driver only enables/disables the coherency of CPU clusters and not other devices connected to the CCI-400. * Update FVP port to use new cci_init() function and remove unnecessary CCI defintions from platform_def.h. Also rename fvp_cci_setup() to fvp_cci_enable() to more clearly differentiate between CCI initialization and enabling. THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER TO BE UPDATED Fixes ARM-software/tf-issues#168 Change-Id: I1946a51409b91217b92285b6375082619f607fec
-
Juan Castillo authored
This patch groups the current contents of the Trusted DRAM region at address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in a single shared memory area that may be allocated to Trusted SRAM (default) or Trusted DRAM at build time by setting the FVP_SHARED_DATA_LOCATION make variable. The size of this shared memory is 4096 bytes. The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM' is not currently supported due to restrictions in the maximum number of mmu tables that can be created. Documentation has been updated to reflect these changes. Fixes ARM-software/tf-issues#100 Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
-
- 12 Aug, 2014 2 commits
-
-
Dan Handley authored
Fix the following issues with the console log output: * Make sure the welcome string is the first thing in the log output (during normal boot). * Prefix each message with the BL image name so it's clear which BL the output is coming from. * Ensure all output is wrapped in one of the log output macros so it can be easily compiled out if necessary. Change some of the INFO() messages to VERBOSE(), especially in the TSP. * Create some extra NOTICE() and INFO() messages during cold boot. * Remove all usage of \r in log output. Fixes ARM-software/tf-issues#231 Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3
-
Juan Castillo authored
Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM BLn_BASE and BLn_LIMIT definitions have been updated and are based on these new memory regions. The available memory for each bootloader in the linker script is defined by BLn_BASE and BLn_LIMIT, instead of the complete memory region. TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of the platform porting. FVP common definitions are defined in fvp_def.h while platform_def.h contains exclusively (with a few exceptions) the definitions that are mandatory in the porting guide. Therefore, platform_def.h now includes fvp_def.h instead of the other way around. Porting guide has been updated to reflect these changes. Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
-
- 11 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch separates the stack size for each BL stage and reduces it after stack usage analysis was done. Fixes ARM-software/tf-issues#200 Change-Id: I8edc6de2551b0a6788761d121937692b2149bb29
-
- 01 Aug, 2014 1 commit
-
-
Juan Castillo authored
The purpose of platform_is_primary_cpu() is to determine after reset (BL1 or BL3-1 with reset handler) if the current CPU must follow the cold boot path (primary CPU), or wait in a safe state (secondary CPU) until the primary CPU has finished the system initialization. This patch removes redundant calls to platform_is_primary_cpu() in subsequent bootloader entrypoints since the reset handler already guarantees that code is executed exclusively on the primary CPU. Additionally, this patch removes the weak definition of platform_is_primary_cpu(), so the implementation of this function becomes mandatory. Removing the weak symbol avoids other bootloaders accidentally picking up an invalid definition in case the porting layer makes the real function available only to BL1. The define PRIMARY_CPU is no longer mandatory in the platform porting because platform_is_primary_cpu() hides the implementation details (for instance, there may be platforms that report the primary CPU in a system register). The primary CPU definition in FVP has been moved to fvp_def.h. The porting guide has been updated accordingly. Fixes ARM-software/tf-issues#219 Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e
-
- 28 Jul, 2014 1 commit
-
-
Achin Gupta authored
This patch removes the allocation of memory for coherent stacks, associated accessor function and some dead code which called the accessor function. It also updates the porting guide to remove the concept and the motivation behind using stacks allocated in coherent memory. Fixes ARM-software/tf-issues#198 Change-Id: I00ff9a04f693a03df3627ba39727e3497263fc38
-
- 10 Jul, 2014 1 commit
-
-
Sandrine Bailleux authored
This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
-
- 23 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
The array of affinity nodes is currently allocated for 32 entries with the PSCI_NUM_AFFS value defined in psci.h. This is not enough for large systems, and will substantially over allocate the array for small systems. This patch introduces an optional platform definition PLATFORM_NUM_AFFS to platform_def.h. If defined this value is used for PSCI_NUM_AFFS, otherwise a value of two times the number of CPU cores is used. The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves nearly 1.5KB of memory. Fixes ARM-software/tf-issues#192 Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445
-
- 20 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
This memory is not used by the FVP port and requires an additional 4KB translation table. This patch removes the entry from the memory map and reduces the number of allocated translation tables. Fixes ARM-software/tf-issues#196 Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
-
- 23 May, 2014 1 commit
-
-
Dan Handley authored
Previously, platform.h contained many declarations and definitions used for different purposes. This file has been split so that: * Platform definitions used by common code that must be defined by the platform are now in platform_def.h. The exact include path is exported through $PLAT_INCLUDES in the platform makefile. * Platform definitions specific to the FVP platform are now in /plat/fvp/fvp_def.h. * Platform API declarations specific to the FVP platform are now in /plat/fvp/fvp_private.h. * The remaining platform API declarations that must be ported by each platform are still in platform.h but this file has been moved to /include/plat/common since this can be shared by all platforms. Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
-