Pali

  • Content Count

    16
  • Joined

About Pali

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @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?
  2. 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
  3. @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?
  4. 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?
  5. 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?
  6. @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.
  7. @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 de
  8. 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.
  9. @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 suppor
  10. 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
  11. @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 relate
  12. @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.
  13. 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
  14. 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.
  15. 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