All Activity

Hi, this board isn't supported, hence no images available.

Basically I'm confused I want to download. I need someone's help on this. I looked up the download multiple times and I still have not found it.

Orangepi4pro is pure shit. A lot of marketing and no support at all. No driver to install nvme, I ruined the SPI trying to install Assist, and now I have a unuseful expensive brick.

Yes. I just came to armbian-config and there I select en_US as default, but it does not change Mate to en_US. It change are only on cli.

@iav Thank you for the detailed reponse. I was not blaming the overlay or your build; I know the cpu voltages don't impact on this seperate issue. I have seen this before with the 6.18 kernel on the Helios64 which is why for the moment I am sticking with the 6.12 kernel with the opp microvolt patch which seems to be stable for me at least. I assume something has changed in the underlying PCIe architecture or drivers between 25.11.2 with 6.12.58 and 26.5.0 with 6.18.30 which results in this issue on my hardware. It is interesting that the build works on your hardware though. I will investigate the PCIe issue further when time allows and raise a issue.

@ljones0 in meantime can you test edge kernel images, i'm sure those works.

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg-reconfigure locales and change default locale Tried?

I have Debian and installed Mate. I happen to install sv_SE.UTF-8 and en_US.UTF-8 but I cannot change languish on desktop from sv_SE.UTF-8 to en_US.UTF-8. First I just remove "sv_SE.UTF-8, but then the Terminal complain it did not find sv_SE, so install again. I generate the 2 locales, And thied to when I marked the local I want en_US, but it say sv_SE are active in Mate. I tried to run: sudo localectl set-locale en_US.UTF-8 Failed to issue method call: Access denied I don't find any "Languish controll" at all in Mate desktop It is right languish in terminal. Cheers Joni

Unfortunately "apt-file" stopped working for packages in the Armbian repos, which seems to be due to the absence of "Contents" files. Can this please be fixed, or is it intentional for some reason?

1. https://github.com/apritzel/sunxi-fw 2. "adb reboot bootloader" takes you to fastboot if android boots up, "fastboot" if you are at u-boot terminal. See help for list of u-boot commands, I do not know that much about it but you can feed the list to AI and see if something useful comes up. So to get acceleration we need to pull at least 6.12.x kernel from raxda a7a a7s a7z to get video acceleration going, maybe like https://github.com/radxa-build/radxa-a733/releases

Thanks for your information. 1: In step 8 (`./sunxi-fw extract -n "wty:init_boot.fex" -o stock_init_boot.img Firmware.img`) you extract init_boot with sunxi-fx. How do you extract it? #: I've tried 3 times and haven't succeeded. Can you tell me the steps? I might not be writing correctly somewhere. 🤦‍♂️🤦‍♂️ 2: You say that if the message "lock bootloader" appears on the screen with TF UART, I can enter fastboot mode. What is the procedure?🤷‍♂️ Thanks

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

Hello @jock, thank you for the quick reply! Indeed, the drivers for the 8723cs have been disabled in the rockchip64 version, as confirmed by my config file: grep -i "8723" /boot/config-$(uname -r) # CONFIG_RTL8723CS is not set # CONFIG_RTW88_8723CS is not set I found 2 GitHub repos with the uncompiled drivers for the 8723cs chipset: - https://github.com/VictorIstratii151/rtl8703bs_rtl8723cs_linux_driver - https://github.com/TinkerBoard-Android/rockchip-android-external-wifi_driver/tree/android14-rockchip I tried to compile them natively on my machine but without success. They relies on Android-specific headers that are missing in Armbian. Regarding the rockchip armhf family you mentioned, do I need to completely reinstall Armbian on my board using a different image (the 32-bit armhf one)? Do I have to use the Armbian build framework to achieve this? Or is there a way/tool to cross-compile this specific module for my current 64-bit setup? Thanks again for your help!

Hi Taz I wanted to let you know: 1: I got them working perfectly again thanks to your help.👍👍 2: The problem was with the firmware, which always gave an error when updating.🤦‍♂️ #: I downloaded the firmware twice from the official Teclast website. #: I downloaded it the third time, and this time it updated completely. #: It's possible that some files got corrupted when I extracted them. 3: How do you connect the TF UART adapter? 4: Why did you install this Armbian operating system on the Allwinner A733? #: Does it work better? Is it smoother than Android on this tablet? Thanks

@Delutto Thank you for your contribution! Your changes have been successfully merged to my repo https://github.com/cdhigh/armbian_sv6256p Now the driver should work with kernels from 6.0 through 7.x.

This issue is not from u-boot but rather a board config Please see this https://github.com/armbian/build/pull/9333 and use edge kernel instead, stable doesn't include this fix Cheers !

Hello everyone. I made a direct connection between the 5V from the motherboard and the 5V from the USB ports to try and overcome the current limitation of the USB ports. However, something went wrong. I undid this direct connection, but the motherboard is still shorting the USB ports. I believe the short circuit is in that ADG3T port. Does anyone have any idea what happened? I didn't even connect anything to the USB port. Thanks.

@Evgeniy evotronik When I switch from 1 Gbps to 100 Mbps... Ethernet returns to normal.

HDMI is working out of box now?

latest u-boot still suffers... ############################################### latest u-boot from https://github.com/inindev/uboot-rockchip/releases image: https://github.com/inindev/uboot-rockchip/releases/download/v2026.04/rk3568-odroid-m1.zip ################################################ # 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 51070 connected to 192.168.1.195 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec [ 5] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 6.00-7.00 sec 256 KBytes 2.10 Mbits/sec [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec [ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.00 MBytes 839 Kbits/sec 197 sender [ 5] 0.00-10.00 sec 896 KBytes 734 Kbits/sec receiver iperf Done. root@odroidm1:~# grep -a --null-data U-Boot /dev/mtd0ro U-Boot SPL 2026.04 (Apr 16 2026 - 23:02:37 +0000)

When I ask multiple questions, it is for a reason. When you don't answer all of the questions, then I can't help you as I have to guess. So here is a guess, that you are burning the SD card on Windows. I have seen reports that on some versions of Windows, that windows will automount the FAT partition on the SD card after burning, and when it mounts it it alters it in ways that cause problems. I haven't spent any time looking into that issue, but because of what I have seen repored, I would avoid doing the burn on windows. Please try it on a linux box. As for recommended burning tool, you should follow the Armbian documentation (https://docs.armbian.com/User-Guide_Getting-Started) and use Armbian Imager.