OPI zero 2w, Ethernet doesn't work after upgrade to v10.2.3

The result

root@DietPi:~# modprobe dwmac-sun8i
root@DietPi:~# lsmod | grep dwmac_sun8i
root@DietPi:~# 

I try 'G_DEV_TEST_FIRMWARE
`

Oh, that driver is builtin, i.e. it is always loaded. Let’s see whether matching it in the device tree helps.

With kenel 6.18.23 in place and a reboot

root@DietPi:~# modprobe dwmac-sun8i
root@DietPi:~# lsmod | grep dwmac_sun8i
root@DietPi:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether f4:e4:dc:4d:b4:4b brd ff:ff:ff:ff:ff:ff

Okay, so it requires the vendor driver. Enabled:

Pressing thumbs that it compiles.

EDIT: That did not work, the driver was not (attempted to be) compiled. Let me check, maybe some dependency is missing.

EDIT2: The patch was not in the series.conf, i.e. was not applied :roll_eyes:. Done with orangepizero2w: fix ethernet using sunxi-gmac driver Ā· MichaIng/build@cf6f98e Ā· GitHub, and build retriggered.

EDIT3: It is still not compiled. Reason is that CONFIG_MFD_AC200_SUNXI=m for some reason is not applied (a dependency of CONFIG_SUNXI_GMAC), i.e. it is defined in the defconf, but not in the result kernel config. However, it is defined in this patch, which is applied as CONFIG_MFD_AC200=m is effective, and the related driver module present in the kernel package: build/patch/kernel/archive/sunxi-6.18/patches.armbian/drv-mfd-ac200-add-support.patch at main Ā· armbian/build Ā· GitHub
CONFIG_PWM_SUNXI_ENHANCE=m and CONFIG_I2C=y are present, i.e. dependencies are satisfied. Hence no idea why CONFIG_MFD_AC200_SUNXI is not applied, so that CONFIG_SUNXI_GMAC cannot be applied either. I’ll have another look.

EDIT4: Found it, somehow there are two related patches, a complete one with CONFIG_AC200_PHY_SUNXI, and one with CONFIG_AC200_PHY only:

Ohh yesssss it work with the new build and

G_DEV_TEST_FIRMWARE
root@DietPi:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether e2:57:59:18:e4:4a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether f4:e4:dc:4d:b4:4b brd ff:ff:ff:ff:ff:ff

I’m connected via eth0 and LMS work perfectly , it’s a good day

Thanks a lot MichaIng

Today i start for a long bike riding but when i be back
a make the upgrade for 10.3.3 that i see if it’s good with the kernel

Have a wonderfull day :wink:

Great catch with the compatible strings! This explains why Ethernet is missing. However, regarding the WiFi crashes (sprdwl_ng), it might be worth checking if similar DTS mismatches exist for the WiFi/BT power rails or MMC bus parameters in the 6.18 patch.

On 6.12, everything works because it uses the old proven patches. On 6.18, if the sprdwl_ng driver is trying to access registers or interrupts that aren’t correctly defined in the new consolidated DTS, it would explain the Data abort / level 3 translation fault I’m seeing.

Staying on 6.12 for now, waiting for the updated 6.18 build with your fixes!

Awesome that it finally works! There were some more iterations needed to get the Ethernet driver to build. The respective patchset was quite broken, looks like there was some attempt to split larger patches into smaller ones, but stopped half way with only half of the drivers left, old patches still in place but not applied, leaving also some kernel config keys disfunctional.

The sprdwl_ng patches are in a Linux family/version independent place, so they have not changed. It is possible that a change between Linux 6.12 and 6.18 introduced new ways it can crash the system, but:

  • It caused crashes in dozens different ways before, also on Linux 6.12.
  • It does not crash my Orange Pi Zero 3 with Linux 6.18.

That driver is just incredibly crappy, so it will keep causing crashes that are hard to associate to any particular kernel changes. Like in one case it was due to a subtil module init timing change, where loading the cpufreq-dt after sprdwl_ng caused a system crash. I do not even want to think about what sprdwl_ng touched exactly that causes other entirely unrelated stable drivers to crash afterwards. I will probably stop investing as much time as I did to debug this driver, and just accept the fact that it is evil shit and should probably just stay blacklisted on any production system for security and peace of mind.

Good evening MichaIng

Back from my bike ride, I turned my OPI Zero 2W back on and tested Kodi, since LMS was working perfectly this morning.

With the latest DietPi update 10.2.3, to get Kodi to work perfectly, you have to disable video acceleration in the Kodi settings, and then everything works flawlessly.

So I updated DietPi to 10.3.3, and now everything is working fine too. LMS is working as expected, and Kodi is working the same way. I’m currently watching an ARTE concert via Ethernet. And the Wi-Fi is working too.

Regarding the expansion card with the Ethernet port, whose lights are flashing correctly, the USB ports are also working well.

Using the same script to enable I2S, I’m outputting via the 40-pin connector to my PCM5102 DAC.

Life is good.

Thank you very much, MichaIng.

Good evening MichaIng
After some long-term testing, things aren’t looking so good for the OPI Zero 2W.

Indeed, after a certain amount of time (1 hour), the OPI Zero 2W freezes.

This happens both with Ethernet and Wi-Fi.

I’m downgrading the kernel to 6.12 to verify that the issue is indeed with the kernel 6.18

That is bad. Do you see any last kernel message if you attach HDMI? I would suspect the WiFi driver, but if you enable Ethernet (and reboot), that should not be loaded anymore :thinking:. Maybe it is still in the initramfs. Verify it is blacklisted in /etc/modprobe.d/dietpi-disable-wifi.conf, then rebuilt the initramfs:

sudo update-initramfs -u

Otherwise to hopefully get logs of the crash, enable persistent system logs:

dietpi-software uninstall 103
sudo mkdir /var/log/journal
sudo reboot

systemd-journald automatically logs to /var/log/journal instead of /run/log/journal, if the prior directory exists. So if this is not a tmpfs (dietpi-ramlog uninstalled/disabled), they remain. If this is desired as long-term setup, it makes sense to limit the lifetime of the logs somewhat, e.g.

sudo mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' | sudo tee /etc/systemd/journald.conf.d/99-lifetime.conf
SystemMaxFiles=7
MaxFileSec=2day
_EOF_

which means up to 7 rotated files with 2 days of logs each => 12-14 days of logs at any time.

Hello MichaIng , i do that and tell you later when it happens

Good morning MichaIng

Just a question, how to read the journal ?
It’s just happend this morning

I be back later tonight

Have a good day

to read the full log, just run journalctl

thanks Joulinar

After upgrade tonight and reboot my OPI Zero 2w works without problem
i wait that it happend to read the journal :wink:

Hello MichaIng

It happend tonigth after two hours of listening music with LMS
see above the journal
Journalctl_22_04_2026.txt (77,5 Ko)
Not shure that we find something in it
I restart my OPI zero 2w and listen again

I just updated to 10.3 and lost my ethernet connection on opi zero 2w, i dont think the fix mentioned in the changelog works at all. Can someone guide me on how to revert back?

Good morning riri0

You use the expansion board ?

To downgrade the kernel use this command

apt install linux-{image,dtb}-current-sunxi64=26.02.0-trunk-dietpi8

If you use the official expansion board: does the WiFi interface show up at all?

ip l

Please check for kernel errors as well:

dmesg -l 0,1,2,3

The log shows only the boot session -- Boot 7937c2e113b34d968be6657313938a6e -- from after the crash. It however also shows that /var/log/journal is used (now). So if it is not the case yet, journalctl should show prior boot sessions from next reboot or crash on, separated with a line like above.

Please either answer to my comment, or mention me directly, else I do not get a forum notification :wink:.

Hello @MichaIng

The crashing issue appeared today, so I restarted and copied the log with the two boot sessions from today.

In the first part of the boot – Boot 8db3a054c0924927916fb48bed97928e – I don’t see where it crashed.
The text file is below.
Journalctl_25_04_2026.txt (156,2 Ko)