- 05 Apr, 2017 1 commit
-
-
Masahiro Yamada authored
If SCP_BL2 is passed in from the command line, it is recognized by make_helpers/tbbr/tbbr_tools.mk, and the cert_create tool generates the corresponding key and content certificates. On the other hand, the top-level Makefile does not care SCP_BL2, so the --scp-fw option is not passed to the fiptool. As far as I see plat/arm/css/common/css_common.mk, it looks like a platform's job to add $(eval $(call FIP_ADD_IMG,SCP_BL2,--scp-fw)). We can make the top-level Makefile kind enough to take care of it. This is useful when we want to have optional SCP_BL2 firmware. Adjust css_common.mk so that Juno still requires SCP_BL2 by default. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 27 Mar, 2017 1 commit
-
-
Summer Qin authored
This patch modifies some of the functions in ARM platform layer to cater for the case when multi-threading `MT` is set in MPIDR. A new build flag `ARM_PLAT_MT` is added, and when enabled, the functions accessing MPIDR now assume that the `MT` bit is set for the platform and access the bit fields accordingly. Also, a new API plat_arm_get_cpu_pe_count is added when `ARM_PLAT_MT` is enabled, returning the PE count within the physical cpu corresponding to `mpidr`. Change-Id: I04ccf212ac3054a60882761f4087bae299af13cb Signed-off-by: Summer Qin <summer.qin@arm.com>
-
- 06 Feb, 2017 1 commit
-
-
Douglas Raillard authored
Introduce zeromem_dczva function on AArch64 that can handle unaligned addresses and make use of DC ZVA instruction to zero a whole block at a time. This zeroing takes place directly in the cache to speed it up without doing external memory access. Remove the zeromem16 function on AArch64 and replace it with an alias to zeromem. This zeromem16 function is now deprecated. Remove the 16-bytes alignment constraint on __BSS_START__ in firmware-design.md as it is now not mandatory anymore (it used to comply with zeromem16 requirements). Change the 16-bytes alignment constraints in SP min's linker script to a 8-bytes alignment constraint as the AArch32 zeromem implementation is now more efficient on 8-bytes aligned addresses. Introduce zero_normalmem and zeromem helpers in platform agnostic header that are implemented this way: * AArch32: * zero_normalmem: zero using usual data access * zeromem: alias for zero_normalmem * AArch64: * zero_normalmem: zero normal memory using DC ZVA instruction (needs MMU enabled) * zeromem: zero using usual data access Usage guidelines: in most cases, zero_normalmem should be preferred. There are 2 scenarios where zeromem (or memset) must be used instead: * Code that must run with MMU disabled (which means all memory is considered device memory for data accesses). * Code that fills device memory with null bytes. Optionally, the following rule can be applied if performance is important: * Code zeroing small areas (few bytes) that are not secrets should use memset to take advantage of compiler optimizations. Note: Code zeroing security-related critical information should use zero_normalmem/zeromem instead of memset to avoid removal by compilers' optimizations in some cases or misbehaving versions of GCC. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 07 Dec, 2016 2 commits
-
-
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>
-
Soby Mathew authored
This patch introduces an additional layer of abstraction between CSS power management hooks and the SCPI driver. A new set of APIs are introduced in order to abstract out power management operations from underlying communication mechanism with the SCP. The SCPI and the associated MHU drivers are moved into a `drivers` folder in CSS. The new SCP communication abstraction layer is added in the `drivers/scp` folder. The existing CSS power management uses the new APIs to reflect this abstraction. Change-Id: I7d775129fc0558e9703c2724523fb8f0a916838c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 21 Sep, 2016 1 commit
-
-
Yatharth Kochar authored
This patch adds changes in ARM platform code to use new version of image loading. Following are the major changes: -Refactor the signatures for bl31_early_platform_setup() and arm_bl31_early_platform_setup() function to use `void *` instead of `bl31_params_t *`. -Introduce `plat_arm_bl2_handle_scp_bl2()` to handle loading of SCP_BL2 image from BL2. -Remove usage of reserve_mem() function from `arm_bl1_early_platform_setup()` -Extract BL32 & BL33 entrypoint info, from the link list passed by BL2, in `arm_bl31_early_platform_setup()` -Provides weak definitions for following platform functions: plat_get_bl_image_load_info plat_get_next_bl_params plat_flush_next_bl_params bl2_plat_handle_post_image_load -Instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL31`, `BL32` and `BL33` images. All the above changes are conditionally compiled using the `LOAD_IMAGE_V2` flag. Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
-
- 15 Sep, 2016 2 commits
-
-
Jeenu Viswambharan authored
This patch implements CSS platform hook to support NODE_HW_STATE PSCI API. The platform hook queries SCP to obtain CSS power state. Power states returned by SCP are then converted to expected PSCI return codes. Juno's PSCI operation structure is modified to use the CSS implementation. Change-Id: I4a5edac0e5895dd77b51398cbd78f934831dafc0
-
Jeenu Viswambharan authored
This patch adds the function scpi_get_css_power_state to perform the 'Get CSS Power State' SCP command and handle its response. The function parses SCP response to obtain power states of requested cluster and CPUs within. Change-Id: I3ea26e48dff1a139da73f6c1e0893f21accaf9f0
-
- 18 Jul, 2016 1 commit
-
-
Soby Mathew authored
This patch reworks type usage in generic code, drivers and ARM platform files to make it more portable. The major changes done with respect to type usage are as listed below: * Use uintptr_t for storing address instead of uint64_t or unsigned long. * Review usage of unsigned long as it can no longer be assumed to be 64 bit. * Use u_register_t for register values whose width varies depending on whether AArch64 or AArch32. * Use generic C types where-ever possible. In addition to the above changes, this patch also modifies format specifiers in print invocations so that they are AArch64/AArch32 agnostic. Only files related to upcoming feature development have been reworked. Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
-
- 08 Jun, 2016 1 commit
-
-
David Wang authored
In GICv3 mode, the non secure group1 interrupts are signalled via the FIQ line in EL3. To support waking up from CPU_SUSPEND to standby on these systems, EL3 should route FIQ to EL3 temporarily before wfi and restore the original setting after resume. This patch makes this change for the CSS platforms in the `css_cpu_standby` psci pm ops hook. Change-Id: Ibf3295d16e2f08da490847c1457bc839e1bac144
-
- 19 Feb, 2016 1 commit
-
-
Soby Mathew authored
The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
-
- 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
-
- 16 Feb, 2016 2 commits
-
-
Vikram Kanigiri authored
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
-
Vikram Kanigiri authored
Current code mandates loading of SCP_BL2/SCP_BL2U images for all CSS platforms. On future ARM CSS platforms, the Application Processor (AP) might not need to load these images. So, these items can be removed from the FIP on those platforms. BL2 tries to load SCP_BL2/SCP_BL2U images if their base addresses are defined causing boot error if the images are not found in FIP. This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set to `1` does: 1. Adds SCP_BL2, SCP_BL2U images to FIP. 2. Defines the base addresses of these images so that AP loads them. And vice-versa if it is set to `0`. The default value is set to `1`. Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
-
- 15 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
-
- 11 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
-
- 05 Feb, 2016 1 commit
-
-
Antonio Nino Diaz authored
Replaced a long dash in a comment by the ASCII character '-'. Support for multibyte character in the source character set is not enforced by the C99 standard. To maximize compatibility with C processing tools (e.g. compilers or static code analysis tools), they should be removed. Change-Id: Ie318e380d3b44755109f042a76ebfd2229f42ae3
-
- 05 Jan, 2016 1 commit
-
-
Juan Castillo authored
The fip_create tool specifies images in the command line using the ARM TF naming convention (--bl2, --bl31, etc), while the cert_create tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double convention is confusing and should be aligned. This patch updates the fip_create command line options to follow the TBBR naming convention. Usage examples in the User Guide have been also updated. NOTE: users that build the FIP by calling the fip_create tool directly from the command line must update the command line options in their scripts. Users that build the FIP by invoking the main ARM TF Makefile should not notice any difference. Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
-
- 14 Dec, 2015 2 commits
-
-
Juan Castillo authored
This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
-
Juan Castillo authored
This patch replaces all references to the SCP Firmware (BL0, BL30, BL3-0, bl30) with the image terminology detailed in the TF wiki (https://github.com/ARM-software/arm-trusted-firmware/wiki): BL0 --> SCP_BL1 BL30, BL3-0 --> SCP_BL2 bl30 --> scp_bl2 This change affects code, documentation, build system, tools and platform ports that load SCP firmware. ARM plaforms have been updated to the new porting API. IMPORTANT: build option to specify the SCP FW image has changed: BL30 --> SCP_BL2 IMPORTANT: This patch breaks compatibility for platforms that use BL2 to load SCP firmware. Affected platforms must be updated as follows: BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID BL30_BASE --> SCP_BL2_BASE bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo() bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2() Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
-
- 09 Dec, 2015 5 commits
-
-
Yatharth Kochar authored
Firmware update feature needs a new FIP called `fwu_fip.bin` that includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images along with the FWU_CERT certificate in order for NS_BL1U to load the images and help the Firmware update process to complete. This patch adds the capability to support the new target `fwu_fip` which includes above mentioned FWU images in the make files. The new target of `fwu_fip` and its dependencies are included for compilation only when `TRUSTED_BOARD_BOOT` is defined. Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc
-
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
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
-
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
-
- 26 Nov, 2015 2 commits
-
-
Sandrine Bailleux authored
By default, only the primary CPU is powered on by SCP on CSS platforms. Secondary CPUs are then powered on later using PSCI calls. However, it is possible to power on more than one CPU at boot time using platform specific settings. In this case, several CPUs will enter the Trusted Firmware and execute the cold boot path code. This is currently not supported and secondary CPUs will panic. This patch preserves this behaviour in the normal boot flow. However, when booting an EL3 payload, secondary CPUs are now held in a pen until their mailbox is populated, at which point they jump to this address. Note that, since all CPUs share the same mailbox, they will all be released from their holding pen at the same time and the EL3 payload is responsible to arbitrate execution between CPUs if required. Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9
-
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 2 commits
-
-
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
-
- 27 Oct, 2015 2 commits
-
-
Juan Castillo authored
This patch is a complete rework of the main Makefile. Functionality remains the same but the code has been reorganized in sections in order to improve readability and facilitate adding future extensions. A new file 'build_macros.mk' has been created and will contain common definitions (variables, macros, etc) that may be used from the main Makefile and other platform specific makefiles. A new macro 'FIP_ADD_IMG' has been introduced and it will allow the platform to specify binary images and the necessary checks for a successful build. Platforms that require a BL30 image no longer need to specify the NEED_BL30 option. The main Makefile is now completely unaware of additional images not built as part of Trusted Firmware, like BL30. It is the platform responsibility to specify images using the macro 'FIP_ADD_IMG'. Juno uses this macro to include the BL30 image in the build. BL33 image is specified in the main Makefile to preserve backward compatibility with the NEED_BL33 option. Otherwise, platform ports that rely on the definition of NEED_BL33 might break. All Trusted Board Boot related definitions have been moved to a separate file 'tbbr_tools.mk'. The main Makefile will include this file unless the platform indicates otherwise by setting the variable 'INCLUDE_TBBR_MK := 0' in the corresponding platform.mk file. This will keep backward compatibility but ideally each platform should include the corresponding TBB .mk file in platform.mk. Change-Id: I35e7bc9930d38132412e950e20aa2a01e2b26801
-
David Wang authored
Currently all ARM CSS platforms which include css_helpers.S use the same strong definition of `plat_arm_calc_core_pos`. This patch allows these CSS platforms to define their own strong definition of this function. * Replace the strong definition of `plat_arm_calc_core_pos` in css_helpers.S with a utility function `css_calc_core_pos_swap_cluster` does the same thing (swaps cluster IDs). ARM CSS platforms may choose to use this function or not. * Add a Juno strong definition of `plat_arm_calc_core_pos`, which uses `css_calc_core_pos_swap_cluster`. Change-Id: Ib5385ed10e44adf6cd1398a93c25973eb3506d9d
-
- 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 6 commits
-
-
Soby Mathew authored
This patch adds the necessary documentation updates to porting_guide.md for the changes in the platform interface mandated as a result of the new PSCI Topology and power state management frameworks. It also adds a new document `platform-migration-guide.md` to aid the migration of existing platform ports to the new API. The patch fixes the implementation and callers of plat_is_my_cpu_primary() to use w0 as the return parameter as implied by the function signature rather than x0 which was used previously. Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
-
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
-
Sandrine Bailleux authored
Now that the FVP mailbox is no longer zeroed, the function platform_mem_init() does nothing both on FVP and on Juno. Therefore, this patch pools it as the default implementation on ARM platforms. Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91
-
Sandrine Bailleux authored
Since there is a unique warm reset entry point, the FVP and Juno port can use a single mailbox instead of maintaining one per core. The mailbox gets programmed only once when plat_setup_psci_ops() is invoked during PSCI initialization. This means mailbox is not zeroed out during wakeup. Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
-
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
-
- 09 Jun, 2015 1 commit
-
-
Sandrine Bailleux authored
For CSS based platforms, the constants MHU_SECURE_BASE and MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes. As such, they were misnamed because the mailboxes are completely unrelated to the MHU hardware. This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines. The address of the Trusted Mailboxes is now relative to the base of the Trusted SRAM. This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE, which is the address of the first memory region used for communication between AP and SCP. This is used by the BOM and SCPI protocols. Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
-
- 27 May, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the primary cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in platform_is_primary_cpu(). Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa
-