Getting LibreELEC to work with RockPi 4B and a Hifiberry DAC+ Pro XLR

dpapavas · February 9, 2024 at 4:58 PM

Hi,

I have a RockPi 4B coupled with a Hifiberry DAC+ Pro XLR. The Hifiberry wasn't designed for the RockPi, but it is in fact compatible with it. I know it, because I have got it working on Armbian, with the 4.4 BSP kernel for a while now. As far as I can remember, what is needed in order to get it to work, are compiling and installing a kernel module for the PCM5242 DAC chip and an overlay, in order to configure the RK3399's pins for the proper modes needed to talk to the DAC.

1. Can someone point me to the easiest way of doing the above, i.e. compiling a custom module and loading a custom device overlay, in libreELEC? Note that the PCM5242 is not supported by the Linux kernel, but, from what I remeber, the driver for the PCM512X chips, which are supported, can be used with some trivial changes. I'm not asking for help on modifying the driver code, just on building and loading the result on libreELEC.

2. I did write the overlay (.dtb) file for my current setup, but this is applicable to the 4.4 kernel and it needs substantial changes for newer kernels as far as I recall. (There was at least a substantial change in the relevant sound subsystem design in the 4.19 release of the kernel or somewhere around that time anyway.) Sadly (or perhaps mercifully, depending on how one looks at it) I don't remember anything about writing, compiling and loading device tree overlays any more. If someone has some experience with it and would be willing to help out, I'd be most grateful.

Thanks in advance,
Dimitris

**chewitt** · February 10, 2024 at 11:31 AM

Commit device-tree changes for the different audio setup to an upstream kernel git source (Linux 6.6 for RK boards) then use "git format-patch" to create a diff patch that can be imported to "projects/Rockchip/patches/linux" in the buildsystem. When you build the patch is applied and the resulting dtb file has the changes built in, so no need to mess around with true overlays.

This wiki article describes how to self-build: https://wiki.libreelec.tv/development/build-basics

This describes workflow to enable a different kernel module: https://wiki.libreelec.tv/development/git-tutorial

dpapavas · February 12, 2024 at 10:55 AM

Thanks you for the pointers! I'm building a (stock) image as I type this and everything seems to be going smoothly. Regarding the kernel driver, I'll need to patch an existing kernel driver, not just enable it, but I suppose I can do that with another patch.

The documentation you pointed me to, mentions editing "projects/Generic/linux/linux.x86_64.conf" in order to enable a module. That's the file I need to edit too, even though the PROJECT I'm using is "Rockchip", not "Generic", right?

**chewitt** · February 12, 2024 at 11:11 AM

Wrong. You need to edit the kernel defconfig for the correct Rockchip device. Generic is only used with x86_64 hardware.

dpapavas · February 13, 2024 at 1:10 PM

Ah, the defconfig is under /devices in the Rockchip project, since more than one SoCs are supported. Sorry, I missed that.

dpapavas · February 18, 2024 at 8:10 PM

Quote from chewitt

Commit device-tree changes for the different audio setup to an upstream kernel git source (Linux 6.6 for RK boards) then use "git format-patch" to create a diff patch that can be imported to "projects/Rockchip/patches/linux" in the buildsystem.

Just to be sure I get you correctly, you're suggesting I should just make my changes straight inside arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts, right?

**chewitt** · February 19, 2024 at 6:23 AM

Using an overlay is probably the "more technically correct" way to do things but I wouldn't worry about that until you have a working set of changes. Patching the kernel source will have an easier dev workflow as you figure those changes out.

dpapavas · February 20, 2024 at 11:28 AM

Well, I did get it work! Can't believe it was only a matter of a couple of days work; I've been putting this off, staying with a heavily patched, mostly broken, Kodi 18 installation, running on the mostly broken 4.4 BSP kernel for a couple of years now. Thanks again for all your help. I have a bunch of things to sort out now and hence probably a bunch of questions, but I'll be starting new threads in more appropriate subsections as needed.

For anyone looking into this, the general outline of the what needs to be done is this:

1. Start with the appropriate kernel sources based on libreelec version.

2. Apply patches from Raspberry Pi kernel repo, introducing support for HifiBerry devices. At the time of this writing this is a single commit (for the 6.1 kernel for instance, it is "f1b09af4656d (HEAD) Add support for all the downstream rpi sound card drivers") and you don't really need to apply all of it, just the changes relating to your device, e.g. "*hifiberry_dacplus*".

3. Fix the DAI link in "hifiberry_dacplus.c", to reflect the correct RK3399 I2C and I2S channels.

Quote

SND_SOC_DAILINK_DEFS(rpi_hifiberry_dacplus,
DAILINK_COMP_ARRAY(COMP_CPU("rk3399-i2s.1")),
DAILINK_COMP_ARRAY(COMP_CODEC("pcm512x.7-004d", "pcm512x-hifi")),
DAILINK_COMP_ARRAY(COMP_PLATFORM("rk3399-i2s.1")));

4. Add the following to the Rock Pi 4B device tree, to enable I2C7 and connect it to the codec, enable I2S1 and add the platform device:

Quote

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
index 0806545922f5..d6071aec4237 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
@@ -14,6 +14,17 @@ / {
aliases {
mmc2 = &sdio0;
};
+
+ dacpro_osc: dacpro-osc {
+ compatible = "hifiberry,dacpro-clk";
+ #clock-cells = <0>;
+ };
+
+ hifiberry_dacplus: hifiberry-dacplus {
+ compatible = "hifiberry,hifiberry-dacplus";
+ i2s-controller = <&i2s1>;
+ status = "okay";
+ };
};

&sdio0 {
@@ -47,3 +58,25 @@ bluetooth {
vddio-supply = <&vcc_1v8>;
};
};
+
+&i2s1 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+};
+
+&i2c7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ pcm5122@4d {
+ #sound-dai-cells = <0>;
+ compatible = "ti,pcm5122";
+ reg = <0x4d>;
+ clocks = <&dacpro_osc>;
+ AVDD-supply = <&vcc3v3_sys>;
+ DVDD-supply = <&vcc3v3_sys>;
+ CPVDD-supply = <&vcc3v3_sys>;
+ status = "okay";
+ };
+};

Display More

5. Make a patch with "git format patch HEAD^" and move it into the correct LibreElec distribution directory.

6. Add "CONFIG_SND_SOC_RK3399_HIFIBERRY_DACPLUS=m" to your device's kernel defconfig in the LibreElec sources.

7. Make the image and install it.

**chewitt** · February 20, 2024 at 6:26 PM

Congrats

The ideal thing would be for the i2c/i2s bits to be obtained from device-tree allowing a common driver module to be upsteamed to the mainline kernel with minor device-tree changes (applied through an overlay) providing the runtime differentiation between RPi and RK (or any other compatible) SoC type.

dpapavas · February 20, 2024 at 6:57 PM

I assume you're talking about the DAI link parameters in the platform driver ("hifiberry_dacplus.c"). I agree and it would have made my life a lot easier, but on the one hand, this is by its nature a Raspberry Pi-specific device, so I suppose it is not entirely unreasonable to claim that it belongs to the Pi's fork of the kernel (although whether there should be such a fork at all is another matter, one which I'm not qualified to judge).

On the other hand from what I've seen, the various people writing drivers for similar devices aren't big on upstreaming changes to the mainline kernel in general. They apply locally (in the sense of at the Pi kernel level) changes to upstream code, such as the codec driver in this case, instead of attempting to push them upstream, which doesn't help in many ways.

I've pushed a fix I did for the codec driver upstream a few years ago, but trying to push a driver for a commercial device that isn't mine would feel a little weird

**chewitt** · February 21, 2024 at 10:22 AM

I guess the question/responsibility rests with hifiberry folks. Do they want to broaden the market for their boards to other fully pin-compatible SoC platforms? .. which probably gets a Yes/No answer. They're small enough that more sales would be great. Equally they are probably so focussed on Raspberry Pi that they're unsure what anything else might entail for long-term support and that might result in an over-cautious no response. The only way to find out is making contact and asking them. In reality it's probably a small change and pushing something upstream: and in parallel pushing the update to RaspiOS so the required overlay changes are already in-place when the upstream change flows downstream in some future kernel bump.

Entirely up to you if you want to ask them and advocate, but I'll always encourage that kind of thing to happen. The RPi kernel devs are sending more things upstream than ever before, but the pile of technical debt is still large. Hence all help in reducing it is good and .. no worse opinion of anyone for finding something easier to do

dpapavas · February 21, 2024 at 4:52 PM

I've had some contact with the (or at least one of the) developers of HifiBerry boards when I made that bugfix to the codec driver. (In fact, he was nice enough to give me the similar, in terms of drivers, board I'm using right now for my trouble.) At the time I, didn't have the Rock Pi yet, but was considering it and asked him whether the boards might work with it. In fact, reviewing this communication, I told him

Quote

I might give it a try when software support for the board
matures a bit more. I'll let you know if I do.

for which he thanked me, so I suppose he might well be interested in supporting the Rock Pi 4. I think I'll drop him a line as soon as I find some time.