Repository navigation
[BUG] Lenovo Yoga Pro 16s IMH9 engineering sample: MTL firmware authentication fails with 0x97 #11042
Description
Describe the bug
A Lenovo Yoga Pro 16s IMH9 engineering sample cannot authenticate either of
the current Meteor Lake SOF firmware variants shipped by Arch Linux. Both the
Intel-signed and community binaries reach VALIDATE_PUB_KEY and fail with ROM
error 0x97. The SOF driver then times out with -110.
An OEM Intel DSP firmware extracted from the Lenovo Windows recovery image
does authenticate and boot on the same machine. I am not attaching or
redistributing that vendor binary in this report.
This looks similar to the prototype-key issue fixed in #8281, but it still
occurs with current 2026 packages. I would like to determine whether this ES
platform needs an available development-key build, whether rimage is selecting
the wrong key slot for this hardware, or whether the silicon accepts only a
Lenovo/OEM signing key.
To Reproduce
- Install
sof-firmware 2025.12.2-1on Arch Linux. - Boot the stock Intel-signed
intel/sof-ipc4/mtl/intel-signed/sof-mtl.ri. - Observe firmware authentication failure with ROM error
0x97. - Select the packaged community
sof-mtl.ri; observe the same error.
Reproduction Rate
100% with both packaged firmware variants. The OEM recovery firmware boots
successfully on every tested boot.
Expected behavior
SOF should provide or identify a firmware build signed for this Meteor Lake ES
platform, or document that this key configuration cannot be supported by
public SOF binaries.
Impact
Showstopper for the internal digital microphone and the normal SOF audio path.
The legacy HDA driver can produce speaker/headphone output but cannot expose
the internal DMIC.
Environment
Kernel: Linux 7.1.4-arch1-1
SOF package: sof-firmware 2025.12.2-1
linux-firmware package: linux-firmware 20260622-1
Topology during stock-firmware test: sof-hda-generic-4ch.tplg
Platform: Intel Meteor Lake-P
System: Lenovo Yoga Pro 16s IMH9 engineering sample
DMI product_name: 0000
DMI product_family/version: YOGA Pro 16s IMH9
Audio controller: 8086:7e28, subsystem 17aa:3811
Codec: Realtek ALC287, subsystem 17aa:38d6
DMIC count reported by NHLT: 4
Tested firmware hashes:
b549c4447cbd92c636feb6993a75ae0a6b1d831336d2723b82c9fcc03c0ae778 packaged Intel-signed sof-mtl.ri
f26f251f36e3fece5da4469d23363295ec5f7f9bf423634051628c4e9d64926f packaged community sof-mtl.ri
ab570de158e5002ce998fb7e85396ea592b85bd526c733245b51ed99a1f06a0f Lenovo recovery DSP firmware
The OEM firmware identifies itself as version 20.40.1393.0.
Failure log: packaged Intel-signed firmware
Firmware file: intel/sof-ipc4/mtl/sof-mtl.ri
Loaded firmware library: ADSPFW, version: 2.14.1.1
hda_cl_copy_fw: timeout with rom_status_reg (0x163200) read
Firmware download failed
fw_state: SOF_FW_BOOT_IN_PROGRESS (3)
0xd000000c: module: ROM_EXT, state: VALIDATE_PUB_KEY, not running
error code: 0x97 (unknown)
Failed to start DSP
error: failed to boot DSP firmware -110
error: sof_probe_work failed err: -110
The community path produced the same VALIDATE_PUB_KEY / 0x97 result.
Successful control: OEM recovery firmware
Firmware file: intel/sof-ipc4/mtl/es-windows/sof-mtl.ri
Loaded firmware library: ADSPFW, version: 20.40.1393.0
Booted firmware version: 20.40.1393.0
DMICs detected in NHLT tables: 4
After the firmware boot issue was bypassed, the OEM firmware could not
instantiate all processing modules in the current generic four-channel
topology (EQIIR, EQFIR, DRC and TDFB are absent). A reduced topology with
direct playback/capture routes successfully exposes raw 48 kHz, S32_LE,
four-channel DMIC capture. I understand that an old OEM firmware is not
expected to match the current topology; this is included only to confirm that
the DSP and DMIC hardware work once a correctly authenticated firmware boots.
Questions
- Is this platform expected to be covered by the key-slot fix from rimage: mtl/lnl: fix key slot setup based on imr type #8421, or
does its ES fuse/key configuration differ? - Is there a public community/development-key
sof-mtl.riexpected to
authenticate on this ES unit? - If not, is using the matching OEM firmware the only viable route for this
hardware?
Related: #8281 and #10420. In #8281, 0x97 was identified as
ADSP_MANIFEST_KEY_NOT_REGISTERED (the manifest key does not match any
registered platform key).
Activity
lgirdwood commentedon Jul 29, 2026
@lhxll07 engineering sample devices will use the engineering keys for multiple firmwares. These devices are not supported with production SOF FW as they usually have custom configurations are are not validated products. If you do work for the OEM/ODM pls do contact through the official channel for assistance.
lhxll07 commentedon Jul 31, 2026
Thanks for confirming. I do not work for the OEM/ODM; this is a privately owned engineering-sample machine.
The matching DSP firmware from the Lenovo recovery image authenticates and boots reliably, so I will continue using that firmware and document that production SOF firmware does not support this ES key configuration. No engineering-key firmware or further support is requested.
This report can remain as a reference for the
VALIDATE_PUB_KEY/0x97behavior. Please feel free to close it.wzk4work commentedon Aug 29, 2026
Hi @lhxll07 — I'm hitting the exact same
VALIDATE_PUB_KEY/0x97wall on a ThinkPad X13 Gen 5 (type 21LU, model 21LUFVT010), which is also a Meteor Lake-P engineering sample (CPU brand stringGenuine Intel(R) 0000, audio controller8086:7e28, subsystem17aa:232a). Adding some data in case it's a useful reference, then a question.Confirmed on this unit (BIOS N45ET26W / 1.16, kernel 7.0.0):
intel/sof-ipc4/mtl/sof-mtl.ri(intel-signed) and thecommunity/variant both fail atROM_EXT / VALIDATE_PUB_KEY, error0x97(ADSP_MANIFEST_KEY_NOT_REGISTERED), then-110.dsp_fw_mtl_qs.bin(20.40.12741.9, from Microsoft Update Catalog) is signed with the same production key as linux-firmware's intel-signedsof-mtl.ri, so it also fails0x97here.VALIDATE_PUB_KEYand fail0x97too. So nothing publicly downloadable authenticates on this ES.dsp_driver=1) recovers speakers/headset only, and the internal mics are reachable only via the DSP path.Question: do Meteor Lake-P engineering samples share a common engineering key? I.e. would the OEM firmware that authenticates on your Yoga Pro 16s IMH9 ES (
20.40.1393.0) also passVALIDATE_PUB_KEYon a different MTL-P ES like this X13, or is the trusted key per-unit / per-OEM batch? (As noted earlier in this thread, ES units aren't supported by production SOF FW — I'm only trying to understand the key-provisioning model.)If they do share a key: as another private (non-OEM) MTL-P ES owner in the same spot, I'd be grateful if you'd be willing to share the working DSP binary or your extraction steps for a test — entirely at your discretion given the redistribution sensitivity you already flagged, and happy to take it off-list. Even just confirming the shared-key question would help a lot. Thanks for the very thorough write-up either way.