- 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
-
- 22 Jan, 2015 1 commit
-
-
Soby Mathew authored
This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
-
- 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
-
- 25 Sep, 2014 1 commit
-
-
Soby Mathew authored
This patch uses the IMAGE_BL<x> constants to create translation tables specific to a boot loader stage. This allows each stage to create mappings only for areas in the memory map that it needs. Fixes ARM-software/tf-issues#209 Change-Id: Ie4861407ddf9317f0fb890fc7575eaa88d0de51c
-
- 20 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch adds CPU core and cluster power down sequences to the CPU specific operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and generic AEM sequences have been added. The latter is suitable for the Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is saved in the per-cpu data so that it can be easily accessed during power down seqeunces. An optional platform API has been introduced to allow a platform to disable the Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak definition of this function (plat_disable_acp()) does not take any action. It should be overriden with a strong definition if the ACP is present on a platform. Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d
-
- 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 1 commit
-
-
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
-
- 28 Jul, 2014 1 commit
-
-
Juan Castillo authored
Assert a valid security state using the macro sec_state_is_valid(). Replace assert() with panic() in those cases that might arise because of runtime errors and not programming errors. Replace panic() with assert() in those cases that might arise because of programming errors. Fixes ARM-software/tf-issues#96 Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5
-
- 19 Jul, 2014 1 commit
-
-
Achin Gupta authored
This patch adds a 'flags' parameter to each exception level specific function responsible for enabling the MMU. At present only a single flag which indicates whether the data cache should also be enabled is implemented. Subsequent patches will use this flag when enabling the MMU in the warm boot paths. Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa
-
- 09 Jul, 2014 2 commits
-
-
Dan Handley authored
Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform specific inputs in the arm_gic_setup() function so that the driver has no explicit dependency on platform code. Provide weak implementations of the platform interrupt controller API in a new file, plat/common/plat_gic.c. These simply call through to the ARM GIC driver. Move the only remaining FVP GIC function, fvp_gic_init() to plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c Fixes ARM-software/tf-issues#182 Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
-
Dan Handley authored
Changed the fvp_config array in fvp_common.c into a struct and moved into a new optional common platform header, include/plat/common/plat_config.h. Removed the config definitions in fvp_def.h and updated all references to the platform config. This makes the interface to the platform config cleaner and uses a little less RAM. Fixes ARM-software/tf-issues#180 Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
-
- 27 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
The code in the FVP port which checks the platform type and revision information in the SYS_ID register strictly supported only the first revision of the Base and Foundation FVPs. The current check also does not reflect the fact that the board revision field is 'local' to the board type (HBI field). Support for a new Foundation model is required now, and the checking code is relaxed to allow execution (with a diagnostic) on unrecognised revisions of the Base and Foundation FVP. Change-Id: I7cd3519dfb56954aafe5f52ce1fcea0ee257ba9f
-
- 24 Jun, 2014 1 commit
-
-
Vikram Kanigiri authored
This patch reworks FVP specific code responsible for determining the entry point information for BL3-2 and BL3-3 stages when BL3-1 is configured as the reset handler. Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec
-
- 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
-
- 02 Jun, 2014 1 commit
-
-
Lin Ma authored
Current ATF uses a direct physical-to-virtual mapping, that is, a physical address is mapped to the same address in the virtual space. For example, physical address 0x8000_0000 is mapped to 0x8000_0000 virtual. This approach works fine for FVP as all its physical addresses fall into 0 to 4GB range. But for other platform where all I/O addresses are 48-bit long, If we follow the same direct mapping, we would need virtual address range from 0 to 0x8fff_ffff_ffff, which is about 144TB. This requires a significant amount of memory for MMU tables and it is not necessary to use that much virtual space in ATF. The patch is to enable mapping a physical address range to an arbitrary virtual address range (instead of flat mapping) Changed "base" to "base_va" and added "base_pa" in mmap_region_t and modified functions such as mmap_add_region and init_xlation_table etc. Fixes ARM-software/tf-issues#158
-
- 23 May, 2014 3 commits
-
-
Dan Handley authored
Previously, the enable_mmu_elX() functions were implicitly part of the platform porting layer since they were included by generic code. These functions have been placed behind 2 new platform functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu(). These are weakly defined so that they can be optionally overridden by platform ports. Also, the enable_mmu_elX() functions have been moved to lib/aarch64/xlat_tables.c for optional re-use by platform ports. These functions are tightly coupled with the translation table initialization code. Fixes ARM-software/tf-issues#152 Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
-
Dan Handley authored
FVP specific files and functions containing the word "plat" have been renamed to use the word "fvp" to distinguish them from the common platform functionality and porting functions. Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
-
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
-
- 22 May, 2014 3 commits
-
-
Juan Castillo authored
TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and the rest of DRAM as non-secure. Non-secure software must not attempt to access the 16MB secure area. Device tree files (sources and binaries) have been updated to match this configuration, removing that memory from the Linux physical memory map. To use UEFI and Linux with this patch, the latest version of UEFI and the updated device tree files are required. Check the user guide in the documentation for more details. Replaced magic numbers with #define for memory region definition in the platform security initialization function. Fixes ARM-software/tf-issues#149 Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
-
Vikram Kanigiri authored
This change adds optional reset vector support to BL3-1 which means BL3-1 entry point can detect cold/warm boot, initialise primary cpu, set up cci and mail box. When using BL3-1 as a reset vector it is assumed that the BL3-1 platform code can determine the location of the BL3-2 images, or load them as there are no parameters that can be passed to BL3-1 at reset. It also fixes the incorrect initialisation of mailbox registers on the FVP platform This feature can be enabled by building the code with make variable RESET_TO_BL31 set as 1 Fixes ARM-software/TF-issues#133 Fixes ARM-software/TF-issues#20 Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
-
Vikram Kanigiri authored
The issues addressed in this patch are: 1. Remove meminfo_t from the common interfaces in BL3-x, expecting that platform code will find a suitable mechanism to determine the memory extents in these images and provide it to the BL3-x images. 2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x code as the images use link-time information to determine memory extents. meminfo_t is still used by common interface in BL1/BL2 for loading images Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f
-
- 09 May, 2014 2 commits
-
-
Sandrine Bailleux authored
Instead of having a single version of the MMU setup functions for all bootloader images that can execute either in EL3 or in EL1, provide separate functions for EL1 and EL3. Each bootloader image can then call the appropriate version of these functions. The aim is to reduce the amount of code compiled in each BL image by embedding only what's needed (e.g. BL1 to embed only EL3 variants). Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa
-
Sandrine Bailleux authored
The goal of these macros is to improve code readability by providing a concise way to check whether we are running in the expected exception level. Change-Id: If9aebadfb6299a5196e9a582b442f0971d9909b1
-
- 07 May, 2014 2 commits
-
-
Andrew Thoelke authored
disable_mmu() cannot work as a C function as there is no control over data accesses generated by the compiler between disabling and cleaning the data cache. This results in reading stale data from main memory. As assembler version is provided for EL3, and a variant that also disables the instruction cache which is now used by the BL1 exception handling function. Fixes ARM-software/tf-issues#147 Change-Id: I0cf394d2579a125a23c2f2989c2e92ace6ddb1a6
-
Andrew Thoelke authored
The current code does not always use data and instruction barriers as required by the architecture and frequently uses barriers excessively due to their inclusion in all of the write_*() helper functions. Barriers should be used explicitly in assembler or C code when modifying processor state that requires the barriers in order to enable review of correctness of the code. This patch removes the barriers from the helper functions and introduces them as necessary elsewhere in the code. PORTING NOTE: check any port of Trusted Firmware for use of system register helper functions for reliance on the previous barrier behaviour and add explicit barriers as necessary. Fixes ARM-software/tf-issues#92 Change-Id: Ie63e187404ff10e0bdcb39292dd9066cb84c53bf
-
- 06 May, 2014 3 commits
-
-
Dan Handley authored
Reduce the number of header files included from other header files as much as possible without splitting the files. Use forward declarations where possible. This allows removal of some unnecessary "#ifndef __ASSEMBLY__" statements. Also, review the .c and .S files for which header files really need including and reorder the #include statements alphabetically. Fixes ARM-software/tf-issues#31 Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
-
Dan Handley authored
Add tag names to all unnamed structs in header files. This allows forward declaration of structs, which is necessary to reduce header file nesting (to be implemented in a subsequent commit). Also change the typedef names across the codebase to use the _t suffix to be more conformant with the Linux coding style. The coding style actually prefers us not to use typedefs at all but this is considered a step too far for Trusted Firmware. Also change the IO framework structs defintions to use typedef'd structs to be consistent with the rest of the codebase. Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f
-
Dan Handley authored
Make codebase consistent in its use of #include "" syntax for user includes and #include <> syntax for system includes. Fixes ARM-software/tf-issues#65 Change-Id: If2f7c4885173b1fd05ac2cde5f1c8a07000c7a33
-
- 24 Apr, 2014 1 commit
-
-
Harry Liebel authored
- Use the TrustZone controller on Base FVP to program DRAM access permissions. By default no access to DRAM is allowed if 'secure memory' is enabled on the Base FVP. - The Foundation FVP does not have a TrustZone controller but instead has fixed access permissions. - Update FDTs for Linux to use timers at the correct security level. - Starting the FVPs with 'secure memory' disabled is also supported. Limitations: Virtio currently uses a reserved NSAID. This will be corrected in future FVP releases. Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
-
- 15 Apr, 2014 2 commits
-
-
Andrew Thoelke authored
The BL images share common stack management code which provides one coherent and one cacheable stack for every CPU. BL1 and BL2 just execute on the primary CPU during boot and do not require the additional CPU stacks. This patch provides separate stack support code for UP and MP images, substantially reducing the RAM usage for BL1 and BL2 for the FVP platform. This patch also provides macros for declaring stacks and calculating stack base addresses to improve consistency where this has to be done in the firmware. The stack allocation source files are now included via platform.mk rather than the common BLx makefiles. This allows each platform to select the appropriate MP/UP stack support for each BL image. Each platform makefile must be updated when including this commit. Fixes ARM-software/tf-issues#76 Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632
-
Dan Handley authored
Rename the array "mmap" in plat/fvp/aarch64/plat_common.c to "fvp_mmap", to avoid confusion with the array of the same name in lib/arch/aarch64/xlat_tables.c Fixes ARM-software/tf-issues#114 Change-Id: I61478c0070aa52d5dcf5d85af2f353f56c060cfb
-
- 08 Apr, 2014 1 commit
-
-
Sandrine Bailleux authored
BL3-1 architecture setup code programs the system counter frequency into the CNTFRQ_EL0 register. This frequency is defined by the platform, though. This patch introduces a new platform hook that the architecture setup code can call to retrieve this information. In the ARM FVP port, this returns the first entry of the frequency modes table from the memory mapped generic timer. All system counter setup code has been removed from BL1 as some platforms may not have initialized the system counters at this stage. The platform specific settings done exclusively in BL1 have been moved to BL3-1. In the ARM FVP port, this consists in enabling and initializing the System level generic timer. Also, the frequency change request in the counter control register has been set to 0 to make it explicit it's using the base frequency. The CNTCR_FCREQ() macro has been fixed in this context to give an entry number rather than a bitmask. In future, when support for firmware update is implemented, there is a case where BL1 platform specific code will need to program the counter frequency. This should be implemented at that time. This patch also updates the relevant documentation. It properly fixes ARM-software/tf-issues#24 Change-Id: If95639b279f75d66ac0576c48a6614b5ccb0e84b
-
- 21 Mar, 2014 2 commits
-
-
Vikram Kanigiri authored
Each ARM Trusted Firmware image should know in which EL it is running and it should use the corresponding register directly instead of reading currentEL and knowing which asm register to read/write Change-Id: Ief35630190b6f07c8fbb7ba6cb20db308f002945
-
Vikram Kanigiri authored
Remove the hard coding of all the MMU related registers with 0 and disable MMU by clearing the M and C bit in SCTLR_ELx Change-Id: I4a0b1bb14a604734b74c32eb31315d8504a7b8d8
-
- 05 Mar, 2014 1 commit
-
-
Jon Medhurst authored
Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
- 20 Feb, 2014 1 commit
-
-
Achin Gupta authored
This patch factors out the ARM FVP specific code to create MMU translation tables so that it is possible for a boot loader stage to create a different set of tables instead of using the default ones. The default translation tables are created with the assumption that the calling boot loader stage executes out of secure SRAM. This might not be true for the BL3_2 stage in the future. A boot loader stage can define the `fill_xlation_tables()` function as per its requirements. It returns a reference to the level 1 translation table which is used by the common platform code to setup the TTBR_EL3. This patch is a temporary solution before a larger rework of translation table creation logic is introduced. Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
-
- 17 Feb, 2014 2 commits
-
-
Jeenu Viswambharan authored
This patch moves the translation tables into their own section. This saves space that would otherwise have been lost in padding due to page table alignment constraints. The BL31 and BL32 bases have been consequently adjusted. Change-Id: Ibd65ae8a5ce4c4ea9a71a794c95bbff40dc63e65
-
James Morrissey authored
Also fix warnings generated in release builds when assert code is absent. Change-Id: I45b9173d3888f9e93e98eb5b4fdc06727ba5cbf4
-