[PATCH v2 2/4] arm: mach-k3: Do not map ATF and OPTEE regions in MMU

[Andrew Davis]

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 at 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,
>> +		.size = 0x1e780000UL,
>>   		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>   			 PTE_BLOCK_INNER_SHARE
>>   	}, {
>> @@ -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,
>> +		.size = 0x1e780000UL,
>>   		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>   			 PTE_BLOCK_INNER_SHARE
>>   	}, {
>> @@ -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,
>> +		.size = 0x60000000UL,
>>   		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>   			 PTE_BLOCK_INNER_SHARE
>>   	}, {