From: Simon Glass <sjg@chromium.org>
To: Fangsuo Wu <tiger20081015@gmail.com>, Tom Rini <trini@konsulko.com>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: Possiable memory conflict with fdt memory region
Date: Thu, 27 Jan 2022 08:06:00 -0700 [thread overview]
Message-ID: <CAPnjgZ1_rZ7QF6DUA9982G8W24HzJU615LSpgxZ4wKqXDX6NdQ@mail.gmail.com> (raw)
In-Reply-To: <CAMDn9+SxqB2QUsgaN9P5_pBMRSzGQJpCvCs72OR1OTQzLvQ-Jw@mail.gmail.com>
Hi Fangsuo,
On Mon, 27 Dec 2021 at 09:31, Fangsuo Wu <tiger20081015@gmail.com> wrote:
>
> Hi, in image_setup_linux(),
> stage 1: Boot_fdt_add_mem_rsv_regions() is called first to add the mem
> reserve regions which prevents u-boot from using them to store the
> initrd or the fdt blob;
> stage 2: Then boot_relocate_fdt() is called to reserve or alloc fdt
> blob from the avaiable lmb region.
>
> But it seems at stage 1 it doesn't cover up all mem reserve regions.
> For example, if CMD_PSTORE is configured, fdt_fixup_pstore(blob) will
> add pstore to reserved-memory node in fdt in image_setup_libfdt()
> after stage 2 , which may conflict with fdt memory region and can't be
> detected since fdt_fixup_pstore doesn't call lmb_reserve(lmb, pstrore
> addr, pstore len).
>
> In image_setup_libfdt, there are also other functions like
> ft_board_setup which may change existing reserved memory node's size
> and lead to the same issue.
>
> Do you think a common function is needed before
> boot_fdt_add_mem_rsv_regions() in stage 1? The function can be used to
> fix-up or add new reserved memory nodes. Thanks.
+Tom Rini
Possibly. I am not an expert on this, but perhaps send a patch?
Regards,
Simon
prev parent reply other threads:[~2022-01-27 15:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-27 11:10 Possiable memory conflict with fdt memory region Fangsuo Wu
2022-01-27 15:06 ` Simon Glass [this message]
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=CAPnjgZ1_rZ7QF6DUA9982G8W24HzJU615LSpgxZ4wKqXDX6NdQ@mail.gmail.com \
--to=sjg@chromium.org \
--cc=tiger20081015@gmail.com \
--cc=trini@konsulko.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.