[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Wed, 29 Nov 2023 at 22:06, 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,

That is actually best addressed in Linux by checking the DTS against
yaml DT bindings. We don't have that testing available in u-boot and
only depend on careful reviews.

> > 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).

Okay so let's try an alternative intermediate step then. We import the
Linux DT files *as it is* and then keep the u-boot specific custom
changes in <soc>-u-boot.dtsi file which is included by the board DTS
file. This has been the approach that other u-boot platforms follow
and allow us to easily sync them with Linux while reducing custom
u-boot specific bits. Eventually we should target at dropping u-boot
specific custom bits and then directly pick up DTB from Linux and boot
it.

> >
> >>
> >>>
> >>> 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.

We have to choose the middle-ground carefully here. It shouldn't give
the impression that it is an actual Linux DT that you can pass
directly to Linux via EFI. As otherwise users will hit problems due to
the partially modified DTs in u-boot.

>
> 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.

Once we have the previous loaders (ABL or LK) providing u-boot fully
fledged DTB then we don't need to maintain Linux DT copy in u-boot
which is always a pain to keep in sync.

>
> 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.

See the side effects of an intermediate step mentioned above. Having
<soc>-u-boot.dtsi clearly separates the changes we have to make for
u-boot.

-Sumit

>
> 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)
> >
>