arm-trusted-firmware/plat/arm/css/drivers/scp/css_bom_bootloader.c

195 lines
5.1 KiB
C
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
2015-03-19 18:58:55 +00:00
/*
* Copyright (c) 2014-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
2015-03-19 18:58:55 +00:00
*
* 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
2015-03-19 18:58:55 +00:00
*/
#include <arch_helpers.h>
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
#include <assert.h>
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
2015-03-19 18:58:55 +00:00
#include <css_def.h>
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
#include <debug.h>
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
2015-03-19 18:58:55 +00:00
#include <platform.h>
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
#include <stdint.h>
#include "../scpi/css_mhu.h"
#include "../scpi/css_scpi.h"
#include "css_scp.h"
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
/* ID of the MHU slot used for the BOM protocol */
#define BOM_MHU_SLOT_ID 0
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
/* Boot commands sent from AP -> SCP */
#define BOOT_CMD_INFO 0x00
#define BOOT_CMD_DATA 0x01
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
/* BOM command header */
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
2015-03-19 18:58:55 +00:00
typedef struct {
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
uint32_t id : 8;
uint32_t reserved : 24;
} bom_cmd_t;
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
2015-03-19 18:58:55 +00:00
typedef struct {
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
uint32_t image_size;
uint32_t checksum;
} cmd_info_payload_t;
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
2015-03-19 18:58:55 +00:00
/*
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
* Unlike the SCPI protocol, the boot protocol uses the same memory region
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
2015-03-19 18:58:55 +00:00
* for both AP -> SCP and SCP -> AP transfers; define the address of this...
*/
#define BOM_SHARED_MEM PLAT_CSS_SCP_COM_SHARED_MEM_BASE
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
#define BOM_CMD_HEADER ((bom_cmd_t *) BOM_SHARED_MEM)
#define BOM_CMD_PAYLOAD ((void *) (BOM_SHARED_MEM + sizeof(bom_cmd_t)))
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
typedef struct {
/* Offset from the base address of the Trusted RAM */
uint32_t offset;
uint32_t block_size;
} cmd_data_payload_t;
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
2015-03-19 18:58:55 +00:00
/*
* All CSS platforms load SCP_BL2/SCP_BL2U just below BL rw-data and above
* BL2/BL2U (this is where BL31 usually resides except when ARM_BL31_IN_DRAM is
* set. Ensure that SCP_BL2/SCP_BL2U do not overflow into BL1 rw-data nor
* BL2/BL2U.
*/
CASSERT(SCP_BL2_LIMIT <= BL1_RW_BASE, assert_scp_bl2_overwrite_bl1);
CASSERT(SCP_BL2U_LIMIT <= BL1_RW_BASE, assert_scp_bl2u_overwrite_bl1);
CASSERT(SCP_BL2_BASE >= BL2_LIMIT, assert_scp_bl2_overwrite_bl2);
CASSERT(SCP_BL2U_BASE >= BL2U_LIMIT, assert_scp_bl2u_overwrite_bl2u);
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
static void scp_boot_message_start(void)
{
mhu_secure_message_start(BOM_MHU_SLOT_ID);
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
2015-03-19 18:58:55 +00:00
}
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
static void scp_boot_message_send(size_t payload_size)
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
2015-03-19 18:58:55 +00:00
{
/* Ensure that any write to the BOM payload area is seen by SCP before
* we write to the MHU register. If these 2 writes were reordered by
* the CPU then SCP would read stale payload data */
dmbst();
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
2015-03-19 18:58:55 +00:00
/* Send command to SCP */
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
mhu_secure_message_send(BOM_MHU_SLOT_ID);
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
2015-03-19 18:58:55 +00:00
}
static uint32_t scp_boot_message_wait(size_t size)
{
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
uint32_t mhu_status;
mhu_status = mhu_secure_message_wait();
/* Expect an SCP Boot Protocol message, reject any other protocol */
if (mhu_status != (1 << BOM_MHU_SLOT_ID)) {
ERROR("MHU: Unexpected protocol (MHU status: 0x%x)\n",
mhu_status);
panic();
}
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
2015-03-19 18:58:55 +00:00
/* Ensure that any read to the BOM payload area is done after reading
* the MHU register. If these 2 reads were reordered then the CPU would
* read invalid payload data */
dmbld();
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
return *(uint32_t *) BOM_SHARED_MEM;
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
2015-03-19 18:58:55 +00:00
}
static void scp_boot_message_end(void)
{
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
mhu_secure_message_end(BOM_MHU_SLOT_ID);
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
2015-03-19 18:58:55 +00:00
}
int css_scp_boot_image_xfer(void *image, unsigned int image_size)
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
2015-03-19 18:58:55 +00:00
{
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
uint32_t response;
uint32_t checksum;
cmd_info_payload_t *cmd_info_payload;
cmd_data_payload_t *cmd_data_payload;
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
2015-03-19 18:58:55 +00:00
assert((uintptr_t) image == SCP_BL2_BASE);
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
if ((image_size == 0) || (image_size % 4 != 0)) {
ERROR("Invalid size for the SCP_BL2 image. Must be a multiple of "
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
"4 bytes and not zero (current size = 0x%x)\n",
image_size);
return -1;
}
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
/* Extract the checksum from the image */
checksum = *(uint32_t *) image;
image = (char *) image + sizeof(checksum);
image_size -= sizeof(checksum);
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
mhu_secure_init();
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
2015-03-19 18:58:55 +00:00
VERBOSE("Send info about the SCP_BL2 image to be transferred to SCP\n");
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
/*
* Send information about the SCP firmware image about to be transferred
* to SCP
*/
scp_boot_message_start();
BOM_CMD_HEADER->id = BOOT_CMD_INFO;
cmd_info_payload = BOM_CMD_PAYLOAD;
cmd_info_payload->image_size = image_size;
cmd_info_payload->checksum = checksum;
scp_boot_message_send(sizeof(*cmd_info_payload));
#if CSS_DETECT_PRE_1_7_0_SCP
{
const uint32_t deprecated_scp_nack_cmd = 0x404;
uint32_t mhu_status;
VERBOSE("Detecting SCP version incompatibility\n");
mhu_status = mhu_secure_message_wait();
if (mhu_status == deprecated_scp_nack_cmd) {
ERROR("Detected an incompatible version of the SCP firmware.\n");
ERROR("Only versions from v1.7.0 onwards are supported.\n");
ERROR("Please update the SCP firmware.\n");
return -1;
}
VERBOSE("SCP version looks OK\n");
}
#endif /* CSS_DETECT_PRE_1_7_0_SCP */
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
response = scp_boot_message_wait(sizeof(response));
scp_boot_message_end();
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
if (response != 0) {
ERROR("SCP BOOT_CMD_INFO returned error %u\n", response);
return -1;
}
VERBOSE("Transferring SCP_BL2 image to SCP\n");
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
2015-03-19 18:58:55 +00:00
/* Transfer SCP_BL2 image to SCP */
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
scp_boot_message_start();
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
BOM_CMD_HEADER->id = BOOT_CMD_DATA;
cmd_data_payload = BOM_CMD_PAYLOAD;
cmd_data_payload->offset = (uintptr_t) image - ARM_TRUSTED_SRAM_BASE;
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
cmd_data_payload->block_size = image_size;
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
scp_boot_message_send(sizeof(*cmd_data_payload));
response = scp_boot_message_wait(sizeof(response));
scp_boot_message_end();
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
2015-03-19 18:58:55 +00:00
Move to the new ARM SCP Messaging Interfaces 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
2015-03-18 14:52:53 +00:00
if (response != 0) {
ERROR("SCP BOOT_CMD_DATA returned error %u\n", response);
return -1;
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
2015-03-19 18:58:55 +00:00
}
return 0;
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
2015-03-19 18:58:55 +00:00
}
int css_scp_boot_ready(void)
{
VERBOSE("Waiting for SCP to signal it is ready to go on\n");
/* Wait for SCP to signal it's ready */
return scpi_wait_ready();
}