Hi Caleb, On Tue, 24 Oct 2023 at 11:10, Caleb Connolly <caleb.conno...@linaro.org> wrote: > > > > On 24/10/2023 19:03, Simon Glass wrote: > > Hi Caleb, > > > > On Tue, 24 Oct 2023 at 04:32, Caleb Connolly <caleb.conno...@linaro.org> > > wrote: > >> > >> Add a new config option to allow u-boot to reuse the FDT provided by the > > > > U-Boot (please fix throughout) > > Will do! > > > >> previous stage bootloader when available. > >> > >> On some boards the previous stage bootloader can populate > >> platform-specific parts of the devicetree such as the memory node, this > >> allows us to avoid hardcoding it in u-boot and instead determine it > >> dynamically at runtime. > >> > >> Signed-off-by: Caleb Connolly <caleb.conno...@linaro.org> > >> --- > >> This patch will improve generic support for Qualcomm boards by enabling > >> us to configure the memory map at runtime rather than having hardcoded > >> maps on a per-device basis. I've gone for this approach initially to try > >> and avoid introducing board specific code where possible, but I'm happy > >> to rework this into mach-snapdragon if that's preferred. > > > > Do you think it could use bloblist instead? I did send a patch to use > > the FDT in the bloblist: > > If it would require changes to the previous stage bootloader then > unfortunately not. We're mostly stuck with the behaviour that we've got > for now...
Yes it would. What is the previous-stage bootloader? > > This mechanism of retrieving the DTB is also used on the apple M1 I > think, and any other board where we're booting U-Boot as a drop-in for > the kernel on arm64. I believe M1 is an open source project so perhaps they could adopt firmware handoff when it is finalised. Anyway, can this use OF_BOARD instead, perhaps? It already permits board-specific actions and is used by some rpi boards. > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230926141514.2101787-40-...@chromium.org/ > > > > Regards, > > Simon > > Regards, Simon