Hi Simon.
On Mon, 16 Dec 2024 at 00:27, Simon Glass <s...@chromium.org> wrote:
> Hi Peter,
>
> On Wed, 11 Dec 2024 at 09:36, Peter Robinson <pbrobin...@gmail.com> wrote:
> >
> >
> >
> > On Mon, 9 Dec 2024 at 19:55, Simon Glass <s...@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?
>
I did already comment on it, please go back through your emails ;-)
> >
> >>
> >> 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 <s...@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
>
