On Sat, Jun 28, 2025 at 12:38:19AM +0530, Anshul Dalal wrote: > 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 <[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 > > > > 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.
OK thanks, reverting shortly. -- Tom
signature.asc
Description: PGP signature
