- 25 Jan, 2019 3 commits
-
-
Antonio Nino Diaz authored
Change-Id: Ida5dae39478654405d0ee31a6cbddb4579e76a7f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Change-Id: Icc59cdaf2b56f6936e9847f1894594c671db2e94 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Change-Id: I656753a1825ea7340a3708b950fa6b57455e9056 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
From now on, platform_def.h must include any header with definitions that are platform-specific (like arm_def.h) and the included headers mustn't include back platform_def.h, and shouldn't be used by other files. Only platform_def.h should be included in other files. This will ensure that all needed definitions are present, rather than needing to include all the headers in all the definitions' headers just in case. This also prevents problems like cyclic dependencies. Change-Id: I9d3cf4d1de4b956fa035c79545222697acdaf5ca Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 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>
-
- 07 Jun, 2018 1 commit
-
-
Soby Mathew authored
The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 16 Apr, 2018 1 commit
-
-
Samarth Parikh authored
Currently the SCMI driver supports MHUv1, but Arm platforms may have varied versions of MHU driver, with MHUv2 controllers being in the latest Arm platforms. This patch updates the SCMI driver to support MHUv2, specifically that the sender must send the wake-up to the receiver before initiating any data transfer. Also, the existing mhu driver files, css_mhu.c and css_mhu.h, have been moved from the scpi directory to a new directory, css/drivers/mhu. Change-Id: I9b46b492a3e1d9e26db12d83a9773958a8c8402f Signed-off-by: Samarth Parikh <samarth.parikh@arm.com>
-
- 28 Feb, 2018 1 commit
-
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined Fixed for: make DEBUG=1 PLAT=juno LOG_LEVEL=50 all Change-Id: Ic8f611da734f356566e8208053296e6c62b54709 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 06 Sep, 2017 1 commit
-
-
Soby Mathew authored
This patch does the required changes to enable CSS platforms to build and use the SDS framework. Since SDS is always coupled with SCMI protocol, the preexisting SCMI build flag is now renamed to `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on CSS platforms. Also some of the workarounds applied for SCMI are now removed with SDS in place. Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 20 Jul, 2017 2 commits
-
-
Soby Mathew authored
On ARM CSS platforms, the SCP_BL2/2U image is loaded below BL1 read-write data. This same memory is used to load BL31 later on. But sufficient checks were not done to ensure that the SCP_BL2 would not overwrite BL1 rw data. This patch adds the required CASSERT checks to prevent overwrite into BL1 or BL2 memory by load of SCP_BL2/2U. Also the size of BL31 is increased and SCP_BL2/2U size is decreased to accomodate it within the allocated region. Change-Id: I23b28b5e1589e91150852a06452bd52b273216ee Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
The SCP_BL2 is transferred to SCP during BL2 image load and authenticate sequence. The Boot-Over-MHU (BOM) protocol is used as transport for this. After the SCP boots using the transferred image, the AP CPU waits till the `READY` message is received from SCP. This patch separates the API for transport of image from the wait for `READY` message and also moves the related files to the `css/drivers` folder. The previous API `scp_bootloader_transfer` is renamed to `css_scp_boot_image_xfer` to reflect the css naming convention. This reorganisation also allows easier switch to a different transport (eg: Shared Data Structure based transfer) in future Change-Id: I8a96f9c4616ffde6dbfdf7c18f6f6f8bfa40bbf0 Signed-off-by: Soby Mathew <soby.mathew@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
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>
-
- 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
-
- 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
-
- 14 Dec, 2015 1 commit
-
-
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 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
-
- 28 Apr, 2015 3 commits
-
-
Sandrine Bailleux authored
There has been a breaking change in the communication protocols used between the AP cores and the SCP on CSS based platforms like Juno. This means both the AP Trusted Firmware and SCP firmware must be updated at the same time. In case the user forgets to update the SCP ROM firmware, this patch detects when it still uses the previous version of the communication protocol. It will then output a comprehensive error message that helps trouble-shoot the issue. Change-Id: I7baf8f05ec0b7d8df25e0ee53df61fe7be0207c2
-
Sandrine Bailleux authored
The communication protocol used between the AP cores and the SCP in CSS-based platforms like Juno has undergone a number of changes. This patch makes the required modifications to the SCP Boot Protocol, SCPI Protocol and MHU driver code in shared CSS platform code so that the AP cores are still able to communicate with the SCP. This patch focuses on the mandatory changes to make it work. The design of this code needs to be improved but this will come in a subsequent patch. The main changes are: - MHU communication protocol - The command ID and payload size are no longer written into the MHU registers directly. Instead, they are stored in the payload area. The MHU registers are now used only as a doorbell to kick off messages. Same goes for any command result, the AP has to pick it up from the payload area. - SCP Boot Protocol - The BL3-0 image is now expected to embed a checksum. This checksum must be passed to the SCP, which uses it to check the integrity of the image it received. - The BL3-0 image used to be transferred a block (4KB) at a time. The SCP now supports receiving up to 128KB at a time, which is more than the size of the BL3-0 image. Therefore, the image is now sent in one go. - The command IDs have changed. - SCPI Protocol - The size of the SCPI payload has been reduced down from 512 bytes to 256 bytes. This changes the base address of the AP-to-SCP payload area. - For commands that have a response, the response is the same SCPI header that was sent, except for the size and the status, which both must be updated appropriately. Success/Failure of a command is determined by looking at the updated status code. - Some command IDs have changed. NOTE: THIS PATCH BREAKS COMPATIBILITY WITH FORMER VERSIONS OF THE SCP FIRMWARE AND THUS REQUIRES AN UPDATE OF THIS BINARY. THE LATEST SCP BINARY CAN BE OBTAINED FROM THE ARM CONNECTED COMMUNITY WEBSITE. Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7
-
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
-
- 21 Aug, 2014 1 commit
-
-
Sandrine Bailleux authored
This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
-