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

Simon Glass sjg at chromium.org
Mon Dec 16 01:27:22 CET 2024


Hi Peter,

On Wed, 11 Dec 2024 at 09:36, Peter Robinson <pbrobinson at gmail.com> wrote:
>
>
>
> On Mon, 9 Dec 2024 at 19:55, 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.
>
>
> And what about where extlinux isn't used?
>
>>
>> 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.
>
>
> Please re-word the above, it doesn't make sense to me, "the rpi_4 I am using" .... what about the other millions of RPis out there?
>
>>
>> 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.
>
>
> Don't remove it, re-word it so it's up to date.
>
>>
>> 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.
>
>
> The below looks irrelevant to the patch at hand, it looks like it should be in the cover letter.

Do you have any comments on the code in this series?

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

Regards,
Simon


More information about the U-Boot mailing list