[PATCH 2/3] arm: mach-k3: Remove non-cached memory map areas

Andrew Davis afd at ti.com
Tue Nov 28 18:00:39 CET 2023


On 11/27/23 9:47 AM, Nishanth Menon wrote:
> On 23:04-20231123, Vignesh Raghavendra wrote:
>>
>>
>> On 11/23/2023 10:52 PM, Andrew Davis wrote:
>>> @@ -219,16 +177,9 @@ struct mm_region am62_mem_map[] = {
>>>   	}, {
>>>   		.virt = 0x80000000UL,
>>>   		.phys = 0x80000000UL,
>>> -		.size = 0x1E780000UL,
>>> -		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>> -			PTE_BLOCK_INNER_SHARE
>>> -	}, {
>>> -		.virt = 0xA0000000UL,
>>> -		.phys = 0xA0000000UL,
>>> -		.size = 0x60000000UL,
>>> +		.size = 0x80000000UL,
>>>   		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>>   			 PTE_BLOCK_INNER_SHARE
>>> -
>>>   	}, {
>>>   		.virt = 0x880000000UL,
>>>   		.phys = 0x880000000UL,
>>
>>
>> This causes issues when TF-A region @0x9e780000 is firewalled off from
>> non-secure world. A53 does speculative accesses to this region from EL1
>> leading to FW exceptions being reported on TIFS log (although A53 itself
>> doesn't seem to abort)
> 
> Hmm... Why not just manage the ones that use TFA in DDR seperately? I
> suppose OPTEE will come in the way?
> 
> Looks like the no-map is not honored well.. as you were mentioning, a
> zephyr style generating the map from dts might be much better, but then
> we do support multiple dtbs as well..
> 
> OK - I guess we need to leave this cleanup for now.
> 

We can make the same cleanup while leaving the firewall hole in place
(it is in the same spot for all SoCs today so no problem here). I'll
send a v2 with that.

Andrew


More information about the U-Boot mailing list