Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB

[Linus Walleij <linus.walleij@linaro.org>]

On Mon, Jul 6, 2020 at 5:03 PM Geert Uytterhoeven
<geert+renesas@glider.be> 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@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Dmitry Osipenko <digetx@gmail.com>
> Cc: Lukasz Stelmach <l.stelmach@samsung.com>

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