- 09 Dec, 2015 11 commits
-
-
Yatharth Kochar authored
This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
-
Yatharth Kochar authored
The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
-
Yatharth Kochar authored
This patch adds Firmware Update support for ARM platforms. New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide platform specific Firmware update code. BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for authenticating NS_BL2U image(For both FVP and JUNO platform). Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
-
Yatharth Kochar authored
Firmware update(a.k.a FWU) feature is part of the TBB architecture. BL1 is responsible for carrying out the FWU process if platform specific code detects that it is needed. This patch adds support for FWU feature support in BL1 which is included by enabling `TRUSTED_BOARD_BOOT` compile time flag. This patch adds bl1_fwu.c which contains all the core operations of FWU, which are; SMC handler, image copy, authentication, execution and resumption. It also adds bl1.h introducing #defines for all BL1 SMCs. Following platform porting functions are introduced: int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size, unsigned int flags); This function can be used to add platform specific memory checks for the provided base/size for the given security state. The weak definition will invoke `assert()` and return -ENOMEM. __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved); This function can be used to initiate platform specific procedure to mark completion of the FWU process. The weak definition waits forever calling `wfi()`. plat_bl1_common.c contains weak definitions for above functions. FWU process starts when platform detects it and return the image_id other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in `bl1_main()`. NOTE: User MUST provide platform specific real definition for bl1_plat_mem_check() in order to use it for Firmware update. Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
-
Yatharth Kochar authored
As of now BL1 loads and execute BL2 based on hard coded information provided in BL1. But due to addition of support for upcoming Firmware Update feature, BL1 now require more flexible approach to load and run different images using information provided by the platform. This patch adds new mechanism to load and execute images based on platform provided image id's. BL1 now queries the platform to fetch the image id of the next image to be loaded and executed. In order to achieve this, a new struct image_desc_t was added which holds the information about images, such as: ep_info and image_info. This patch introduces following platform porting functions: unsigned int bl1_plat_get_next_image_id(void); This is used to identify the next image to be loaded and executed by BL1. struct image_desc *bl1_plat_get_image_desc(unsigned int image_id); This is used to retrieve the image_desc for given image_id. void bl1_plat_set_ep_info(unsigned int image_id, struct entry_point_info *ep_info); This function allows platforms to update ep_info for given image_id. The plat_bl1_common.c file provides default weak implementations of all above functions, the `bl1_plat_get_image_desc()` always return BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns. These functions gets compiled into all BL1 platforms by default. Platform setup in BL1, using `bl1_platform_setup()`, is now done _after_ the initialization of authentication module. This change provides the opportunity to use authentication while doing the platform setup in BL1. In order to store secure/non-secure context, BL31 uses percpu_data[] to store context pointer for each core. In case of BL1 only the primary CPU will be active hence percpu_data[] is not required to store the context pointer. This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to store the context and context pointers respectively. It also also re-defines cm_get_context() and cm_set_context() for BL1 in bl1/bl1_context_mgmt.c. BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime environment, to support resuming execution from a previously saved context. NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()` INSTEAD TO MAINTAIN EXISTING BEHAVIOUR. Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
-
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
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
-
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
-
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 1 commit
-
-
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
-
- 04 Dec, 2015 4 commits
-
-
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 2 commits
-
-
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
-
- 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 4 commits
-
-
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
-
Soby Mathew authored
This patch deprecates the legacy ARM GIC driver and related header files (arm_gic.h, gic_v2.h, gic_v3.h). For GICv2 systems, platform ports should use the GICv2 driver in include/drivers/arm/gicv2.h and for GICv3 systems, platform ports should use the GICv3 driver in include/drivers/arm/gicv3.h NOTE: The ARM Legacy GIC drivers have been deprecated with this patch. Platform ports are encouraged to migrate to the new GIC drivers. Change-Id: Ic0460ef0427b54a6aac476279a7f29b81943e942
-
Soby Mathew authored
This patch adds a driver for ARM GICv2 systems, example GIC-400. Unlike the existing GIC driver in `include/drivers/arm/arm_gic.h`, this driver is optimised for GICv2 and does not support GICv3 systems in GICv2 compatibility mode. The driver interface has been implemented in `drivers/arm/gic/v2/gicv2_main.c`. The corresponding header is in `include/drivers/arm/gicv2.h`. Helper functions are implemented in `drivers/arm/gic/v2/gicv2_helpers.c` and are accessible through the `drivers/arm/gic/v2/gicv2_private.h` header. Change-Id: I09fffa4e621fb99ba3c01204839894816cd89a2a
-
Achin Gupta authored
This patch adds a driver for ARM GICv3 systems that need to run software stacks where affinity routing is enabled across all privileged exception levels for both security states. This driver is a partial implementation of the ARM Generic Interrupt Controller Architecture Specification, GIC architecture version 3.0 and version 4.0 (ARM IHI 0069A). The driver does not cater for legacy support of interrupts and asymmetric configurations. The existing GIC driver has been preserved unchanged. The common code for GICv2 and GICv3 systems has been refactored into a new file, `drivers/arm/gic/common/gic_common.c`. The corresponding header is in `include/drivers/arm/gic_common.h`. The driver interface is implemented in `drivers/arm/gic/v3/gicv3_main.c`. The corresponding header is in `include/drivers/arm/gicv3.h`. Helper functions are implemented in `drivers/arm/gic/v3/arm_gicv3_helpers.c` and are accessible through the `drivers/arm/gic/v3/gicv3_private.h` header. Change-Id: I8c3c834a1d049d05b776b4dcb76b18ccb927444a
-
- 24 Nov, 2015 1 commit
-
-
Soby Mathew authored
This patch changes the build time behaviour when using deprecated API within Trusted Firmware. Previously the use of deprecated APIs would only trigger a build warning (which was always treated as a build error), when WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always trigger a build time warning. Whether this warning is treated as error or not is determined by the build flag ERROR_DEPRECATED which is disabled by default. When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or inclusion of deprecated headers will result in a build error. Also the deprecated context management helpers in context_mgmt.c are now conditionally compiled depending on the value of ERROR_DEPRECATED flag so that the APIs themselves do not result in a build error when the ERROR_DEPRECATED flag is set. NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to using ERROR_DEPRECATED, otherwise deprecated API usage will no longer trigger a build error. Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
-
- 19 Nov, 2015 1 commit
-
-
Sandrine Bailleux authored
The default reset values for the L2 Data & Tag RAM latencies on the Cortex-A72 on Juno R2 are not suitable. This patch modifies the Juno platform reset handler to configure the right settings on Juno R2. Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
-
- 13 Nov, 2015 1 commit
-
-
Vikram Kanigiri authored
As per Section D7.2.81 in the ARMv8-A Reference Manual (DDI0487A Issue A.h), bits[29:28], bits[23:22], bit[20] and bit[11] in the SCTLR_EL1 are RES1. This patch adds the missing bit[20] to the SCTLR_EL1_RES1 macro. Change-Id: I827982fa2856d04def6b22d8200a79fe6922a28e
-
- 02 Nov, 2015 2 commits
-
-
Juan Castillo authored
Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
-
Sandrine Bailleux authored
This patch introduces a new function called 'print_entry_point_info' that prints an entry_point_t structure for debugging purposes. As such, it can be used to display the entry point address, SPSR and arguments passed from a firmware image to the next one. This function is now called in the following images transitions: - BL1 to BL2 - BL1 to BL31 - BL31 to the next image (typically BL32 or BL33) The following changes have been introduced: - Fix the output format of the SPSR value : SPSR is a 32-bit value, not a 64-bit one. - Print all arguments values. The entry_point_info_t structure allows to pass up to 8 arguments. In most cases, only the first 2 arguments were printed. print_entry_point_info() now prints all of them as 'VERBOSE' traces. Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a
-
- 30 Oct, 2015 3 commits
-
-
Soby Mathew authored
This patch fixes a compilation issue for platforms that are aligned to ARM Standard platforms and include the `plat_arm.h` header in their platform port. The compilation would fail for such a platform because `xlat_tables.h` which has the definition for `mmap_region_t` is not included in `plat_arm.h`. This patch fixes this by including `xlat_tables.h` in `plat_arm.h` header. Fixes ARM-Software/tf-issues#318 Change-Id: I75f990cfb4078b3996fc353c8cd37c9de61d555e
-
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
-
Soby Mathew authored
This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
-
- 28 Oct, 2015 1 commit
-
-
Juan Castillo authored
This patch adds an optional API to the platform port: void plat_error_handler(int err) __dead2; The platform error handler is called when there is a specific error condition after which Trusted Firmware cannot continue. While panic() simply prints the crash report (if enabled) and spins, the platform error handler can be used to hand control over to the platform port so it can perform specific bookeeping or post-error actions (for example, reset the system). This function must not return. The parameter indicates the type of error using standard codes from errno.h. Possible errors reported by the generic code are: -EAUTH : a certificate or image could not be authenticated (when Trusted Board Boot is enabled) -ENOENT : the requested image or certificate could not be found or an IO error was detected -ENOMEM : resources exhausted. Trusted Firmware does not use dynamic memory, so this error is usually an indication of an incorrect array size A default weak implementation of this function has been provided. It simply implements an infinite loop. Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
-
- 23 Oct, 2015 2 commits
-
-
Juan Castillo authored
This patch replaces custom definitions used as return values for the load_auth_image() function with standard error codes defined in errno.h. The custom definitions have been removed. It also replaces the usage of IO framework error custom definitions, which have been deprecated. Standard errno definitions are used instead. Change-Id: I1228477346d3876151c05b470d9669c37fd231be
-
Juan Castillo authored
This patch redefines the values of IO_FAIL, IO_NOT_SUPPORTED and IO_RESOURCES_EXHAUSTED to match the corresponding definitions in errno.h: #define IO_FAIL (-ENOENT) #define IO_NOT_SUPPORTED (-ENODEV) #define IO_RESOURCES_EXHAUSTED (-ENOMEM) NOTE: please note that the IO_FAIL, IO_NOT_SUPPORTED and IO_RESOURCES_EXHAUSTED definitions are considered deprecated and their usage should be avoided. Callers should rely on errno.h definitions when checking the return values of IO functions. Change-Id: Ic8491aa43384b6ee44951ebfc053a3ded16a80be
-
- 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
-
- 19 Oct, 2015 1 commit
-
-
Sandrine Bailleux authored
The CASSERT() macro introduces a typedef for the sole purpose of triggering a compilation error if the condition to check is false. This typedef is not used afterwards. As a consequence, when the CASSERT() macro is called from withing a function block, the compiler complains and outputs the following error message: error: typedef 'msg' locally defined but not used [-Werror=unused-local-typedefs] This patch adds the "unused" attribute for the aforementioned typedef. This silences the compiler warning and thus makes the CASSERT() macro callable from within function blocks as well. Change-Id: Ie36b58fcddae01a21584c48bb6ef43ec85590479
-
- 30 Sep, 2015 1 commit
-
-
Varun Wadekar authored
This patch adds PM handlers to TLKD for the system suspend/resume and system poweroff/reset cases. TLK expects all SMCs through a single handler, which then fork out into multiple handlers depending on the SMC. We tap into the same single entrypoint by restoring the S-EL1 context before passing the PM event via register 'x0'. On completion of the PM event, TLK sends a completion SMC and TLKD then moves on with the PM process. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 28 Sep, 2015 1 commit
-
-
Sandrine Bailleux authored
The generic delay timer driver expects a pointer to a timer_ops_t structure containing the specific timer driver information. It doesn't make a copy of the structure, instead it just keeps the pointer. Therefore, this pointer must remain valid over time. The SP804 driver doesn't satisfy this requirement. The sp804_timer_init() macro creates a temporary instanciation of the timer_ops_t structure on the fly and passes it to the generic delay timer. When this temporary instanciation gets deallocated, the generic delay timer is left with a pointer to invalid data. This patch fixes this bug by statically allocating the SP804 timer_ops_t structure. Change-Id: I8fbf75907583aef06701e3fd9fabe0b2c9bc95bf
-