Hi Peter, On Mon, 21 Apr 2025 at 11:34, Peter Robinson <pbrobin...@gmail.com> wrote: > > Hi Simon, > > With the other changes in the rpi pull this no longer applies. > > On Fri, 20 Dec 2024 at 00:35, 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. 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?
Yes, I've made a note to do this and should get to it in early Sept. Regards, Simon
