[Bug 2167022] Re: No audio output ("Dummy Output" only) — missing ADSP/CDSP firmware for ASUS Zenbook A14 UX3407NA (Snapdragon X2 Elite)

[Ubuntu Kernel Bot]

** Tags added: kernel-daily-bug linux-firmware-daily-bug

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubuntu-concept.
https://bugs.launchpad.net/bugs/2167022

Title:
  No audio output ("Dummy Output" only) — missing ADSP/CDSP firmware for
  ASUS Zenbook A14 UX3407NA (Snapdragon X2 Elite)

Status in ubuntu-concept:
  Invalid
Status in linux-firmware-qualcomm-misc package in Ubuntu:
  New

Bug description:
  Summary
  Audio does not work out of the box. PulseAudio/PipeWire only shows a "Dummy

  Output" sink, and aplay -l reports no soundcards found. Root cause
  traced to

  the ADSP (audio DSP) and CDSP (compute DSP) remoteprocs failing to
  fully boot

  due to missing device-specific firmware files.
  System Information
  ·	Laptop: ASUS Zenbook A14 (UX3407NA)
  ·	SoC: Qualcomm Snapdragon X2 Elite (X2E88100) — platform codename "Glymur"
  ·	OS: Ubuntu 26.04.1 LTS (resolute), arm64
  ·	Kernel: 7.2.0-18-qcom-x1e (from ppa:ubuntu-concept/x1e)
  ·	linux-firmware version: 20260319.git217ca6e4.1ubuntu (Ubuntu package)
  Diagnostic Steps Taken
  1. Initial state — firmware files missing entirely
  dmesg showed:
  remoteproc remoteproc1: Direct firmware load for qcom/glymur/ASUSTeK/UX3407NA/qcadsp8480.mbn failed with error -2
  remoteproc remoteproc1: request_firmware failed: -2
  remoteproc remoteproc2: Direct firmware load for qcom/glymur/ASUSTeK/UX3407NA/qccdsp8480.mbn failed with error -2
  remoteproc remoteproc2: request_firmware failed: -2

  Neither file existed anywhere under /lib/firmware/ — Ubuntu's
  installed

  linux-firmware package (20260319 snapshot) predates their addition.
  2. Found generic Glymur reference firmware upstream, but not device-specific
  Checked the upstream linux-firmware project

  (https://gitlab.com/kernel-firmware/linux-firmware) and found a
  generic

  qcom/glymur/ folder containing adsp.mbn, cdsp.mbn, adsp_dtb.mbn,

  cdsp_dtb.mbn, etc. — but no ASUSTeK/UX3407NA/ subfolder with

  device-specific firmware.
  As a test, copied the generic adsp.mbn/cdsp.mbn files into the expected

  device-specific path
  (/lib/firmware/qcom/glymur/ASUSTeK/UX3407NA/qcadsp8480.mbn

  and qccdsp8480.mbn). After also fixing an initramfs packaging gap (see
  below),

  this resolved the original -2 error and the DSPs began actually booting:
  remoteproc remoteproc2: Booting fw image qcom/glymur/ASUSTeK/UX3407NA/qccdsp8480.mbn, size 3252504
  remoteproc remoteproc1: Booting fw image qcom/glymur/ASUSTeK/UX3407NA/qcadsp8480.mbn, size 17070040

  3. New blocker — device-tree blobs missing in the format the driver expects
  Immediately after, both DSPs failed at the next boot stage:
  qcom_q6v5_pas 32300000.remoteproc: Direct firmware load for qcom/glymur/ASUSTeK/UX3407NA/cdsp_dtbs.elf failed with error -2
  qcom_q6v5_pas 32300000.remoteproc: request_firmware failed for qcom/glymur/ASUSTeK/UX3407NA/cdsp_dtbs.elf: -2
  remoteproc remoteproc2: Failed to load program segments: -2

  qcom_q6v5_pas 6800000.remoteproc: Direct firmware load for qcom/glymur/ASUSTeK/UX3407NA/adsp_dtbs.elf failed with error -2
  qcom_q6v5_pas 6800000.remoteproc: request_firmware failed for qcom/glymur/ASUSTeK/UX3407NA/adsp_dtbs.elf: -2
  remoteproc remoteproc1: Failed to load program segments: -2

  The driver requests adsp_dtbs.elf / cdsp_dtbs.elf (plural "dtbs", .elf

  format). The only files available anywhere upstream are adsp_dtb.mbn /

  cdsp_dtb.mbn (singular "dtb", .mbn format) — a different container
  format,

  not a simple rename/copy candidate. This appears to be a genuine gap:
  the

  kernel driver expects a newer firmware packaging convention than what

  currently exists in the public linux-firmware repository for this platform.
  Secondary Issue Found: initramfs does not bundle newly-added /lib/firmware files
  This system uses dracut (not classic initramfs-tools, despite the

  update-initramfs command wrapper). Files manually added under

  /lib/firmware/ are not automatically included in the initramfs, so
  even

  after placing correct firmware files on disk, the early-boot
  remoteproc drivers

  could not find them until an explicit /etc/dracut.conf.d/*.conf with

  install_items+= was added. This may be worth flagging separately,
  since

  firmware normally shipped via the linux-firmware package presumably
  has its

  own mechanism for this — device-specific firmware added by end
  users/packagers

  after the fact does not appear to be picked up automatically.
  Expected Behavior
  Audio DSP (ADSP/CDSP) should boot fully using appropriate firmware for this

  device, and a real audio sink should appear (not just PipeWire's dummy output).
  Actual Behavior
  No functional audio device; ADSP/CDSP fail to complete boot due to missing

  device-specific .elf device-tree firmware files.
  What Would Resolve This
  Device-specific ADSP/CDSP firmware (in particular adsp_dtbs.elf /

  cdsp_dtbs.elf, plus verification that qcadsp8480.mbn/qccdsp8480.mbn

  generic substitutes are actually correct/safe for this exact model)
  needs to

  be contributed to linux-firmware for qcom/glymur/ASUSTeK/UX3407NA/,

  presumably by ASUS or Qualcomm, or by a community member with access
  to the

  Windows driver package for this exact laptop model.
  Suggested Filing Location(s)
  ·	Primary: linux-firmware project issue tracker —

  https://gitlab.com/kernel-firmware/linux-firmware/-/issues

  (missing device-specific firmware for ASUS Zenbook A14 UX3407NA / Glymur)
  ·	Also worth filing at ppa:ubuntu-concept/x1e —
  https://bugs.launchpad.net/ubuntu-concept

  (both for visibility/tracking, and specifically for the
  dracut/initramfs

  packaging gap noted above)
  Additional Notes
  ·	Happy to test firmware files or provide further diagnostics if a maintainer

  wants to work through this — I have the Windows partition still
  available on

  this dual-boot machine, which may be useful for extracting reference
  driver

  data if that's a viable path forward.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-concept/+bug/2167022/+subscriptions