Hi Simon,
gzip u-boot::
gzip u-boot-nodtb.binAppend 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.