[PATCH v3 4/8] dts: Add alternative location for upstream DTB builds

[Simon Glass]

Hi Caleb,

On Tue, Jan 2, 2024 at 5:51 AM Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
> [snip]
> >>>
> >>>>> However, I am very much in favour of having a generalized U-Boot
> >>>>> image. This might become true in some cases like U-Boot acts as a
> >>>>> second stage bootloader for a particular SoC which is a unified image
> >>>>> where the prior stage passes the DT to it. The Qcom effort in this
> >>>>> direction can be an example here.
> >>>>
> >>>> Not relevant to the topic at hand, perhaps, but Qualcomm uses a
> >>>> closed-source blob to jump to U-Boot and is certainly not an example
> >>>> we should emulate. But yes, passing a DT to U-Boot proper can be
> >>>> useful.
>
> Just to chime in here, this limitation is true for production Qualcomm
> devices where all of the bootloader blobs are signed by the OEM (true
> for most phones). But for development platforms we can do better. I
> expect this is a topic we will keep on coming back to, so I'd like to
> just take the time to explain some of the technical details on Qualcomm
> platforms, as there is a lot more nuance than you might be aware of.
>
> The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 ->
> sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL
> (LinuxLoader.efi app) -> Linux
>
> On production devices the best we can do is replace "Linux" with U-Boot,
> and if we're lucky then we can leverage features of ABL to simplify
> things like DTB selection (it supports picking from a bunch of
> concatenated DTBs, but we can just as easily implement some similar
> feature in U-Boot ourselves).
>
> On a development board I have been successful in replacing the
> hypervisor with a stub and replacing XBL_Core with U-Boot - giving us
> EL2 and removing the entire proprietary UEFI stack. There is no reason
> that we can't go further than this.
>
> The Qualcomm Chromebooks all run Coreboot, for sure on those it would be
> possible to use U-Boot much earlier (although there is still the
> proprietary XBL_Sec TZ blob).
>
> The Dragonboard410c (and MSM8916 SoC overall) has been pretty much
> entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline
> project. On these devices it is easily possible to run U-Boot as a
> first-stage bootloader (at least to the same extent one can on the more
> open ARM platforms, or even more open if you wish). Although the
> bootloader of choice for most of these devices is a home-grown fork of lk.
>
> For new SoCs, with the number of Qualcomm devices out there, and
> communities like postmarketOS enabling support on so many of them... My
> hope is that we will quickly see phones being the most common Qualcomm
> devices supported by U-Boot. While it is indeed extremely unfortunate
> that we can't replace the bootloader entirely, using U-Boot as a fresh
> slate is still extremely liberating (EFI! Firmware updates! No need for
> distro hacks to update the kernel! Multi-boot! etc...). I wish we could
> focus more on how U-Boot will make supporting Linux on these devices SO
> SO much easier, and less on how broken the (usually impossible to
> modify) bootloader they shipped with is.
>
> While almost all of the boot chain I explained above is proprietary, the
> ABL source code is publicly available (although most device vendors
> don't publish their modified production version, I suppose for fear of
> embarrassment). The statement "Qualcomm uses a closed-source blob to
> jump to U-Boot" is at the very least an oversimplification.
>
> To be contrarian, here is an example of a phone vendor who do publish
> their ABL source code, here is the code that runs Linux (or U-Boot in
> our case).
>
> https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x/QcomModulePkg/Library/BootLib/BootLinux.c#L1039
>
> My point is, there is a lot of nuance and complexity here, and we need
> to be careful about what exactly we're referring to.

Thank you very much for the information, it is a great read. Yes my
comment was wide of the mark and I am pleased to hear it.

BTW, I would very much like to see Linaro ensuring that new 96boards
have open source firmware before they are released. Before release
seems to be the only time that the vendor can devote time to it.

Regards,
Simon