public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, Wolfgang Denk <wd@denx.de>,
	Marek Vasut <marex@denx.de>
Cc: 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: Mon, 2 Aug 2021 17:27:59 -0400	[thread overview]
Message-ID: <20210802212759.GD9379@bill-the-cat> (raw)
In-Reply-To: <1971775f-28de-83d0-9459-a4e68c744a18@siemens.com>

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

On Thu, Jul 29, 2021 at 09:22:02AM +0200, Jan Kiszka wrote:

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
> 
> While the goal is valid and there is surely unused memory in that area,
> we also have a lot of crucial things still located at the top-of-memory
> while running lmb_alloc_base. Such things are the page table (tlb_addr),
> relocated U-Boot and the active stack. Possibly more. So this patch was
> premature, we will need relocations of those things first if we want to
> use the range.
> 
> Fixes booting on the IOT2050, but likely also on other boards. It got 
> stuck on relocating the FDT - over the relocated U-Boot code.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Practically,
> 
> void arch_lmb_reserve(struct lmb *lmb)
> {
> 	lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
> }
> 
> worked as well for me - but it left the stack in danger.

I want to cycle back up to this practically part.  Marek, would changing
the arch_lmb_reserve (or possibly even making this a more global thing /
option) still let the area you want exposed on rcar3 (I assume) be
exposed ?  Or would it be covered again?  Part of the problem,
practically speaking, is that we need to ensure that as part of
(attempting and likely succeeding in) booting the OS we don't overwrite
ourself and hang.

An alternative that I'm not 100% sure I like would be adjusting
env_get_bootm_size() so that the case of bootm_size and bootm_low are
unset, so we figure out a value based on gd->ram_top we also take in to
account where U-Boot itself is atm and exclude that.  It's possible that
if we had something like that at the start of the DT world, we wouldn't
have the code to disable fdt relocation, which really feels like it's
largely been "things crash when we relocate stuff, disable relocation"
and not so much "save a little boot time, we optimized things VERY
CAREFULLY".

-- 
Tom

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

  parent reply	other threads:[~2021-08-02 21:28 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
2021-08-08 13:35                 ` Marek Vasut
2021-08-02 21:27 ` Tom Rini [this message]
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=20210802212759.GD9379@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 \
    --cc=wd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox