Fast Ethernet Controller FEC slow start

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

Fast Ethernet Controller FEC slow start

Jump to solution
1,684 Views
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

Labels (2)
0 Kudos
1 Solution
765 Views
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

View solution in original post

2 Replies
766 Views
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

765 Views
CarlosCasillas
NXP Employee
NXP Employee

Hi Frederik,

Thanks for sharing your solution with the Community!!!

Best regards!

/Carlos

0 Kudos