github
/
arm-trusted-firmware
mirror of https://github.com/ARM-software/arm-trusted-firmware.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3350 Commits
5 Branches
114 Tags
55 MiB
Tree: 79c17995aa
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '79c17995aa'
${ noResults }
arm-trusted-firmware/plat/arm/css/common/css_common.mk

87 lines
2.7 KiB
Raw Normal View History

Add common ARM and CSS platform code 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
10 years ago
#
Build: merge build macros between FIP_ and FWU_FIP_ The build system supports generating two FIP images, fip and fwu_fip. Accordingly, we have similar build macros. FIP_ADD_PAYLOAD <--> FWU_FIP_ADD_PAYLOAD CERT_ADD_CMD_OPT <--> FWU_CERT_ADD_CMD_OPT FIP_ADD_IMG <--> FWU_FIP_ADD_IMG The duplicated code increases the maintenance burden. Also, the build rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from source files, but we want to put it in fwu_fip. We can not do it in a single macro call since the current MAKE_BL does not support fwu_fip. To refactor those in a clean way is to support one more argument to specify the FIP prefix. If it is empty, the images are targeted to fip, whereas if the argument is "FWU_", targeted to fwu_fip. The build macros prefixed with FWU_ go away. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
7 years ago
# Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved.
Add common ARM and CSS platform code 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
10 years ago
#
Use SPDX license identifiers 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>
8 years ago
# SPDX-License-Identifier: BSD-3-Clause
Add common ARM and CSS platform code 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
10 years ago
#
Make SCP_BL2(U) image loading configurable on CSS platforms 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
9 years ago
# By default, SCP images are needed by CSS platforms.
CSS_LOAD_SCP_IMAGES ?= 1
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
# By default, SCMI driver is disabled for CSS platforms
CSS: Changes for SDS framework 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>
8 years ago
CSS_USE_SCMI_SDS_DRIVER ?= 0
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
Add common ARM and CSS platform code 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
10 years ago
PLAT_INCLUDES += -Iinclude/plat/arm/css/common \
-Iinclude/plat/arm/css/common/aarch64
AArch32: Add SP_MIN support for JUNO This patch adds support for SP_MIN on JUNO platform. The changes include addition of AArch32 assembly files, JUNO specific SP_MIN make file and miscellaneous changes in ARM platform files to enable support for SP_MIN. Change-Id: Id1303f422fc9b98b9362c757b1a4225a16fffc0b Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
8 years ago
PLAT_BL_COMMON_SOURCES += plat/arm/css/common/${ARCH}/css_helpers.S
Add common ARM and CSS platform code 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
10 years ago
SoC security setup for CSS platforms in BL1 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
9 years ago
BL1_SOURCES += plat/arm/css/common/css_bl1_setup.c
Add common ARM and CSS platform code 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
10 years ago
CSS: Changes for SDS framework 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>
8 years ago
BL2_SOURCES += plat/arm/css/common/css_bl2_setup.c
Add common ARM and CSS platform code 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
10 years ago
CSS: Changes for SDS framework 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>
8 years ago
BL2U_SOURCES += plat/arm/css/common/css_bl2u_setup.c
Introduce SCP power management abstraction 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>
8 years ago
BL31_SOURCES += plat/arm/css/common/css_pm.c \
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
plat/arm/css/common/css_topology.c
CSS: Changes for SDS framework 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>
8 years ago
ifeq (${CSS_USE_SCMI_SDS_DRIVER},0)
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
BL31_SOURCES += plat/arm/css/drivers/scp/css_pm_scpi.c \
plat/arm: Add MHUv2 support to SCMI driver 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>
7 years ago
plat/arm/css/drivers/mhu/css_mhu.c \
Introduce SCP power management abstraction 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>
8 years ago
plat/arm/css/drivers/scpi/css_scpi.c
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
else
BL31_SOURCES += plat/arm/css/drivers/scp/css_pm_scmi.c \
plat/arm/css/drivers/scmi/scmi_common.c \
plat/arm/css/drivers/scmi/scmi_pwr_dmn_proto.c \
plat/arm: Add MHUv2 support to SCMI driver 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>
7 years ago
plat/arm/css/drivers/scmi/scmi_sys_pwr_proto.c \
plat/arm/css/drivers/mhu/css_mhu_doorbell.c
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
endif
Add common ARM and CSS platform code 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
10 years ago
ifneq (${RESET_TO_BL31},0)
Remove dashes from image names: 'BL3-x' --> 'BL3x' 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
9 years ago
$(error "Using BL31 as the reset vector is not supported on CSS platforms. \
Add common ARM and CSS platform code 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
10 years ago
Please set RESET_TO_BL31 to 0.")
endif
Make SCP_BL2(U) image loading configurable on CSS platforms 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
9 years ago
# Process CSS_LOAD_SCP_IMAGES flag
$(eval $(call assert_boolean,CSS_LOAD_SCP_IMAGES))
$(eval $(call add_define,CSS_LOAD_SCP_IMAGES))
ifeq (${CSS_LOAD_SCP_IMAGES},1)
Build: add generic way to include SCP_BL2 into FIP image 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>
8 years ago
NEED_SCP_BL2 := yes
Make SCP_BL2(U) image loading configurable on CSS platforms 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
9 years ago
ifneq (${TRUSTED_BOARD_BOOT},0)
Build: change the first parameter of TOOL_ADD_IMG to lowercase In the next commit, I need the image name in lowercase because output files are generally named in lowercase. Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase since we generally use uppercase Make variables. make_helpers/build_macros.mk provides 'uppercase' macro to convert a string into uppercase, but 'lowercase' does not exist. We can implement it if we like, but it would be more straightforward to change the argument of TOOL_ADD_IMG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
7 years ago
$(eval $(call TOOL_ADD_IMG,scp_bl2u,--scp-fwu-cfg,FWU_))
Make SCP_BL2(U) image loading configurable on CSS platforms 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
9 years ago
endif
CSS: Changes for SDS framework 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>
8 years ago
ifeq (${CSS_USE_SCMI_SDS_DRIVER},1)
BL2U_SOURCES += plat/arm/css/drivers/scp/css_sds.c \
plat/arm/css/drivers/sds/sds.c
Detect SCP version incompatibility 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
10 years ago
CSS: Changes for SDS framework 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>
8 years ago
BL2_SOURCES += plat/arm/css/drivers/scp/css_sds.c \
plat/arm/css/drivers/sds/sds.c
else
BL2U_SOURCES += plat/arm/css/drivers/scp/css_bom_bootloader.c \
plat/arm: Add MHUv2 support to SCMI driver 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>
7 years ago
plat/arm/css/drivers/mhu/css_mhu.c \
CSS: Changes for SDS framework 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>
8 years ago
plat/arm/css/drivers/scpi/css_scpi.c
Detect SCP version incompatibility 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
10 years ago
CSS: Changes for SDS framework 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>
8 years ago
BL2_SOURCES += plat/arm/css/drivers/scp/css_bom_bootloader.c \
plat/arm: Add MHUv2 support to SCMI driver 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>
7 years ago
plat/arm/css/drivers/mhu/css_mhu.c \
CSS: Changes for SDS framework 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>
8 years ago
plat/arm/css/drivers/scpi/css_scpi.c
# Enable option to detect whether the SCP ROM firmware in use predates version
# 1.7.0 and therefore, is incompatible.
CSS_DETECT_PRE_1_7_0_SCP := 1
# Process CSS_DETECT_PRE_1_7_0_SCP flag
$(eval $(call assert_boolean,CSS_DETECT_PRE_1_7_0_SCP))
$(eval $(call add_define,CSS_DETECT_PRE_1_7_0_SCP))
endif
endif
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
CSS: Changes for SDS framework 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>
8 years ago
ifeq (${CSS_USE_SCMI_SDS_DRIVER},1)
PLAT_BL_COMMON_SOURCES += plat/arm/css/drivers/sds/${ARCH}/sds_helpers.S
endif
CSS: Add SCMI driver for SCP This patch adds the SCMI driver for communicating with SCP. The power domain management and system power management protocol of the SCMI specification[1] is implemented in the driver. The SCP power management abstraction layer for SCMI for CSS power management is also added. A new buid option `CSS_USE_SCMI_DRIVER` is introduced to select SCMI driver over SCPI. [1] ARM System Control and Management Interface v1.0 (SCMI) Document number: ARM DEN 0056A Change-Id: I67265615a17e679a2afe810b9b0043711ba09dbb Signed-off-by: Soby Mathew <soby.mathew@arm.com>
8 years ago
CSS: Changes for SDS framework 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>
8 years ago
# Process CSS_USE_SCMI_SDS_DRIVER flag
$(eval $(call assert_boolean,CSS_USE_SCMI_SDS_DRIVER))
$(eval $(call add_define,CSS_USE_SCMI_SDS_DRIVER))