iMX6 Dual: Configuring RGMII pins causes SD3 pins to stop working?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6 Dual: Configuring RGMII pins causes SD3 pins to stop working?

Jump to solution
827 Views
jwatts
Contributor I

We have a custom board design based on the iMX6 Dual (MCIMX6D6AVT10AD), and I've reached a perplexing issue while trying to bring up the RGMII interface. Configuring any of the following pins causes some of the SD3 pins to no longer function properly:

                MX6QDL_PAD_RGMII_TD0__RGMII_TD0      

                MX6QDL_PAD_RGMII_TD1__RGMII_TD1      

                MX6QDL_PAD_RGMII_TD2__RGMII_TD2      

                MX6QDL_PAD_RGMII_RXC__RGMII_RXC      

                MX6QDL_PAD_RGMII_RD3__RGMII_RD3      

                MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL

Since my root filesystem is on an SD card plugged in to SD3, it's much more difficult to debug this issue, although I do have a JTAG probe to read registers if necessary.

I've looked through the TRM a fair bit, but the only common thread I can find between the RGMII pins and the SD3 pins is that they originate from the same clock source. Does any one else have any further insight in to what might be causing this?

Also, I noticed that the Wandboard Dual uses both these interfaces in pretty much the same exact fashion that I would like, but uses the iMX6 DualLite: Is there any appreciable difference between the SOC I'm using the DualLite?

Other details that might be relevant:

  • Linux kernel with only board specific changes based on imx_3.10.17_1.0.0_ga
  • Barebox boot loader based upon v2015.06.0
  • Using 4-bit SDHC on SD3
Labels (2)
0 Kudos
1 Solution
648 Views
igorpadykov
NXP Employee
NXP Employee

Hi Josh

one can printf iomux registers for SD3 pins. As for clocks

in general your assumption may be correct: if enet driver uses the same clock

source, then for changing rgmii clock one may need to take in consideration

EB790 Configuration of Phase Fractional Dividers and

ERR006282 - ROM code uses nonreset PFDs to generate clocks, which may lead to

random boot failures  IMX6DQCE

Application software is still required to perform a PFD reset in Silicon revision 1.3 under the

following conditions:

• Reprogramming (relocking) PLL2/PLL3

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
3 Replies
649 Views
igorpadykov
NXP Employee
NXP Employee

Hi Josh

one can printf iomux registers for SD3 pins. As for clocks

in general your assumption may be correct: if enet driver uses the same clock

source, then for changing rgmii clock one may need to take in consideration

EB790 Configuration of Phase Fractional Dividers and

ERR006282 - ROM code uses nonreset PFDs to generate clocks, which may lead to

random boot failures  IMX6DQCE

Application software is still required to perform a PFD reset in Silicon revision 1.3 under the

following conditions:

• Reprogramming (relocking) PLL2/PLL3

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

0 Kudos
648 Views
jwatts
Contributor I

Thanks for the quick reply Igor!

I probably should have have tried to dump the IOMUX registers before posting: I'm not yet sure where and why Linux is altering the the SD3 pins, but that is precisely what appears to have happened.

Thanks also for pointing out PFD errata, I may still need to look into that as well.

0 Kudos
648 Views
jwatts
Contributor I

For others pulling their hair out: The Dual and the DualLight do not share the same IOMUX registers. Rather, it appears that the Dual and Quad are the same in this regard. Changing my device-tree to include from imx6q.dtsi instead of imx6dl.dtsi resolved this issue (and several others I was working through).

0 Kudos