Issue with ethernet in u-boot


we have a carrier-board with 2 ethernet interfaces: one is directly connected to the SOM and the other uses the RGMII interface with a Microchip Ethernet Tranceiver (KSZ9131RNXI) on our board.
We want to use one network interface to load a kernel in u-boot via TFTP but we get an error:

ethernet@30bf0000 Waiting for PHY auto negotiation to complete… TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@30be0000 Waiting for PHY auto negotiation to complete… TIMEOUT !
Could not initialize PHY ethernet@30be0000

I found out that the SOM’s pre-installed Toradex Linux image uses a u-boot device-tree where both mdio interfaces for fec and eqos have the same reg = 7 parameter.
In the toradex-linux device-tree file (imx8mp-verdin.dtsi) the reg parameter is different for both interfaces: fec->mdio: reg=3, eqos->mdio: reg=7.

When changing the u-boot device tree to the same values as in the Linux dev-tree the error disappears. But somehow the ethernet ports still seem to have an issue. When unplugging the cable from one interface and connecting to the other a connection cannot be established any more.

I’m wondering if the setup with the reg parameter in u-boot is just wrong? And is changing the reg number to 3 and 7 ok for using two interfaces? What is the “reg” number 3 and 7 referencing at all and where is this number defined?

Here is the dev-tree from u-boot:

We are using the following SOM:
Toradex Verdin iMX8M Plus Quad 2GB V1.0B, Serial# 06849375

BuildInfo at bootup:

  • ATF 0a236bd
  • U-Boot 2020.04-0+git.a685d2827d97

BR Ralph

Hi @Ralph !

Can you please share your schematics? So we can review your carrier board?
If you prefer, you can share it via email: Please refer to this thread on the email.

About this, we checked the imx8mp-verdin.dtsi and both reg values are 7.

You can make a search inside the Kernel’s Documentation to find it:

$ cd ~/linux-toradex/Documentation
$ git branch
$ grep -rniP "ethernet-phy-ieee802.3-c22"
devicetree/bindings/net/brcm,unimac-mdio.txt:40:                compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/hisilicon-hip04-net.txt:48:                     compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/hisilicon-hip04-net.txt:54:                     compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/snps,dwc-qos-ethernet.txt:163:                  compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/mdio-mux-meson-g12a.txt:42:                                  "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/ibm,emac.txt:158:                               compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/brcm,bcmgenet.txt:74:                   compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/brcm,bcmgenet.txt:121:                  compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/nixge.txt:87:                           compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/fsl-fec.txt:102:                        compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/aspeed,ast2600-mdio.yaml:42:                    compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/socionext-netsec.txt:51:                                compatible = "ethernet-phy-ieee802.3-c22";
devicetree/bindings/net/ethernet-phy.yaml:32:      - const: ethernet-phy-ieee802.3-c22
 $ cat devicetree/bindings/net/ethernet-phy.yaml | grep -A5 "reg:"
    minimum: 0
    maximum: 31
      The ID number for the PHY.

Best regards,

Hi Henrique,

We are currently on an older commit version where reg=3 was set for the fec mdio → linked here.
Why was this changed from 3 to 7?
Anyhow, I currently try to upgrade to the release 2022.02 for all meta layers in order to have the latest changes.

But I’m still confused with the address of the MDIOs. The PHY chip which is on the SOM module (named eqos->mdio in the dev-tree) has address 7, right? This is fixed in the schematics on the SOM, as far as I understand.
The fec interface needs a PHY chip on the carrier board which has it’s own address defined on the carrier board schematic. Why is the address 7 (reg=7) defined in the devtree imx8mp-verdin.dtsi at all when this needs to be done on the carrier board?

I had a look on our carrier board schematic and it seems to have address 7. Is this even possible to have eqos->mdio with address 7 and fec->mdio with address 7 too?

Regards, Ralph

Hi @Ralph !

To be fair, I am not aware of the motivation behind the reg change (from 3 to 7).

Linux (the drivers) needs to know the address of the devices and the device tree is the place to inform it. You will see the same pattern, for example, with I2C devices, where we also need to fill in their address in their device tree nodes.

On Verdin iMX8M Plus the PHYs are connected to different MDIO interfaces, so there is no issue at all to use the same address on both PHYs: there will be no collision.

And, just to clarify: were you able to solve the issue?

Best regards,

Hi @henrique.tx,

thanks for your clarification. I was just confused about the change with the addresses. We also had an hw issue with the strapping resistors which are defining the address on the phy. We fixed this issue and set both addresses to 7 and it works fine now.

BR Ralph

Hi @Ralph!

Great to know that your issue was solved!

Please mark the appropriate message as the solution :slight_smile:

Best regards,