[PATCH 00/21] Qualcomm generic board support

[Tom Rini]

On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
> 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).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231122/5188a8b7/attachment.sig>