arm64: dts: qcom: glymur: Add Asus Zenbook A14 (UX3407NA)
Hi Nicko,
I have an ASUS Zenbook A14 UX3407NA as well and have been investigating the audio issue further.
On my unit I see the same basic hardware layout you described: the two WSA8845 devices on swr0 attach, while the two devices described on swr3 remain unattached. I now have working stereo speakers and internal microphone on NixOS.
The currently working setup is:
keep the stock 4-channel GLYMUR-CRD AudioReach topology
remove the nonexistent WSA2/swr3 speaker path from the board/UCM configuration
constrain the WSA codec-DMA backend to 2 channels in the x1e80100 machine driver
map the frontend channel order so physical left/right, which land in PCM slots 0 and 2, are exposed as normal stereo
I have also started turning this into cleaner, distribution-independent patches for the DTS, AudioReach topology, and alsa-ucm-conf here:
https://github.com/chrispouliot/ux3407na-linux-audio
Those exact upstream-style patches have not been tested yet; they are currently intended as RFC material. In particular, I am not yet sure whether the correct upstream solution is a board-specific 2-channel AudioReach topology, or whether Glymur should retain the 4-channel frontend and express the 2-channel speaker constraint elsewhere.
I would appreciate any guidance on where that constraint is expected to live upstream.
Thanks,
Chris
Quoted 124 lines · Nicko van Someren
Quoted 5 lines · Bjorn Andersson
From: Bjorn Andersson <[email protected]>
UX3407NA is a variant of the Asus Zenbook A14 built on the Qualcomm Glymur platform. It comes with an 18-core X2 Elite SoC, 32GB DDR, and the other typical Glymur platform capabilities.
Firstly, many thanks for this. I recently acquired one of these machines for some firmware work I'm doing and having a working Linux system on it makes my life much easier!
I tested this patch set, along with the others it depends on. I have it mostly working now but ran into some issues that might indicate a few changes.
WIFI:
Quoted 4 lines
+ wifi@0 {
+ compatible = "pci17cb,1107";
...
+ };ASUS don't specify what WiFi7 chip they use, which is fairly normal since ASUS tends to swap the parts depending on supply. As a result, my machine has a QCC2072 (17cb:1112) WiFi/BT module not the WCN7850 (17cb:1107) device that you listed. Inspection of the hardware shows that the WiFi/BT module is a solder-down M.2 LGA module, but electrically that's still an M.2 interface. Photos that I can find of the Zenbook A16 show it does the same. I think it might be more reliable to define a wlan-connector, like Konrad Dybcio did in the Asus Zenbook A16 (UX3607OA) (2/3) from 2026-07-21, rather than specify the chip.
SOUND:
Regarding sound definitions, the dts declares four WSA8845s -- a woofer and tweeter per side, two on swr0 and two on swr3.
Quoted 9 lines
+&swr0 {
+ status = "okay";(quoted diff) +5
-0+ + /* WSA8845, left woofer */ + + /* WSA8845, left tweeter */ +};Review
Quoted 10 lines
(quoted diff) +7
-0+ +&swr3 { + status = "okay"; + /* WSA8845, right woofer */ + + /* WSA8845, right tweeter */ +};This machine only has two speakers (again confirmed by physical inspection). Only swr0 shows attached on /sys/bus/soundwire/devices/sdw:*/status:
sdw:1:0:0217:0204:00:0 Attached sdw:1:0:0217:0204:00:1 Attached sdw:4:0:0217:0204:00:0 UNATTACHED sdw:4:0:0217:0204:00:1 UNATTACHEDI don't think that's a config fault either; the swr0 and swr3 reset lines are both claimed and in identical state of (out, 0, 2mA, no pull). It's not really a surprise that the cheaper model from ASUS would not use the full spec audio offered on the Qualcomm reference designs, but without a suitable UX3407NA-tplg.bin topology file I can't really tell more.
It appears that the audio setup is blocked further up the audio stack anyway. I hacked some dts changes, purloined blobs from Windows and got a stereo speaker setup configured. SoundWire is healthy, but no audio is possible because the DSP does not respond. The ADSP boots and the audio PD is reported up:
remoteproc remoteproc1: remote processor adsp is now up
PDR: Indication received from msm/adsp/audio_pd, state:0x1fffffffqcom,apr ...: Adding APR/GPR dev: gprsvc:service:2:1then, on every boot:
qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode
I'm curious as to if you tested this (or if this even known to work on the Zenbook A16, Yoga Slim 7x or EliteBook X G2q with the other submissions). Do you know if/when the required firmware blobs will be forthcoming and upstreamed?
HDMI:
The built-in HDMI cannot read EDID: the connector reports "connected" with a monitor attached but the EDID is 0 bytes and there are no modes. Less than 2 seconds into every boot, before any cable is involved:
gcc_usb3_tert_phy_com_aux_clkstatus stuck at 'off' Failed to enable clk 'com_aux': -16
phy phy-88e1000.phy.5: phy init failed --> -16I have not really investigated this in detail.
eDP:
eDP link training intermittently times out on resume, leaving visible flicker until another suspend/resume retrains it:
[drm:msm_dp_ctrl_link_train_1_2] *ERROR* link training #2 on phy 0 failed. ret=-110
I am carrying the (unmerged) "phy: qcom: edp: update v8 power-on programming sequence" series, so this may be feedback for that rather than a report against mainline.
Anyway, thank you again for this patch series. It got me to the point of having a very usable machine for my limited needs. If you have updates the need testing I'm happy to help.
Nicko