Espressobin support development efforts

lanefu

By lanefu,
in Armada A388, A3700

 Share
22 22

Recommended Posts

FlashBurn

FlashBurn 5

Posted
Posted

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
Link to post
Share on other sites
Donate and support the project!

FlashBurn

FlashBurn 5

Posted
Posted

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
Link to post
Share on other sites
ebin-dev

ebin-dev 36

Posted
Posted

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
Link to post
Share on other sites
ebin-dev

ebin-dev 36

Posted
Posted
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
Link to post
Share on other sites
barish

barish 8

Posted
Posted
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
Link to post
Share on other sites
Pali

Pali 14

Posted
Posted
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
Link to post
Share on other sites
barish

barish 8

Posted
Posted (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 by barish
addendum
2
Link to post
Share on other sites
Pali

Pali 14

Posted
Posted

@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
Link to post
Share on other sites
Igor

Igor 2201

Posted
Posted
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
Link to post
Share on other sites
BenCranston

BenCranston 2

Posted
Posted

@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
Link to post
Share on other sites
hrw

hrw 2

Posted
Posted

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
Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
22 22
Go to topic listing