Support creating a single tarball with all the image artifacts used during flashing

[ricardosalveti]

In addition to kernel and rootfs, we also require several other binaries and files in order to flash the complete image, and it is a bit of a pain to distribute all files outside the yocto build environment.

Support creating a single tarball that contains everything needed to perform a full flash of the device, similar to how it is done on meta-tegra (tegraflash: https://github.com/OE4T/meta-tegra/blob/master/classes-recipe/image_types_tegra.bbclass).

We experimented with a similar approach in foundries, creating a so called qcomflash file, which can be found at https://github.com/foundriesio/meta-partner/blob/qualcomm/classes/image_types_qcom.bbclass#L41.

This would allow us to distribute a single tarball which contains everything needed to perform a full flash of the device.

[mwasilew]

I guess one caveat for Foundries tarball is that included qdl doesn't work (wrong interpreter). Maybe qdl should not be shipped as a part of tarball?

[ndechesne]

is that because we include an arm native binary of qdl? if so, we probably want to distribute both an arm and x86 versions? or we can let qdl installation up to the user on the host.

for ubuntu there is a snap, btw, so for most users it is straighforward to install the snap package. it is kept up to date (and fwiw, I have write/maintainer permission on this snap)

[mwasilew]

It's x86 binary, but the interpreter comes from OE build:

$ file qdl 
qdl: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /srv/oe/build/tmp-lmp_xwayland/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=d6988c2f9118520037982e0812c675f58b69b442, for GNU/Linux 3.2.0, stripped

[ndechesne]

ok, then we should not ship it. it might be included in an SDK, if we ever have one.

[quaresmajose]

We need to fix the OE interpreter issue and also try to link the qdl statically

[ndechesne]

You cannot 'fix' the OE interpreter issue, without doing an SDK, can you? when you compile qdl as a host package, it will be built to be executed in the context of the OE/bitbake build. We need to build the sdk variant (canary build) to be able to use the binary outside of bitbake.

I don't think we should deliver qdl. it's a flashing tool, and it's ok to ask the user to install it. Also, this is a very Yocto centric solution, we intend to support Debian and more anyways. I even believe we should split out the 'boot/system firmware' away from the Yocto build, and have a standalone boot firmware package/product per device instead, as we briefly discussed last week. Not an immediate goal, but something on our radar.

[ricardosalveti]

I guess one caveat for Foundries tarball is that included qdl doesn't work (wrong interpreter). Maybe qdl should not be shipped as a part of tarball?

It was removed already in the 1.2 updates.

[ricardosalveti]

We need to fix the OE interpreter issue and also try to link the qdl statically

We tried, won't work because of the dependencies, better to just drop.