Hi,
I'm currently integrating the DP83825 Ethernet IC with my i.MX7DSABRESD system. Previously, the board functioned perfectly with the RTL8211 IC. Due to supply chain disruptions, we opted to switch Ethernet ICs. However, I've encountered difficulties getting the DP83825 to work despite my troubleshooting efforts.
Kernel version is; Linux imx7dsabresd 5.4.70-2.3.11+gb34a9c9644c1
Related part of my device tree;
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>,
<&clks IMX7D_PLL_ENET_MAIN_50M_CLK>,
<&clks IMX7D_ENET1_REF_ROOT_DIV>;
clock-names = "ipg", "ahb", "ptp", "enet_clk_ref","enet_out";
assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <100000000>;
phy-mode = "rmii";
phy-handle = <ðphy0>;
fsl,magic-packet;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};
};
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog>;
imx7d-sdb {
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO10__ENET1_MDIO 0x3
MX7D_PAD_GPIO1_IO11__ENET1_MDC 0x3
MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1
MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1
MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1
MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER 0x1
MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1
MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
MX7D_PAD_ENET1_TX_CLK__CCM_ENET_REF_CLK1 0x40000001
>;
};
….
Pin connections are as this;
Dmesg output is;
[ 1.243155] fec 30be0000.ethernet: Invalid MAC address: 00:00:00:00:00:00
[ 1.249973] fec 30be0000.ethernet: Using random MAC address: 56:47:52:60:e4:f0
[ 1.258273] libphy: fec_enet_mii_bus: probed
[ 1.264233] fec 30be0000.ethernet eth0: registered PHC device 0
[ 8.445135] Generic PHY 30be0000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)
ifconfig and ethtool outputs
Since the speed and duplex settings are currently unknown, it suggests there might be a problem with the driver.
I can see MDIO and MDCLK at 2.5 MHz, and ETH_REF Clock at 50 MHz with an oscilloscope. However, there's no activity on TXD[0,1], RXD[0,1], TX_EN, RX_CTL, or RXC pins. All of these pins are low.
Do you have any suggestions on how to troubleshoot this issue?
Solved! Go to Solution.
I finally resolved the problem. It turned out to be a hardware problem. I had to connect the reference clock to GPIO1_12 to fix it. Let me show you the specific changes I made – perhaps they might be helpful for others working with RMII..
Here are the changes I made in u-boot;
in include/configs/mx7dsabresd.h file
#define CONFIG_FEC_XCV_TYPE RMII
in board/freescale/mx7dsabresd/mx7dsabresd.c file
static iomux_v3_cfg_t const fec1_pads[] = {
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_GPIO1_IO10__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
MX7D_PAD_GPIO1_IO11__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
};
...
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *const iomuxc_gpr_regs
= (struct iomuxc_gpr_base_regs *) IOMUXC_GPR_BASE_ADDR;
int ret;
clrsetbits_le32(&iomuxc_gpr_regs->gpr[1],
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
ret = set_clk_enet(ENET_50MHz);
if (ret)
return ret;
return 0;
}
int board_phy_config(struct phy_device *phydev)
{
phy_write(phydev, MDIO_DEVAD_NONE, 0x1f, 0x4000); //software reset
if (phydev->drv->config)
phydev->drv->config(phydev);
return 0;
}
After these change, in u-boot we can see "alive" message for a ping;
Here are the changes I made in kernel;
in /tmp/work-shared/imx7dsabresd/kernel-source/arch/arm/boot/dts/imx7d-sdb.dts file;
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>,
<&clks IMX7D_PLL_ENET_MAIN_50M_CLK>,
<&clks IMX7D_ENET1_REF_ROOT_DIV>;
clock-names = "ipg", "ahb", "ptp", "enet_clk_ref","no_enet_out";
assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <100000000>;
phy-mode = "rmii";
phy-handle = <ðphy0>;
fsl,magic-packet;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};
};
...
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO10__ENET1_MDIO 0x3
MX7D_PAD_GPIO1_IO11__ENET1_MDC 0x3
MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1
MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1
MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1
MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER 0x1
MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1
MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 0x1
>;
};
In addition, I had to modify some code related to GPIO_1_12 because other peripherals, such as SPI4, were already using this pin.
I finally resolved the problem. It turned out to be a hardware problem. I had to connect the reference clock to GPIO1_12 to fix it. Let me show you the specific changes I made – perhaps they might be helpful for others working with RMII..
Here are the changes I made in u-boot;
in include/configs/mx7dsabresd.h file
#define CONFIG_FEC_XCV_TYPE RMII
in board/freescale/mx7dsabresd/mx7dsabresd.c file
static iomux_v3_cfg_t const fec1_pads[] = {
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX7D_PAD_GPIO1_IO10__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
MX7D_PAD_GPIO1_IO11__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
};
...
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *const iomuxc_gpr_regs
= (struct iomuxc_gpr_base_regs *) IOMUXC_GPR_BASE_ADDR;
int ret;
clrsetbits_le32(&iomuxc_gpr_regs->gpr[1],
(IOMUXC_GPR_GPR1_GPR_ENET1_TX_CLK_SEL_MASK |
IOMUXC_GPR_GPR1_GPR_ENET1_CLK_DIR_MASK), 0);
ret = set_clk_enet(ENET_50MHz);
if (ret)
return ret;
return 0;
}
int board_phy_config(struct phy_device *phydev)
{
phy_write(phydev, MDIO_DEVAD_NONE, 0x1f, 0x4000); //software reset
if (phydev->drv->config)
phydev->drv->config(phydev);
return 0;
}
After these change, in u-boot we can see "alive" message for a ping;
Here are the changes I made in kernel;
in /tmp/work-shared/imx7dsabresd/kernel-source/arch/arm/boot/dts/imx7d-sdb.dts file;
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET_AXI_ROOT_CLK>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>,
<&clks IMX7D_PLL_ENET_MAIN_50M_CLK>,
<&clks IMX7D_ENET1_REF_ROOT_DIV>;
clock-names = "ipg", "ahb", "ptp", "enet_clk_ref","no_enet_out";
assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
<&clks IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <100000000>;
phy-mode = "rmii";
phy-handle = <ðphy0>;
fsl,magic-packet;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};
};
...
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO10__ENET1_MDIO 0x3
MX7D_PAD_GPIO1_IO11__ENET1_MDC 0x3
MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x1
MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x1
MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x1
MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER 0x1
MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x1
MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x1
MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x1
MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 0x1
>;
};
In addition, I had to modify some code related to GPIO_1_12 because other peripherals, such as SPI4, were already using this pin.
Hi,
Thank you for your interest in NXP Semiconductor products,
Is there any logs of link is not ready missing?
There probably is not a link set between MAC and PHY, could you provide the dump for mdio in u-boot to confirm this?
Is this issue persistent in u-boot? Can you ping in u-boot?
Regards
Thank you for your reply Josephlinares.
My u-boot version is;
I set ip address 192.168.1.177
when I ping, I get this;
After writing
mdio write 0x1F 0x4000
which is software reset. I get this message in kernel space;
and "ethtool eth0" shows me
Speed: 100 MB/s
Duplex: Full
If I don't write "mdio write 0x1F 0x4000" on u-boot I see
Speed: Unknown!
Duplex: Unknown!
link detected : no
here. In u-boot, I have changed #define CONFIG_FEC_XCV_TYPE RGMII
to RMII in ./include/configs/mx7dsabresd.h .
Also, in ./board/freescale/mx7dsabresd/mx7dsabresd.c I have changed
ret = set_clk_enet(ENET_125MHz)
to ENET_50MHZ
Still I cannot get ping ..
The question is from the phy not the i.MX.
You need to ask phy vendor TI for phy fixup or check the linux source code if there is existing phy fixup for DP83825.
If just "mdio write 0x1F 0x4000", you can write down the phy fixup.
phy_register_fixup_for_uid(PHY_ID_DP83825, DP83825_PHY_ID_MASK,
dp83825_phy_fixup)
I checked the device tree, TI has binding guide for 83822, but it should be the same for 83825
ti,rmii-mode: description: | If present, select the RMII operation mode. Two modes are available: - RMII master, where the PHY outputs a 50MHz reference clock which can be connected to the MAC. - RMII slave, where the PHY expects a 50MHz reference clock input shared with the MAC. The RMII operation mode can also be configured by its straps. If the strap pin is not set correctly or not set at all, then this can be used to configure it. $ref: /schemas/types.yaml#/definitions/string enum: - master - slave required:
Thank you for your help opedis. I appreciate your suggestion (phy_register_fixup_for_uid). I think, I have to try it work in u-boot first. u-boot is less complicated than kernel.