gprovost

I don't know the reason for having NTFS on these disks. Maybe laziness, maybe concerns to simply take out the disk and put it back into your Windows PC for recovery etc...
but just want to let you know that also for Windows exist driver to make real file systems like ext4 available. So no need to be afraid to travel into unknown territory and format them for ext4 or any other awesome fs like zfs for example

@privilegejunkie what specific model? My guess is that the answer is no, though. That's a relatively old article and the WD utility mentioned there only applies to old Red drives that are 4TB and below. For WD drives that support IDLE3, you can try to use idle3ctl (apt install idle3-tools) to manage their idle setting. I've turned idle3 off on all my drives because they're usually idle for, at most 5 minutes leading to constant sleep/wake.

RK3399 commercial grade is rated as 0 - 80C ambient operating temperature. To not be confused with max Temperature junction (Tj) which is 125C ;-)

RK3399 commercial grade is rated as 0 - 80C ambient operating temperature. To not be confused with max Temperature junction (Tj) which is 125C ;-)

RK3399 commercial grade is rated as 0 - 80C ambient operating temperature. To not be confused with max Temperature junction (Tj) which is 125C ;-)

Looking into the fancontrol configuration, I think we were way too conservative on the settings making the fan going too early in higher RPM.
Plus we are not taking into consideration that the heatsink is already doing a pretty good job in passive mode.
 
I would recommend the following fancontrol settings until we provide a way to control the fan based on HDD temp instead :
 
# Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=40  

Looking into the fancontrol configuration, I think we were way too conservative on the settings making the fan going too early in higher RPM.
Plus we are not taking into consideration that the heatsink is already doing a pretty good job in passive mode.
 
I would recommend the following fancontrol settings until we provide a way to control the fan based on HDD temp instead :
 
# Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=40  

@Jaques-Ludwig As explains by @SIGSEGV you still need to store the bootloader somewhere else than USB because the system cannot boot directly from USB. So in our wiki we present the following approach : Bootloader on eMMC, Root file System on USB.
 
Very soon we will also explain how to store bootloader SPI, but honestly not really major added value than the above approach.
 
 
Technically you need to use jumper P10 to disable eMMC to be sure the system won't boot from it.
However take note the 1st stage bootloader (aka SPL) will always try to first find 2nd stage bootloader (aka U-boot) on microSD first, then eMMC. So it means that even if system boot from eMMC, if there is a microSD card inserted with a 2nd stage bootloader (aka U-Boot), the system will boot the system from microSD card... therefore you don't really need to bother about P10 jumper. Hope I'm not confusing more by trying to explain more :-/

@Jaques-Ludwig As explains by @SIGSEGV you still need to store the bootloader somewhere else than USB because the system cannot boot directly from USB. So in our wiki we present the following approach : Bootloader on eMMC, Root file System on USB.
 
Very soon we will also explain how to store bootloader SPI, but honestly not really major added value than the above approach.
 
 
Technically you need to use jumper P10 to disable eMMC to be sure the system won't boot from it.
However take note the 1st stage bootloader (aka SPL) will always try to first find 2nd stage bootloader (aka U-boot) on microSD first, then eMMC. So it means that even if system boot from eMMC, if there is a microSD card inserted with a 2nd stage bootloader (aka U-Boot), the system will boot the system from microSD card... therefore you don't really need to bother about P10 jumper. Hope I'm not confusing more by trying to explain more :-/

For now there is no solution between this 2 combination of limitation. But clearly our focus is to make 2.5GbE performance as good as on LK4.4 on LK5.8 (soon LK5.9).

For anyone looking to build an iSCSI target on their new Helios64, I can confirm that it's working correctly under the test builds for Armbian 20.11.
Thanks to @aprayoga for his comment on the pull request, the kernels modules related to LinuxIO have been added to all boards in the Armbian project.
 

This blog post / issue report only applies to Helios64, not Helios4.
 
 
Maybe corruption as you point out, or BTRFS bug on latest kernel... hard to say.
You can revert to previous kernel using armbian-config > System > Other

Yes, you can boot off USB.
You need to either have a U-Boot image on the SD card or on the eMMC.
From there, if the system partition is not found on the SD Card or the eMMC, it will try to look for it on the USB drives that are connected.
 
My system is booting from a USB drive at the moment - the U-Boot is installed on the eMMC (I erased the partition table afterwards, but the bootloader is still there).
If you zero out the eMMC, you loose the bootloader and you need to boot from an SD card. I belive that once we can install the bootloader to the SPI chip you would be able to boot directly from the USB.
 
As @TRS-80 mentioned on the post above - the tool to use for moving your current system from the SD Card to either a USB or eMMC is "nad-sata-isntall".
Today, there was a new post on the wiki page for the Helios64 about the process.
 

Thanks to the Armbian team, we have now this forum club dedicated to Kobol products.
 
Feel free to create new topics to report issues, discuss features or share experience with Helios64.

We just added 2 new pages on our wiki :
 
Transfer Installed OS - How to transfer your OS install from microSD card to eMMC, USB or HDD/SSD.
Troubleshooting - Basic troubleshooting guide when starting with Helios64.

We just added 2 new pages on our wiki :
 
Transfer Installed OS - How to transfer your OS install from microSD card to eMMC, USB or HDD/SSD.
Troubleshooting - Basic troubleshooting guide when starting with Helios64.

Thanks to the Armbian team, we have now this forum club dedicated to Kobol products.
 
Feel free to create new topics to report issues, discuss features or share experience with Helios64.

To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
Check it out:
 

Yes you can upgrade. The issue of instability wasn't related to the kernel actually but to some silly bug in Armbian hardware optimization script.

@TDCroPower Here the small hardware tweak ;-)
 
WARNING Please understand we are not responsible for any damage you might do to the board !
 

 

The boot.scr script is damaged. You can try to recreate it. Boot from sd once again, mount the emmc filesystem and recreate
 
mkdir /tmp/mmc mount /dev/mmc/mmcblk1p1 /tmp/mmc chroot /tmp/mmc mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr  
 

When I received my Helios64 - the case was out of whack -- the alignment was off by about 1/4 inch (3-5mm or so)....
since it was out of whack -- I gave it one - with a rubber mallet - worked perfectly - 
a gentle but sharp tap - once on both sides (I'll go through my phone later today to see if I took pictures)
 
Rich

@TDCroPower Here the small hardware tweak ;-)
 
WARNING Please understand we are not responsible for any damage you might do to the board !
 

 

@TDCroPower Here the small hardware tweak ;-)
 
WARNING Please understand we are not responsible for any damage you might do to the board !
 

 

@TDCroPower Here the small hardware tweak ;-)
 
WARNING Please understand we are not responsible for any damage you might do to the board !