- 09 Dec, 2015 17 commits
-
-
Yatharth Kochar authored
The upcoming Firmware Update feature needs transitioning across Secure/Normal worlds to complete the FWU process and hence requires context management code to perform this task. Currently context management code is part of BL31 stage only. This patch moves the code from (include)/bl31 to (include)/common. Some function declarations/definitions and macros have also moved to different files to help code sharing. Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
-
Yatharth Kochar authored
This patch adds support for secure setup of the SoC on CSS platforms in BL1. This change is required to provide memory access to normal world images that take part in upcoming Firmware Update feature. Change-Id: Ib202fb6cb82622c1874b700637d82ea72575e6fe
-
Yatharth Kochar authored
The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to make a request to BL1 to execute BL31. But BL2 also uses it as opcode to check if it is allowed to execute which is not the intended usage of `RUN_IMAGE` SMC. This patch removes the usage of `RUN_IMAGE` as opcode passed to next EL to check if it is allowed to execute. Change-Id: I6aebe0415ade3f43401a4c8a323457f032673657
-
Yatharth Kochar authored
This patch adds `uppercase` macro to prepare IMAGE_BLxx defines used for conditional compilation and to prepare variables used for defining BL source and linker file names. This change is needed for upcoming BL images that can have names which uses both letters and numbers. Change-Id: I05ce9bcd0d221a54db92c0fe3ad28e9e0080ed2e
-
danh-arm authored
Include psci.h from tegra platform header
-
Yatharth Kochar authored
The `plat/nvidia/tegra/include/tegra_private.h` file uses resources from psci.h (for example, psci_power_state_t) but does not explicitly include psci.h. This does not currently cause a problem since psci.h is indirectly included via other headers. However, this may not be the case in future. This patch explicitly includes psci.h from tegra_private.h Change-Id: Ia991147898dbd117c1d3496a95850995a5554c05
-
danh-arm authored
Initialize VTTBR_EL2 when bypassing EL2
-
Sandrine Bailleux authored
In the situation that EL1 is selected as the exception level for the next image upon BL31 exit for a processor that supports EL2, the context management code must configure all essential EL2 register state to ensure correct execution of EL1. VTTBR_EL2 should be part of this set of EL2 registers because: - The ARMv8-A architecture does not define a reset value for this register. - Cache maintenance operations depend on VTTBR_EL2.VMID even when non-secure EL1&0 stage 2 address translation are disabled. This patch initializes the VTTBR_EL2 register to 0 when bypassing EL2 to address this issue. Note that this bug has not yet manifested itself on FVP or Juno because VTTBR_EL2.VMID resets to 0 on the Cortex-A53 and Cortex-A57. Change-Id: I58ce2d16a71687126f437577a506d93cb5eecf33
-
danh-arm authored
Remove the assert for TZC base during initialization
-
danh-arm authored
Fix issue in Floating point register restore
-
danh-arm authored
Modify TSP and ARM standard platforms for new GIC drivers v2
-
danh-arm authored
Fix SP804 delay timer on FVP
-
Soby Mathew authored
The `fpregs_context_restore()` function used to restore the floating point regsiter context had a typo error wherein it was doing `str` instead of `ldr` for a register. This issue remained undetected becuase none of the ARM Standard development platforms save and restore the floating point register context when a context switch is done. This patch corrects the issue. Change-Id: Id178e0ba254a5e0a4a844f54b39d71dc34e0f6ea
-
Soby Mathew authored
Earlier the TSP only ever expected to be preempted during Standard SMC processing. If a S-EL1 interrupt triggered while in the normal world, it will routed to S-EL1 `synchronously` for handling. The `synchronous` S-EL1 interrupt handler `tsp_sel1_intr_entry` used to panic if this S-EL1 interrupt was preempted by another higher priority pending interrupt which should be handled in EL3 e.g. Group0 interrupt in GICv3. With this patch, the `tsp_sel1_intr_entry` now expects `TSP_PREEMPTED` as the return code from the `tsp_common_int_handler` in addition to 0 (interrupt successfully handled) and in both cases it issues an SMC with id `TSP_HANDLED_S_EL1_INTR`. The TSPD switches the context and returns back to normal world. In case a higher priority EL3 interrupt was pending, the execution will be routed to EL3 where interrupt will be handled. On return back to normal world, the pending S-EL1 interrupt which was preempted will get routed to S-EL1 to be handled `synchronously` via `tsp_sel1_intr_entry`. Change-Id: I2087c7fedb37746fbd9200cdda9b6dba93e16201
-
Soby Mathew authored
This patch enables support for EL3 interrupts in the Interrupt Management Framework (IMF) of ARM Trusted Firmware. Please note that although the registration of the EL3 interrupt type is now supported, it has not been tested on any of the ARM Standard platforms. Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1
-
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
-
Soby Mathew authored
This patch adds platform helpers for the new GICv2 and GICv3 drivers in plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate file in their build according to the GIC driver to be used. The existing plat_gic.c is only meant for the legacy GIC driver. In the case of ARM platforms, the major changes are as follows: 1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU interface register values has been modified to detect the type of CPU interface being used (System register or memory mappped interface) before using the right interface to print the registers. 2. The power management helper function that is called after a core is powered up has been further refactored. This is to highlight that the per-cpu distributor interface should be initialised only when the core was originally powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API was used. 3. In the case of CSS platforms, the system power domain restore helper `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish` handler as the system power domain is always expected to be initialized when the `on_finish` handler is invoked. Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
-
- 08 Dec, 2015 4 commits
-
-
danh-arm authored
Add CCI-400 specific driver to deprecated driver list
-
Vikram Kanigiri authored
Add compile time `__warn_deprecated` flag to public api's in CCI-400 specific driver so that user is aware of the driver being deprecated. Similarly, it also adds an error message when `ERROR_DEPRECATED` is set to prevent succesful compilation if CCI-400 specific driver is used. Change-Id: Id7e61a560262abc01cbbd432ca85b9bf448a194d
-
Soby Mathew authored
When resuming from system suspend the TZC needs to be re-initialized. Hence the assertion for TZC base address to detect re-initialization is removed. Change-Id: I53d64146f6c919e95526441bb997f7b309c68141
-
danh-arm authored
Tegra new platform apis v2
-
- 04 Dec, 2015 5 commits
-
-
Varun Wadekar authored
This patch modifies the Tegra port to support the new platform APIs so that we can disable the compat layer. This includes modifications to the power management and platform topology code. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Soby Mathew authored
On a GICv2 system, interrupts that should be handled in the secure world are typically signalled as FIQs. On a GICv3 system, these interrupts are signalled as IRQs instead. The mechanism for handling both types of interrupts is the same in both cases. This patch enables the TSP to run on a GICv3 system by: 1. adding support for handling IRQs in the exception handling code. 2. removing use of "fiq" in the names of data structures, macros and functions. The build option TSPD_ROUTE_IRQ_TO_EL3 is deprecated and is replaced with a new build flag TSP_NS_INTR_ASYNC_PREEMPT. For compatibility reasons, if the former build flag is defined, it will be used to define the value for the new build flag. The documentation is also updated accordingly. Change-Id: I1807d371f41c3656322dd259340a57649833065e
-
Soby Mathew authored
The TSP is expected to pass control back to EL3 if it gets preempted due to an interrupt while handling a Standard SMC in the following scenarios: 1. An FIQ preempts Standard SMC execution and that FIQ is not a TSP Secure timer interrupt or is preempted by a higher priority interrupt by the time the TSP acknowledges it. In this case, the TSP issues an SMC with the ID as `TSP_EL3_FIQ`. Currently this case is never expected to happen as only the TSP Secure Timer is expected to generate FIQ. 2. An IRQ preempts Standard SMC execution and in this case the TSP issues an SMC with the ID as `TSP_PREEMPTED`. In both the cases, the TSPD hands control back to the normal world and returns returns an error code to the normal world to indicate that the standard SMC it had issued has been preempted but not completed. This patch unifies the handling of these two cases in the TSPD and ensures that the TSP only uses TSP_PREEMPTED instead of separate SMC IDs. Also instead of 2 separate error codes, SMC_PREEMPTED and TSP_EL3_FIQ, only SMC_PREEMPTED is returned as error code back to the normal world. Background information: On a GICv3 system, when the secure world has affinity routing enabled, in 2. an FIQ will preempt TSP execution instead of an IRQ. The FIQ could be a result of a Group 0 or a Group 1 NS interrupt. In both case, the TSPD passes control back to the normal world upon receipt of the TSP_PREEMPTED SMC. A Group 0 interrupt will immediately preempt execution to EL3 where it will be handled. This allows for unified interrupt handling in TSP for both GICv3 and GICv2 systems. Change-Id: I9895344db74b188021e3f6a694701ad272fb40d4
-
Soby Mathew authored
This patch renames the GICv3 interrupt group macros from INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0, INTR_GROUP1S and INTR_GROUP1NS respectively. Change-Id: I40c66f589ce6234fa42205adcd91f7d6ad8f33d4
-
Juan Castillo authored
This patch fixes several issues with the SP804 delay timer on FVP: * By default, the SP804 dual timer on FVP runs at 32 KHz. In order to run the timer at 35 MHz (as specified in the FVP user manual) the Overwrite bit in the SP810 control register must be set. * The CLKMULT and CLKDIV definitions are mixed up: delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz) From the delay function: delta_us = (delta * ops->clk_mult) / ops->clk_div; Matching both expressions: 1 / f(MHz) = ops->clk_mult / ops->clk_div And consequently: f(MHz) = ops->clk_div / ops->clk_mult Which, for a 35 MHz timer, translates to: ops->clk_div = 35 ops->clk_mult = 1 * The comment in the delay timer header file has been corrected: The ratio of the multiplier and the divider is the clock period in microseconds, not the frequency. Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
-
- 02 Dec, 2015 5 commits
-
-
danh-arm authored
Fix TZC-400 peripheral detection
-
danh-arm authored
TBB: add ARM OIDs
-
danh-arm authored
Jc/tbb wdog
-
Juan Castillo authored
This patch adds watchdog support on ARM platforms (FVP and Juno). A secure instance of SP805 is used as Trusted Watchdog. It is entirely managed in BL1, being enabled in the early platform setup hook and disabled in the exit hook. By default, the watchdog is enabled in every build (even when TBB is disabled). A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG` has been introduced to allow the user to disable the watchdog at build time. This feature may be used for testing or debugging purposes. Specific error handlers for Juno and FVP are also provided in this patch. These handlers will be called after an image load or authentication error. On FVP, the Table of Contents (ToC) in the FIP is erased. On Juno, the corresponding error code is stored in the V2M Non-Volatile flags register. In both cases, the CPU spins until a watchdog reset is generated after 256 seconds (as specified in the TBBR document). Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
-
Juan Castillo authored
This patch adds ARM specific OIDs which will be used to extract the extension data from the certificates. These OIDs are arranged as a subtree whose root node has been specifically allocated for ARM Ltd. { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 4128 } Change-Id: Ice20b3c8a31ddefe9102f3bd42f7429986f3ac34
-
- 01 Dec, 2015 3 commits
- 27 Nov, 2015 3 commits
-
-
Vikram Kanigiri authored
The TZC-400 driver implementation incorrectly uses the component ID registers to detect the TZC-400 peripheral. As all ARM peripherals share the same component ID, it doesn't allow to uniquely identify the TZC-400 peripheral. This patch fixes the TZC-400 driver by relying on the `part_number_0` and `part_number_1` fields in the `PID` registers instead. The `tzc_read_component_id` function has been replaced by `tzc_read_peripheral_id`, which reads the 'part_number' values and compares them with the TZC-400 peripheral ID. Also, it adds a debug assertion to detect when the TZC driver initialisation function is called multiple times. Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6
-
Juan Castillo authored
Based on SP805 Programmer's model (ARM DDI 0270B). This driver provides three public APIs: void sp805_start(uintptr_t base, unsigned long ticks); void sp805_stop(uintptr_t base); void sp805_refresh(uintptr_t base, unsigned long ticks); Upon start, the watchdog starts counting down from the number of ticks specified. When the count reaches 0 an interrupt is triggered. The watchdog restarts counting down from the number of ticks specified. If the count reaches 0 again, the system is reset. A mechanism to handle the interrupt has not been implemented. Instead, the API to refresh the watchdog should be used instead to prevent a system reset. Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab
-
Juan Castillo authored
FVP and Juno platforms include a NOR flash memory to store and load the FIP, the kernel or a ramdisk. This NOR flash is arranged as 2 x 16 bit flash devices and can be programmed using CFI standard commands. This patch provides a basic API to write single 32 bit words of data into the NOR flash. Functions to lock/unlock blocks against erase or write operations are also provided. Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
-
- 26 Nov, 2015 3 commits
-
-
Sandrine Bailleux authored
The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on the platform porting layer are simple enough to be described in the User Guide directly. This patch removes the reference to the Porting Guide. Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d
-
Sandrine Bailleux authored
This patch introduces a new build option named COLD_BOOT_SINGLE_CPU, which allows platforms that only release a single CPU out of reset to slightly optimise their cold boot code, both in terms of code size and performance. COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform may release several CPUs out of reset. In this case, the cold reset code needs to coordinate all CPUs via the usual primary/secondary CPU distinction. If a platform guarantees that only a single CPU will ever be released out of reset, there is no need to arbitrate execution ; the notion of primary and secondary CPUs itself no longer exists. Such platforms may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the primary/secondary CPU identification in the cold reset code. All ARM standard platforms can release several CPUs out of reset so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like Juno, bringing up more than one CPU at reset should only be attempted when booting an EL3 payload, as it is not fully supported in the normal boot flow. For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform APIs become optional: - plat_secondary_cold_boot_setup(); - plat_is_my_cpu_primary(). The Porting Guide has been updated to reflect that. User Guide updated as well. Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
-
Sandrine Bailleux authored
- Document the new build option EL3_PAYLOAD_BASE - Document the EL3 payload boot flow - Document the FVP model parameters to boot an EL3 payload Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37
-