[PATCH 00/21] Qualcomm generic board support

[Simon Glass]

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?

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

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?

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

[..]

Regards,
Simon