[PATCH 00/21] Qualcomm generic board support

[Simon Glass]

Hi Sumit,

On Tue, 5 Dec 2023 at 00:44, Sumit Garg <sumit.garg at linaro.org> wrote:
>
> 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.

LK is Little kernel, I believe. That is an open source project, right?
But I suppose it is BSD licensed so in fact the code is not available?
Is ABL obsolete?

I'm not sure that it matters in any case. We should be able to
standardise the U-Boot part and let the private projects implement
that, for a seamless boot.

What you have written above is not a good way for U-Boot to be
packaged or invoked.

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

Here I am not referring to Linux, but to the firmware stages. We need
firmware handoff so all these nutty binaries around the place can
communicate with the open source (firmware) projects in a sensible
fashion.

For Linux we can pass the DT using existing mechanisms.

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

It is the hiding of the DT that I object to. I would like to see these
files in U-Boot, so we can build U-Boot for the platform and boot it
with its local DT. Otherwise many of the innovations U-Boot provides,
such as firmware packaging, become impossible. My feeling on this
might change if the bindings process were easier.

Regards,
Simon