- 06 May, 2014 6 commits
-
-
Dan Handley authored
Move the BL function prototypes out of arch.h and into the appropriate header files to allow more efficient header file inclusion. Create new BL private header files where there is no sensible existing header file. Change-Id: I45f3e10b72b5d835254a6f25a5e47cf4cfb274c3
-
Dan Handley authored
Move the function prototypes from gic.h into either gic_v2.h or gic_v3.h as appropriate. Update the source files to include the correct headers. Change-Id: I368cfda175cdcbd3a68f46e2332738ec49048e19
-
Dan Handley authored
Separate out the CASSERT macro out of bl_common.h into its own header to allow more efficient header inclusion. Change-Id: I291be0b6b8f9879645e839a8f0dd1ec9b3db9639
-
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
-
Dan Handley authored
Move the FVP power driver to a directory under the FVP platform port as this is not a generically usable driver. Change-Id: Ibc78bd88752eb3e3964336741488349ac345f4f0
-
Dan Handley authored
Move almost all system include files to a logical sub-directory under ./include. The only remaining system include directories not under ./include are specific to the platform. Move the corresponding source files to match the include directory structure. Also remove pm.h as it is no longer used. Change-Id: Ie5ea6368ec5fad459f3e8a802ad129135527f0b3
-
- 29 Apr, 2014 1 commit
-
-
Vikram Kanigiri authored
This patch saves the 'power_state' parameter prior to suspending a cpu and invalidates it upon its resumption. The 'affinity level' and 'state id' fields of this parameter can be read using a set of public and private apis. Validation of power state parameter is introduced which checks for SBZ bits are zero. This change also takes care of flushing the parameter from the cache to main memory. This ensures that it is available after cpu reset when the caches and mmu are turned off. The earlier support for saving only the 'affinity level' field of the 'power_state' parameter has also been reworked. Fixes ARM-Software/tf-issues#26 Fixes ARM-Software/tf-issues#130 Change-Id: Ic007ccb5e39bf01e0b67390565d3b4be33f5960a
-
- 24 Apr, 2014 1 commit
-
-
Harry Liebel authored
The TZC-400 performs security checks on transactions to memory or peripherals. Separate regions can be created in the address space each with individual security settings. Limitations: This driver does not currently support raising an interrupt on access violation. Change-Id: Idf8ed64b4d8d218fc9b6f9d75acdb2cd441d2449
-
- 15 Apr, 2014 1 commit
-
-
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
-
- 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
-
- 03 Apr, 2014 1 commit
-
-
Sandrine Bailleux authored
Change-Id: I7272a800accb7de71cbbf6b715a43061bbf79f8c
-
- 26 Mar, 2014 2 commits
-
-
Andrew Thoelke authored
This extends the --gc-sections behaviour to the many assembler support functions in the firmware images by placing each function into its own code section. This is achieved by creating a 'func' macro used to declare each function label. Fixes ARM-software/tf-issues#80 Change-Id: I301937b630add292d2dec6d2561a7fcfa6fec690
-
Vikram Kanigiri authored
This patch adds support in the generic PSCI implementation to call a platform specific function to enter a standby state using an example implementation in ARM FVP port Fixes ARM-software/tf-issues#94 Change-Id: Ic1263fcf25f28e09162ad29dca954125f9aa8cc9
-
- 21 Mar, 2014 1 commit
-
-
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
-
- 20 Mar, 2014 3 commits
-
-
Jeenu Viswambharan authored
Current implementation of Bakery Lock does tight-loop waiting upon lock contention. This commit reworks the implementation to use WFE instruction for waiting, and SEV to signal lock availability. It also adds the rationale for choosing Bakery Locks instead of exclusion primitives, and more comments for the lock algorithm. Fixes ARM-software/tf-issue#67 Change-Id: Ie351d3dbb27ec8e64dbc9507c84af07bd385a7df Co-authored-by: Vikram Kanigiri <vikram.kanigiri@arm.com>
-
Jeenu Viswambharan authored
This patch adds call count, UID and version information SMC calls for the Trusted OS, as specified by the SMC calling convention. Change-Id: I9a3e84ac1bb046051db975d853dcbe9612aba6a9
-
Jeenu Viswambharan authored
This patch implements ARM Standard Service as a runtime service and adds support for call count, UID and revision information SMCs. The existing PSCI implementation is subsumed by the Standard Service calls and all PSCI calls are therefore dispatched by the Standard Service to the PSCI handler. At present, PSCI is the only specification under Standard Service. Thus call count returns the number of PSCI calls implemented. As this is the initial implementation, a revision number of 0.1 is returned for call revision. Fixes ARM-software/tf-issues#62 Change-Id: I6d4273f72ad6502636efa0f872e288b191a64bc1
-
- 05 Mar, 2014 4 commits
-
-
Ryan Harkin authored
Fixes ARM-software/tf-issues#42 Some callers of load_image() may need to get the size of the image before/after loading it. Change-Id: I8dc067b69fc711433651a560ba5a8c3519445857 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
Jon Medhurst authored
So it updates each time a bootloader changes, not just when bl*_main.c files are recompiled. Fixes ARM-software/tf-issues#33 Change-Id: Ie8e1a7bd7e1913d2e96ac268606284f76af8c5ab Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Change-Id: I5b8d040ebc6672e40e4f13925e2fd5bc124103f4 Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
bakery_lock_release() expects an mpidr as the first argument however bakery_lock_release() is calling it with the 'entry' argument it has calculated. Rather than fixing this to pass the mpidr value it would be much more efficient to just replace the call with assert(bakery->owner == entry) As this leaves no remaining users of bakery_lock_held(), we might as well delete it. Fixes ARM-software/tf-issues#27 Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
- 26 Feb, 2014 1 commit
-
-
Jeenu Viswambharan authored
At present SPD power management hooks and BL3-2 entry are implemented using weak references. This would have the handlers bound and registered with the core framework at build time, but leaves them dangling if a service fails to initialize at runtime. This patch replaces implementation by requiring runtime handlers to register power management and deferred initialization hooks with the core framework at runtime. The runtime services are to register the hooks only as the last step, after having all states successfully initialized. Change-Id: Ibe788a2a381ef39aec1d4af5ba02376e67269782
-
- 20 Feb, 2014 7 commits
-
-
Ryan Harkin authored
Fixes issues #10: https://github.com/ARM-software/tf-issues/issues/10 This patch changes all/most variables of type int to be size_t or long to fix the sizing and alignment problems found when building with the newer toolchains such as Linaro GCC 13.12 or later. Change-Id: Idc9d48eb2ff9b8c5bbd5b227e6907263d1ea188b Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
Achin Gupta authored
This patch implements a set of handlers in the SPD which are called by the PSCI runtime service upon receiving a power management operation. These handlers in turn pass control to the Secure Payload image if required before returning control to PSCI. This ensures that the Secure Payload has complete visibility of all power transitions in the system and can prepare accordingly. Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2
-
Achin Gupta authored
This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
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
-
Achin Gupta authored
This patch adds the following support to the BL3-1 stage: 1. BL3-1 allows runtime services to specify and determine the security state of the next image after BL3-1. This has been done by adding the `bl31_set_next_image_type()` & `bl31_get_next_image_type()` apis. The default security state is non-secure. The platform api `bl31_get_next_image_info()` has been modified to let the platform decide which is the next image in the desired security state. 2. BL3-1 exports the `bl31_prepare_next_image_entry()` function to program entry into the target security state. It uses the apis introduced in 1. to do so. 3. BL3-1 reads the information populated by BL2 about the BL3-2 image into its internal data structures. 4. BL3-1 introduces a weakly defined reference `bl32_init()` to allow initialisation of a BL3-2 image. A runtime service like the Secure payload dispatcher will define this function if present. Change-Id: Icc46dcdb9e475ce6575dd3f9a5dc7a48a83d21d1
-
Achin Gupta authored
This patch reworks BL2 to BL3-1 hand over interface by introducing a composite structure (bl31_args) that holds the superset of information that needs to be passed from BL2 to BL3-1. - The extents of secure memory available to BL3-1 - The extents of memory available to BL3-2 (not yet implemented) and BL3-3 - Information to execute BL3-2 (not yet implemented) and BL3-3 images This patch also introduces a new platform API (bl2_get_bl31_args_ptr) that needs to be implemented by the platform code to export reference to bl31_args structure which has been allocated in platform-defined memory. The platform will initialize the extents of memory available to BL3-3 during early platform setup in bl31_args structure. This obviates the need for bl2_get_ns_mem_layout platform API. BL2 calls the bl2_get_bl31_args_ptr function to get a reference to bl31_args structure. It uses the 'bl33_meminfo' field of this structure to load the BL3-3 image. It sets the entry point information for the BL3-3 image in the 'bl33_image_info' field of this structure. The reference to this structure is passed to the BL3-1 image. Also fixes issue ARM-software/tf-issues#25 Change-Id: Ic36426196dd5ebf89e60ff42643bed01b3500517
-
Jeenu Viswambharan authored
This patch adds guards so that an exception vector exceeding 32 instructions will generate a compile-time error. This keeps the exception handlers in check from spilling over. Change-Id: I7aa56dd0071a333664e2814c656d3896032046fe
-
- 17 Feb, 2014 11 commits
-
-
Jeenu Viswambharan authored
This patch uses the reworked exception handling support to handle runtime service requests through SMCs following the SMC calling convention. This is a giant commit since all the changes are inter-related. It does the following: 1. Replace the old exception handling mechanism with the new one 2. Enforce that SP_EL0 is used C runtime stacks. 3. Ensures that the cold and warm boot paths use the 'cpu_context' structure to program an ERET into the next lower EL. 4. Ensures that SP_EL3 always points to the next 'cpu_context' structure prior to an ERET into the next lower EL 5. Introduces a PSCI SMC handler which completes the use of PSCI as a runtime service Change-Id: I661797f834c0803d2c674d20f504df1b04c2b852 Co-authored-by: Achin Gupta <achin.gupta@arm.com>
-
Achin Gupta authored
This patch introduces the reworked exception handling logic which lays the foundation for accessing runtime services in later patches. The type of an exception has a greater say in the way it is handled. SP_EL3 is used as the stack pointer for: 1. Determining the type of exception and handling the unexpected ones on the exception stack 2. Saving and restoring the essential general purpose and system register state after exception entry and prior to exception exit. SP_EL0 is used as the stack pointer for handling runtime service requests e.g. SMCs. A new structure for preserving general purpose register state has been added to the 'cpu_context' structure. All assembler ensures that it does not use callee saved registers (x19-x29). The C runtime preserves them across functions calls. Hence EL3 code does not have to save and restore them explicitly. Since the exception handling framework has undergone substantial change, the changes have been kept in separate files to aid readability. These files will replace the existing ones in subsequent patches. Change-Id: Ice418686592990ff7a4260771e8d6676e6c8c5ef
-
Achin Gupta authored
This patch introduces the framework to enable registration and initialisation of runtime services. PSCI is registered and initialised as a runtime service. Handling of runtime service requests will be implemented in subsequent patches. Change-Id: Id21e7ddc5a33d42b7d6e455b41155fc5441a9547
-
Achin Gupta authored
This patch uses the context library to save and restore EL3 state on the 'cpu_context' data structures allocated by PSCI for managing non-secure state context on each cpu. Change-Id: I19c1f26578204a7cd9e0a6c582ced0d97ee4cf80
-
Achin Gupta authored
This patch adds support for a cpu context management library. This library will be used to: 1. Share pointers to secure and non-secure state cpu contexts between runtime services e.g. PSCI and Secure Payload Dispatcher services 2. Set SP_EL3 to a context structure which will be used for programming an ERET into a lower EL 3. Provide wrapper functions to save and restore EL3 & EL1 state. These functions will in turn use the helper functions in context.S Change-Id: I655eeef83dcd2a0c6f2eb2ac23efab866ac83ca0
-
Achin Gupta authored
This patch introduces functions for saving and restoring shared system registers between secure and non-secure EL1 exception levels, VFP registers and essential EL3 system register and other state. It also defines the 'cpu_context' data structure which will used for saving and restoring execution context for a given security state. These functions will allow runtime services like PSCI and Secure payload dispatcher to implement logic for switching between the secure and non-secure states. The save and restore functions follow AArch64 PCS and only use caller-saved temporary registers. Change-Id: I8ee3aaa061d3caaedb28ae2c5becb9a206b6fd74
-
Achin Gupta authored
This patch ensures that VBAR_EL3 points to the simple stack-less 'early_exceptions' when the C runtime stack is not correctly setup to use the more complex 'runtime_exceptions'. It is initialised to 'runtime_exceptions' once this is done. This patch also moves all exception vectors into a '.vectors' section and modifies linker scripts to place all such sections together. This will minimize space wastage from alignment restrictions. Change-Id: I8c3e596ea3412c8bd582af9e8d622bb1cb2e049d
-
Harry Liebel authored
The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
-
Harry Liebel authored
This tool can be used to create a Firmware Image Packages (FIP). These FIPs store a combined set of firmware images with a Table of Contents (ToC) that can be loaded by the firmware from platform storage. - Add uuid.h from FreeBSD. - Use symbolic links to shared headers otherwise unwanted headers and definitions are pulled in. - A FIP is created as part of the default FVP build. - A BL3-3 image(e.g. UEFI) must be provided. Change-Id: Ib73feee181df2dba68bf6abec115a83cfa5e26cb
-
James Morrissey authored
The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
-
James Morrissey authored
This is intended primarily for use as a storage abstraction. It allows operations such as image-loading to be implemented in a platform-independent fashion. Each platform registers a set of IO drivers during initialisation. The platform must also provide a function that will return a device and a specifier that can be used to access specified content. Clients of the API will primarily use device and entity handles. The term "entity" is deliberately vague, to allow for different representations of content accessed using different types of specifier, but will often be interpreted as a "file" where the specifier will normally be its path. This commit builds, but is intended to be paired with a sample implementation of "load_image" using a semi-hosting driver on FVP. Change-Id: Id3b52f1c0eb9ce76b44b99fc6b6460803668cc86
-