Commit Graph

10 Commits

Author SHA1 Message Date
Nishanth Menon 7f323eb2df 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-23 06:36:25 -06:00
Nishanth Menon f577388a32 ti: k3: common: sec_proxy: Fill non-message data fields with 0x0
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
2020-12-23 06:33:39 -06:00
Andrew F. Davis fb98ca5a81 ti: k3: drivers: sec_proxy: Use direction definitions
The direction of a thread should be explicitly compared to avoid
confusion. Also fixup message wording based on this direction.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: Ia3cf9413cd23af476bb5d2e6d70bee15234cbd11
2019-04-23 11:09:13 -04:00
Andrew F. Davis 6c30baee93 ti: k3: drivers: sec_proxy: Fix printf format specifiers
The ID of a thread is not used outside for printing it out when
something goes wrong. The specifier used is also not consistent.
Instead of storing the thread ID, store its name and print that.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Change-Id: Id137c2f8dfdd5c599e220193344ece903f80af7b
2019-04-23 11:09:11 -04:00
Antonio Niño Díaz a0d894397d
Merge pull request #1772 from glneo/clear-proxy-queue
TI K3 Clear proxy receive queue on transmit
2019-01-22 15:03:01 +00:00
Andrew F. Davis 2004552e62 ti: k3: drivers: sec_proxy: Allow clearing a Secure Proxy receive thread
It can be needed to discard all messages in a receive queue. This
can be used during some error recovery situations.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
2019-01-21 13:33:32 -06:00
Andrew F. Davis 4f9444cd29 ti: k3: drivers: sec_proxy: Switch error messages
The logic is correct here, but the error messages are
reversed, switch them.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
2019-01-21 12:05:43 -06:00
Antonio Nino Diaz 09d40e0e08 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: 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>
2019-01-04 10:43:17 +00:00
Antonio Nino Diaz c3cf06f1a3 Standardise header guards across codebase
All identifiers, regardless of use, that start with two underscores are
reserved. This means they can't be used in header guards.

The style that this project is now to use the full name of the file in
capital letters followed by 'H'. For example, for a file called
"uart_example.h", the header guard is UART_EXAMPLE_H.

The exceptions are files that are imported from other projects:

- CryptoCell driver
- dt-bindings folders
- zlib headers

Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-11-08 10:20:19 +00:00
Andrew F. Davis d76fdd33e0 ti: k3: drivers: Add Secure Proxy driver
Secure Proxy module manages hardware threads that are meant
for communication between the processor entities. Add support
for this here.

Signed-off-by: Andrew F. Davis <afd@ti.com>
2018-08-22 10:33:09 -05:00