arm-trusted-firmware/plat/arm/board/fvp/include/platform_def.h

174 lines
5.6 KiB
C
Raw Normal View History

/*
* Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* Neither the name of ARM nor the names of its contributors may be used
* to endorse or promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef __PLATFORM_DEF_H__
#define __PLATFORM_DEF_H__
#include <arm_def.h>
#include <board_arm_def.h>
#include <common_def.h>
#include <tzc400.h>
#include <v2m_def.h>
#include "../fvp_def.h"
/* Required platform porting definitions */
#define PLAT_NUM_PWR_DOMAINS (ARM_CLUSTER_COUNT + \
PLATFORM_CORE_COUNT)
#define PLAT_MAX_PWR_LVL ARM_PWR_LVL1
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
/*
* Other platform porting definitions are provided by included headers
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
*/
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
/*
* Required ARM standard platform porting definitions
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
*/
#define PLAT_ARM_CLUSTER0_CORE_COUNT 4
#define PLAT_ARM_CLUSTER1_CORE_COUNT 4
#define PLAT_ARM_TRUSTED_ROM_BASE 0x00000000
#define PLAT_ARM_TRUSTED_ROM_SIZE 0x04000000 /* 64 MB */
#define PLAT_ARM_TRUSTED_DRAM_BASE 0x06000000
#define PLAT_ARM_TRUSTED_DRAM_SIZE 0x02000000 /* 32 MB */
/* No SCP in FVP */
#define PLAT_ARM_SCP_TZC_DRAM1_SIZE MAKE_ULL(0x0)
#define PLAT_ARM_DRAM2_SIZE MAKE_ULL(0x780000000)
#define PLAT_ARM_SHARED_RAM_CACHED 1
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
/*
* Load address of BL33 for this platform port
fvp: Reuse BL1 and BL2 memory through image overlaying This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
2014-06-16 16:12:27 +01:00
*/
#define PLAT_ARM_NS_IMAGE_OFFSET (ARM_DRAM1_BASE + 0x8000000)
/*
* PL011 related constants
*/
#define PLAT_ARM_BOOT_UART_BASE V2M_IOFPGA_UART0_BASE
#define PLAT_ARM_BOOT_UART_CLK_IN_HZ V2M_IOFPGA_UART0_CLK_IN_HZ
#define PLAT_ARM_BL31_RUN_UART_BASE V2M_IOFPGA_UART1_BASE
#define PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ V2M_IOFPGA_UART1_CLK_IN_HZ
#define PLAT_ARM_CRASH_UART_BASE PLAT_ARM_BL31_RUN_UART_BASE
#define PLAT_ARM_CRASH_UART_CLK_IN_HZ PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ
#define PLAT_ARM_TSP_UART_BASE V2M_IOFPGA_UART2_BASE
#define PLAT_ARM_TSP_UART_CLK_IN_HZ V2M_IOFPGA_UART2_CLK_IN_HZ
/* CCI related constants */
#define PLAT_ARM_CCI_BASE 0x2c090000
#define PLAT_ARM_CCI_CLUSTER0_SL_IFACE_IX 3
#define PLAT_ARM_CCI_CLUSTER1_SL_IFACE_IX 4
/* System timer related constants */
#define PLAT_ARM_NSTIMER_FRAME_ID 1
/* Mailbox base address */
#define PLAT_ARM_TRUSTED_MAILBOX_BASE ARM_TRUSTED_SRAM_BASE
/* TrustZone controller related constants
*
* Currently only filters 0 and 2 are connected on Base FVP.
* Filter 0 : CPU clusters (no access to DRAM by default)
* Filter 1 : not connected
* Filter 2 : LCDs (access to VRAM allowed by default)
* Filter 3 : not connected
* Programming unconnected filters will have no effect at the
* moment. These filter could, however, be connected in future.
* So care should be taken not to configure the unused filters.
*
* Allow only non-secure access to all DRAM to supported devices.
* Give access to the CPUs and Virtio. Some devices
* would normally use the default ID so allow that too.
*/
#define PLAT_ARM_TZC_BASE 0x2a4a0000
#define PLAT_ARM_TZC_FILTERS REG_ATTR_FILTER_BIT(0)
#define PLAT_ARM_TZC_NS_DEV_ACCESS ( \
TZC_REGION_ACCESS_RDWR(FVP_NSAID_DEFAULT) | \
TZC_REGION_ACCESS_RDWR(FVP_NSAID_PCI) | \
TZC_REGION_ACCESS_RDWR(FVP_NSAID_AP) | \
TZC_REGION_ACCESS_RDWR(FVP_NSAID_VIRTIO) | \
TZC_REGION_ACCESS_RDWR(FVP_NSAID_VIRTIO_OLD))
Rework use of ARM GIC drivers on ARM platforms Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
2015-11-03 14:18:34 +00:00
/*
* GIC related constants to cater for both GICv2 and GICv3 instances of an
* FVP. They could be overriden at runtime in case the FVP implements the legacy
* VE memory map.
*/
#define PLAT_ARM_GICD_BASE BASE_GICD_BASE
#define PLAT_ARM_GICR_BASE BASE_GICR_BASE
#define PLAT_ARM_GICC_BASE BASE_GICC_BASE
/*
* Define a list of Group 1 Secure and Group 0 interrupts as per GICv3
* terminology. On a GICv2 system or mode, the lists will be merged and treated
* as Group 0 interrupts.
*/
#define PLAT_ARM_G1S_IRQS ARM_G1S_IRQS, \
FVP_IRQ_TZ_WDOG, \
FVP_IRQ_SEC_SYS_TIMER
#define PLAT_ARM_G0_IRQS ARM_G0_IRQS
/*
* PLAT_ARM_MAX_BL1_RW_SIZE is calculated using the current BL1 RW debug size
* plus a little space for growth.
*/
#if TRUSTED_BOARD_BOOT
# define PLAT_ARM_MAX_BL1_RW_SIZE 0x9000
#else
# define PLAT_ARM_MAX_BL1_RW_SIZE 0x6000
#endif
/*
* PLAT_ARM_MAX_BL2_SIZE is calculated using the current BL2 debug size plus a
* little space for growth.
*/
#if TRUSTED_BOARD_BOOT
# define PLAT_ARM_MAX_BL2_SIZE 0x1D000
#else
# define PLAT_ARM_MAX_BL2_SIZE 0xC000
#endif
/*
* PLAT_ARM_MAX_BL31_SIZE is calculated using the current BL31 debug size plus a
* little space for growth.
*/
#define PLAT_ARM_MAX_BL31_SIZE 0x1D000
#endif /* __PLATFORM_DEF_H__ */