Jump to content


  • Posts

  • Joined

  • Last visited


Recent Profile Visitors

3345 profile views
  1. @prahal Thanks for fixing this bug ! You mentioned, that you are investigating the emmc hs400 issue. Once you (or someone else) found a solution to it, please let us know. We could then try to test newer versions of the linux kernel and see what remains to be done.
  2. not necessary - not even desired by most of the helios64 users
  3. Just put a # in front of the line in armbian.list (should have the same effect as freeze kernel in armbian-config): cat /etc/apt/sources.list.d/armbian.list # deb http://apt.armbian.com bullseye main bullseye-utils bullseye-desktop Regarding a new kernel: the new ones (newer than 5.10.43) do not support emmc speed HS400, seem to have issues with the 2.5Gb/s interface (transfer rates are about half the speed), and the switch to the new mainlined bootloader is essentially untested... Would be wise to focus on this - besides the general stability.
  4. @bunducafe I am still running this system: Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64. The Armbian image should still be available in the archive and I downgraded linux to 5.10.43, since this is the last version able to access emmc with hs400. Since there is no maintainer I have disabled any updates through the Armbian channel (in /etc/apt/sources.list.d/armbian.list). Debian Bullseye updates are not affected in any way by this and still arrive from time to time. That is fine for now.
  5. @grek Would you have the possibility to test the speed of the 2.5 Gb/s Ethernet Interface with your system ?
  6. Rock 5 B (Pico ITX - 8-core) is really powerful and power efficient (8nm lithography). I have preordered one.
  7. I just had an issue with the 2.5G interface after the latest update to Armbian Bullseye 22.02.01 (linux 5.15.25): The 2.5G Interface would not appear to work as expected anymore. A 12.225 GB test file was transferred from Helios64 to a client via a 2.5G switch using netatalk with only about 120 MB/s. The system I am normally using ( Armbian 21.08.2 Bullseye, linux downgraded to 5.10.43), transfers the file with 271 MB/s (as expected). Here are the related dmesg messages : [ 11.159252] r8152 2-1.4:1.0: Direct firmware load for rtl_nic/rtl8156a-2.fw failed with error -2 [ 11.159293] r8152 2-1.4:1.0: unable to load firmware patch rtl_nic/rtl8156a-2.fw (-2) [ 11.199745] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256 [ 11.215517] r8152 2-1.4:1.0 eth1: v1.12.12 [ 11.215734] usbcore: registered new interface driver r8152 [ 14.606490] r8152 2-1.4:1.0 eth1: Promiscuous mode enabled [ 14.606732] r8152 2-1.4:1.0 eth1: carrier on Is there anyone observing the same issue ?
  8. Interesting ! I tried again with a fresh Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) on SD and used apt update && apt upgrade to install the latest kernel 5.15.25. After a reboot, an rsync from SD to another SD attached to the USB port worked perfectly. I have noticed today that SD and emmc device names have changed between linux 5.10.xx and linux 5.15.yy from /dev/mmcblk2p1 (emmc) and /dev/mmcblk1p1 (SD) to /dev/mmcblk1p1 and /dev/mmcblk0p1 respectively. Since my backup scripts use the device names they could not work correctly anymore with kernel 5.15.yy. MEA CULPA. All device names are now replaced by their corresponding UUIDs in the backup scripts - so that this can't happen again. So you can update your buster or bullseye installation to the latest Armbian kernel (no rsync issues) - but be aware that there are still some other issues to be resolved, in particular if you are using zfs-dkms (see the parallel threads).
  9. You can downgrade linux from 5.10.63 to 5.10.43: just install those files with dpkg -i *.deb (headers included, full emmc speed).
  10. Hi there, the emmc issues were solved by reducing read/write speed by a factor of 2 (thanks to @piter75). Unfortunately this is still the case with newer kernels 5.15.xx. I am still using linux 5.10.43 without any issues and without the emmc speed limitation (Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64). Upgrading from Buster to Bullseye should work, but your mileage may vary depending on your specific Buster installation. The upgrade will install the newest kernel 5.15.25. I had troubles at least with rsync in this context. Alternatively you can grab the latest Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) from the archive and downgrade to linux 5.10.43. To do that you just need to download those files and install them with 'dpkg -i *.deb' and disable any further Armbian updates in /etc/apt/sources.list.d/armbian.list . Debian updates will still arrive ... The system on SD can be transferred to emmc. Cheers!
  11. Hi, updating Helios64 (Armbian Bullseye) to the latest kernel (Armbian 22.02.1 with Linux 5.15.25-rockchip64) went flawlessly - it seems to be stable so far (Thanks!). However, emmc read/write speed is still reduced by a factor of 2 compared to linux 5.10.43. @piter75 Do you know if there is anybody trying to re-enable high emmc read/write speeds in newer kernels ?
  12. I can understand that you are disappointed. But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all. All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.
  13. Kobol stopped operations (partly due to the chip shortage) and @gprovost himself did not exclude that Kobol may resume operations some time again. I am still hoping that we will see a follow-up of Helios64 based on a successor of the rk3399 developed by Kobol.
  14. Some Helios64 had issues with CPU freezes or other instabilities. If you buy one you should make sure that you can give it back if it is one of those. Cheers ebin-dev
  15. @flowerThe 2.5G interface (eth1) indeed operates absolutely reliable if connected to a 2.5G switch - even without the hardware mod and using current Armbian Bullseye (kernel downgraded to 5.10.43). My interfaces are managed by systemd-networkd - the config files for the bridged setup are attached below. With this configuration the interfaces receive ipv4 and link local ipv6 addresses. Net transfer rates are around 255 MBytes/s (a nice alternative to bonding two 1Gig Ethernet interfaces). Armbian 21.08.6 Bullseye with Linux 5.10.43-rockchip64 # cd /etc/systemd/network/ # ls -la total 20 drwxr-xr-x 2 root root 4096 Nov 16 14:42 . drwxr-xr-x 6 root root 4096 Nov 26 07:00 .. -rw-r--r-- 1 root root 30 Nov 26 2020 br0.netdev -rw-r--r-- 1 root root 233 Oct 10 19:27 br0.network -rw-r--r-- 1 root root 40 Nov 16 14:42 eth0.network # cat br0.netdev [NetDev] Name=br0 Kind=bridge # cat br0.network [Match] Name=br0 [Network] IPForward=yes DHCP=no Address=192.168.xxx.xxx/24 Gateway=192.168.xxx.xxx DNS=192.168.xxx.xxx # cat eth0.network [Match] Name=eth1 [Network] Bridge=br0 # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether off unmanaged 3 br0 bridge routable configured 4 eth1 ether enslaved configured 5 lxcbr0 bridge no-carrier unmanaged 6 vethpivccu ether degraded unmanaged 6 links listed.
  • Create New...