On Thu, 29 Apr 2021 at 18:11, Simon Glass sjg@chromium.org wrote:
Hi Patrick,
On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay patrick.delaunay@foss.st.com wrote:
Save the no-map information present in 'reserved-memory' node to allow correct handling when the MMU is configured in board to avoid speculative access.
Signed-off-by: Patrick Delaunay patrick.delaunay@foss.st.com
(no changes since v1)
common/image-fdt.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
Where is no-map documented?
Reviewed-by: Simon Glass sjg@chromium.org
I don't remember exactly where the discussion ended up the last time, so please disregard this if we settled it, but I still don't think that secure-only memory should be described in the DT at all.
The v7 and v8 documentation are not 100% aligned on this, but the S bit is now considered a true address bit, and so secure address 0x0 and non-secure address zero could be decoded by different peripherals at the same time, even if some TZ firewall implementations don't implement it that way.
Since DT addresses don't carry the S bit at all, any address described in DT must be assumed to be a non-secure address. This means that the no-map region essentially describes a non-secure region that does not exist, in order to prevent a secure region at the same offset (which DT cannot describe in the first place) from being covered by the linear mapping.
So, apologies if we are going around in circles here, but could you please explain again why the DT is describing secure memory as non-secure memory, and then reserving it again using no-map?