linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
	"Lukasz Stelmach" <l.stelmach@samsung.com>,
	"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>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Chris Brandt" <chris.brandt@renesas.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, "Rob Herring" <robh+dt@kernel.org>,
	"Grant Likely" <grant.likely@arm.com>
Subject: Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
Date: Tue, 19 May 2020 14:11:14 +0200	[thread overview]
Message-ID: <CAMuHMdV0_GTop+YTPeu+aSFB=1YHsyzLXn-+0fa8upkNMq10bQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3H=7qx+Rz9sScTVCSMKWGwQ_ROnyoyK73A5yUd+_jbTw@mail.gmail.com>

Hi Arnd,

On Tue, May 19, 2020 at 1:28 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, May 19, 2020 at 1:21 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
>
> > >
> > > > However, something under /chosen should work.
> > >
> > > Yet another sticky plaster...
> >
> > IMHO the old masking technique is the hacky solution covered by
> > plasters.
> >
> > DT describes the hardware.  In general, where to put the kernel is a
> > software policy, and thus doesn't belong in DT, except perhaps under
> > /chosen.  But that would open another can of worms, as people usually
> > have no business in specifying where the kernel should be located.
> > In the crashkernel case, there is a clear separation between memory to
> > be used by the crashkernel, and memory to be solely inspected by the
> > crashkernel.
> >
> > Devicetree Specification, Release v0.3, Section 3.4 "/memory node" says:
> >
> >     "The client program may access memory not covered by any memory
> >      reservations (see section 5.3)"
> >
> > (Section 5.3 "Memory Reservation Block" only talks about structures in
> > the FDT, not about DTS)
> >
> > Hence according to the above, the crashkernel is rightfully allowed to
> > do whatever it wants with all memory under the /memory node.
> > However, there is also
> > Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> > This suggests the crashkernel should be passed a DTB that contains a
> > /reserved-memory node, describing which memory cannot be used freely.
> > Then the decompressor needs to take this into account when deciding
> > where the put the kernel.
> >
> > Yes, the above requires changing code. But at least it provides a
> > path forward, getting rid of the fragile old masking technique.
>
> There is an existing "linux,usable-memory-range" property documented
> in Documentation/devicetree/bindings/chosen.txt, which as I understand
> is exactly what you are looking for, except that it is currently only
> documented for arm64.

Thank you, that looks appropriate!

It seems this is not really used by the early startup code.
Is that because the early startup code always runs in-place, and the
kernel image is not even copied?

> Would extending this to arm work?

Let's see.... Th arm early boot code seems to be more complex than the
arm64 code ;-)

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

  reply	other threads:[~2020-05-19 12:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200429082134eucas1p2415c5269202529e6b019f2d70c1b5572@eucas1p2.samsung.com>
2020-04-29  8:21 ` [PATCH v6] ARM: boot: Obtain start of physical memory from DTB Geert Uytterhoeven
2020-05-19  8:53   ` Lukasz Stelmach
2020-05-19  9:30     ` Russell King - ARM Linux admin
2020-05-19  9:44     ` Geert Uytterhoeven
2020-05-19  9:46       ` Russell King - ARM Linux admin
2020-05-19 11:21         ` Geert Uytterhoeven
2020-05-19 11:28           ` Arnd Bergmann
2020-05-19 12:11             ` Geert Uytterhoeven [this message]
2020-05-19 11:43           ` Russell King - ARM Linux admin
     [not found]             ` <CGME20200519122044eucas1p1220e8827c66dd1ace94b0a86a34f9c37@eucas1p1.samsung.com>
2020-05-19 12:20               ` Lukasz Stelmach
2020-05-19 12:27                 ` Russell King - ARM Linux admin
     [not found]                   ` <CGME20200519125008eucas1p2fe9f14c8f785e956a15097d1eca491c7@eucas1p2.samsung.com>
2020-05-19 12:49                     ` Lukasz Stelmach
2020-05-19 13:12                       ` Russell King - ARM Linux admin
     [not found]                         ` <CGME20200519140211eucas1p24dbc0f54594983731a2dcdd4a943ae27@eucas1p2.samsung.com>
2020-05-19 14:02                           ` Lukasz Stelmach
     [not found]           ` <CGME20200519114657eucas1p156e85218074a7656b93b162e6242bc56@eucas1p1.samsung.com>
2020-05-19 11:46             ` Lukasz Stelmach
2020-05-19 13:56           ` Ard Biesheuvel
2020-05-19 14:28             ` Russell King - ARM Linux admin
2020-05-19 14:32               ` Ard Biesheuvel

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='CAMuHMdV0_GTop+YTPeu+aSFB=1YHsyzLXn-+0fa8upkNMq10bQ@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=chris.brandt@renesas.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=eric.miao@nvidia.com \
    --cc=grant.likely@arm.com \
    --cc=l.stelmach@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.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=robh+dt@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).