hartraft

I landed the restoration of the eMMC hs400 support and the fix for the helios64-heartbeat-led.service that I had broken in a previous commit.
The upped voltages are not in.
Though these upped voltage seems to help a lot of people, they are not the endgame. Ie I tried setting all the CPU b voltages to max 1.2, and I believe I can still crash the CPUs b with my test case...
 
Also, I am onboarding on another board maintenance. Fixed an issue with a PL2303 USB serial adapter that it did not support 1.5Mbps but only 1.2Mbps....
 
In the meantime, I nailed down an issue on edge 6.14 that might also affect other version but not tested yet. I fixed it locally by setting the startup time for  HDD rail a and rail b to have them not start at the same time by the kernel. Ie the upstream Linux kernel have the HDD rails defined, and it seems it restarts them when the kernel load thus draining too many amps on my board and I repeatedly had:

 
Internal error: synchronous external abort: 0000000096000210 [#1] PREEMPT SMP (...) [ 3.890774] Call trace: [ 3.891012] rockchip_pcie_rd_conf+0xf4/0x1e8 (P) [ 3.891461] pci_bus_read_config_dword+0x7c/0xdc [ 3.891906] pci_bus_generic_read_dev_vendor_id+0x34/0x1b4 [ 3.892428] pci_scan_single_device+0xa0/0x108 [ 3.892857] pci_scan_slot+0x68/0x1c4 [ 3.893216] pci_scan_child_bus_extend+0x44/0x2cc [ 3.893668] pci_scan_bridge_extend+0x320/0x60c [ 3.894104] pci_scan_child_bus_extend+0x1b8/0x2cc [ 3.894564] pci_scan_root_bus_bridge+0x64/0xe4 [ 3.895000] pci_host_probe+0x30/0x108 [ 3.895367] rockchip_pcie_probe+0x43c/0x5e4 [ 3.895777] platform_probe+0x68/0xdc  
I cannot reproduce this PCIe failure after adding the 10 seconds delay that Kobol devs put in the u-boot between rail a and rail b startup. Though, 10 seconds seems a lot, but I have no clue why the Kobol team chose such a huge value.
 

Hello @prahal
with your voltage fix I have an uptime of 158 days.
Without, maybe 3-4 days if it boots at all.
Your other fixes are also great. But they don't have the same impact by far. Even if the voltage is not a 100% fix in your eyes, for most people it is a game changer and enables operation in the first place, so I am surprised that you see so little priority there.
Please don't get me wrong, I'm very grateful for the fix, I just think it should be implemented first, as I think stable operation is more important than how an LED flashes
 

Hi, 
I agree with Snakekick, the voltage patch is for me the best thing for the helios64 run stable. 
Maybe it's not a perfect solution but:
"It is better to have a good solution in time than a perfect one too late."

It's really nice to see all these recent community efforts to revive and keep the Helios64 alive and useful.
However, the relevant info seems to be a bit all over the place.
 
For instance, with the device tree files (dtb files). Which one is the "latest" one? How do you know which one to use for your current kernel? Where should you download it? (as an attachment to a user post on this forum?) Are they going to be merged as part of regular Armbian?
These questions are not that hard to answer if you read through the topics and have some technical knowledge, but that's sort of the problem!
 
Essentially, it would be great to start making things a bit more organised so people don't have to piece the information together from various forum posts

root@helios64:/etc/systemd/system# uname -a Linux helios64 6.12.11-current-rockchip64 #1 SMP PREEMPT Thu Jan 23 16:23:05 UTC 2025 aarch64 GNU/Linux root@helios64:/etc/systemd/system# zfs version zfs-2.2.7-1~bpo12+1 zfs-kmod-2.2.7-1~bpo12+1
Check it out, its zfs on the latest kernel on helios64!
 
I upgraded from the original buster back from 2021, it was running for years and had uptime more than 850 days.
 
root@helios64:/etc/apt# cat sources.list deb http://deb.debian.org/debian/ bookworm main contrib deb-src http://deb.debian.org/debian/ bookworm main contrib deb http://security.debian.org/debian-security bookworm-security main deb-src http://security.debian.org/debian-security bookworm-security main deb http://deb.debian.org/debian/ bookworm-updates main deb-src http://deb.debian.org/debian/ bookworm-updates main deb http://deb.debian.org/debian bookworm-backports main contrib deb-src http://deb.debian.org/debian bookworm-backports main contrib  
The important part is the last bookworm-backports main contrib, thats where the zfs in right version comes from, also cat preferences.d/90_zfs  
Package: src:zfs-linux
Pin: release n=bookworm-backports
Pin-Priority: 990

I have the dtb from a dropbox link in here from Croatian-flag guy, and ondemand governor from 480 to 1.2ghz.
 
Pretty stable so far, just have to set correct fan settings and drive standby time.
 
Check your smartctl -a for drive-power-on cycles or spin-down-spin-up cycles, the stupid smartmontools smartd was causing the drives to spin up just because it was checking their values. My drives are now on 82k cycles, sigh.
 
What power usage do you get from wall-meter, mine is on 11watt when all drives are powered down with hdparm -Y
 

I just found a very interesting talk by Sebastian Reichel who works with hardware enablement of the RK3588 at Collabora in this video between 06:52:09 to 07:27:07 which I can recommend for those interested in the Collabora project for Rockchip.  Now also available here https://kernel-recipes.org/en/2023/schedule/getting-the-rk3588-soc-supported-upstream/ 
 

Okay, so I finally did it this Friday. I did the expose eMMC steps - https://wiki.kobol.io/helios64/install/emmc/
 
(Somebody will probably have to mirror that link and the eMMC SD-Card exposure image if those instructions and files ever come Offline for good.)
 
I'm also going to report that it all works just fine. I connected it with Picocom afterwards over USB-C with `picocom -b 1500000 /dev/ttyUSB0`, boots up fine, got a login prompt, did the Armbian initial setup stuff like setting up root password, a user password, which was different from last time I think, and then shell, etc...
 
Now I'm in the long-haul process of meticulously restoring my config backups one by one from my old install, got SSH quickly set up again so I could disconnect the serial cable, double-checking them to make sure my static mounts will still work, my personal user scripts still run, and everything else still works without too many errors. I'm going to install more packages, set up Systemd's networking stack (networkd/resolved) the way I want, the Btrfs array, then NFS, and finally, maybe I'll even try to set up extras that I can't remember right now, like maybe disabling the ZRAM if it becomes a problem. Because usually the 4 GB of regular RAM is enough.
 
So far, yes, everything is working great. I'll report back with any problems I run into.

@mrjpaxton Dist-upgrade(ing) from bullseye to bookworm did finally complete successfully. However, one should consider that device names have changed (otherwise your system may end up offline 🙂) the new interface names are:
 
# interface names (bookworm) sd: /dev/mmcblk0 emmc: /dev/mmcblk1 eth0: end0 (1GBase-T ethernet) eth1: end1 (2.5GBase-T ethernet)  
P.S.: I am currently setting up bookworm from scratch starting from the fresh image to get rid of the stuff that accumulated during the last years.

I finally have openZFS loading as a module with modprobe (still need to test that it's actually working correctly, but so far so good...)
I'm using the Armbian Lunar CI rolling release since there is a working Linux-Header for this kernel
https://imola.armbian.com/beta/pool/main/l/linux-headers-midstream-rockchip-rk3588/  
After that, I essentially followed the instructions for building openZFS, but some minor changes to the META file for license and max kernel version.
 
I want to say thank you to all the Armbian team members for making such an amazing platform for SBCs. All my boards run Armbian.
 
here was the config command I used
git clone https://github.com/openzfs/zfs cd ./zfs sh autogen.sh ./configure --with-config=user make -s -j$(nproc) sudo make install sudo ldconfig sudo depmod sudo modprobe zfs

With working PCI
https://github.com/armbian/os/releases (look for Rock5 "midstream")
 

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

Thanks.
 
Now we may consider switching all boards to MGLRU on 6.1 😀

Thanks a lot, ended up that yesterday I tested kernel v5.18.0 on rk322x with the old version of the extra patch compiling the whole debian mesa packages ecosystem with success. The box was sporting just 1gb of ram, 512mb of zram swap space and 2gb of extra USB HDD swap file.
The conditions were absolutely heavy and unhealthy, but the whole packages rebuilding from sources finally completed without errors, even after extreme swapping and hours of compilation time. The system was always responsive to SSH shells, which is a great achievement by itself!
 
 

@hartraft - there are two kernel options for mglru: CONFIG_LRU_GEN=y and CONFIG_LRU_GEN_ENABLED=y - the first is to have mglru built into the kernel and the second is to have it enabled by default - if they are not in your kernel config it might be required to rebuild the kernel with them (or at least the first) enabled

@hartraft Currently, I can assure you that the tinkerboard with armbian edge kernel (6.1) receives MGLRU compiled and enabled by default because I maintain the rk3288 (rockchip 32 bit) family.
The other two boards are not under my maintenance so I can't say anything about, but you could check in the config sample file in your /boot directory to see if a kernel is compiled with the options pointed by @hexdump

Finally! On my personal testing on 5.19.x never had any issue with both armhf and arm64 architectures

@ebin-dev @piter75
I believe the upstream fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=8a866d527ac0441c0eb14a991fa11358b476b11d will do the job (in 6.1-rc1 so to be expected in Armbian edge if you want to try EMMC anew when it lands). This is likely the same issue as before the bad commit I pointed at the code only called set_machine_constraints once.  Still, requires testing (I saw that a lot of rk339 boards removed hs400 in Armbian, maybe that will fix them all).
 
regulator: core: Resolve supply name earlier to prevent double-init Previously, an unresolved regulator supply reference upon calling regulator_register on an always-on or boot-on regulator caused set_machine_constraints to be called twice. This in turn may initialize the regulator twice, leading to voltage glitches that are timing-dependent. A simple, unrelated configuration change may be enough to hide this problem, only to be surfaced by chance. One such example is the SD-Card voltage regulator in a NanoPI R4S that would not initialize reliably unless the registration flow was just complex enough to allow the regulator to properly reset between calls. Fix this by re-arranging regulator_register, trying resolve the regulator's supply early enough that set_machine_constraints does not need to be called twice. Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com> Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com Signed-off-by: Mark Brown <broonie@kernel.org>  
Note that this fix reintroduce the less critical bug that was fixed by the bad commit I pinpointed namely sysfs entries issues; This was also fixed in 6.1-rc1 by commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=520fb178212d1dd545ed0ed231df09111b30ab7e "regulator: core: Fix regulator supply registration with sysfs"

I do love the XU4, but it only sports 2GB of RAM.

I am working with: Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux
I have snapraid configered via the OMV interface but MergerFS and LUKs manually because the plugins were not present at the time but I am not sure if this really does any difference. Beyond that I am using some Dockers like Airsonic, Jellyfin, Nextcloud.
And the ondemand governor is now between 400-1800MHz and runs all the tasks (Snapraid + rsync + smart on a weekly basis) smoothly. My current uptime now is 21 days.

Mind if I ask which kernel are you using? and did you experience any problems adding any addon's? I had no problems with a fresh install of Bullseye on my Helios4 but had issues when I tried adding snapraid and mergerfs on my Helios64 with the stock Bullseye Kernel.
 
Also Experiencing a freeze/issue When installing OMV through armbian-config where it freezes at the end while processing triggers for man-db

Since 4 weeks now I am runnign the helios64 together with OpenMediavault 6 with the full CPU capacity and ondemand governor.
Before I had always problems when doing an scheduled task but with OMV6 the problem seems to be solved. I am quite pleased now with the performance and a rocksolid NAS.
 

UPDATE:
Even changing the cables, the disks keep failing over time. I wasn't able to have my NAS running more than a day or two without a failure on the disks. After buying an APC UPS with Boost and Trim Automatic Voltage Regulation (AVR), my NAS is now running without any failure over more than a week!
So the problem was the unstable energy in my house. Maybe I'll try to put back the original ones to see if it works.

Go ahead, OMV6 works fairly well with the Helios64... there are some bits and pieces that are not completely ported (plugins for example) and some need a bit of adjustment whatsoever. But all in all it is okay.
 
I am running OMV6 together with SnapRaid. MergerFS and Luks I am running outside of OMV as I do find it easier to customize for my needs.

I have been trying for a while now the edge kernels and I have found that after the HW-mod (above) the network bonding has started to work... not consistently but once setup, the next reboot will actually enable the full network bonding. Currently I'm running 5.15.4, had to rebuild ZFS but that was it.

Packages I've upgraded:
- linux-dtb-edge-rockchip64/focal 21.11.0-trunk.65 arm64
- linux-headers-edge-rockchip64/focal 21.11.0-trunk.65 arm64
- linux-image-edge-rockchip64/focal 21.11.0-trunk.65 arm64

- Package: zfs-dkms
  - Version: 2.1.1-0york0~20.04
  - Priority: optional
  - Section: kernel
  - Source: zfs-linux
 
$ cat /proc/net/bonding/nm-bond0 Ethernet Channel Bonding Driver: v5.15.4-rockchip64 Bonding Mode: transmit load balancing Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Peer Notification Delay (ms): 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 64:62:66:xx:xx:xx Slave queue ID: 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 64:62:66:xx:xx:xx Slave queue ID: 0  

Hi,
 
I thought this forum did support on the Helios{4,64} regardless of the OS since Kobol is now closed.
More, the issues I encounter testing the Armbian patches can be helpful for the future Armbian releases (I had the eMMC issues long time before many Armbian users were impacted with the Buster update).
I did tried to apply the Armbian patches for kernel 5.15, but they fail because Helios4 and 64 are now mainlined.
 
But not problem, I will try to fix it by myself, and report back the solution here. I have the skills to do it.
BTW I have the same issue with vanilla kernel 5.15 and Helios4. I will test it first on the helios4 because it's not used anymore.
 
Kind regards,
Xavier Miller