
On 11/29/23 2:00 AM, Manorit Chawdhry wrote:
Hi Andrew,
On 28/11/23 22:35, Andrew Davis wrote:
ATF and OPTEE regions may be firewalled from non-secure entities. To prevent access to this area we leave a hole there in the MMU map. This is the same idea as [0] but we complete that patch by adding the same for AM65, J721e, J7200, and J721s2 here.
[0] commit 0688ff3ae23c ("arm: mach-k3: arm64-mmu: do not map ATF and OPTEE regions in A53 MMU")
Signed-off-by: Andrew Davis afd@ti.com
arch/arm/mach-k3/arm64-mmu.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c index d872ed714c4..5c858ae0f84 100644 --- a/arch/arm/mach-k3/arm64-mmu.c +++ b/arch/arm/mach-k3/arm64-mmu.c @@ -24,7 +24,7 @@ struct mm_region am654_mem_map[] = { }, { .virt = 0x80000000UL, .phys = 0x80000000UL,
.size = 0x20000000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE }, {.size = 0x1e780000UL,
@@ -75,7 +75,7 @@ struct mm_region j7200_mem_map[] = { }, { .virt = 0x80000000UL, .phys = 0x80000000UL,
.size = 0x20000000UL,
.size = 0x1e780000UL,
ATF lies 0x70000000 for j7 devices.
For reference.
configs/am62ax_evm_a53_defconfig:8:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e780000
configs/verdin-am62_a53_defconfig:11:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e780000
configs/am64x_evm_a53_defconfig:11:8:CONFIG_K3_ATF_LOAD_ADDR=0x701c0000 -> This is also different
configs/am62x_beagleplay_a53_defconfig:9:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e780000 configs/am62x_evm_a53_defconfig:8:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e780000
and rest all devices use 0x70000000
OP-TEE is consistent across all SoCs and lies at 9e800000 and I can see that removing the map after 9e780000 does handle that but am not sure if I see the ATF being unified with all this flow.
We don't need to carve out ATF in our MMU map when it lives in SRAM as SRAM is already marked non-caching/device memory and so shouldn't be touched by U-Boot. Only when in DRAM do we do this carveout, and for all platforms that have ATF in DRAM it lies at 0x9e780000. So we make the MMU gap start at this location.
But as you have noticed, for platforms that keep ATF in SRAM this hole in DRAM is slightly larger than it needs to be (but that doesn't hurt anything, the OP-TEE hole is ~24MB and this just makes it just 128KB larger. This is DRAM so no one will care about 128KB).
The benefit of unconditionally leaving the MMU gap in DRAM cover where ATF would have been, even on SRAM platforms, is it makes the memory map unified across all platforms allowing us to combine them as in patch [4/4].
Andrew
Regards, Manorit
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE
}, { @@ -123,7 +123,7 @@ struct mm_region j721e_mem_map[] = { }, { .virt = 0x80000000UL, .phys = 0x80000000UL,
.size = 0x20000000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE }, {.size = 0x1e780000UL,
@@ -180,7 +180,13 @@ struct mm_region j721s2_mem_map[] = { }, { .virt = 0x80000000UL, .phys = 0x80000000UL,
.size = 0x80000000UL,
.size = 0x1e780000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
- }, {
.virt = 0xa0000000UL,
.phys = 0xa0000000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE }, {.size = 0x60000000UL,