Skip to content

st,stm32-ethernet silently selects wrong MAC model on STM32H5 (falls through to default instead of DWC EQOS) #13

Description

@devitwise

Verified against: dts2repl commit c2aae3dd278f318900ba4af8cab7ad338b50e0df (current main as of writing).

Devicetree compatible: st,stm32-ethernet

Board/SoC: STM32H5 (board stm32h5f5j_dk), Zephyr v4.4.1. Zephyr's dts/arm/st/h5/stm32h563.dtsi declares the ethernet node as:

compatible = "st,stm32h5-ethernet", "st,stm32h7-ethernet", "st,stm32-ethernet";

What is emitted: The wrong model. In dts2repl/models.json (currently lines 551-552):

"st,stm32-ethernet": {  "st,stm32h7": { "type": "Network.SynopsysDWCEthernetQualityOfService", "systemClockFrequency": 50000000 },
                        "_": "Network.SynopsysEthernetMAC" },

The nested key (st,stm32h7) is matched by renode_model_overlay() in dts2repl/dts2repl.py against the overlays set built by get_overlays(), which only collects the compatible (and model) strings of the root / node and the /soc node — it never looks at the peripheral node's own compatible list. STM32H5's SoC-level compatible does not contain st,stm32h7, so the match falls through to the "_" default and Network.SynopsysEthernetMAC is emitted. This is silent: a model IS produced, the platform loads without error, but the network interface never comes up in the guest, because the H5's Ethernet MAC is actually the same Synopsys DWC EQOS IP as H7's and needs Network.SynopsysDWCEthernetQualityOfService.

What should be emitted: Network.SynopsysDWCEthernetQualityOfService for STM32H5 as well.

Suggested fix: Match against the ethernet node's own compatible list (which already lists st,stm32h7-ethernet for H5, per the dtsi snippet above), not only against the SoC/platform compatible strings; alternatively add an explicit st,stm32h5 key to the nested mapping.

Also observed: dts2repl emits no PHY node for the ethernet controller at all. Zephyr's Ethernet PHY driver (phy_mii) needs a Network.EthernetPhysicalLayer attached to the MAC to find a link; without one, MDIO reads never resolve even if the MAC model is corrected.

Evidence this is the actual fix, from testing a hand-written overlay against real Zephyr networking on STM32H5 in Renode:

mac: Network.SynopsysDWCEthernetQualityOfService @ {
    sysbus 0x40028000;
    sysbus new Bus.BusMultiRegistration { address: 0x40028C00; size: 0x200; region: "mtl" };
    sysbus new Bus.BusMultiRegistration { address: 0x40029000; size: 0x200; region: "dma" }
    }
    systemClockFrequency: 50000000
    dmaBusWidth: BusWidth.Bits32
    -> nvic0@106
phy: Network.EthernetPhysicalLayer @ mac 0
    BasicControl: 0x3100
    BasicStatus: 0x782D
    Id1: 0x0007
    Id2: 0xC130

With this in place, the guest's PHY driver resolves the link correctly:

<inf> phy_mii: PHY (0) ID 7C130
<inf> phy_mii: PHY (0) Link speed 10 Mb, half duplex

With the current dts2repl output (Network.SynopsysEthernetMAC + no PHY), none of this happens and the interface is silently non-functional.

Renode version used to verify: 1.16.1+20260623git3f5a91013.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions