• Content Count

  • Joined

  • Last visited

About Merblud

  • Rank

Recent Profile Visitors

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

  1. 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?
  2. 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.
  3. Is there a package uboot in the armbian without miniloader?
  4. If you use a uboot builded according to scheme (tpl/spl)->uboot (without rockchip miniloader), the loading is fast.
  5. If you use kernel 5.x or above then welcome to Kernel 5.x.x and rk3399.
  6. 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.
  7. If the kernel is built for a multiarch configuration. Can 't these patches cause the kernel to become inoperable on other SoC (not rk3399)?
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. Merblud

    NanoPC T4

    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?
  13. Merblud

    NanoPC T4

    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?
  14. Merblud

    NanoPC T4

    Hi all. Tell me please. How to get a uinitrd from a initrd.img?