gprovost

Hahahah best one I have read so far about the LED brightness. Yeah be sure it something we will solve in next batch.

We are coming up soon with a change that will finally improve DVFS stability.

Ok here the dirty way to update it in your specific case where eMMC is at /dev/mmcblk1
 
 
We will work on nand-sata-install to support the use case of rootfs on HDD/SSD and bootloader on eMMC.

I assume the original thinking of the authors of fancontrol was, that when the programm crashes/unexpectedly get closed, it does not leave the fans at a low speed and possibly endanger the system. 
The fancontrol does not differentiate between shutdown and exit / kill.
 
And from a system perspective it is much better to have annoying loud fans (but a cool and healthy system) than slowly burning away components while no sound is heard
 
I guess that also answers your second question, if you comment those lines away, the fans wont auto speed up if fancontrol crashes or similar.

We are coming up soon with a change that will finally improve DVFS stability.

We are coming up soon with a change that will finally improve DVFS stability.

Native ZFS encryption speed is not optimal on ARM and is limited by CPU speed on the Helios64. The optimizations that have gone in are limited to amd64 based architectures and require CPU features not available on ARM. Another consideration is that because of the lack of CPU features, the CPU will be heavily loaded during encrypted reads and writes meaning there are less resources available for other tasks. The problem isn't AES though, which is fully supported by the RK3309, it's GCM. This means that you can do full disk encryption via LUKS and run ZFS without encryption on top -- this is what I do. It's the best we can have at the moment and for the foreseeable future, nobody to my knowledge is working on ARM encryption optimizations for ZFS currently.
 
Edit: This may be of interest: https://github.com/openzfs/zfs/issues/10347

The problem of this post is solved !!
Your fans with an efficient thermal pad and SSD drives are 18w and 10db peak.
I very rarely exceed 12w in a day and the unit is completely inaudible.
Except for doing these tests which do not reflect the reality of normal use at all.

@qrthi it seems something wrong during writing to eMMC.
Your log show these lines
Wrong image format for "source" command SCRIPT FAILED: continuing... How did you write the image? We recommend to use Etcher because it has write verification.
 
 
The boot mode jumper only needed if for some reason the bootloader corrupted and to fix it you need to completely bypass the boot device.
If the bootloader (u-boot) just fine, it will load Armbian from the sdcard first.
The "Card did not respond to voltage select" is because you removed the sdcard.
If you put Armbian sdcard, the lines would be
Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 6 ms (517.6 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1  
My suggestion,
1. Download latest Armbian image.
2. Since you already have u-boot on your eMMC, no need to download and write the helios64_sdcard_u-boot-only.img.xz into sdcard.
3. Power on and enter UMS recovery mode
4. Write the image using Etcher. No need to extract the image. Etcher can handle it just fine.
5. Reboot Helios64.
 
 

This has been fixed via a patch to mvebu-current (LK5.10) so should be available via nightly or with the next armbian release : https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/0001-Revert-block-simplify-set_init_blocksize-to-regain-l.patch

It is fixed in LK 5.11 in mainline, but unsure if Armbian will get LK5.11 on mvebu or if we wait until the next LTS kernel version.

I just recently upgraded my Helios4 to Armbian 20.11.6 with kernel 5.9.14-mvebu. I encountered some minor hiccups, which turn out to be either a kernel or binutils bug, but the binutils developers fixed this in the 2.35 release which you can install from testing (see https://github.com/openzfs/zfs/issues/11444 for the details).
 
I haven't tested this on a 5.10-kernel, nor have I made the switch to ZFS 2.0 yet. But according to @Igor this seems to work also just fine. @SvenHz, if you get this working on your Helios4, I would appreciate if you could report this here, just to keep track of any issues (or the absence thereof).

@Mangix probably not, if he hasn't used it for a few months.
 
 
@pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. 
For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one.
 
For LED meaning: https://wiki.kobol.io/helios4/hardware/
For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/

Yeah I know. I removed them. Simply posting for more info.

We have no knowledge of OMV internals. - Armbian works, otherwise you would not be able to install that software and ZFS on Armbian as well. 
 
I would say you should ask this on OMV forums.
 
Here you need to provide at least:
 

This and the regular logs:
 
armbianmonitor -u  

RK3399 has a single PCIe 2.1 x 4 lanes port, you can't split the lanes for multi interfaces unless you use a PCIe switch which is an additional component that would increase a lot the board cost.
 
That's clearly the intention, we don't want either to restart form scratch the software and documentation :P
 
Yes this will be fixed, it was a silly design mistake. We will also make the back panel bracket holder with rounder edges to avoid user to scratch their hands :/
 
We will post soon how to manage fan speed based on HDD temperature (using hddtemp tool), that would make more sense than current approach.
You can already find an old example : https://unix.stackexchange.com/questions/499409/adjust-fan-speed-via-fancontrol-according-to-hard-disk-temperature-hddtemp
 

This is a quirk for UAS device applied to all Armbian release, it is not specific to Helios64.
https://github.com/armbian/build/blob/2b1306443d973033c6f2cef7b221f5c25f0af98d/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L379

I shared the design of the thermal pad, showing that the whole area below heatsink is cover with thermal pad by default.
 

 
@allen--smithee That's very valuable feedback, I think we will need to review our approach on thermal pad.
One factor we had to take in consideration is also ease of installation on the factory line.

@ShadowDance @alban I guess it was a shot in the dark to check if NCQ has any sort of impact.

I have been following the discussion for a while and would like to report where i am at. Also I would like to request that this information is being recorded in a systematic way by Kobol, of course only if this isn't already happening. 
 
I have the following setup:
pool: mypool state: ONLINE scan: resilvered 12K in 00:00:00 with 0 errors on Tue Feb 9 17:22:03 2021 config: NAME STATE READ WRITE CKSUM mypool ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ata-WDC_WD40EFRX-68N32N0_WD-WCC7XXXXXXXX ONLINE 0 0 0 ata-WDC_WD40EFRX-68N32N0_WD-WCC7XXXXXXXX ONLINE 0 0 0 ata-WDC_WD40EFRX-68N32N0_WD-WCC7XXXXXXXX ONLINE 0 0 0 ata-WDC_WD40EFRX-68N32N0_WD-WCC7XXXXXXXX ONLINE 0 0 0 ata-WDC_WD40EFRX-68N32N0_WD-WCC7XXXXXXXX ONLINE 0 0 0  
Some weeks ago I noticed that the health of the zpool is DEGRADED. I checked and one device had READ errors and was marked as FAULTED. This has also resulted in storing UDMA CRC errors in the SMART stats for this drive. So, I cleared the errors and ran a scrub to see what is going on.
 
sudo zpool scrub mypool  
 
I monitored the scrub with
sudo watch zpool status  
And I saw quite quickly that all drives have started to get READ errors. SMART also reported that all drives now have UDMA CRC errors.
 
It was clear that something bad is going on, so I contacted Kobol and the we started to debug the issue together.
 
First I changed the SATA speed to 3Gbps by adding the following line to /boot/armbianEnv.txt
extraargs=libata.force=3.0
 
The results were similar, but I noticed that the errors started to show up a bit later in the scrubbing process. The UDMA CRC Errors count has increased.
 
Then I replaced the power and the SATA Cables with new ones, which unfortunately did not bring any improvement.
 
Then I disabled NCQ by adding the following to /boot/armbianEnv.txt
extraargs=libata.force=noncq  
and reverted back to SATA 6 Gbps by removing the 3 Gbps line, introduced earlier.
 
This had a positive results and I was able to run the scrub without any errors.
 
Then I went back and installed the old(original) cable harness again and retested - all good.
 
While disable NCQ is having a positive impact on the errors, it is also having a negative impact on the speed and to some amount also on the disk drives' health. 
 
I have also tried to reduce NCQs depth to 31, which is the recommended value, however this did not have any impact. 
 
I hope that using this information Kobol will try to reproduce this issue themselves, to see if its only certain boards that are affected or if its every board. 
 
 
 
 
 

@gprovost
my Cpu + 2disks fan will always have a PWMMIN=35
my intention is to decrease PWMMAX and to delay the intervention of active ventilation.
 
Before, solicited the cpu made the fans roar, this is no longer the case today.
I can perform tasks with the first 5 minutes of a 100% CPU and the unit remains silent and afterwards I don't need a big air flow to stay cold.
 
cat / dev / thermal-board / temp1_input indicates:
 10 ° less than the CPU during stress.
 1 ° less than the CPU at rest.
I have to perform a long test to confirm but I think I can maintain Tcpu100% < 70° (Tboard < 60°) with only PWMMAX = 50 on fan-p6. 
 
There are certainly some points to improve concerning the thickness, in my unit, I used a thickness of 1.5 mm for the whole surface.
I realized that the inductors were high points on the PCB.
My intention was to remove the thermal pad on top so that it would be in direct contact with the radiator.
It would be relevant to try with 2mm in order to also cover the inductors from the top. 
 
It is planned to dismantle it in a week to see the contact points and check the height in the gel.
unfortunately the gel has already sagged, I can't modify the height of the radiator with the elements unless I do a modeling pad workshop,
but I can crush a very thin layer of pad at the top of inductor to avoid an air cushion. 
If necessary I have a second Gelid Pad 90x50x1.5 but I would like to keep it for the next one 
 
the 3W solution does the job, it's not the most efficient (not to say an insulator) but it's an economical solution,
and intended for most people who use traditional Hard Disk Drives that require active ventilation to improve the life span.
My use is particular, after all my unit screws into a living room and uses SDD that heats up little.
But it's a point to be improved indeed and if you charge an extra 10$ for a 6W pad you can be sure that I'll take it off to put a better and I'll tell you that your solution was crap.

@allen--smithee Actually what you are doing is not ideal since now the inductors (little squary components that appears through your thermal pad) are not able anymore to dissipate heat via the heatsink. These inductors generate quite a lot of heat and it will spread to LPDDR4 and PMIC trough PCB. The purpose of the Helios64 heatsink is obviously not to just dissipate heat for the SoC but for all other key components (LPDDR4, SATA controller, USB-to-LAN, etc...).
 
Here your measurement is only from the SoC point of view, which is not necessary the best way at looking at overall thermal management. Could you add back some thermal pad on the inductors and re-run your thermal measurement. It would be interesting to see if you see the same thing afterwards.
 
In any case we will change thermal pad supplier, we are not really happy by the current one.
 

@freed00m
Could you disable NCQ and see how if you manage to complete the SMART extended test.
 
Edit /boot/armbianEnv.txt and add the following line :
 
extraargs=libata.force=noncq  
 

Quick update here, I was running some benchmarks today.  Off the top of my head:
 
1. local SSD was getting something like 1200 MB/s write and 1500 MB/s read
2. USB connected HDD was getting ~175 MB/s write and 175 MB/s read
3. NAS (not helios) connected at 1 Gbps was getting ~100 MB/s read/write
4. Helios in DAS mode and on Raid 10 was getting approximately 170 write and 250 read.
5. Helios in DAS mode on a single drive was getting 190 write and 220 read. 
 
For the capture 1 use case, I think a solid contender.  Unfortunately, as I described in the other thread, I can't get my whole array presented in DAS mode (it wants to give me 200GB for a 18TB array).
 
 
Updated: also ran on a single drive instead of the array.  Slightly better write numbers with slightly worse read numbers.  Also, frustratingly, drive capacity was off -- this time showing 1.2 TB instead of 10.

Just wanted to report that the CPU frequency mod has been running stable under normal use for 15 days now (on 1Gbe connection). Haven't tried the voltage mod.
 
I'll switch to the February 4th Buster 5.10 build soon.
 
 
edit: 23 days, and I shut it down for sd card backup and system update. cpu freq mod is rock solid.

Around 3W/m-K. Dimension and thickness below , the small 21x21x1mm square is the one above the RK3399 SoC :
 

 
 
Let's clarify, you can use Helios64 board in passive cooling mode on its own, but if the board is installed in the provided enclosure along HDDs device then you definitely need active cooling.