FlashBurn 5 Posted August 20, 2020 Share Posted August 20, 2020 I still don´t get it. I tried archlinux with a kernel 5.8 and it worked like it should. So I tried armbian and build my own kernel 5.7.16 (dev) and still the problem that I don´t get the right frequency. Does anyone has an idea what I can check to find the differences between the archlinux kernel and the armbian kernel? 0 Quote Link to post Share on other sites
FlashBurn 5 Posted August 27, 2020 Share Posted August 27, 2020 I just tried the current bootloader for 1200 MHz and 1000 MHz and the current Buster image (5.6.19) and still don´t get the right frequency It now recognizes the maximum frequency right, but if I use 7zip to verify I still don´t have the right frequency with 1200 MHz bootloader -> 750 MHz with 1000 MHz bootloader -> 800 MHz Can someone tell me if it works for them or if it is the same as for me?! 0 Quote Link to post Share on other sites
lanefu 306 Posted August 28, 2020 Author Share Posted August 28, 2020 Yeah still 800mhz when set to 1000. Main goal this release was get to a newer kernel that was stable 0 Quote Link to post Share on other sites
ebin-dev 36 Posted September 5, 2020 Share Posted September 5, 2020 The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz: root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 794 794 794 794 794 794 794 794 I also tried the bootloader with CPU_DDR=1000_800. Armbian launches without issues, cpufreq-info correctly reports the maximum CPU frequency of 1000MHz, but 7zip still reports a CPU frequency of about 800 MHz: root@espressobin:~# cat /proc/version Linux version 5.8.6-mvebu64 (root@desktop) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #20.08.2 SMP PREEMPT Fri Sep 4 22:39:30 CEST 2020 root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:87.38%, 250 MHz:1.61%, 500 MHz:0.12%, 1000 MHz:10.89% (309) root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 612 794 794 794 794 794 794 794 1 Quote Link to post Share on other sites
ebin-dev 36 Posted September 10, 2020 Share Posted September 10, 2020 On 9/5/2020 at 2:31 PM, ebin-dev said: The current Armbian buster image with kernel 5.8.6 (thanks to @Igor) works nicely in combination with the current Armbian bootloader - at least with CPU_DDR=800_800 on a V5_0_1 EspressoBin 1GB. 7Zip correctly reports a CPU frequency of 800 MHz: Here are some additional tests with all current Armbian bootloader versions. The current Armbian buster image boots with all of them - none of the bootloader versions leads to crashes or requires a cumbersome recovery (at least on a V5_0_1 EspressoBin 1G - see below). It seems that everything works as expected with CPU_DDR frequencies 600_600 and 800_800. However, CPU frequency remains at 800 MHz if 1000_800 is loaded and is even reduced to 750MHz if DDR_Topology 1200_750 is loaded (according to 7zip, but cpufreq-info reports the correct maximum CPU frequency). So - stable operation is established with each of the four DDR_Topologies loaded, but a system with the current bootloader (compiled from Marvells sources) and a current kernel 5.8.6 simply throttle CPU speeds above 800MHz in order to maintain a usable system. I have the impression that this is a feature rather than a bug. It would be highly desirable that GlobalScaleTechnologies comments on these observations or stops advertising Armada 3720 based products as using "Marvell 64bit Dual Core ARM A53 Armada 3700 SOC clocked up to 1.2Ghz". Anyway - I have replaced my EspressoBin some time ago by a more suitable SBC ... DDR_Topology 600_600 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 338 595 595 595 595 595 595 595 DDR_Topology 800_800 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 421 794 789 794 794 793 793 793 DDR_Topology 1000_800 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 789 794 794 794 794 794 793 794 DDR_Topology 1200_750 root@espressobin:~# 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 747 748 743 748 748 746 747 747 root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91% (179) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:92.16%, 300 MHz:0.75%, 600 MHz:0.18%, 1.20 GHz:6.91% (179) 0 Quote Link to post Share on other sites
FlashBurn 5 Posted September 10, 2020 Share Posted September 10, 2020 As an arch kernel is working like it should, maybe it is a problem of the kernel config? 0 Quote Link to post Share on other sites
ebin-dev 36 Posted September 10, 2020 Share Posted September 10, 2020 Or we are just missing a patch - the real CPU frequency as measured by 7zip seems to correspond to the selected DDR frequency. But would that help ? You still require a stable system. 0 Quote Link to post Share on other sites
Pali 14 Posted October 4, 2020 Share Posted October 4, 2020 @ebin-devand do you have Espressobin with A3720 1.2GHz SOC? See my post https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/?tab=comments#comment-109760 I have not seen A3720 SOC with 1.2GHz CPU yet and trying to overclock 800MHz or 1GHz CPU to 1.2GHz just would not work or would not be stable. 0 Quote Link to post Share on other sites
barish 8 Posted October 8, 2020 Share Posted October 8, 2020 On 6/15/2020 at 3:48 PM, barish said: I changed now to the legacy U-Boot (17.10) because it boots very reliably (which is what I need). I am not sure of the negative effects (testing is ongoing) but there is no option for me at the moment. I hope that someone with U-Boot and/or Marvell skills can tell me what changes from 17.10 -> 18.12 led to the unreliable booting. Since it takes place at the start of the WTMI RAM tuning process, I can only assume that there is the rub. Finally, Globalscale did the trick and pushed the modifications, that they had added to make 17.10 stable for all EspressoBin-Boards, to 18.12 as well. Thanks a lot, Globalscale!! Unfortunately, they did this in their repos and not in the official Marvell repos. I extracted the changes and made a pull request at the Marvell repo. I hope the changes will be merged soon, because I can then use the official Armbian build tools to generate a U-Boot/firmware that flawlessly works with my EspressoBin v7 DDR4 1cs 1GB boards. For now, I compile using the Globalscale repo and got a really stable firmware (tested on three boards for now), I am using the mainline U-Boot (2020.10), too and have no problems – but have not tested this with PCIe periphery (like wifi or SATA adaptors). 2 Quote Link to post Share on other sites
Pali 14 Posted October 10, 2020 Share Posted October 10, 2020 On 9/10/2020 at 7:15 PM, ebin-dev said: Or we are just missing a patch - the real CPU frequency as measured by 7zip seems to correspond to the selected DDR frequency. But would that help ? You still require a stable system. @ebin-dev: There is a bug in armada 3720 cpufreq kernel driver which cause that incorrect clock is used for CPU frequency. And this is reason why real measured CPU frequency is only 800 MHz. Patches for this fixing cpufreq driver are here: https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/ Could you please test them and check if it fixes that issue on your board? 0 Quote Link to post Share on other sites
barish 8 Posted November 23, 2020 Share Posted November 23, 2020 (edited) With help from @Pali, I managed to put the Pull Request at the right spot, so when it's accepted, EspressoBin v7 1GB and 2GB will be stable with most current U-Boot and Marvell sources! Unfortunately, I have no board with 2GB, so maybe someone can test it who owns a 2GB v7. Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version. Edit: The Pull Request has just been merged. I will make a PR at Armbian Build to use newest Marvell repo branches. Edited November 26, 2020 by barish addendum 2 Quote Link to post Share on other sites
BenCranston 2 Posted January 30 Share Posted January 30 @Pali I'd love to test. Is there a process I should be following to get these patches installed? I've setup the armbian build environment and can create the installation packages, but not sure how to apply patches into that for testing. Thanks for the help. 0 Quote Link to post Share on other sites
Pali 14 Posted January 30 Share Posted January 30 @BenCranston We have sent second version of patches for A3720 which should make 1 GHz mode finally stable. See post https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/?do=findComment&comment=117511 If you want to test them, download all patches from emails via (raw) button near Message-ID: line and then apply them, either via `patch -p1 -i filename` or via `git am filename` (if working you have linux sources checkouted from git). Other option is to clone my git kernel repository https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/ and compile kernel from it. Fixes are in branch a3720-cpufreq-issues. 1 Quote Link to post Share on other sites
BenCranston 2 Posted January 30 Share Posted January 30 Sweet. thanks. building kernel from your source tree now. 0 Quote Link to post Share on other sites
Igor 2201 Posted February 1 Share Posted February 1 On 11/23/2020 at 2:49 PM, barish said: Armbian builder is using older branches for stability reasons up to now to compile the U-Boot images – maybe with all the new patches in place, Armbian can also use the newest U-Boot version. https://github.com/armbian/build/pull/2598 Beta repository (beta.armbian.com in about 30m from now) or manual install, builds 91+ contains those patches. I also switched u-boot but needs testing. 1 Quote Link to post Share on other sites
lanefu 306 Posted February 3 Author Share Posted February 3 fyi there's another PR for some SATA performance improvements that could use some testing on ebin https://git.io/JtEA 0 Quote Link to post Share on other sites
Pali 14 Posted February 14 Share Posted February 14 On 1/30/2021 at 5:54 PM, BenCranston said: Sweet. thanks. building kernel from your source tree now. Ok! @BenCranston let us know if patches are working for you! 0 Quote Link to post Share on other sites
BenCranston 2 Posted February 14 Share Posted February 14 @Pali Yes! The patches are working great for me. I ended up switching to the beta kernel builds and got them that way. Trying to build the kernel with the Arabian tools and incorporate the patches was beyond me. I see the cpu actively switching between the various clock rates and the performance test indicate I'm getting 1GHz clock now. Things have been really stable with no trouble to report. 0 Quote Link to post Share on other sites
Pali 14 Posted February 14 Share Posted February 14 @BenCranston Perfect, thank you for testing! Could you send an email reply to https://lore.kernel.org/lkml/20210114124032.12765-1-pali@kernel.org/ with your Tested-By: name line? 0 Quote Link to post Share on other sites
hrw 2 Posted February 16 Share Posted February 16 I am not a user of Armbian and do not plan to. Wanted to write here and thank to whoever provided UART U-Boot files as I used them to get my EspressoBin v5 running. Now it has mainline U-Boot 2021.01 and works as normal EBBR board. I plan to use OpenWRT on it and use as a router for some time. Few more words: https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/ 2 Quote Link to post Share on other sites
cirne 0 Posted February 16 Share Posted February 16 I was trying to install snapd in espressobin and I noticed that it doesn't run because the kernel doesn't have support for squashfs. Is there a reason why this feature is disabled? 0 Quote Link to post Share on other sites
Igor 2201 Posted February 16 Share Posted February 16 3 minutes ago, cirne said: Is there a reason why this feature is disabled? None. I just don't recall anyone asked for snapd before. Send a pull request to those files https://github.com/armbian/build/tree/master/config/kernel 0 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.