From: "Jaehoon Chung" <jh80.chung@samsung.com>
To: "'Simon Glass'" <sjg@chromium.org>,
"'U-Boot Mailing List'" <u-boot@lists.denx.de>
Cc: "'Tom Rini'" <trini@konsulko.com>,
"'Stephen Warren'" <swarren@wwwdotorg.org>,
"'Stephen Warren'" <swarren@nvidia.com>,
"'Matthias Brugger'" <mbrugger@suse.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 v3 5/5] rpi: Use the U-Boot control FDT for fdt_addr
Date: Tue, 10 Dec 2024 20:17:30 +0900 [thread overview]
Message-ID: <0b9401db4af5$1a2029c0$4e607d40$@samsung.com> (raw)
In-Reply-To: <20241209195528.730260-6-sjg@chromium.org>
> -----Original Message-----
> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Simon Glass
> Sent: Tuesday, December 10, 2024 4:55 AM
> To: U-Boot Mailing List <u-boot@lists.denx.de>
> Cc: Tom Rini <trini@konsulko.com>; Stephen Warren <swarren@wwwdotorg.org>; Stephen Warren
> <swarren@nvidia.com>; Matthias Brugger <mbrugger@suse.com>; Simon Glass <sjg@chromium.org>; 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: [PATCH v3 5/5] rpi: Use the U-Boot control FDT for fdt_addr
>
> The fdt_addr variable is used in extlinux as a fallback devicetree if
> none is provided by the boot command.
>
> The existing mechanism uses the devicetree provided to U-Boot, but in
> its original, unrelocated position. For the rpi_4 I am using, this is
> 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.
>
> In version 2, it incorporates some changes to fdt_addr, etc. suggested
> by Tom, as well as adding myself as a maintainer.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Drop patch to allow expanding the devicetree during relocation
>
> board/raspberrypi/rpi/rpi.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 9122f33d88d..8f6ab1b1b9b 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>
> @@ -325,19 +327,10 @@ static void set_fdtfile(void)
> env_set("fdtfile", fdtfile);
> }
>
> -/*
> - * 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 */
> 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);
> }
>
> /*
> @@ -572,7 +565,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)
> --
> 2.34.1
next prev parent reply other threads:[~2024-12-10 11:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 19:55 [PATCH v3 0/5] rpi: Tidy up booting Simon Glass
2024-12-09 19:55 ` [PATCH v3 1/5] rpi: Add myself to the list of maintainers Simon Glass
2024-12-09 23:02 ` Peter Robinson
2024-12-09 19:55 ` [PATCH v3 2/5] rpi: Set bootm_size to 512MB Simon Glass
2024-12-10 11:16 ` Jaehoon Chung
2024-12-11 16:27 ` Peter Robinson
2024-12-11 16:57 ` Tom Rini
2024-12-11 17:26 ` Simon Glass
2024-12-16 15:16 ` Simon Glass
2024-12-09 19:55 ` [PATCH v3 3/5] rpi: Drop fdt_high and initrd_high Simon Glass
2024-12-10 11:16 ` Jaehoon Chung
2024-12-09 19:55 ` [PATCH v3 4/5] rpi: Update environment to support booti and large initrd Simon Glass
2024-12-10 11:17 ` Jaehoon Chung
2024-12-09 19:55 ` [PATCH v3 5/5] rpi: Use the U-Boot control FDT for fdt_addr Simon Glass
2024-12-10 11:17 ` Jaehoon Chung [this message]
2024-12-11 16:36 ` Peter Robinson
2024-12-16 0:27 ` Simon Glass
2024-12-18 16:26 ` Peter Robinson
2025-01-09 15:07 ` 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='0b9401db4af5$1a2029c0$4e607d40$@samsung.com' \
--to=jh80.chung@samsung.com \
--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 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.