So the Ethernet adapter is not detected at all, and does not throw any kernel errors either, as if the node were not enabled. But is it, right?
cat /proc/device-tree/soc/ethernet@5030000/status; echo
I compared the two patches, and the related MAC and PHY nodes are identical. Also in mainline Linux there were no related changes. The new patch misses a larger number of PWM, HDMI, and other nodes, but this does not look related, more like a reasonable cleanup to reduce the patch to locally tested features. And some other changes were done due to some dropped restructure, like the dedicated regulators dtsi patched into Linux 6.12: build/patch/kernel/archive/sunxi-6.12/patches.armbian/arm64-dts-add-sun50i-h618-cpu-dvfs.dtsi.patch at ef5966af47bda682e68555c120df3429fa253bae · armbian/build · GitHub
Most likely assumption for now is that no driver is matches. Can you check again for any Ethernet related kernel messages:
dmesg | grep -E 'eth|mac|phy|5030000'
… Copilot agrees with my assumption, going more into detail. It tends to generally agree more often than it should, but let me verify with emac0, worth to test that on emac1:
Your assumption is correct. Here’s the full picture:
Linux 6.12 (Armbian patch): allwinner,sunxi-gmac
The 6.12 Armbian patch replaces the mainline compatible with a BSP/vendor driver string:
compatible = "allwinner,sunxi-gmac";
This matches the out-of-tree sunxi-gmac driver carried in the Armbian 6.12 kernel tree — a legacy Allwinner vendor driver, not the mainline dwmac-sun8i stmmac glue layer.
Linux 6.18 (Armbian patch): allwinner,sun50i-h616-emac — no driver match
The 6.18 patch uses:
compatible = "allwinner,sun50i-h616-emac";
But the mainline dwmac-sun8i.c match table (as of current mainline, which 6.18 tracks) is:
static const struct of_device_id sun8i_dwmac_match[] = {
{ .compatible = "allwinner,sun8i-h3-emac", .data = &emac_variant_h3 },
{ .compatible = "allwinner,sun8i-v3s-emac", .data = &emac_variant_v3s },
{ .compatible = "allwinner,sun8i-a83t-emac", .data = &emac_variant_a83t },
{ .compatible = "allwinner,sun8i-r40-gmac", .data = &emac_variant_r40 },
{ .compatible = "allwinner,sun50i-a64-emac", .data = &emac_variant_a64 },
{ .compatible = "allwinner,sun50i-h6-emac", .data = &emac_variant_h6 },
{ }
};
allwinner,sun50i-h616-emac is absent — hence no driver binds, no interface appears, and no errors are logged (the node is simply ignored).
Why emac0 works but emac1 doesn’t
Interestingly, emac0 in the upstream sun50i-h616.dtsi already handles this correctly by providing a fallback compatible:
compatible = "allwinner,sun50i-h616-emac0",
"allwinner,sun50i-a64-emac"; ← this fallback IS in the match table
The emac1 patch for 6.18 has no such fallback.
Fix
The 6.18 patch needs either:
-
A fallback compatible string in the DTS node (the simplest fix, matching how emac0 is done):
- compatible = "allwinner,sun50i-h616-emac";
+ compatible = "allwinner,sun50i-h616-emac",
+ "allwinner,sun50i-h6-emac";
The emac_variant_h6 config is appropriate for H616 EMAC1 — it has soc_has_internal_phy = false (the PHY is on the external AC200 chip, same situation as H6), and supports MII/RMII/RGMII with delay tuning.
-
Or add allwinner,sun50i-h616-emac to dwmac-sun8i.c’s match table upstream — the proper long-term fix, but requires a kernel patch submission.
Option 1 is the right Armbian-local fix for the 6.18 patch file.
@Totof before I adjust the patch, can you verify by loading the respective driver manually?
lsmod # verify that dwmac-sun8i is not loaded.
modprobe dwmac-sun8i
ip l
EDIT: I just see that the sunxi-gmac driver is still patched into the kernel: https://github.com/armbian/build/blob/ef5966af47bda682e68555c120df3429fa253bae/patch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-sun8i-add-h618-emac.patch
But it is not enabled anymore in the Linux 6.18 kernel config. So if the mainline driver does not work, or does not work well, we can instead test to enable CONFIG_SUNXI_GMAC=m, like it was the case with Linux 6.12. But I’d prefer a mainline driver over a patched driver, and whether it actually compiles on Linux 6.18 is also uncertain, since obviously this has never been tested.
. Ah those are still separate patches:
. Something to test when enabling WiFi:
