The result
root@DietPi:~# modprobe dwmac-sun8i
root@DietPi:~# lsmod | grep dwmac_sun8i
root@DietPi:~#
I try 'G_DEV_TEST_FIRMWARE
`
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
. 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 ![]()
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:
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
. 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 ![]()
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
.
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)