Merge changes from topic "ti-am62l-mailbox-psci-base-support" into integration

* changes:
feat(ti): introduce basic support for the AM62L
feat(ti): introduce PSCI Driver for AM62L
feat(ti): ad

Merge changes from topic "ti-am62l-mailbox-psci-base-support" into integration

* changes:
feat(ti): introduce basic support for the AM62L
feat(ti): introduce PSCI Driver for AM62L
feat(ti): add support for TI mailbox driver
refactor(ti): move out k3/common to ti/common
refactor(ti): introduce ti_bl31_setup
refactor(ti): add the sec hdr to the ti sci msg
refactor(ti): rename the k3_sec_proxy_chan_id
refactor(ti): rename the sec_proxy functions
refactor(ti): add top level ti_sci transport layer
refactor(ti): move TI SCI and sec proxy to drivers

show more ...

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we

refactor(ti): move out k3/common to ti/common

This will allow us to support more platforms that share commonalities
like the k3_gicv3, console, helpers, etc.
With this new common folder location, we can move the previously
created ti_bl31_setup file into the new location so it can be shared
across multiple TI SoCs when need comes.
With this, also update all copyright dates.

Change-Id: Ie4365e32cd3b4b5870fe2cd03843400506e46265
Signed-off-by: Dhruva Gole <d-gole@ti.com>

show more ...

Merge "fix(ti): align static device region addresses to reduce MMU table count" into integration

fix(ti): align static device region addresses to reduce MMU table count

Align our device memory regions to the next highest MMU table level (LV2).
This allows the xlat_tables library code to use a s

fix(ti): align static device region addresses to reduce MMU table count

Align our device memory regions to the next highest MMU table level (LV2).
This allows the xlat_tables library code to use a single entry in the
higher order table, vs having to create a new table for LV3 entries.

This reduces our tables to just 4: 2 LV2 and 1 LV3 plus 1 spare in case
alignment changes ever cause one to be split. This saves 24KB of our
128KB total TF-A SRAM (~18%!).

While here, as USE_COHERENT_MEM does not change MAX_XLAT_TABLES but
does change our total MAX_MMAP_REGIONS, move that check accordingly.

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

show more ...

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 I8e67a921,I0dc06072,I5e149063,I962cdfc7,I5c5d0444 into integration

* changes:
plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0
plat: ti: k3: board: Lets cast our ma

Merge changes I8e67a921,I0dc06072,I5e149063,I962cdfc7,I5c5d0444 into integration

* changes:
plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0
plat: ti: k3: board: Lets cast our macros
plat: ti: k3: common: bl31_setup: Use BL31_SIZE instead of computing
plat: ti: k3: platform_def.h: Define the correct number of max table entries
plat: ti: k3: board: lite: Increase SRAM size to account for additional table

show more ...

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.
periphe

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

show more ...

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: 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]

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

show more ...

Merge "ti: k3: common: Make UART number configurable" into integration

ti: k3: common: Make UART number configurable

This allows to build for k3-based boards that use a different UART as
console, such as the IOT2050 which requires K3_USART=1.

Signed-off-by: Jan Kiszka

ti: k3: common: Make UART number configurable

This allows to build for k3-based boards that use a different UART as
console, such as the IOT2050 which requires K3_USART=1.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Change-Id: I7171f86c3cabae2c575b8fbeecef839b48bd109b

show more ...

Merge "ti: k3: common: Remove MSMC port definitions" into integration

ti: k3: common: Remove MSMC port definitions

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 d

ti: k3: common: Remove MSMC port definitions

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

show more ...

Merge changes from topic "k3-cleanups" into integration

* changes:
ti: k3: common: Align elements of map region table
ti: k3: common: Enable SEPARATE_CODE_AND_RODATA by default
ti: k3: common:

Merge changes from topic "k3-cleanups" into integration

* changes:
ti: k3: common: Align elements of map region table
ti: k3: common: Enable SEPARATE_CODE_AND_RODATA by default
ti: k3: common: Remove shared RAM space
ti: k3: common: Drop _ADDRESS from K3_USART_BASE to match other defines

show more ...

ti: k3: common: Enable SEPARATE_CODE_AND_RODATA by default

This should be more secure and looks a bit cleaner.

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

ti: k3: common: Enable SEPARATE_CODE_AND_RODATA by default

This should be more secure and looks a bit cleaner.

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

show more ...

ti: k3: common: Remove shared RAM space

We don't use this for anything right now, remove it.

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

ti: k3: common: Drop _ADDRESS from K3_USART_BASE to match other defines

This makes definitions more consistent, plus helps alignment.

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

ti: k3: common: Drop _ADDRESS from K3_USART_BASE to match other defines

This makes definitions more consistent, plus helps alignment.

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

show more ...

Merge pull request #1777 from glneo/runtime-gicr

ti: k3: common: Add support for runtime detection of GICR base address

ti: k3: common: Add support for runtime detection of GICR base address

Valid addresses for GICR base are always a set calculable distance from
the GICD and is based on the number of cores a given in

ti: k3: common: Add support for runtime detection of GICR base address

Valid addresses for GICR base are always a set calculable distance from
the GICD and is based on the number of cores a given instance of GICv3 IP
can support. The formula for the number of address bits is given by the
ARM GIC-500 TRM section 3.2 as 2^(18+log2(cores)) with the MSB set to
one for GICR instances. Holes in the GIC address space are also
guaranteed to safely return 0 on reads. This allows us to support runtime
detection of the GICR base address by starting from GIC base address plus
BIT(18) and walking until the GICR ID register (IIDR) is detected. We
stop searching after BIT(20) to prevent searching out into space if
something goes wrong. This can be extended out if we ever have a device
with 16 or more cores.

Signed-off-by: Andrew F. Davis <afd@ti.com>

show more ...

Merge pull request #1775 from glneo/uart-baud-rate

ti: k3: common: Allow customizing UART baud rate using build options

ti: k3: common: Allow customizing UART baud rate using build options

To accommodate scenarios where we want to use a UART baud rate other than
the default 115,200 allow the associated compiler defin

ti: k3: common: Allow customizing UART baud rate using build options

To accommodate scenarios where we want to use a UART baud rate other than
the default 115,200 allow the associated compiler definition to be set
via the K3_USART_BAUD build option by updating the platform make file.

Since the platform make file now also contains the default value (still
115,200), go ahead and remove the redundant definition from the platform
header file.

Suggested-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>

show more ...

Merge pull request #1726 from antonio-nino-diaz-arm/an/includes

Sanitise includes across codebase

Sanitise includes across codebase

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- inclu

Sanitise includes across codebase

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: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a282 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca33988b9 ("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>

show more ...