Merblud

  • Posts

    28
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Merblud's Achievements

  1. Strange and obscure problem. With the latest patches, I have audio output working through the codec rt5651. But only with a 5.2.8 core. I used these fixes in core 5.4.35. But no sound device rt5651 is created. At the same time, everything is normal in the log. The codec driver is connecting successfully. Good news. There was an error in dts file patch. You must use the name "realtek" instead of "rockchip" in the node rt5651: rt5651@1a. In this case, the codec driver module will be used successfully. Otherwise, the module will not load automatically. &i2c1 { clock-frequency = <200000>; i2c-scl-rising-time-ns = <150>; i2c-scl-falling-time-ns = <30>; status = "okay"; rt5651: rt5651@1a { #sound-dai-cells = <0>; compatible = "realtek,rt5651"; reg = <0x1a>; clocks = <&cru SCLK_I2S_8CH_OUT>; clock-names = "mclk"; pinctrl-names = "default"; pinctrl-0 = <&i2s_8ch_mclk>; }; };
  2. Probably in Armbian core is already patched (used SCLK_I2SOUT_SRC in rk3399-cru.h).
  3. amixer set 'HPO L' on amixer set 'HPO R' on amixer set 'HPOVOL L' on amixer set 'HPOVOL R' on amixer set 'HPO MIX HPVOL' on amixer set 'OUT MIXL DAC L1' on amixer set 'OUT MIXR DAC R1' on amixer set 'Stereo DAC MIXL DAC L1' on amixer set 'Stereo DAC MIXR DAC R1' on
  4. I am sorry. I checked with the 5.2.8 core from kernel.org (not from Armbian build system). I prepared the patch for core 5.4.35. But the core 5.4.35 didn 't have time to check. I have to do the assembly directly on T4. It long.
  5. I used the fdt file patch in conjunction with the kernel patch from here: Orange Pi 4 Kernel 5.x.x rt5651 sound and bluetooth fixed In this kernel patch use SCLK_I2S_8CH Which option is more relevant for today?
  6. A patch for NanoPC-T4 that resolves a sound problem (hdmi and rt5651). For dts/dtsi files only. For kernel modules, the solution is listed above. Nanopc-sound.dts.patch
  7. Yes. Works for me. Main patches here: Orange Pi 4 Kernel 5.x.x rt5651 sound and bluetooth fixed But it is for NanoPC T4 that the fdt is needed. He won 't work from Orange Pi 4. At least the codec is connected to another bus.
  8. It is possible to sum up the results. A full power cut is working. I don 't know how to do this in fresh versions of the kernel. It 's possible it 's already working by default. Did not check. But I have a patch that solves this problem. The sound works. The sound through HDMI works in the latest versions of kernel. The changes were only needed in fdt. The problem with outputting audio through the codec has also been solved. Orange Pi 4 Kernel 5.x.x rt5651 sound and bluetooth fixed It works. A different fdt is needed for the NanoPC-T4. The latest versions of the u-boot load the kernel quickly.
  9. I am still trying unsuccessfully to get the sound through the rt5651 codec using the main line kernel (I use NanoPC-T4). I corrected the dts/dtb file and assembled the kernel module. The kernel performs i2s bus and codec switching. The corresponding audio device appears on the system. I start a alsamixer. I can change settings. When I change some settings, I can even hear clicks in the dynamic. So the codec chip is powered up. And the codec chip is controlled through the i2c bus. I can switch the audio output through the codec. But there is no sound. I can 't figure out what the reason is. The dts/dtb files for main line kernel and rockchip 4.4.xxx kernel are slightly different. But I don 't see any criticism. Maybe I can 't understand that. The kernel generates several error messages when initializing the audio sub-system. But in my opinion, these mistakes are not critical. It seems that the audio stream is not going on the i2s bus connected to codec. Or the codec chip does not receive the stream. Give advice. What else can I check?
  10. I built the uboot myself according to instructions (from git). It 's not very difficult. But the latest versions of the uboot don 't work for me.
  11. Is there a package uboot in the armbian without miniloader?
  12. If you use a uboot builded according to scheme (tpl/spl)->uboot (without rockchip miniloader), the loading is fast.
  13. If you use kernel 5.x or above then welcome to Kernel 5.x.x and rk3399.
  14. Here 's the patch (5.3.4 kernel). diff -u a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi 2019-10-17 23:47:33.000000000 +0300 +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi 2019-10-27 22:34:55.988303874 +0300 @@ -105,6 +105,27 @@ }; }; + rt5651-sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "realtek,rt5651-codec"; + simple-audio-card,format = "i2s"; + simple-audio-card,mclk-fs = <256>; + simple-audio-card,widgets = + "Microphone", "Mic Jack", + "Headphone", "Headphone Jack"; + simple-audio-card,routing = + "Mic Jack", "MICBIAS1", + "IN1P", "Mic Jack", + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR"; + simple-audio-card,cpu { + sound-dai = <&i2s0>; + }; + simple-audio-card,codec { + sound-dai = <&rt5651>; + }; + }; + sdio_pwrseq: sdio-pwrseq { compatible = "mmc-pwrseq-simple"; clocks = <&rk808 1>; @@ -184,6 +205,10 @@ status = "okay"; }; +&hdmi_sound { + status = "okay"; +}; + &i2c0 { clock-frequency = <400000>; i2c-scl-rising-time-ns = <160>; @@ -432,6 +457,16 @@ i2c-scl-rising-time-ns = <150>; i2c-scl-falling-time-ns = <30>; status = "okay"; + + rt5651: rt5651@1a { + compatible = "rockchip,rt5651"; + reg = <0x1a>; + clocks = <&cru SCLK_I2S_8CH_OUT>; + clock-names = "mclk"; + hp-det-gpio = <&gpio4 RK_PC4 GPIO_ACTIVE_LOW>; + spk-con-gpio = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; + #sound-dai-cells = <0>; + }; }; &i2c2 { @@ -459,6 +494,16 @@ status = "okay"; }; +&i2s0 { + rockchip,playback-channels = <8>; + rockchip,capture-channels = <8>; + status = "okay"; +}; + +&i2s2 { + status = "okay"; +}; + &io_domains { bt656-supply = <&vcc_1v8>; audio-supply = <&vcca1v8_codec>; @@ -724,3 +769,9 @@ &vopl_mmu { status = "okay"; }; + +&spdif { + i2c-scl-rising-time-ns = <450>; + i2c-scl-falling-time-ns = <15>; + status = "okay"; +}; But the patch merely indicates to the kernel what equipment is present. We need another driver for the rt5651. Kernel sources have a module rt5651.c. I haven 't figured it out yet. You might need some more rk3399-specific module.