From: Christopher Obbard <christopher.obbard@linaro.org>
To: Simon Glass <sjg@chromium.org>,
U-Boot Mailing List <u-boot@lists.denx.de>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Stephen Warren <swarren@nvidia.com>,
Matthias Brugger <mbrugger@suse.com>,
Tom Rini <trini@konsulko.com>,
Francois Berder <fberder@outlook.fr>,
"Ivan T. Ivanov" <iivanov@suse.de>,
Patrick Rudolph <patrick.rudolph@9elements.com>,
Peter Robinson <pbrobinson@gmail.com>,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: Re: [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr
Date: Sun, 30 Mar 2025 15:07:25 +0100 [thread overview]
Message-ID: <ac7234cc70a2bf7eee2ce12213cf1f170d58b54f.camel@linaro.org> (raw)
In-Reply-To: <20241220003447.2913443-6-sjg@chromium.org>
Hi Simon,
[resending as I used the wrong e-mail address which isn't on the list,
oops]
On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> The fdt_addr variable is used in extlinux as a fallback devicetree if
> none is provided by the boot command. Otherwise the only use in U-
> Boot
> seems to me efi_install_fdt() when the internal FDT is required.
>
> The existing mechanism uses the devicetree provided to U-Boot, but in
> its original, unrelocated position. In my testing on an rpi_4, this
> ends
> up at 2b35ef00 which is not a convenient place in memory, if the
> ramdisk
> is large.
>
> U-Boot already deals with this sort of problem by relocating the FDT
> to a safe address.
>
> So use the control-FDT address instead.
>
> Remove the existing comment, which is confusing, since the FDT is not
> actually passed unmodified to the kernel: U-Boot adds various things
> using its FDT-fixup mechanism.
>
> Note that board_get_usable_ram_top() reduces the RAM top for boards
> with
> less RAM. This behaviour is left unchanged as there is no other
> mechanism for U-Boot to handle this.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G
> ---
>
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
>
> Changes in v2:
> - Drop patch to allow expanding the devicetree during relocation
>
> board/raspberrypi/rpi/rpi.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c
> b/board/raspberrypi/rpi/rpi.c
> index c46fe4b2350..f74006e0968 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -3,6 +3,8 @@
> * (C) Copyright 2012-2016 Stephen Warren
> */
>
> +#define LOG_CATEGORY LOGC_BOARD
> +
> #include <config.h>
> #include <dm.h>
> #include <env.h>
> @@ -326,18 +328,13 @@ static void set_fdtfile(void)
> }
>
> /*
> - * If the firmware provided a valid FDT at boot time, let's expose
> it in
> - * ${fdt_addr} so it may be passed unmodified to the kernel.
> + * Allow U-Boot to use its control FDT with extlinux if one is not
> provided.
> + * This will then go through the usual fixups that U-Boot does,
> before being
> + * handed off to Linux
> */
> static void set_fdt_addr(void)
> {
> - if (env_get("fdt_addr"))
> - return;
> -
> - if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
> - return;
> -
> - env_set_hex("fdt_addr", fw_dtb_pointer);
> + env_set_hex("fdt_addr", (ulong)gd->fdt_blob);
> }
>
> /*
> @@ -571,7 +568,10 @@ int ft_board_setup(void *blob, struct bd_info
> *bd)
> {
> int node;
>
> - update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
> + if (blob == gd->fdt_blob)
> + log_debug("Same FDT: nothing to do\n");
> + else
> + update_fdt_from_fw(blob, (void *)gd->fdt_blob);
>
> node = fdt_node_offset_by_compatible(blob, -1, "simple-
> framebuffer");
> if (node < 0)
next prev parent reply other threads:[~2025-03-30 14:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 0:34 [PATCH v4 0/5] rpi: Tidy up booting Simon Glass
2024-12-20 0:34 ` [PATCH v4 1/5] rpi: Add myself to the list of maintainers Simon Glass
2025-03-30 13:37 ` Christopher Obbard
2025-04-21 10:09 ` Peter Robinson
2025-05-23 20:20 ` Simon Glass
2024-12-20 0:34 ` [PATCH v4 2/5] rpi: Set bootm_size to 512MB Simon Glass
2025-03-30 13:35 ` Christopher Obbard
2025-04-21 10:09 ` Peter Robinson
2024-12-20 0:34 ` [PATCH v4 3/5] rpi: Drop fdt_high and initrd_high Simon Glass
2025-03-30 13:35 ` Christopher Obbard
2025-03-30 14:07 ` Christopher Obbard
2025-04-21 10:10 ` Peter Robinson
2024-12-20 0:34 ` [PATCH v4 4/5] rpi: Update environment to support booti and large initrd Simon Glass
2025-03-30 13:35 ` Christopher Obbard
2025-03-30 14:07 ` Christopher Obbard
2025-04-21 10:09 ` Peter Robinson
2024-12-20 0:34 ` [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr Simon Glass
2025-03-30 13:36 ` Christopher Obbard
2025-03-30 14:07 ` Christopher Obbard [this message]
2025-04-21 10:34 ` Peter Robinson
2025-05-23 20:20 ` Simon Glass
2025-01-15 14:09 ` [PATCH v4 0/5] rpi: Tidy up booting Simon Glass
2025-01-30 19:54 ` Simon Glass
2025-02-03 3:41 ` Peter Robinson
2025-03-30 13:29 ` Christopher Obbard
2025-03-30 15:03 ` Christopher Obbard
2025-04-01 15:51 ` Simon Glass
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=ac7234cc70a2bf7eee2ce12213cf1f170d58b54f.camel@linaro.org \
--to=christopher.obbard@linaro.org \
--cc=fberder@outlook.fr \
--cc=iivanov@suse.de \
--cc=mbrugger@suse.com \
--cc=patrick.rudolph@9elements.com \
--cc=pbrobinson@gmail.com \
--cc=rasmus.villemoes@prevas.dk \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox