Merblud

  • Posts

    28
  • Joined

  • Last visited

Posts posted by Merblud

  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. 6 hours ago, balbes150 said:

    What alsa settings do you use to enable audio ?

     

    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

     

  3. 6 hours ago, balbes150 said:

    There is a strange result. When using sources and patches from the Armbian build system (core 5.4) and adding changes from the T4 patch, the 5651 device does not appear. But if  comment on a line

    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.

  4. 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.

  5. 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?

  6. 6 hours ago, Marko Buršič said:

    I use the u-boot that comes on image file. How to install "this" tpl/spl u-boot?

    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.

  7. 4 hours ago, Igor said:


    If u-boot is build and packed by our build tools:

    - install .deb package as usual (dpkg -i xxxxxxxxxxxxxxxx.deb and remove potentially conflicting u-boot package if exists)

    - armbian-config -> system -> update boot loader

    Is there a package uboot in the armbian without miniloader?

  8. 17 hours ago, Marko Buršič said:

    I have a RockPi 4, installed Armbian Buster Server 5.3.11. same problem, more than 30s to unpack, while on 4.4 kernel I haven't noticed so long times at boot up.

    If you use a uboot builded according to scheme (tpl/spl)->uboot (without rockchip miniloader), the loading is fast.

  9. 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.

  10. On 9/3/2019 at 11:57 PM, piter75 said:

    Manjaro's patch reverted the performance segregation of the cores to bring back pre 5.2 behaviour.

    Ezequiel's patch OTOH tries to initialise cpufreq driver as soon as possible during the boot to make the cores' performance closer to the kernel's assumption of it - at least that's how I understand it.

    If the kernel is built for a multiarch configuration. Can 't these patches cause the kernel to become inoperable on other SoC (not rk3399)?

  11. 9 hours ago, piter75 said:

    There are some patches to make it work better:

    https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-aarch64-rc/commit/129dd4053ddca867b0255bd7e4cff109b66bf61a

    https://gitlab.collabora.com/rockpi/linux/commit/e55cd521ed67943cc3edcd8b78884ad53741da8c

     

    I have used the latter in my local build on Rock Pi 4 and it works well - boot times in 5.3-rc4 are reduced.

    I did not make a PR for it as it is a hack really but I sure can to make the booting experience smoother.

     

    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?

  12. 2 piter75

     

    Thanks. I 'll try to use it all.

     

    9 hours ago, piter75 said:

    It was emphasised by this commit: https://github.com/torvalds/linux/commit/97df3aa76b4a384e29668f374a8b1034a31aa215 which makes a preference to use to use big cores instead of LiTTLE ones.

    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?

  13. On 9/2/2019 at 7:51 PM, drice said:

    It appears to be decompression of initramfs taking 31 seconds:

    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.

  14. There are several questions on the topic:

    1. 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.
    2. Why is there still no sound in fdt for nanopc-t4? I corrected fdt, but I can 't put it in kernel.org. 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?
    3. 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.

  15. 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?

  16. 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?

  17. 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.