[PATCH v4 1/2] mach-k3: add runtime memory carveouts for MMU table

[Andrew Davis]

On 6/27/25 1:09 PM, Tom Rini wrote:
> On Fri, Jun 27, 2025 at 01:06:50PM -0500, Andrew Davis wrote:
>> On 6/18/25 7:42 AM, Anshul Dalal wrote:
>>> In u-boot we only provide a single MMU table for all k3 platforms,
>>> this does not scale for devices with reserved memory outside the range
>>> 0x9e780000 - 0xa0000000 or for devices with < 2GiB of memory (eg
>>> am62-SIP with 512MiB of RAM).
>>>
>>> To properly configure the MMU on various k3 platforms, the
>>> reserved-memory regions need to be queried at runtime from the
>>> device-tree and the MMU table should be updated accordingly.
>>>
>>> This patch adds the required fixups to the MMU table (during proper
>>> U-boot stage) by marking the reserved regions as non cacheable and
>>> keeping the remaining area as cacheable.
>>>
>>> For the A-core SPL, the 128MiB region starting from SPL_TEXT_BASE
>>> is marked as cacheable i.e 0x80080000 to 0x88080000.
>>>
>>> The 128MiB size is chosen to allow for future use cases such as falcon
>>> boot from the A-Core SPL which would require loading kernel image from
>>> the SPL stage. This change also ensures the reserved memory regions that
>>> all exist past 0x88080000 are non cacheable preventing speculative
>>> accesses to those addresses.
>>>
>>> Signed-off-by: Anshul Dalal <anshuld at ti.com>
>>> ---
>>> Changes for v4:
>>>    - Add call to k3_mem_map_init for beagleplay
>>>    - Mark reserved regions as non-cacheable
>>
>> In v2 I said you cannot mark any regions as non-caching. How did this
>> sneak back in? If the reserved memory region is marked in DT as "no-map"
>> it must not be mapped at all. So NAK.
> 
> Presumably at the top of your mailbox now that I just pushed it to
> -next. 

Yes, this bubbled up to my attention thanks to your applied to -next message.

> Should I revert, or expect a prompt follow-up to clean things up?

If we get a quick cleanup patch that maps the reserved regions as caching to
match previous behavior that would remove much of the reason for this patch
in the first place. Removing mapping the reserved memory then we will break
remoteproc loading. Both have issues so reverting will probably be needed

Andrew