On Friday 20 May 2022 14:30:02 Pali Rohár wrote: > + linux-mm > > Do you know what are requirements for kernel to support non-contiguous > memory support and what is needed to enable it for 32-bit powerpc? Any hints? > Currently powerpc arch code does not support "memblock.memory.cnt > 1" > except for WII which seems like a hack... See below. > > On Friday 20 May 2022 20:44:04 Ash Logan wrote: > > On 20/5/22 18:04, Pali Rohár wrote: > > > On Friday 20 May 2022 13:41:04 Ash Logan wrote: > > >> On 14/5/22 08:43, Pali Rohár wrote: > > >>> On Wednesday 02 March 2022 15:44:05 Ash Logan wrote: > > >>>> pgtable_32.c:mapin_ram loops over each valid memory range, which means > > >>>> non-contiguous memory just works. > > >>> > > >>> Hello! Does it mean that non-contiguous memory works for any 32-bit > > >>> powerpc platform, and not only for wiiu? If yes, should not be > > >>> non-contiguous memory support enabled for all 32-bit ppc boards then? > > >> > > >> Hi! Sorry for my delayed response. As best I can tell, it does indeed > > >> Just Work, but I have only been able to test on wiiu which is missing a > > >> lot of features other boards have (like PCI) - so it's possible there's > > >> still an assumption elsewhere in the kernel that I haven't hit. > > >> > > >> As best I can tell, the Wii and Wii U are the only 32-bit powerpc boards > > >> out there where it's even possible to have non-contiguous memory. > > > > > > What is the reason that those two boards are the **only**? Is there some > > > specific requirement from bootloader or hardware to "enable" > > > non-contiguous memory support? > > > > Not that I know of, I was just saying that I was only aware of those two > > boards where the memory map isn't contiguous, and that is the only place > > where it has been tested. Evidently you know of another board! > > > > > I'm interested in enabling non-contiguous memory support for P2020-based > > > board as it has gaps in its 32-bit memory layout and which could be used > > > for RAM mapping when 4GB DDR3 module is plugged in (default is 2GB). > > > > If it's like the Wii or Wii U (some memory at 0, a gap for MMIO or > > whatever, then more memory at a higher address) then you should try a > > patch along these lines, because barring the unknowns I mentioned before > > it should work. At least as far as I'm aware ;) > > > > >>>> Signed-off-by: Ash Logan <ash@xxxxxxxxxxxx> > > >>>> --- > > >>>> arch/powerpc/mm/init_32.c | 4 ++-- > > >>>> 1 file changed, 2 insertions(+), 2 deletions(-) > > >>>> > > >>>> diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c > > >>>> index 3d690be48e84..59a84629d9a0 100644 > > >>>> --- a/arch/powerpc/mm/init_32.c > > >>>> +++ b/arch/powerpc/mm/init_32.c > > >>>> @@ -125,10 +125,10 @@ void __init MMU_init(void) > > >>>> * lowmem_end_addr is initialized below. > > >>>> */ > > >>>> if (memblock.memory.cnt > 1) { > > >>>> -#ifndef CONFIG_WII > > >>>> +#if !defined(CONFIG_WII) && !defined(CONFIG_WIIU) > > >>>> memblock_enforce_memory_limit(memblock.memory.regions[0].size); > > >>>> pr_warn("Only using first contiguous memory region\n"); > > >>>> -#else > > >>>> +#elif defined(CONFIG_WII) > > >>>> wii_memory_fixups(); > > >>>> #endif > > >>>> } > > >>>> -- > > >>>> 2.35.1 > > >>>>