SGTL5000 Codec Not working with Linux 5.4 on IMX8X

I am using the Colibri IMX8X with Boot to Qt (b2qt). I have been creating my own custom image tailor to my hardware and software needs by adding my own meta layer in yocto, using the Qt 5.15.x b2qt configurations as a base.

When I started with Qt 5.15.4, it was building toradex-linux 4.14-2.3. With that build (and using the prebuilt image from Qt for IMX8 the audio codec worked fine out the box. I tried to recreate the build based on Qt 5.15.7, but now Qt is trying to build against 5.4. Now using my own device tree or the colibri-eval-v3 device tree I can’t get the codec to actually produce sound.

I’ve been down a path of trying to find the differences in the device trees, but since everything was refactored heavily between versions it’s hard to find any clear mistakes. I was thinking there may be something with DMAs or even a bug in the actual SGTL5000 driver since that’s clearly different and now provides more controls in the alsamixer, but I mostly want someone else to test and confirm that this is indeed broken.

Greetings @Patricks,

I just did the following test:

  • Flashed our latest BSP 5.5.0 Quarterly image on a Colibri i.MX8X. Specifically I flashed to the multimedia reference image to have access to all the audio libraries.
  • After booting and logging into the image I ran aplay sound/Gong.wav.
  • I was able to clearly hear the sound playback on the headphones I have attached.

There was no other configurations and the default device tree was used (eval device tree). Far as I can tell there’s no issues with audio playback on this codec.

For further information this is the kernel version of this release:

root@colibri-imx8x-06750825:~# uname -a
Linux colibri-imx8x-06750825 5.4.154-5.5.0+git.c65f1622951c #1 SMP PREEMPT Mon Jan 3 15:58:01 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

It’s unclear what exact version of kernel 5.4 you are on.

Best Regards,
Jeremias

@jeremias.tx Thank you for the sanity check. I have tried kernel version 5.4.129-0+git.022cb949c6ec, and 5.4.154-0+git.c65f1622951c.

Could you also check to see if an error I’m seeing is a red herring? (does this come up in your working image or not?) I get the following in dmesg on boot:

[    2.643380] debugfs: Directory '59040000.sai' with parent 'imx8qxp-sgtl5000' already present!
[    2.652802] asoc-simple-card sound-card: sgtl5000 <-> 59040000.sai mapping ok
[    2.660163] asoc-simple-card sound-card: ASoC: no DMI vendor name!

I was trying to figure out what I did wrong in my custom DTS, thinking that was the problem, but I get the same message when using the -colibiri-eval-v3.dtb. So then I started trying to dig into general dtsi issues or kernel config issues.

Finally, do you have any insight into when the Colibri-IMX8X will be considered full production and have a stable BSP release?

Thanks in advance!

Those same dmesg logs show up on my setup as well. I don’t think they indicate any kind of error or issue.

As for Colibri i.MX8X roadmap. The hardware roadmap on the product page: NXP i.MX 8X Computer on Module - Colibri iMX8QXP - Arm Cortex A35

As seen we don’t have a hard date yet on when this product will be elevated to “Volume Product” status. However the software itself is fairly stable. I’m referring to the latest BSP 5 release of it.

Best Regards,
Jeremias

Thanks for that. Final question to help me find the difference creating the problem. I assume that the link below is the right way to build the reference image you used to test the sound with.

You could use that link to build a Yocto image.

However for just the reference images themselves we already provide pre-built binaries that an be installed via our Easy Installer: Toradex Download Links (Torizon, Linux BSP, WinCE and Partner Demos) | Toradex Developer Center

Of course if you need to customize or dig into what goes into the reference images you’ll need that article you’re referencing.

Out of curiosity the OS image you’re currently working with did you build it yourself or did it come from Qt?

Best Regards,
Jeremias

Thanks again to @jeremias.tx for the sanity checks. I finally found the problem. Hopefully I can document it clearly enough to help future people hitting this issue.

The problem is a bad /var/lib/alsa/asound.state file that I was injecting into my build in an attempt to make the system start up with the desired sound mixer settings. I just configured what I wanted in a an older b2qt reference image for the IMX8, rebooted to get the settings to be written to the asound.state file, then grabbed that file and put it in my meta layer to jam that specific file in my image in place of any default.

I’m guessing that with the latest Linux build especially that the driver is different, has different options/configs/etc (I have yet to dig into these details) and so the loading of the asound.state was getting the mixer config into a bad state or some such thing. If any alsa experts want to chime in on how best to accomplish this properly in a yocto build, that would be great, but for now my plan will be to remove this file from my build, create a new image, repeat my old process and inject that new file again. It’s certainly ugly, but I bet it’ll work.

Also if anyone is interested in debugging the details, let me know and I’ll post the good and bad asound.state files.

Thank you for sharing your findings and glad you were able to nail down the issue.