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

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

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?

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

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?

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.

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

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.