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

[Anshul Dalal]

On Sat Jun 28, 2025 at 12:12 AM IST, Andrew Davis wrote:
> 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
>

The idea of the patch was to carveout the optee and atf's reserved
memory out of u-boot proper but I blindly mapped every reserved node as
non-cacheable which was not the right approach. I can send a quick
follow up fix but it would likely remove everything this patch added to
begin with. So, I feel it's better to drop this altogether and I'll post
a v5 later with the required changes.

Aplogies for any inconvenience.

- Anshul