Dietpi: Rock64 | 3.5mm audio jack not working

[lupa18]

Creating a bug report/issue

Required Information

• DietPi version | 6.21.1
• Distro version | stretch
• Kernel version | Linux DietPi 4.4.77-rockchip-ayufan-136
• SBC device | Rock64 (aarch64)
• Power supply used | 5V 1A
• SDcard used | SanDisk ultra

Steps to reproduce

1. Update dietpi using: sudo dietpi-update
2. Try to play some sound

Expected behaviour

Hear sounds

Actual behaviour

Can't hear anything

Extra details

Log says:
Feb 08 20:03 : exception: Failed to open "DietPi Alsa" [alsa]
Feb 08 20:03 : exception: nested: Failed to open ALSA device "default": Permission denied

So I try to change sound card permissions and works !
sudo chmod -R a+rw /dev/snd

But after next update, the problem appears again.

[MichaIng]

@lupa18
Thanks for your report.

Which sound card do you use, or native 3.5mm jack output?

[lupa18]

Native 3.5mm

thank you!

[sChUhBiDu]

This fixed it for me as well!

Why is the sound so quiet? can you make a louder somehow? Even with 100% its not loud.

[MichaIng]

@lupa18 @sChUhBiDu
Did you try to play sound via MPD? Then it is most likely related to: https://github.com/Fourdee/DietPi/issues/2462

Solution in this case would be:

sed -Ei '/^(user|group)[[:blank:]]/d' /etc/mpd.conf
sed -i '/^Group=/d' /lib/systemd/system/mpd.service
G_CONFIG_INJECT 'User=' 'User=mpd' /lib/systemd/system/mpd.service '\[Service\]'
G_CONFIG_INJECT 'PermissionsStartOnly=' 'PermissionsStartOnly=true' /lib/systemd/system/mpd.service '^User=mpd'
usermod -a -G audio,dietpi mpd
systemctl daemon-reload
systemctl restart mpd

This is safer then chmod -R a+rw /dev/snd and of course boot persistent.

[lupa18]

Perfect ! I will try.

Only this little fix: first line, at the end should be: /etc/mpd.conf

[MichaIng]

@lupa18
And did it solve your issue? As this is very likely I will mark this as closed. However feel free to reopen if required.

[lupa18]

yes, It works!! ... will dietpi include these changes?

[MichaIng]

@lupa18
Already included in the current Beta: https://github.com/MichaIng/DietPi/blob/beta/CHANGELOG.txt#L46
Release will be soon, as long no further bugs are reported 😃. You can help testing if you want: https://github.com/MichaIng/DietPi/issues/2632

[lupa18]

Sorry, I think it was solved, because mpd begin working, but sound really don't coming ount. Then I search for logs and found this:

exception: nested: Failed to open ALSA device "default": Operation not permitted

(I'm using dietpi's fresh install)

[lupa18]

I have availability to help on this, but not sure how to proceed, where is syslog and things like that.

[lupa18]

And from dmesg, I got:

[    3.389176] of_get_named_gpiod_flags: can't parse 'simple-audio-card,hp-det-gpio' property of node '/spdif-sound[0]'
[    3.389187] of_get_named_gpiod_flags: can't parse 'simple-audio-card,mic-det-gpio' property of node '/spdif-sound[0]'

[MichaIng]

@lupa18

exception: nested: Failed to open ALSA device "default": Operation not permitted

(I'm using dietpi's fresh install)

Since the error looks quite clear, just to verify:

• Did you either update to the current Beta or apply the steps above: https://github.com/MichaIng/DietPi/issues/2522#issuecomment-466820376
• The fix is not yet released, so is not included in fresh DietPi installs.

The dmesg error is about GPIO/SPDIF, so is not related to your 3.5mm jack.

[lupa18]

I'm using: v6.21.1 | Rock64 (aarch64)

I applied comment above, but I think second line has an error. Then I tested again by adding manually Group=audio but can't reproduce nothing trough jack output.

[MichaIng]

@lupa18
The second line as desired should remove the Group= entry from the systemd unit. But adding Group=audio does not harm as well, it just has no effect since the mpd user is already member of the audio group by line 5.

Hmm and your OT solution sudo chmod -R a+rw /dev/snd does not help as well?

[lupa18]

No, that "solution" doesn't work, and no way to hear anything.

When I go to dietpi-config I see:

• default: hw:0,0
• hw:0,0 HDMI
• hw:1,0 SPDIF
• usb-dac: ..

Is correct to configure hw:1,0 SPDIF for use jack output ?

[MichaIng]

@lupa18

Is correct to configure hw:1,0 SPDIF for use jack output ?

It depends if you need a digital (SPDIF) or analogue (default) signal. Usually if you attach a speaker directly to the jack it requires an analogue signal, but it is not listed in your case.

Just found that by default the required kernel module is not enabled. Please try:

modprobe sunxi_codec
aplay -l
aplay -L

I hope you see the 3.5mm jack (analogue output) then. If yes, do:

mkdir -p /etc/modules-load.d
echo 'sunxi_codec' > /etc/modules-load.d/sunxi_codec.conf

And you can then select this device via dietpi-config > Audio as well, respectively through MPD.

[lupa18]

@MichaIng

It seems that module is not there:

$ modprobe sunxi_codec
modprobe: FATAL: Module sunxi_codec not found in directory /lib/modules/4.4.174-rockchip64

[MichaIng]

@lupa18
Hmm please show result of:
find /lib/modules/$(uname -r) -type f -name '*.ko' | grep 'sunxi'

[lupa18]

@MichaIng
No results :(

[MichaIng]

@lupa18
Ah sorry 4.4.174-rockchip64 means you are on the new ARMbian-based image now.

Hmm least list active modules first:
lsmod

And also again print all found sound devices:

aplay -l
aplay -L

I just searched through the image an just found following optional modules:

snd-soc-rockchip-i2s-tdm # I2C sound out
snd-soc-rockchip-hdmi-dp # Digital HDMI out (?) or something
snd-soc-rockchip-hdmi-analog # Analogue HDMI out

Can't find a 3.5mm jack module, so either I am blind or it is hard coded into the kernel (thus should be enabled by default).

---

Just found: https://forum.armbian.com/topic/9895-no-audio-on-35-av/
So it looks like an ARMbian/manufacturer-side issue...

[lupa18]

@MichaIng

Hmm least list active modules first:
lsmod

# lsmod
Module                  Size  Used by
bcmdhd               1245184  0
af_packet              40960  8
8188eu                864256  0
gpio_ir_recv           16384  0
rk_vcodec              65536  0
ip_tables              24576  0
x_tables               28672  1 ip_tables
autofs4                40960  2

And also again print all found sound devices:

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDMI], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SPDIF [SPDIF], device 0: ff030000.spdif-dit-hifi dit-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

aplay -L

# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
equal
sysdefault:CARD=HDMI
    HDMI,
    Default Audio Device
dmix:CARD=HDMI,DEV=0
    HDMI,
    Direct sample mixing device
dsnoop:CARD=HDMI,DEV=0
    HDMI,
    Direct sample snooping device
hw:CARD=HDMI,DEV=0
    HDMI,
    Direct hardware device without any conversions
plughw:CARD=HDMI,DEV=0
    HDMI,
    Hardware device with all software conversions
sysdefault:CARD=SPDIF
    SPDIF,
    Default Audio Device
dmix:CARD=SPDIF,DEV=0
    SPDIF,
    Direct sample mixing device
dsnoop:CARD=SPDIF,DEV=0
    SPDIF,
    Direct sample snooping device
hw:CARD=SPDIF,DEV=0
    SPDIF,
    Direct hardware device without any conversions
plughw:CARD=SPDIF,DEV=0
    SPDIF,
    Hardware device with all software conversions

[MichaIng]

@lupa18
Hmm I think hw:1,0 SPDIF does not work, right? I really couldn't find any reference. The guides to enable A/V jack on Rock64 I found are all outdated since they contain the above mentioned module which does not exist anymore, as well not on official Rock64 image 🤔. I think we can currently not do more than waiting... A shame to be true, a well promoted 3.5mm jack but absolutely no documentations about it and obviously currently no chance to use it...

[lupa18]

@MichaIng
Does not work
But where can I open an issue ?

[MichaIng]

@lupa18
I just found an old issue: https://github.com/MichaIng/DietPi/issues/2153#issuecomment-431698710
It's about Pine A64, but possible that the issue affects all Pine64 SBCs.

I thought it was solved with the ARMbian image, but now I'm thinking that ARMbian might have just imported the "issue" since it is based on Ayufans kernel as well (?).

Fourdee already opened an issue: https://github.com/ayufan-pine64/linux-build/issues/65

@Fourdee
Do you remember if this was solved with ARMbian image? If you find time, could you verify that the issue is the same with Rock64? Not 100% sure since in Pine A64 it seems HDMI is at hw:1,0 so aplay -l lists at least the 3.5mm jack at hw:0,0? Here as above HDMI is hw:0,0 and 3.5mm jack is not shown at all.

---

On the other hand: https://github.com/ayufan-rock64/linux-build/pull/30#issuecomment-466604641

• So headphone (A/V) jack showed up there as hw:0...

[MichaIng]

Just checked the boot config files:

• /boot/boot.scr is the effective boot script. It loads overlays via:

for overlay_file in ${overlays}; do
    if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/rockchip/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
        echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
        fdt apply ${load_addr} || setenv overlay_error "true"
    fi
done

• /boot/armbianEnv.txt sets overlay_prefix=rockchip.
• But there are no files like: /boot/dtb/rockchip/overlay/rockchip-${overlay_file}.dtbo
• The image only contains files like: /boot/dtb/rockchip/rk3328-${overlay_file}.dtb
• Not sure if the dtbo's are created during early boot (initrd?) and then loaded if set via overlays=${overlay_file} in armbianEnv.txt, or this would not even work due to wrong patchs and/or at least overlay_prefix=rk3328 would be required?

I found /boot/dtb/rockchip/rk3328-rock64.dtb which contains a lot of features like I2s I2C GPIO UART etc. etc. and it looks like you can enable/disable each via parameter. Great that I could not find any documentation about this, or if there is a .....

Just checked the armbian-config script: https://github.com/armbian/config/blob/master/debian-config-jobs#L1025-L1079

• So indeed e.g. adding overlays=rock64 to /boot/armbianEnv.txt should load this overlay?

But the following does not fit to any of the paths above on Rock64:
https://github.com/armbian/config/blob/master/debian-config-functions#L46-L47

---

@lupa18
Could you please paste:
ls -Al /boot/dtb/{,rockchip/}overlay

[lupa18]

Hi @MichaIng , here:

root@rock64:~# ls -Al /boot/dtb/{,rockchip/}overlay
ls: cannot access '/boot/dtb/overlay': No such file or directory
ls: cannot access '/boot/dtb/rockchip/overlay': No such file or directory

[MichaIng]

@lupa18
As I though. Hmm, only possibility is that they are created as initrd during boot, but that does not match to the armbian-config file as well which is of course not exec during initrd phase.

Not 100% sure but I guess indeed the issue is due to an overlay file structure change with the latest kernel which is not correctly implemented into at least ARMbian configuration script + boot config files.

[lupa18]

ok @MichaIng at this point this is near Chinese language for me :stuck_out_tongue_closed_eyes:

Is there any other thing I can do for trying to fix it? workaround?

or, what is your recommendation? downgrade? install other OS ?

thanks in advance!

[MichaIng]

@lupa18
Sorry that this was forgotten for a while.

I think I found what is missing. Please try G_AGI device-tree-compiler and reboot.

[lupa18]

@MichaIng no problem with delay.

I installed that package, but problem persist.

[MichaIng]

@lupa18
Can you please paste output of:

fdtget /boot/dtb/rockchip/rk3328-rock64.dtb

Strange is I checked sound docs on Ayufan build docs: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/sound.md

• There aplay only lists I2S additionally (for GPIO sound modules), but can't see A/V composite there as well 🤔.

Also the discussion on the ARMbian forum didn't get further: https://forum.armbian.com/topic/9895-no-audio-on-35-av/

• Strange that there one user reports it's working on the Stretch (Debian) image but not on the Bionic (Ubuntu) one... But since both share the same kernel/bootloader I hope solutions apply to all of them.

Lets see if the inspection of the default device tree (above command) gives some hint. The file itself is blob with some strings inside like simple-audio-card and enabled/disabled, so I indeed hope that it is possible to toggle chip/board features there.

Indeed most strange that a kernel is shipped with this big change on the device tree structure (I think change from kernel module toggle to device tree overlay toggle system, like RPi did already long time ago) but nearly no documentation about how to adjust these... Looks like we have to test new base images throughout as well, but to be true man power doesn't allow to test every single feature since this would take days. Basically we rely on a functional base image, according to bootloader/kernel/firmware and chip/board features.

[lupa18]

@MichaIng that command doesn't output nothing :(

[MichaIng]

@lupa18
Ah now I found it: dtc -I dtb -O dts /boot/dtb/rockchip/rk3328-rock64.dtb

The list could be long (it is on my RPi2). The top section is most properly the interesting one that lists the aliases (names) of the available nodes (devices) in the device tree.

I e.g. found audio on RPi2. I could then check the available properties of this device and check the value of the desired property, e.g. status to check whether it's enabled or not:

2019-04-09 21:18:10 root@micha:/boot# dtc -I dtb -O dts bcm2709-rpi-2-b.dtb
...
        aliases {
                serial0 = "/soc/serial@7e201000";
                serial1 = "/soc/serial@7e215040";
                audio = "/soc/audio";
                aux = "/soc/aux@0x7e215000";
                sound = "/soc/sound";
                soc = "/soc";
                dma = "/soc/dma@7e007000";
                intc = "/soc/interrupt-controller@7e00b200";
                watchdog = "/soc/watchdog@7e100000";
                random = "/soc/rng@7e104000";
                mailbox = "/soc/mailbox@7e00b880";
                gpio = "/soc/gpio@7e200000";
                uart0 = "/soc/serial@7e201000";
                sdhost = "/soc/mmc@7e202000";
                mmc0 = "/soc/mmc@7e202000";
                i2s = "/soc/i2s@7e203000";
                spi0 = "/soc/spi@7e204000";
                i2c0 = "/soc/i2c@7e205000";
                uart1 = "/soc/serial@7e215040";
                spi1 = "/soc/spi@7e215080";
                spi2 = "/soc/spi@7e2150c0";
                mmc = "/soc/mmc@7e300000";
                mmc1 = "/soc/mmc@7e300000";
                i2c1 = "/soc/i2c@7e804000";
                i2c2 = "/soc/i2c@7e805000";
                usb = "/soc/usb@7e980000";
                leds = "/leds";
                fb = "/soc/fb";
                vchiq = "/soc/vchiq";
                thermal = "/soc/thermal@7e212000";
                axiperf = "/soc/axiperf";
                ethernet0 = "/soc/usb@7e980000/usb1@1/usbether@1";
        };
...
2019-04-09 21:22:11 root@micha:/boot# fdtget -p bcm2709-rpi-2-b.dtb audio
compatible
brcm,pwm-channels
status
pinctrl-names
pinctrl-0
phandle
2019-04-09 21:22:15 root@micha:/boot# fdtget bcm2709-rpi-2-b.dtb audio status
disabled

• disabled on my RPi is fine since I indeed did not enable any audio functionality on this headless system.

fdtput can then be used to write a value to to a specific nodes property, e.g. set status of a found audio device to "enabled". We then need to know if those are boot persistent, so written to the dtb file or, what I guess, only written to the currently loaded device tree. Since my dtb did not change until the last kernel upgrade but I switched certain devices/overlays meanwhile. So we would then need to find a way to enable/disable features via the config files, armbianEnv.txt or directly boot.cmd. Again documentation missing, or, at least I could not find it yet. On RPi it's clear an well documented about how to toggle features via config.txt.
Last resort would then be to add the required fdtput command to some boot script.

I hope we can get the A/V hack working with this and then provide infos to ARMbian and perhaps open issues on Pine64/Rock64/Ayufan GitHub repos. At best we get the info then about what needs to be adjusted on the boot configuration files to correctly and safely toggle all these features.

[lupa18]

Here is the output: rock64.log

And some extra warnings:

Warning (unit_address_vs_reg): Node /usb@ff600000 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound/simple-audio-card,dai-link@0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /sound/simple-audio-card,dai-link@1 has a unit name, but no reg property

[MichaIng]

@lupa18
Haha, I have a bunch of warnings on RPi2 as well, however everything I need works.
But yours are related to simple-audio-card. I'll eat a broom if this is not related to the audio jack issue.

I found an interesting commit to the Linux mainline kernel: https://github.com/ayufan-rock64/linux-mainline-kernel/commit/fb1e5210f6e0fb26a557de8d8abd357d2dfcb945

The Rock64 boards has analog audio jack on it. RK3328 can output
analog audio signal using I2S1 and ACODEC core.

I thought I2S is always related to the GPIO pins, but possibly this is internally connected to the A/V jack.

Now looking into the non-mainline kernel original dts file/source: https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts#L164-L186

Node "sound" is named "I2S" indeed and is the only audio related node besides SPDIF and HDMI sound. So this must be it. This whole part looks identical to your output btw. Just the format of some values is different, e.g. the source contains values like &spdif while in your output it's translated to something like this: <0x98>
I guess & marks something like a variable/place-holder for the final node addresses or such.
EDIT: Indeed it's the "phandle" values of the related "codec" and "i2s" node. Puhh learning much about about all of this here 😄.

---

But now the interesting part, please paste output of:

fdtget -p /boot/dtb/rockchip/rk3328-rock64.dtb sound
fdtget /boot/dtb/rockchip/rk3328-rock64.dtb sound status

If it does not output anything, then we can try to add/change it. But lets first do a backup of the dtb file, so you can revert at any time even if it does not boot anymore or something (by plugging SDcard to external system and copy back original dtb.

cp /boot/dtb/rockchip/rk3328-rock64.dtb /boot/rk3328-rock64.dtb_bak

!!! The following not before we checked available properties for this node and that it is indeed available as this name etc 😉.
fdtput /boot/dtb/rockchip/rk3328-rock64.dtb sound status okay

[MichaIng]

Okay another find: https://elinux.org/Device_Tree_Linux#disabled_nodes

A node is enabled if:
status == "ok"
status == "okay"
status property does not exist
Convention for disabling a node:
status == "disabled"

So adding the status "okay" as above should not have any effect 🤔.

---

Okay I think it is finally not related to the device tree but instead a kernel config parameter CONFIG_SND_SOC_RK3328: https://forum.armbian.com/topic/9021-unable-to-enable-analog-audio-on-renegade-roc-3328-cc/

• This is indeed the audio codec: https://www.cateee.net/lkddb/web-lkddb/SND_SOC_RK3328.html

Igor just did a commit based on a recent Ayufan commit that adds the mentioned kernel config: https://github.com/armbian/build/commit/58725209d970c98489a4ee5cdf085a80347c5d47#diff-af44a8beae56649725473816c7358d26R4289

Ayufan kernel default configs contain this for a long while:

• https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/arch/arm64/configs/rockchip_defconfig#L564
• https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/arch/arm64/configs/rockchip_linux_defconfig#L937

So perhaps we just need to wait until a new kernel with this new settings applied is released.

[lupa18]

First:

# fdtget -p /boot/dtb/rockchip/rk3328-rock64.dtb sound
Error at 'sound': FDT_ERR_BADPATH

then:

# fdtget /boot/dtb/rockchip/rk3328-rock64.dtb sound status
Error at 'sound': FDT_ERR_BADPATH

and I'm not sure if any other thing is needed.

[FredericGuilbault]

Is this solved ?

[MichaIng]

@FredericGuilbault
Not sure which kernel package is used on Rock64. If it's linux-image-rockchip64, then it should be solved. Current kernel version there is 4.4.180 and the issue was solved with 4.4.178.

[lupa18]

Upgrade will be enough? or I should download and flash DP again?

[MichaIng]

@lupa18
apt update && apt full-upgrade should do it. Check that a kernel package update is included (linux-image-rockchip64) and reboot afterwards to load it.

I keep finger crossed, hope I interpreted the changelogs correctly 😅.

[MichaIng]

@lupa18
Any news from your side? Meanwhile I uploaded a Buster-based testing image: #2979

[MichaIng]

I mark this as closed, especially in regards to new Buster image. Feel free to reopen if required.