Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2015-2019, ARM Limited and Contributors. All rights reserved.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef PLATFORM_DEF_H
|
|
|
|
#define PLATFORM_DEF_H
|
|
|
|
|
|
|
|
#include <arch.h>
|
|
|
|
#include <common/tbbr/tbbr_img_def.h>
|
|
|
|
#include <lib/utils_def.h>
|
|
|
|
#include <plat/common/common_def.h>
|
|
|
|
|
|
|
|
#include "rpi_hw.h"
|
|
|
|
|
|
|
|
/* Special value used to verify platform parameters from BL2 to BL31 */
|
|
|
|
#define RPI3_BL31_PLAT_PARAM_VAL ULL(0x0F1E2D3C4B5A6978)
|
|
|
|
|
|
|
|
#define PLATFORM_STACK_SIZE ULL(0x1000)
|
|
|
|
|
|
|
|
#define PLATFORM_MAX_CPUS_PER_CLUSTER U(4)
|
|
|
|
#define PLATFORM_CLUSTER_COUNT U(1)
|
|
|
|
#define PLATFORM_CLUSTER0_CORE_COUNT PLATFORM_MAX_CPUS_PER_CLUSTER
|
|
|
|
#define PLATFORM_CORE_COUNT PLATFORM_CLUSTER0_CORE_COUNT
|
|
|
|
|
2020-03-12 14:20:04 +00:00
|
|
|
#define RPI_PRIMARY_CPU U(0)
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
|
|
|
|
#define PLAT_MAX_PWR_LVL MPIDR_AFFLVL1
|
|
|
|
#define PLAT_NUM_PWR_DOMAINS (PLATFORM_CLUSTER_COUNT + \
|
|
|
|
PLATFORM_CORE_COUNT)
|
|
|
|
|
|
|
|
#define PLAT_MAX_RET_STATE U(1)
|
|
|
|
#define PLAT_MAX_OFF_STATE U(2)
|
|
|
|
|
|
|
|
/* Local power state for power domains in Run state. */
|
|
|
|
#define PLAT_LOCAL_STATE_RUN U(0)
|
|
|
|
/* Local power state for retention. Valid only for CPU power domains */
|
|
|
|
#define PLAT_LOCAL_STATE_RET U(1)
|
|
|
|
/*
|
|
|
|
* Local power state for OFF/power-down. Valid for CPU and cluster power
|
|
|
|
* domains.
|
|
|
|
*/
|
|
|
|
#define PLAT_LOCAL_STATE_OFF U(2)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Macros used to parse state information from State-ID if it is using the
|
|
|
|
* recommended encoding for State-ID.
|
|
|
|
*/
|
|
|
|
#define PLAT_LOCAL_PSTATE_WIDTH U(4)
|
|
|
|
#define PLAT_LOCAL_PSTATE_MASK ((U(1) << PLAT_LOCAL_PSTATE_WIDTH) - 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some data must be aligned on the biggest cache line size in the platform.
|
|
|
|
* This is known only to the platform as it might have a combination of
|
|
|
|
* integrated and external caches.
|
|
|
|
*/
|
|
|
|
#define CACHE_WRITEBACK_SHIFT U(6)
|
|
|
|
#define CACHE_WRITEBACK_GRANULE (U(1) << CACHE_WRITEBACK_SHIFT)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* I/O registers.
|
|
|
|
*/
|
|
|
|
#define DEVICE0_BASE RPI_IO_BASE
|
|
|
|
#define DEVICE0_SIZE RPI_IO_SIZE
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mailbox to control the secondary cores. All secondary cores are held in a
|
|
|
|
* wait loop in cold boot. To release them perform the following steps (plus
|
|
|
|
* any additional barriers that may be needed):
|
|
|
|
*
|
|
|
|
* uint64_t *entrypoint = (uint64_t *)PLAT_RPI3_TM_ENTRYPOINT;
|
|
|
|
* *entrypoint = ADDRESS_TO_JUMP_TO;
|
|
|
|
*
|
|
|
|
* uint64_t *mbox_entry = (uint64_t *)PLAT_RPI3_TM_HOLD_BASE;
|
|
|
|
* mbox_entry[cpu_id] = PLAT_RPI3_TM_HOLD_STATE_GO;
|
|
|
|
*
|
|
|
|
* sev();
|
|
|
|
*/
|
|
|
|
/* The secure entry point to be used on warm reset by all CPUs. */
|
2019-07-15 09:04:27 +01:00
|
|
|
#define PLAT_RPI3_TM_ENTRYPOINT 0x100
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
#define PLAT_RPI3_TM_ENTRYPOINT_SIZE ULL(8)
|
|
|
|
|
|
|
|
/* Hold entries for each CPU. */
|
|
|
|
#define PLAT_RPI3_TM_HOLD_BASE (PLAT_RPI3_TM_ENTRYPOINT + \
|
|
|
|
PLAT_RPI3_TM_ENTRYPOINT_SIZE)
|
|
|
|
#define PLAT_RPI3_TM_HOLD_ENTRY_SIZE ULL(8)
|
|
|
|
#define PLAT_RPI3_TM_HOLD_SIZE (PLAT_RPI3_TM_HOLD_ENTRY_SIZE * \
|
|
|
|
PLATFORM_CORE_COUNT)
|
|
|
|
|
|
|
|
#define PLAT_RPI3_TRUSTED_MAILBOX_SIZE (PLAT_RPI3_TM_ENTRYPOINT_SIZE + \
|
|
|
|
PLAT_RPI3_TM_HOLD_SIZE)
|
|
|
|
|
|
|
|
#define PLAT_RPI3_TM_HOLD_STATE_WAIT ULL(0)
|
|
|
|
#define PLAT_RPI3_TM_HOLD_STATE_GO ULL(1)
|
2020-03-12 05:11:06 +00:00
|
|
|
#define PLAT_RPI3_TM_HOLD_STATE_BSP_OFF ULL(2)
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* BL31 specific defines.
|
|
|
|
*
|
|
|
|
* Put BL31 at the top of the Trusted SRAM. BL31_BASE is calculated using the
|
|
|
|
* current BL31 debug size plus a little space for growth.
|
|
|
|
*/
|
2019-07-15 09:04:27 +01:00
|
|
|
#define PLAT_MAX_BL31_SIZE ULL(0x80000)
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
|
|
|
|
#define BL31_BASE ULL(0x1000)
|
2019-07-15 09:04:27 +01:00
|
|
|
#define BL31_LIMIT ULL(0x80000)
|
|
|
|
#define BL31_PROGBITS_LIMIT ULL(0x80000)
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
|
|
|
|
#define SEC_SRAM_ID 0
|
|
|
|
#define SEC_DRAM_ID 1
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Other memory-related defines.
|
|
|
|
*/
|
|
|
|
#define PLAT_PHY_ADDR_SPACE_SIZE (ULL(1) << 32)
|
|
|
|
#define PLAT_VIRT_ADDR_SPACE_SIZE (ULL(1) << 32)
|
|
|
|
|
|
|
|
#define MAX_MMAP_REGIONS 8
|
|
|
|
#define MAX_XLAT_TABLES 4
|
|
|
|
|
|
|
|
#define MAX_IO_DEVICES U(3)
|
|
|
|
#define MAX_IO_HANDLES U(4)
|
|
|
|
|
|
|
|
#define MAX_IO_BLOCK_DEVICES U(1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Serial-related constants.
|
|
|
|
*/
|
2020-03-10 12:33:16 +00:00
|
|
|
#define PLAT_RPI_MINI_UART_BASE RPI4_MINI_UART_BASE
|
2020-03-10 12:34:56 +00:00
|
|
|
#define PLAT_RPI_PL011_UART_BASE RPI4_PL011_UART_BASE
|
|
|
|
#define PLAT_RPI_PL011_UART_CLOCK RPI4_PL011_UART_CLOCK
|
2020-03-10 12:33:16 +00:00
|
|
|
#define PLAT_RPI_UART_BAUDRATE ULL(115200)
|
Add basic support for Raspberry Pi 4
The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.
This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.
Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2019-07-09 11:25:57 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* System counter
|
|
|
|
*/
|
|
|
|
#define SYS_COUNTER_FREQ_IN_TICKS ULL(54000000)
|
|
|
|
|
|
|
|
#endif /* PLATFORM_DEF_H */
|