Subject: Re: Cache Maintenance For SiP buffers
Hello Jacky,
thanks for your prompt reply.
On 07.09.23 04:03, Jacky Bai wrote:
Subject: Cache Maintenance For SiP buffers
Hi,
I was looking at imx_hab_handler, which forwards calls into the BootROM on i.MX SoCs in response to secure monitor calls. The BootROM call (and thus the SiP call) accepts two pointers as arguments, where it
writes data.
The plat/imx/imx8m/imx8m*/imx8m*_bl31_setup.c files map the RAM as MT_MEMORY | MT_RW, which would mean that not only is it writable
from
TF-A side, but it's also mapped cacheable.
I see no explicit cache maintenance in the i.MX SiP code for these two pointer arguments and haven't been successful to find where in TF-A core code if at all, complete D-Cache is flushed on SMC exit.
Therefore I ask:
- Don't shared non-secure memory buffers between EL3 and lower EL
require explicit cache maintenance?
Did I miss the place where this cache maintenance is done?
How did it work so far? barebox does explicit flushing before HAB SiP, invalidation after. U-Boot doesn't do cache maintenance. Both apparently work...
You can refer to the docs/plat/imx8m.rst HAB section. ^_^.
I had checked the docs and while there is a note about why RAM is mapped MT-RW, there is no info about how cache coherency is maintained, hence my question.
RAM is the OCRAM, it is not used in the HAB SiP call for write data buffer.
TF-A RAM is OCRAM, but I care about the write data buffers used by BL33. Those are in DRAM, which is mapped cachable both in secure and non-secure world and may require explicit cache maintenance.
The DRAM is mapped as MT_NS in secure world. Should no cache coherence issue.
BR
Thanks, Ahmad
BR
Thanks, Ahmad
Pengutronix e.K. | |