gprovost Posted October 15, 2020 Author Posted October 15, 2020 11 hours ago, antsu said: - What is the expected temperature range for this SoC? - How does the heatsink interface with the SoC? Pads, paste? - Does the heatsink also make contact with any other chips around the CPU? - Would it benefit in any way from a "re-paste" with high performance thermal paste? 1/ in IDLE around 40C. But beyond that it's hard to define an "expected" temperature too many factors in place. I guess we could give the temperature numbers for each use cases listed in our power consumption table : https://wiki.kobol.io/helios64/hardware/#power-consumption 2/ Thermal pad. 3/ Heatsink is in contact will all key ICs, PMIC and inductors (The "center" square is the SoC) 4/ You can experiment, but i really don't think it would benefit much. 1
RaSca Posted October 15, 2020 Posted October 15, 2020 Hi everybody, as I mentioned on the helios64 site, there seems to be a problem with external USB drives. I've tried with two different of them that works perfectly on other systems, but not here. The first one, once connected (it doesn't matter front or rear), gives these messages: Oct 13 12:42:18 helios64 kernel: usb 2-1.3: USB disconnect, device number 8 Oct 13 12:42:21 helios64 kernel: usb 2-1.2: new SuperSpeed Gen 1 USB device number 9 using xhci-hcd Oct 13 12:42:31 helios64 kernel: usb 2-1.2: New USB device found, idVendor=174c, idProduct=5106, bcdDevice= 0.01 Oct 13 12:42:31 helios64 kernel: usb 2-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Oct 13 12:42:31 helios64 kernel: usb 2-1.2: Product: AS2105 Oct 13 12:42:31 helios64 kernel: usb 2-1.2: Manufacturer: ASMedia Oct 13 12:42:37 helios64 kernel: usb 2-1.2: can't set config #1, error -110 The second one: Oct 14 15:41:07 helios64 kernel: usb 1-1.3: new high-speed USB device number 55 using xhci-hcd Oct 14 15:41:07 helios64 kernel: usb 1-1.3: New USB device found, idVendor=1e68, idProduct=003a, bcdDevice= 1.32 Oct 14 15:41:07 helios64 kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 14 15:41:07 helios64 kernel: usb 1-1.3: Product: DS pocket light Oct 14 15:41:07 helios64 kernel: usb 1-1.3: Manufacturer: TrekStor Oct 14 15:41:07 helios64 kernel: usb 1-1.3: SerialNumber: 201108241936 Oct 14 15:41:07 helios64 kernel: usb-storage 1-1.3:1.0: USB Mass Storage device detected Oct 14 15:41:07 helios64 kernel: scsi host5: usb-storage 1-1.3:1.0 Oct 14 15:41:07 helios64 kernel: usb 1-1.3: USB disconnect, device number 55 Oct 14 15:41:07 helios64 kernel: usb 1-1.3: new high-speed USB device number 56 using xhci-hcd Oct 14 15:41:08 helios64 kernel: usb 1-1.3: device descriptor read/all, error -71 Oct 14 15:41:08 helios64 kernel: usb 1-1.3: new high-speed USB device number 57 using xhci-hcd Oct 14 15:41:09 helios64 kernel: usb 1-1.3: device descriptor read/64, error -71 Oct 14 15:41:09 helios64 kernel: usb 1-1.3: Device not responding to setup address. Oct 14 15:41:10 helios64 kernel: usb 1-1.3: Device not responding to setup address. What is curious is that connecting a USB3 hub, like: Oct 14 15:45:28 helios64 kernel: usb 1-1.3: new high-speed USB device number 126 using xhci-hcd Oct 14 15:45:28 helios64 kernel: usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0612, bcdDevice=90.14 Oct 14 15:45:28 helios64 kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 14 15:45:28 helios64 kernel: usb 1-1.3: Product: USB2.0 Hub Oct 14 15:45:28 helios64 kernel: usb 1-1.3: Manufacturer: GenesysLogic Oct 14 15:45:28 helios64 kernel: hub 1-1.3:1.0: USB hub found Oct 14 15:45:28 helios64 kernel: hub 1-1.3:1.0: 4 ports detected both disks are recognized. As a side note this is a matter of just external USB disks, USB sticks give no problem at all. Any suggestion?
flower Posted October 15, 2020 Posted October 15, 2020 Good news 5.8 seems stable now.I did a paralell stress test on cpu and all hdds for an hour and had it running for about 10h since without any problems.4.4 would lock.Only missing part for me is auto poweron as soon as my house power is back up and 2.5gbit perf problems.I put my unit in production now. Gesendet von meinem CLT-L29 mit Tapatalk
antsu Posted October 15, 2020 Posted October 15, 2020 @RaSca Are your disks powered from the USB port itself, or do they have their own power supplies? Is your USB hub powered externally? To me it sounds like the disks are trying to draw more power than the board can provide, and thus failing. For the record, I have a 14TB WD Elements (powered by a 12V external PSU) connected to my H64 and running flawlessly, reaching the max speeds the disk can provide (~200MB/s reads).
KiSM Posted October 15, 2020 Posted October 15, 2020 (edited) On 10/14/2020 at 7:13 PM, antsu said: @KiSMI had the same kind of issue with the legacy image. It seems anything that puts a constant load on the system eventually causes a kernel crash, and sometimes a reboot. The current image (kernel 5.8) however is rock solid. I've been using it now for 2 days and really stressing both the CPU and disks on my Helios64 without a single problem. @antsu I flashed the image with the 5.8 kernel, set it up the same way I did before and SnapRAID works without issue. Thanks! Edited October 15, 2020 by KiSM @ the person i'm replying to
ebin-dev Posted October 15, 2020 Posted October 15, 2020 On 10/12/2020 at 5:38 AM, aprayoga said: you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature. The auto power on is always enabled by bootloader. If the file /lib/systemd/system-shutdown/disable_auto_poweron is deleted "auto power on" does not happen - it sits just there and waits for the power button to be pressed. Would you please explain any further actions necessary to "enable auto power on" ? The information about the power staggering approach of HDD Rails A and B is very interesting. HDD rail A seem to refer to disks 3,4, and 5. They are powered up first. After about 10s disks 1 and 2 follow. Could you briefly explain how to enable/disable powering HDD rails A and B ?
TDCroPower Posted October 15, 2020 Posted October 15, 2020 The new firmware 20.08.10 is finally available via apt-get... root@helios64:~# apt list --upgradable Listing... Done armbian-config/buster,buster 20.08.10 all [upgradable from: 20.08.8] armbian-firmware/buster,buster 20.08.10 all [upgradable from: 20.08.8] linux-buster-root-current-helios64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-dtb-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-image-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-u-boot-helios64-current/buster 20.08.10 arm64 [upgradable from: 20.08.8] openmediavault-omvextrasorg/buster,buster 5.4.1 all [upgradable from: 5.4] root@helios64:~# As soon as my copy of my backup to my new RAID5 is finished I will update and test the part with the eMMC right away! edit: Perfect, the update went through cleanly and installing/booting from eMMC now works without problems. _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 20.08.10 Buster with Linux 5.8.14-rockchip64 No end-user support: work in progress System load: 28% Up time: 1 min Memory usage: 8% of 3.71G IP: 192.168.180.5 CPU temp: 41°C Usage of /: 45% of 15G Last login: Thu Oct 15 16:47:49 2020 from 192.168.180.83 root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 381M 11M 370M 3% /run /dev/mmcblk1p1 15G 6.1G 7.4G 45% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp folder2ram 1.9G 11M 1.9G 1% /var/log folder2ram 1.9G 0 1.9G 0% /var/tmp folder2ram 1.9G 268K 1.9G 1% /var/lib/openmediavault/rrd folder2ram 1.9G 724K 1.9G 1% /var/spool folder2ram 1.9G 14M 1.9G 1% /var/lib/rrdcached folder2ram 1.9G 12K 1.9G 1% /var/lib/monit folder2ram 1.9G 1.3M 1.9G 1% /var/cache/samba tmpfs 381M 0 381M 0% /run/user/0 root@helios64:~#
tekrantz Posted October 15, 2020 Posted October 15, 2020 As I am (as usual) doing something slightly different can someone tell me what module (or whatever) needs to me loaded to cause the /dev/fan* devices to exist? Thanks in advance!
flower Posted October 15, 2020 Posted October 15, 2020 19 minutes ago, tekrantz said: As I am (as usual) doing something slightly different can someone tell me what module (or whatever) needs to me loaded to cause the /dev/fan* devices to exist? Thanks in advance! i think its pwm_fan. hard to tell as /dev/fan is a symlink and doesnt have a major:minor number root@ghost:~# lsmod|grep pwm_fan pwm_fan 20480 0
tekrantz Posted October 15, 2020 Posted October 15, 2020 16 minutes ago, flower said: i think its pwm_fan. hard to tell as /dev/fan is a symlink and doesnt have a major:minor number root@ghost:~# lsmod|grep pwm_fan pwm_fan 20480 0 Thanks for the info but I have pwm_fan loaded but no /dev/fan* devices.
raoulh Posted October 15, 2020 Posted October 15, 2020 On 10/14/2020 at 5:27 PM, Igor said: Because packages needs up to 24h before they are transmitted around the mirrors. Then package list is updated. And then this will work for you. Patience and perhaps some support? This service is almost entirely paid from our own pockets so complaining is not an option That was not a complain, but a real question. Sorry if you took it wrong.
flower Posted October 15, 2020 Posted October 15, 2020 3 minutes ago, tekrantz said: Thanks for the info but I have pwm_fan loaded but no /dev/fan* devices. ls -alh /dev/fan-p? lrwxrwxrwx 1 root root 41 Oct 15 00:00 /dev/fan-p6 -> /sys/devices/platform/p6-fan/hwmon/hwmon5 lrwxrwxrwx 1 root root 41 Oct 15 00:00 /dev/fan-p7 -> /sys/devices/platform/p7-fan/hwmon/hwmon4 maybe its just the symlink thats missing?
tekrantz Posted October 15, 2020 Posted October 15, 2020 17 minutes ago, flower said: ls -alh /dev/fan-p? lrwxrwxrwx 1 root root 41 Oct 15 00:00 /dev/fan-p6 -> /sys/devices/platform/p6-fan/hwmon/hwmon5 lrwxrwxrwx 1 root root 41 Oct 15 00:00 /dev/fan-p7 -> /sys/devices/platform/p7-fan/hwmon/hwmon4 maybe its just the symlink thats missing? Brilliant, thank you!
registr123 Posted October 15, 2020 Posted October 15, 2020 4 hours ago, TDCroPower said: The new firmware 20.08.10 is finally available via apt-get... root@helios64:~# apt list --upgradable Listing... Done armbian-config/buster,buster 20.08.10 all [upgradable from: 20.08.8] armbian-firmware/buster,buster 20.08.10 all [upgradable from: 20.08.8] linux-buster-root-current-helios64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-dtb-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-image-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-u-boot-helios64-current/buster 20.08.10 arm64 [upgradable from: 20.08.8] openmediavault-omvextrasorg/buster,buster 5.4.1 all [upgradable from: 5.4] root@helios64:~# As soon as my copy of my backup to my new RAID5 is finished I will update and test the part with the eMMC right away! edit: Perfect, the update went through cleanly and installing/booting from eMMC now works without problems. _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 20.08.10 Buster with Linux 5.8.14-rockchip64 No end-user support: work in progress System load: 28% Up time: 1 min Memory usage: 8% of 3.71G IP: 192.168.180.5 CPU temp: 41°C Usage of /: 45% of 15G Last login: Thu Oct 15 16:47:49 2020 from 192.168.180.83 root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 381M 11M 370M 3% /run /dev/mmcblk1p1 15G 6.1G 7.4G 45% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp folder2ram 1.9G 11M 1.9G 1% /var/log folder2ram 1.9G 0 1.9G 0% /var/tmp folder2ram 1.9G 268K 1.9G 1% /var/lib/openmediavault/rrd folder2ram 1.9G 724K 1.9G 1% /var/spool folder2ram 1.9G 14M 1.9G 1% /var/lib/rrdcached folder2ram 1.9G 12K 1.9G 1% /var/lib/monit folder2ram 1.9G 1.3M 1.9G 1% /var/cache/samba tmpfs 381M 0 381M 0% /run/user/0 root@helios64:~# did you use nand-sata-install ?
antsu Posted October 15, 2020 Posted October 15, 2020 A little advice for anyone planning to use nand-sata-install to install on the eMMC and has already installed and configured OMV: nand-sata-install will break OMV, but it's easy to fix if you know what's happening. It will skip /srv when copying the root to avoid copying stuff from other mounted filesystems, but OMV 5 stores part of its config in there (salt and pillar folders) and will throw a fit if they're not there when you boot from the eMMC. Simply copy these folders back from the microSD using your preferred method. If you have NFS shares set in OMV, make sure to add the entry /export/* to the file /usr/lib/nand-sata-install/exclude.txt BEFORE running nand-sata-install, or it will try to copy the content of your NFS shares to the eMMC. Lastly, if you're using ZFS, which by default mounts to /<pool_name>, make sure to add its mountpoint to /usr/lib/nand-sata-install/exclude.txt before nand-sata-install as well. 4
TDCroPower Posted October 15, 2020 Posted October 15, 2020 2 hours ago, registr123 said: did you use nand-sata-install ? yes I have. I started it via armbian-config >>> System >>> Install >>> "2 Boot from eMMC - system on eMMC", but it is the same script that is behind it. Before that I installed OMV and Docker natively on the system and pihole, unifi controller, iobroker and emby server as container. @antsu you are probably right, because under /srv I cant't find my OMV -> SMB Shared Folders... root@helios64:~# ll /srv/ total 0 root@helios64:~# i try to boot from the microSD again to save the 2 directories. You should tell the armbian team or the dev of the nand-sata-install script. I think you can do this via their Jira ticket system? edit: unfortunately I did not manage to boot from the microSD again. Does anyone know how to switch from eMMC boot to microSD boot? Solution: with this mount command... mount /dev/mmcblk0p1 /mnt ... you can have access to the microsd files under /mnt... root@helios64:~# ll /mnt/ total 96 lrwxrwxrwx 1 root root 7 Aug 30 20:55 bin -> usr/bin drwxr-xr-x 3 root root 4096 Oct 15 16:47 boot drwxr-xr-x 2 root root 4096 Oct 5 16:04 dev drwxr-xr-x 108 root root 12288 Oct 15 16:49 etc drwxr-xr-x 2 root root 4096 Sep 22 02:38 export drwxr-xr-x 3 root root 4096 Oct 6 02:24 home lrwxrwxrwx 1 root root 7 Aug 30 20:55 lib -> usr/lib drwx------ 2 root root 16384 Oct 5 16:17 lost+found drwxr-xr-x 2 root root 4096 Aug 30 20:55 media drwxr-xr-x 4 root root 4096 Oct 15 16:48 mnt drwxr-xr-x 4 root root 4096 Oct 14 01:18 opt drwxr-xr-x 2 root root 4096 Jul 10 23:04 proc drwx------ 5 root root 4096 Oct 14 01:39 root drwxr-xr-x 2 root root 4096 Oct 5 16:13 run lrwxrwxrwx 1 root root 8 Aug 30 20:55 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 5 16:05 selinux drwxr-xr-x 2 root root 4096 Sep 22 02:38 sharedfolders drwxr-xr-x 6 root root 4096 Oct 15 16:39 srv drwxr-xr-x 2 root root 4096 Jul 10 23:04 sys drwxrwxrwt 2 root root 4096 Oct 5 16:17 tmp drwxr-xr-x 11 root root 4096 Oct 6 03:22 usr drwxr-xr-x 14 root root 4096 Oct 6 03:12 var root@helios64:~# and to copy the two directories back into the /srv directory just use the following two commands... cp -r /mnt/srv/pillar /srv cp -r /mnt/srv/salt /srv ... and after an reboot its back... root@helios64:~# ll /srv/ total 16 drwxr-xr-x 10 root root 4096 Oct 15 16:40 dev-disk-by-label-nas drwxr-xr-x 2 ftp nogroup 4096 Oct 6 03:06 ftp drwxr-xr-x 3 root root 4096 Oct 6 03:05 pillar drwxr-xr-x 5 root root 4096 Oct 6 03:05 salt root@helios64:~#
axeleroy Posted October 15, 2020 Posted October 15, 2020 Hi, Not sure if this is the right place, but I cannot seem to boot Armbian 20.08.10 Kernel 5.8 from SD. After I unsuccessfully installed on a Samsung EVO SD Card, I tried once again on a Sandisk Ultra (this exact model) but it has been stuck on "Starting Kernel..." for more than 5 minutes. I'm not sure if it's just the first boot that takes a while or if I botched something. Also probably not helping is that the provided USB C to A cable is a bit loose and can easily be pulled from the board. Thanks!
flower Posted October 17, 2020 Posted October 17, 2020 Some of you had the problem that the back of the enclosure does not really fit and stuck a few mm to the outside - leading to loose usb cables.I use noctua fans which are bigger and had the same problem since then.I could solve it by putting that fan cage thingy outside and not inside the case.Maybe it helps you tooGesendet von meinem CLT-L29 mit Tapatalk 1
TDCroPower Posted October 18, 2020 Posted October 18, 2020 After several weeks of testing and trying I finally put my Helios64 into production. With the 20.08.10 and the possibility to run the firmware over the eMMC I can finally sleep more calmly again. The front view mounted: The back view connected: And to prevent my wife from killing me because there is a lighting party going on in the hallway I taped the front LEDs with insulating tape... And for all who have problems with the included USB-C cable at the USB-C port of the Helios64. You have to remove the plastic so that the connector looks like this... The black plastic of the USB-C cable must NOT touch the backside of the Helios64, this ensures that the Cable is 100% plugged in. 1
djurny Posted October 18, 2020 Posted October 18, 2020 Hi all, In the last few days, finally found some time to migrate my helios4 backup node to helios64. In the beginning I had some trouble accessing the serial console, but this was resolved in the end. Spoiler Connected the USB-C - USB-A cable to a USB hub, connected to a RaspberryPi (2B). RaspberryPi detected USB/serial converter: [...] kernel: [869447.887756] usb 1-1.4.4.3: FTDI USB Serial Device converter now attached to ttyUSB4 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 3: Dev 11, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 1: Dev 9, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 2: Dev 6, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M Bus 001 Device 011: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Connected serial console using "screen /dev/ttyUSB4 1500000" but no output seen. (Mapping is sound, see output of syslog/lsusb. One helios4 is disconnected at the moment, so only 3 out of 4 are showing in lsusb at the moment.) Thought it had to do with the USB hub on the Pi, as there are 4 other USB-to-serial converters connected to it and I am running the hub without external power. Used my laptop, also using screen, but still no output seen. Then switched back to the Pi and used picocom (as mentioned on the wiki), but I could not select 1500000 baudrate? $ picocom /dev/ttyUSB4 -b 1500000 picocom v1.7 port is : /dev/ttyUSB4 flowcontrol : none baudrate is : 1500000 parity is : none databits are : 8 escape is : C-a [...] FATAL: failed to add device /dev/ttyUSB4: Invalid baud rate In the end I used minicom and oddly enough, output was seen. Did not look any further (lazy and working on getting ansible configuration working with the new helios64 setup). I want to ask if anyone has issues with the red disk status LEDs? As it seems like 3 of them are not responding to setting values in /sys/class/leds/helios64:red:ata?-err/brightness. Looks a bit odd with allmost all of the error LEDs on. Groetjes,
gprovost Posted October 18, 2020 Author Posted October 18, 2020 12 minutes ago, djurny said: I want to ask if anyone has issues with the red disk status LEDs? As it seems like 3 of them are not responding to setting values in /sys/class/leds/helios64:red:ata?-err/brightness. Looks a bit odd with allmost all of the error LEDs on. It might be that one side of front panel (the side with red LEDs) touch a bit the metal opening shorting the LED therefore lighting them up. Could you trip to loosen a bit the 2x screws holding the front panel, then push a bit back the PCB, then tighten again the screw. Otherwise putting a piece of tape on the PCB side that touch the metal opening, to isolate the LED, could help. For next batch we will have to increase more the gap because mass production doesn't seem to meet exactly our tolerance requirement :-/ 2
Bethlehem Posted October 18, 2020 Posted October 18, 2020 The Linux 5.8 kernel is getting more and more stable now. I have to do a hard-reset on Helios64 at least once per day before and I rarely have to do it after Armbian 20.08.10. Although I am still waiting for the DAS mode to be sorted out on USB-C port (I never touched the USB-C port after getting OMV fixed up). My only concern now is the CPU temperature. It sometimes runs up to around 65-70 C. I got a spare 2-pin cpu fan that I bought for my Raspberry Pi 4 and I think it could be installed onto the Helios64's heatsink. I just have to figure out where should the two power pins be put onto. Note.: I installed the OS on MicroSD card. I know EMMC would run faster but I am OK with the speed now.
TDCroPower Posted October 18, 2020 Posted October 18, 2020 @Bethlehem my Helios64 installation with 3x WD Red 4TB, OMV und Docker nativ -> Containers: Portainer, pihole, iobroker, emby, unifi controller, netdata... runs at 45°C Welcome to Armbian 20.08.10 Buster with Linux 5.8.14-rockchip64 No end-user support: work in progress System load: 20% Up time: 1 day 9:02 Memory usage: 61% of 3.71G IP: 172.18.0.1 192.168.180.5 CPU temp: 45°C Usage of /: 59% of 15G [ General system configuration (beta): armbian-config ] Last login: Sun Oct 18 03:35:55 2020 from 192.168.180.83 root@helios64:~# note that the change to eMMC is not necessarily only about speed, mainly about the stability an eMMC has compared to a microSD. A microSD will most likely die faster than an eMMC. Especially if you want to run your system in the background in continuous operation at some point, a microSD in continuous operation is not pleasant.
flower Posted October 18, 2020 Posted October 18, 2020 (edited) 48 minutes ago, Bethlehem said: The Linux 5.8 kernel is getting more and more stable now. I have to do a hard-reset on Helios64 at least once per day before and I rarely have to do it after Armbian 20.08.10. Although I am still waiting for the DAS mode to be sorted out on USB-C port (I never touched the USB-C port after getting OMV fixed up). My only concern now is the CPU temperature. It sometimes runs up to around 65-70 C. I got a spare 2-pin cpu fan that I bought for my Raspberry Pi 4 and I think it could be installed onto the Helios64's heatsink. I just have to figure out where should the two power pins be put onto. Note.: I installed the OS on MicroSD card. I know EMMC would run faster but I am OK with the speed now. Rockchip says CPU is Ok with temps up to 80 degree. Do you have any load? Without load my unit is around 50 degree. if i stress test cpu and hdd it goes up to 78 degree. think about airflow when installing that small fan. normally the air goes from the front to the backside. another fan would probably disturb that flow. regarding emmc: the speedup is not that big. actually i prefer running of sd because it is way easier to backup and to replace. there are not many writes to the emmc while running anyway (not sure if this is true for omv though) EDIT: you can also install updates without any fear while using sd. just keep a known working copy somewhere Edited October 18, 2020 by flower add a line
TDCroPower Posted October 18, 2020 Posted October 18, 2020 @aprayoga was once again very active, so we can look forward to further optimizations in the next armbian releases ... https://github.com/armbian/build/commit/079b467342fffa7678f903793c589e9fe9fb8b69 https://github.com/armbian/build/commit/5e62c071f0c4bafd1d25ef5f5259bb485935a77e 1
registr123 Posted October 18, 2020 Posted October 18, 2020 2 hours ago, Bethlehem said: My only concern now is the CPU temperature. It sometimes runs up to around 65-70 C. I got a spare 2-pin cpu fan that I bought for my Raspberry Pi 4 and I think it could be installed onto the Helios64's heatsink. I just have to figure out where should the two power pins be put onto. CPU temp: 45°C on average for me. 5 WD disks inside omv and few containers running
barnumbirr Posted October 18, 2020 Posted October 18, 2020 Just now, registr123 said: CPU temp: 45°C on average for me. 5 WD disks inside omv and few containers running 42°C for me with 5x12TB WD drives with OMV, Plex and rtorrent/rutorrent running. I did change the fans for Noctua ones and have tweaked fancontrol to suit the upgrade.
djurny Posted October 18, 2020 Posted October 18, 2020 7 hours ago, gprovost said: It might be that one side of front panel (the side with red LEDs) touch a bit the metal opening shorting the LED therefore lighting them up. D'oh. Looks like that is indeed the case. Will plan to try to add some clearance for the front panel during the next scheduled down activity
JeffDwork Posted October 19, 2020 Posted October 19, 2020 12 hours ago, TDCroPower said: After several weeks of testing and trying I finally put my Helios64 into production. With the 20.08.10 and the possibility to run the firmware over the eMMC I can finally sleep more calmly again. And to prevent my wife from killing me because there is a lighting party going on in the hallway I taped the front LEDs with insulating tape... Search on Amazon for LightDims. Stick-on, peel-off semi-transparent plastic film in several different transparency levels - 50%, 15%, 0% (perhaps more levels).
RamsDeep Posted October 19, 2020 Posted October 19, 2020 Is there a How-To for deploying ZFS anywhere? I am a beginner and figuring this out as I go. Installing the module from OMV does not appear to work for me currently Thanks
Recommended Posts