| 7173f5f6 | 24-Sep-2015 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Fix relocation of __PERCPU_BAKERY_LOCK_SIZE__
When a platform port does not define PLAT_PERCPU_BAKERY_LOCK_SIZE, the total memory that should be allocated per-cpu to accommodate all bakery locks is
Fix relocation of __PERCPU_BAKERY_LOCK_SIZE__
When a platform port does not define PLAT_PERCPU_BAKERY_LOCK_SIZE, the total memory that should be allocated per-cpu to accommodate all bakery locks is calculated by the linker in bl31.ld.S. The linker stores this value in the __PERCPU_BAKERY_LOCK_SIZE__ linker symbol. The runtime value of this symbol is different from the link time value as the symbol is relocated into the current section (.bss). This patch fixes this issue by marking the symbol as ABSOLUTE which allows it to retain its correct value even at runtime.
The description of PLAT_PERCPU_BAKERY_LOCK_SIZE in the porting-guide.md has been made clearer as well.
Change-Id: Ia0cfd42f51deaf739d792297e60cad5c6e6e610b
show more ...
|
| 54dc71e7 | 11-Sep-2015 |
Achin Gupta <achin.gupta@arm.com> |
Make generic code work in presence of system caches
On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This mean
Make generic code work in presence of system caches
On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).
This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes:
1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed.
2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA.
3. Cache maintenance by set/way operations are only used prior to power down.
NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.
Fixes ARM-software/tf-issues#205
Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
show more ...
|
| ee7b35c4 | 10-Sep-2015 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Re-design bakery lock memory allocation and algorithm
This patch unifies the bakery lock api's across coherent and normal memory implementation of locks by using same data type `bakery_lock_t` and s
Re-design bakery lock memory allocation and algorithm
This patch unifies the bakery lock api's across coherent and normal memory implementation of locks by using same data type `bakery_lock_t` and similar arguments to functions.
A separate section `bakery_lock` has been created and used to allocate memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are allocated in normal memory, each lock for a core has to spread across multiple cache lines. By using the total size allocated in a separate cache line for a single core at compile time, the memory for other core locks is allocated at link time by multiplying the single core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock algorithm now uses lock address instead of the `id` in the per_cpu_data. For locks allocated in coherent memory, it moves locks from tzfw_coherent_memory to bakery_lock section.
The bakery locks are allocated as part of bss or in coherent memory depending on usage of coherent memory. Both these regions are initialised to zero as part of run_time_init before locks are used. Hence, bakery_lock_init() is made an empty function as the lock memory is already initialised to zero.
The above design lead to the removal of psci bakery locks from non_cpu_power_pd_node to psci_locks.
NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED. THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY LOCKS IN NORMAL MEMORY.
Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
show more ...
|
| 85a181ce | 13-Jul-2015 |
Soby Mathew <soby.mathew@arm.com> |
PSCI: Migrate TF to the new platform API and CM helpers
This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API.
PSCI: Migrate TF to the new platform API and CM helpers
This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API. The per-cpu data framework APIs which took MPIDRs as their arguments are deleted and only the ones which take core index as parameter are retained.
Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
show more ...
|
| 67487846 | 13-Jul-2015 |
Soby Mathew <soby.mathew@arm.com> |
PSCI: Switch to the new PSCI frameworks
This commit does the switch to the new PSCI framework implementation replacing the existing files in PSCI folder with the ones in PSCI1.0 folder. The correspo
PSCI: Switch to the new PSCI frameworks
This commit does the switch to the new PSCI framework implementation replacing the existing files in PSCI folder with the ones in PSCI1.0 folder. The corresponding makefiles are modified as required for the new implementation. The platform.h header file is also is switched to the new one as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults to 1 to enable compatibility layer which let the existing platform ports to continue to build and run with minimal changes.
The default weak implementation of platform_get_core_pos() is now removed from platform_helpers.S and is provided by the compatibility layer.
Note: The Secure Payloads and their dispatchers still use the old platform and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build flag will remain enabled in subsequent patch. The compatibility for SPDs using the older APIs on platforms migrated to the new APIs will be added in the following patch.
Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
show more ...
|
| 12d0d00d | 09-Apr-2015 |
Soby Mathew <soby.mathew@arm.com> |
PSCI: Introduce new platform and CM helper APIs
This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This f
PSCI: Introduce new platform and CM helper APIs
This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This framework will be introduced in the follwoing patch and it removes the assumption that the MPIDR based affinity levels map directly to levels in a power domain tree. The new platforms APIs and context management helpers based on core position are as described below:
* plat_my_core_pos() and plat_core_pos_by_mpidr()
These 2 new mandatory platform APIs are meant to replace the existing 'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the linear index of the calling core and 'plat_core_pos_by_mpidr()' returns the linear index of a core specified by its MPIDR. The latter API will also validate the MPIDR passed as an argument and will return an error code (-1) if an invalid MPIDR is passed as the argument. This enables the caller to safely convert an MPIDR of another core to its linear index without querying the PSCI topology tree e.g. during a call to PSCI CPU_ON.
Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always platform specific, it is no longer possible to maintain a default implementation of this API. Also it might not be possible for a platform port to verify an MPIDR before the C runtime has been setup or the topology has been initialized. This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to topology setup. As a result, the generic Trusted Firmware code does not call this API before the topology setup has been done.
The 'plat_my_core_pos' API should be able to run without a C runtime. Since this API needs to return a core position which is equal to the one returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR, this too cannot have default implementation and is a mandatory API for platform ports. These APIs will be implemented by the ARM reference platform ports later in the patch stack.
* plat_get_my_stack() and plat_set_my_stack()
These APIs are the stack management APIs which set/return stack addresses appropriate for the calling core. These replace the 'platform_get_stack()' and 'platform_set_stack()' APIs. A default weak MP version and a global UP version of these APIs are provided for the platforms.
* Context management helpers based on linear core position
A set of new context management(CM) helpers viz cm_get_context_by_index(), cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index() are defined which are meant to replace the old helpers which took MPIDR as argument. The old CM helpers are implemented based on the new helpers to allow for code consolidation and will be deprecated once the switch to the new framework is done.
Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
show more ...
|
| e347e843 | 24-Jun-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #310 from sandrine-bailleux/sb/tf-issue-304-phase1
Enhance BL3-1 entrypoint handling to support non-TF boot firmware - Phase 1 |
| bf031bba | 02-Jun-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Introduce PROGRAMMABLE_RESET_ADDRESS build option
This patch introduces a new platform build option, called PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has a programmable or fixed r
Introduce PROGRAMMABLE_RESET_ADDRESS build option
This patch introduces a new platform build option, called PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has a programmable or fixed reset vector address.
If the reset vector address is fixed then the code relies on the platform_get_entrypoint() mailbox mechanism to figure out where it is supposed to jump. On the other hand, if it is programmable then it is assumed that the platform code will program directly the right address into the RVBAR register (instead of using the mailbox redirection) so the mailbox is ignored in this case.
Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
show more ...
|
| 52010cc7 | 19-May-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Rationalize reset handling code
The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option.
This patch rel
Rationalize reset handling code
The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option.
This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code.
This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code.
This improves code re-use and consolidates the code flows for different types of systems.
NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC.
Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
show more ...
|
| 5717aae1 | 13-May-2015 |
Achin Gupta <achin.gupta@arm.com> |
Fix handling of spurious interrupts in BL3_1
There are couple of issues with how the interrupt routing framework in BL3_1 handles spurious interrupts.
1. In the macro 'handle_interrupt_exception',
Fix handling of spurious interrupts in BL3_1
There are couple of issues with how the interrupt routing framework in BL3_1 handles spurious interrupts.
1. In the macro 'handle_interrupt_exception', if a spurious interrupt is detected by plat_ic_get_pending_interrupt_type(), then execution jumps to 'interrupt_exit_\label'. This macro uses the el3_exit() function to return to the original exception level. el3_exit() attempts to restore the SPSR_EL3 and ELR_EL3 registers with values from the current CPU context. Since these registers were not saved in this code path, it programs stale values into these registers. This leads to unpredictable behaviour after the execution of the ERET instruction.
2. When an interrupt is routed to EL3, it could be de-asserted before the GICC_HPPIR is read in plat_ic_get_pending_interrupt_type(). There could be another interrupt pending at the same time e.g. a non-secure interrupt. Its type will be returned instead of the original interrupt. This would result in a call to get_interrupt_type_handler(). The firmware will panic if the handler for this type of interrupt has not been registered.
This patch fixes the first problem by saving SPSR_EL3 and ELR_EL3 early in the 'handle_interrupt_exception' macro, instead of only doing so once the validity of the interrupt has been determined.
The second problem is fixed by returning execution back to the lower exception level through the 'interrupt_exit_\label' label instead of treating it as an error condition. The 'interrupt_error_\label' label has been removed since it is no longer used.
Fixes ARM-software/tf-issues#305
Change-Id: I81c729a206d461084db501bb81b44dff435021e8
show more ...
|
| 8b779620 | 24-Mar-2015 |
Kévin Petit <kevin.petit@arm.com> |
Add support to indicate size and end of assembly functions
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the ass
Add support to indicate size and end of assembly functions
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the assembler using the .size directive.
To fulfil the above requirements, this patch introduces an 'endfunc' macro which contains the .endfunc and .size directives. It also adds a .func directive to the 'func' assembler macro.
The .func/.endfunc have been used so the assembler can fail if endfunc is omitted.
Fixes ARM-Software/tf-issues#295
Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc Signed-off-by: Kévin Petit <kevin.petit@arm.com>
show more ...
|
| 27bc0106 | 17-Mar-2015 |
danh-arm <dan.handley@arm.com> |
Merge pull request #268 from vikramkanigiri/vk/move_init_cpu_ops
Initialise cpu ops after enabling data cache |
| 12e7c4ab | 29-Jan-2015 |
Vikram Kanigiri <vikram.kanigiri@arm.com> |
Initialise cpu ops after enabling data cache
The cpu-ops pointer was initialized before enabling the data cache in the cold and warm boot paths. This required a DCIVAC cache maintenance operation to
Initialise cpu ops after enabling data cache
The cpu-ops pointer was initialized before enabling the data cache in the cold and warm boot paths. This required a DCIVAC cache maintenance operation to invalidate any stale cache lines resident in other cpus.
This patch moves this initialization to the bl31_arch_setup() function which is always called after the data cache and MMU has been enabled.
This change removes the need: 1. for the DCIVAC cache maintenance operation. 2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND call since memory contents are always preserved in this case.
Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6
show more ...
|
| dad25049 | 05-Feb-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Enable type-checking of arguments passed to printf() et al.
This patch modifies the declarations of the functions printf() et al. and adds the right GCC attribute to request the compiler to check th
Enable type-checking of arguments passed to printf() et al.
This patch modifies the declarations of the functions printf() et al. and adds the right GCC attribute to request the compiler to check the type of the arguments passed to these functions against the given format string. This will ensure that the compiler outputs warning messages like the following whenever it detects an inconsistency:
file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
It also fixes the type mismatch inconsistencies that it revealed across the code base.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.
Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6
show more ...
|
| 79a97b2e | 20-Nov-2014 |
Yatharth Kochar <yatharth.kochar@arm.com> |
Call reset handlers upon BL3-1 entry.
This patch adds support to call the reset_handler() function in BL3-1 in the cold and warm boot paths when another Boot ROM reset_handler() has already run.
Th
Call reset handlers upon BL3-1 entry.
This patch adds support to call the reset_handler() function in BL3-1 in the cold and warm boot paths when another Boot ROM reset_handler() has already run.
This means the BL1 and BL3-1 versions of the CPU and platform specific reset handlers may execute different code to each other. This enables a developer to perform additional actions or undo actions already performed during the first call of the reset handlers e.g. apply additional errata workarounds.
Typically, the reset handler will be first called from the BL1 Boot ROM. Any additional functionality can be added to the reset handler when it is called from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used to identify whether this is the first version of the reset handler code to be executed or an overridden version of the code.
The Cortex-A57 errata workarounds are applied only if they have not already been applied.
Fixes ARM-software/tf-issue#275
Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
show more ...
|
| f4f1ae77 | 13-Jan-2015 |
Soby Mathew <soby.mathew@arm.com> |
Demonstrate model for routing IRQs to EL3
This patch provides an option to specify a interrupt routing model where non-secure interrupts (IRQs) are routed to EL3 instead of S-EL1. When such an inter
Demonstrate model for routing IRQs to EL3
This patch provides an option to specify a interrupt routing model where non-secure interrupts (IRQs) are routed to EL3 instead of S-EL1. When such an interrupt occurs, the TSPD arranges a return to the normal world after saving any necessary context. The interrupt routing model to route IRQs to EL3 is enabled only during STD SMC processing. Thus the pre-emption of S-EL1 is disabled during Fast SMC and Secure Interrupt processing.
A new build option TSPD_ROUTE_NS_INT_EL3 is introduced to change the non secure interrupt target execution level to EL3.
Fixes ARM-software/tf-issues#225
Change-Id: Ia1e779fbbb6d627091e665c73fa6315637cfdd32
show more ...
|
| ab8707e6 | 08-Jan-2015 |
Soby Mathew <soby.mathew@arm.com> |
Remove coherent memory from the BL memory maps
This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The p
Remove coherent memory from the BL memory maps
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
show more ...
|
| 8c5fe0b5 | 08-Jan-2015 |
Soby Mathew <soby.mathew@arm.com> |
Move bakery algorithm implementation out of coherent memory
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
Move bakery algorithm implementation out of coherent memory
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
show more ...
|
| d07baec4 | 10-Oct-2014 |
Andrew Thoelke <andrew.thoelke@arm.com> |
Merge pull request #206 from soby-mathew/sm/reset_cntvoff
Reset CNTVOFF_EL2 register before exit into EL1 on warm boot |
| d7fbf132 | 16-Sep-2014 |
Juan Castillo <juan.castillo@arm.com> |
Fix LENGTH attribute value in linker scripts
This patch fixes the incorrect value of the LENGTH attribute in the linker scripts. This attribute must define the memory size, not the limit address.
F
Fix LENGTH attribute value in linker scripts
This patch fixes the incorrect value of the LENGTH attribute in the linker scripts. This attribute must define the memory size, not the limit address.
Fixes ARM-software/tf-issues#252
Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
show more ...
|
| ae213cee | 04-Sep-2014 |
Jens Wiklander <jens.wiklander@linaro.org> |
Initialize SCTLR_EL1 based on MODE_RW bit
Initializes SCTLR_EL1 based on MODE_RW bit in SPSR for the entry point. The RES1 bits for SCTLR_EL1 differs for Aarch64 and Aarch32 mode. |
| 14c0526b | 29-Aug-2014 |
Soby Mathew <soby.mathew@arm.com> |
Reset CNTVOFF_EL2 register before exit into EL1 on warm boot
This patch resets the value of CNTVOFF_EL2 before exit to EL1 on warm boot. This needs to be done if only the Trusted Firmware exits to E
Reset CNTVOFF_EL2 register before exit into EL1 on warm boot
This patch resets the value of CNTVOFF_EL2 before exit to EL1 on warm boot. This needs to be done if only the Trusted Firmware exits to EL1 instead of EL2, otherwise the hypervisor would be responsible for this.
Fixes ARM-software/tf-issues#240
Change-Id: I79d54831356cf3215bcf1f251c373bd8f89db0e0
show more ...
|
| 44804252 | 06-Aug-2014 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Miscellaneous documentation fixes
This patch gathers miscellaneous minor fixes to the documentation, and comments in the source code.
Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b Co-Authore
Miscellaneous documentation fixes
This patch gathers miscellaneous minor fixes to the documentation, and comments in the source code.
Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b Co-Authored-By: Soby Mathew <soby.mathew@arm.com> Co-Authored-By: Dan Handley <dan.handley@arm.com>
show more ...
|
| d3f70af6 | 14-Aug-2014 |
Soby Mathew <soby.mathew@arm.com> |
Add CPU specific crash reporting handlers
This patch adds handlers for dumping Cortex-A57 and Cortex-A53 specific register state to the CPU specific operations framework. The contents of CPUECTLR_EL
Add CPU specific crash reporting handlers
This patch adds handlers for dumping Cortex-A57 and Cortex-A53 specific register state to the CPU specific operations framework. The contents of CPUECTLR_EL1 are dumped currently.
Change-Id: I63d3dbfc4ac52fef5e25a8cf6b937c6f0975c8ab
show more ...
|
| add40351 | 14-Aug-2014 |
Soby Mathew <soby.mathew@arm.com> |
Add CPU specific power management operations
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
Add CPU specific power management operations
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
show more ...
|