Hello Ahmad,
-----Original Message----- From: Ahmad Fatoum a.fatoum@pengutronix.de Sent: Thursday, September 7, 2023 7:56 AM To: Jacky Bai ping.bai@nxp.com; tf-a@lists.trustedfirmware.org; Ye Li ye.li@nxp.com; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Cc: Pengutronix Kernel Team kernel@pengutronix.de Subject: Re: Cache Maintenance For SiP buffers
Hello Jacky,
On 07.09.23 07:30, Jacky Bai wrote:
On 07.09.23 04:03, Jacky Bai wrote:
Subject: Cache Maintenance For SiP buffers
- 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.
AFAICS, TF-A has a cacheable mapping of DRAM. If there's no explicit flushing in TF-A, that means that:
- There may be dirty lines in cache on exit to non-secure world
- barebox invalidates cache on return from SMC
- dirty lines are discarded, RAM is fetched, result is lost
The HAB code is working though, which makes me suspicious, whether I am not missing something.
From what I know, and If I read Section 4 of AN12263 [1], it is the BootROM itself that performs cache maintenance operations. The readout of whether cache is enabled has been missing on certain i.MX6 SOCs (listed in the same section), hence there was a need to inform the BootROM of those SOCs that cache is enabled. This is implemented in U-Boot commit 53c8a510e7 ("arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail"), however the commit description does not explicitly states that this indication is addressed.
Please note, that this applies mainly to HABv4 RVT authenticate_image() API that is primarily used to extend the RoT after the bootloader is fully operational. NXP documentation does not detail if the same applies to BootROM authenticating initial image (PBL or SPL), but I would assume that it does.
Regards, Andrey
Cheers, Ahmad
BR
Thanks, Ahmad
BR
Thanks, Ahmad
Pengutronix e.K. | |
--