• Posts

  • Joined

  • Last visited

Everything posted by Merblud

  1. Try a newer version of u-boot.
  2. 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>; }; };
  3. Probably in Armbian core is already patched (used SCLK_I2SOUT_SRC in rk3399-cru.h).
  4. 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
  5. I am sorry. I checked with the 5.2.8 core from (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.
  6. 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?
  7. 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
  8. 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.
  9. 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.
  10. 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 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?
  11. 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.
  12. Is there a package uboot in the armbian without miniloader?
  13. If you use a uboot builded according to scheme (tpl/spl)->uboot (without rockchip miniloader), the loading is fast.
  14. If you use kernel 5.x or above then welcome to Kernel 5.x.x and rk3399.
  15. 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.
  16. If the kernel is built for a multiarch configuration. Can 't these patches cause the kernel to become inoperable on other SoC (not rk3399)?
  17. I understand correctly that here the maximum values for the performance of the cores at the start are forced to be setted? Or something else?
  18. 2 piter75 Thanks. I 'll try to use it all. I understand correctly that the hard setting of the performance value in the FDT is a bad solution. The kernel calculates the performance of the cores at start-up. What's the problem? Logic does not provide that cores can be different?
  19. Thanks. The thought of decompressing of initramfs didn 't come to my mind right away. But it takes me less than 30 seconds. But I did not pay attention to it: [ 2.333097] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages [ 2.333648] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages [ 2.334066] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages [ 2.334454] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages [ 65.467118] alg: No test for lzo-rle (lzo-rle-generic) [ 65.474155] alg: No test for lzo-rle (lzo-rle-scomp) [ 65.653691] ACPI: Interpreter disabled. But this kernel is not from armbian. This is my local build (5.2.8). I probably didn 't take anything into account.
  20. There are several questions on the topic: Between the moment of transfer of control to the kernel from the u-boot and the moment of start of the kernel operation it takes 1.5 -2 minutes. I assume that during this period of time there is decompression of the code and placement in memory. But why so long? The 4.4.x kernel starts instantly. When I first turned on a nanopc-t4 with a 5.x.x (4.20) kernel, I already thought the kernel was corrupted. And quite accidentally waited for the green LED to blink. Why is there still no sound in fdt for nanopc-t4? I corrected fdt, but I can 't put it in It is possible that my patch goes against the established structure, but now I use sound. Maybe there are some subtle nuances that I 'm not aware of? Why can 't the kernel turn off power? The 4.4.x kernel was fine. It 's a flaw in fdt, in the kernel, something else? Thanks.
  21. As a result it is necessary to create the mbr partition? And why then the loader tries to look for the gpt partition? For example: GPT 0x3190d20 signature is wrong LoadTrust Addr:0x4000 Or nobody just knows what occurs in a blob from Rockchip?
  22. Help to understand with boot process. I watch documentation from rockchip. There it is specified that several gpt partitions have to be created. I take a sd-card with the image of the armbian which is written down on it. I start the gdisk. I receive result: GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *************************************************************** Disk /dev/sdd: 31176704 sectors, 14.9 GiB Logical sector size: 512 bytes Disk identifier (GUID): 1239DBE7-E7AC-4D30-B146-AEF177251577 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 31176670 Partitions will be aligned on 2048-sector boundaries Total free space is 344477 sectors (168.2 MiB) Number Start (sector) End (sector) Size Code Name 1 32768 30864927 14.7 GiB 8300 Linux filesystem Why so? It is really necessary to create the mbr partition?
  23. Hi all. Tell me please. How to get a uinitrd from a initrd.img?
  24. Hi. Why is the 2d drawing in X11 so slow? If you use mali blobs, the scrolling in the Windows is delayed, moving the Windows is done with jerks. Even when display compositing is enabled, you can see how the under level Windows are redrawn in parts. If you do not use mali blobs, the scrolling in the Windows is excellent. But the Windows move slowly. When the compositing is disabled, the window can reach several (5-7) seconds. One would think that the graphics accelerator and processor are slow. But I have experience using weaker devices (e.g. tegra k1 or exynos with mali t6xx). There such delays are not observed even in the mode without hardware acceleration.