Hi,
For one complete week, I have been struggling with this issue.
I have studied every post related to this situation here in this forum, and also in u-boot mailing list, and any other possible location in the internet. I applied all of the suggested ideas, still the ethernet connection of my board does not work.
So, I just put a report of what I have done here but I do not have any hope any one solve the issue.
I have an Automotive PHY in my custom imx6q board. This is a 100MBits phy with RGMII interface and works at 25MHz.
Our designer, as a usual mistake that he always do, has avoided to put any crystal oscillator on the board, and has connected the GPIO16 pin to the PHY. He has not connected GPIO16 pin to the ENET_REF_CLK.
I am using u-boot 2015.02
Here my pin arrangement for ethernet connection:
static iomux_v3_cfg_t const enet_pads[] = {
MX6_PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RXC__RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD0__RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD1__RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL_CLK),
MX6_PAD_ENET_CRS_DV__GPIO1_IO25 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
};
You have seen this 100 times in thie forum, because every body has problem with ethernet connectivity of imx6 when he builds his own custom board. specially when the pcb designer starts doing creative actions instead of looking at reference designs.
for both of the MX6_PAD_GPIO_16__ENET_REF_CLK and MX6_PAD_ENET_REF_CLK__ENET_TX_CLK
I have the SION bit active. this is the default in the u-boot.
Here, my code to setup the clock for ethernet block:
int board_eth_init(bd_t *bis)
{
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
writel(0x000c0000, 0x20e0790);
setup_iomux_enet();
/* set gpr1[ENET_CLK_SEL] */
setbits_le32 (&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
setbits_le32 ( 0x20e083c, 0);
writel ( 0x11, 0x20e01d4 );
int ret = enable_fec_anatop_clock(0, ENET_25MHZ);
if (ret)
return ret;
return cpu_eth_init(bis);
}
As you see, I am setting bit 21 of GPR to tell the logic get your tx clock from inside the chip.
Also I am setting the io voltage to 2.5 volts to be sure I don't have issue with data transfer between imx6 and the phy.
Also I am making sure that the value of IOMUXC_ENET_REF_CLK_SELECT_INPUT and IOMUXC_SW_MUX_CTL_PAD_ENET_REF_CLK are ok but over-writing them directly.
Now, with this setup, I get the 100 MBits link up.
It is always up and is stable.
The 25MHz clock is generated fine and is going to the PHY.
I expect that the enet controller is also receiving a copy of the clock.
But here is the outcome:
No communication happens with the outside world. for example. the dhcp command or ping command, they all fail, the fec_send always fails. no matter what I do it fails.
e.g. a part of ping ....
ARP Retry count exceeded; starting again
Sadri : fec_halt : ...
eth_halt: wait for stop regs
eth_halt: done
fec_mii_setspeed: mii_speed 0000001a
fec_open: fec_open(dev)
fec_mdio_read: phy: 00 reg:01 val:0x3fdd
fec_open:Speed=100
fec_recv: ievent 0x0
fec_recv: status 0x8000
fec_recv: stop
fec_send: status 0x8c00 index 0 ret -22
fec_recv: ievent 0x0
fec_recv: status 0x8000
fec_recv: stop
As you see fec_send fails, with a status of 0x8c00.
Now I tried to find out what does this 0x8c00 means. But I really could not find anything meaningful inside imx documentation. The DMA documentation is so huge than needs 1 month to be studied.
So the question is,
Might any body know, why the SDMA is failing to write the packet to the MAC block? why the fec_send times out?
I have seen meany people with similar problem, but at the end they say oh SION bit was not set, but here, this is not the case, I am sure SION bit is set, or at lease when reading the registers back it is there.
Thanks.
Hello Igor,
Thanks for the response.
I have seen these posts before,
I don't see any thing new there,
These are all what I have already done. can you point me out to anything this patch is doing and I am not doing?
Is there any one who can tell me , what does 0x8c00 for the status of buffer descriptor mean?
I do not believe in a patch that magically fixes every thing without you knowing what happened.
by the way these patches are old, they are not compatible with the latest u-boot.
If I patch my u-boot with this, the outcome is only errors.
A major problem with imx6 is that all the time every thing is changing. the u-boot code is changing, constant definitions are changing, the main reference document is changing, even I have noticed they change the register names inside the document.
Once one person suggests a solution to a problem, it is valid only for 2 months, after that everything has changed!
Hi Mo
u-boot 2015.02 is not officially supported by nxp, please try
uboot-imx.git - Freescale i.MX u-boot Tree
Best regards
igor
Hi Mo
please try RMII patches provided on
https://community.freescale.com/thread/313741
https://community.freescale.com/message/346089#346089
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------