Werner

I guess the image was built from a pending pull request for testing before merge. Since it has been merged now it should work. Make sure your framework clone is up to date (git pull).

Looks like stuff got lost due to force-push. Check this how it looked before: https://github.com/rvdr/build/activity?ref=spi-nvme-patches

Okay we're randomly poking at things. Please provide the following for every image you test. dmesg | grep -iE "stmmac|sun8i|dwmac|emac|phy|mdio|motorcomm|yt8531" dmesg | grep -i "registered.*phy\|phy.*connect" ls -l /sys/bus/mdio_bus/devices/ cat /sys/bus/mdio_bus/*/phy_id 2>/dev/null find /sys/class/net -name "end0" -o -name "eth0" | head -1 | xargs -I {} cat {}/phys_switch_id 2>/dev/null ls /sys/firmware/devicetree/base/soc/ethernet*/mdio/ and the output of armbianmonitor -u (if network doesn't work use -U instead to print to stdout) The following one adds phy-io-supply = <&reg_gmac_3v3>; to the emac, just in case... https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal_phy-io-supply.img.xz

duplicate https://forum.armbian.com/topic/57200-orange-pi-zero-2w-repeatedly-asks-for-wi-fi-password/?do=findComment&comment=231167

One last attempt. Reverted back to .62 due to upstream regulator handling changes https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.62_minimal.img.xz

Bummer. Well. Was worth a try. You can stick with 6.18 for now.

Different attempt. Instead of working around trying to revert which might be the root cause: https://lists.openwall.net/linux-kernel/2025/09/17/618 I'll provide you with another image containing this adjustment shortly. https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal.img.xz Could you do me a favour and execute these commands on both in a non-working state of a broken image and in working state of a good image? dmesg | grep -i "phy.*halt\|mdio.*reset" watch -n 1 'ethtool eth0 | grep -E "Speed|Duplex|Link detected"' cat /sys/class/net/eth0/phydev/phy_state 2>/dev/null Edit: https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal_regulator_fix.img.xz this image follows another different approach by adjusting regulators which may cause issues. Feel free to test

So to cut a long story short 6.18.y kernel image works? If so then this issue has low priority since 6.18 will replace 6.12 as current in a few month anyway since it is the new LTS kernel upstream.

Please report here https://github.com/armbian/imager/issues

standard baud rate for rockchip socs is 1500000. And for the other your cp2102 is no good for this high speed since it cannot handle it. And instead of failing it will output garbage. get ft232r, cp2104 or pl2303 based adapter.

May have found something. Perhaps https://lists.openwall.net/linux-kernel/2025/09/17/618 causes issues. Here is a test image that works around this by adjusting device tree a bit. Please test and report https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal.img.xz

logs?

From a quick research it seems mainline driver does not support this. You need to install out of band driver from realtek

https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/#comment-199170

Okay, didn't bother checking beforehand

I think this patch can also be backported to 6.18.y in Armbian if @rpardini didn't plan to do anyway.

https://patchwork.kernel.org/project/linux-rockchip/patch/20251230-arm64-dts-rockchip-rk3588-npu-enablements-v1-1-d38b182a59e3@pardini.net/ fyi

You are community. Contact yourself As there is no maintainer for this board everyone and nobody the same time is responsible for it. If nobody cares, functionality will fall apart over time.

The userspace is behind, that's not an issue. Hardware support is a kernel thing. If its not there an up-to-date userspace like Forky or Sid means nothing.

Alright, partial success rfkill. Hm perhaps wifi trouble?

Alright, found something. @Meestor_X please try this one: https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img.xz

--> (667) DEBUG: Partition table after write_uboot [ /dev/loop0 ] --> (667) COMMAND: sfdisk -l /dev/loop0 The primary GPT table is corrupt, but the backup appears OK, so that will be used. Disk /dev/loop0: 2.37 GiB, 2541748224 bytes, 4964352 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 62C4432A-F158-49BE-8F59-F5A5895C7057 Device Start End Sectors Size Type /dev/loop0p1 8192 1056767 1048576 512M Linux extended boot /dev/loop0p2 1056768 4962303 3905536 1.9G Linux root (ARM-64) This is what the image looks while still on loop dev just before detaching from. But for some reason its messed up right after. Don't know why...yet root@build:~/build/output/images# parted Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img u b p Error: /root/build/output/images/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img: unrecognised disk label Model: (file) Disk /root/build/output/images/Armbian-unofficial_26.02.0-trunk_Radxa-cubie-a5e_trixie_edge_6.18.2_minimal.img: 2541748224B Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags:

I usually just re-plug the sdcard back into my laptop, the fs mounts automatically for me. Using Linux though, no clue about MacOS.

Please set verbosity to 7 in armbianenv.txt to get a clue about what happens after "starting kernel..." data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== Interesting. While this isn't an actual issue since the correct dt was loaded nevertheless it seems like BOOT FDT FILE Is set wrong

moved to tvboxes