7f323eb2df
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 |
||
|---|---|---|
| bl1 | ||
| bl2 | ||
| bl2u | ||
| bl31 | ||
| bl32 | ||
| common | ||
| docs | ||
| drivers | ||
| fdts | ||
| include | ||
| lib | ||
| make_helpers | ||
| plat | ||
| services | ||
| tools | ||
| .checkpatch.conf | ||
| .editorconfig | ||
| .gitignore | ||
| .gitreview | ||
| Makefile | ||
| dco.txt | ||
| license.rst | ||
| readme.rst | ||
readme.rst
Trusted Firmware-A
Trusted Firmware-A (TF-A) is a reference implementation of secure world software for Arm A-Profile architectures (Armv8-A and Armv7-A), including an Exception Level 3 (EL3) Secure Monitor. It provides a suitable starting point for productization of secure world boot and runtime firmware, in either the AArch32 or AArch64 execution states.
TF-A implements Arm interface standards, including:
- Power State Coordination Interface (PSCI)
- Trusted Board Boot Requirements CLIENT (TBBR-CLIENT)
- SMC Calling Convention
- System Control and Management Interface (SCMI)
- Software Delegated Exception Interface (SDEI)
The code is designed to be portable and reusable across hardware platforms and software models that are based on the Armv8-A and Armv7-A architectures.
In collaboration with interested parties, we will continue to enhance TF-A with reference implementations of Arm standards to benefit developers working with Armv7-A and Armv8-A TrustZone technology.
Users are encouraged to do their own security validation, including penetration testing, on any secure world code derived from TF-A.
More Info and Documentation
To find out more about Trusted Firmware-A, please view the full documentation that is available through trustedfirmware.org.
Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.