Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

Hi Dmitry,

On Thu, Mar 19, 2020 at 3:35 PM Dmitry Osipenko [off-list ref] wrote:

19.03.2020 11:18, Geert Uytterhoeven пишет:

quoted

On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko [off-list ref] wrote:

quoted

25.02.2020 14:40, Geert Uytterhoeven пишет:

quoted

On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski
[off-list ref] wrote:

quoted

On 27.01.2020 15:07, Geert Uytterhoeven wrote:

quoted

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>
---
Against arm/for-next.

This patch landed recently in linux-next. It breaks legacy booting from
the zImage + appended DT + cmdline/memory info provided via ATAGs. I
will debug it further once I find some spare time. What I noticed so
far, the cmdline/memory info is not read from the ATAGs, only the values
provided via appended DT are used.

Oops, something happening like this was one of my biggest worries when
posting this patch... Sorry for the breakage.

IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs?

I'll have a closer look later today.
In the mean time, I've sent some debug code I used when developing
this patch, which may be useful, hopefully.

NVIDIA Tegra is also affected by this patch. A week ago an updated
version of the patch was pushed into linux-next and now machine doesn't
boot at all.

I'm sorry to hear that.

Did v2 work for you?

Same as it was for Marek.

quoted

Are you sure this updated version is the culprit? There are several other
recent changes to head.S in arm/for-next.

Yes

quoted

Do you boot a separate DTB or an appended DTB?

Appended

quoted

Do you use ATAGS?

Yes

Thanks for the info!

I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and
disabling thumb2 build fixes the problem. Please correct it in the next
version of the patch, thanks in advance.

Interesting.  I enabled CONFIG_THUMB2_KERNEL=y, and it doesn't make
a difference for the few board combos I've tried (with/without appended DTB).
So it must be related to ATAGS.  Will dive deeper...

P.S. I never realized CONFIG_THUMB2_KERNEL=y had such a big size
impact: my kernel shrunk by ca. 1 MiB.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel