- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 29 Nov, 2018 1 commit
-
-
Chandni Cherukuri authored
In order to allow Arm platforms to override the default list of PSCI callbacks, remove the existing weak implementation of 'plat_arm_psci_override_pm_ops' function and let all the Arm platforms implement their own 'plat_arm_psci_override_pm_ops' function. For platforms that support SCMI protocol, the function 'css_scmi_override_pm_ops' can be additionally used as well to override the default PSCI callbacks. Change-Id: If7c27468bd51a00ea9c2a3716b5894163f5a9f3c Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
-
- 09 Oct, 2018 1 commit
-
-
Sathees Balya authored
Change-Id: Ia00eba2b18804e6498d935d33ec104953e0e5e03 Signed-off-by: Sathees Balya <sathees.balya@arm.com>
-
- 03 Oct, 2018 1 commit
-
-
Daniel Boulby authored
Mark the initialization functions found in the BL31 boot sequence as __init so they can be reclaimed when no longer needed. Change-Id: I687a89346419c7710ef5097feaa325d83c527697 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 28 Sep, 2018 1 commit
-
-
Antonio Nino Diaz authored
- Remove references to removed build options. - Remove support for legacy GIC driver. - Remove support for LOAD_IMAGE_V2=0. Change-Id: I72f8c05620bdf4a682765e6e53e2c04ca749a3d5 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 24 Jul, 2018 2 commits
-
-
Jeenu Viswambharan authored
This also gets rid of MISRA violations for Rule 8.3 and 8.4. Change-Id: I45bba011b16f90953dd4b260fcd58381f978eedc Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Antonio Nino Diaz authored
Fix violations of MISRA C-2012 Rules 10.1, 10.3, 13.3, 14.4, 17.7 and 17.8. Change-Id: I6c9725e428b5752f1d80684ec29cb6c52a5c0c2d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 12 Jul, 2018 1 commit
-
-
Dimitris Papastamos authored
Change-Id: Iaebbeac1a1d6fbd531e5694b95ed068b7a193e62 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 11 Jul, 2018 1 commit
-
-
Sandrine Bailleux authored
The plat_arm_mmap variable is already declared in plat_arm.h, which is included from plat/arm/common/arm_common.c. Similarly, plat_arm.h declares the 'plat_arm_psci_pm_ops' variable, which does not need to be declared again in plat/arm/common/arm_pm.c. The duplication was not compliant with MISRA rule 8.5. Change-Id: Icc42547cc025023226b1078a7ec4f06d093364b7 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 19 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size reserved for BL2 has been increased. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit 2f18aa1f . It is causing some tests to fail. Until the cause is found and fixed, it is needed to remove this commit from master. Change-Id: Ic5ff7a841903a15613e00379e87cbbd8a0e85152 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size of BL31 has been increased in builds with SPM. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 13 Nov, 2017 1 commit
-
-
Jeenu Viswambharan authored
The function arm_validate_ns_entrypoint() validates a given non-secure physical address. This function however specifically returns PSCI error codes. Non-secure physical address validation is potentially useful across ARM platforms, even for non-PSCI use cases. Therefore make this function common by returning 0 for success or -1 otherwise. Having made the function common, make arm_validate_psci_entrypoint() a wrapper around arm_validate_ns_entrypoint() which only translates return value into PSCI error codes. This wrapper is now used where arm_validate_ns_entrypoint() was currently used for PSCI entry point validation. Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 11 Oct, 2017 1 commit
-
-
Soby Mathew authored
Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and arm_system_pwr_domain_save functions. Introduce FVP PSCI power level 3 (System level) support. This is solely done to provide example code on how to use the GICv3 save and restore helpers. Also make CSS GICv3 platforms power off the Redistributor on SYSTEM SUSPEND as its state is saved and restored. Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Co-Authored-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 24 May, 2017 1 commit
-
-
dp-arm authored
Since ARM_DRAM2_BASE is above the 32-bit limit, the condition is always false. Wrap this condition in an ifndef to avoid warnings during compilation. Change-Id: Ideabb6c65de6c62474ed03eb29df4b049d5316be Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 07 Dec, 2016 1 commit
-
-
Soby Mathew authored
The capabilities exposed by the PSCI generic layer depends on the hooks populated by the platform in `plat_arm_psci_pm_ops`. Currently ARM Standard platforms statically define this structure. However, some platforms may want to modify the hooks at runtime before registering them with the generic layer. This patch introduces a new ARM platform layer API `plat_arm_psci_override_pm_ops` which allows the platform to probe the power controller and modify `plat_arm_psci_pm_ops` if required. Consequently, 'plat_arm_psci_pm_ops' is no longer qualified as `const` on ARM Standard platforms. Change-Id: I7dbb44b7bd36c20ec14ded5ee45a96816ca2ab9d Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 18 Feb, 2016 1 commit
-
-
Juan Castillo authored
The shared memory region on ARM platforms contains the mailboxes and, on Juno, the payload area for communication with the SCP. This shared memory may be configured as normal memory or device memory at build time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED'). When set as normal memory, the platform port performs the corresponding cache maintenance operations. From a functional point of view, this is the equivalent of setting the shared memory as device memory, so there is no need to maintain both options. This patch removes the option to specify the shared memory as normal memory on ARM platforms. Shared memory is always treated as device memory. Cache maintenance operations are no longer needed and have been replaced by data memory barriers to guarantee that payload and MHU are accessed in the right order. Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
-
- 09 Dec, 2015 2 commits
-
-
Soby Mathew authored
This patch overrides the default weak definition of `bl31_plat_runtime_setup()` for ARM Standard platforms to specify a BL31 runtime console. ARM Standard platforms are now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required by `arm_bl31_plat_runtime_setup()` to initialize the runtime console. The system suspend resume helper `arm_system_pwr_domain_resume()` is fixed to initialize the runtime console rather than the boot console on resumption from system suspend. Fixes ARM-software/tf-issues#220 Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
-
Achin Gupta authored
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
-
- 26 Nov, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch adds support for booting EL3 payloads on CSS platforms, for example Juno. In this scenario, the Trusted Firmware follows its normal boot flow up to the point where it would normally pass control to the BL31 image. At this point, it jumps to the EL3 payload entry point address instead. Before handing over to the EL3 payload, the data SCP writes for AP at the beginning of the Trusted SRAM is restored, i.e. we zero the first 128 bytes and restore the SCP Boot configuration. The latter is saved before transferring the BL30 image to SCP and is restored just after the transfer (in BL2). The goal is to make it appear that the EL3 payload is the first piece of software to run on the target. The BL31 entrypoint info structure is updated to make the primary CPU jump to the EL3 payload instead of the BL31 image. The mailbox is populated with the EL3 payload entrypoint address, which releases the secondary CPUs out of their holding pen (if the SCP has powered them on). The arm_program_trusted_mailbox() function has been exported for this purpose. The TZC-400 configuration in BL2 is simplified: it grants secure access only to the whole DRAM. Other security initialization is unchanged. This alternative boot flow is disabled by default. A new build option EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3 payload's entry point address. The build system has been modified such that BL31 and BL33 are not compiled and/or not put in the FIP in this case, as those images are not used in this boot flow. Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
-
- 30 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch adds the capability to power down at system power domain level on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers are modified to add support for power management operations at system power domain level. A new helper for populating `get_sys_suspend_power_state` handler in plat_psci_ops is defined. On entering the system suspend state, the SCP powers down the SYSTOP power domain on the SoC and puts the memory into retention mode. On wakeup from the power down, the system components on the CSS will be reinitialized by the platform layer and the PSCI client is responsible for restoring the context of these system components. According to PSCI Specification, interrupts targeted to cores in PSCI CPU SUSPEND should be able to resume it. On Juno, when the system power domain is suspended, the GIC is also powered down. The SCP resumes the final core to be suspend when an external wake-up event is received. But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP. Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level in `juno_validate_power_state()` and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c. A system power domain resume helper `arm_system_pwr_domain_resume()` is defined for ARM standard platforms which resumes/re-initializes the system components on wakeup from system suspend. The security setup also needs to be done on resume from system suspend, which means `plat_arm_security_setup()` must now be included in the BL3-1 image in addition to previous BL images if system suspend need to be supported. Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
-
- 20 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch does the following reorganization to psci power management (PM) handler setup for ARM standard platform ports : 1. The mailbox programming required during `plat_setup_psci_ops()` is identical for all ARM platforms. Hence the implementation of this API is now moved to the common `arm_pm.c` file. Each ARM platform now must define the PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same as ARM_SHARED_RAM_BASE. 2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be exported via `plat_arm_psci_pm_ops`. This allows the common implementation of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`. In the case of CSS platforms, a default weak implementation of the same is provided in `css_pm.c` which can be overridden by each CSS platform. 3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now made library functions and a new header file `css_pm.h` is added to export these generic PM handlers. This allows the platform to reuse the adequate CSS PM handlers and redefine others which need to be customized when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`. Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
-
- 13 Aug, 2015 3 commits
-
-
Soby Mathew authored
This patch implements the platform power managment handler to verify non secure entrypoint for ARM platforms. The handler ensures that the entry point specified by the normal world during CPU_SUSPEND, CPU_ON or SYSTEM_SUSPEND PSCI API is a valid address within the non secure DRAM. Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
-
Soby Mathew authored
This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
-
Soby Mathew authored
This patch migrates ARM reference platforms, Juno and FVP, to the new platform API mandated by the new PSCI power domain topology and composite power state frameworks. The platform specific makefiles now exports the build flag ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer. Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
-
- 28 Apr, 2015 1 commit
-
-
Dan Handley authored
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
-
- 31 Mar, 2015 1 commit
-
-
Varun Wadekar authored
TLK Dispatcher (tlkd) is based on the tspd and is the glue required to run TLK as a Secure Payload with the Trusted Firmware. Change-Id: I69e573d26d52342eb049feef773dd7d2a506f4ab Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 15 Aug, 2014 1 commit
-
-
Achin Gupta authored
This patch disables routing of external aborts from lower exception levels to EL3 and ensures that a SError interrupt generated as a result of execution in EL3 is taken locally instead of a lower exception level. The SError interrupt is enabled in the TSP code only when the operation has not been directly initiated by the normal world. This is to prevent the possibility of an asynchronous external abort which originated in normal world from being taken when execution is in S-EL1. Fixes ARM-software/tf-issues#153 Change-Id: I157b996c75996d12fd86d27e98bc73dd8bce6cd5
-
- 28 Jul, 2014 1 commit
-
-
Achin Gupta authored
This patch reworks the manner in which the M,A, C, SA, I, WXN & EE bits of SCTLR_EL3 & SCTLR_EL1 are managed. The EE bit is cleared immediately after reset in EL3. The I, A and SA bits are set next in EL3 and immediately upon entry in S-EL1. These bits are no longer managed in the blX_arch_setup() functions. They do not have to be saved and restored either. The M, WXN and optionally the C bit are set in the enable_mmu_elX() function. This is done during both the warm and cold boot paths. Fixes ARM-software/tf-issues#226 Change-Id: Ie894d1a07b8697c116960d858cd138c50bc7a069
-
- 24 Jun, 2014 1 commit
-
-
Juan Castillo authored
Exclude stdlib files because they do not follow kernel code style. Fixes ARM-software/tf-issues#73 Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab
-
- 23 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
Consolidate all BL3-1 CPU context initialization for cold boot, PSCI and SPDs into two functions: * The first uses entry_point_info to initialize the relevant cpu_context for first entry into a lower exception level on a CPU * The second populates the EL1 and EL2 system registers as needed from the cpu_context to ensure correct entry into the lower EL This patch alters the way that BL3-1 determines which exception level is used when first entering EL1 or EL2 during cold boot - this is now fully determined by the SPSR value in the entry_point_info for BL3-3, as set up by the platform code in BL2 (or otherwise provided to BL3-1). In the situation that EL1 (or svc mode) is selected for a processor that supports EL2, the context management code will now configure all essential EL2 register state to ensure correct execution of EL1. This allows the platform code to run non-secure EL1 payloads directly without requiring a small EL2 stub or OS loader. Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f
-
- 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 1 commit
-
-
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
-