Fast Ethernet Controller FEC slow start

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Fast Ethernet Controller FEC slow start

跳至解决方案
2,825 次查看
frederikjuul
Contributor II

I'm building an embedded system using an IMX6SX. I need it to boot very fast, so I've been tuning boot parameters.

The system first boots into uboot, which loads the kernel over TFTP, then boots into the kernel using NFS. My bootargs are:

console=ttymxc0,115200 root=/dev/nfs ip=192.168.42.2:192.168.42.1:192.168.42.1:255.255.255.0::eth0 nfsroot=192.168.42.1:/tmp/rootfs quiet

Most of the system is booted in the first 0.3 seconds. However when it comes to the FEC it hangs for something VERY close to exactly 4 seconds, before moving on.

A log of the issue:

http://pastebin.com/GbHBMSuc

If I try the same boot using a fixed-phy setup, the 4 seconds are reduced to similarly close to 2 seconds, which is still a bit more than I would like. Otherwise the log looks the same.

To me, given the very exact times, it looks like a timeout or a delay. I was hoping that someone could give me some pointers to mitigate the problem a bit, be reducing the delay. In the final setup the phy will be an FPGA and I will be able to know everything about the setup beforehand, which I hope will help with boot time even further. I can't find what in the source code causes this delay and I can't seem to get it to print out anymore than it already does.

As soon as I get my hands on some of my custom boards, I will try booting without using NFS, which will also mean that the FEC driver is not strictly necessary on boot, which might make it possible to mitigate my problem.

[    0.304651] snvs_rtc 20cc034.snvs-rtc-lp: setting system clock to 1970-01-01 00:24:39 UTC (1479)
[    0.392520] fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)
[    4.392509] libphy: 2188000.ethernet:01 - Link is Up - 1000/Full
[    4.432115] IP-Config: Complete:
[    4.432132]      device=eth0, hwaddr=00:04:9f:03:87:c4, ipaddr=192.168.42.2, mask=255.255.255.0, gw=192.168.42.1
[    4.432141]      host=192.168.42.2, domain=, nis-domain=(none)
[    4.432149]      bootserver=192.168.42.1, rootserver=192.168.42.1, rootpath=
[    4.446599] VFS: Mounted root (nfs filesystem) readonly on device 0:12.
[    4.447943] devtmpfs: mounted
[    4.448153] Freeing unused kernel memory: 248K (80698000 - 806d6000)
[    4.761983] random: dd urandom read with 14 bits of entropy available

标签 (2)
0 项奖励
回复
1 解答
1,906 次查看
frederikjuul
Contributor II

I think I found out the issue. I tracked it down to the state machine in the PHY subsystem.

Apparently the PHY state machine needed two calls get ethernet up and running. These calls were queued in a work queue with a delay of 1 second. Two PHYs * two calls * 1 second = 4 seconds.  By changing the delay to 0 I got a much faster boot. Now I just need to test if the increased load on the PHY state machine breaks my system in other ways.

New boot:

changed phy.c - Pastebin.com

The file i changed was in linux/drivers/net/phy/phy.c

Specifically I changed the HZ to 0 in

Linux/drivers/net/phy/phy.c - Linux Cross Reference - Free Electrons

Linux/drivers/net/phy/phy.c - Linux Cross Reference - Free Electrons

在原帖中查看解决方案

2 回复数
1,907 次查看
frederikjuul
Contributor II

I think I found out the issue. I tracked it down to the state machine in the PHY subsystem.

Apparently the PHY state machine needed two calls get ethernet up and running. These calls were queued in a work queue with a delay of 1 second. Two PHYs * two calls * 1 second = 4 seconds.  By changing the delay to 0 I got a much faster boot. Now I just need to test if the increased load on the PHY state machine breaks my system in other ways.

New boot:

changed phy.c - Pastebin.com

The file i changed was in linux/drivers/net/phy/phy.c

Specifically I changed the HZ to 0 in

Linux/drivers/net/phy/phy.c - Linux Cross Reference - Free Electrons

Linux/drivers/net/phy/phy.c - Linux Cross Reference - Free Electrons

1,906 次查看
CarlosCasillas
NXP Employee
NXP Employee

Hi Frederik,

Thanks for sharing your solution with the Community!!!

Best regards!

/Carlos

0 项奖励
回复