aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-05-29Merge pull request #115 'athoelke-at:fix-bl31-X1-parameter'Dan Handley
2014-05-29Merge pull request #114 from 'vikramkanigiri:vk/pass_bl33_args'Dan Handley
2014-05-29Allow platform parameter X1 to be passed to BL3-1Andrew Thoelke
bl2_main() was overwriting any platform set X1 parameter for BL3-1 with the value zero. This patch ensure that any platform set value is correctly passed to BL3-1. The FVP port adds a check to verify this parameter is being passed correctly. Fixes ARM-software/tf-issues#173 Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
2014-05-28Pass the args to the BL3-3 entrypointVikram Kanigiri
At present the arguments for BL3-3 in the entry_point_info structure are not being transferred to X0-X7 before starting execution of this image This patch saves the args for BL3-3 into cpu context used for its entry Fixes ARM-software/tf-issues#172 Change-Id: I001b4b9bff6a264336f0d01d377619ae719f928b
2014-05-27Merge pull request #110 from soby-mathew:sm/support_normal_irq_in_tsp-v4 ↵Dan Handley
into for-v0.4
2014-05-27Merge pull request #112 from danh-arm:dh/refactor-plat-header-v4 into for-v0.4Dan Handley
2014-05-27Further renames of platform porting functionsDan Handley
Rename the ic_* platform porting functions to plat_ic_* to be consistent with the other functions in platform.h. Also rename bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info() and remove the duplicate declaration in bl31.h. Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84
2014-05-27Remove FVP specific comments in platform.hDan Handley
Remove the FVP specific comments in platform.h since this file is re-usable across all platforms. Change-Id: Ifd4a4f72562adb3ecf8b9078b0150f170ef22dba
2014-05-27Fixup Standard SMC Resume HandlingSoby Mathew
This patch fixes a missed return and code alignment issues in TSP_FID_RESUME handling. Change-Id: Icf8aeb76dfd6898745653ce039e3bac45e0a9b3a
2014-05-23Add enable mmu platform porting interfacesDan Handley
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
2014-05-23Rename FVP specific files and functionsDan Handley
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
2014-05-23Move BL porting functions into platform.hDan Handley
Some platform porting functions were in BL specific header files. These have been moved to platform.h so that all porting functions are in the same place. The functions are now grouped by BL. Obsolete BL headers files have been removed. Also, the weak declaration of the init_bl2_mem_layout() function has been moved out the header file and into the source file (bl_common.c) using the more succinct #pragma syntax. This mitigates the risk of 2 weak definitions being created and the wrong one being picked up by the compiler. Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
2014-05-23Split platform.h into separate headersDan Handley
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
2014-05-23Remove unused data declarationsDan Handley
Some data variables were declared but not used. These have been removed. Change-Id: I038632af3c32d88984cd25b886c43ff763269bf9
2014-05-23Remove extern keyword from function declarationsDan Handley
Function declarations implicitly have external linkage so do not need the extern keyword. Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32
2014-05-23Merge pull request #101 from sandrine-bailleux:sb/tf-issue-81-v2Andrew Thoelke
2014-05-23doc: Update information about the memory layoutSandrine Bailleux
Rework the "Memory layout on FVP platforms" section in the Firmware Design document. Add information about where the TSP image fits in the memory layout when present. Add documentation for the base addresses of each bootloader image in the porting guide. Change-Id: I4afb2605e008a1cb28c44a697804f2cb6bb4c9aa
2014-05-23Make the memory layout more flexibleSandrine Bailleux
Currently the platform code gets to define the base address of each boot loader image. However, the linker scripts couteract this flexibility by enforcing a fixed overall layout of the different images. For example, they require that the BL3-1 image sits below the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way that it violates this constraint makes the build fail at link-time. This patch requires the platform code to now define a limit address for each image. The linker scripts check that the image fits within these bounds so they don't rely anymore on the position of a given image in regard to the others. Fixes ARM-software/tf-issues#163 Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
2014-05-23Make BL1 RO and RW base addresses configurableSandrine Bailleux
BL1 RO and RW base address used to be fixed, respectively to the first address of the Trusted ROM and the first address of the Trusted RAM. Introduce new platform defines to configure the BL1 RO and RW base addresses. Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6
2014-05-23Merge pull request #104 from athoelke:at/tsp-entrypoints-v2Andrew Thoelke
2014-05-23Merge pull request #105 from athoelke:sm/support_normal_irq_in_tsp-v2Andrew Thoelke
2014-05-23Merge pull request #102 from achingupta:ag/tf-issues#104-v2Andrew Thoelke
2014-05-23Merge pull request #100 from jcastillo-arm:jc/tf-issues/149-v4Andrew Thoelke
2014-05-23Merge pull request #101 from sandrine-bailleux:sb/tf-issue-81-v2Andrew Thoelke
2014-05-23Merge pull request #103 from athoelke:dh/tf-issues#68-v3Andrew Thoelke
2014-05-23Merge pull request #99 from vikramkanigiri:vk/tf-issues-133_V3Andrew Thoelke
2014-05-23Merge pull request #67 from achingupta:ag/psci_standby_bug_fixAndrew Thoelke
2014-05-23Limit BL3-1 read/write access to SRAMAndrew Thoelke
At present BL3-1 has access to all of the SRAM, including regions that are mapped as read-only and non-cacheable by other firmware images. This patch restricts BL3-1 to only be able to read/write from memory used for its own data sections Change-Id: I26cda1b9ba803d91a9eacda768f3ce7032c6db94 Conflicts: plat/fvp/bl31_plat_setup.c
2014-05-23Use a vector table for TSP entrypointsAndrew Thoelke
The TSP has a number of entrypoints used by the TSP on different occasions. These were provided to the TSPD as a table of function pointers, and required the TSPD to read the entry in the table, which is in TSP memory, in order to program the exception return address. Ideally, the TSPD has no access to the TSP memory. This patch changes the table of function pointers into a vector table of single instruction entrypoints. This allows the TSPD to calculate the entrypoint address instead of read it. Fixes ARM-software/tf-issues#160 Change-Id: Iec6e055d537ade78a45799fbc6f43765a4725ad3
2014-05-23Non-Secure Interrupt support during Standard SMC processing in TSPSoby Mathew
Implements support for Non Secure Interrupts preempting the Standard SMC call in EL1. Whenever an IRQ is trapped in the Secure world we securely handover to the Normal world to process the interrupt. The normal world then issues "resume" smc call to resume the previous interrupted SMC call. Fixes ARM-software/tf-issues#105 Change-Id: I72b760617dee27438754cdfc9fe9bcf4cc024858
2014-05-22Allow BL3-2 platform definitions to be optionalDan Handley
The generic image loading and IO FIP code no longer forces the platform to create BL3-2 (Secure-EL1 Payload) specific definitions. The BL3-2 loading code in bl2/bl2main.c is wrapped by a #ifdef BL32_BASE blocks, allowing the BL3-2 definitions to be optional. Similarly for the name_uuid array defintion in drivers/io/io_fip.c. Also update the porting guide to reflect this change. The BL3-2 platform definitions remain non-configurably present in the FVP port. Fixes ARM-software/tf-issues#68 Change-Id: Iea28b4e94d87a31f5522f271e290919a8a955460
2014-05-22Enable secure timer to generate S-EL1 interruptsAchin Gupta
This patch enables secure physical timer during TSP initialisation and maintains it across power management operations so that a timer interrupt is generated every half second. Fixes ARM-software/tf-issues#104 Fixes ARM-software/tf-issues#134 Change-Id: I66c6cfd24bd5e6035ba75ebf0f047e568770a369
2014-05-22Add S-EL1 interrupt handling support in the TSPDAchin Gupta
This patch adds support in the TSPD for registering a handler for S-EL1 interrupts. This handler ferries the interrupts generated in the non-secure state to the TSP at 'tsp_fiq_entry'. Support has been added to the smc handler to resume execution in the non-secure state once interrupt handling has been completed by the TSP. There is also support for resuming execution in the normal world if the TSP receives a EL3 interrupt. This code is currently unused. Change-Id: I816732595a2635e299572965179f11aa0bf93b69
2014-05-22Add support for asynchronous FIQ handling in TSPAchin Gupta
This patch adds support in the TSP to handle FIQ interrupts that are generated when execution is in the TSP. S-EL1 interrupt are handled normally and execution resumes at the instruction where the exception was originally taken. S-EL3 interrupts i.e. any interrupt not recognized by the TSP are handed to the TSPD. Execution resumes normally once such an interrupt has been handled at EL3. Change-Id: Ia3ada9a4fb15670afcc12538a6456f21efe58a8f
2014-05-22Add support for synchronous FIQ handling in TSPAchin Gupta
This patch adds support in the TSP for handling S-EL1 interrupts handed over by the TSPD. It includes GIC support in its platform port, updates various statistics related to FIQ handling, exports an entry point that the TSPD can use to hand over interrupts and defines the handover protocol w.r.t what context is the TSP expected to preserve and the state in which the entry point is invoked by the TSPD. Change-Id: I93b22e5a8133400e4da366f5fc862f871038df39
2014-05-22Use secure timer to generate S-EL1 interruptsAchin Gupta
This patch adds support in the TSP to program the secure physical generic timer to generate a EL-1 interrupt every half second. It also adds support for maintaining the timer state across power management operations. The TSPD ensures that S-EL1 can access the timer by programming the SCR_EL3.ST bit. This patch does not actually enable the timer. This will be done in a subsequent patch once the complete framework for handling S-EL1 interrupts is in place. Change-Id: I1b3985cfb50262f60824be3a51c6314ce90571bc
2014-05-22Introduce interrupt handling framework in BL3-1Achin Gupta
This patch adds a common handler for FIQ and IRQ exceptions in the BL3-1 runtime exception vector table. This function determines the interrupt type and calls its handler. A crash is reported if an inconsistency in the interrupt management framework is detected. In the event of a spurious interrupt, execution resumes from the instruction where the interrupt was generated. This patch also removes 'cm_macros.S' as its contents have been moved to 'runtime_exceptions.S' Change-Id: I3c85ecf8eaf43a3fac429b119ed0bd706d2e2093
2014-05-22Introduce platform api to access an ARM GICAchin Gupta
This patch introduces a set of functions which allow generic firmware code e.g. the interrupt management framework to access the platform interrupt controller. APIs for finding the type and id of the highest pending interrupt, acknowledging and EOIing an interrupt and finding the security state of an interrupt have been added. It is assumed that the platform interrupt controller implements the v2.0 of the ARM GIC architecture specification. Support for v3.0 of the specification for managing interrupts in EL3 and the platform port will be added in the future. Change-Id: Ib3a01c2cf3e3ab27806930f1be79db2b29f91bcf
2014-05-22Introduce interrupt registration framework in BL3-1Achin Gupta
This patch introduces a framework for registering interrupts routed to EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and FIQ bits and the security state an interrupt is generated in. The framework recognizes three type of interrupts depending upon which exception level and security state they should be handled in i.e. Secure EL1 interrupts, Non-secure interrupts and EL3 interrupts. It provides an API and macros that allow a runtime service to register an handler for a type of interrupt and specify the routing model. The framework validates the routing model and uses the context management framework to ensure that it is applied to the SCR_EL3 prior to entry into the target security state. It saves the handler in internal data structures. An API is provided to retrieve the handler when an interrupt of a particular type is asserted. Registration is expected to be done once by the primary CPU. The same handler and routing model is used for all CPUs. Support for EL3 interrupts will be added to the framework in the future. A makefile flag has been added to allow the FVP port choose between ARM GIC v2 and v3 support in EL3. The latter version is currently unsupported. A framework for handling interrupts in BL3-1 will be introduced in subsequent patches. The default routing model in the absence of any handlers expects no interrupts to be routed to EL3. Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
2014-05-22Add context library API to change a bit in SCR_EL3Achin Gupta
This patch adds an API to write to any bit in the SCR_EL3 member of the 'cpu_context' structure of the current CPU for a specified security state. This API will be used in subsequent patches which introduce interrupt management in EL3 to specify the interrupt routing model when execution is not in EL3. It also renames the cm_set_el3_elr() function to cm_set_elr_el3() which is more in line with the system register name being targeted by the API. Change-Id: I310fa7d8f827ad3f350325eca2fb28cb350a85ed
2014-05-22Rework 'state' field usage in per-cpu TSP contextAchin Gupta
This patch lays the foundation for using the per-cpu 'state' field in the 'tsp_context' structure for other flags apart from the power state of the TSP. It allocates 2 bits for the power state, introduces the necessary macros to manipulate the power state in the 'state' field and accordingly reworks all use of the TSP_STATE_* states. It also allocates a flag bit to determine if the TSP is handling a standard SMC. If this flag is set then the TSP was interrupted due to non-secure or EL3 interupt depending upon the chosen routing model. Macros to get, set and clear this flag have been added as well. This flag will be used by subsequent patches. Change-Id: Ic6ee80bd5895812c83b35189cf2c3be70a9024a6
2014-05-22Doc: Add the "Building the Test Secure Payload" sectionSandrine Bailleux
Add a section in the user guide explaining how to compile the TSP image and include it into the FIP. This includes instructions to make the TSP run from Trusted DRAM (rather than Trusted SRAM) on FVP. Change-Id: I04780757a149eeb5482a12a61e821be947b882c0
2014-05-22fvp: Move TSP from Secure DRAM to Secure SRAMSandrine Bailleux
The TSP used to execute from secure DRAM on the FVPs because there was not enough space in Trusted SRAM to fit it in. Thanks to recent RAM usage enhancements being implemented, we have made enough savings for the TSP to execute in SRAM. However, there is no contiguous free chunk of SRAM big enough to hold the TSP. Therefore, the different bootloader images need to be moved around to reduce memory fragmentation. This patch keeps the overall memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and BL3-1 in between) but moves the base addresses of all the bootloader images in such a way that: - memory fragmentation is reduced enough to fit BL3-2 in; - new base addresses are suitable for release builds as well as debug ones; - each image has a few extra kilobytes for future growth. BL3-1 and BL3-2 are the images which received the biggest slice of the cake since they will most probably grow the most. A few useful numbers for reference (valid at the time of this patch): |-----------------------|------------------------------- | image size (debug) | extra space for the future --------|-----------------------|------------------------------- BL1 R/W | 20 KB | 4 KB BL2 | 44 KB | 4 KB BL3-1 | 108 KB | 12 KB BL3-2 | 56 KB | 8 KB --------|-----------------------|------------------------------- Total | 228 KB | 28 KB = 256 KB --------|-----------------------|------------------------------- Although on FVPs the TSP now executes from Trusted SRAM by default, this patch keeps the option to execute it from Trusted DRAM. This is controlled by the build configuration 'TSP_RAM_LOCATION'. Fixes ARM-Software/tf-issues#81 Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
2014-05-22TSP: Let the platform decide which secure memory to useSandrine Bailleux
The TSP's linker script used to assume that the TSP would execute from secure DRAM. Although it is currently the case on FVPs, platforms are free to use any secure memory they wish. This patch introduces the flexibility to load the TSP into any secure memory. The platform code gets to specify the extents of this memory in the platform header file, as well as the BL3-2 image limit address. The latter definition allows to check in a generic way that the BL3-2 image fits in its bounds. Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c
2014-05-22Reserve some DDR DRAM for secure use on FVP platformsJuan Castillo
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
2014-05-22Add support for BL3-1 as a reset vectorVikram Kanigiri
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
2014-05-22Rework memory information passing to BL3-x imagesVikram Kanigiri
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
2014-05-22Populate BL31 input parameters as per new specVikram Kanigiri
This patch is based on spec published at https://github.com/ARM-software/tf-issues/issues/133 It rearranges the bl31_args struct into bl31_params and bl31_plat_params which provide the information needed for Trusted firmware and platform specific data via x0 and x1 On the FVP platform BL3-1 params and BL3-1 plat params and its constituents are stored at the start of TZDRAM. The information about memory availability and size for BL3-1, BL3-2 and BL3-3 is moved into platform specific data. Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9
2014-05-22Rework handover interface between BL stagesVikram Kanigiri
This patch reworks the handover interface from: BL1 to BL2 and BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el() and run_image() functions as they catered for code paths that were never exercised. BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same by calling run_image(). Similarly, BL2 issues the SMC to transfer execution to BL3-1 through BL1 directly. Only x0 and x1 are used to pass arguments to BL31. These arguments and parameters for running BL3-1 are passed through a reference to a 'el_change_info_t' structure. They were being passed value in general purpose registers earlier. Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1
2014-05-22Introduce macros to manipulate the SPSRVikram Kanigiri
This patch introduces macros (SPSR_64 and SPSR_32) to create a SPSR for both aarch32 and aarch64 execution states. These macros allow the user to set fields in the SPSR depending upon its format. The make_spsr() function which did not allow manipulation of all the fields in the aarch32 SPSR has been replaced by these new macros. Change-Id: I9425dda0923e8d5f03d03ddb8fa0e28392c4c61e