DP83848K: Ethernet is not working in the U-boot while migration

Hi Jamal,

Could you please share the Uboot driver and PHY DTS config you are using?

Thank you,
Evan

Hi Evan,

Attached the patch file we had added in the U-boot source Code.

Etherenet NODE configured in DTSI file 

&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet2>;
phy-mode = "rmii";
status = "okay";
phy-handle = <&ethphy0>;
iw_fec_prop;
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@4 {
reg = <4>;
};
};
};


Kindly let me know if you need any further clarification.

diff -Naur A/drivers/net/fec_mxc.c B/drivers/net/fec_mxc.c
--- A/drivers/net/fec_mxc.c     2025-06-30 10:33:04.000000000 +0530
+++ B/drivers/net/fec_mxc.c     2025-07-04 09:54:50.601765124 +0530
@@ -37,6 +37,8 @@

 DECLARE_GLOBAL_DATA_PTR;

+bool iw_fec_prop = false;
+
 /*
  * Timeout the transfer after 5 mS. This is usually a bit more, since
  * the code in the tightloops this timeout is used in adds some overhead.
@@ -1237,6 +1239,16 @@
        uint32_t start;
        int ret;

+       if (dev_read_bool(dev, "iw-fec-prop"))
+       {
+               iw_fec_prop = true;
+       }
+       else
+       {
+               // Do Nothing
+       }
+
+
        ret = board_interface_eth_init(dev, pdata->phy_interface);
        if (ret)
                return ret;
diff -Naur A/drivers/net/phy/dp83848.c B/drivers/net/phy/dp83848.c
--- A/drivers/net/phy/dp83848.c 1970-01-01 05:30:00.000000000 +0530
+++ B/drivers/net/phy/dp83848.c 2025-07-04 09:54:50.601765124 +0530
@@ -0,0 +1,30 @@
+/*
+ * Micrel PHY drivers
+ *
+ * SPDX-License-Identifier:    GPL-2.0+
+ *
+ * Copyright 2010-2011 Freescale Semiconductor, Inc.
+ * author Andy Fleming
+ * (C) 2012 NetModule AG, David Andrey, added KSZ9031
+ */
+#include <config.h>
+#include <common.h>
+#include <micrel.h>
+#include <phy.h>
+
+static struct phy_driver DP83848_driver = {
+       .name = "TI DP83848",
+       .uid = 0x20005C90,
+       .mask = 0xfffffff0,
+       .features = PHY_BASIC_FEATURES,
+       .config = &genphy_config,
+       .startup = &genphy_startup,
+       .shutdown = &genphy_shutdown,
+};
+
+int phy_dp83848_init(void)
+{
+       phy_register(&DP83848_driver);
+
+       return 0;
+}
diff -Naur A/drivers/net/phy/Kconfig B/drivers/net/phy/Kconfig
--- A/drivers/net/phy/Kconfig   2025-06-30 10:33:04.000000000 +0530
+++ B/drivers/net/phy/Kconfig   2025-07-04 09:54:50.601765124 +0530
@@ -426,6 +426,12 @@
 config PHY_NCSI
        bool "NC-SI based PHY"

+config PHY_DP83848
+       tristate "PHY for TI DP83848"
+       depends on MX6ULL_IWG26I
+       help
+         This is the driver for the TI DP83848KSQ/NOPB PHYs.
+
 endif #PHYLIB

 config FSL_MEMAC
diff -Naur A/drivers/net/phy/Makefile B/drivers/net/phy/Makefile
--- A/drivers/net/phy/Makefile  2025-06-30 10:33:04.000000000 +0530
+++ B/drivers/net/phy/Makefile  2025-07-04 09:54:50.601765124 +0530
@@ -43,3 +43,4 @@
 obj-$(CONFIG_PHY_MSCC) += mscc.o
 obj-$(CONFIG_PHY_FIXED) += fixed.o
 obj-$(CONFIG_PHY_NCSI) += ncsi.o
+obj-$(CONFIG_PHY_DP83848) += dp83848.o

Hi Jamal,

I was not able to find any differences in Yocto 4 vs. 5 that would impact the initialization probe for Ethernet.

Was there any hardware change in the setup, specifically related to address strapping and SMI pins?

PHYAD0 (COL)
PHYAD1 (RXD_0)
PHYAD2 (RXD_1)
PHYAD3 (RXD_2)
PHYAD4 (RXD_3)
MDC/MDIO

Assuming hardware is equivalent with the same strapped PHY address, could you please share a capture of MDC/MDIO signals in passing vs. failing case? This will help confirm if system is properly attempting to identify 848 at same address.

Thank you,
Evan

Hi Evan,

There is no change in the hardware. We will proceed with the waveform capture and share the updates with you.

Regards,
Jamal Deen

Hi Evan,

In this waveform, the yellow line corresponds to YOCTO 4.0, while the blue line corresponds to YOCTO 5.0. The capture was taken from the U-Boot boot log.

Please let me know if you need any additional details regarding this. Uploded the image in the below link.

iwaveglobal-my.sharepoint.com/.../EqspVI273dNMtMGWQNgBTNsBpztsQfotZEQ5MZtUuduLyQ

Regards,
Jamal Deen

Hi Jamal,

Thank you for sharing. It looks like the turnaround on MDIO is not occurring in Yocto 5 case, which suggests PHY is not alive, or strapped address has changed. Is it possible to measure the supply pins and input clock of the PHY? 

Assuming supplies and input clock are valid, it's possible that the SoC behavior relative to driving MII/RMII pins is changing between Yocto 4 vs. 5. In this case, SoC could affect strapped address on startup. There are two ways to verify, please try whichever is more convenient:

1) Measure voltage on PHYAD0 - 4 pins during power to confirm which address is strapped. Can compare between Yocto 4 vs. 5 cases.

2) Iterate DTS PHY address setting to find the unintended address:

ethphy0: ethernet-phy@4 {
reg = <4>; // change to 1,2,3, ... and boot in each case to see if identified

Thank you,
Evan

Hi Evan,

We have tried changing the PHYADDR to 1, 2, and 3, but the issue still persists. As mentioned in point 1, we will measure the voltage levels on the PHYAD0–PHYAD4 pins and share the readings with you.

Please let us know if you need any additional information or clarification.

Regards,
Jamal Deen

Hi Evan,

Could you please share your inputs to help identify and resolve the issue?

Regards,
Jamal Deen

Hi Jamal,

PHY address values strap from 0 to 31, so the unintended value may be above range [0-4]. Iterating through DTS addresses 0-31 or measuring strap pin voltage on power will help confirm.

Thank you,
Evan

Hi Evan,

We have tested all values from 0 to 31, but the issue persists in every case.

Regards,
Jamal Deen

Thanks for confirming Jamal.

This result suggests the PHY is not powered, or the input clock on X1 is not compliant. Is the PHY's input clock or power dependent on SoC? Sharing schematic may help clarify this as well.

Could you please measure the voltage across RBIAS resistor while powered? This should measure close to 1V if the PHY is alive. For X1, please confirm 25M +/- 50 ppm is measured here.

Thank you,
Evan

Hi Evan,

We are currently working on this and will provide an update on the status tomorrow.

Regards,
Jamal Deen