mirror of
https://github.com/eclipse-threadx/threadx.git
synced 2026-10-06 06:59:08 +08:00
Frédéric Desbiens
b1a48824ea
entry.S programs ATCM to 0x30000000 and enables it at both exception levels. This
happens at EL2 deliberately: writing ENABLEEL2 from EL1 is silently ignored, which
was measured on BTCM and CTCM -- the base took and ENABLEEL10 took while
ENABLEEL2 stayed clear -- and the same write from EL2 sticks. tcm_enable() keeps
ENABLEEL10 as its success criterion for the same reason, since requiring both
would report failure for a bank that is usable at the level the caller runs at.
Programming ATCM also moves it off address 0, where CFGTCMBOOTx leaves it, so a
null-pointer write now faults instead of quietly landing in tightly-coupled
memory.
The boot image verifies rather than programs, preloads ATCM because ECC is enabled
and the check bits are not initialised by the core, and proves the bank holds data
both before the MPU is enabled and after. One MPU region covers it: the TRM
requires a region before an enabled TCM can be used, and an enabled TCM always
behaves as Non-cacheable Non-shareable Normal memory whatever the region says, so
only the permissions there matter.
BTCM and CTCM are left disabled, and that is a measurement rather than caution.
Enabling any second bank removes all measurable data-cache benefit:
ATCM only cache gain 24%
ATCM + BTCM cache gain 0%
ATCM + BTCM + CTCM cache gain 0%
ATCM + BTCM at another base cache gain 0%
ATCM + CTCM, BTCM disabled cache gain 0%
Five configurations, one variable. Not a particular bank, not its address, and not
the ECC preload: enabling a second bank at all. The benchmark buffer is in
non-RTU-local SRAM at 0x31800000, outside every TCM window, and CCSIDR reports the
same 16KB four-way cache throughout. I was wrong twice while narrowing this --
first blaming the preload, then blaming BTCM specifically -- and each was settled
by a run rather than by argument.
No erratum covers it. Checked the Cortex-R52 errata notice SDEN-857344 issue 19,
all twenty-five entries, and the S32Z2 0P91J mask set errata, whose RTU and R52
entries are ERR050509, ERR051107, ERR051153, ERR051441, ERR051613, ERR051614 and
ERR052126. A RAM pool shared between the RTU's last-level cache and the TCMs would
explain it, the LLC being documented as allocating ways to specific domains, but
that is a guess and it belongs with the other questions for NXP.
Little is lost meanwhile. The reference manual describes TCM_A as the bank
"optimized for small, regularly executed code such as interrupt service routines
or OS kernels", which is what a TCM is wanted for here, and enabling the other two
is one line each in entry.S once there is an answer.
Two checks were also wrong and are fixed. T5 reported every bank accessible while
two were disabled, because a disabled TCM's address range is serviced through AXIM
and memory answering there says nothing about the TCM; it now requires the bank to
be enabled as well. And T2 called tcm_enable() from EL1 for all three banks, which
would have switched on the very banks entry.S leaves off.
Verified on S32Z280 silicon: ATCM enabled and holding data before and after the
MPU, the cache benchmark back to 24%, protection checks X2 and X4 unchanged, and
the ThreadX demo still reporting 100 ticks with 20 preemptions.
Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>