Pali got a reaction from lanefu in Espressobin v5 - any luck to get true 1Ghz or 1.2 Ghz?
Yes, see my comment https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=110303 After my tests it seems to be stable on 1GHz CPU, but testers are welcome! I'm planning to send a new version of patches.
Do you have a board with 1.2GHz SOC variant? I'm asking because I have not seen Armada3720 SOC with 1.2GHz CPU yet. See my comment https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/?tab=comments#comment-109760 where I wrote how to detect CPU variant.
Pali got a reaction from Werner in How to make ESPRESSObin v7 stable?
Hello! We found out that stability issue is not specific to Espressobin V7, but also for other boards with Armada 3720 SOC. And mentioned patch from Victor Gu which sets minimal voltage to 1.108V for 500 MHz and lower speeds seems to fixes this issue.
Marek prepared new patches for mainline kernel which include that Victor's patch and other fixes for armada 3720 cpufreq driver. See link:
Could you please test these patches if they finally fix also your instability issues on Espressobin V7?
Pali got a reaction from Werner in EspressoBin mainline u-boot/atf
@dhewg: There are more variants of A3720 SOC and they differs in CPU freq. Variant number is printed on SOC. So if you have SOC with 1GHz CPU you should use/flash 1GHz firmware image, if you have only SOC with 800MHz CPU then you should flash 800MHz image. In part order number documents is also 1.2GHz variant of SOC but I have not see it yet. No idea if Marvell started producing it.
In this public document https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf at page 154 is decoder of numbers printed on SOC and on page 153 is decoder of numbers, important is speed code. Based on SOC chip which you have on your Espressobin you should prepare firmware (WTM+ATF+U-Boot) and flash it.
So this if somebody flashed incorrect variant then it is probably reason for instability of Espressobin.
Pali got a reaction from Werner in espressobin uboot security concerns switch init portmask
Proper fix for this issue will be part of U-Boot version v2020.10-rc4.
But instead of doing hack/workaround by completely disabling all lan ports, fix in U-Boot v2020.10 just disables forwarding packets between lan and wan interfaces.
So packets from non-CPU ports would not be forwarded to other non-CPU ports (fixes this security issue) and packets from CPU port would be still forwarded to all other ports like before (so netboot will work as before via any port, unlike your workaround).
Plus configuration is set prior enabling Topaz forwarding, so there is no time window in which insecure configuration is active.