However, vendor image also uses a different PHY handle phy@0, while mainline Linux uses ethernet-phy@1. I don’t know where these are defined, maybe the 2nd sets delays, and we hence need to switch to the first as well. Also in mainline Linux, these GPIO resets are defined in the MAC, with these snps attributes, while in mainline Linux, they are defined in the PHY instead. And the “deassert” delay is explicitly increased in the vendor device tree. So that would be another thing to test, if RX/TX delays do not help.
EDIT: Some mainline commits related to the resets:
So the way it is done in the vendor kernel is deprecated. The delays have been updated in these cases based on documented vendor recommendations. They have been reduced in almost all cases, and in case of Orange Pi 3B and ROCK 3B, they are as well significantly larger (the “deassert” one at least) in the vendor device tree. Since those 2 device trees were mainlined before the deprecation/migration, there is no explicit info about vendor recommendations, however, would be weird if vendors have larger delays than what they recommend themselves, and even a the “deassert” delay transparently further increased, visible due to the commented line. We can try to apply the longer delay via new method reset-deassert-us, if RX/TX delays do not fix it already.
And then, the vendor device trees define also assigned-clock-rates in the MAC, so that is another thing to test.
confirming @MidG971 results - ethernet not working, wifi broken.
Is there anyone with the new board version here?
How to go back to the other kernel (6.13-rc5)? Uninstalling the one you linked just makes the board unbootable. The kernel symlink seems to be removed, I can probably recreate it but is there a command that does this automatically?
I wonder why WiFi is still broken, as all Armbian patches are back in, and our patch is not at all related to WiFi. What happens if you try to load the module manually?
modprobe sprdwl_ng
ip l
To go back to a previous kernel where WiFi was working:
cd /tmp
wget https://dietpi.com/downloads/binaries/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb
reboot
Not /testing/ vs non-testing here. This is not the Linux 6.13 “edge” kernel, but 6.12 “current” kernel.
As said, I was confused that even the last build broke WiFi, since it reverted the Armbian patch removal completely. It should be mostly equal to the previous 6.12.7 build, where WiFi was working, only with a small patch for the WiFi adapter, which cannot break WiFi. But kwiboo just commented on the GitHub issue, that mainline Linux 6.12.9 pulled a patch which broke some things: Image | Radxa ROCK 3B · Issue #7327 · MichaIng/DietPi · GitHub
Not sure whether it is related, but if so, would be a pretty rare coincidence, that a 6.12.8 build broke WiFi due to testing patch removals, and the next build, which reverted that, had it broken due to faulty mainline Linux patch in 6.12.9.
An Armbian developer said on the Orangepi Discord that the WiFi and ethernet works on v1.1 with stuff from the beta Armbian repository (25.2.0-trunk.322). I am not sure how to test this yet though.
Our rebase onto the the same repository. So as long as it was not fixed after we did the build, it is in ours as well. EDIT: And nope, there was no related commit in the meantime:
But I will do another build regardless, as after what I was reading yesterday, I am now sure the Ethernet problem is about the PHY reset, or its reset delays.
To be sure, can you flash the bootloader to SPI via dietpi-config advanced options? Because a recent one is needed to reset the PHY right in the bootloader, and Kwiboo says that should be sufficient. When booting from eMMC, the one from there should be used, but that is written together with the image, which was new enough. But maybe the board is still booting from SPI.
I was testing on armbian, so no dietpi-config there. I have Joshua Riek’s Ubuntu installed to the eMMC, will this procedure not prevent it from booting?
I do have a UART indeed, will check but not tonight. I wouldn’t want to break my current Ubuntu installation though, so please tell me if there is a chance of making it unbootable (or maybe I can just dd a backup of the SPI? I think it’s clear now).
It was surely not empty, if you never touched it. As said, usually, when booting form SD card or eMMC, the bootloader on this card should be used, SPI only as fallback. Only when booting from NVMe/M.2 SSD or USB, where hardware cannot load a bootloader from directly, the SPI bootloader is needed. But who knows, wouldn’t be the first time that an SBC behaves unexpected/against conventions.
… either that, or the PHY must be reset properly from the kernel, i.e. the device tree needs adjustment. Kwiboo also mentioned another solution. So actually, if you have time to test another kernel build first, that would be great. Our images shall work with any bootloader, if possible.
