hartraft

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

Hi jotapesse, yes same for me ... but on closer inspection ... the flashing of the LAN activity light no longer seems
to be tied to real network activity!
 
1/ It flashes a lot less than it used to do.
2/ If I download a large movie file from the Helios64 to my PC I occasionally see a brief flash, but not the sustained activity that
I'd expect from a download that takes several minutes.
3/ Inspecting my network router, I can see constant low level activity on the Helios64 ip address (I only have one ethernet cable attached to the Helios64)
but don't see any flashing LED.
 
So in conclusion ... its still not working properly!  

Hi everyone! Just to let you all know that I have updated today my Helios64 to Armbian 21.08.3 Bullseye and the "LAN" front panel led now works again. :-) Great!

New version 20211007-edge with 5.14.9 core. All equipment works, including analog sound and remote control.
 
@JMCC
I checked the operation of your KODI-18 packages on this kernel, KODI starts, but there is still an error and the video does not play, maybe I forgot some kernel options or a patch. I plan to check it again in the near future.

bisected eMMC breakage:
06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 is the first bad commit
 
commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu May 20 01:12:23 2021 +0300 regulator: core: resolve supply for boot-on/always-on regulators commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream. For the boot-on/always-on regulators the set_machine_constrainst() is called before resolving rdev->supply. Thus the code would try to enable rdev before enabling supplying regulator. Enforce resolving supply regulator before enabling rdev. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> drivers/regulator/core.c | 6 ++++++ 1 file changed, 6 insertions(+)  
is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/regulator/core.c?id=98e48cd9283dbac0e1445ee780889f10b3d1db6a
from thread https://lore.kernel.org/all/20210519221224.2868496-1-dmitry.baryshkov@linaro.org/
 
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 7b3de8b0b1ca..043b5f63b94a 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1422,6 +1422,12 @@ static int set_machine_constraints(struct regulator_dev *rdev) * and we have control then make sure it is enabled. */ if (rdev->constraints->always_on || rdev->constraints->boot_on) { + /* If we want to enable this regulator, make sure that we know + * the supplying regulator. + */ + if (rdev->supply_name && !rdev->supply) + return -EPROBE_DEFER; + if (rdev->supply) { ret = regulator_enable(rdev->supply); if (ret < 0) {  
EDIT 1: this change to return EPROBE_DEFER if regulator has a supply name but no supply ready was intended to complete commit aea6cb99703e17019e025aa71643b4d3e0a24413 which  expects set_machine_constraints to return this eprobe_defer error to attempt to resolve the supply ( before attempting a second run of set_machine_constraints).
 
One still need to find out if aea6cb99703e17019e025aa71643b4d3e0a24413 fails to resolve the supply and thus does not make a second attempt to set_machine_constraints thus leaves the regulator disabled or else.
 
 
commit aea6cb99703e17019e025aa71643b4d3e0a24413 Author: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Date: Sat Sep 26 23:32:41 2020 +0200 regulator: resolve supply after creating regulator When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ff8e99ca0306..9f704a6c4802 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5280,15 +5280,20 @@ regulator_register(const struct regulator_desc *regulator_desc, else if (regulator_desc->supply_name) rdev->supply_name = regulator_desc->supply_name; - /* - * Attempt to resolve the regulator supply, if specified, - * but don't return an error if we fail because we will try - * to resolve it again later as more regulators are added. - */ - if (regulator_resolve_supply(rdev)) - rdev_dbg(rdev, "unable to resolve supply\n"); - ret = set_machine_constraints(rdev, constraints); + if (ret == -EPROBE_DEFER) { + /* Regulator might be in bypass mode and so needs its supply + * to set the constraints */ + /* FIXME: this currently triggers a chicken-and-egg problem + * when creating -SUPPLY symlink in sysfs to a regulator + * that is just being created */ + ret = regulator_resolve_supply(rdev); + if (!ret) + ret = set_machine_constraints(rdev, constraints); + else + rdev_dbg(rdev, "unable to resolve supply early: %pe\n", + ERR_PTR(ret)); + } if (ret < 0) goto wash;  
 
 
My logs for bad shows:
[ 1.257297] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 1.257446] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 1.257588] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 1.257728] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 1.258114] reg-fixed-voltage pcie-power: Failed to register regulator: -517 [ 1.258312] reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517 [ 1.258451] reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517 [ 1.258705] reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517 [ 1.261721] reg-fixed-voltage usblan-power: Failed to register regulator: -517 [ 2.158719] vdd_log: supplied by regulator-dummy [ 2.230749] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.230781] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.230792] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.240854] rk808 0-001b: failed to register 12 regulator [ 2.249848] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.253127] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! [ 2.423549] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517 [ 2.424263] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517 [ 2.424830] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517 [ 2.425443] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517 [ 2.556287] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.556318] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.556328] rk808-regulator rk808-regulator: max buck steps per change: 4  
while for good:
[ 2.172993] vdd_log: supplied by regulator-dummy [ 2.330040] rk808-regulator rk808-regulator: there is no dvs0 gpio [ 2.330071] rk808-regulator rk808-regulator: there is no dvs1 gpio [ 2.330081] rk808-regulator rk808-regulator: max buck steps per change: 4 [ 2.347345] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 2.350525] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!

I have slightly different approach to going's solution, but this would be compatible with it