Increase the lite platform SEC_SRAM_SIZE to 128k to allow space
for GIC context.
Change-Id: I6414309757ce9a9b7b3a9233a401312bfc459a3b
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ENABLE_PIE (position independent executable) is default on K3
platform to handle variant RAM configurations in the system. This,
unfortunately does cause confusion while reading the code, so, lets
make things explicit by selecting 0x0 as the "SEC_SRAM_BASE" out of
which we compute the BL31_BASE depending on usage.
Lets also document a warning while at it to help folks copying code
over to a custom K3 platform and optimizing size by disabling PIE to
modify the defaults.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I8e67a9210e907e266ff6a78ba4d02e3259bb2b21
Lets cast our macros to the right types and reduce a few MISRA
warnings.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I0dc06072713fe7c9440eca0635094c5f3ceb7f1c
We actually have additional table entries than what we accounted for in
our size. MAX_XLAT_TABLES is 8, but really we could be using upto 10
depending on the platform. So, we need an extra 8K space in.
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: I5c5d04440ef1fccfaf2317066f3abbc0ec645903
Add device support for the 'lite' K3 devices. These will use modified
device addresses and allow for fewer cores to save memory.
Note: This family of devices are characterized by a single cluster
of ARMv8 processor upto a max of 4 processors and lack of a level 3
cache.
The first generation of this family is introduced with AM642.
See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I8cd2c1c9a9434646d0c72fca3162dd5bc9bd692a
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
commit 65f7b81728 ("ti: k3: common: Use coherent memory for shared data")
introduced WARMBOOT_ENABLE_DCACHE_EARLY and USE_COHERENT_MEM to handle
multiple clusters across L3 cache systems. This is represented by
"generic" board in k3 platform.
On "lite" platforms, however, system level coherency is lacking since
we don't have a global monitor or an L3 cache controller. Though, at
a cluster level, ARM CPU level coherency is very much possible since
the max number of clusters permitted in lite platform configuration is
"1".
However, we need to be able to disable USE_COHERENT_MEM for the lite
configuration due to the lack of system level coherency.
See docs/getting_started/build-options.rst for further information.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I4a0ec150b3f9ea12369254aef834a6cbe82d6be6
When all cores in a cluster are powered down the parent cluster can
be also powered down. When the last core has requested powering down
follow by sending the cluster power down sequence to the system
power controller firmware.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: I0ffeb339852c66ef62743aecd3e17ca20bad6216
The MSMC port defines were added to help in the case when some ports
are not connected and have no cores attached. We can get the same
functionality by defined the number of cores on that port to zero.
This simplifies several code paths, do this here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: I3247fe37af7b86c3227e647b4f617fab70c8ee8a
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
While it would be useful to have a device tree based build, the
required components are not in place yet, so support just a simple
statically defined configuration to begin with.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Dave Gerlach
Nishanth Menon
Andrew F. Davis
Deepika Bhavnani
Antonio Nino Diaz