Hi Andrei, I think you are right about this inconsistency. AFAIK, AArch64 memory model says that when S1 MMU is off, all Data accesses are Device_nGnRnE. And this means that there is inconsistent memory attributes when USE_COHERENT_MEM=1 in current TF-A.
My opinion is that this is probably an oversight and need to be corrected. Since nGnRnE has stronger ordering than nGnRE, it is unlikely to cause any problem. I think MT_NON_CACHEABLE does not have the required properties for being used in the Bakery Lock algorithm and we will still have the inconsistent memory attributes when accessed with S1 MMU off. We need to use the MT_Device memory type.
Best Regards Soby Mathew
From: Olivier Deprez via TF-A tf-a@lists.trustedfirmware.org Sent: Tuesday, May 13, 2025 1:00 PM To: Andrei Stefanescu andrei.stefanescu@nxp.com; tf-a@lists.trustedfirmware.org Cc: Ciprian Marian Costea ciprianmarian.costea@nxp.com; Alexandru-Catalin Ionita alexandru-catalin.ionita@nxp.com Subject: [TF-A] Re: Question about memory mapping attributes for MT_DEVICE
Hi,
On peripheral regions mapped as nGnRE, and by browsing git history, I can only really tell that this mapping exists since first TF-A commit in 2013 (!). https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/4f...
I'm a bit nervous about changing this attribute globally which will affect all peripherals mapped as MT_DEVICE.
For the use case you mention, I appreciate you're intending to map a 'normal' memory region e.g. DRAM or SRAM (as opposed to a peripheral MMIO), so I'd be inclined to say you could map this region as MT_NON_CACHEABLE achieving the same purpose?
Regards, Olivier.
________________________________ From: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Sent: 13 May 2025 13:42 To: Andrei Stefanescu <andrei.stefanescu@nxp.commailto:andrei.stefanescu@nxp.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Cc: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.commailto:ghennadi.procopciuc@nxp.com>; Ciprian Marian Costea <ciprianmarian.costea@nxp.commailto:ciprianmarian.costea@nxp.com>; Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.commailto:alexandru-catalin.ionita@nxp.com> Subject: Re: Question about memory mapping attributes for MT_DEVICE
The email was moderated, re-sending on behalf of Andrei.
________________________________ From: Andrei Stefanescu <andrei.stefanescu@nxp.commailto:andrei.stefanescu@nxp.com> Sent: 13 May 2025 12:35 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Cc: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.commailto:ghennadi.procopciuc@nxp.com>; Ciprian Marian Costea <ciprianmarian.costea@nxp.commailto:ciprianmarian.costea@nxp.com>; Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.commailto:alexandru-catalin.ionita@nxp.com> Subject: Question about memory mapping attributes for MT_DEVICE
Hi,
I noticed that the memory mapping attributes for MT_DEVICE memory are defined to: nGnRE [1]. Why was nGnRE selected instead of nGnRnE?
Platforms which have USE_COHERENT_MEM set to 1 will map the coherent memory area as MT_DEVICE. This area is helpful for cases where a backery lock is shared between cores which have MMU enabled and cores which don't (whose access is equivalent to nGnRnE). This would generate an access attributes mismatch for the coherent memory area.
Would it be ok to send a patch which changes the ATTR_DEVICE to nGnRnE?
Best regards, Andrei Stefanescu
[1] - https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/...