[PATCH v3 5/5] rpi: Use the U-Boot control FDT for fdt_addr

Jaehoon Chung jh80.chung at samsung.com
Tue Dec 10 12:17:30 CET 2024



> -----Original Message-----
> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Simon Glass
> Sent: Tuesday, December 10, 2024 4:55 AM
> To: U-Boot Mailing List <u-boot at lists.denx.de>
> Cc: Tom Rini <trini at konsulko.com>; Stephen Warren <swarren at wwwdotorg.org>; Stephen Warren
> <swarren at nvidia.com>; Matthias Brugger <mbrugger at suse.com>; Simon Glass <sjg at chromium.org>; Francois
> Berder <fberder at outlook.fr>; Ivan T. Ivanov <iivanov at suse.de>; Patrick Rudolph
> <patrick.rudolph at 9elements.com>; Peter Robinson <pbrobinson at gmail.com>; Rasmus Villemoes
> <rasmus.villemoes at 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 at chromium.org>

Reviewed-by: Jaehoon Chung <jh80.chung at samsung.com>
Tested-by: Jaehoon Chung <jh80.chung at 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





More information about the U-Boot mailing list