recipes-ml: Add recipe for QAIRT SDK #1412

tjamula · 2026-01-20T11:07:11Z

This PR adds a new bitbake recipe for integrating the QAIRT SDK (v2.41.0.251128) into the build system.

These are pre built binaries and more information about the SDK can be found at : QAIRT overview

koenkooi

Nit: there's no such thing as 'Yocto recipes', it's either 'bitbake recipes' or 'OE recipes'.

koenkooi · 2026-01-20T12:20:58Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+def platform_dir(d):
+    sdk_lib_dir = d.getVar("S", True) + "/lib/"
+    if os.path.exists(sdk_lib_dir) and os.path.isdir(sdk_lib_dir):
+        dir_prefix = "aarch64-oe-linux-gcc"


Don't hardcode TARGET_VENDOR to '-oe' here, it will break on any distro that sets it.

The folder names such as aarch64-oe-linux-gcc* come directly from the upstream SDK ZIP.
These directories are not generated by us and are not derived from TARGET_VENDOR.
They are fixed names in the binary SDK delivered externally.
The SDK ships multiple target‑specific folders, for example:

aarch64-android
aarch64-oe-linux-gcc8.2
aarch64-oe-linux-gcc9.3
aarch64-oe-linux-gcc11.2
aarch64-ubuntu-gcc9.4
aarch64-windows-msvc
android
arm64x-windows-msvc
x86_64-linux-clang
x86_64-windows-msvc

Since these names are SDK‑defined, the recipe must select and install the correct library folder based on the target we are building for.

What approach would you recommend for selecting the appropriate SDK directory based on the target?

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

koenkooi · 2026-01-20T12:22:19Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+    cp -r ${S}/bin/${PLATFORM_DIR}/* ${D}/${bindir}
+}
+
+INHIBIT_PACKAGE_STRIP = "1"


Add a comment why these are needed.

Updated with the comments.

koenkooi · 2026-01-20T12:22:55Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+
+INSANE_SKIP_${PN} += "arch"
+
+SOLIBS = ".so"


This and all the lines below need extensive comments in the recipe itself explaining why the defaults don't work.

Updated with the comments.

lumag

Commit message doesn't exist. It must.

lumag · 2026-01-20T22:44:37Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

@@ -0,0 +1,66 @@
+LICENSE = "Proprietary"


No. Please define and/or provide more exact licence.

The SDK can be downloaded from:
https://softwarecenter.qualcomm.com/api/download/software/sdks/Qualcomm_AI_Runtime_Community/All/2.41.0.251128/v2.41.0.251128.zip

The corresponding license file is located at:
${UNPACKDIR}/qairt/${PV}/LICENSE.pdf

Given that the license is explicitly provided within the SDK, what would you recommend using as the LICENSE value instead of Proprietary?

Define new non-generic licence type, see NO_GENERIC_LICENSE. Also please add licence in the text format.

The current SDK does not include the license in a plain text format. I’ve raised this issue with the QAIRT team, but even if they decide to add a .txt version, it will only come in their next release, which may take 1–2 months.

This license seems to be AI specific, so won't be LICENSE.qcom and LICENSE.qcom-2, needs to be yet another license for qualcomm, specific to AI.

lumag · 2026-01-20T22:45:50Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+
+HEXAGON_VERSION = "v68"
+HEXAGON_VERSION:qcs9100 = "v73"
+HEXAGON_VERSION:qcs8300 = "v75"


No. Please see how it's done for FastRPC. No target-specific packages are allowed.

In our case, the SDK we are integrating ships multiple prebuilt, mutually exclusive, target‑specific library directories, such as:
hexagon-v66
hexagon-v68
hexagon-v69
hexagon-v73
hexagon-v75
hexagon-v79
hexagon-v81

Since only one of these is valid for the target we are building for, the recipe does need some logic to select the correct directory otherwise we install the wrong binaries.

Given this, could you please suggest what the recommended approach should be for selecting the correct SDK directory?

As I wrote, please see how it's handled by the FastCV

Ugh, In my first message I wrote FastRPC instead of FastCV. Sorry for the confusion.

meta-qcom/recipes-multimedia/fastcv/qcom-fastcv-binaries_1.8.4.bb

Line 55 in 3cfd302

PACKAGES += "\

In the FastCV recipe, they create several target‑specific packages and assign the corresponding files to each one. Can you confirm whether this same approach is expected for the qairt hexagon libraries as well?

Yes. We are working with FastRPC to implement loading of system-specific Hexagon libraries in a generic way, but until that's implemented the set of small packages is a correct way to handle QAIRT.

Each target has its corresponding hexagon architecture and the libs should be installed based on that.

So, i was planning to package these libs based on the Hexagon architecture and have the install directories and package names based on the hexagon architecture.

But i’ve noticed that in fastcv and the hexagon-dsp-binaries the package names and installation paths include the target device names.

Should I follow the exact same convention of using the target‑based install paths and package naming, or is it preferable to adopt the Hexagon‑architecture‑based packaging approach instead?

So, what happens with your approach next time the customer asks to have a single rootfs which works on a variety of devices (they do)?
So, it's not possible to have just a single set of Hexagon libs in a rootfs. We are trying to solidify a good solution for the co-installing device-independent libs. However for now the best course of action is to install those libs into a device-specific location (as it will be looked into by the FastRPC anyway).

lumag · 2026-01-20T22:46:06Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+
+do_install() {
+    install -d ${D}/${includedir}
+    install -d ${D}/${libdir}/rfsa/adsp


This dir is going to be ignored by FastRPC daemon

lumag · 2026-01-20T22:46:36Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+INSANE_SKIP:${PN}-dev += "already-stripped"
+INSANE_SKIP:${PN}-dbg += "already-stripped"
+
+INSANE_SKIP_${PN} += "arch"


Split Hexagon to separate packages. Moreover this line won't work, if I'm not mistaken.

Will update this based on the packaging of the hexagon libs.

ricardosalveti · 2026-01-21T16:25:41Z

Still no commit message, please expand explaining why this recipe is getting included and the scope of QAIRT SDK.

ricardosalveti · 2026-01-21T16:39:22Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://LICENSE.pdf;md5=878b885995f453e328edbcd5a1302306"
+
+SUMMARY = "QAIRT-SDK"


This is not really a summary, please extend.

I think the description needs to move to summary and that part needs to be more descriptive ...

I have updated the summary and description.

ricardosalveti · 2026-01-21T16:43:57Z

I'm not familiar with this SDK, but it is quite huge, containing multiple pre-built libraries for multiple targets, can you extend why we need to include this SDK? Who are the users, why we need it integrated in meta-qcom and so on.

Integrating entire proprietary-base SDKs in yocto is not that common.

anujm1 · 2026-01-22T00:46:44Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+FILES_SOLIBSDEV = ""
+
+# Include non standard library paths.
+FILES:${PN} += "${libdir}/*"


This isn't non-standard library path.

This ensures that the Hexagon libraries installed under ${libdir}/rfsa/adsp are packaged.

The final install path for these libraries is still under discussion. If we later move to
device‑specific packages with their own Hexagon library sets, the corresponding FILES
entries will be added there and this entry can be removed.

I'm sorry, it's not. ${libdir}/rfsa/adsp is unsupported and must be dropped.

anujm1 · 2026-01-22T00:48:17Z

recipes-ml/qairt/qairt-sdk_2.41.0.251128.bb

+INHIBIT_PACKAGE_STRIP = "1"
+INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+INSANE_SKIP:${PN} += "already-stripped"
+INSANE_SKIP:${PN}-dev += "already-stripped"


What is in -dev that is already stripped?

dev package only contains the header files and the dbg is empty. Removed the suppression for dev and dbg packages.

tjamula · 2026-01-22T09:22:39Z

@ricardosalveti , I have enhanced the commit message and the description.

We contribute to Qualcomm’s IMSDK, which is also planned to be added to meta‑qcom. Several applications within the IMSDK rely on the QAIRT SDK, enabling users to run end‑to‑end Machine Learning use‑cases alongside multimedia workflows on Qualcomm devices.

Add recipe for QAIRT SDK, which provides the tools, runtimes, and model‑execution components required to enable Machine Learning use‑cases on Qualcomm devices. This integration supports efficient inference across CPU, GPU, and NPU/HTP accelerators, while also enabling the development of ML applications, including those incorporated within Qualcomm’s IMSDK. Signed-off-by: Tushar Patra Jamula <tjamula@qti.qualcomm.com>

tjamula requested review from lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners January 20, 2026 11:07

koenkooi requested changes Jan 20, 2026

View reviewed changes

lumag requested changes Jan 20, 2026

View reviewed changes

tjamula force-pushed the qairt branch 2 times, most recently from 07bce4a to f803949 Compare January 21, 2026 14:03

ricardosalveti reviewed Jan 21, 2026

View reviewed changes

anujm1 reviewed Jan 22, 2026

View reviewed changes

tjamula force-pushed the qairt branch from f803949 to 2d9651c Compare January 22, 2026 09:09

tjamula marked this pull request as draft January 22, 2026 10:07

tjamula force-pushed the qairt branch from 2d9651c to 4cea7ea Compare January 22, 2026 13:12


		INSANE_SKIP_${PN} += "arch"

		SOLIBS = ".so"

recipes-ml: Add recipe for QAIRT SDK #1412

Are you sure you want to change the base?

recipes-ml: Add recipe for QAIRT SDK #1412

Conversation

tjamula commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

koenkooi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lumag left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ricardosalveti commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ricardosalveti commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjamula commented Jan 22, 2026

Uh oh!

tjamula commented Jan 20, 2026 •

edited

Loading