• Content Count

  • Joined

Everything posted by Pali

  1. 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.
  2. Hello! We have sent second version of patches for A3720 which should make 1 GHz mode finally stable:
  3. 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.
  4. Yes, see my comment 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 where I wrote how to detect CPU variant.
  5. 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.
  6. @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: There are new kernel patches which should address this issue: Could you test them if they fixes instability also of your Espressobin?
  7. Seems that another source of problems is bootenv where is hardcoded another set of mac addresses...
  8. @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: Could you please test them and check if it fixes that issue on your board?
  9. 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?
  10. 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 @Anders: Would you be able to test these patches and check if they are stable on your Espressobin V7 boards?
  11. @ebin-devand do you have Espressobin with A3720 1.2GHz SOC? See my post 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.
  12. @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 at page 154 is de
  13. Hello @gtg498u, could you try to update U-Boot to new version from 2020 as described in thread As I wrote, new version contains lot of fixes for Armada 3720.
  14. @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
  15. 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
  16. @dhewg: Look at issue 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 may be also relate
  17. @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.
  18. 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
  19. 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.
  20. This is due to broken and insane armbian uboot boot script: 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