[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

Hi Simon,

On Tue, 5 Dec 2023 at 06:22, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Sumit,
>
> On Tue, 21 Nov 2023 at 23:21, Sumit Garg <sumit.garg at linaro.org> wrote:
> >
> > Hi Caleb,
> >
> > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> > >
> > > Historically, Qualcomm boards in U-Boot have all had their own
> > > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > > devicetree with little/no compatibility with upstream DT.
> > >
> > > This series makes a few final prepatory changes, and then replaces
> > > almost all of the board specific code with generic alternatives. The end
> > > result is that all Qualcomm boards both current and future (with the
> > > exception of the db410c and db820c) can be supported by a single U-Boot
> > > binary by just providing the correct DT. New boards can be added without
> > > introducing any addition mach/ or board/ code or config options.
> > >
> > > Due to the nature of this change, the patch ("mach-snapdragon:
> > > generalise board support") has become pretty big, I tried a few
> > > different ways to represent this in git history, but the other methods
> > > (e.g. adding a stub "generic" target and removing it again) were more
> > > confusing and made for much messier git history. The current patch is
> > > mostly atomic, but requires regenerating the config.
> > >
> > > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > > this is dropped in favour of a adding a new vbus-supply property to the
> > > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > > future patch. This handles the common case of a board requiring some
> > > regulator be enabled for USB host mode.
> > >
> >
> > Thanks for your work. It is a good step towards a generalized u-boot
> > on Qcom platforms. Although I would like to give it an in-depth
> > review, I have a common discussion point about DT, see below.
> >
> > > A more detailed description of the changes is below.
> > >
> > > == Memory map ==
> > >
> > > The memory map was historically hardcoded into U-Boot, this meant that
> > > U-Boot had to be built for a specific variant of a device. This is
> > > changed to instead read the memory map from the DT /memory node.
> > >
> > > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > > null pointer access happens then it will cause a bus stall (and board
> > > hang). This is fixed so that null pointer accesses will now correctly
> > > throw an exception.
> > >
> > > == 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
>
> What is this?? Who or what uses a gzipped image with a single DT attached?

The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
LK). It is the usual way Linux is booted on these platforms. U-boot is
being brought into this chain to leverage standardized EFI boot
processes.

>
> >
> > 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.
>
> That is not the current situation, unfortunately.
>

Hopefully with efforts from Caleb and team we can reach that point soon.

> U-Boot is moving to using Binman to package the firmware. There needs
> to be a description of the firmware image for each U-Boot boot. To my
> way of thinking, rpi is a degenerate form, not something to be copied,
> due to the closed-source nature of the firmware and its inability to
> be changed. We do have (in the works) a way to pass a DT using a
> standard firmware handoff. Perhaps that can be adopted by these
> closed-source projects?

Why should we really need firmware handoff if the DT can be passed in
one of the u-boot boot arguments? Linux kernel does support this
method to retrieve DT as well.

>
> BTW I am very pleased to see this series and I hope that Qualcomm (via
> Linaro) can continue to improve its U-Boot support.

It's good to know, thanks.

-Sumit

>
> [..]
>
> Regards,
> Simon