All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Marek Vasut <marex@denx.de>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Hai Pham <hai.pham.ud@renesas.com>,
	Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>,
	Stephen Warren <swarren@nvidia.com>,
	Lokesh Vutla <lokeshvutla@ti.com>
Subject: Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
Date: Thu, 5 Aug 2021 19:31:03 -0400	[thread overview]
Message-ID: <20210805233103.GS858@bill-the-cat> (raw)
In-Reply-To: <4046119c-c61c-ed49-92e6-dee5f8c67b3c@denx.de>

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

On Thu, Aug 05, 2021 at 11:53:24PM +0200, Marek Vasut wrote:
> On 8/2/21 3:00 PM, Tom Rini wrote:
> > On Mon, Aug 02, 2021 at 02:54:22AM +0200, Marek Vasut wrote:
> > > On 7/29/21 6:58 PM, Tom Rini wrote:
> > > 
> > > [...]
> > > 
> > > > > > so when did rcar3 introduce something there that shouldn't be
> > > > > > reserved?  And you had phrased this to me on IRC as about reserving spot
> > > > > > for ATAGS, and that not being needed of course on arm64.  But that's not
> > > > > > what's going on.  Perhaps the answer is that rcar3 needs to introduce a
> > > > > > board_lmb_reserve to free the normal arch one and provide whatever more
> > > > > > narrow scope it needs.
> > > > > 
> > > > > Based on the commit message 2359fa7a878 ("arm: bootm: Disable LMB
> > > > > reservation for command line and board info on arm64") , this is about ATAGS
> > > > > and we really don't need to reserve those on arm64.
> > > > 
> > > > Commit 2359fa7a878 disables the entire arch_lmb_reserve function on
> > > > aarch64, yes.  I assumed when we had talked that it was a small area
> > > > being set aside and perhaps mis-recalled that ATAGS tended to live at
> > > > DDR_BASE + 0x800 or so.
> > > 
> > > That arch_lmb_reserve() is responsible for reserving architecture specific
> > > memory. On arm32 it is ATAGS, on arm64 it is nothing as far as I can tell
> > > (and see below regarding the TLB).
> > 
> > I don't think that LMB ever covered ATAGS.  ATAGS, I could have sworn,
> > were at start of memory + 0x800 or so.  This LMB is for the top of
> > memory where U-Boot is.
> 
> What is there to protect which Linux does not set up again ?

What does Linux have to do this with?  I don't see, but maybe have
missed, where "U-Boot adds memory region to internal LMB list" is
translated to "Update the device tree Linux will have with these
regions".  I do see code to read the reserved-memory regions from a DTB
and add them to our LMB, but not the other direction.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2021-08-05 23:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29  7:22 [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64" Jan Kiszka
2021-07-29 15:01 ` Marek Vasut
2021-07-29 15:23   ` Tom Rini
2021-07-29 16:47     ` Marek Vasut
2021-07-29 16:58       ` Tom Rini
2021-08-02  0:54         ` Marek Vasut
2021-08-02  9:37           ` Jan Kiszka
2021-08-02 10:48             ` Marek Vasut
2021-08-02 11:36               ` Jan Kiszka
2021-08-02 11:38                 ` Marek Vasut
2021-08-02 11:54                   ` Jan Kiszka
2021-08-02 13:04                     ` Tom Rini
2021-08-02 14:03                       ` Jan Kiszka
2021-08-02 14:27                         ` Tom Rini
2021-08-02 14:34                           ` Jan Kiszka
2021-08-02 14:44                             ` Tom Rini
2021-08-05 21:52                               ` Marek Vasut
2021-08-06 16:43                                 ` Tom Rini
2021-08-02 13:00           ` Tom Rini
2021-08-05 21:53             ` Marek Vasut
2021-08-05 23:31               ` Tom Rini [this message]
2021-08-08 13:35                 ` Marek Vasut
2021-08-02 21:27 ` Tom Rini
2021-08-03 21:51   ` Tom Rini
2021-08-05 22:22     ` Marek Vasut
2021-08-06 16:49       ` Tom Rini
2021-08-08 13:45         ` Marek Vasut
2021-08-08 14:00           ` Tom Rini
2021-08-08 14:28             ` Marek Vasut
2021-08-08 14:54               ` Tom Rini
2021-08-08 15:25                 ` Marek Vasut
2021-08-08 15:57                   ` Tom Rini
2021-08-09  7:34                   ` [EXT] " Ye Li
2021-08-09 13:16                     ` Tom Rini
2021-08-09 14:11                       ` Wolfgang Denk
2021-08-09 14:21                         ` Tom Rini
2021-08-09  6:44               ` Wolfgang Denk
2021-08-09 12:53                 ` Tom Rini
2021-08-08 18:21 ` Tom Rini

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=20210805233103.GS858@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=hai.pham.ud@renesas.com \
    --cc=jan.kiszka@siemens.com \
    --cc=lokeshvutla@ti.com \
    --cc=marex@denx.de \
    --cc=simon.k.r.goldschmidt@gmail.com \
    --cc=swarren@nvidia.com \
    --cc=u-boot@lists.denx.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.