| 401607cf | 08-May-2014 |
danh-arm <dan.handley@arm.com> |
Merge pull request #63 from soby-mathew/sm/save_callee_saved_registers_in_cpu_context-1
Preserve x19-x29 across world switch for exception handling |
| 18a17e6a | 08-May-2014 |
danh-arm <dan.handley@arm.com> |
Merge pull request #62 from athoelke/set-little-endian-v2
Set processor endianness immediately after RESET v2 |
| c3260f9b | 30-Apr-2014 |
Soby Mathew <soby.mathew@arm.com> |
Preserve x19-x29 across world switch for exception handling
Previously exception handlers in BL3-1, X19-X29 were not saved and restored on every SMC/trap into EL3. Instead these registers were 'save
Preserve x19-x29 across world switch for exception handling
Previously exception handlers in BL3-1, X19-X29 were not saved and restored on every SMC/trap into EL3. Instead these registers were 'saved as needed' as a side effect of the A64 ABI used by the C compiler.
That approach failed when world switching but was not visible with the TSP/TSPD code because the TSP is 64-bit, did not clobber these registers when running and did not support pre-emption by normal world interrupts. These scenarios showed that the values in these registers can be passed through a world switch, which broke the normal and trusted world assumptions about these registers being preserved.
The Ideal solution saves and restores these registers when a world switch occurs - but that type of implementation is more complex. So this patch always saves and restores these registers on entry and exit of EL3.
Fixes ARM-software/tf-issues#141
Change-Id: I9a727167bbc594454e81cf78a97ca899dfb11c27
show more ...
|
| 7935d0a5 | 28-Apr-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Access system registers directly in assembler
Instead of using the system register helper functions to read or write system registers, assembler coded functions should use MRS/MSR instructions. This
Access system registers directly in assembler
Instead of using the system register helper functions to read or write system registers, assembler coded functions should use MRS/MSR instructions. This results in faster and more compact code.
This change replaces all usage of the helper functions with direct register accesses.
Change-Id: I791d5f11f257010bb3e6a72c6c5ab8779f1982b3
show more ...
|
| 8cec598b | 28-Apr-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Correct usage of data and instruction barriers
The current code does not always use data and instruction barriers as required by the architecture and frequently uses barriers excessively due to thei
Correct usage of data and instruction barriers
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
show more ...
|
| 40fd0725 | 24-Apr-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Set processor endianness immediately after RESET
SCTLR_EL3.EE is being configured too late in bl1_arch_setup() and bl31_arch_setup() after data accesses have already occured on the cold and warm boo
Set processor endianness immediately after RESET
SCTLR_EL3.EE is being configured too late in bl1_arch_setup() and bl31_arch_setup() after data accesses have already occured on the cold and warm boot paths.
This control bit must be configured immediately on CPU reset to match the endian state of the firmware (little endian).
Fixes ARM-software/tf-issues#145
Change-Id: Ie12e46fbbed6baf024c30beb50751591bb8c8655
show more ...
|
| 97043ac9 | 09-Apr-2014 |
Dan Handley <dan.handley@arm.com> |
Reduce deep nesting of header files
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
Reduce deep nesting of header files
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
show more ...
|
| 35e98e55 | 09-Apr-2014 |
Dan Handley <dan.handley@arm.com> |
Make use of user/system includes more consistent
Make codebase consistent in its use of #include "" syntax for user includes and #include <> syntax for system includes.
Fixes ARM-software/tf-issues
Make use of user/system includes more consistent
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
show more ...
|
| 2bf28e62 | 20-Mar-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Allocate single stacks for BL1 and BL2
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
Allocate single stacks for BL1 and BL2
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
show more ...
|
| 9c2c763d | 15-Apr-2014 |
danh-arm <dan.handley@arm.com> |
Merge pull request #36 from athoelke/at/gc-sections-80
Using GCC --gc-sections to eliminate unused code and data |
| 9e86490f | 31-Mar-2014 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Define frequency of system counter in platform code
BL3-1 architecture setup code programs the system counter frequency into the CNTFRQ_EL0 register. This frequency is defined by the platform, thoug
Define frequency of system counter in platform code
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
show more ...
|
| 65a9c0e9 | 31-Mar-2014 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Revert "Move architecture timer setup to platform-specific code"
This reverts commit 1c297bf015226c182b66498d5a64b8b51c7624f5 because it introduced a bug: the CNTFRQ_EL0 register was no longer progr
Revert "Move architecture timer setup to platform-specific code"
This reverts commit 1c297bf015226c182b66498d5a64b8b51c7624f5 because it introduced a bug: the CNTFRQ_EL0 register was no longer programmed by all CPUs. bl31_platform_setup() function is invoked only in the cold boot path and consequently only on the primary cpu.
A subsequent commit will correctly implement the necessary changes to the counter frequency setup code.
Fixes ARM-software/tf-issues#125
Conflicts:
docs/firmware-design.md plat/fvp/bl31_plat_setup.c
Change-Id: Ib584ad7ed069707ac04cf86717f836136ad3ab54
show more ...
|
| 0a30cf54 | 18-Mar-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Place assembler functions in separate sections
This extends the --gc-sections behaviour to the many assembler support functions in the firmware images by placing each function into its own code sect
Place assembler functions in separate sections
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
show more ...
|
| d8b07aa0 | 20-Mar-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Move per cpu exception stack in BL31 to tzfw_normal_stacks
Fixes ARM-software/tf-issues#70
Change-Id: I7f024f173fbdecd315076f528b05d6295aff7276 |
| 6ba0b6d6 | 11-Mar-2014 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Remove partially qualified asm helper functions
Each ARM Trusted Firmware image should know in which EL it is running and it should use the corresponding register directly instead of reading current
Remove partially qualified asm helper functions
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
show more ...
|
| 1c297bf0 | 07-Jan-2014 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Move architecture timer setup to platform-specific code
At present, bl1_arch_setup() and bl31_arch_setup() program the counter frequency using a value from the memory mapped generic timer. The gener
Move architecture timer setup to platform-specific code
At present, bl1_arch_setup() and bl31_arch_setup() program the counter frequency using a value from the memory mapped generic timer. The generic timer however is not necessarily present on all ARM systems (although it is architected to be present on all server systems).
This patch moves the timer setup to platform-specific code and updates the relevant documentation. Also, CNTR.FCREQ is set as the specification requires the bit corresponding to the counter's frequency to be set when enabling. Since we intend to use the base frequency, set bit 8.
Fixes ARM-software/tf-issues#24
Change-Id: I32c52cf882253e01f49056f47c58c23e6f422652
show more ...
|
| 35ca3511 | 19-Feb-2014 |
Achin Gupta <achin.gupta@arm.com> |
Add support for BL3-2 in BL3-1
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-
Add support for BL3-2 in BL3-1
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
show more ...
|
| e4d084ea | 19-Feb-2014 |
Achin Gupta <achin.gupta@arm.com> |
Rework BL2 to BL3-1 hand over interface
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 p
Rework BL2 to BL3-1 hand over interface
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
show more ...
|
| a7934d69 | 07-Feb-2014 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Add exception vector guards
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
Add exception vector guards
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
show more ...
|
| caa84939 | 06-Feb-2014 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Add support for handling runtime service requests
This patch uses the reworked exception handling support to handle runtime service requests through SMCs following the SMC calling convention. This i
Add support for handling runtime service requests
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>
show more ...
|
| 07f4e078 | 02-Feb-2014 |
Achin Gupta <achin.gupta@arm.com> |
Introduce new exception handling framework
This patch introduces the reworked exception handling logic which lays the foundation for accessing runtime services in later patches. The type of an excep
Introduce new exception handling framework
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
show more ...
|
| 9ac63c59 | 16-Jan-2014 |
Achin Gupta <achin.gupta@arm.com> |
Add helper library for cpu context management
This patch introduces functions for saving and restoring shared system registers between secure and non-secure EL1 exception levels, VFP registers and e
Add helper library for cpu context management
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
show more ...
|
| b739f22a | 18-Jan-2014 |
Achin Gupta <achin.gupta@arm.com> |
Setup VBAR_EL3 incrementally
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_exce
Setup VBAR_EL3 incrementally
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
show more ...
|
| 3a4cae05 | 16-Jan-2014 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Change comments in assembler files to help ctags
Ctags seem to have a problem with generating tags for assembler symbols when a comment immediately follows an assembly label.
This patch inserts a s
Change comments in assembler files to help ctags
Ctags seem to have a problem with generating tags for assembler symbols when a comment immediately follows an assembly label.
This patch inserts a single space character between the label definition and the following comments to help ctags.
The patch is generated by the command:
git ls-files -- \*.S | xargs sed -i 's/^\([^:]\+\):;/\1: ;/1'
Change-Id: If7a3c9d0f51207ea033cc8b8e1b34acaa0926475
show more ...
|
| 4f603683 | 14-Jan-2014 |
Harry Liebel <Harry.Liebel@arm.com> |
Do not trap access to floating point registers
Traps when accessing architectural features are disabled by clearing bits in CPTR_EL3 during early boot, including accesses to floating point registers
Do not trap access to floating point registers
Traps when accessing architectural features are disabled by clearing bits in CPTR_EL3 during early boot, including accesses to floating point registers. The value of this register was previously undetermined, causing unwanted traps to EL3. Future EL3 code (for example, context save/restore code) may use floating point registers, although they are not used by current code.
Also, the '-mgeneral-regs-only' flag is enabled in the GCC settings to prevent generation of code that uses floating point registers.
Change-Id: I9a03675f6387bbbee81a6f2c9ccf81150db03747
show more ...
|