Merblud
-
Posts
30 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Merblud
-
-
What happens if a sata-enabled kernel is loaded at the time when the nvme ssd was connected. Or vice versa. Can the ssd be damaged (physically)?
-
Try a newer version of u-boot.
-
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>; }; }; -
-
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
-
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.
-
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?
-
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. -
On 4/19/2020 at 10:40 AM, balbes150 said:
Question. Does someone have sound running through the 3.5 analog output on the kernel 5 ?
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. -
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. -
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 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.
-
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?
-
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.
-
If you use kernel 5.x or above then welcome to Kernel 5.x.x and rk3399.
-
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.
-
Xfce work successfully with panfrost (mesa 19.2, nanopc-t4).
-
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)?
-
9 hours ago, piter75 said:
There are some patches to make it work better:
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?
-
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?
-
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.
-
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 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?
- 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.
-
-
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?
Power management on rock 5b
in Rockchip
Posted
Greetings to the happy owners of the rock 5b. Tell me if the rock 5b turns off the power to all its components when shutting down. I understand that the power from the external power supply is still being supplied. And what happens to the devices on the board: ssd, fan, wifi etc.