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>
There maybe a lot of reuse between platforms for bl31_setup in future
which may require us to have a common bl31 setup driver for TI.
The ti_bl31_setup is expected to contain all the reusable bits
and the soc_bl31_setup can have the custom soc init functionality
like the mmap regions and any special sequences needed at
device boot
While at it, also fix the path of the reference to the kernel doc
for booting.
Change-Id: Ie574f08cf3ba75362c45f85306499061ef89c964
Signed-off-by: Dhruva Gole <d-gole@ti.com>
The TI SCI transport header will allow us to abstract all transport
related calls from the actual medium of transport which can vary
from device to device.
For eg. it is sec proxy for current TI K3 devices, but in future it
maybe mailbox like in the TI AM62L.
With this change, we no longer need to include anything from the IPC
folder, so drop it from plat_common.mk
Change-Id: Ic99209688cf69f20e694e31e553ce4ec74254669
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Prepare to support more devices and abstract TI SCI and it's transport
layers. This refactor will help keep things clean when new ipc drivers
get added.
Change-Id: I05673f379b1398c0b6a2bd9e1b5392165d12f151
Signed-off-by: Dhruva Gole <d-gole@ti.com>
DM_MANAGED is the new mode to support a model where DM chooses the
suspend mode. Previously suspend always chose deep sleep. Now DM may
also choose other modes like IO+DDR or other modes in the future. DM has
more knowledge about constraints regarding wakeup latency or which parts
of the system need to work continuously, so it is better able to decide
what suspend mode should be used.
To support DM_MANAGED in TF-A the next system mode needs to be fetched
and passed to the enter sleep message. The new ti_sci command to fetch
the next system mode is added which is ti_sci_lpm_get_next_sys_mode().
DM_MANAGED is only enabled if the firmware capability is supported.
Change-Id: I7244e27793cc60e1673271990d7cd840294d6cc3
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
ti_sci_get_revision handles getting the firmware version and ti_sci_init
is just a wrapper around it with no added benefit.
Refactor the ti_sci_get_revision to give the version information and
remove ti_sci_init wrapper.
Change-Id: I39184af5b00bedc8b9220533f1ddac3b6672d2f1
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The trail bytes from the secure proxy driver were being overwritten,
increase the count each time to not overwrite the existing data and not
get the end data corrupted from secure proxy.
Fixes: d76fdd33e0 ("ti: k3: drivers: Add Secure Proxy driver")
Change-Id: I8e23f8b6959da886d6ab43049746f78765ae1766
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
As stated in the commit introducing the NS_TIMER_SWITCH build flag,
saving/restoring this registers causes the non-secure timer to stop
while in the secure world and non-secure timer interrupts are prevented
from asserting until we return to the non-secure world. This breaks
any realtime OS on the non-secure side that uses this timer for
realtime scheduling.
This flag is by default off, but OP-TEE SPD enables it. The K3 OP-TEE
platform makes no use of these registers and we would like to have
support for realtime OSs while also supporting the OP-TEE SPD. Disable
this flag in our platform definition.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I65055512d897b93b7690fd63c734f4731a6e09e6
Failing to send a message is often not fatal and we will end up trying
to send again. This would fail as some exit paths do not release the
secure proxy xfer lock. Release this lock on all return paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I3939015774f819572dbd26720b2c105fba7574cb
Instead of hardcoding this at build time we can ask the firmware if
suspend is supported and if not disable accordingly. Then remove compile-
time ifdefs.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ib966c04c0bdb79a82e8d890cec5e65d883acd6e3
This TISCI API is used to retrieve the firmware capabilities of the
currently running system-firmware.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I55402dcf876e997eb21bb1f31c725e167c507c47
No K3 SoC supported by this TARGET_BOARD has any cluster
2 or 3 cores. Remove these to save some memory.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I27868a2f3aac25fa0fdec56847e273d88f0d9a87
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
The refactor caused many APIs to be regressed due to copy paste changes
so fix them.
Fixes: 6688fd7aec ("refactor(ti): refactor ti_sci_{setup,do}_xfer to allow zero size response")
Change-Id: I03a808fa0bf2cbefbc1c9924bdaf4cfb2ad7f2cb
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The commit 3e14df6f63 removed clearing of argument registers even when
BL31 is the first stage. In that case the registers are left in a random
state. TI platforms check that the arguments have been zero'd in early
setup and so all TI platforms are not broken. Not sure why this check was
here at all, so simply remove it to fix boot.
Fixes: 3e14df6f63 ("fix(bl31): avoid clearing of argument registers in RESET_TO_BL31 case")
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I02bdd16b67fb5facc4c47ec596a42f110a663377
When communicating with the system controller over secure proxy we clear
a thread, write our message, then wait for a response. This must not be
interrupted by a different transfer on the same thread. Take a lock
during this sequence to prevent contention.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I7789f017fde7180ab6b4ac07458464b967c8e580
Let the compiler choose when to inline. Here this reduces binary size.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I68cd0fc3a94c8c94781ca3dc277a1dd4c6f2bd3a
This allows us to use the common xfer setup path even for no-wait
messages. Then factor that out of each no-wait function.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ib17d3facd293f3fc91dda56b2906121b43250261
Although we do not use these for anything today, they are returned
in this structure and the struct's definition should match.
While here fix a couple comment typos.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Iac4ec999b44e703e600bde93b0eee83753566876
Taking a reference at this early stage can cause boot failure if the DM
firmware is not fully initialized. Remove this early call until the
fix in DM firmware is widely available.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ic9c47ccf1e9a1b9faeb1c7d2665d54cf55ef5396
Some of our specialized sections are not prefixed with the conventional
period. The compiler uses input section names to derive certain other
section names (e.g. `.rela.text`, `.relacpu_ops`), and these can be
difficult to select in linker scripts when there is a lack of a
delimiter.
This change introduces the period prefix to all specialized section
names.
BREAKING-CHANGE: All input and output linker section names have been
prefixed with the period character, e.g. `cpu_ops` -> `.cpu_ops`.
Change-Id: I51c13c5266d5975fbd944ef4961328e72f82fc1c
Signed-off-by: Chris Kay <chris.kay@arm.com>
Send a TI-SCI control message to system firmware to power down the board.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I6b8fa64baa94da078db82fc8e115630c9f200b3d
This could be useful if we had extra information to print or
when RAS extensions are available, neither apply here so lets
not trap these in EL3 for now.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ia0334eb845686964e794afe45c7777ea64fd6b0b
Snoop requests should not be responded to during atomic operations. This
can be handled by the interconnect using its global monitor or by the
core's SCU delaying to check for the corresponding atomic monitor state.
TI SoCs take the second approach. Set the snoop-delayed exclusive handling
bit to inform the core it needs to delay responses to perform this check.
As J784s4 is currently the only SoC with multiple A72 clusters, limit
this delay to only that device.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I875f64e4f53d47a9a0ccbf3415edc565be7f84d9
Do this early before we enable caching as a workaround for ARM A72
Errata #854172.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ic878fdb49e598da0ea6ade012712f8f57023678e
The Cortex-A72 based cores on K3 platforms have cache ECC and
parity protection, enable these.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Icd00bc4aa9c1c48f0fb2a10ea66e75e0b146ef3c
The Cortex-A72 based cores on K3 platforms can be clocked fast
enough that an extra latency cycle is needed to ensure correct
L2 access. Set the latency here for all A72 cores.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: I639091dd0d2de09572bf0f73ac404e306e336883
Current RAS framework in TF-A only supports handling errors originating
from NS world but the HANDLE_EA_EL3_FIRST flag configures it for all
lower Els. To make the current design of RAS explicit, rename this macro
to HANDLE_EA_EL3_FIRST_NS and set EA bit in scr_el3 only when
switching to NS world.
Note: I am unaware of any platform which traps errors originating in
Secure world to EL3, if there is any such platform then it need to
be explicitly implemented in TF-A
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: If58eb201d8fa792c16325c85c26056e9b409b750
The J784S4 SoC has two quad Cortex-A72 core clusters. This is the first
SoC in the K3 family with Quad cores in a A-72 cluster. So, a new board
configuration is introduced to support quad core clusters on the J784S4
SoC of the K3 family of devices.
See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022)
for further details: http://www.ti.com/lit/zip/spruj52
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Change-Id: I0ed1f14ab32a56ae06e3df3161ace4597d14a48d
Not all K3 platforms support low power mode, so to allow these
features to be included for platforms that do in build and
therefore reported in the PSCI caps, define K3_PM_SYSTEM_SUSPEND
flag that can be set during build that will cause appropriate
space and functionality to be included in build for system
suspend support.
Change-Id: I821fbbd5232d91de6c40f63254b855e285d9b3e8
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
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>
Add necessary K3 PSCI handlers to enable system suspend to be reported
in the PSCI capabilities when asked during OS boot.
Additionally, have the handlers provide information that all domains
should be off and also have the power domain suspend handler invoke the
TISCI_MSG_ENTER_SLEEP message to enter system suspend.
Change-Id: I351a16167770e9909e8ca525ee0d74fa93331194
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add functions to save and restore GICv3 redist and dist contexts during
low power mode and then call these during the suspend entry and finish
psci handlers.
Change-Id: I26c2c0f3b7fc925de3b349499fa42d2405441577
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
This TISCI API must be used to trigger entry into system suspend, and
this is done through the use of TI_SCI_MSG_ENTER_SLEEP. Introduce a
method to send this message.
Change-Id: Id7af5fb2a34623ad69e76764f389ff4d8d259fba
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 compute BL31_END - BL31_START on the fly, which is basically
BL31_SIZE. Lets just use the BL31_SIZE directly so that we dont
complicate PIE relocations when actual address is +ve and -ve offsets
relative to link address.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I5e14906381d2d059163800d39798eb39c42da4ec
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
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
The ti_sci_msg_req_reboot message payload has been extended to include
a domain field, and this should be zero to reset the entire SoC with
System Firmwares newer than v2020.04. Add the domain field to the
ti_sci_msg_req_reboot message structure for completeness. Set it up
to zero to fix the reboot issues with newer firmwares.
This takes care of the specific ABI that changed and has an impact on
ATF function.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I4f8064b9d6555687822dc2b2b8ec97609286fa0b
Sec proxy data buffer is 60 bytes with the last of the registers
indicating transmission completion. This however poses a bit
of a challenge.
The backing memory for sec_proxy is regular memory, and all sec proxy
does is to trigger a burst of all 60 bytes of data over to the target
thread backing ring accelerator. It doesn't do a memory scrub when
it moves data out in the burst. When we transmit multiple messages,
remnants of previous message is also transmitted which results in
some random data being set in TISCI fields of messages that have been
expanded forward.
The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.
So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).
This allows us to scale and introduce ABI changes back into TF-A only
as needed.
Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: Ie22cb2a319f4aa80aef23ffc7e059207e5d4c640
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
