[BUG] Lenovo Yoga Pro 16s IMH9 engineering sample: MTL firmware authentication fails with 0x97

[lhxll07]

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

1. Install sof-firmware 2025.12.2-1 on Arch Linux.
2. Boot the stock Intel-signed
   intel/sof-ipc4/mtl/intel-signed/sof-mtl.ri.
3. Observe firmware authentication failure with ROM error 0x97.
4. 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

1. 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?
2. Is there a public community/development-key sof-mtl.ri expected to
   authenticate on this ES unit?
3. 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).