Unable to reset MAC in IMX8MP

[Ben10]

Hi we are facing a problem in our board which was developed based on the IMX8MP board. In our board we are using DP83867 as the ethernet phy and we are getting a message as " unable to reset ENET_QOS". What should I do??

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

->I have a few queries to ask that I've mentioned below.

->Please share the dmesg logs and the console logs(the command you give).
->Please share the connection diagram you made.
->Please share the Linux BSP version that you are using.

->It will help to debug further.

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Actually it is working in linux , while the problem is with windows 10 IOT. We got the windows 10 IOT source code for NXP IMX8MP board from NXP. The NXP board uses RTL8211F as the ethernet phy but in our board we use DP83867 as the ethernet phy. But the pins connections are the same.  So when I run the driver I get a message as " Unable to reset Enet_QoS" and also all the ethernet phy register data that  we read comes as 1. I am not asking help with windows 10 IOT development, I need to know whether there was any specific initialisation required maybe clock or something.

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

->Please make sure to check the pad settings for enet_qos if one is using it on rmii interface or rgmii interface.
->Please make sure to check the voltage on the interface, whether there is an hw issue or not.
->Please also make sure to check the clock settings for enet_qos
->Please make sure to check that the RMII reference clock (50 MHz) can be fed to IP from an external source or internally from PLL on SoC.

One can refer to section 11.7 Ethernet Quality Of Service (ENET_QOS) in RM for more details.
https://www.nxp.com/webapp/Download?colCode=IMX8MPRM

I hope it helps!

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Hi @Dhruvit 

Thanks for the reply.

Our board is developed based on NXP IMX8MP. So there are only a few changes. Our board has two ethernet ports same like the NXP board. But the difference is we use DP83867 as the ethernet phy while NXP uses RTL8211F as the ethernet phy and in NXP board both the ethernet phys share the same MDIO bus while in our board the phys use a separate bus. All the pins from the phy in our board has been connected to the SOC in the same way as the NXP board. There are no changes. The ethernet phys used in both the boards also are almost similar. I think if here were any design issues with our board then it would not have worked with linux. In linux we only added few things in the dts file and it worked also the pin muxing is the same in both the boards.

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

I'm afraid that there are a few ethernet drivers that are supported that I've mentioned below down.

Networking drivers
ENET => All i.MX
• i.MX 8 supports Atheros AR8031 PHY with 10/100/1000 bps mode.
ENET QOS => i.MX 8M Plus
• ENET QOS is available on i.MX 8M Plus.
• RTL8211 PHY is supported.
PCIe  => All i.MX
• i.MX 8 supports -> M.2 interface.

Please read this release notes for more details.
https://www.nxp.com/docs/en/release-note/IMXWNR.pdf

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Hi @Dhruvit 

In NXP IMX8MP both the ethernet phys share a common MDIO/MDC bus, but in our board ,the  two phys don't share the MDIO/MDC bus and have separate buses, so in that what are the changes that we  might need to do??

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

In our board the two ethernet phys don't share the same mdio bus unlike the NXP board in which both the phys share a common bus, so could that cause a problem in accessing the MDIO of the ethernet phys??
->Yes, it could be possible that the two Ethernet PHYs not sharing the same MDIO can cause the problem of "unable to reset enet_qos".
->The ENET_QOS registers are located in the MDIO space of the Ethernet controller. (Please check the datasheet for more details) If the two Ethernet PHYs are not sharing the same MDIO, then the ENET_QOS registers for each Ethernet phy will be located in different MDIO addresses. This can cause the problem "unable to reset enet_qos" It's like accessing those registers from 2 diff locations at a time.

->Please make sure that the two Ethernet PHYs share the same MDIO.

->One can also refer to section 11.6.2.17 PHY management interface in the RM for more details.
https://www.nxp.com/webapp/Download?colCode=IMX8MPRM

I hope this information helps!

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Hi @Dhruvit 

Thanks for replying

In our board the MDIO/MDC of EnetQoS is connected to the MDIO/MDC of the ethernet controller, while the MDIO/MDC of the other Enet  is not connected to the MDIO/MDC of the ethernet controller rather it is connected to "i.MX8MP - SAI" interface. But the enet port works in linux but not in windows.

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

Please find the Internal Windows team response below.

I would like to correct the statement above - our EVK board does not use one MDIO peripheral for both Phys, interested resistors R424 and R425 are marked as DNP (Do not populate). So this should not be the issue.
 
I have got a piece of information about QoS behavior on i.MX8MP expects a clock signal from the RXC pin. They could be able to provide a reset.

So, try to check the PHYs RXC output if it is generating or not. If not so, try to connect the ethernet cable. Or, some of the PHYs can enable clock output by register setting.”

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Hi @Dhruvit 

Thanks for the reply

In our board we are also not able to access the ethernet phy registers because when I read the phy registers I get all the bits of Enet and EnetQoS phy registers as 1. So, I am not able to control the phy through registers.

[Dhruvit]

Hi @Ben10,

I hope you are doing well.

Could you please provide a schematic for further debugging?

Thanks & Regards,
Dhruvit Vasavada

[Ben10]

Hi @Dhruvit 

I am sorry, I won't be able to provide you with the schematic but I can tell you how any pin from the soc is connected to the ethernet phy. All the pins in our board from the ethernet phy are connected to the IMX8MP soc just like how it is connected in the NXP IMX8MP board.

[Ben10]

Hi @Dhruvit 

In our board the two ethernet phys don't share the same mdio bus unlike the NXP board in which both the phys share a common bus, so could that cause a problem in accessing the MDIO of the ethernet phys??

[Ben10]

Hi @Dhruvit 

When I probe the MDC pin after booting the windows I  am not getting the clock signal but if I try to probe the MDC pin while restarting the windows I get clock signal of 2.5 MHz. With 2.5MHz clock signal ethernet works in ubuntu. So, is there a way to fix this in windows??

The image below is after booting into windows.

The image below is while restarting the board in windows

[Frantisek_Prochaska]

Hi @Ben,
signal traces on your image doesn't look as expected. I would expect couple burst of data looking similar to I2C.
See https://support.saleae.com/tutorials/learning-portal/learning-resources/management-data-input-output... .

Here's couple of ideas based on discussion:
1. The electrical connection should be correct, so there should be a little need to change routing in board init.c.
2. From my understanding the configuration of phy is done in ASL file. Windows driver reads list of actions and performs couple of writes into PHY.
3. There's chance that PHY has been setup by U-Boot and BoardInit.c just mimics that. Even if possibly incomplete, It still must be correct because it will break the configuration.
I wouldn't fiddle with routing much as not to break the routing before having chance to debug ethernet driver itself.
4. You can also record and compare MDIO traces of both MDIO signals and the enable/chip select and compare the traces for various operating systems and boards - Linux, Windows on NXP EVK and Linux and Windows on you new board.
5. You have mentioned there's no way to provide us you schematic. Maybe you can post Devicetree patch required to get your PHY working.

[Ben10]

Hi @Frantisek_Prochaska 

Thanks for the reply

After probing the clock signals in windows, I also probed the power signals of the ethernet phy and I observed that the phy wasn't getting any power from the power supply. It was because the power supply was given to the phy through a LDO which was controlled by an I2C GPIO expander. So, I2C GPIO is connected to the SOC through I2C6, so I tried to read a register from the I2C GPIO expander through I2C6 but got a message that "failed to setup I2C controller". So, what could possibly be the reason??

[Frantisek_Prochaska]

Hi @Ben10,
First thought was to have a look into Boardinit.c.
Search for Pca6416I2cConfig for inspiration. You shall be able to configure your expander too.

Make sure to enable clocks and route pins for your I2C in I2cInit() otherwise you get bus errors.

Good luck!

[Ben10]

Hi @Frantisek_Prochaska 

Thanks for the reply

I have done everything from pin muxing and initializing the clock, but I couldn't get the bus to work. I get error message that the I2C bus is idle.

[Frantisek_Prochaska]

This one?
```
DEBUG ((DEBUG_ERROR, "%a: Controller remains idle\n", __FUNCTION__));
```
You might have made a mistake when routing the I2C signals to pins. Also check if you need on SoC Pull up resistors.
Finding right macros for pins is never easy. You have the Linux DeviceTree configuration for your i2c so you can compare values.

[Ben10]

Hi @Frantisek_Prochaska 

Thanks for the reply 

The ethernet in our board works fine in ubuntu, so which means there's no hardware or design issues. 

I have done the following pin muxing and clock settings in i2cinit() function in the boardinit.c file for I2C6:

IOMUXC_SW_MUX_CTL_PAD_SAI5_RXFS = IOMUXC_MUX_ALT3 | IOMUXC_MUX_SION_ENABLED; //I2C6 IOMUXC_SW_MUX_CTL_PAD_SAI5_RXC = IOMUXC_MUX_ALT3 | IOMUXC_MUX_SION_ENABLED; //I2C6 IOMUXC_SW_PAD_CTL_PAD_SAI5_RXFS = I2C_PAD_CTRL; //I2C6 IOMUXC_SW_PAD_CTL_PAD_SAI5_RXC = I2C_PAD_CTRL; //I2C6

CCM_CCGR_I2C5 = 0x00; //I2C6

CCM_TARGET_ROOT_I2C6 = CCM_TARGET_ROOT_MUX(0) | CCM_TARGET_ROOT_PRE_PODF(0) | CCM_TARGET_ROOT_POST_PODF(0) | CCM_TARGET_ROOT_ENABLE_MASK; //I2C6

CCM_CCGR_I2C6 = 0x03; //I2C6