• Content Count

  • Joined

About Pali

  • Rank

Recent Profile Visitors

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

  1. 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.
  2. @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
  3. 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
  4. @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
  5. @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.
  6. 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
  7. 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.
  8. 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