Skip to content

Instantly share code, notes, and snippets.

@masselstine
Last active April 1, 2024 21:05
Show Gist options
  • Star 15 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save masselstine/8fe9634b4c31cef07b8dfab089e4eb38 to your computer and use it in GitHub Desktop.
Save masselstine/8fe9634b4c31cef07b8dfab089e4eb38 to your computer and use it in GitHub Desktop.
Linux on the Zenbook 14 OLED refresh (UM3402YAR)

Linux on the Zenbook 14 OLED (refresh) - Model UM3402YAR

BIOS

The latest BIOS is version 303 "UM3402YAR.303" (Release Date: 09/05/2023). All items posted here will be specific to the model number and BIOS version described here (BIOS 300, 302 were known working). Some things might be specific to Arch Linux but should be generic and portable to other distributions. There are no guarantees and should you wish to try any of this out it is assumed to be at your own risk.

Sound

The sound does not work out of the box (at least not on Arch but I am guessing for most Distros as well).

The patch 0001-ALSA-hda-realtek-Add-quirk-for-ASUS-UM3402YAR-using-.patch is required to be applied to kernels older than v6.4 to ensure that the Realtek sound device is properly bound to the Cirrus amplifiers. If you are using kernel v6.4 or newer this patch is not needed.

The ssdt_csc3551.dsl file can be used per the instructions found in the file header. No need to patch the DSDT, this is a stand-alone SSDT that is easily used via GRUB. It can also be used as an EFI var and the efivar_ssdt= kernel command line option. The values are prelimary as I review the Windows oem50.inf and oem37.inf files from Windows in order to extract the proper values.

The firmware files are missing from the linux-firmware on Arch Linux (and most likely other distros as well, until someone submits them for merge). Originally I was using direct copies of firmware files for the similar "10431e12" device that were present in /lib/firmware/cirrus. At the time these appeared to be identical. Updating the Windows OS recently and looking again shows that there are differences. So I am now copying the firmware files from Windows and running the "compress-rename.sh" script to prepare them on Linux.

To start grab the full contents of c:\windows\system32\csaudio from Windows. Once you have these files on Linux you should have something like

$ ls -l
total 1080
-rw-r--r-- 1 mark mark   5532 Nov 24 14:16 10431E12_220304_V0_A0.bin
-rw-r--r-- 1 mark mark   2012 Nov 24 14:16 10431E12_220304_V0_A0_cal.bin
-rw-r--r-- 1 mark mark   5532 Nov 24 14:16 10431E12_220304_V0_A1.bin
-rw-r--r-- 1 mark mark   2012 Nov 24 14:16 10431E12_220304_V0_A1_cal.bin
-rw-r--r-- 1 mark mark   5532 Nov 24 14:16 10431E12_220304_V1_A0.bin
-rw-r--r-- 1 mark mark   2012 Nov 24 14:16 10431E12_220304_V1_A0_cal.bin
-rw-r--r-- 1 mark mark   5532 Nov 24 14:16 10431E12_220304_V1_A1.bin
-rw-r--r-- 1 mark mark   2012 Nov 24 14:16 10431E12_220304_V1_A1_cal.bin
-rw-r--r-- 1 mark mark   2600 Nov 24 14:16 Calibration_and_Diagnostics_CS35L41B_48000_29.63.1_left_cal.bin
-rw-r--r-- 1 mark mark   1548 Nov 24 14:16 Calibration_CS35L41B_48000_29.63.1_left_cal.bin
-rw-r--r-- 1 mark mark  11556 Nov 24 14:38 csaudio.cat
-rw-r--r-- 1 mark mark 100255 Nov 24 14:38 csaudioext.cat
-rw-r--r-- 1 mark mark 110868 Nov 24 14:35 csaudioext.inf
-rw-r--r-- 1 mark mark   6392 Nov 24 14:35 csaudio.inf
-rw-r--r-- 1 mark mark 350632 Nov 24 14:37 csaudio.sys
-rw-r--r-- 1 mark mark   5208 Nov 24 14:16 Enhance_Protect_Lite_Mono_CS35L41B_48000_29.63.1_left.bin
-rw-r--r-- 1 mark mark  33456 Nov 24 14:16 halo_cspl_RAM_diag_revB2_29.63.1.wmfw
-rw-r--r-- 1 mark mark  34068 Nov 24 14:16 halo_cspl_RAM_revB2_29.63.1.wmfw
-rw-r--r-- 1 mark mark   6392 Nov 24 14:31 oem37.inf
-rw-r--r-- 1 mark mark   9812 Nov 24 14:31 oem37.PNF
-rw-r--r-- 1 mark mark 110868 Nov 24 14:31 oem50.inf
-rw-r--r-- 1 mark mark  91068 Nov 24 14:31 oem50.PNF
-rw-r--r-- 1 mark mark 136610 Nov 24 14:32 oem82.inf
-rw-r--r-- 1 mark mark   3920 Nov 24 14:16 Protect_Lite_CS35L41B_48000_29.63.1_left.bin
-rw-r--r-- 1 mark mark    760 Nov 24 14:16 top_passthrough_CS35L41B_48000_29.63.1_full.bin

From this directory run the $ bash compress-rename.sh script to generate the firmware files. You should now have

$ ls -l *zst
-rw-r--r-- 1 mark mark  1148 Nov 24 14:16 cs35l41-dsp1-spk-cali-10431683-spkid0-l0.bin.zst
-rw-r--r-- 1 mark mark  1144 Nov 24 14:16 cs35l41-dsp1-spk-cali-10431683-spkid0-r0.bin.zst
-rw-r--r-- 1 mark mark  1145 Nov 24 14:16 cs35l41-dsp1-spk-cali-10431683-spkid1-l0.bin.zst
-rw-r--r-- 1 mark mark  1147 Nov 24 14:16 cs35l41-dsp1-spk-cali-10431683-spkid1-r0.bin.zst
-rw-r--r-- 1 mark mark 18852 Nov 24 16:39 cs35l41-dsp1-spk-cali-10431683.wmfw.zst
-rw-r--r-- 1 mark mark  3122 Nov 24 14:16 cs35l41-dsp1-spk-prot-10431683-spkid0-l0.bin.zst
-rw-r--r-- 1 mark mark  3117 Nov 24 14:16 cs35l41-dsp1-spk-prot-10431683-spkid0-r0.bin.zst
-rw-r--r-- 1 mark mark  3146 Nov 24 14:16 cs35l41-dsp1-spk-prot-10431683-spkid1-l0.bin.zst
-rw-r--r-- 1 mark mark  3127 Nov 24 14:16 cs35l41-dsp1-spk-prot-10431683-spkid1-r0.bin.zst
-rw-r--r-- 1 mark mark 18852 Nov 24 16:39 cs35l41-dsp1-spk-prot-10431683.wmfw.zst

Copy all of these files to /lib/firmware/cirrus.

SPKR _DSD validation

Elements are described in the kernel documentation found here

100% Confirmed

  • "cirrus,dev-index": Confirmed by: Simple printk() was used to determine the values of the two AMPs. These are used to determine the index used ('0' or '1') when retrieving values from other elements in the _DSD
  • "reset-gpios": Confirmed by: The driver issues a reset after reading the ACPI data and waits for the reset to complete by polling IRQ status for CS35L41_OTP_BOOT_DONE. If this is not set correctly then the reset would fail and a OTP_BOOT_DONE waiting message would be printed.
  • "spk-id-gpios": Mostly confirmed by: There are 4 GPIOs listed in the 'shipped' ACPI DSDT. Index 0 is the reset-gpios Indicies 0x02 and 0x03 share a pin and are "shared". So by processes of elimination GPIO at index 'One' remains. The 0th element is definitely SPKR the 2nd and 3rd elements are best guess.
  • "cirrus,speaker-position": Confirmed by: Simple left and right position in driver code & left and right are properly outputting sound in sound settings with isolated output
  • "cirrus,gpio1-func": Confirmed by: the comment in the oem50.inf for "CONF_0330.NT"
  • "cirrus,gpio2-func": Mostly confirmed by: the speakers working. Also a "Amp short error" interrupt was received while this work was being done.
  • "cirrus,boost-type": Confirmed by: the comment in the oem50.inf for "CONF_0330.NT"
  • "cirrus,gpio1-output-enable": Confirmed by: with GPIO1 being VSPK_SWITCH then GPIO1 needs to be an output
  • "cirrus,gpio1-src-select": Confirmed by: with GPIO1 being used as a GPIO output, then this is the only thing that makes sense

The patch and the SSDT are the only changes required to get sound working. Again, use of items posted here is use-at-your-own-risk.

Fingerprint

Not working

From f309c07e244945b9b3b3c473d5e8394cce132ddf Mon Sep 17 00:00:00 2001
From: Mark Asselstine <mark@tundrafam.ca>
Date: Sat, 29 Apr 2023 11:21:55 -0400
Subject: [PATCH] ALSA: hda/realtek: Add quirk for ASUS UM3402YAR using CS35L41
This Asus Zenbook laptop use Realtek HDA codec combined with
2xCS35L41 Amplifiers using I2C with External Boost.
Signed-off-by: Mark Asselstine <mark@tundrafam.ca>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f70d6a33421d..905acd66ea01 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9500,6 +9500,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK),
+ SND_PCI_QUIRK(0x1043, 0x1683, "ASUS UM3402YAR", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x16b2, "ASUS GU603", ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1740, "ASUS UX430UA", ALC295_FIXUP_ASUS_DACS),
--
2.40.1
#!/usr/bin/bash
#
# Create the needed Linux firmware files from a copy of the firmware
# files from Windows (c:\windows\system32\csaudio)
#
zstd halo_cspl_RAM_revB2_29.63.1.wmfw -o halo_cspl_RAM_revB2_29.63.1.wmfw.zst
for t in cali prot
do
for i in 0 1
do
for side in l r
do
j=0
if [ $side == "r" ]; then
j=1
fi
deco=""
if [ $t == "cali" ]; then
deco="_cal"
fi
ofile=10431E12_220304_V${i}_A${j}${deco}.bin
zstd ${ofile} -o ${ofile}.zstd
mv ${ofile}.zstd cs35l41-dsp1-spk-${t}-10431683-spkid${i}-${side}0.bin.zst
done
done
cp halo_cspl_RAM_revB2_29.63.1.wmfw.zst cs35l41-dsp1-spk-${t}-10431683.wmfw.zst
done
rm halo_cspl_RAM_revB2_29.63.1.wmfw.zst
# dmesg | grep cs3
[ 12.582998] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 12.591327] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[ 12.636874] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 12.758779] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[ 12.762457] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[ 13.262629] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[ 13.266856] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[ 13.270159] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[ 13.274041] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_L_tuning_IDHX_ReDC_Finish_PICL_RTL_0304.bin
[ 13.379459] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[ 13.393246] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[ 13.397723] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[ 13.898417] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[ 13.903515] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 0: ID cd v29.63.1 XM@94 YM@e
[ 13.907164] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: 1: ID f20b v0.1.0 XM@176 YM@0
[ 13.909854] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_R_tuning_IDHX_ReDC_Finish_PICL_RTL_0304.bin
[ 14.014944] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
...
;; ASUSTEK Zenbook notebook (see FC-2054)
%CirrusSpeakerAmp% = CONF_0322, ACPI\VEN_CSC&DEV_3551&SUBSYS_104316A3 ; UX3402VA [FC-1831] [FC-1905]
%CirrusSpeakerAmp% = CONF_0451, ACPI\VEN_CSC&DEV_3551&SUBSYS_104316D3 ; UX5304VA [FC-2056]
%CirrusSpeakerAmp% = CONF_0450, ACPI\VEN_CSC&DEV_3551&SUBSYS_104316F3 ; UX7602VZ [FC-1836]
%CirrusSpeakerAmp% = CONF_0460, ACPI\VEN_CSC&DEV_3551&SUBSYS_10431F1F ; H7604JV/HU/W7604J3D [FC-2033]
%CirrusSpeakerAmp% = CONF_0470, ACPI\VEN_CSC&DEV_3551&SUBSYS_10431863 ; UX6404VA/VU [FC-2015]
%CirrusSpeakerAmp% = CONF_0330, ACPI\VEN_CSC&DEV_3551&SUBSYS_10431683 ; UM3402YAR [FC-1827] (UM3402_refresh)
%CirrusSpeakerAmp% = CONF_0430, ACPI\VEN_CSC&DEV_3551&SUBSYS_104318D3 ; UM3504DA [FC-2054]
...
;; 2-ch I2C, ext. VSPK, SPKR_ID
[CONF_0330.NT]
AddReg=CONF_0320.Settings.AddReg, CONF_0330.Config.AddReg, L51_2_VSPK.Init.AddReg
AddReg=PB6.61.1.Firmware.AddReg, PB6.61.1.Tunings.AddReg, CONF_0330.Tunings.AddReg, 2_SPK_2_VEN_DefaultGain.AddReg
CopyFiles=PB6.61.1.Firmware.CopyFiles, PB6.61.1.Tunings.CopyFiles, CONF_0330.Tunings.CopyFiles
//
// Build
// # iasl -tc ssdt_csc3551.dsl
// Create the proper directory structure and copy .aml file
// # mkdir -p kernel/firmware/acpi
// # cp ssdt_csc3551.aml kernel/firmware/acpi/ssdt_csc3551.aml
// Package into a format loadable by grub
// # find kernel | cpio -H newc --create > acpi_override
// Copy to /boot
// # cp acpi_override /boot/.
// Load via grub
// initrd /acpi_override /amd-ucode.img /initramfs-linux.img
// Supporting docs
// https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/cirrus%2Ccs35l41.yaml
//
DefinitionBlock ("", "SSDT", 2, "CUSTOM", "CSC3551", 0x00000003)
{
External (_SB_.I2CD, DeviceObj)
External (_SB_.I2CD.SPKR, DeviceObj)
Scope (\_SB.I2CD.SPKR)
{
Name(_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () { "cirrus,dev-index", Package () { 0x40, 0x41 }},
// reset-gpios: 2nd elem is GPIO index: Zero, One, 0x02 or 0x03
Package () { "reset-gpios", Package () {
SPKR, Zero, Zero, Zero,
SPKR, Zero, Zero, Zero
} },
// spk-id-gpios: 2nd elem is GPIO index: Zero, One, 0x02 or 0x03
Package () { "spk-id-gpios", Package () {
SPKR, One, Zero, Zero,
SPKR, One, Zero, Zero
} },
Package () { "cirrus,speaker-position", Package () { Zero, One } },
// gpioX-func: 0 not used, 1 VSPK_SWITCH, 2: INTERRUPT, 3: SYNC
Package () { "cirrus,gpio1-func", Package () { One, One } },
Package () { "cirrus,gpio2-func", Package () { 0x02, 0x02 } },
// boost-type: 0 internal, 1 external
Package () { "cirrus,boost-type", Package () { One, One } },
// gpio1-output-enable: true, false (default: false, ie: input)
Package () { "cirrus,gpio1-output-enable", Package () { One, One } },
// gpio1-src-select: 0 High Impedance (default), 1 GPIO, 2 Sync, 3 MCLK input
Package () { "cirrus,gpio1-src-select", Package () { One, One } }
}
})
}
}
@masselstine
Copy link
Author

@starman45 check the dmesg to ensure you are not seeing "Falling back to default firmware" for the CS35 device. When messing around with firmware files I had a typo in the name and one of the amplifiers got default firmware files loaded and exhibited much lower volume than the other. NOTE as well that I have updated the gist to not reuse the firmware for the "10431e12" device but instead grab the files from Windows. This has improved my sound quality to match what I was seeing in Windows.

@kelna
Copy link

kelna commented Nov 26, 2023

Thank you masselstine and especially farfaa! Farfaa's simple step-by-step guide and script worked like a charm perfectly on my 3402YA. The only change I had to make on Arch is the last command: instead of update-grub its grub-mkconfig -o /boot/grub/grub.cfg

Well yes, it worked. But I have a strange issue on my UM3402YA. Sometimes (very often) there is no sound after waking up from sleep. I couldn't yet figure out in what circumstance this occurs because sometimes I have sound after waking up. But if it goes away, I cannot bring it back, only by rebooting. Does anyone experience this?

@masselstine
Copy link
Author

Thank you masselstine and especially farfaa! Farfaa's simple step-by-step guide and script worked like a charm perfectly on my 3402YA. The only change I had to make on Arch is the last command: instead of update-grub its grub-mkconfig -o /boot/grub/grub.cfg

Well yes, it worked. But I have a strange issue on my UM3402YA. Sometimes (very often) there is no sound after waking up from sleep. I couldn't yet figure out in what circumstance this occurs because sometimes I have sound after waking up. But if it goes away, I cannot bring it back, only by rebooting. Does anyone experience this?

I see this as well. Sometimes adjusting the volume is enough to correct things. It is not unusual for Linux device drivers to run into issues with suspect/resume, it is just a matter of someone with the skills and time to dig into the issue. Maybe one day I will have the time.

@dabendji2000
Copy link

Hello everyone. I have a Zenbook UM3402YAR (with AMD Ryzen). I am running Ubuntu 23.10 and have tried a lot of proposals to get the sound working, but have failed every time so far. I am not a very profound user when it comes to applying all the steps that are written here (i.e. modifying different files, patching kernel etc) and would really appreciate all the help from anybody willing to help me.
The last thing that I've tried is that I have installed and am running the latest linux kernel (6.6.4) as this laptop model should be included in version 6.5.6 (and I guess above) but no success so far.

The current output of the "dmesg | grep cs3" command is:
[ 2.025236] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 2.026834] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[ 2.060481] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2

Appreciate all/any help you could provide...

@amritk
Copy link

amritk commented Dec 7, 2023

@starman45 check the dmesg to ensure you are not seeing "Falling back to default firmware" for the CS35 device. When messing around with firmware files I had a typo in the name and one of the amplifiers got default firmware files loaded and exhibited much lower volume than the other. NOTE as well that I have updated the gist to not reuse the firmware for the "10431e12" device but instead grab the files from Windows. This has improved my sound quality to match what I was seeing in Windows.

hey @masselstine I have this exact issue. I followed the steps in ssdt_csc3551.dsl to get the sound working again. Now it works but it is really quiet and I get the Falling back to default firmware error. Unfortunately I nuked windows as soon as I got the laptop. Do you think I should re-install windows to grab the files?

Thanks btw! 👍 I was about to return the laptop since i Just got it but this gist showed that there is a path forward.

@masselstine
Copy link
Author

@starman45 check the dmesg to ensure you are not seeing "Falling back to default firmware" for the CS35 device. When messing around with firmware files I had a typo in the name and one of the amplifiers got default firmware files loaded and exhibited much lower volume than the other. NOTE as well that I have updated the gist to not reuse the firmware for the "10431e12" device but instead grab the files from Windows. This has improved my sound quality to match what I was seeing in Windows.

hey @masselstine I have this exact issue. I followed the steps in ssdt_csc3551.dsl to get the sound working again. Now it works but it is really quiet and I get the Falling back to default firmware error. Unfortunately I nuked windows as soon as I got the laptop. Do you think I should re-install windows to grab the files?

Thanks btw! 👍 I was about to return the laptop since i Just got it but this gist showed that there is a path forward.

You could potentially find driver downloads from Asus to avoid having to reinstall windows. Installing Windows into a QEMU/KVM guest is another option. I would share the files myself but I haven't reviewed the license to ensure this is possible. I hope to work with the Linux device driver author as they work for Cirrus Logic and could submit them to the Linux firmware team without license concerns.

@hmyzna
Copy link

hmyzna commented Dec 9, 2023

Thank you, found it all useful for making the sound louder on UM3504DA, didn't need c:\windows\system32\csaudio, just downloaded Cirrus SmartAMP driver installer from my laptop's support page. Ran the installer on my windows machine, and it had an option to extract to a directory, which I chose. In the directory I extracted the driver to, I was able to find 104318D3_221223_V01_smth and halo_cspl_RAM_revB2_29.80.0.wmfw. I moved them to my laptop, renamed them according to your script and copied them to /lib/firmware/cirrus/.

@kelna
Copy link

kelna commented Dec 15, 2023

Well yes, it worked. But I have a strange issue on my UM3402YA. Sometimes (very often) there is no sound after waking up from sleep. I couldn't yet figure out in what circumstance this occurs because sometimes I have sound after waking up. But if it goes away, I cannot bring it back, only by rebooting. Does anyone experience this?

I see this as well. Sometimes adjusting the volume is enough to correct things. It is not unusual for Linux device drivers to run into issues with suspect/resume, it is just a matter of someone with the skills and time to dig into the issue. Maybe one day I will have the time.

If you indeed find the fix for that, I would be very much willing to donate some BTC in the ballpark of a couple dozen dollars (which is not much, but I'm poor). You already helped a lot but that would really put the icing on the cake.

Anyways, if you have any alternative workaround, I'm insterested. I was thinking about restarting the sound service (pipewire) but nothing worked so far as a quick fix, only full system reboot which is very cumbersome.

@ransur0t
Copy link

ransur0t commented Dec 18, 2023

Well, after an initial success with building the firmware from cloning @farfaaa 's repo, I've since learned that I may have a bit more to do!

dmesg output as follows:
$ dmesg | grep cs3
[ 26.958770] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 26.965984] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[ 27.021142] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 27.215692] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Falling back to default firmware.
[ 27.219611] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[ 27.219615] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
[ 27.721389] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
[ 27.722586] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot.bin: v0.58.0
[ 27.722590] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS35L53\Fixed_Attenuation_Mono_48000_29.78.0\full\Fixed_Attenuation_Mono_48000_29.78.0_full.bin
[ 27.750115] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[ 27.750661] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Falling back to default firmware.
[ 27.753201] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[ 27.753204] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot.wmfw: Fri 24 Jun 2022 14:55:56 GMT Daylight Time
[ 28.248621] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.58.0, 2 algorithms
[ 28.249818] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot.bin: v0.58.0
[ 28.249824] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: e:\workspace\workspace\tibranch_release_playback_6.76_2\ormis\staging\default_tunings\internal\CS35L53\Fixed_Attenuation_Mono_48000_29.78.0\full\Fixed_Attenuation_Mono_48000_29.78.0_full.bin
[ 28.276814] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])

I've got a dual boot setup on my UM3402YAR, so I've booted into windows and copied over the contents of c:\windows\system32\csaudio and also downloaded and extracted the the SmartAMP_Cirrus driver files from Asus. I'll need to review the methods reported in this thread to determine the best course of action. Any pointers in this regard would be very much appreciated!

For reference, sound is good and stable, but certainly much lower volume than Win 11 OS and there is also the "falling back to default firmware" issue referenced herein.

EDIT
I ran the compress-rename.sh script on the firmware pulled from c:\windows\system32\csaudio and copied it to /lib/firmware/cirrus. Rebooted and sound levels are on par with Windows, dmesg shows no errors!

$ dmesg | grep cs3
[ 15.359141] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 15.360122] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Reset line busy, assuming shared reset
[ 15.400173] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2
[ 15.544588] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware version: 3
[ 15.544593] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[ 16.042289] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[ 16.043457] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683-spkid1-l0.bin: v0.43.1
[ 16.043460] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_L_tuning_IDYC_ReDC_Finish_PICL_RTL_0304.bin
[ 16.144080] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
[ 16.145587] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware version: 3
[ 16.145594] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683.wmfw: Fri 27 Aug 2021 14:58:19 W. Europe Daylight Time
[ 16.643453] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Firmware: 400a4 vendor: 0x2 v0.43.1, 2 algorithms
[ 16.644644] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-10431683-spkid1-r0.bin: v0.43.1
[ 16.644650] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: spk-prot: C:\Users\tyang\Desktop\Product Setting\SmartAMP\ASUS\ASUS_Zenbook\UM3402\Tuning_Release\220304\ASUS_UM3402_R_tuning_IDYC_ReDC_Finish_PICL_RTL_0304.bin
[ 16.745131] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])

@dorian-cruveiller
Copy link

HI, i have another laptop using this chip and is connected in I2C too. Everything works great except when rebooting, i have the the following error:

Failed waiting for OTP_BOOT_DONE: -121

I tried to change reset-gpios like this:

Package () { "reset-gpios", Package () {
    SPKR, One, Zero, Zero,
    SPKR, One, Zero, Zero
} },

I also tried 0x02 and 0x03 but none of these work when rebooting.

Any help would be very appreciated.

@nullptroma
Copy link

I don’t want to install Windows on a laptop, could you send me all the firmware files that need to be placed in /lib/firmware/cirrus?

@ransur0t
Copy link

Try this link to Cirrus firmware for the amp:

https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus

@nullptroma
Copy link

Try this link to Cirrus firmware for the amp:

https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus

I use it and see Falling back to default firmware. in dmesg. Volume is low

@ransur0t
Copy link

Try this link to Cirrus firmware for the amp:
https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus

I use it and see Falling back to default firmware. in dmesg. Volume is low

Did you run $ bash compress-rename.sh and place the renamed files in proper directory?

@nullptroma
Copy link

Did you run $ bash compress-rename.sh and place the renamed files in proper directory?

This script is needed to change files taken from Windows. I didn't take files from Windows because I don't have it on my laptop. I want to set up sound without Windows and ask people to send me these files

@ransur0t
Copy link

Did you run $ bash compress-rename.sh and place the renamed files in proper directory?

This script is needed to change files taken from Windows. I didn't take files from Windows because I don't have it on my laptop. I want to set up sound without Windows and ask people to send me these files

I believe the files posted in the firmware repo are all named *.bin, hence the need for rename them per comment above.

@nullptroma
Copy link

nullptroma commented Jan 12, 2024

I believe the files posted in the firmware repo are all named *.bin, hence the need for rename them per comment above.

It work! Thank you!

@nullptroma
Copy link

@ransur0t
Copy link

ransur0t commented Jan 13, 2024 via email

@asp345
Copy link

asp345 commented Jan 15, 2024

With kernel 6.7, a patch (https://lore.kernel.org/all/20231218151221.388745-1-sbinding@opensource.cirrus.com/ )is added for cs35l41 which fixes sound on many Asus laptops. Unfortunately this device (UM3402YAR) has PCI_SUBSYS_ID=1043:1683 (result of udevadm info /sys/bus/pci/devices/0000:00:00.0 | grep PCI_SUBSYS_ID) and it does not appear here. https://github.com/torvalds/linux/blob/master/sound/pci/hda/cs35l41_hda_property.c
Adding correct values to that table might fix speakers. But I don't know what are the correct values for reset_gpio_index, spkid_gpio_index, cs_gpio_index, boost_ind_nanohenry, boost_peak_milliam, boost_cap_microfarad. Last three are probably not needed as this device uses external boost.

@nullptroma
Copy link

Modified script + .bin files from https://github.com/CirrusLogic/linux-firmware/tree/main/cirrus, run script and move .zst to /lib/firmware/cirrus

Oh
I can see cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: DSP1: Algorithm coefficient version 29.63.1 but expected 29.85.0 In dmesg | grep CSC, mistake versions. How should files are naming for new version from cirrus github?

@Targa250R
Copy link

Targa250R commented Feb 5, 2024

Good news, the UM3402YAR (device 10431683) has been added to the table in sound/pci/hda/cs35l41_hda_property.c for kernel 6.8-rc3 as per this commit.

I don't own a UM3402YAR, but rather its 2022 predecessor UM3402YA with the Ryzen 5825U (device 10431E12). Does anyone know how I should go about contacting a kernel maintainer to have this model added to the table? I am not familiar with the LKML and I am assuming it is bad etiquette to directly email one of the persons listed in the patch comments. I built a kernel using the GPIO values from the UM3402YAR and it seems to be working fine with no error messages on the UM3402YA.

@masselstine
Copy link
Author

@Targa250R I can prepare a patch, pass it to you to verify and would be fine submitting it to the kernel.

@masselstine
Copy link
Author

@Targa250R I am preparing the patch. In your initial testing did you also require the I2C quirk change? I am pretty sure you would not as that device already has a quirk listed (just a different laptop model #). But I would like to confirm.

@Targa250R
Copy link

@masselstine The UM3402YA quirk has been mainlined since kernel 6.2-rc8, but someone made an error when editing the Realtek patch file for kernel 6.7-rc7 and accidentally swapped the device IDs for the UM3402YA (10431E12) and the UM6702RA (10431EE2). There is a patch proposed as of yesterday to correct this issue, but it is functionally trivial since both devices use the same quirk.

@Targa250R
Copy link

@masselstine It looks like that same patch proposal also inserts the UM3402YA device ID to the table in the CS35L41 property file, so the kernel maintainers are already reviewing it for inclusion with kernel 6.8.

I thank you very much for your assistance and for your many efforts over the past year to help us all get the sound hardware working in these devices!

@masselstine
Copy link
Author

@Targa250R , perfect. Prior to sending a patch out it is good to look on the mailing lists for similar submissions, so I would have seen this (hopefully). Thanks for saving me the trouble and pointing it out. I am glad things will be sorted once Linus gets the next release out or the commits are back-ported by the stable kernel folks.

@nullptroma
Copy link

After the release of 6.8, when everything works, will it be necessary to somehow remove the current fixes in the form of renamed drivers?

@zonkypop
Copy link

Upgraded the kernel to 6.8-rc5 and sound is working for the first time 🥳

@nullptroma
Copy link

Upgraded the kernel to 6.8-rc5 and sound is working for the first time 🥳

but the sound is quiet. Cisco .zst files are still needed, aren't they?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment