gprovost

Because there is no real driver for using the rockchips videoengine yet. It uses software transcoding which obviously needs lots of cpu power.

@dancgn if it crashes occasionally, you could try to use armbian-config to change the CPU speed / governor to 'performance' (armbian-config > System > CPU). I personally use 1800000 for CPU speed but I've seen 1200000 recommended elsewhere on the forum, YMMV.

You can monitor your ZFS speed by issuing "zpool iostat x" with x being the time between each report in seconds. You can put some crazy value there, like 0.001s.
There is one catch... I think the read/write values are the cumulative speed of each disk (with the parity), and not the true usable data R/W of the pool.


On my helios, I'm getting about 140MBps true reads and 80MBps true writes for a raidz2 on 4 very old and already dying hdd.
2x   https://www.newegg.com/hitachi-gst-ultrastar-a7k1000-hua721010kla330-1tb/p/N82E16822145164  
2x   https://www.newegg.com/seagate-barracuda-es-2-st31000340ns-1tb/p/N82E16822148278


WRITING TO from dd point of view:

 
The same write from iostat point of view




And wow, ZFS is learning fast... Files get cached on RAM. I get crazy reading speeds after successive reads on the same file:




I also tried to copy a large folder from an NTFS USB SSD to ZFS and the write speed reported by zpool iostat was about 140MBps. So yeah. This is not a definitive answer about write speed. But our measurements are on the same ballpark at least.
I believe the write speed could be optimized but only at the cost of general purpose usability. For my use cases it is enough speed and redundancy. I won't go into a speed race to find later that I trapped myself in a corner case.
 
Edit: it is looking like the caching is actually done by the kernel in this case (I have not configured any ZFS cache).

If someone want to do make an automated read/write test script, you can flush the kernel like described here:
 

Hi @snakekick,
USB HDD for snapraid parity, sounds like my setup! You can check with vm_block_dump what is waking up your device: 
 
echo 1 | sudo tee /proc/sys/vm/block_dump Above will enable logging of block device accesses into syslog.
 
If you want to see it happen without flooding your /var/log/syslog:
sudo service rsyslog stop while true ; do dmesg -cT ; done sudo service rsyslog start  
See: Documentation for /proc/sys/vm/* and How to conserve battery power using laptop-mode.
 
You should also check if you have enabled SMART offline auto testing on your HDD; that might also wake up your drive, but this is done by the drive itself:
sudo smartctl -a /dev/sdX | egrep 'offline' sudo smartctl --offlineauto=off /dev/sdX  
Other things that will wake up your drive: temperature monitoring services like hddtemp, you should check if it offers options to not access the drive if it's in standby/sleep mode.  Other things like blkid when used as root, will also check all blockdevices, even if you think it is using cache.
 
What is the brand of USB dock you are using? Perhaps your dock is doing something to the drive to wake it up regularly.
 
Hope that helps,
Groetjes,

yeah, but the feeling is less than 2 seconds. Can it because the flashing starts after the message (no lit, then lit)?
 
Meanwhile, I have my custom kernel and OS (Gentoo Linux), they run fine :-)

I’m helping my friend set up Helios64 with OpenMediaVault as a media server. We’d manage to set it up as per your documentation mentioned on your wiki page but are stuck on SD-Card to eMMC migration. As after migrating with no error so far we’re still unable to boot the system without the SD-Card in Helios64.

We still couldn’t figure out what could be the problem? Can you guys help?

@slymanjojo
If you don't need the transcoding - the minidlna package could be a good alternative, low resource usage and the performance mostly will depend on your network and the reproduction device.
Once HW transcoding makes it to the latest kernels, the other packages should behave much better - you're not the only one waiting for it.

Hi gprovost,
Yes I happened to find RTC in the doc yesterday!
 
I'm still using auto power on in case of power failure.
 
But, as you kindly suggest, I'm now using RTC - 2 tasks in OpenMediaVault5 job scheduling...
1/  sudo rtcwake -m disable                                                           (each reboot to reset any outstanding wake timers)
2/  sudo rtcwake -m off --date '+ 6 hour 15 minutes 0 seconds'    (each morning at 01:00 to shutdown and set wake timer for 07:15)
 
It worked fine this morning!  

Nice tuto :-)
 
This could be easily turned into a page for our wiki :  https://github.com/kobol-io/wiki ;-)

Sorry for the confusion, after installing everything again, everything is working well.

Thank you very much

Thanks!
I could not respond earlier because forum allows to make only one post in the first day.
It is embarrassing, I am actually quite certain that I tried to boot with SD card and without it several times, and the result was the same (no signs of life). And I even wrote the image to the card again and tried again. But when I tried to boot yet again with the same card the next day, after reading @SIGSEGV's answer, it booted! I can only suspect lousy contact on the card or something?..
@gprovost yes, of course I did. And believe that I explained clear enough at "which step".
Anyway all is well now, thank you for your help!

If you're seeing a few of those every now and then, nothing to be alarmed about. It can happen when the CPU is stressed and is normal. If you're constantly seeing it then you might want to consider either reducing the CPU load or disabling NOHZ.
 
For understanding what NOHZ does, I highly recommend this Stack Overflow answer to: "How NOHZ=ON affects do_timer() in Linux kernel?".
 
If you want to get rid of the message, you can simply add the following to /boot/armbianEnv.txt:
 
extraargs=nohz=off  
But if you decide to do this, make sure you fully understand what it does by reading the aforementioned SO article and perhaps https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt.

As we have mentioned on the wiki, you can watch the System LED as visual cue. When it blink once, release the button.
There are roughly 2 second delay to release the button.
https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64-mainline/general-support-recovery-button.patch#L131-L137
 
Another visual cue you can check is through serial console.
U-Boot 2020.07-armbian (Nov 23 2020 - 16:22:15 +0100) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC using mmc0 device for download mode rockchip_dnl_mode = ums mode as soon as you see rockchip_dnl_mode = ums mode, release the button.

Hi,
Not sure if I can help here, but willing to help.
Can you put the SDcard into another Linux system and list the contents of the /boot folder? Also, please share the contents of the /boot/armbianEnv.txt. Looks like the same thing I had once, after a downgrade of kernel, the DTB files were renamed or not present for unknown reasons.
Groetjes

Trying this and will report back, thank you.

Focal / root on eMMC / ZFS on hdd / LXD / Docker
 
I received my Helios64 yesterday, installed the system, and decided to write down my steps before I forget them. Maybe someone will be interested. :-)
 
Preparation:
Assembly your box as described here. Download Armbian Focal image from here and flash it to SD card. You may use Ether. Insert the SD card to your Helios64 and boot. After 15-20s the box should be accessible via ssh. (Of course you have to find out it's IP address somehow. For example check your router logs or use this.)  
First login:
ssh root@IP Password: 1234  
After prompt - change password and create your daily user. You should never login as root again. Just use sudo in the future. :-)
Note: The auto-generated user is member of "disk" group. I do not like it. You may remove it so: "gpasswd -d user disk".
 
Now move your system to eMMC:
apt update apt upgrade armbian-config # Go to: System -> Install -> Install to/update boot loader -> Install/Update the bootloader on SD/eMMC -> Boot from eMMC / system on eMMC  
You can choose root filesystem. I have chosen ext4. Possibly f2fs might be a better idea, but I have not tested it.
When finished - power off, eject the sd card, power on. 
Your system should now boot from eMMC.
 
If you want to change network configuration (for example set static IP) use this: "sudo nmtui".
You should also change the hostname:
sudo armbian-config # Go to: Personal -> Hostname  
 
ZFS on hard disk:
sudo armbian-config # Go to Software and install headers. sudo apt install zfs-dkms zfsutils-linux # Optional: sudo apt install zfs-auto-snapshot # reboot  
Prepare necessary partitions - for example using fdisk or gdisk.
Create your zfs pool. More or less this way:
sudo zpool create -o ashift=12 -m /mypool -mypool mirror /dev/disk/by-partuuid/abc123 /dev/disk/by-partuuid/xyz789  
Reboot and make sure the pool is imported automatically. (For example by typing "zpool status".)
You should now have working system with root on eMMC and ZFS pool on HDD.
 
Docker with ZFS:
Prepare the filesystem:
sudo zfs create -o mountpoint=/var/lib/docker mypool/docker-root sudo zfs create -o mountpoint=/var/lib/docker/volumes mypool/docker-volumes sudo chmod 700 /var/lib/docker/volumes # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/docker-root sudo zfs set com.sun:auto-snapshot=true mypool/docker-volumes  
Create /etc/docker/daemon.json with the following content:
{ "storage-driver": "zfs" }  
Add /etc/apt/sources.list.d/docker.list with the following content:
deb [arch=arm64] https://download.docker.com/linux/ubuntu focal stable # deb-src [arch=arm64] https://download.docker.com/linux/ubuntu focal stable  
Install Docker:
sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io #You might want this: sudo usermod -aG docker your-user  
 
Voila! Your Docker should be ready! Test it: "docker run hello-world".
 
Option: Install Portainer:
sudo zfs create rpool/docker-volumes/portainer_data # You might omit the above line if you do not want to have separate dataset for the docker volume (bad idea). docker volume create portainer_data docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce  
Go to http://yourip:9000 and configure.
 
 
LXD with ZFS:
 
sudo zfs create -o mountpoint=none mypool/lxd-pool sudo apt install lxd sudo lxc init # Configure ZFS this way: Do you want to configure a new storage pool (yes/no) [default=yes]? yes Name of the new storage pool [default=default]: Name of the storage backend to use (dir, btrfs, ceph, lvm, zfs) [default=zfs]: zfs Create a new ZFS pool (yes/no) [default=yes]? no Name of the existing ZFS pool or dataset: mypool/lxd-pool [...] #You might want this: sudo usermod -aG lxd your-user # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/lxd-pool sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/containers sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/custom sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/virtual-machines  
That's it. Lxd should work now on ZFS. :-)
 

Is there someone experienced in ZFS building around? We would like to include support directly to the kernel but troubles doesn't want to go away https://github.com/armbian/build/pull/2414

I got my box yesterday and assembled it (looks gorgeous, and reasonably easy to assemble).
Without external power and with battery connected, green led 1 is on. With external power, orange led 9 in addition to that.
FTDI chip is recognized regardless of power status, I can connect to the console.
After pressing power button, green LEDs 2 and 3 and blue LEDs 4 and 5 light up immediately, and after that nothing else happens. Nothing on the serial console, no LEDs change status.
Tried disconnecting the battery. Then without external power, all LEDs are dark (but FTDI chip is still visible), with external power orange LED 9 blinks, the rest is exactly the same: four more LEDs light up on pressing the power button, and no other signs of life.
 
Looks to me as if either u-boot is absent / corrupted / inaccessinle, or the SoC does not enter boot mode.
 
No jumpers connected. There is no CR1225 (the board arrived without it. But with the 18660 pack).
 
Any advise? (I would be comfortable to play with low level boot tools).

A small update if you're willing to use a legacy kernel:
 
I have not tested it yet...

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

It's really missing. How to restore it?
EDIT: Restored via "apt-get reinstall".

Since I had collected as much information from the broken AC adapter brick as possible, I decided to cut off the connector.  This revealed only 2 wires which meant there is only one possible configuration.  Both pins 1 and 2 must be 12V.
 
I grabbed one of my old computer power supplies, and fashioned a terminal connector to tie the 2 wires to the 12V rail and ground.  I verified the 4 pins on the connector, plugged it in and my Helios4 booted up without any issues.  I'm still waiting about a week and I'll swap out my 500W temporary PSU when it arrives.
 
For anyone with similar power issues, hopefully this thread may be helpful to them.
 
 
Here's the appropriate pinouts of the 4-pin AC adapter required for Helios 4 (see previous diagram for pin locations):
PIN 1: +12
PIN 2: +12
PIN 3: GND
PIN 4: GND

Thanks for the update. Good to hear that with fix cpu frequency system is stable.
 
Yeah the main source of instability is DVFS, we already did some change by tweaking regulator ramp delay : https://github.com/armbian/build/commit/d18323fcc358ddd5bd0836c4853cbc281b6293c6
 
It improved a lot stability but unfortunately doesn't seem to completely solved the problem for everyone. So we are still investigating and getting Rockchip to look at it also.

OK, relevant posts have been moved with the title that was suggested:
 
USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4
 
Thanks @usual user for help keeping the forums organized! 

Yes new packages with required driver are ready, you can just do the usual apt-get update && apt-get upgrade then reboot.