Sound on the RockPro64

Hi!

Some time ago I installed the official RockPro64-image 14.2-RELEASE on my device and upgraded it to 14.3-RELEASE-p4 just today.

Sound does not work: No device /dev/dsp* whatsoever.

ChatGPT tells me to do the following:
Code:
kldload snd_soc_rockchip_i2s
kldload snd_soc_es8316
kldload snd_soc_simple_card
But the respective kernel modules are not included in my installation.

Two questions:
  • Is sound support theoretically available on the RockPro64?
  • If yes, do I need to recompile the kernel or is there a simpler way (for the inbuilt audio chip!)?
Best,
Holger
 
It works on my Rock64, but I had to add an override for analog-sound device (compatible = "simple-audio-card") in FDT.
Originally it was set to disabled.
 
It works on my Rock64, but I had to add an override for analog-sound device (compatible = "simple-audio-card") in FDT.
Originally it was set to disabled.
Can you please tell me the exact line (resp. diff) you added to the original DTS file (./sys/contrib/device-tree/src/arm64/rockchip/rk3399-rockpro64.dts)
 
To be precise, I did not modify any dts file, I created an overlay dtso file.
For my Rock64 (which is based on RK3328) its content is:
Code:
/dts-v1/;
/plugin/;

/ {
    compatible = "rockchip,rk3328";
};

&{/analog-sound} {
    status = "okay";
};

I named the file rk3328-analog-sound.dtso and placed it in sys/dts/arm64/overlays/.
For your RK3399 things would be different, of course.
If you prefer, you can modify a dts / dtsi file directly instead of creating an overlay.

Maybe your issue is completely different.
From a quick look at rk3399-rockpro64.dtsi, "sound" node seems to be enabled by default as status is not explicitly set.
See https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#status

You may want to examine the actual active FDT, e.g., with sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | vi -.
Output of devinfo -v may provide additional insights.
Also, check dmesg / messages for any sound / audio related messages.
 
[…]
You may want to examine the actual active FDT, e.g., with sysctl -b hw.fdt.dtb | dtc -I dtb -O dts | vi -.
Output of devinfo -v may provide additional insights.
Also, check dmesg / messages for any sound / audio related messages.
The output of sysctl -b hw.fdt.dtb | … looks promising (although I am not an expert):
Code:
        […]
        i2c@ff110000 {

                compatible = "rockchip,rk3399-i2c";
                […]
                status = "okay";
                […]
                codec@11 {

                        compatible = "everest,es8316";
                        reg = <0x11>;
                        clocks = <0x8 0x59>;
                        clock-names = "mclk";
                        #sound-dai-cells = <0x0>;
                        phandle = <0xf4>;
                        port {

                                endpoint {

                                        remote-endpoint = <0x3c>;
                                        phandle = <0xa6>;
                                };
                        };
                };
        };
        […]

Also, devinfo -v gives good results, as far as I can tell:
Code:
    […]
    rk_i2c0 <RockChip I2C> pnpinfo name=i2c@ff110000 compat=rockchip,rk3399-i2c
      iicbus0 <OFW I2C bus>
        unknown pnpinfo name=codec@11 compat=everest,es8316  at addr=0x22
        iic0 <I2C generic I/O> at addr=0
    […]

However, in dmesg hardly anything appears:
Code:
root@rechenknecht:~ # dmesg | grep everest
root@rechenknecht:~ # dmesg | grep es8316
root@rechenknecht:~ # dmesg | grep i2c0
rk_i2c0: <RockChip I2C> mem 0xff110000-0xff110fff irq 22 on ofwbus0
iicbus0: <OFW I2C bus> on rk_i2c0

Do I need to activate the driver in the kernel config?
 
So you need to tell us what audio you are trying to use?
Mini-Phono jack is analog
HDMI is digital audio

Look at the dtsi for some details:
You have analog, spdif and HDMI audio

Code:
    sound {
        compatible = "audio-graph-card";
        label = "Analog";
        dais = <&i2s1_p0>;
    };

    sound-dit {
        compatible = "audio-graph-card";
        label = "SPDIF";
        dais = <&spdif_p0>;
    };

You may also find rockpro64 device tree overlays if you look around.

 
So you need to tell us what audio you are trying to use?
Mini-Phono jack is analog
HDMI is digital audio
[…]
I would like to use the mini-phono (analog) jack.

I poked around in the kernel source tree, searching for “es8316”, “emerest”, etc., but did not find anything. Could it be that there is just no driver implemented yet?
 
[…]
NetBSD Pinebook Pro dmesg:
Ok, this is way above my head but I'll ask nonetheless: The NetBSD ist about 700 lines of code and does not look too horrible.

Is porting a driver from NetBSD in general a clever thing to do? Both license- and architecture-wise?
 
You will have to add a device tree node too:

This is for another board but this is the correct format. i2s instead i2c ? NetBSD dmesg shows i2c for PineBookPro. i2c-tools should shed some light.
Code:
        };

+       i2c@c240000 {
+               es8316_codec: es8316@10 {
+                       compatible = "everest,es8316";
+                       reg = <0x10>;
+                       status = "okay";
+               };
+       };
I think browsing thru ofwdump -a on FreeBSD would be beneficial.
 
its both i2c and i2s
i2c is used for control and i2s for digital data transfer to / from host (like dma in a classic soundblaster)
for rk3328 the control part is mmio for rk3399 and rk356x is i2c
 
anyway as the i2s driver has no dma support and it looks like the i2s controller fifo size is 32 bytes you will have about 6k interrupts per second which kind of sucks

LE. it seems it's 32 * 4bytes which will cut interrupt rate to 1500/s.
 
anyway as the i2s driver has no dma support and it looks like the i2s controller fifo size is 32 bytes you will have about 6k interrupts per second which kind of sucks

LE. it seems it's 32 * 4bytes which will cut interrupt rate to 1500/s.
Is DMA support in the i2s driver difficult to implement? Would an implementation be desirable also for other use cases, or just sound?
 
many high throughput devices (like NICs, AHCI, etc) have built in dma engine and usually the driver uses it
other devices don't have their own dma engine and rely on the soc's dma subsystem (where there are entries like dmas = , and dma-names in the dts
these dma dts entries act like clocks (point to a device and a channel)
the xdma driver (dev/xdma/xdma.c) should support it but it is not included in any arm kernels by default and i never tested it
then if the xdma driver really works switching the transfer code from pio to dma should not be to complicated
i see that spi, uart and i2s are the dma consumers on rk356x. on other rk boards is probably the same.
 
Back
Top