Werner

Alright, well, such things can happen when attempting to fix a bug and not having hw to test on hand I'll leave it to Cornelius to send a fix since he can directly verify if it works.

Oh great. Then I'll steal borrow your dts and replace the one currently in the framework later

on which kernel did you test?

I tried integrating the suggestion into the actual device tree. Feel free to test: https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.64_minimal.img.xz

mirrors/repo are degraded at the moment. We're aware and working on it.

If that worked for you, then you're lucky. For me it did not (other board tested). I guess the files on there have an older state which is still good. Again, as mentioned, repo is being worked on and we're aware of the issues and trying our best to resolve this asap.

I suggest to try kernel-patch build command. Your changes then are compiled into a patch which is then applied to the kernel source before building.

duplicate

moved to off-topic since op is not using Armbian.

Hm interesting. Didn't know this exists. But if it doesn't work I suggest to run a build with also DEBUG=yes set and then share the whole log using the curl command provided at the end. May give some clues if this fails to apply or works as intended.

never heard of that one before. Serial console is enabled by default on all boards (lookup your board manual on where to connect) which also outputs uboot logs while on early boot stage. For increased kernel verbosity set verbositoy to 7 in /boot/armbianEnv.txt

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