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. Should I revert, or expect a prompt follow-up to clean things up? -- Tom
signature.asc
Description: PGP signature
