the issue is fixed with edge kernel, with armbian u-boot included in 26.2.1 speed is now at gigabit level # uname -r 6.19.0-edge-rockchip64 # grep -a --null-data U-Boot /dev/mtd0ro U-Boot SPL 2026.01_armbian-2026.01-S127a-Pc2e6-H706e-Vab81-B2eb2-R448a (Feb 10 2026 - 04:37:42 +0000) # iperf3 -R -c odroidm1.lan Connecting to host odroidm1.lan, port 5201 Reverse mode, remote host odroidm1.lan is sending [ 5] local 192.168.1.192 port 45834 connected to 192.168.1.195 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 110 MBytes 919 Mbits/sec [ 5] 1.00-2.00 sec 110 MBytes 919 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 928 Mbits/sec [ 5] 3.00-4.00 sec 110 MBytes 927 Mbits/sec [ 5] 4.00-5.00 sec 110 MBytes 922 Mbits/sec [ 5] 5.00-6.00 sec 110 MBytes 919 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 928 Mbits/sec [ 5] 7.00-8.00 sec 110 MBytes 925 Mbits/sec [ 5] 8.00-9.00 sec 110 MBytes 925 Mbits/sec [ 5] 9.00-10.00 sec 110 MBytes 921 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec 110 sender [ 5] 0.00-10.00 sec 1.08 GBytes 923 Mbits/sec receiver

This device is currently an outcast here, and until someone with understanding sets out to fix at least the main problems, welcome to the official image on the 5.15 kernel.

You can find the pinout at https://linux-sunxi.org/MicroSD_Breakout : CD is rx, CLK is tx and GND. There is a risk that using 3.3 v TTL levels on the tf card slot could fry the microsd controller so I would suggest getting the 1.8V version I mentioned earlier. So here is how I boot debian Trixie these days: (still need to figure out how to automate this but I do not know how yet using u-boot) setenv bootargs console=ttyAS0,115200 root=/dev/sda28 rw rootwait init=/sbin/init clk_ignore_unused sunxi_flash read 4007F000 boot_a sunxi_flash read 4fa00000 dtbo_a fdt addr 0x4fa00000 bootm 4007F000 - 4fa00000 Write dtb: dtc -I dtb -O dts -o tablet.dts tablet_patched.dtb dd if=tablet_patched.dtb of=/dev/sda24 status=progress conv=fsync dd if=tablet_patched.dtb of=/dev/sda25 status=progress conv=fsync You need these on host: sudo apt update sudo apt install debootstrap qemu-user-static How to prepaire the rootfs which will be flashed to userdata using fastboot: fallocate -l 8G teclast_trixie.img mkfs.ext4 -b 4096 teclast_trixie.img sudo mount -o loop teclast_trixie.img /mnt/trixie sudo mount --bind /dev /mnt/trixie/dev sudo mount --bind /sys /mnt/trixie/sys sudo mount --bind /proc /mnt/trixie/proc sudo debootstrap --arch=arm64 trixie /mnt/trixie http://deb.debian.org/debian sudo chroot /mnt/teclast /bin/bash passwd root echo "t60" > /etc/hostname apt update apt install build-essential kmod # you will need to install bunch of others but not more than 3 GB I think because fastboot wont reliably transfer more exit sudo fastboot erase userdata sudo fastboot flash userdata teclast_trixie.img How to do the raxda kernel: ./magiskboot unpack boot.img cp ../../raxda_kernel.img kernel ./magiskboot repack boot.img new_boot.img sudo fastboot flash boot_a new_boot.img sudo fastboot flash boot_b new_boot.img Wifi driver is a bit complicated(TBD): modprobe aic8800_bsp modprobe aic8800_fdrv ip link show wlan0 Here are the stock partitions: root@t60:~# blkid /dev/sda26: SEC_TYPE="msdos" UUID="2200-140B" BLOCK_SIZE="4096" TYPE="vfat" PARTLABEL="media_data" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5e" /dev/sda22: UUID="dd7fd886-b74f-41cf-a5b1-bf1b47afaf8c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="treadahead" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5a" /dev/sda1: SEC_TYPE="msdos" LABEL="Volumn" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="bootloader_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e45" /dev/sda23: SEC_TYPE="msdos" UUID="4019-0FB8" BLOCK_SIZE="4096" TYPE="vfat" PARTLABEL="private" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5b" /dev/sda21: UUID="a5aa7e72-84f0-40c4-9693-2a2ad5896309" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="metadata" PARTUUID="a0085546-4166-744a-a353-fca9272b8e59" /dev/sda28: UUID="f84bc812-d087-4cba-a90f-d045d40d2e44" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="userdata" PARTUUID="a0085546-4166-744a-a353-fca9272b8e60" /dev/sda4: PARTLABEL="env_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e48" /dev/sda16: PARTLABEL="vbmeta_system_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e54" /dev/sda2: PARTLABEL="bootloader_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e46" /dev/sda24: PARTLABEL="dtbo_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5c" /dev/sda14: PARTLABEL="vbmeta_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e52" /dev/sda12: PARTLABEL="misc" PARTUUID="a0085546-4166-744a-a353-fca9272b8e50" /dev/sda9: PARTLABEL="init_boot_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4d" /dev/sda20: PARTLABEL="empty" PARTUUID="a0085546-4166-744a-a353-fca9272b8e58" /dev/sda10: PARTLABEL="init_boot_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4e" /dev/sda7: PARTLABEL="vendor_boot_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4b" /dev/sda19: PARTLABEL="frp" PARTUUID="a0085546-4166-744a-a353-fca9272b8e57" /dev/sda5: PARTLABEL="boot_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e49" /dev/sda27: PARTLABEL="pstore" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5f" /dev/sda17: PARTLABEL="vbmeta_vendor_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e55" /dev/sda3: PARTLABEL="env_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e47" /dev/sda25: PARTLABEL="dtbo_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e5d" /dev/sda15: PARTLABEL="vbmeta_system_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e53" /dev/sda13: PARTLABEL="vbmeta_a" PARTUUID="a0085546-4166-744a-a353-fca9272b8e51" /dev/sda11: PARTLABEL="super" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4f" /dev/sda8: PARTLABEL="vendor_boot_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4c" /dev/sda6: PARTLABEL="boot_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e4a" /dev/sda18: PARTLABEL="vbmeta_vendor_b" PARTUUID="a0085546-4166-744a-a353-fca9272b8e56" tablet.dts

Updating to include a few more I've successfully run... OpenMW - FOSS Engine to play Morrowind & it's KOTOR total conversion Starwind Quakespasm - FOSS engine to play Quake and it's expansions, mods & total conversions UFO: Alien Invasion - an XCom "homage" Yamagi Quake 2 - FOSS engine for Quake 2 I was able to test Quake Mods like the cyberpunk FPS prequel to a prequel to a Dreamcast mecha game "Slave Zero X: Enyo" and top down fantasy RPG "Prydon Gate". Both work great but I'll need to upgrade the eMMC before I can try larger sized conversions like Brutalist Jam III or Slayer's Testaments.

@SymbiosisSystems, Thanks for testing and reporting back. Before diving into the panic itself, a bit of context: the CPU stability overlay we packaged from the prahal/ebin-dev recipe is opt-in precisely because, thanks to the RK3399 silicon lottery, most Helios64 units don't need it. The very fact that you do need it already hints that your particular unit is sitting closer to the edge of its operating margin than a typical one. That's not blaming the hardware — just an observation that units with marginal stability often expose other weak spots that stay invisible on an "average" board. Now to the crash itself. `Asynchronous SError` in `rockchip_pcie_rd_conf` during PCI enumeration is a known bus-level abort on the RK3399 PCIe controller, not on the CPU. Our overlay has nothing to do with CPU cluster voltages here: it only raises `vdd_cpu_b` on opp00..opp06 of the A72 cluster, while PCIe sits on `vdd_logic` and separate PCIe rails which we don't touch. The PCIe x2 Gen2 lane from the RK3399 in Helios64 is wired directly to the soldered-on JMicron JMB585 SATA controller ([Kobol Wiki — SATA](https://wiki.kobol.io/helios64/sata/)), which provides the five SATA ports. So the only possible endpoint where bus scan is currently failing is the JMB585. The typical scenario goes like this: the endpoint replies with CRS (Configuration Request Retry Status) or simply doesn't respond within the completion timeout window → the root complex raises a completion abort → AArch64 sees it as an async SError. This class of bugs on the RK3399 is well documented: - [\[BUG\] rk3399-rockpro64 pcie synchronous external abort](https://lore.kernel.org/linux-pci/CAMdYzYrYHtiEXwiKxwWcKSV7Re6dG4zTvkKtZxvso+fLBRYbPQ@mail.gmail.com/T/) — same class of bus-level abort on the same SoC. - [RFC patch: configurable bus scan delay](https://www.spinics.net/lists/linux-pci/msg103350.html) — the general nature of CRS/timeout problems (the specific HBA delays from that thread don't directly apply to Helios64, since your endpoint is a fixed JMB585, not a swappable card). - [rockchip-linux/kernel#116](https://github.com/rockchip-linux/kernel/issues/116) and [#118](https://github.com/rockchip-linux/kernel/issues/118) — "Some PCIe devices cause Rockchip PCIe controller to crash in bus scan". - The [v5 series fixing the RK3399 PCIe endpoint driver](https://patchwork.ozlabs.org/project/devicetree-bindings/cover/20230418074700.1083505-1-rick.wertenbroek@gmail.com/#3135632) — CRS handling and the Configuration Enable bit. - Armbian has known about RK3399 PCIe quirks for a long time: [commit edb45f9 — "Make PCIe reset optional"](https://github.com/armbian/build/commit/edb45f9acf322fc4b27bf7efba3f14a3a432b617). So your stack trace falls into a family of long-known RK3399 PCIe problems and is unrelated to the voltage overlay. If someone — from the rockchip64 maintainers or from the community — picks up your case, here's what is usually expected to be attached to a report like this, otherwise diagnosis will inevitably hit a wall of missing data: 1. A full serial bootlog via USB-UART (Helios64 → 1500000 baud), both with the overlay and without it (just comment out `overlays=` in `armbianEnv.txt`) — to see whether the picture differs or this is an independent problem. 2. State of the SATA bays: try booting with the bays completely empty (or one drive at a time) — if the PCIe link to the JMB585 comes up cleanly without any SATA load, the problem narrows down to one of the drives rather than the link itself. 3. u-boot and BL31 (ATF) versions — `dmesg | grep -iE "u-boot|psci|bl31"`, plus `strings /boot/u-boot.bin | grep -m1 "U-Boot 20"` if you have access. 4. The full `dmesg` up to the moment of the crash — even if truncated, whatever made it out to serial. 5. The entire contents of `/boot/armbianEnv.txt`. 6. Try two extra kernel boot parameter options — this is the simplest experiment and often helps on unstable RK3399 PCIe. **a) Disable PCIe power management** (a known workaround for the broken PM on RK3399). Open `/boot/armbianEnv.txt`: ``` sudo nano /boot/armbianEnv.txt ``` Find a line starting with `extraargs=`. Two cases: - **If such a line exists** — append the parameters at its end, separated by a space. For example, it was: ``` extraargs=console=tty1 ``` Becomes: ``` extraargs=console=tty1 pcie_aspm=off pcie_port_pm=off ``` - **If there is no such line at all** — just add a new line at the very end of the file: ``` extraargs=pcie_aspm=off pcie_port_pm=off ``` Save (Ctrl+O, Enter, Ctrl+X), `sudo reboot`, try booting. To revert: remove what you appended (or delete the added line entirely) and reboot again. **b)** You can try downgrading PCIe from Gen2 to Gen1 (RK3399 Gen2 link training is regularly unstable), but that requires writing your own device tree overlay — there is no ready-made one in Armbian. And finally, to be honest: we are not PCIe stack experts and not rockchip64