• Content Count

  • Joined

  • Last visited

About Heisath

  • Rank
    Elite member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1066 profile views
  1. Hi FredK, The contradicting armbian version numbers are thing open to discussion. Basically armbian uses many packages and not all of them get updated everytime -> different version number exist. This is synced at every major release. The fact alone that the linux kernel 5.8 was released with 20.08.xx was a mistake on armbian side. Sorry for the problems we caused. If you can live with the LEDs not working a fix will be available at the latest for the 20.11 release (end of November). If you need the LEDs working now you can switch to kernel version 5.4.xx (via a
  2. Hi FredK, I confirmed your problem. There seems to be some issue on the pin assignment of the LEDs. Can you tell us which kernel version you are using? (output of uname -a and/or armbianmonitor -u) As a quick fix you can go back to 20.08.13 or try to just downgrade the kernel via armbian-config. Regards, Heisath
  3. Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. Apart from that, please tell us which pcie cards you are using exactly and which pcie bridge. Depending on the manufacturer of the network cards they might all have the same MAC address, that would explain your problem. And just to make sure I understood you correctly, if you use all 3 cards and 3 seperate PCs it works? Then it will not be a driver issue.
  4. A "howto setup armbian build environment" video would also be good. Just start with installed virtualbox and go over installing Ubuntu Focal, getting the github stuff, building for some board. That way new users could easier activate, test, report "missing" kernel features.
  5. Yep the Espressobin is not optimal for routing / switching. If you need multiple eth's maybe look at the PCEngines boards (APU2) which have up to 4 dedicated Gbit ports. https://pcengines.ch/apu4d4.htm Or check the Clearfogpro / base. These atleast have a seperate SFP port, which can be used as copper/fiber with up to 2.5Gbit/s and additional LANs.
  6. Regarding SSD performance in general: 1Gbit/s Ethernet would limit your data rates to about 120MB/s, which normal drives are also capable of doing. But an SSD also has the big advantage of faster (nearly instant) access times (to any sector/block) which is definitely noticable when running VMs (as their data is more random access than serial). Bonding several eth links together is no problem (regardless wether they are directly attached or via USB3 / whatever). See the Linux Bonding package for more info https://help.ubuntu.com/community/UbuntuBonding (for example). If have
  7. Will need to try this. And talk with @gprovost about it, regarding their time for helios4. Lets discuss this in its own thread, as this is not coupled with 20.08 release. @Hijax and I are still testing / discussing this. Current plan is to order a few board (4) (assembled) from JLCPCB just for us to test.
  8. I missed the meeting, sorry. Nothing to add from mvebu side though. I've been busy with the armbian-testing boards.
  9. Well thanks for the (late) reply. I fixed this in between, somehow my apt got detached and did not update the rootfs package.
  10. Anyway, next steps to save time are: - completely remove NetworkManager (you need to do your network config the classic way then). - remove armbian zram and ramlog (which can be done via apt remove or just disable the services) - make sure your device does not run a fsck on every boot - remove u-boot 'prompt timeout' (the time the bootloader waits for user input before booting the system, I guess thats 3s default on armbian) Btw. no guarantee that your system works perfectly after above steps - there's a reason for every service running.
  11. @Userlab If you need to get bigger M.2 cards in there I can suggest using an adapter with extension cable like this: https://www.amazon.com/Sintech-M-Key-Extention-Cable-20CMS/dp/B07DZCCGJN/ You can break the device side to any length you need it. And attach larger and wider cards at the other end.
  12. You could also disable the "NetworkManager-wait-online.service" service. This normally waits a few seconds until some network connection has been established. Use "systemctl disable NetworkManager-wait-online.service" to disable it.
  13. Also you can (as always) download the current versions directly from armbian. https://www.armbian.com/helios4/ https://dl.armbian.com/helios4/
  14. The information you linked indicating there is 2.5Gbps mode is always only for the chip (Armada 3700) used on the espressobin. This Marvell chip does have the 2.5Gbps interface. That is also the reason it is explained on Marvell github. The espressobin itself has all 3 ethernet ports wired through one switch with only RGMII going in. As can be seen here: http://wiki.espressobin.net/tiki-index.php?page=Block+diagram As only one RGMII is feeding all 3 ports I dont think 2.5Gbps will be possible on any of them.
  15. Yeah measuring 3.3V failure or higher frequency is hard(er) do find. But you could atleast measure 5V and 12V while the board with hdds is running. If all looks fine there we can investigate further, but maybe the supply brick is broken. Check this post on where/howto measure: