iMX6Q Custom Board, u-boot, 100MBits Ethernet, not working, connected to RGMII

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

iMX6Q Custom Board, u-boot, 100MBits Ethernet, not working, connected to RGMII

1,417 Views
mamsadegh
Contributor I

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.

0 Kudos
3 Replies

703 Views
mamsadegh
Contributor I

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!

0 Kudos

703 Views
igorpadykov
NXP Employee
NXP Employee

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

0 Kudos

703 Views
igorpadykov
NXP Employee
NXP Employee

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!

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

0 Kudos