From: Arnd Bergmann <arnd@arndb.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Geert Uytterhoeven" <geert+renesas@glider.be>,
"Dmitry Osipenko" <digetx@gmail.com>,
"Nicolas Pitre" <nico@fluxnic.net>,
"Eric Miao" <eric.miao@nvidia.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Lukasz Stelmach" <l.stelmach@samsung.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Russell King" <linux@armlinux.org.uk>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"Chris Brandt" <chris.brandt@renesas.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB
Date: Mon, 20 Jul 2020 11:53:15 +0200 [thread overview]
Message-ID: <CAK8P3a33AWe-fa8jJnRrme56Hgc-hLdNH4FK6FEPyZ0=O=vwtg@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdZD3gVLdcjaOL9ZCfZD+hrOUB0-q0NpoHu6m1Ujupw6Fw@mail.gmail.com>
On Mon, Jul 20, 2020 at 11:45 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Jul 6, 2020 at 5:03 PM Geert Uytterhoeven
>
> 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.
No idea what /exactly/ is going wrong, but I would point out that this is one
of the platforms that is handled as a special case in the Makefile when
setting TEXT_OFFSET:
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.
textofs-y := 0x00008000
# We don't want the htc bootloader to corrupt kernel during resume
textofs-$(CONFIG_PM_H1940) := 0x00108000
# RTD1195 has Boot ROM at start of address space
textofs-$(CONFIG_ARCH_REALTEK) := 0x00108000
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
ifeq ($(CONFIG_ARCH_SA1100),y)
textofs-$(CONFIG_SA1111) := 0x00208000
endif
textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
textofs-$(CONFIG_ARCH_MESON) := 0x00208000
textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
TEXT_OFFSET := $(textofs-y)
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Geert Uytterhoeven" <geert+renesas@glider.be>,
"Nicolas Pitre" <nico@fluxnic.net>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Lukasz Stelmach" <l.stelmach@samsung.com>,
"Russell King" <linux@armlinux.org.uk>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"Chris Brandt" <chris.brandt@renesas.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Eric Miao" <eric.miao@nvidia.com>,
"Dmitry Osipenko" <digetx@gmail.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB
Date: Mon, 20 Jul 2020 11:53:15 +0200 [thread overview]
Message-ID: <CAK8P3a33AWe-fa8jJnRrme56Hgc-hLdNH4FK6FEPyZ0=O=vwtg@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdZD3gVLdcjaOL9ZCfZD+hrOUB0-q0NpoHu6m1Ujupw6Fw@mail.gmail.com>
On Mon, Jul 20, 2020 at 11:45 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Jul 6, 2020 at 5:03 PM Geert Uytterhoeven
>
> 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.
No idea what /exactly/ is going wrong, but I would point out that this is one
of the platforms that is handled as a special case in the Makefile when
setting TEXT_OFFSET:
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.
textofs-y := 0x00008000
# We don't want the htc bootloader to corrupt kernel during resume
textofs-$(CONFIG_PM_H1940) := 0x00108000
# RTD1195 has Boot ROM at start of address space
textofs-$(CONFIG_ARCH_REALTEK) := 0x00108000
# SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
ifeq ($(CONFIG_ARCH_SA1100),y)
textofs-$(CONFIG_SA1111) := 0x00208000
endif
textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
textofs-$(CONFIG_ARCH_MESON) := 0x00208000
textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
TEXT_OFFSET := $(textofs-y)
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-20 9:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 15:02 [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB Geert Uytterhoeven
2020-07-06 15:02 ` Geert Uytterhoeven
2020-07-07 6:50 ` Ard Biesheuvel
2020-07-07 6:50 ` Ard Biesheuvel
2020-07-07 7:39 ` Geert Uytterhoeven
2020-07-07 7:39 ` Geert Uytterhoeven
2020-07-07 7:45 ` Ard Biesheuvel
2020-07-07 7:45 ` Ard Biesheuvel
2020-07-07 7:58 ` Geert Uytterhoeven
2020-07-07 7:58 ` Geert Uytterhoeven
2020-07-07 8:35 ` Ard Biesheuvel
2020-07-07 8:35 ` Ard Biesheuvel
2020-07-07 8:40 ` Ard Biesheuvel
2020-07-07 8:40 ` Ard Biesheuvel
2020-07-07 9:09 ` Ard Biesheuvel
2020-07-07 9:09 ` Ard Biesheuvel
2020-07-20 9:45 ` Linus Walleij
2020-07-20 9:45 ` Linus Walleij
2020-07-20 9:53 ` Arnd Bergmann [this message]
2020-07-20 9:53 ` Arnd Bergmann
2020-07-21 12:58 ` Linus Walleij
2020-07-21 12:58 ` Linus Walleij
2020-07-23 1:19 ` Stephen Boyd
2020-07-23 1:19 ` Stephen Boyd
2020-08-03 10:18 ` Geert Uytterhoeven
2020-08-03 10:18 ` Geert Uytterhoeven
2020-08-03 19:46 ` Stephen Boyd
2020-08-03 19:46 ` Stephen Boyd
2020-08-14 14:03 ` Linus Walleij
2020-08-14 14:03 ` Linus Walleij
2020-08-14 14:06 ` Ard Biesheuvel
2020-08-14 14:06 ` Ard Biesheuvel
2020-08-15 9:18 ` Russell King - ARM Linux admin
2020-08-15 9:18 ` Russell King - ARM Linux admin
2020-08-15 8:28 ` Stephen Boyd
2020-08-15 8:28 ` Stephen Boyd
2020-08-15 9:16 ` Russell King - ARM Linux admin
2020-08-15 9:16 ` Russell King - ARM Linux admin
2020-08-15 10:28 ` Linus Walleij
2020-08-15 10:28 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK8P3a33AWe-fa8jJnRrme56Hgc-hLdNH4FK6FEPyZ0=O=vwtg@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=ardb@kernel.org \
--cc=chris.brandt@renesas.com \
--cc=digetx@gmail.com \
--cc=eric.miao@nvidia.com \
--cc=geert+renesas@glider.be \
--cc=l.stelmach@samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=masahiroy@kernel.org \
--cc=nico@fluxnic.net \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.