| 2fcd408b | 27-Sep-2022 |
Andrew Davis <afd@ti.com> |
feat(ti): do not handle EAs in EL3
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-o
feat(ti): do not handle EAs in EL3
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
show more ...
|
| 5668db72 | 12-Jan-2023 |
Andrew Davis <afd@ti.com> |
feat(ti): set snoop-delayed exclusive handling on A72 cores
Snoop requests should not be responded to during atomic operations. This
can be handled by the interconnect using its global monitor or by
feat(ti): set snoop-delayed exclusive handling on A72 cores
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
show more ...
|
| 10d5cf1b | 01-Sep-2022 |
Andrew Davis <afd@ti.com> |
feat(ti): disable L2 dataless UniqueClean evictions
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: Ic878fdb49
feat(ti): disable L2 dataless UniqueClean evictions
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
show more ...
|
| 81858a35 | 10-Jan-2023 |
Andrew Davis <afd@ti.com> |
feat(ti): set L2 cache ECC and and parity on A72 cores
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
feat(ti): set L2 cache ECC and and parity on A72 cores
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
show more ...
|
| a9f46fad | 11-Feb-2022 |
Dave Gerlach <d-gerlach@ti.com> |
feat(ti): allow build config of low power mode support
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
feat(ti): allow build config of low power mode support
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>
show more ...
|
| 38164e64 | 07-Jan-2022 |
Dave Gerlach <d-gerlach@ti.com> |
feat(ti): increase SEC_SRAM_SIZE to 128k
Increase the lite platform SEC_SRAM_SIZE to 128k to allow space
for GIC context.
Change-Id: I6414309757ce9a9b7b3a9233a401312bfc459a3b
Signed-off-by: Dave Ge
feat(ti): increase SEC_SRAM_SIZE to 128k
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>
show more ...
|
| 2393c276 | 30-Nov-2021 |
Dave Gerlach <d-gerlach@ti.com> |
feat(ti): add PSCI handlers for system suspend
Add necessary K3 PSCI handlers to enable system suspend to be reported
in the PSCI capabilities when asked during OS boot.
Additionally, have the hand
feat(ti): add PSCI handlers for system suspend
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>
show more ...
|
| b40a4677 | 07-Jan-2022 |
Dave Gerlach <d-gerlach@ti.com> |
feat(ti): add gic save and restore calls
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.
feat(ti): add gic save and restore calls
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>
show more ...
|
| 3dd87efb | 26-Mar-2021 |
Nishanth Menon <nm@ti.com> |
plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0
ENABLE_PIE (position independent executable) is default on K3
platform to handle variant RAM configurations in the system. This,
unfo
plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0
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
show more ...
|
| a2b56476 | 26-Mar-2021 |
Nishanth Menon <nm@ti.com> |
plat: ti: k3: common: bl31_setup: Use BL31_SIZE instead of computing
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
c
plat: ti: k3: common: bl31_setup: Use BL31_SIZE instead of computing
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
show more ...
|
| c9f887d8 | 26-Mar-2021 |
Nishanth Menon <nm@ti.com> |
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 ...
|
| 84af8956 | 09-Dec-2020 |
Andrew F. Davis <afd@ti.com> |
ti: k3: Introduce lite device board support
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 dev
ti: k3: Introduce lite device board support
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
show more ...
|
| 7f323eb2 | 11-Dec-2020 |
Nishanth Menon <nm@ti.com> |
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 ...
|
| ff7b75e2 | 11-Dec-2020 |
Nishanth Menon <nm@ti.com> |
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 ...
|
| 22b7a229 | 24-Oct-2020 |
Suman Anna <s-anna@ti.com> |
ti: k3: drivers: ti_sci: Update ti_sci_msg_req_reboot to include domain
The ti_sci_msg_req_reboot message payload has been extended to include
a domain field, and this should be zero to reset the en
ti: k3: drivers: ti_sci: Update ti_sci_msg_req_reboot to include domain
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
show more ...
|