Merge changes from topic "ti-k3-checks-and-refactor" into integration

* changes:
fix(ti): fix typo in boot authentication message name
refactor(ti): remove empty validate_ns_entrypoint function

Merge changes from topic "ti-k3-checks-and-refactor" into integration

* changes:
fix(ti): fix typo in boot authentication message name
refactor(ti): remove empty validate_ns_entrypoint function
refactor(ti): use console_set_scope() rather than empty function hack
refactor(ti): factor out common board code into common files
feat(ti): add PSCI system_off support
feat(ti): do not handle EAs in EL3
feat(ti): set snoop-delayed exclusive handling on A72 cores
feat(ti): disable L2 dataless UniqueClean evictions
feat(ti): set L2 cache ECC and and parity on A72 cores
feat(ti): set L2 cache data ram latency on A72 cores to 4 cycles

show more ...

refactor(ti): factor out common board code into common files

Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ibf7328418c5285a64608b80e7c430a8dee64fb1d

Merge changes I8cd2c1c9,I697711ee,I4a0ec150,I4f8064b9,Ie22cb2a3, ... into integration

* changes:
ti: k3: Introduce lite device board support
ti: k3: common: sec_proxy: Introduce sec_proxy_lite d

Merge changes I8cd2c1c9,I697711ee,I4a0ec150,I4f8064b9,Ie22cb2a3, ... into integration

* changes:
ti: k3: Introduce lite device board support
ti: k3: common: sec_proxy: Introduce sec_proxy_lite definition
ti: k3: Move USE_COHERENT_MEM only for the generic board
ti: k3: drivers: ti_sci: Update ti_sci_msg_req_reboot to include domain
ti: k3: common: sec_proxy: Fill non-message data fields with 0x0
ti: k3: common: Make plat_get_syscnt_freq2 check CNT_FID0 GTC reg
ti: k3: common: Enable A72 erratum 1319367
ti: k3: common: Enable A53 erratum 1530924
maintainers: Update maintainers for TI port

show more ...

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 communi

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

show more ...

ti: k3: Move USE_COHERENT_MEM only for the generic board

commit 65f7b81728d0 ("ti: k3: common: Use coherent memory for shared data")
introduced WARMBOOT_ENABLE_DCACHE_EARLY and USE_COHERENT_MEM to h

ti: k3: Move USE_COHERENT_MEM only for the generic board

commit 65f7b81728d0 ("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

show more ...

Merge pull request #1403 from glneo/for-upstream-k3

TI K3 platform support

ti: k3: Introduce basic generic board support

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 co

ti: k3: Introduce basic generic board support

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>

show more ...