Add a way to generate a qcom-flash tarball without a rootfs

[koenkooi]

Some vendors publish a 'boot firmware' artefact and a separate 'OS' artefact to make changing out the rootfs easier. Having something similar for meta-qcom would allow the following scenario:

1. Build the rootfs-free qcomflash.tar.gz for each 'real' machine
2. Build a rooffs using qcom-armv8a machine or qcom-deb-images.
3. Flash!

There is some process to sort out on how and when to populate the ESP, but having a way to easily and quickly build a such a qcom-flash tarball would be a huge improvement.

[ricardosalveti]

This is something we wanted to start enabling us support for generic machines, but I would say that this tool should be available outside meta-qcom, and meta-qcom could consume (or replicate) the steps for the image generated via yocto.

This should be common with the work happening with debian/ubuntu/etc. @lool ^

[lool]

I love it

There is only dependency which is in the wrong direction: dtb.bin/DTB FIT are generated from the kernel dtbs derived from the HLOS rootfs. I personally think that this is wrong for a number of scenarios, but I can also see why in some scenarios it's handy. This part will likely need a f2f discussion with a number of stakeholders, but in the meantime we could start decoupling a bit.

This is the high-level map that qcom-deb-images follows and that I think we could generalize for now:

• HLOS build outputs 1) rootfs and ESP and 2) a tarball with all dtbs; I might be filtering on qcom/*, but if we would take compute into account, that's probably a bad idea, we could include pretty much everything at this stage
• boot firmware "build" outputs per-board tarballs or a tarball with per-board subdirs, notably with per board CDT, pointing to the expected HLOS filenames for flashing

It would be quite generic if in 1) we generated a tarball with ESP and rootfs contents with ESP under boot/efi for instance, and then had scripts to generate the disk image files (for 512B or 4KiB sector sizes) but currently qcom-deb-images depends on the FS UUID in the fstab to mount / though. Perhaps this is not needed with the proper rootfs GUIDs and modern systemd? Not sure.