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

[Peter Robinson]

Hi Simon,

With the other changes in the rpi pull this no longer applies.

On Fri, 20 Dec 2024 at 00:35, Simon Glass <sjg at chromium.org> 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.

I'm not sure the context of the two paragraphs, they seem to conflict
with each other.

> So use the control-FDT address instead.

The RPi is interest as we have different DTs, the one the firmware
provides, which is useful as it deals with things like overlays, the
U-Boot one we've typically not used or one loaded from disk which is
generally the upstream Linux kernel one, how does this change address
that? I have concerns this will change the logic overall. Does it?

> 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.

Could you answer my query above and rebase?

Thanks,
Peter

> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
> 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)
> --
> 2.34.1
>