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 <[email protected]>
---
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
