galliumos-distro
galliumos-distro copied to clipboard
Sound on Kaby Lake
After the success of ticket #379 I thought I'd create one for us Kaby Lake users.
I have an Acer Chromebook Spin 13 with an i5-8250u (board: Nami) running a different distro (FC30) with a recent kernel (5.3.x) but I got sound to work. If your kernel conf doesn't include kbl_da7219_max98357 as a module, you should probs. recompile it with that as m or y.
This is what I did:
- blacklist snd_hda_intel in /etc/modprobe.d
- Copy over
dsp_lib_ghw_spt_release.bin
from ChromeOS recovery image to /lib/firmware - Copy over all the firmware files in /lib/firmware/intel (ChrOs) to /lib/firmware/intel
- Copy over
9d71-GOOGLE-NAMIMAX-0-tplg.bin
from ChromeOS recovery image to /lib/firmware - Create a directory
kblda7219max.akali360
in /usr/share/alsa/ucm/ - Add HiFi.conf in this directory (attached, extracted from ChromeOS and updated to new ALSA vocabulary)
- Add kblda7219max.akali360.conf in this directory
Comment "Akali360 internal card"
SectionUseCase."HiFi" {
File "HiFi.conf"
Comment "Default"
}
- Reboot
- Run
alsaucm -c kblda7219max.akali360 set _verb HiFi set _enadev Speaker ; pulseaudio -k
- Play something on youtube :-) speakers work!
- Run
alsaucm -c kblda7219max.akali360 set _verb HiFi set _disdev Speaker ; alsaucm -c kblda7219max.akali360 set _verb HiFi set _enadev Headphone ; pulseaudio -k
for headphone jack
note that since github doesn't let me upload .conf, I uploaded the file with the extension .conf.txt rename that before you drop it in /usr/share/alsa/ucm/ HiFi.conf.txt
I hope someone with more moxy in automation can set-up something similar to the skylake-firmware package that extracts sound stuff & all for GalliumOS on Kaby Lake .
I have an Acer Chromebook Spin 13 with i5-8250u as well, but isn't that AKALI360 board? Furthermore I tried to follow your instructions, however I couldn't mount the root partition (I suppose that's partition 3 or ROOT-A) in my OS, it always returned an error (something with bad fs or bad superblock, Gparted said it was improperly formatted, but couldn't fix it). I used the shell script for creating the image, is there any difference to the Chrome extension?
Thanks for your effort to resolve this issue!
First question: at step #1 I don't find a modprobe.d file in the etc folder. Should I create one?
Thanks!
Thanks for your effort to resolve this issue!
First question: at step #1 I don't find a modprobe.d file in the etc folder. Should I create one?
Thanks!
https://askubuntu.com/questions/110341/how-to-blacklist-kernel-modules
modprobe.d is a directory. Just write blacklist snd_hda_intel
into a file inside it.
Did you succeed getting the firmware out of the recovery image? If yes, how? Apparently the root partition uses EXT4 “features” only supported by ChromeOS, or at least not by mainstream e2fsprogs
therefore it is not mountable.
Thanks @FantasyCookie17 for the clarification.
I created a recovery image in via the chrome app and then was able to mount the USB drive in GalliumOS. In the disk volume, there's a single folder named un-encrypted, and a single file named vmlinuz_hd.vblock. The folder has some sub-folders, with the final folder /unencrypted/import_extenstions/extensions having a bunch of .crx files. This doesn't seem right.
@chrysophylax , I think we could really use your help at this point to clarify this procedure in more detail. I'm willing to help test and troubleshoot (and even write up a detailed procedure), but we need your help!
Thanks!
A quick follow-up: I also found the ROOT-A volume on the recovery image, but it also fails to mount, with the following error:
Error mounting /dev/sda3 at /media/chrx/ROOT-A: wrong fs type, bad option, bad superblock on /dev/sda3, missing codepage or helper program, or other error.
@JulesArcher I think I was able to mount some partition, maybe the one you mentioned was one them. And I got exactly the same error with the ROOT-A partition. As I said above, some other program ((GNOME?) disks or Gparted, I think) said it had “unsupported features”.
I've done some googling on the above error and found a thread that suggests that a filesystem still needs to be created:
https://unix.stackexchange.com/questions/315063/mount-wrong-fs-type-bad-option-bad-superblock
@FantasyCookie17, Can you make any sense of this?
Thanks!
@JulesArcher I think I was able to mount some partition, maybe the one you mentioned was one them. And I got exactly the same error with the ROOT-A partition. As I said above, some other program ((GNOME?) disks or Gparted, I think) said it had “unsupported features”.
I took a look and there are at least 2 issues with mounting that partition. It does have unsupported features enabled on the file system that appear to be related to ChromeOS. Using tune2fs you normally can disabled those features, but when you run that it complains about not finding a valid superblock.
I can see super blocks in the by using dumpe2fs so there must be extra data in those superblocks that our tools don't understand.
I think we're going to need an adult.
@JulesArcher Making a new file system on a partition will make the data that was previously on it inaccessible afaik (data that wasn’t completely wiped with 0s or random bits can be recovered however, but that’s a rather difficult procedure, and is not affected by FS anyway afaik). It’s basically what I said about unsupported features, and apparently also what @AngryEngineer mentioned - thank you for that, I didn’t know about these tools.
Weird there’s no one else looking into this issue and writing something. I hoped that at least the GalliumOS devs knew more... And @chrysophylax seems to have disappeared, both here and on Reddit.
@FantasyCookie17 I've been looking at this issue as a whole and although @chrysophylax was able to get this working using the binaries form ChromeOS, it might not be the end all solution here. According to MrChromeBox the driver firmware doesn't seems to be an issue (I can confirm the default kernel seems to have no issues with drivers.) Seems like the missing piece here is the encoder information and the ALSA topology. If we can figure that out without using binaries from ChromeOS then we might get some more traction.
Heyo, I've been off radar abroad and from illness. Back now!
I have successfully followed these steps earlier https://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices/workaround-for-battery-discharge-in-dev-mode#TOC-Modify-the-recovery-image-so-we-can-mount-it to modify a recovery image back when it discharged. It should work for you guys who cannot mount the recovery image's root partition.
@chrysophylax Thank you, orobably should have simply used a search engine myself. I tried your instructions on my own AKALI360 running Void Linux, and since step 7, the following error started appearing periodically on the virtual, non-graphical terminals:
DMAR: DRHD: handling fault status reg 3 DMAR [DMA READ] Request device [00:1f.3] fault addr 0 [fault reason 06] PTE Read access is not set
Trying step 8 or 10, I got something like this:
ALSA lib parser.c:1508:(get_card_long_name) no soundcards found... ALSA lib parser.c:1306:(parse_master_section) unknown field ``��ҧ in master section ALSA lib parser.c:1306:(parse_master_section) unknown field ``��ҧ in master section ALSA lib parser.c:1313:(parse_master_section) error: use case missing file ALSA lib main.c:957:(snd_use_case_mgr_open) error: failed to import kblda7219max.akali360 use case configuration -22 alsaucm: error failed to open sound card kblda7219max.akali360: Invalid argument E: [pulseaudio] main.c: Failed to kill daemon: No such process
(I just wrote a double ` at some places here as there was originally a single one interrupting the code block and not being shown)
I installed alsa-utils, alsa-plugins-pulseaudio, alsa-firmware and alsa-lib after step 7. Perhaps there are more dependencies needed? I already had pulseaudio before.
I also used some chmod on some of the config and firmware files/directories as I wasn’t able to read/access them as a normal user. I made none of them executable, except for the directories (as that is needed for cding into them).
Last but certainly not least, after following your instructions, the fan was always spinning rather loudly and when I tried shutting it down through a command or the power button, the OS did stop to run, but neither the fan nor the power LED turned off, and I had to force shutdown by pressing the power button for a longer time.
I also get something like the following error at boot: kblda7219max: ASoc: failed to init-link ssp1-soc: -512
The fan doesn't turn up abnormally much anymore, however it still doesn't shutdown properly. Btw, I have the Intel ME disabled.
So apparently I needed to add intel_iommu=off
to the GRUB default command line arguments in /etc/default/grub and then update-grub
. Now I don't have my fan turning up that much anymore, and it shuts down like it normally would as well. However when doing step 8 or 10, I still get the same errors, and I still get that failed to init-link error
above at boot. I now also get another error sometimes: Kbl Audio Port: ASoc: no backend DAIs enabled for Kbl Audio Port
. When I call pulseaudio
, the following is returned several times: E: [pulseaudio] module-alsa-card.c: Failed to find a working profile. E: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="0" name="platform-kbl_da7219_max98357a" card_name="alsa_card.platform-kbl_da7219_max98357a" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed. E: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files
After that a message that an error occured more than 5 times in 10s or something.
Calling pulseaudio --start
returns nothing, entering pulseaudio
then will give me E: [pulseaudio] pid.c: Daemon already running. E: [pulseaudio] main.c: pa_pid_file_create() failed.
(I suppose that's normal behavior.) Trying to play some sound with aplay
, e.g. sudo cat /dev/input/mouse0 | aplay
will return Playing raw data 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono aplay: set_params:1405: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: U8 SUBFORMAT: STD SAMPLE_BITS: 8 FRAME_BITS: 8 CHANNELS: 1 RATE: 8000 PERIOD_TIME: (85312 85313) PERIOD_SIZE: (682 683) PERIOD_BYTES: (682 683) PERIODS: (3 5) BUFFER_TIME: 341250 BUFFER_SIZE: 2730 BUFFER_BYTES: 2730 TICK_TIME: 0
I have both the alsa and pulseaudio services enabled on my Void Linux installation.
I'd be happy to provide more information in case anyone needs to know more. Is the output of dmesg
needed/appreciated? (Edit: probably it isn't, just contains normal wifi information and that no DAIs enabled error
)
Seems to be related to https://askubuntu.com/questions/886512/baytrail-audio-port-asoc-no-backend-dais-enabled-for-baytrail-audio-port/978059, but the "solution" provided there didn't help, and apparently it didn't help the one who replied either.
Maybe there 's another package I need to install or some service I should run? Any specific permissions I need to set for the firmware? Some special ALSA config apart from what was provided needed?
Hi,
I have unfortunately no idea what could be messing up your installation. As mentioned, it seems to run fine on all the recent kernels (5.3.x) on Fedora Linux for me. I haven't had it break since I got it working despite several updates.
I have not disabled Intel ME although I doubt that could be affecting the audio bits.
I even asked on Reddit (r/linuxquestions) and Unix Stackexchange. no answer on either so far...
@chrysophylax How did you fix the screen rotated 180° issue on Fedora though? I once tried it and that was a problem I had (in GNOME), had to do something with systemd’s iio-sensor-proxy, which has some kind of 2d matrix for config, but no documentation on what the parameters do.
I guess I’m going to try OpenBSD soon, as this is an ALSA issue probably (ALSA being specific to Linux), maybe that’ll fix it (if I load the same firmware). I have at least read that OpenBSD works better on laptops than FreeBSD in terms of hardware support, so at least there’s a small chance (although ChromeOS is based on Gentoo).
@FantasyCookie17 , I just uninstalled iio-sensor-proxy. I have no use for a rotated screen.
Anyone got this working on Ubuntu based distros?
OpenBSD doesn't even boot properly, and the ALSA configuration wouldn't work there either of course. So I'll try QubesOS soon... It's based on Fedora, so maybe I'll have more luck there.
After trying various distributions with various issues (even during install or with booting post-install, including Fedora), I now tried Manjaro. At least it boots, however I didn't get the sound either. I get other errors there as well and I'm not sure how to fix. First it said the syntax field was not defined, which (I think) was fixed by adding Syntax 2
to the top of the file. At least that's what some other configs contained. The directory was ucm2
and not ucm
there. And then I got some hardware not found error. The kernel modules were called differently, and I didn't think this would be a problem as maybe they were called different anyway due to newer kernel (5.4)... I guess I'll try to install Fedora again... I don't appreciate that I first have to install it to external media because of missing F2FS support in installer however (even with Blivet). It'd be nice if this could somehow be adopted into standard alsaucm configuration somehow. Maybe do a PR/issue so the config, which apparently doesn't work on some distros, can be fixed by their devs (or by the distributors)? And apart from the sound, we need to get that Raydium TS firmware somehow to get the touchscreen working. The one in the ChromeOS image is just a (sym/hard)link which is broken. Note that the sound is much more important to me and probably most users other users as well than the touchscreen.
I now tried Fedora as well (31). It doesn’t even have an alsaucm
command, and afaict no way to install it (the alsa-ucm package doesn’t contain it). Also there are only generic and Skylake DA7219 modules in the default kernel, not the one OP mentioned.
So basically, if anyone has a working fix on any distro, or managed to apply what @chrysophylax did on any distro, please share. Maybe Gallium devs could port and package this somehow?
Doesn't work on CentOS 8 with default kernel either. But again, the kernel module you mentioned is not included by default. And I currently don't have the time for Gentoo or anything like that.
EDIT: Probably I just needed to load the module via modprobe
- i t actually was there in most kernels, but I somehow totally forgot about that command. However, that doesn't change it still doesn't work for some reason. I tried it again on CentOS, as it was still installed. It still uses 4.18 kernel, but that probably doesn't matter as ChromeOS is still on 4.4 AFAIK.
Well, that's unfortunate. It stopped working on F31 at some point during the updates.
I think I fugred out why it probably stopped working. The default kernel builds by Fedora & friends now include the sof-kernel driver enabled and removes the kblda7219max driver which unfortunately leaves us Kaby Lake people without any soundcards recognised by the kernel.
$ cat /proc/asound/cards --- no soundcards ---
Add to that that alsaucm for many has migrated to using the ucm2 format, we need to migrate the configuration file as well. My next go-to will be to consider switching from Fedora to a distro that lets you rebuild your kernel in a more friendly way...
@chrysophylax Would you be able to share the bin files you mentioned above? I made the mistake of not making a recovery image for my system so I don't have access to them.
Edit: I found it at https://cros-updates-serving.appspot.com/
@chrysophylax I've followed your instructions but ALSA seems to be having problems finding the device. I've also tried doing modprobe snd-soc-kbl_da7219_max98357a
and that didn't seem to help. alsa force-reload
also. What is the exact name of the kernel config option for the driver? It seems that it's already enabled, but I've also only seen the A variant and not the plain one.
These are the only options I could find that weren't enabled, but they didn't have the KBL in them:
SND_SOC_MT8183_DA7219_MAX98357A SND_SOC_MT8183_MT6358_TS3A227E_MAX98357A
uname -r
5.5.6-050506-generic
These are the only options I could find that weren't enabled, but they didn't have the KBL in them:
SND_SOC_MT8183_DA7219_MAX98357A SND_SOC_MT8183_MT6358_TS3A227E_MAX98357A
as indicated in the name, those drivers are for the Mediatek MT8183/6358 SoCs
snd-soc-kbl_da7219_max98357a = Kabylake SoC, DA7219 codec, Maxim 98357a amplifier. Not all Kabylake Chromebooks use that combination; some use the Maxim 98927 or 98373
@MrChromebox Thank you. Should I try those other drivers? I had assumed since my computer model and CPU model was exactly the same as theirs that it would have the same audio hardware but I know that manufacturers will sometimes change parts around midlife.
@empathicqubit no, I'm saying that the MT8183 drivers are completely not applicable. Your Kabylake device has one of the 3 setups I listed, and is likely all 3 drivers are included together in all recent kernels
@empathicqubit I've taken a break on patching the alsa configuration files to the new ucm2 format as I've not much free time and there doesn't seem to be much documentation available on how to port old->new. I know the SOF team does have proper Kaby Lake support on its to-do list. You can follow the feature request on https://github.com/thesofproject/sof/issues/1899