[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Wed, 22 Nov 2023 at 19:31, Tom Rini <trini at 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.connolly at 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