ebin-dev

Members
  • Posts

    274
  • Joined

  • Last visited

2 Followers

Recent Profile Visitors

2931 profile views

ebin-dev's Achievements

  1. Rock 5 B (Pico ITX - 8-core) is really powerful and power efficient (8nm lithography). I have preordered one.
  2. 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 ?
  3. 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).
  4. 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).
  5. 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!
  6. 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 ?
  7. 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.
  8. 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.
  9. 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
  10. @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.
  11. Just recently I purchased a 2.5G switch to improve network bandwidth (and latency). I am really thrilled regarding the performance and stability of Helios64 using the 2.5G interface (eth1). I am currently on Armbian 21.08.3 Bullseye with Linux 5.10.43-rockchip64 (no errors at all). With netatalk as a file server I can access now large files with 255 MByte/s. This is clearly enough to work on files stored on the Helio64 (i.e. accessing RAW images on the remote ssd, processing them on a laptop and writing back the resulting dng and jpg images). Does anyone know if there is a power save state that could be configurerd for eth1 - or is this something that depends entirely on the switch ? Helios64 rocks ! I really hope that the Kobol team will resume operations once the chip shortage is overcome. EDIT: I am using the default cpufreq settings: # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand
  12. If you followed the example given by werner it should be mounted to /mount ... Try this: sudo vim /mount/boot/armbianEnv.txt
  13. On emmc (/dev/mmcblk2p1) you just need to replace the root UUID in /etc/fstab and in /boot/armbianEnv.txt to match the UUID of your emmc (e4e3bcd6-3f03-4362-bbe0-f1654138c5d8). Then reboot without microsd in the slot...
  14. Actually I am currently just exploring. Using Kodi as a headless server to stream to DLNA enabled devices turned out to be suboptimal :-)) . Meanwhile I switched to Plex on the server. For all clients (SmartTV, Computers and iOS Devices) a native Plex app is available for free (except for iOS - a one time fee of 4.99 Euros is required for each device) and I am astonished about the performance and professional look of the system. The installation is configured as non-accessible from the outside - nonetheless the media can be streamed to remote devices coupled to the home network via VPN. Setting up a client-server system with Plex is a "no-brainer". You just have to make sure that the required ports are not used by other servers (port 9090 was used by another media server in my case). I would strongly recommend Plex if you wish to stream content from a (headless) server to various client devices in your home network.
  15. Thank you very much for the hint. Installation of the packages went smoothly on the headless server. After messing around with the configuration files guisettings.xml and advancedsettings.xml I could access the web interface on port 8080 and change the settings, configure some addons etc. However, it would not appear to be possible to add a media library or addons using the web interface - the required functionality is not displayed. Is this a known limitation of the web interface or is this due to a mistake on my side ? As there is no access to any other Kodi GUI on the headless server I am stuck at that point. I am looking forward to test Kodi 19 packages once you found some time to build them.