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

[Caleb Connolly]

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

Kind regards,
Caleb

>>>
>>> It's a very valid use case we need to continue to support. And to save
>>> Mark from having to repeat himself, again, it's intentionally and not
>>> changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the
>>> fact that one can use U-Boot this way is part of how engineers get proof
>>> of concept work done to show that if they had U-Boot available then they
>>> could also support X/Y/Z easier. And maybe they'll be able to longer
>>> term push internally to use bloblist to pass things along.
>>>
>>> Heck, trying to not go too far off on a tangent, maybe the m1n1 loader
>>> can implement both conventions, as both Linux Kernel[0] and Bloblist[1]
>>> use x0 for device tree, but bloblist has x1 non-zero and Linux does not,
>>> so both could be present here? Or is there some incompatibility I don't
>>> see on quick skimming?
>>
>> Right.  Some time ago I suggested Simon to lobby the Linux kernel
>> folks to change the arm64 Linux kernel entry convention to state that
>> x1 can be non-zero in which case it points at a bloblist.  If that
>> happened I'd probably do the work to make m1n1 pass a bloblist.  And
>> it would probably make the folks who want to directly boot a Linux
>> kernel from TF-A (without going through U-Boot) happy as well.
> 
> I got a lot of push-back on that. Perhaps there might be some
> willingness if it is explained that Linux doesn't need to understand
> the bloblist, just tolerate it being there. There are probably other
> people who will be more successful at pushing for kernel changes.
> 
> As you know, the handoff protocol is designed such that you don't need
> to decode the bloblist to find the devicetree. BTW I would like to put
> the ACPI/SMBIOS tables in the bloblist as well (with EFI we would
> provide pointers into the bloblist for Linux to use)
> 
> Regards,
> Simon

-- 
// Caleb (they/them)