Pali

Do you mean loading firmware directly from SATA (without NOR)? Or loading firmware from NOR and only loading kernel from SATA? Last week I updated documentation how to build & store fimware to SATA disk (needs special partition), see: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html (search for "SATA device boot") And last year I have tested that U-Boot loaded from NOR is able to access SATA disk and load kernel from it without need to use uSD card. If it does not work post U-Boot output from serial console.

You need to wait or you can try to remind your email on mailing list... I did not have time to look at it.

Perfect! Thank you for testing. Would you mind replying to that mailing list email with "Tested-by: your name" line? If it is stable on your board then I think other tests are not needed. You may try to enable ondemand governor and let board running under normal conditions for a longer time if you do not see any other issues.

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

@RöttiThis looks like an AHCI or PCIe issue. Please report bug to the linux-ide@vger.kernel.org mailing list where are more SATA/AHCI developers and could help you to debug issue. Maybe it is also A3720 related PCIe issue, so send me an email I can provide you a A3720 PCIe patch which could fix some stability issues.

I have been communicating with Globalscaletechnologies and they confirmed me that LED2 is broken on v5 and cannot be fixed. On v7 it is working fine, I have prepared patch (now in mainline kernel) for it which other people tested and it worked. I do not have v7 so cannot show it, but relevant file is exported via /sys/class/leds/led2/brightness.

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/

I have already wrote that led 2 connected to GPIO does not work on espressobin v5. And on espressobion v7 is already enabled and available in mainline kernel v7 dts files.

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.

Which one is red led? IIRC espressobin v5 has only 2 leds: power which is always on (when power adapter is attached) and wifi led which is conrolled by wifi card (if you have e.g. ath9k card you can control it via ath9k driver). There is also third led (labeled led2) but this one is non-working due to HW bug.

@odoll: This is not Globalscale issue, but rather Marvell issue as it affects all A3720 boards, not only Espressobin. See for more details my post: https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/?do=findComment&comment=110302 There are new kernel patches which should address this issue: https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/ Could you test them if they fixes instability also of your Espressobin?

Seems that another source of problems is bootenv where is hardcoded another set of mac addresses... https://github.com/armbian/build/blob/master/config/bootenv/mvebu64.txt

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

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?

Hello! There is a bug in kernel's cpufreq driver which cause that Armada 3720 SOC is running only at 800 MHz, even it reports 1 GHz. Marek sent patches which fix this issue. See link https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/ @Anders: Would you be able to test these patches and check if they are stable on your Espressobin V7 boards?

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

@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 @gtg498u, could you try to update U-Boot to new version from 2020 as described in thread https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/? As I wrote, new version contains lot of fixes for Armada 3720.

@dhewg: It is classic internet troll who just want to make people angry and spam discussion. It is its primary aim... you probably have not seen such trolls in technical discussions/mailinglists as there is no place for such entities. Just ignore it and all its comments as they contains zero information. Do not loose your temper, do not write any reply to its posts, i.e. do not feed trolls. Looks like it does not understand main fact that without people like you who develop, test and prepare binaries of upstream images, there would be no working hw support, and therefore also no armbian support... EDIT, @dhewg: you can put it into ignore list and its comments would be hidden, so no troll spam anymore.

Hello @gtg498u! You should ignore @Igor's comments as it looks like that it is some local forum troll and joking that defend his decision that armbian erases ethernet MAC address is the correct. Also in this thread he said that U-Boot v2019.04-rc4 is very old version and you should use last version, but his armbian provides only U-Boot version U-Boot 2018.03, which is even older. So do not take his comments seriously. And based on these fatal decisions I would not be surprised that other things start to be broken with new u-boot or kernel versions, if there are other similar custom armbian patches like that which erase MAC address. @gtg498u: Could you look at thread https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/ and try to use @dhewg's builds of ATF+u-boot? We have sent more patches to upstream U-Boot to fix Armada 3720 HW, so it should work better than armbian builds. Also from that kernel log I see that crash is in aardvark PCIe bus driver. I sent more fixes for aardvark driver into 5.8 kernel which should make support for ath10k cards more stable. Could try to use 5.8 kernel? If problems are still there, please send me whole dmesg log and I will try to look at aardvark/A3720 issues.

@dhewg: Look at issue https://forum.armbian.com/topic/10281-espressobin-all-boards-and-all-nics-have-the-same-mac-address/?do=findComment&comment=107341 Armbian boot script basically damaged any uniqueness of MAC addresses, plus it erase factory MAC address. That is why I put into README file that warning and steps how to recover Espressobin from broken Armbian. And based on this and other @Igor's reaction in other threads it looks like it is joking or trolling. I guess that problem in https://forum.armbian.com/topic/15054-kernel-54-rc4-worksdo-i-need-u-boot-v201904-rc4/ may be also related to some changes in uboot/script/kernel.

@lmhhj: Can you try 5.8 kernel? It contains lot of fixes in 3720 pcie driver. Also, if you have problems with MSI interrupts, you can try to turn them off and use just classic PCI interrupts by appending pci=nomsi into boot args.

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.

As I wrote mac address is normally stored in env variable at location stored in manufactured uboot. If you had compiled your own uboot version, you may set different location for env in SPI which would lead to not loading env variables. But in any case, erasing existing mac address or permanently removing it, by changing it by static hardcoded value is the worst what could have been done. Even abnormal behavior does not excuse permanent removal of existing manufactur mac address. I have already sent README update patch.

This is due to broken and insane armbian uboot boot script: https://dl.armbian.com/espressobin/u-boot/bootscript/boot.cmd This armbian boot script overwrites mac address to F0:AD:4E:03:64:7F for all espressobin boards. Normally espressobin boards have stored in this variable its original mac address assigned at manufacturing, but somebody in armbian must have been drunk when decided to erase original mac address and replace it by static value for all espressobin boards. Last version of mainline linux kernel (+upcoming stable kernel releases) are able to read mac address from uboot env (as passed via FDT; kernel patch), so the best is to restore espressobin's original mac address into uboot (espressobin boards had stick with printed mac address) and stop using that insane uboot armbian script which erases original unique mac address.