Firmware version testing

[vandah]

We're currently reviewing the intel-npu-driver snap tests with @wfrench and we're wondering about the firmware version testing:

1. For testing the NPU driver, is it necessary to make sure the version of firmware is the same release as the UMD driver ? Is there already a version test included in the npu-umd-test utility?
2. Is it possible to deterministically extract the version string (as in the firmware column in the releases table) from the firmware binary?

[jwludzik]

1. We recommend keeping the firmware and driver/compiler (libze_intel_npu.so/libnpu_driver_compiler) versions in sync. To satisfy kernel requirements (our intel_vpu kernel module driver), we must ensure that new kernel/firmware does not break the old driver/compiler. This means users can use the latest kernel and firmware with older intel-npu-driver releases.
   You can find NPU firmware in two places: in intel/linux-npu-driver and firmware/linux-firmware.
   No, there is no version test in npu-umd-test. Looking at the kernel requirement, we cannot assume that users use the recommended firmware.
2. Yes, you can use the strings command to extract it from the binary, but the line index with the version is not constant and might vary from binary to binary:

0.0.0
20250723*MTL_CLIENT_SILICON-NVR+NN-deployment*52e7ebee50a93a07d14a1f162226cd55ad3999f0*52e7ebee50a93a07d14a1f162226cd55ad3999f0*52e7ebee50a

The kernel can load different firmware, so it is best to check which firmware is loaded using debugfs if available:

$ cat /sys/kernel/debug/accel/0000\:00\:0b.0/fw_name
intel/vpu/vpu_37xx_v0.0.bin

The vanilla kernel has a patch that allows getting the firmware version (fw_version) from debugfs, see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/accel/ivpu/ivpu_debugfs.c?h=v6.16.8&id=2baf2143dd406ce7ffb847a03ad40e3cc99322fa

The best way to check what firmware version is loaded is to check dmesg after intel_vpu kernel module driver is loaded:

$ sudo dmesg | grep intel_vpu
[ 2524.743937] intel_vpu 0000:00:0b.0: [drm] Firmware: intel/vpu/vpu_37xx_v0.0.bin, version: 20250723*MTL_CLIENT_SILICON-NVR+NN-deployment*52e7ebee50a93a07d14a1f162226cd55ad3999f0*52e7ebee50a93a07d14a1f162226cd55ad3999f0*52e7ebee50a
[ 2524.853268] [drm] Initialized intel_vpu 1.0.0 20230117 for 0000:00:0b.0 on minor 0

[vandah]

Thanks a lot for your answer!

Yes, you can use the strings command to extract it from the binary, but the line index with the version is not constant and might vary from binary to binary

If the line number can change, can we rely on the format being one of YYYYMMDD*... or Mmm DD YYYY*... ? If there's more of the version string that stays consistent across releases that would be helpful for matching too.

[jwludzik]

No, as it might be different from platform to platform. For example LunarLake has following version:

Jun 11 2025*NPU40xx*build/ci/npu-fw-ci-ci_branch_UD202524_npu_release_25ww22-20250603_183038-26415-8-g5437076a64c*5437076a64c995fd1fbe21c3019f522b56db98f9

I can only suggest to make a map between the firmware version and Linux NPU driver release. The fixed table with all version will help to identify the installed firmware version

[vandah]

Right, what I meant was if there are any planned changes to these formats or if we could say e.g. Lunar Lake has Mmm DD YYYY*... and Meteor and Arrow Lake have YYYYMMDD*... or just in general say we try to find a string in either of those formats (and then that would be the line that we match to the dmesg output)?

[jwludzik]

I am sorry for such delay in reply. Today it should be fine for the use case that you defined. I am trying to get full commitment from the team on this