Helios64 Support


Recommended Posts

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)

 

IMG_8053.thumb.JPG.ce53567ed26f8e80c6298bddea19a8ff.JPG

 

4/ You can experiment, but i really don't think it would benefit much.

Link to post
Share on other sites
  • Werner pinned, unpinned, featured and unfeatured this topic
Donate and support the project!

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?

Link to post
Share on other sites

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

Link to post
Share on other sites

@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).

Link to post
Share on other sites
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 by KiSM
@ the person i'm replying to
Link to post
Share on other sites
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 ?

Link to post
Share on other sites

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:~#

 

Link to post
Share on other sites
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

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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 :P

 

That was not a complain, but a real question. Sorry if you took it wrong.

Link to post
Share on other sites
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?

Link to post
Share on other sites
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!

Link to post
Share on other sites
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 ?

Link to post
Share on other sites

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.

Link to post
Share on other sites
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:~#

 

Link to post
Share on other sites

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!

Link to post
Share on other sites

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 tooeb98a99a88088006651654f82b0e5140.jpg

Gesendet von meinem CLT-L29 mit Tapatalk

Link to post
Share on other sites

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:

ln6nHBB.jpg

 

w9i4NmH.jpg

 

The back view connected:

5BTZLjX.jpg

 

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...

YFFjgEr.jpg

 

 

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...

FzXS9L1.jpg

 

au0gMG9.jpg

 

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.

Link to post
Share on other sites

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,

P_20201017_091336.jpg

P_20201017_155744.jpg

Link to post
Share on other sites
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  :-/

Link to post
Share on other sites

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.

Link to post
Share on other sites

@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.

Link to post
Share on other sites
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 by flower
add a line
Link to post
Share on other sites
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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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 :)

Link to post
Share on other sites
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).

Link to post
Share on other sites
  • Werner locked this topic
Guest
This topic is now closed to further replies.