On Wed, 22 Nov 2023 at 19:31, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > Hi Caleb, > > > > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.conno...@linaro.org> > > wrote: > [snip] > > > == DT loading == > > > > > > Previously, boards used the FDT blob embedded into U-Boot (via > > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary > > > bootloader, so we can instead rely on the first-stage bootloader to > > > populate some useful FDT properties for us (notably the /memory node and > > > KASLR seed) and fetch the DTB that it provides. Combined with the memory > > > map changes above, this let's us entirely avoid configuring the memory > > > map explicitly. > > > > Since with this change, we don't need to embed FDT blob in the u-boot > > binary, so I was thinking if we really need to import DTs from Linux > > for different platforms and then play a catchup game? > > > > IMO, the build command would look like following if we import > > pre-built FDT blob from Linux: > > > > - Build u-boot:: > > > > $ export CROSS_COMPILE=<aarch64 toolchain prefix> > > $ make qcom_defconfig > > $ make > > > > - gzip u-boot:: > > > > gzip u-boot-nodtb.bin > > > > - Append dtb to gzipped u-boot:: > > > > cat u-boot-nodtb.bin.gz > > <linux-tree>/arch/arm64/boot/dts/qcom/your-board.dtb > > > u-boot-nodtb.bin.gz-dtb > > > > This would avoid the maintenance burden to keep DT in sync with that > > of Linux. And since DT bindings in Linux are backwards compatible, we > > can say u-boot should work with DTB picked up from any Linux kernel > > stable release. > > I guess one question I have is, are we being passed the device tree > (since we're acting like the Linux Kernel)
Yeah that is the case here, see patch #1 in this series regarding how FDT address is being retrieved from previous stage bootloader (ABL on sdm845 and qcs404 SoCs). > or knowing that we have the > dtb attached to the end of us and making use of the old kernel appended > dtb option? We're fine in for example the rpi_arm64 case of just being > given a device tree from the previous stage and not needing one in-tree. > That's good to know and we can replicate that for Qcom platforms which are chainloaded and don't need an embedded DT. -Sumit > -- > Tom