[PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB
Linus Walleij
linus.walleij at linaro.org
Mon Jul 20 05:45:38 EDT 2020
On Mon, Jul 6, 2020 at 5:03 PM Geert Uytterhoeven
<geert+renesas at 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 at fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Reviewed-by: Nicolas Pitre <nico at fluxnic.net>
> Reviewed-by: Ard Biesheuvel <ardb at kernel.org>
> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Tested-by: Dmitry Osipenko <digetx at gmail.com>
> Cc: Lukasz Stelmach <l.stelmach at 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
More information about the linux-arm-kernel
mailing list