On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > 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).
That's what I thought. > > 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. So yes, moving these towards the direction of rpi_arm64 and specifically using imply OF_HAS_PRIOR_STAGE or select OF_HAS_PRIOR_STAGE (force that the dtb must be provided to us) sounds like the right direction to take these platforms. -- Tom
signature.asc
Description: PGP signature
