Developer options for overriding the firmware in meta-qcom

[mike-scott]

This issue will be used to discuss how each use-case below can be addressed in Qualcomm Linux 2.x while making sure to address various considerations like licensing, versions and SBoM data.

Qualcomm Linux (QLI) developers have three workflows when integrating QCOM firmware into the rootfs image:

1. In QLI 1.x, firmware was pulled from public download areas like Code Linaro or the Qualcomm Software Center. In QLI 2.x, firmware is pulled from the upstream linux-firmware repository. The recipe include used to define various QCOM firmware recipes and what binaries are used in them is here: https://github.com/qualcomm-linux/meta-qcom/blob/master/recipes-bsp/firmware/firmware-qcom.inc. A packagegroup then defines what firmware recipes are required per SoC or machine codename. Example for RB3Gen2: https://github.com/qualcomm-linux/meta-qcom/blob/master/recipes-bsp/packagegroups/packagegroup-rb3gen2.bb.
2. ODMs with HW that requires customized firmware may need to override some of the default firmware pulled from the linux-firmware repo
3. Product makers need to pre-sign ALL of the QCOM firmware in the rootfs with their OEM keys. This requires a mechanism that allows them to override default QCOM firmware in the rootfs with their signed versions. Optionally, QLI could support build time signing of firmware.

The current method for building firmware utilizes the QCOM "metabuild" package. The build output of this package contains 3 .zip files. In the past, QLI 1.x had recipes which would specifically consume these 3 .zip files as part of the Qualcomm Linux build. However 2 of those recipes were deprecated in QLI 1.7 and now it's not obvious how QLI 2.x can consume 2 of the 3 .zip files.

The 3 .zips from the metabuild package are:

1. <SOC>_bootbinaries.zip (Example: QCM6490_bootbinaries.zip): these boot-related artifacts can be overridden using the recipes here: https://github.com/qualcomm-linux/meta-qcom/tree/master/recipes-bsp/firmware-boot (this workflow is currently supported)
2. <SOC>_dspso.zip (Example: QCM6490_dspso.zip): There are no firmware (mbn/mdt) in this artifact, however, it contains libraries for using asdp/cdsp which can be customized by ODMs or product makers. These files are placed under /usr/lib/dsp/ in the rootfs. In QLI 1.x, there was a recipe which allowed a developer to consume this .zip file: https://github.com/qualcomm-linux/meta-qcom-hwe/blob/qcom-6.6.97-QLI.1.6-Ver.1.2.1/recipes-firmware/firmware/firmware-qcom-dspso_1.0.bb. This was replaced with hexagon-dsp-binaries_(date).bb which pulls these binaries from a public Github Repo: https://github.com/linux-msm/hexagon-dsp-binaries/. This is not a clearly defined operation.
3. <SOC>_fw.zip (Example: QCM6490_fw.zip): This artifact contains firmware and libraries which are added to the rootfs (as opposed to the boot binaries firmware). In QLI 1.x, there was a recipe which allowed a user to override with their own .zip file: https://github.com/qualcomm-linux/meta-qcom-hwe/blob/qcom-6.6.97-QLI.1.6-Ver.1.2.1/recipes-firmware/firmware/firmware-qcom-hlosfw_1.0.bb. Currently, there is no direct replacement for the older way of integrating the fw.zip artifacts.

Considerations:

• Maintain license and version differences between the linux-firmware files and overridden files
• SBOM should reflect the correct package name and version that is actually added to the build
• Product makers should not be required to build Qualcomm Linux in order to sign their firmware. The QCOM OEM keys should rarely leave a secure location. Currently, a pre-signing behavior is preferred as this keeps the use of these keys to a minimum and it has a low barrier of entry (as opposed to integrating remote signing capability into the build). NOTE: A downside to pre-signing is that outdated firmware (signed) will be used even when newer upstream firmware is available. The advantage to this workflow is that all builds will immediately work on secure boot enabled HW.