On Mon, Jul 6, 2020 at 5:03 PM Geert Uytterhoeven <geert+renesas@xxxxxxxxx> wrote: > Currently, the start address of physical memory is obtained by masking > the program counter with a fixed mask of 0xf8000000. This mask value > was chosen as a balance between the requirements of different platforms. > However, this does require that the start address of physical memory is > a multiple of 128 MiB, precluding booting Linux on platforms where this > requirement is not fulfilled. > > Fix this limitation by obtaining the start address from the DTB instead, > if available (either explicitly passed, or appended to the kernel). > Fall back to the traditional method when needed. > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space), > i.e. not at a multiple of 128 MiB. > > Suggested-by: Nicolas Pitre <nico@xxxxxxxxxxx> > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> > Reviewed-by: Nicolas Pitre <nico@xxxxxxxxxxx> > Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > Tested-by: Dmitry Osipenko <digetx@xxxxxxxxx> > Cc: Lukasz Stelmach <l.stelmach@xxxxxxxxxxx> I tried to test this on the APQ8060 Qualcomm board. This is an odd beast, because physical memory starts at 0x40200000 which is 8MiB aligned, not even 16 MiB. Oddly this *works* with the mainline kernel, giving the following boot crawl: [ 0.000000] cma: Reserved 256 MiB at 0x50000000 [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000040200000-0x000000005fffffff] [ 0.000000] HighMem empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040200000-0x0000000042dfffff] [ 0.000000] node 0: [mem 0x0000000048000000-0x000000005fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040200000-0x000000005fffffff] It crashes so hard with this patch that I don't even get earlydebug messages. (Scary!) I also tried to simply load the kernel to 0x50000000 which solved an issue I had with KASan in the past, but it doesn't help. The first memblock is at 0x40200000 after all. Any hints at what may be going wrong here? No panic though - I know this platform is a stress test, but it'd be nice not to regress it. Yours, Linus Walleij
