[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

Hi Dennis,

On Wed, 29 Nov 2023 at 22:32, Dennis Gilmore <dgilmore at fedoraproject.org> wrote:
>
> A big benefit of using the full dtb in u-boot means it can be used to
> boot the system without the need to load a replacement file from disk
> or elsewhere, which, AFAIK is required for the System Ready standards
> and it definitely helps in cases like EFI booting.

The discussion here is all focussed on how to reach a point where
u-boot uses unmodified DTB. This would allow the system to be
compliant with System Ready standards with DT being directly passed
from u-boot via EFI config table to Linux.

-Sumit

>
> Dennis
>
> On Wed, Nov 29, 2023 at 10:37 AM Neil Armstrong
> <neil.armstrong at linaro.org> wrote:
> >
> > On 29/11/2023 16:34, Caleb Connolly wrote:
> > >
> > >
> > > On 23/11/2023 07:04, Sumit Garg wrote:
> > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On 22/11/2023 14:27, Tom Rini wrote:
> > >>>> 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?
> > >>>
> > >>> For now, yes.
> > >>
> > >> But why? Is there any value added by larger u-boot specific DT (most
> > >> of the nodes being unused by u-boot) than what currently u-boot
> > >> supports? The more important part is to get alignment with Linux DT
> > >> bindings. If you need to have memory/reserved-memory nodes in u-boot
> > >> DT for generalization purposes then you should import those particular
> > >> nodes only.
> > >
> > > I've been thinking about and hacking on this for the last week or so,
> > > sorry for the delayed reply here.
> > >
> > > The value is in preventing any of the existing bindings from regressing,
> > > and simplifying the bringup process for new platforms (just copy
> > > SoC/PMIC DTSI and write a minimal board DTS to enable the needed hardware).
> > >>
> > >>> There are quite a few features which aren't handled by
> > >>> U-Boot that it shouldn't need to handle (rpm/h resources for example).
> > >>> Also the fixed-regulator / regulator-gpio binding differences.
> > >>
> > >> IMO, we should fix them first and then use Linux DT as it is.
> > >
> > > The biggest blocker here is USB, on sdm845 and the 4 new platforms I
> > > have working, I only support USB high speed, this requires removing the
> > > superspeed phy and adding a DTS property.
> > >
> > > I tried using OF_BOARD_SETUP to make this changes during boot but this
> > > approach really isn't scalable (and I couldn't find a way to make it
> > > work anyway).
> > >
> > >>
> > >>>
> > >>> I would definitely like to move towards supporting Linux DT directly,
> > >>> but this approach gives us a nice middleground of minimising the U-Boot
> > >>> specific DT parts.
> > >>
> > >> I don't see any real benefits here apart from the maintenance burden.
> > >> If it had been an actual Linux DT then that can be passed to Linux as
> > >> it is. However, the current modified import you are trying to do
> > >> doesn't solve that purpose as well.
> > >
> > > Ensuring that we don't introduce non-standard bindings (by using Linux
> > > DTSI) is one benefit, simplifying new platform bringup is another.
> > >
> > > The amount of work required to switch to upstream DT is too much to
> > > block this series on. We can work on improving the situation there once
> > > we have these Qualcomm improvements upstream and new boards added. I do
> > > admit that this is quite an awkward middle-ground, and I would not like
> > > it to last for too long.
> >
> > I'm a real supporter of targeting support of unmodified (or very slighly)
> > Linux DT, having a reduced version of the Linux DT will be a pain at each
> > sync, and you'll need to do this manually.
> >
> > Simply having to copy the Linux DT without any changes will make sure you
> > are in sync with Linux's bindings, and will help making sure you'll boot
> > unchanged Linux DTBs you get from previous loaders.
> >
> > And in bonus, you'll be able to chain it to the next loader like EFI.
> >
> > So I don't see why any work toward this goal is useless, and if an
> > intermediate step is needed, let's do it.
> >
> > Neil
> >
> > >
> > >>
> > >> -Sumit
> > >>
> > >>>>>>>
> > >>>>>>> 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
> > >>>>
> > >>>
> > >>> --
> > >>> // Caleb (they/them)
> > >
> >