Wow! Crazy no?! (lol)
Ok, I can try do that!
Thank you guys for helping me!
Nasty, this explains some other reports. I recognised that there are two device trees now shipped with recent mainline kernel (including Armbian) for each of the revisions respectively. I added a patch to our Armbian fork to create a symlink from old dtb name to the new v1.1 revision. On first boot revision 1.2 is then detected and the dtb adjusted, in case. IIRC this worked well for both revisions. Then at some point the builds failed as a dtb with the old name existed already. I made the symlink creation hence conditional and did not further think about it. Now, I guess or hope, that the new old dtb is actually for v1.2 revision, which hence then broke things again, being not exactly clever for old v1.1 users, causing a breaking change with any kernel upgrade. In that case, enforcing the symlink at build time in our fork would fix it.
Can someone with the v1.1 revision try this when facing the error:
G_CONFIG_INJECT 'fdtfile=' 'fdtfile=rockchip/rk3566-orangepi-3b-v1.1.dtb' /boot/dietpiEnv.txt
1 Like
Okay I just checked the image, and it has the symlink correctly set. Also, the new bootloader selects (resp. should do so) the correct device tree automatically. Could be checked with:
cat /proc/device-tree/model
So in any case, new images should support both revisions, and IIRC this used to work when we migrated to the new kernel with both device trees initially.
1 Like
@MichaIng Iāve tried putting in the fdtfile explicitly previously too, this did not help.
@MichaIng I tried, but is the same (I donāt know if a had made correctly, but I did).
Ethernet port is dead
1 Like
@urostor @mff1985 so in both your cases cat /proc/device-tree/model reports revision 1.1, but Ethernet is broken? So the new kernel with dedicated 1.1 device tree broke it for this revision?
Tell me which image to test, and should I test dietpi or Armbian?
Any of both should behave the same way, or just upgrade the kernel on any running system.
OK, I tested what you said with the latest kernel and this is the result:
Xunlong Orange Pi 3B v1.1
Without stating the fdtfile. The ethernet is down, WiFi seems to work (for now). You are the first person to actually acknowledge and try to look into this error, so thank you.
end0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 5a:95:e8:0f:34:7d brd ff:ff:ff:ff:ff:ff
If I try to enable it:
$ sudo nmcli connection up netplan-end0
[sudo] password for dietpi:
Error: Connection activation failed: The device could not be readied for configuration
Hint: use 'journalctl -xe NM_CONNECTION=6913d6d5-ed71-3675-b363-92bc308db5ca + NM_DEVICE=end0' to get more details.
This command returned:
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6644] device (end0): state change: unavailable -> disconnected (reason 'user-requested', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6673] device (end0): Activation: starting connection 'netplan-end0' (6913d6d5-ed71-3675-b363-92bc308db5ca)
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6681] device (end0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6697] device (end0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6753] device (end0): state change: config -> failed (reason 'config-failed', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6772] device (end0): released from master device br0
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <warn> [1736377664.6780] device (end0): Activation: failed for connection 'netplan-end0'
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.6790] device (end0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.7036] device (end0): Activation: starting connection 'netplan-end0' (6913d6d5-ed71-3675-b363-92bc308db5ca)
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.7040] device (end0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jan 09 00:07:44 orangepi3b NetworkManager[795]: <info> [1736377664.7055] device (end0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
et cetera.
kernel:
Linux orangepi3b 6.13.0-rc5-edge-rockchip64 #1 SMP PREEMPT Sun Dec 29 21:15:45 UTC 2024 aarch64 GNU/Linux
Just as a side note, DietPi is not using NetworkManager. Our tooling and scripts are based on ifupdown.
1 Like
Jep, this was on a recent Armbian image. So we know the edge kernel is affected the same way, and do not need to test it anymore.
I wonder whether the old device tree, from before they were split for v2.1 support, work with the new kernel. At least worth to compare the two.
Okay, in mainline Linux it was added split right from the start, and have not been touched since that: arm64: dts: rockchip: Add Xunlong Orange Pi 3B - kernel/git/stable/linux.git - Linux kernel stable tree
Here the device tree patched inside by Armbian to Linux 6.6: build/patch/kernel/archive/rockchip64-6.6/dt/rk3566-orangepi-3b.dts at ffd1a42d7a6abf25437e80a2641b5d0cff54052f Ā· armbian/build Ā· GitHub
It contains some additional RX/TX delays, I actually remember this for another case: Image | Radxa ROCK 3B Ā· Issue #7327 Ā· MichaIng/DietPi Ā· GitHub
RK3566 vs RK3568, but they are very similar, also device tree nodes and their difference between mainline and vendor kernel are similar. @urostor do you also see this error in your dmesg?
__stmmac_open: Cannot attach to PHY (error: -19)
ā¦ ah, I see it already in the screenshot above: After upgrade emmc died and the new installation via SD card does not connect to the network
Okay, we can assume both are suffering from the same issue with mainline Linux, whether it is with unmodified one or due to an Armbian patch. We could do a kernel build with Armbian patches removed, just to rule that out, resp. search for the faulty patch, instead of trying to overpatch a faulty patch. And if no, we can try to add the missing parts of the vendor device tree into the mainline device tree, and see whether this helps.
Iāll start with a build with patches removed.
4 Likes
So this could be tested, a fresh build with all Armbian patches removed, just to rule out it is not something conflicting with a recent upstream change:
cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb
reboot
1 Like
Hello there, Iāll test your solution once Iām home.
some on Radxa forum arenāt friendly either 
Yes, you met Igor, the main developer of Armbian. He certainly wonāt have a āgoodā opinion of DietPi 
Btw: he is reading our forum as well.
1 Like
Igor is Armbianās head developer, he goes to the Radxa forum to complain about people using armbian, or not enough people using armbian. I wonāt even try to understand. Will test that kernel too
1 Like
I just figured out that the ācurrentā kernel/dtb you linked here is 6.12.8. It did not work to enable ethernet (it could not, this is one of the broken ones), also installing it broke WiFi connectivity too 
2 Likes
Sure it is a new one, and I am trying to narrow down what is causing the issue. So it is not incompatible Armbian patches. Right makes sense that WiFi is lost, as it requires this sprdwl_ng driver, which is not in mainline kernel. Okay Iāll implement the diff between vendor and mainline kernel into Ethernet part of the device tree then, to see whether this helps instead.
However, you might want to be careful not to break the ethernet on the new board version by fixing the old one. I think I heard it works on the new board.
Indeed wifi broken