Pali

There are Espressobin variants with just 512MB of memory. So if your image needs to be compatible with more variants, ensure that you place all parts in first 512 MB of RAM. I'm not sure where is running U-Boot after relocation and where it is malloc area. So choose address which does not conflict with it.
 
You can look at RAM layout used on A3720 CPU:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/marvell/armada/a3k/common/include/platform_def.h?h=v2.6

USB 3.0 is 5Gbps, PCIe 2.1 is 5Gbps and SATA is 6Gbps.
 
For loading you should use some unused space in RAM. Default value of of those variables should contain appropriate values. And they may change between releases, that is why addresses are in variables.

I have tested it on two different A3720 devices and on both it worked. And yes, it is clean U-Boot 2022.04 without any additional patches. So really do not know what can trigger this issue. There can be memory corruption or any other issue which could depend on linker layout, memory usage, etc... But as I cannot reproduce it, it is really hard for me to debug.

Now that fix was backported to stable versions 5.14.6, 5.13.19, 5.10.67, 5.4.148, 4.19.207, 4.14.247, 4.9.283 and 4.4.284.

A38x has 32-bit ARM cores. A3720 has 64-bit A53 ARM cores. 64-bit ARM cores compared to 32-bit cores have additional instructions for crypto operations. And based on some tests it seems that some crypto done via 64-bit ARM blocks is really faster than crypto done on CESA on the same SoC. So the best is to do own tests and measure if CESA or ARM is faster. So think about it like that 64-bit ARM CPU itself has some kind of crypto accelerator engine.

Now that fix was backported to stable versions 5.14.6, 5.13.19, 5.10.67, 5.4.148, 4.19.207, 4.14.247, 4.9.283 and 4.4.284.

Hello @Heisath! This is known problem. QCA98xx wifi chips are buggy, have timing and detection issues related to PCIe, which Qualcomm confirmed. Qualcomm recommendation is to increase PCIe pulse detection and for some (x86) motherboards, vendors released a new BIOS which do it. To make it worse, Marvell A38x SoC has also buggy PCIe which cause other issues and therefore combination of QCA98xx and A38x cause even more issues.
 
I'm preparing patches for pci-mvebu.c kernel driver to fix some issues, but they are not ready yet.
 
For QCA98xx I have prepared patch which are currently on linux-pci mailing list: https://lore.kernel.org/linux-pci/20210505163357.16012-1-pali@kernel.org/
 
Could you test it and check if it helps with new kernel versions?

Hello @Heisath! This is known problem. QCA98xx wifi chips are buggy, have timing and detection issues related to PCIe, which Qualcomm confirmed. Qualcomm recommendation is to increase PCIe pulse detection and for some (x86) motherboards, vendors released a new BIOS which do it. To make it worse, Marvell A38x SoC has also buggy PCIe which cause other issues and therefore combination of QCA98xx and A38x cause even more issues.
 
I'm preparing patches for pci-mvebu.c kernel driver to fix some issues, but they are not ready yet.
 
For QCA98xx I have prepared patch which are currently on linux-pci mailing list: https://lore.kernel.org/linux-pci/20210505163357.16012-1-pali@kernel.org/
 
Could you test it and check if it helps with new kernel versions?

It looks like that even with latest patches is 1.2 GHz mode unstable on more boards. Therefore there is a proposed patch which completely disables cpufreq driver on 1.2 GHz variant of all A3720 SoC including Espressobin:
https://lore.kernel.org/linux-pm/20210630135942.29730-1-kabel@kernel.org/t/#u
 
If you have any input on this or reaction from Marvell / GlobalScale, please reply.

Patch was merged, so you can build and use firmware from Marvell repository.

Patch was merged, so you can build and use firmware from Marvell repository.

I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18

Well, External Abort means that CPU tried to access memory on the bus (not internal CPU memory) and for some reason access (read or write) cannot be completed and it raised exception. Overheating may cause different issues and if some block on SoC stops working then abort may happen.
 
From your log can be seen that base VDD voltage for 1.2 GHz CPU frequency is set to 1.202 V. Typical voltage for 1.2 GHz freq is documented by Marvell as 1.155 V. Higher voltage value makes CPU more stable, but also increase power usage and temperature. And of course higher temperature make CPU less stable.
 
During testing 1 GHz mode when CPU voltage was too low I saw lot of times either this External Abort or segfault of random processes. So External Abort can be definitely caused by instability of CPU. But in your case it may be because of either high temperature or low voltage or something else... Also it may be because your SoC/CPU tested during manufactoring and checked that is not really stable for 1.2 GHz freq (and so written this information into OTP -- not defined VDD value for 1.2 GHz).

I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18

I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18

This backtrace is from debug version of Trusted Firmware. If you compile it without DEBUG=1 then backtrace is omitted.
 
A3720 SoC does not have full power management like ATX on PC, which can turn power off from all components. This is why function a3700_system_off() in Trusted Firmware is not implemented.
 
Basically I just do not know what this a3700_system_off() should do (if I decide to implement it). It can just call reset or maybe call suspend procedure. A3720 has support for some kind of low power suspend/sleep mode, so maybe this is the best approximation of whole power off.

There is just information that External Abort happened. Not sure what is the issue.
 
Check that you have kernel with v3 version of a3720 cpufreq patches as in v3 was updated VDD value for load L1 when base freq is 1.2 GHz.
 
Also can apply updated cpu_vdd_fallback.patch patch? It does not change behavior, only fixes printf for SVC REV: line. But it can can be useful to verify which CPU VDD value is used.

Done! https://lore.kernel.org/linux-arm-kernel/cf766197-666f-3d7d-3b9e-ba512619004e@gmail.com/

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

Hello! We have sent second version of patches for A3720 which should make 1 GHz mode finally stable:
https://lore.kernel.org/linux-arm-kernel/20210114124032.12765-1-pali@kernel.org/

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.
 

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:
https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/
 
Could you please test these patches if they finally fix also your instability issues on Espressobin V7?

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

Hello @FoodGenius!
 
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.