[PATCH 00/21] Qualcomm generic board support

[Simon Glass]

Hi Caleb,

On Tue, 5 Dec 2023 at 03:55, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
>
>
> On 05/12/2023 07:44, Sumit Garg 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:
> [...]
> >>>> == 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.
>
> Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm
> boards/devices are in right now (with the exception of db410c), with
> production devices we can't modify the bootloader without vendors
> releasing their signing keys.

Or perhaps a shim? It would be good if vendors could provide an unlock
mechanism eventually, but I understand it is challenging.

>
> For devices that haven't been locked with vendor keys ("Secureboot off"
> in Qualcomm terminology, note that this has nothing to do with UEFI
> secureboot) we can work towards replacing the bootloader entirely with
> U-Boot, I have done a PoC of this on SDM845. In that case, we have to
> embed the DTB into U-Boot.

OK, I see, that sounds good. My concern is that the open source
approach is preserved and made the easiest option. Decisions which
accommodate private binaries while making open source harder should
generally be rejected.

> >
> >>
> >>>
> >>> 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.
>
> Unfortunately the chances of Qualcomm releasing bootloader updates to
> adopt a standard for chainloading U-Boot on their wholely deprecated
> platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no
> reason to care, and may not even be around anymore) apply these patches
> to their own hacked up fork of the bootloader and ship it to end-users
> is honestly even less likely than OEMs releasing the signing keys for
> devices they don't support anymore.

Yes, I understand it is challenging. Somehow it works better with
Linux, despite hacked up kernels, etc. so perhaps Linaro can help
here?

Regards,
Simon