[REGRESSION] Re: [PATCH v11 00/11] Add support for dynamic MMU configuration

[Emanuele Ghidoli]

On 28/10/2025 05:38, Anshul Dalal wrote:
> Hi Francesco,
> 
> On Mon Oct 27, 2025 at 10:22 PM IST, Francesco Dolcini wrote:
>> Hello Anshul,
>>
>> On Fri, Oct 17, 2025 at 06:45:22PM +0530, Anshul Dalal wrote:
>>> Hi all,
>>>
>>> In U-Boot, TI only provides a single memory map for all k3 platforms, this
>>> does not scale for devices where atf and optee lie outside the range 0x80000000
>>> - 0x80080000 and 0x9e780000 - 0xa0000000 respectively.
>>>
>>> There are also issues for devices with < 2GiB of memory (eg am62SiP with 512MiB
>>> of RAM) as the maximum size for the first DRAM bank is hardcoded to 2GiB in the
>>> current memory map. Furthermore the second DRAM bank is mapped even for devices
>>> that only have a single bank.
>>>
>>> Therefore this patch set adds the required functionality to create the MMU table
>>> at runtime based on the device-tree.
>>>
>>> The patch set has been build tested on all effected platforms but boot-tested
>>> only on TI's K3 EVMs, the beagleplay and phytec's phycore-am6* platforms.
>>>
>>> The following effected boards have not been boot tested:
>>>  - verdin-am62
>>
>> it seems that this series introduce a regression on verdin-am62, I have
>> not done a bi-sect yet, but we run daily build of U-Boot master and the
>> regressions seems to have started when this patch series was
>> merged.
>>
>> On verdin-am62 we detect the RAM size at run-time, see
>> board/toradex/verdin-am62/verdin-am62.c:dram_init(), and now we always
>> get 2GiB even for modules with only 512MB or 1024MB of memory.
>>
> 
> This patch series modified the behavior of enable_caches to configure the
> memory map of the device as per the device-tree instead of using a
> static map for all of K3.
> 
> The issue with verdin-am62 seems to be that while you do properly
> configure gd->ram_size in your dram_init, the '/memory' node of the
> device-tree remains unchanged with the outdated 2GiB size.
> 
> You could try updating the fdt's memory size to the correct value in
> dram_init and see if that fixes the problem.
> 
> Regards,
> Anshul
Hello Anshul,

I was bisecting the series, and I can confirm that the commit "mach-k3: map
all banks using mem_map_from_dram_banks" introduces the regression.

Given that initcall_run_f() calls dram_init_banksize(), and after relocation
board_init_r() calls enable_caches() (call stack: board_init_r() ->
initcall_run_r() -> initr_caches() -> enable_caches()), I would expect that
enable_caches() should not override the bank sizes previously configured.
Currently, however, enable_caches() introduces this side effect.

Wouldn’t it make more sense to call fdtdec_setup_memory_banksize() in the
default dram_init_banksize() (in arch/arm/mach-k3/k3-ddr.c) and avoid calling
it again in mem_map_from_dram_banks()?

Regards,
Emanuele