Espressobin support development efforts

[FlashBurn]

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?

[FlashBurn]

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?!

[lanefu]

Yeah still 800mhz when set to 1000.    Main goal this release was get to a newer kernel that was stable

[ebin-dev]

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

 

[ebin-dev]

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)

 

 

[FlashBurn]

As an arch kernel is working like it should, maybe it is a problem of the kernel config?

[ebin-dev]

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.

[Pali]

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

 

[barish]

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

[Pali]

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?

[barish]

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

[BenCranston]

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

[Pali]

@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).

 

[BenCranston]

Sweet. thanks.  building kernel from your source tree now.  

[Igor]

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.

[lanefu]

fyi there's another PR for some SATA performance improvements that could use some testing on ebin

https://git.io/JtEA

[Pali]

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!

[BenCranston]

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

[Pali]

@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?

[hrw]

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/

[cirne]

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?

[Igor]

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

[Excalibur]

Follow up on hrw. I was planning to install pimox on ESPRESSObin to run virtual OpenWrt and a docker host, which requires a Debian like host. I coudn't get vanilla aarch64 Debian to boot on the board so I turned to Armbian. To my surprise the board is now moved to not supported status.

 

I ultimately got Debian to boot in EBBR and recorded my steps here in case anyone here also want to switch to a different distro. As for pimox I got it installed but idle memory consumption is around 800M. I have tried to run the board as a NAS via on board SATA and USB 3, which was very sluggish (could be my USB 3 docking station's fault). I'm very sad that the board is so resource limited that a little bit more CPU or memory can definitely make it much more capable. At the moment I flashed OpenWrt and only put one docker service on it, since upgrading OpenWrt requires reflashing SD card.

[lanefu]

6 hours ago, Excalibur said:

To my surprise the board is now moved to not supported status.

 

You can still build images with the armbian build tools, but yeah we need the community to step up and maintain the ebin unfortuantely.

[Pali]

6 hours ago, Excalibur said:

I coudn't get vanilla aarch64 Debian to boot

 

It should work fine. At least half year ago it worked without any issue. Any specific error?

[Excalibur]

1 hour ago, Pali said:

 

It should work fine. At least half year ago it worked without any issue. Any specific error?

No error this time but I just prefer to use supported software if possible. If Debian breaks they have to fix it since their image is targeting generic aarch64 and that will be a regression. If Armbian breaks I might be pushed off since the target is not officially supported.

[Pali]

aarch64 is supported by debian. Now I checked my espressobin box with debian and it is still working fine, boot without issue. So if it does not work for you, I suggest to report a bug with error log what does not work.

[Excalibur]

Just now, Pali said:

aarch64 is supported by debian. Now I checked my espressobin box with debian and it is still working fine, boot without issue. So if it does not work for you, I suggest to report a bug with error log what does not work.

I got it working eventually. Thanks.

[y52]

I am upgrading my espressobin v5 board setup with Armbian to v7 board.

Having flashed the u-boot on v7 with 

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

setting the u-boot environments and writing the Armbian image to the USB

Armbian_21.08.1_Espressobin_bullseye_current_5.10.60.img

the board booted as expected, but logged initial errors when initiating the boot from the media:

 

Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0 
starting USB...
USB0:   Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
/
** File not found /boot.scr **                                 <<< ====
## Executing script at 06d00000
Wrong image format for "source" command        <<< ====
/boot/
1063 bytes read in 25 ms (41 KiB/s)
## Executing script at 06d00000
191 bytes read in 10 ms (18.6 KiB/s)
21496320 bytes read in 108 ms (189.8 MiB/s)
8858893 bytes read in 58 ms (145.7 MiB/s)
** File not found /boot/dtb/marvell/armada-3720-community.dtb **
11127 bytes read in 15 ms (723.6 KiB/s)
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    8858829 Bytes = 8.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

 

 

Could anyone prompt if this  " ** File not found /boot.scr ** " is a critical error or it could be fixed?

U-boot environments were set as follows :

Marvell>> setenv boot_targets 'usb sata mmc1 mmc0'
Marvell>> setenv boot_prefixes '/ /boot/'

 

As I am booting from USB, it should be the 1st boot target.

 

boot.scr is in place and has been deployed with the Armbian image. 

# ls -al /boot/boot.scr 
-rw-rw-r-- 1 root root 1063 Aug 26 10:46 /boot/boot.scr

 

What may cause the "** File not found /boot.scr **" ?

 

 

 

The posts from HRW and Excalibur on "Now it has mainline U-Boot 2021.01 and works as normal EBBR board."

were very interesting. It would be worth adding U-Boot 2021.01 to a repository.

Could somebody share his experience upgrading his board with U-Boot 2021.01 and bringing up Armbian?

 

[Pali]

2 minutes ago, y52 said:

Having flashed the u-boot on v7 with 

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

 

This is 5 year old version of U-Boot. Really upgrade to something non-prehistoric. Old version has lot of bugs, so it is not surprise that something does not work as expected.

 

2 minutes ago, y52 said:

It would be worth adding U-Boot 2021.01 to a repository.

 

Note that there is new U-Boot 2022.01 version... But Armbian rejected to update U-Boot + TF-A to recent version (it was needed to only change version in build script), so you need to build and update by yourself. See my post with details, steps are really easy. If you have issues with building, just write and I can help you.