[PATCH 00/21] Qualcomm generic board support

[Caleb Connolly]

Hi Simon,

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

Realistically we aren't in a position to change the bootflow on Qualcomm
boards. This may well change in the future, but for now this is the best
we can do.

On a personal note, I work on a project called postmarketOS, we try to
run upstream Linux and a fully FOSS userspace on phones. I support a few
Qualcomm devices there, and currently the biggest annoyance has been the
bootloader. We can't change it, most OEMs don't care, we're stuck with it.

Below is the MR prototyping UEFI booting postmarketOS with systemd-boot
and U-Boot. This will let us do kernel rollbacks, multi-boot with other
distros, and all the fun things that UEFI gets us. Only because of the
bringup work done here, and (until someone finds an exploit) this is
possible only using the boot mechanism explained by Sumit above.

https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4599

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

I agree, of course it would be great to have U-Boot be a first-class
citizen on Qualcomm devices, but supporting this (admittedly very wonky)
bootflow doesn't exclude that possibility. I very much hope we'll see
some better options for devices going forwards.
> 
-- 
// Caleb (they/them)