- 23 May, 2014 2 commits
-
-
Dan Handley authored
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
-
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
-
- 07 May, 2014 2 commits
-
-
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
-
Andrew Thoelke authored
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
-
- 06 May, 2014 1 commit
-
-
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
-
- 08 Apr, 2014 2 commits
-
-
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
-
Sandrine Bailleux authored
This reverts commit 1c297bf0 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
-
- 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
-
- 10 Mar, 2014 1 commit
-
-
Jeenu Viswambharan authored
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
-
- 17 Jan, 2014 2 commits
-
-
Harry Liebel authored
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
-
Dan Handley authored
Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
-
- 05 Dec, 2013 1 commit
-
-
Dan Handley authored
- Add instructions for contributing to ARM Trusted Firmware. - Update copyright text in all files to acknowledge contributors. Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
-
- 27 Nov, 2013 1 commit
-
-
Sandrine Bailleux authored
Any asynchronous exception caused by the firmware should be handled in the firmware itself. For this reason, unmask SError exceptions (and Debug ones as well) on all boot paths. Also route external abort and SError interrupts to EL3, otherwise they will target EL1. Change-Id: I9c191d2d0dcfef85f265641c8460dfbb4d112092
-
- 25 Oct, 2013 1 commit
-
-
Achin Gupta authored
-