On Fri, May 8, 2015 at 11:33 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> > What exactly is the kernel limitation here? >> >> If we can't enable HIGHMEM, e.g. because the MIPS CPU has D$ aliases, >> then Linux is supposed to ignore any RAM above the highmem/lowmem >> boundary. >> >> There is code in paging_init() that tries to do this. Several years >> ago it used to work, but the last time I tried it (~Oct 2014) it was >> broken due to some other changes in MIPS early memory init, so Linux >> hangs on boot unless you take the excess RAM out of DT. Jaedon may be >> running into the same issue. > > Ok, I see. Could you avoid the problem by not requiring highmem? I think the problem goes away if you disable CONFIG_HIGHMEM. > We have some hacks on arch/arm/mach-realview to provide a nonlinear > virt_to_phys() function, which ends up moving all RAM underneath the > lowmem limit. On this particular chip we can get a linear 1:1 virtual:physical mapping for the first 1GB of system memory using the XKS01 hardware feature and a bit of software support. As Jaedon pointed out, a couple of other things need to be tweaked in the arch/mips code: - Uncached/cached address conversions, as kseg1 is moved and reduced - Enabling XKS01 on each CPU thread on SMP boot, PM resume, or hot unplug - Setting aside a special VA range for uncached ioremaps, similar to ARM, instead of assuming all kseg0 addresses have a corresponding kseg1 address - Adding a wired TLB entry for PA 4000_0000 - 4fff_ffff Without using XKS01, we'd need to use a nonlinear VA:PA mapping and repurpose a large chunk of vmalloc space to map the upper 768MB of system memory. This would also require wired TLB entries and the special ioremap range. I never tried to make this work because the XKS01 solution was cleaner. Going beyond 1GB of system memory on this CPU would require HIGHMEM.
