2016-10-14 02:13:34 +01:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#ifndef PLATFORM_DEF_H
|
|
|
|
|
#define PLATFORM_DEF_H
|
2016-10-14 02:13:34 +01:00
|
|
|
|
|
|
|
|
#include <arch.h>
|
2018-12-14 00:18:21 +00:00
|
|
|
#include <plat/common/common_def.h>
|
|
|
|
|
|
2016-10-14 02:13:34 +01:00
|
|
|
#include <board_def.h>
|
|
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
|
* Generic platform constants
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
|
|
/* Size of cacheable stack */
|
|
|
|
|
#if IMAGE_BL31
|
|
|
|
|
#define PLATFORM_STACK_SIZE 0x800
|
|
|
|
|
#else
|
|
|
|
|
#define PLATFORM_STACK_SIZE 0x1000
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-10-18 20:32:06 +01:00
|
|
|
#define PLATFORM_SYSTEM_COUNT 1
|
|
|
|
|
#define PLATFORM_CORE_COUNT (K3_CLUSTER0_CORE_COUNT + \
|
|
|
|
|
K3_CLUSTER1_CORE_COUNT + \
|
|
|
|
|
K3_CLUSTER2_CORE_COUNT + \
|
|
|
|
|
K3_CLUSTER3_CORE_COUNT)
|
|
|
|
|
|
2019-03-27 14:37:10 +00:00
|
|
|
#define PLATFORM_CLUSTER_COUNT ((K3_CLUSTER0_CORE_COUNT != 0) + \
|
|
|
|
|
(K3_CLUSTER1_CORE_COUNT != 0) + \
|
|
|
|
|
(K3_CLUSTER2_CORE_COUNT != 0) + \
|
|
|
|
|
(K3_CLUSTER3_CORE_COUNT != 0))
|
2016-10-18 20:32:06 +01:00
|
|
|
|
2018-06-25 18:10:53 +01:00
|
|
|
#define PLAT_NUM_PWR_DOMAINS (PLATFORM_SYSTEM_COUNT + \
|
|
|
|
|
PLATFORM_CLUSTER_COUNT + \
|
2016-10-14 02:13:34 +01:00
|
|
|
PLATFORM_CORE_COUNT)
|
2018-06-25 18:10:53 +01:00
|
|
|
#define PLAT_MAX_PWR_LVL MPIDR_AFFLVL2
|
2016-10-14 02:13:34 +01:00
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
|
* Memory layout constants
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ARM-TF lives in SRAM, partition it here
|
2019-01-22 20:00:16 +00:00
|
|
|
*
|
2016-10-14 02:13:34 +01:00
|
|
|
* BL3-1 specific defines.
|
|
|
|
|
*
|
2019-01-22 20:00:16 +00:00
|
|
|
* Put BL3-1 at the base of the Trusted SRAM.
|
2016-10-14 02:13:34 +01:00
|
|
|
*/
|
|
|
|
|
#define BL31_BASE SEC_SRAM_BASE
|
2019-01-22 20:00:16 +00:00
|
|
|
#define BL31_SIZE SEC_SRAM_SIZE
|
2016-10-14 02:13:34 +01:00
|
|
|
#define BL31_LIMIT (BL31_BASE + BL31_SIZE)
|
|
|
|
|
|
2016-10-14 02:13:45 +01:00
|
|
|
/*
|
|
|
|
|
* Defines the maximum number of translation tables that are allocated by the
|
|
|
|
|
* translation table library code. To minimize the amount of runtime memory
|
|
|
|
|
* used, choose the smallest value needed to map the required virtual addresses
|
|
|
|
|
* for each BL stage.
|
|
|
|
|
*/
|
plat: ti: k3: platform_def.h: Define the correct number of max table entries
Since we are using static xlat tables, we need to account for exact
count of table entries we are actually using.
peripherals usart, gic, gtc, sec_proxy_rt, scfg and data account for 6 entries
and are constant, however, we also need to account for:
bl31 full range, codebase, ro_data as additional 3 region
With USE_COHERENT_MEM we do add in 1 extra region as well.
This implies that we will have upto 9 or 10 regions based on
USE_COHERENT_MEM usage. Vs we currently define 8 regions.
This gets exposed with DEBUG=1 and assert checks trigger, which for some
reason completely escaped testing previously.
ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:97
BACKTRACE: START: assert
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I962cdfc779b4eb3b914fe1c46023d50bc289e6bc
2021-03-26 05:34:17 +00:00
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
|
#define MAX_XLAT_TABLES 10
|
|
|
|
|
#else
|
|
|
|
|
#define MAX_XLAT_TABLES 9
|
|
|
|
|
#endif
|
2016-10-14 02:13:45 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Defines the maximum number of regions that are allocated by the translation
|
|
|
|
|
* table library code. A region consists of physical base address, virtual base
|
|
|
|
|
* address, size and attributes (Device/Memory, RO/RW, Secure/Non-Secure), as
|
|
|
|
|
* defined in the `mmap_region_t` structure. The platform defines the regions
|
|
|
|
|
* that should be mapped. Then, the translation table library will create the
|
|
|
|
|
* corresponding tables and descriptors at runtime. To minimize the amount of
|
|
|
|
|
* runtime memory used, choose the smallest value needed to register the
|
|
|
|
|
* required regions for each BL stage.
|
|
|
|
|
*/
|
2018-05-04 20:06:08 +01:00
|
|
|
#define MAX_MMAP_REGIONS 11
|
2016-10-14 02:13:45 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Defines the total size of the address space in bytes. For example, for a 32
|
|
|
|
|
* bit address space, this value should be `(1ull << 32)`.
|
|
|
|
|
*/
|
|
|
|
|
#define PLAT_PHY_ADDR_SPACE_SIZE (1ull << 32)
|
|
|
|
|
#define PLAT_VIRT_ADDR_SPACE_SIZE (1ull << 32)
|
|
|
|
|
|
2016-10-14 02:13:34 +01:00
|
|
|
/*
|
|
|
|
|
* 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 6
|
|
|
|
|
#define CACHE_WRITEBACK_GRANULE (1 << CACHE_WRITEBACK_SHIFT)
|
|
|
|
|
|
2016-10-14 02:13:44 +01:00
|
|
|
/* Platform default console definitions */
|
2019-01-22 19:36:48 +00:00
|
|
|
#ifndef K3_USART_BASE
|
2020-05-20 06:35:48 +01:00
|
|
|
#define K3_USART_BASE (0x02800000 + 0x10000 * K3_USART)
|
2016-10-14 02:13:44 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* USART has a default size for address space */
|
|
|
|
|
#define K3_USART_SIZE 0x1000
|
|
|
|
|
|
|
|
|
|
#ifndef K3_USART_CLK_SPEED
|
|
|
|
|
#define K3_USART_CLK_SPEED 48000000
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* Crash console defaults */
|
2019-01-22 19:36:48 +00:00
|
|
|
#define CRASH_CONSOLE_BASE K3_USART_BASE
|
2016-10-14 02:13:44 +01:00
|
|
|
#define CRASH_CONSOLE_CLK K3_USART_CLK_SPEED
|
|
|
|
|
#define CRASH_CONSOLE_BAUD_RATE K3_USART_BAUD
|
|
|
|
|
|
2016-10-14 02:13:48 +01:00
|
|
|
/* Timer frequency */
|
|
|
|
|
#ifndef SYS_COUNTER_FREQ_IN_TICKS
|
|
|
|
|
#define SYS_COUNTER_FREQ_IN_TICKS 200000000
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-10-14 02:13:49 +01:00
|
|
|
/* Interrupt numbers */
|
|
|
|
|
#define ARM_IRQ_SEC_PHY_TIMER 29
|
|
|
|
|
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_0 8
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_1 9
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_2 10
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_3 11
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_4 12
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_5 13
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_6 14
|
|
|
|
|
#define ARM_IRQ_SEC_SGI_7 15
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Define properties 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_IRQ_PROPS(grp) \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_PHY_TIMER, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_LEVEL), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_1, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_2, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_3, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_4, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_5, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_7, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE)
|
|
|
|
|
|
|
|
|
|
#define PLAT_ARM_G0_IRQ_PROPS(grp) \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_0, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE), \
|
|
|
|
|
INTR_PROP_DESC(ARM_IRQ_SEC_SGI_6, GIC_HIGHEST_SEC_PRIORITY, grp, \
|
|
|
|
|
GIC_INTR_CFG_EDGE)
|
|
|
|
|
|
ti: k3: common: Make plat_get_syscnt_freq2 check CNT_FID0 GTC reg
ARM's generic timer[1] picks up it's graycode from GTC. However, the
frequency of the GTC is supposed to be programmed in CNTFID0[2]
register.
In K3, architecture, GTC provides a central time to many parts of the
SoC including graycode to the generic timer in the ARMv8 subsystem.
However, due to the central nature and the need to enable the counter
early in the boot process, the R5 based bootloader enables GTC and
programs it's frequency based on central needs of the system. This
may not be a constant 200MHz based on the system. The bootloader is
supposed to program the FID0 register with the correct frequency it
has sourced for GTC from the central system controller, and TF-A is
supposed to use that as the frequency for it's local timer.
A mismatch in programmed frequency and what we program for generic
timer will, as we can imagine, all kind of weird mayhem.
So, check the CNTFID0 register, if it is 0, warn and use the default
frequency to continue the boot process.
While at it, we can also check CNTCR register to provide some basic
diagnostics to make sure that we don't have OS folks scratch their
heads. Even though this is used during cpu online operations, the cost
of this additional check is minimal enough for us not to use #ifdeffery
with DEBUG flags.
[1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary
[2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0
[3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: Ib03e06788580f3540dcb1a11677d0d6d398b2c9f
2020-12-11 02:51:51 +00:00
|
|
|
|
|
|
|
|
#define K3_GTC_BASE 0x00A90000
|
|
|
|
|
/* We just need 20 byte offset, but simpler to just remap the 64K page in */
|
|
|
|
|
#define K3_GTC_SIZE 0x10000
|
|
|
|
|
#define K3_GTC_CNTCR_OFFSET 0x00
|
|
|
|
|
#define K3_GTC_CNTCR_EN_MASK 0x01
|
|
|
|
|
#define K3_GTC_CNTCR_HDBG_MASK 0x02
|
|
|
|
|
#define K3_GTC_CNTFID0_OFFSET 0x20
|
|
|
|
|
|
2019-01-22 18:39:31 +00:00
|
|
|
#define K3_GIC_BASE 0x01800000
|
|
|
|
|
#define K3_GIC_SIZE 0x200000
|
2016-10-14 02:13:49 +01:00
|
|
|
|
ti: k3: common: sec_proxy: Introduce sec_proxy_lite definition
There are two communication scheme that have been enabled to communicate
with Secure Proxy in TI.
a) A full fledged prioritized communication scheme, which involves upto
5 threads from the perspective of the host software
b) A much simpler "lite" version which is just a two thread scheme
involving just a transmit and receive thread scheme.
The (a) system is specifically useful when the SoC is massive
involving multiple processor systems and where the potential for
priority inversion is clearly a system usecase killer. However, this
comes with the baggage of significant die area for larger number of
instances of secure proxy, ring accelerator and backing memories
for queued messages. Example SoCs using this scheme would be:
AM654[1], J721E[2], J7200[3] etc.
The (b) scheme(aka the lite scheme) is introduced on smaller SoCs
where memory and area concerns are paramount. The tradeoff of
priority loss is acceptable given the reduced number of processors
communicating with the central system controller. This brings about
a very significant area and memory usage savings while the loss of
communication priority has no demonstrable impact. Example SoC using
this scheme would be: AM642[4]
While we can detect using JTAG ID and conceptually handle things
dynamically, adding such a scheme involves a lot of unused data (cost
of ATF memory footprint), pointer lookups (performance cost) and still
due to follow on patches, does'nt negate the need for a different
build configuration. However, (a) and (b) family of SoCs share the
same scheme and addresses etc, this helps minimize our churn quite a
bit
Instead of introducing a complex data structure lookup scheme, lets
keep things simple by first introducing the pieces necessary for an
alternate communication scheme, then introduce a second platform
representing the "lite" family of K3 processors.
NOTE: This is only possible since ATF uses just two (secure) threads
for actual communication with the central system controller. This is
sufficient for the function that ATF uses.
The (a) scheme and the (b) scheme also varies w.r.t the base addresses
used, even though the memory window assigned for them have remained
consistent. We introduce the delta as part of this change as well.
This is expected to remain consistent as a standard in TI SoCs.
References:
[1] See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: https://www.ti.com/lit/pdf/spruid7
[2] See J721E Technical Reference Manual (SPRUIL1, May 2019)
for further details: https://www.ti.com/lit/pdf/spruil1
[3] See J7200 Technical Reference Manual (SPRUIU1, June 2020)
for further details: https://www.ti.com/lit/pdf/spruiu1
[4] See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I697711ee0e6601965015ddf950fdfdec8e759bfc
2020-12-11 00:39:41 +00:00
|
|
|
#if !K3_SEC_PROXY_LITE
|
2018-05-04 20:06:08 +01:00
|
|
|
#define SEC_PROXY_DATA_BASE 0x32C00000
|
|
|
|
|
#define SEC_PROXY_DATA_SIZE 0x80000
|
|
|
|
|
#define SEC_PROXY_SCFG_BASE 0x32800000
|
|
|
|
|
#define SEC_PROXY_SCFG_SIZE 0x80000
|
|
|
|
|
#define SEC_PROXY_RT_BASE 0x32400000
|
|
|
|
|
#define SEC_PROXY_RT_SIZE 0x80000
|
ti: k3: common: sec_proxy: Introduce sec_proxy_lite definition
There are two communication scheme that have been enabled to communicate
with Secure Proxy in TI.
a) A full fledged prioritized communication scheme, which involves upto
5 threads from the perspective of the host software
b) A much simpler "lite" version which is just a two thread scheme
involving just a transmit and receive thread scheme.
The (a) system is specifically useful when the SoC is massive
involving multiple processor systems and where the potential for
priority inversion is clearly a system usecase killer. However, this
comes with the baggage of significant die area for larger number of
instances of secure proxy, ring accelerator and backing memories
for queued messages. Example SoCs using this scheme would be:
AM654[1], J721E[2], J7200[3] etc.
The (b) scheme(aka the lite scheme) is introduced on smaller SoCs
where memory and area concerns are paramount. The tradeoff of
priority loss is acceptable given the reduced number of processors
communicating with the central system controller. This brings about
a very significant area and memory usage savings while the loss of
communication priority has no demonstrable impact. Example SoC using
this scheme would be: AM642[4]
While we can detect using JTAG ID and conceptually handle things
dynamically, adding such a scheme involves a lot of unused data (cost
of ATF memory footprint), pointer lookups (performance cost) and still
due to follow on patches, does'nt negate the need for a different
build configuration. However, (a) and (b) family of SoCs share the
same scheme and addresses etc, this helps minimize our churn quite a
bit
Instead of introducing a complex data structure lookup scheme, lets
keep things simple by first introducing the pieces necessary for an
alternate communication scheme, then introduce a second platform
representing the "lite" family of K3 processors.
NOTE: This is only possible since ATF uses just two (secure) threads
for actual communication with the central system controller. This is
sufficient for the function that ATF uses.
The (a) scheme and the (b) scheme also varies w.r.t the base addresses
used, even though the memory window assigned for them have remained
consistent. We introduce the delta as part of this change as well.
This is expected to remain consistent as a standard in TI SoCs.
References:
[1] See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: https://www.ti.com/lit/pdf/spruid7
[2] See J721E Technical Reference Manual (SPRUIL1, May 2019)
for further details: https://www.ti.com/lit/pdf/spruil1
[3] See J7200 Technical Reference Manual (SPRUIU1, June 2020)
for further details: https://www.ti.com/lit/pdf/spruiu1
[4] See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I697711ee0e6601965015ddf950fdfdec8e759bfc
2020-12-11 00:39:41 +00:00
|
|
|
#else
|
|
|
|
|
#define SEC_PROXY_DATA_BASE 0x4D000000
|
|
|
|
|
#define SEC_PROXY_DATA_SIZE 0x80000
|
|
|
|
|
#define SEC_PROXY_SCFG_BASE 0x4A400000
|
|
|
|
|
#define SEC_PROXY_SCFG_SIZE 0x80000
|
|
|
|
|
#define SEC_PROXY_RT_BASE 0x4A600000
|
|
|
|
|
#define SEC_PROXY_RT_SIZE 0x80000
|
|
|
|
|
#endif /* K3_SEC_PROXY_LITE */
|
2018-05-04 20:06:08 +01:00
|
|
|
|
|
|
|
|
#define SEC_PROXY_TIMEOUT_US 1000000
|
|
|
|
|
#define SEC_PROXY_MAX_MESSAGE_SIZE 56
|
|
|
|
|
|
2018-05-04 20:06:09 +01:00
|
|
|
#define TI_SCI_HOST_ID 10
|
|
|
|
|
#define TI_SCI_MAX_MESSAGE_SIZE 52
|
|
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#endif /* PLATFORM_DEF_H */
|
