I use LAN8720A in my i.mx6Q board,I want to use u-boot2013.04, how can I do ?
Solved! Go to Solution.
There are some bugs in the "fec_mxc.c ", you can download "u-boot-2013.10-rc1" version get the difference between the u-boot-2013.04 version, then you can find the bugs.
i have exact the same issue.
Please review the following thread:
Jamesbone,
Thank you very much your reply. On this issue, I can describe in more detail.
I can see 50MHz going into the phy from the REF_OUT Pin of the i.MX6Q, I can read the phy ID using the u-boot MDIO commands but when I do ping the terminal display:
U-Boot > ping 192.168.1.1
Using FEC device
ARP Retry count exceeded; starting again
The pinmux i have is the following:
iomux_v3_cfg_t const enet_pads[] = {
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_ENET_CRS_DV__ENET_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RX_ER__ENET_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TX_EN__ENET_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RXD0__ENET_RDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RXD1__ENET_RDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TXD0__ENET_TDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TXD1__ENET_TDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__ANATOP_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_GPIO_8__GPIO_1_8 | MUX_PAD_CTRL(NO_PAD_CTRL), /* reset phy */
};
And the Ethernet configuration in the config file as follows:
/* Ethernet Configuration */
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
#define CONFIG_FEC_XCV_TYPE RMII
#define CONFIG_ETHPRIME "FEC"
#define CONFIG_FEC_MXC_PHYADDR 0
#define CONFIG_PHYLIB
#define CONFIG_PHY_SMSC
In the board file:
#ifdef CONFIG_FEC_MXC
/*
* Initialise the pins, and reset the PHY
*/
static void setup_iomux_enet(void)
{
imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
/* Reset LAN8720 PHY */
gpio_direction_output(ETH_PHY_RESET, 1);
udelay(150);
gpio_set_value(ETH_PHY_RESET, 0);
udelay(150);
gpio_set_value(ETH_PHY_RESET, 1);
udelay(200);
}
int enable_fec_anatop_clock(void)
{
u32 reg = 0;
s32 timeout = 100000;
struct anatop_regs __iomem *anatop =
(struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
reg = readl(&anatop->pll_enet);
if ((reg & BM_ANADIG_PLL_ENET_POWERDOWN) ||
(!(reg & BM_ANADIG_PLL_ENET_LOCK))) {
reg &= ~BM_ANADIG_PLL_ENET_POWERDOWN;
writel(reg, &anatop->pll_enet);
while (timeout--) {
if (readl(&anatop->pll_enet) & BM_ANADIG_PLL_ENET_LOCK)
break;
}
if (timeout < 0)
return -ETIMEDOUT;
}
/* Enable FEC clock */
reg |= BM_ANADIG_PLL_ENET_ENABLE;
reg &= ~BM_ANADIG_PLL_ENET_BYPASS;
writel(reg, &anatop->pll_enet);
return 0;
}
int board_eth_init(bd_t *bis)
{
int ret;
setup_iomux_enet();
ret = cpu_eth_init(bis);
if (ret) {
printf("FEC MXC: %s:failed\n", __func__);
return ret;
}
return 0;
}
static int setup_fec(void)
{
struct iomuxc_base_regs *iomuxc_regs =
(struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
int ret;
/* set gpr1[21] to select anatop clock */
clrsetbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK, 1
<< 21);
ret = enable_fec_anatop_clock();
if (ret)
return ret;
return 0;
}
#endif
int board_late_init(void)
{
#ifdef CONFIG_CMD_BMODE
add_board_boot_modes(board_boot_modes);
#endif
return 0;
}
int board_init(void)
{
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
/* Read the board ID */
/* Setup the FEC clock */
#ifdef CONFIG_FEC_MXC
setup_fec();
#endif
return 0;
}
Have you solve the problem ?
I met the sam problem .
pls
Please check the recent patch for fec_mxc.c
https://github.com/Freescale/u-boot-fslc/commit/530548933bb359c6e6689da307d04e910f52b6be
It is to add polling for the ready bit of BD(Buffer Descriptor) in order to check transfer completion.
In case of kernel, the ready bit of BD is used for checking transfer completion, not TDAR and so kernel with LAN8720 is working well.
- Alex Yang
Hi Alex,
The U-boot patch you mentioned is needed for mx6solox only.
The patch is for all MX6, not only MX6SX and the issue was discovered just on MX6SX reference.
My customer suffered similar issue on customer's board with MX6S and it was resolved after applying the patch.
Especially if the symptom is that MDIO is OK and actual communication is failed, there is strong probability that TDAR clear timing is prior to BD's clear.
It is possibility and my experience, also the patch is OK for all MX6.
In "fec_send" function which in drivers\net\fec_mxc.c file I add the debug codes following:
/*
* Wait until frame is sent. On each turn of the wait cycle, we must
* invalidate data cache to see what's really in RAM. Also, we need
* barrier here.
*/
while (--timeout) {
if (!(readl(&fec->eth->x_des_active) & FEC_X_DES_ACTIVE_TDAR))
break;
}
printf("the x_des_active is 0x%X\n", readl(&fec->eth->x_des_active));
if (!timeout) {
ret = -EINVAL;
goto out;
}
When I execute 'ping 192.168.1.101' command log shows: "the x_des_active is 0x1000000". So the code you provided can not been accessed.
We check the SION bit in IOMUXC_SW_MUX_CTL_PAD_RGMII_TX_CTL has been set . The value is 0x17.
We are sure that the i.MX6Q output 50MHz clock to phy.
So I think the enet module has not work.
Hello,
I have followed this thread and many other similar facing to the same problem without success.
I am using a i.MX6D (Dual no lite) + SMSC 8720A
I read the "Hardware Development Guide for i.MX6" Chapter 12 Using the RMII interface
MX6_PAD_GPIO_16__ENET_ETHERNET_REF_OUT = IOMUX_PAD(0x0618, 0x0248, (2 | IOMUX_CONFIG_SION), 0x083C, 1, 0),
#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | PAD_CTL_SRE_FAST)
MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_CRS_DV__ENET_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RX_ER__ENET_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TX_EN__ENET_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RXD0__ENET_RDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_RXD1__ENET_RDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TXD0__ENET_TDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_TXD1__ENET_TDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
// Reference clock
MX6_PAD_GPIO_16__ENET_ETHERNET_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
// !!! Do not use because inhibits IOMUXC_ENET_REF_CLK_SELECT_INPUT !!!
// MX6_PAD_RGMII_TX_CTL__ANATOP_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__ANATOP_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
// SMSC 8720 PHY Reset
MX6_PAD_EIM_D22__GPIO_3_22 | MUX_PAD_CTRL(NO_PAD_CTRL),
// SMSC 8720 PHY Interrupt
MX6_PAD_EIM_D20__GPIO_3_20 | MUX_PAD_CTRL(NO_PAD_CTRL),
The SION seems OK
u-boot > md.l 020e0248 1
020e0248: 00000012
U-Boot 2013.10 (Jan 30 2015 - 17:23:45)
CPU: Freescale i.MX6Q rev1.5 at 792 MHz
u-boot> print
baudrate=115200
bootdelay=1
ethact=FEC
ethaddr=00:80:18:02:e0:78
ethprime=FEC
ipaddr=192.168.0.184
loadaddr=0x12000000
netmask=255.255.255.0
serverip=192.168.0.6
u-boot > ping 192.168.0.1
MCK DEBUG: fec_halt
MCK DEBUG: fec_init
MCK DEBUG: fec_set_hwaddr ADDR:21880E4
MCK DEBUG: fec_reg_setup
MCK DEBUG: fec_open
MCK DEBUG: genphy_update_link
MCK DEBUG: fec_mdio_read
MCK DEBUG: fec_mdio_read
MCK DEBUG: fec_mdio_read
Using FEC device
MCK DEBUG: fec_send
the x_des_active is 0x1000000
fec_send: status 0x8c00 index 0 ret -22
MCK DEBUG: fec_send
the x_des_active is 0x1000000
fec_send: status 0xac00 index 1 ret -22
MCK DEBUG: fec_send
the x_des_active is 0x1000000
fec_send: status 0x8c00 index 0 ret -22
MCK DEBUG: fec_send
the x_des_active is 0x1000000
fec_send: status 0xac00 index 1 ret -22
I'm not able to figure out what is still missing or what other test to do.
Any hint would be greatly appreciated.
TIA
There are some bugs in the "fec_mxc.c ", you can download "u-boot-2013.10-rc1" version get the difference between the u-boot-2013.04 version, then you can find the bugs.
Thank you Kenny,
I moved to u-boot v.2015.01 but I get the same problem, no ping no trafic on RMII pins.
I argue there were no bugs.
Now I have no clues.
U-Boot 2015.01 (Feb 04 2015 - 18:02:04)
CPU: Freescale i.MX6D rev1.5 at 792 MHz
CPU: Temperature 45 C
Reset cause: POR
Board: MX6-SabreQ
I2C: ready
DRAM: 512 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
Net: *** board_eth_init
PHY special mode write MODE[2:0] = 111
FEC [PRIME]
U-boot > ping 192.168.0.1
Using FEC device
ARP Retry count exceeded; starting again
ARP Retry count exceeded; starting again
Hi Marco
I don't know how much this is going to be of
help but I recently worked on a project where
I had imx6solo and LAN8820 working fine.
I don't know the differences between 8820 and
8720 you are referring to but we used RGMII
and had an external xtal.
I was working with mainline u-boot and
had to make few modifications for 8820
phy support. While I was doing the board
bring up, I set the phy in loopback mode and
got the FEC working properly first. Having
the PHY working properly for GigE was
another story. Perhaps you can do this
too and set the PHY in loopback via mdio
commands and then measure all the
lines leading to PHY to see if FEC is
sending proper clock and data.
I don't have access to that board any more
to try out things but let me know if there is
anything I can be of help, as much as I can
remember how I implemented.
Best regards
Sinan Akman
Thx Sinan,
actually I can query the SMSC872 via u-boot mii commands.
The problem is that I don't have any signal on the lines connecting the CPU to the PHY (RXD0,RXD1,CRS_DV,TXD0,TXD1,TXEN)
Probably I'm missing something...
I use the patch, but the problem is not solved. I print the status in fec_send() function, the logs are following:
ARP Retry count exceeded; starting again
fec_send: status 0x8c00 index 0 ret -22
fec_send: status 0xac00 index 1 ret -22
fec_send: status 0x8c00 index 0 ret -22
fec_send: status 0xac00 index 1 ret -22
Yes, sure the fec driver is common for all imx.
Glad to know that my patch helped you :-)
After I execute ‘ping’ command the TX_DATA0 PIN, TX_DATA1 PIN and TX_EN PIN keep low level. I think the ENET module in the i.MX6Q does not work. But how can I determine it ?
I still thinking the problem it is related to the PHy driver, since I tested in the i.MX6Q SABRE board and it is working fine. Can you share the driver that are you using in Uboot?
Could you gave me your u-boot codes? I try to find the difference. Thank you.
发件人: jamesbone
发送时间: 2014年9月17日 22:48
收件人: kenny wang
主题: Re: - i.mx6Q use LAN8720A in u-boot2013.04
<https://community.freescale.com/> Freescale Community
i.mx6Q use LAN8720A in u-boot2013.04
reply from jamesbone <https://community.freescale.com/people/jamesbone?et=watches.email.thread> in i.MX Community - View <https://community.freescale.com/message/436379?et=watches.email.thread#436379> the full discussion
If you use dynamic IP you can do "setenv ip_dyn yes" otherwise "setenv ip_dyn no". Then try tftp or dhcp transfer.
I set static IP, I do "set ipaddr 192.168.1.30" and "set ethaddr 00:00:01:02:03:04". When I do ping nothing comes out. I have enabled the debug function, and when I execute the 'ping" command I get the error -22 back.
U-Boot > ping 192.168.1.1
eth_halt: wait for stop regs
eth_halt: done
Trying FEC
fec_mii_setspeed: mii_speed 00000014
fec_open: fec_open(dev)
fec_mdio_read: phy: 00 reg:01 val:0x782d
fec_mdio_read: phy: 00 reg:01 val:0x782d
fec_open:Speed=100
Using FEC device
fec_send: status 0x8c00 index 0 ret -22
fec_recv: ievent 0x10000000
fec_recv: status 0x8000
fec_recv: stop