Search the Community

Hello everyone, I recently bought an used Helios64 NAS without AC Adapter. I found some adapters on AliExpress (for Italian country) but I don't know the PIN disposition (about the polarity, V+ V- etc.) Could someone of you share a photo of the original Kobol Helios64 AC Adapter with the polarity details? Thanks.

Actual booting from eMMC and system including OMV from Sata SSD. Running boot & system from eMMC should be possible now and I would like to transfer system from SSD to eMMC without losing my config and starting from scratch again. That way I'll have a sdd beside the hdd for OMV. How can I manually transfer the system including OMV from SSD to eMMC and what configuration files need to be altered?

In case someone is interested in a almost new Helios 64 "full bundle" with a lot of spare parts that did only run for about 3 months: https://www.ebay.de/itm/363567434154 Thanks, Paul

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here! So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot. System Info (prior to failure): - Helios64 board - Armbian with OMV - Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm - System was always booted from an SD card, not eMMC - Upgrade was done via `apt` commands, no manual flashing of U-Boot Current Symptoms: - After Bookworm upgrade, the system fails to boot. - Via USB-C serial connection (using `screen`), I get mostly garbled output like: �`���x�f������������f�������f��~�怘����怘� Or: ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg� - Occasionally, I saw more verbose output including: SetTTY (fd 5): ioctl failed: Invalid argument Sorry, could not find a PTY - No SSH access; connection refused (network stack never comes up). - The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls. What I've Tried: - Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble). - I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it. - Repeated all tests on my second, so-far unused Helios64 — same symptoms. - Changed power cables and tried both UPS and direct plugging to wall socket. - Verified serial setup with `screen /dev/tty.usbserial 1500000`. SD Card Behavior: - After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected. - On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot. Desired Outcome: - I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble. - I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system. Questions: 1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye? 2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)? 3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)? ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself. Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there. I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.

Servus! I'm running an "old" Helios64, still with debian buster and kernel 5.9.14-rockchip64 ... pretty much the same installation, as I had setup the Helios64 years ago. So far it is running great, with no real issues. I have ZFS running on it, with 3 disks. Today I decided to upgrade to something new - and installed Armbian 25.5.1 / Nobel - with kernel "6.12.32-current-rockchip64". Helios64 boots up and everything seems to work fine. I was able to import my ZFS pool and it was accessible - however, when I do heavy i/o, e.g. md5sum on a big file, I get a lot of these errors: Jun 08 20:06:36 helios64 kernel: ata2.00: failed command: READ FPDMA QUEUED Jun 08 20:06:36 helios64 kernel: ata2.00: cmd 60/80:90:40:3a:2f/00:00:06:00:00/40 tag 18 ncq dma 65536 in res 41/84:00:00:00:00/00:00:00:00:00/00 Emask 0x12 (ATA bus error) Jun 08 20:06:36 helios64 kernel: ata2.00: status: { DRDY ERR } Jun 08 20:06:36 helios64 kernel: ata2.00: error: { ICRC ABRT } Jun 08 20:06:36 helios64 kernel: ata2: hard resetting link Jun 08 20:06:36 helios64 kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Jun 08 20:06:36 helios64 kernel: ata2.00: configured for UDMA/133 Jun 08 20:06:36 helios64 kernel: ata2: EH complete Jun 08 20:07:04 helios64 kernel: ata2: limiting SATA link speed to 1.5 Gbps Jun 08 20:07:04 helios64 kernel: ata2.00: exception Emask 0x2 SAct 0x202003 SErr 0x400 action 0x6 Jun 08 20:07:04 helios64 kernel: ata2.00: irq_stat 0x08000000 Jun 08 20:07:04 helios64 kernel: ata2: SError: { Proto } Jun 08 20:07:04 helios64 kernel: ata2.00: failed command: READ FPDMA QUEUED Jun 08 20:07:04 helios64 kernel: ata2.00: cmd 60/00:00:98:55:7f/08:00:07:00:00/40 tag 0 ncq dma 1048576 in res 41/84:00:00:00:00/00:00:00:00:00/00 Emask 0x12 (ATA bus error) Jun 08 20:07:04 helios64 kernel: ata2.00: status: { DRDY ERR } Jun 08 20:07:04 helios64 kernel: ata2.00: error: { ICRC ABRT } This is for ata2, but this happens also for ata3 and ata4 - so all three disk of my ZFS. Interesting so, ZFS itself does not detect any read / write errors - but if you e.g. copy files, you see a noticeable drop in throughput, disk access hangs for a moment. I have installed 25.5.1 on SD card, so I was able to switch back to my original system ... and voilá, no such errors anymore. So it seems to be related to 25.5.1. Does anyone know this problem? Is there a solution or anything I'm missing? Thanks Alex

Helios64 for sale. Works well. With battery. 2.5 lan mod haven't been done. Based in Germany.

If I transfer from Helios64 2.5Gbit Port to a client 2.5Gbit port I'll got a very slow transfer rate (Helios -> client around 200Mbit/s), vice versa full speed, switch is 2.5Gbit (Rj45 ethernet Cat7 cable).Testet with iperf. The switch monitoring indicates always 2 errors. I know about the Hardware issue of Lan-Port2, but it only effect 1Gbit transfer. Nevertheless in the Network are also mixed with 1Gbit clients. Is there anything I'll can try to get full 2.5Gbit speed?

A stable Armbian Bookworm configuration for your Helios64 is provided here (solved). ************************************************************************* Recently a new Armbian 23.08.1 Bookworm image with linux-6.1.50 was made available for Helios64 on its download page (see here) - which is as such great 😀. Everything starts up nicely, but unlike the previous Bookworm 23.05 image, the current one has an issue with accessing USB devices. In the boot process the following error occurs: # cat /var/log/syslog | grep error 2023-09-07T12:31:05.671598+02:00 helios64 kernel: [ 2.537009] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core 2023-09-07T12:31:05.671602+02:00 helios64 kernel: [ 2.537107] dwc3: probe of fe900000.usb failed with error -110 No USB device could be accessed. As this seems to be related to the realtek driver r8152, I compiled and installed the current version of that driver (see below) and after that the USB devices were accessible. # compile and install the current realtek driver git clone https://github.com/wget/realtek-r8152-linux.git cd realtek-r8152-linux... make sudo make install

Helios64 network activity light no longer flashes (always off). I have one ethernet cable attached to eth0 and enabled. Otherwise eth0 is working fine Helios64 is rebooted each 24 hours. If I echo "1" to /sys/class/leds/helios64:blue:net/brightness then LED lights up OK. Contents of /sys/class/leds/helios64:blue:net/trigger [none] usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on panic mmc1 mmc2 netdev stmmac-0:00:link stmmac-0:00:1Gbps stmmac-0:00:100Mbps stmmac-0:00:10Mbps rc-feedback tcpm-source-psy-4-0022-online gpio-charger-online rfkill-any rfkill-none phy0rx phy0tx phy0assoc phy0radio rfkill0 System level Linux Helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux PRETTY_NAME="Armbian 21.08.2 Buster" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

Hello Everyone, Unfortunately my helios64 is not glowing any power LED. As soon as I connect the power supply it only shows a blinking orange LED light, that is basically for the battery status. My power supply is perfectly fine and even I have tried using with the ATX power supply same result. Does anyone face this issue and please help me to get my board working again. Thanks!

CAUTION: This content is provided "as is," without warranties or guarantees, and the user assumes responsibility for any consequences, including data loss, system failure, or damages, whether direct or indirect. This is just a few hints how I persuaded mine helios64 to run stable with armbian 24.11 and linux 6.12.1-edge. I have been stressing it several days now and haven't encountered any issue/crash/kernel oopsie. 1) created custom device tree with higher cpu voltage: big cores up to 1800Mhz@1.3V small cores up to 1400Mhz@1.15V also the clock-latency-ns was bumped from 40000 to 50000 2) set up the cpufrequtils service to use big.LITTLE architecture 3) created the /etc/default/cpufrequtils-bl config for the cpufrequtils service I run the big cores 408Mhz@0.85V - 1608Mhz@1.2V and the small cores 408Mhz@0.85V - 1200Mhz@1.025V I prefer to run the cores slower than absolute max freq. I do not recommend running them at 1800Mhz@1.3V (1.3V is absolute max voltage recommended in rk3399 datasheet). My feeling is that the most problematic was the rate_limit_us. It was set to 75/93 out of the box. The cpufrequtils service sets it hard to 20000, which might be too conservative, but whatever. So, If someone is willing to give this a go, this is how to set it up. Hope this helps someone, also looking forward to any feedback. # backup the original device tree first cp /boot/dtb/rockchip/rk3399-kobol-helios64.dtb rk3399-kobol-helios64.dtb.bak # copy new device tree instead of the original # if you're using some custom overlays, you might wanna get rid of them cp <downloaded rk3399-kobol-helios64.dtb> /boot/dtb/rockchip/ # then set up the cpufrequtils service, which uses the /etc/default/cpufrequtils-bl config # cpufrequtils should be installed apt install cpufrequtils # backup the original cpufrequtils service and cpufrequtils-bl config cp /etc/init.d/cpufrequtils /etc/init.d/cpufrequtils.bak cp /etc/default/cpufrequtils-bl /etc/default/cpufrequtils-bl.bak # copy the files in place of the old ones cp <downloaded cpufrequtils> /etc/init.d/cpufrequtils cp <downloaded cpufrequtils-bl> /etc/default/cpufrequtils-bl # start/restart and enable the cpufrequtils service and reboot to use the new device tree systemctl daemon-reload systemctl restart cpufrequtls systemctl enable cpufrequtls reboot # after reboot, check the cpu settings, this is how mine runs: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq 1200000 1200000 1200000 1200000 1608000 1608000 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq 408000 408000 408000 408000 408000 408000 cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor schedutil schedutil schedutil schedutil schedutil schedutil cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency 50000 50000 50000 50000 62000 62000 cat /sys/devices/system/cpu/cpu*/cpufreq/schedutil/rate_limit_us 20000 20000 20000 20000 20000 20000 rk3399-kobol-helios64.dtb cpufrequtils cpufrequtils-bl

I found my Helis64 unresponsive after about a week or so. Even heartbeat LED is not blinking (permanently on). I see this repeating on the serial console [495778.879711] rcu: rcu_preempt kthread timer wakeup didn't happen for 5324533 jiffies! g9706925 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 [495778.880747] rcu: Possible timer handling issue on cpu=3 timer-softirq=2513452 [495778.881383] rcu: rcu_preempt kthread starved for 5324534 jiffies! g9706925 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=3 [495778.882336] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [495778.883137] rcu: RCU grace-period kthread stack dump: [495778.883584] task:rcu_preempt state:R stack:0 pid:16 tgid:16 ppid:2 flags:0x00000008 [495778.884404] Call trace: [495778.884627] __switch_to+0xe0/0x124 [495778.884946] __schedule+0x308/0xa8c [495778.885263] schedule+0x34/0xf8 [495778.885549] schedule_timeout+0x98/0x1bc [495778.885902] rcu_gp_fqs_loop+0x150/0x670 [495778.886256] rcu_gp_kthread+0x234/0x274 [495778.886603] kthread+0x114/0x118 [495778.886896] ret_from_fork+0x10/0x20 [495778.887219] rcu: Stack dump where RCU GP kthread last ran: [495778.887705] Sending NMI from CPU 4 to CPUs 3: Aside from usual NFS server (unused at the time) and syncthing, it was running duplicity backup at the time. I cannot rule out that it ran out of memory. Though it did run full backup successfully a couple of days ago. helios64-rcu-stall.txt

Hello everybody, I would like to sell my helios4 and helios64. They weren't in operation much and are like new. So they are perfect for spare parts or to use them as a complete replacement. I really like the products but I don't want the hustle of fiddling around with every new armbian release. So if anybody is interested you can contact me and/or write here a comment. Thank you very much!

Hello, i have trouble with my Helios64 (possibly bricked), so I am interested to by a new one. And if i can fix mine, the second one could allow me to participate to armbian support for it. Anyone have one for sale ? Preferably in Europe. Thank you.

Hello, After facing multiple instabilities during previous week, I decided to completely reinstall my helios64 to a fresh image (bookworm) from the download section. But before doing that, I need some help/have some questions: Currently, I’m using emmc to host the system, how can I completely backup and restore the system on an sd-card (you know, just in case...) Does the current image (https://dl.armbian.com/helios64/Bookworm_current_minimal) already contains usb drivers from:and this dtb file: Does the process to install the new image on emmc is the same as the one documented on Kobol site? At the moment, I’m a little bit lost on how to proceed… Thanks a lot for your help.

Hi! My Helios64 crashed, rebooted, then refuses to continue. Seems something is corrupted : the eMMC module? The eMMC contains the /boot folder, then the rootfs is on 1st disk, sda1. So I didn't lose anything, I guess. I will try to boot an microSD card with armbian and if it works, I will boot from it. With the sd card, it doesn't boot, I will disable eMMC with the jumper as documented in the wiki Is it fixable? Here are the startup messages: DDR Version 1.25 20210517 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1 Release Time: May 29 2020 17:36:36, version: 1.26 CPUId = 0x0 ChipType = 0x10, 351 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 68635 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3335db8 signature is wrong recovery gpt... GPT 0x3335db8 signature is wrong recovery gpt fail! Trust Addr:0x4000, 0x58334c42 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xea92c RunBL31 0x40000 @ 95489 us NOTICE: BL31: v1.3(release):845ee93 NOTICE: BL31: Built : 15:51:11, Jul 22 2020 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1196): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2021.07-armbian (Feb 27 2022 - 08:44:53 +0000) 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 Net: dw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. scanning bus for devices... Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! : -110 Scanning disk mmc@fe320000.blk... Disk mmc@fe320000.blk not ready Scanning disk sdhci@fe330000.blk... Found 2 disks No EFI system partition dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busBootOrder not defined EFI boot manager: Cannot load any image starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 4!? 5 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device scanning bus for devices... Device 0: unknown device dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: pxeuuid dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/00000000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/0000000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/000000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/00000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/0000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/000 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/00 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/0 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, h registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399-helios64 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_i nit: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk3399 dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busmissing environment variable: bootfile Retrieving file: pxelinux.cfg/default dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busConfig file not found dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. dw_dm_mdio_init: mdio node is missing, registering legacy mdio busdw_dm_mdio_init: mdio node is missing, registering legacy mdio bus=>

Hey, Quick question, can I use HDDs that have the pin-3 SATA "power disable" feature with the Kobol NAS, or should I steer completely clear of them?

Hello everyone, I would like to sell my Helios64. The NAS is in excellent condition, and has been used with care. It is ready to be configured according to your needs. I did not make the fix to take advantage of 2.5Gb/s connectivity (2.5G Ethernet Issue at 1Gbps Link Speed). I bought it for $285.00 + $28.00 shipping + $45.00 customs clearance + $15.00 for a 2.5" adapter (KOB-H64-ADP-01) (SSD support for the system). Total = $373.00 (~€340) I can provide purchase invoices for these amounts. You can make me your offer proposals. Here are some photos : Best regards, Flolm

Hello everyone, I'm experiencing frequent network disconnections on my system running Armbian 24.5.3, both with Bookworm and Noble bases, which are both using Kernel 6.6.39. This issue becomes particularly frustrating when syncing files with Unison, as the interruptions disrupt the process frequently. To provide some background, I didn't encounter these network issues when I was using the last Focal version, which was running on Kernel 5.x. The current versions of Samba I'm using are 4.17.12-Debian on Bookworm and 4.19.5-Ubuntu on Noble. Unison is at version 2.52.1 on Bookworm and 2.53.3 on Noble. Both systems also have the latest updates for MDADM and OpenSSH from the standard package repositories. In the logs (journalctl -xe), I've noticed the following messages repeatedly: kernel: r8152 2-1.4:1.0 enx646266d00567: Tx timeout kernel: r8152 2-1.4:1.0 enx646266d00567: Tx status -2 These errors are accompanied by the following, occurring approximately 15 seconds earlier: kernel: xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 3 ep 3 with no TDs queued? kernel: xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 3 ep 3 with no TDs queued? kernel: xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 3 ep 3 with no TDs queued? kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e050 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e060 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e070 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e080 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e090 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e0a0 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e0b0 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e0c0 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e110 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 kernel: xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 3 comp_code 1 kernel: xhci-hcd xhci-hcd.0.auto: Looking for event-dma 000000000908e120 trb-start 000000000908e020 trb-end 000000000908e020 seg-start 000000000908e000 seg-end 000000000908eff0 I've come across advice suggesting the installation of the correct driver, but that hasn't been very helpful so far. Has anyone else faced similar issues with network stability, particularly under heavy load (e.g., large file transfers)? If so, what steps did you take to resolve it? I would greatly appreciate any insights or recommendations on how to diagnose or fix this problem. Thank you in advance for your assistance! Best regards, mtlmarko189 edit: Please forgive if I should have overlooked the same topic, but unfortunately I have not found what I was looking for on the topic regarding Helios64.

With the recent update of the kernel "edge" package (6.8.11-edge-rockchip64) when the system boots. interfaces get different names (they used to be "end0" and "eth1" before, and now they are "eth0" and "eth1"), but more importantly, they both show different MAC address (the old address returns when previous kernel is booted). It took some time to figure why it did not appear on its prescribed address... Anyone notice this, or has a clue why? Armbian 24.5.5 noble Linux kobol 6.8.11-edge-rockchip64 #1 SMP PREEMPT Sat May 25 14:28:41 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

Howdy. I m running a Helios64 on Armbian 21.02.1 Buster with Linux 5.10.63-rockchip64. I realise this is somewhat old, but it works for me. I have been using MergerFS to present a big "vritual" storage area on my server: jon@OXYGEN:~$ more /etc/fstab UUID=a79a14c0-3cf4-4fb9-a6c6-838571351371 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 # "Disk 2" = /dev/sda3 = 8d360e1c-1908-4d8d-8289-2b1c83604950 UUID=8d360e1c-1908-4d8d-8289-2b1c83604950 /srv/mnt/disk2 btrfs defaults,noatime,nodiratime,nofail,subvol=@data 0 2 # "Disk 3" = /dev/sdb2 = eceee45f-5be5-48ba-a928-8f61686923b0 UUID=eceee45f-5be5-48ba-a928-8f61686923b0 /srv/mnt/disk3 btrfs defaults,noatime,nodiratime,nofail,subvol=@data 0 2 # "Disk 4" = /dev/sdc3 = 8ba04a0d-92eb-44e5-a4f0-99ebe2431b22 UUID=8ba04a0d-92eb-44e5-a4f0-99ebe2431b22 /srv/mnt/disk4 btrfs defaults,noatime,nodiratime,nofail,subvol=@data 0 2 # "Disk 5" = /dev/sdd3 = c3f0e61b-67af-4b35-acb8-e6698f8c9f64 UUID=c3f0e61b-67af-4b35-acb8-e6698f8c9f64 /srv/mnt/disk5 btrfs defaults,noatime,nodiratime,nofail,subvol=@data 0 2 # MergerFS - aggregate the mounted disks together /srv/mnt/disk2:/srv/mnt/disk3:/srv/mnt/disk4:/srv/mnt/disk5 /srv/mnt/virtual fuse.mergerfs defaults,allow_other,use_ino,fsname=/srv/mnt/virtual 0 0 I have recently begun exporting this virtual disk via nfs. Nice! It relly is easy to set up, and it does "just work": jon@OXYGEN:~$ more /etc/exports /srv/mnt/virtual/oxygen/media 192.168.2.0/24(rw,sync,insecure,no_root_squash,no_subtree_check,nohide,fsid=0) But, when my server is rebooted, the nfs-server.service fails to start: _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 21.02.1 Buster with Linux 5.10.63-rockchip64 No end-user support: work in progress System load: 3% Up time: 9 min Memory usage: 17% of 3.77G IP: 172.19.0.1 172.22.0.1 172.21.0.1 192.168.2.105 CPU temp: 43°C Usage of /: 41% of 15G [ General system configuration (beta): armbian-config ] Last login: Thu May 23 16:18:16 2024 from 1975:1976:1977:e00:dead:beef:0000:1111 jon@OXYGEN:~$ sudo service nfs-kernel-server status [sudo] password for jon: ● nfs-server.service - NFS server and services Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2024-05-25 15:36:31 NZST; 10min ago Process: 1210 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE) Process: 1218 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS) Process: 1219 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS) May 25 15:36:31 OXYGEN systemd[1]: Starting NFS server and services... May 25 15:36:31 OXYGEN exportfs[1210]: exportfs: Failed to stat /srv/mnt/virtual/oxygen/media: No such file or directory May 25 15:36:31 OXYGEN systemd[1]: nfs-server.service: Control process exited, code=exited, status=1/FAILURE May 25 15:36:31 OXYGEN systemd[1]: nfs-server.service: Failed with result 'exit-code'. May 25 15:36:31 OXYGEN systemd[1]: Stopped NFS server and services. Running "$ sudo service nfs-kernel-server start" manually, however, gets it going: jon@OXYGEN:~$ sudo service nfs-kernel-server start jon@OXYGEN:~$ sudo service nfs-kernel-server status ● nfs-server.service - NFS server and services Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled) Active: active (exited) since Sat 2024-05-25 16:03:04 NZST; 1s ago Process: 7428 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Process: 7429 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS) Main PID: 7429 (code=exited, status=0/SUCCESS) May 25 16:03:03 OXYGEN systemd[1]: Starting NFS server and services... May 25 16:03:04 OXYGEN systemd[1]: Started NFS server and services. So, to me, it seems that the MergerFS-provided "virtual" filesystem at /srv/mnt/virtual is not ready at the time that the NFS service is starting up. Does anyone know: 1. whether I can modify the definition of the NFS Service, within systemd, so that it starts up later in the boot process? Am I able to define a dependency on some other filesystem service that has yet to be started? 2. whether I can define something else that gets kicked off late in the boot process, which simply attempts to restart the NFS Server service, in the hope that by this late stage in the boot process the MergerFS location is "ready"? Many thanks, Jon

Hi, Today i upgrade to 24.5.3 when apt full-upgrade proposed me to upgrade and return of crash 😞 Tuned rk3399-kobol-helios64.dtb L2 hs400 file seen to be update... i copy paste file used with 6.6.32... I replace rk3399-kobol-helios64.dtb.org (with 24.5.3) with my rk3399-kobol-helios64.dtb post in this forum sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb.org It's seem to be not crash now... Keep in touch. UPDATE: i confirm, after update to 24.5.3, copy rk3399-kobol-helios64.dtb with L2 and hs400 in place of rk3399-kobol-helios64.dtb original is mandatory UPDATE 2: Same if you build with framwork last 24.8 version, you need to remplace: sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb with sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp rename to rk3399-kobol-helios64.dtb

Hello, I have a problem, when I enter "sudo apt install zfs-dkms" on my Helios64, I get this error message: "Module build for kernel 6.6.36-current-rockchip64 was skipped because the kernel headers for this kernel do not appear to be installed." I also made sure to install the kernel header in armbian-config and also rebooted. When I type "apt list --installed | grep linux-headers", I get this listing: WARNING: apt does not have a stable CLI interface. Use it with caution in scripts. linux-headers-current-rockchip64/bookworm,now 24.5.1 arm64 [installed] omv7 itself is installed and running. The image "Armbian_24.5.3_Helios64_bookworm_current_6.6.36_minimal.img.xz" has been installed. apt update and apt upgrade were run after installing the image The plan is to get OMV7 running with zfs on my Helios64 I hope someone can help me with this Regards Saam27

@prahal There are two versions of the bootloader in the repository (edge and current). I just tried the current u-boot from the repository. It works but dmesg outputs seven of the following messages: [ 9.674633] rockchip-i2s ff8a0000.i2s: Could not register PCM This note mentions that such error messages could mean that DMA and sound are missing in the linux kernel, could this be ignored ? P.S.: Those messages are not thrown if the recommended bootloader (linux-u-boot-edge-helios64_22.02.1_arm64) is flashed to emmc.

The mainline 5.11 patch "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e (not backported to 5.10.y) seems to have broken most if not all rockchip board EMMC HS400 enhanced strobe support. This probably affects supported rockchip boards (at least rk3399 ones, but probably most). That is boards exhibit: [ 18.985162] mmc1: running CQE recovery [ 18.988056] ------------[ cut here ]------------ [ 18.988500] mmc1: cqhci: spurious TCN for tag 12 and the filesystem ends up corrupted on write attempt. Note that another bug about regulator core DEFERRED support (which might have produced the same issue hardware wise) was introduced in 5.10.43 (I had bisected it to https://github.com/torvalds/linux/commit/98e48cd9283dbac0e1445ee780889f10b3d1db6a "regulator: core: resolve supply for boot-on/always-on regulators"). But I was confident that it to be fixed in at least 6.1 by https://github.com/torvalds/linux/commit/8a866d527ac0441c0eb14a991fa11358b476b11d "regulator: core: Resolve supply name earlier to prevent double-init" (introduced in 6.1), still EMMC was still failing on me. Thanks to @RussianNeuroMancer telling me that not all rk339 boards had EMMC HS400es broken, I found that nanopc-t4 had https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 So the current way, from this nanopc-t4 commit, to fix EMMC HS400 on most rockchip is to add "rockchip,enable-strobe-pulldown;" to the "emmc_phy" node (at least this node alias for rk3399). &emmc_phy { + rockchip,enable-strobe-pulldown; status = "okay"; }; With this patch I can renable hs400es for rk3399 emmc on helios64 (it is already set for nanopc-t4 in mainline). Details in: I believe the https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e mainline commit was wrong in that it probably should have done the opposite (that is enable the pulldown) as most boards were hardwired so. As was done for rk3588 boards: "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 " JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees. Maybe one can confirm this is the case not only for rk5588 but for other rockchip boards? (about the default for hardware reset and rockchip BSP with regards to active that eMMC-DS pin's builtin pulldown if any, and board designers for other boards than rk5588 also not bothering to add a dedicated RDS resistor, instead relying on the rockchip internal bias, also if any on non rk5588) At least two other boards disabled hs400es in mainline probbaly due to this patch disabling the internal pulldown by default "phy: rockchip: set pulldown for strobe line in dts" https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e in 2023 in vanilla Linux: Rock 4C+ https://github.com/torvalds/linux/commit/2bd1d2dd808c60532283e9cf05110bf1bf2f9079 Rock Pi 4 https://github.com/torvalds/linux/commit/cee572756aa2cb46e959e9797ad4b730b78a050b