Re: [U-Boot] Defer net initialization
Dear Alexander Stein,
please keep the mailing list on Cc:
In message 201006011035.38778.alexander.stein@systec-electronic.com you wrote:
network command is being run in U-Boot. There have been some discussions about this topic recently (see for example thread starting here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/76507).
I think this thread focus on another problem: setting the MAC address. I have a MAC in the ethaddr environment variable which gets used properly.
You are wrong. The thread is exactly discussing the issue you are suffering from. The whole discussion is basicly around the decision which parts of the hardware (especially the Ethernet hardware) should be initialized where and when.
I traced the call graph a bit down. So on every startup eth_initialize is called from start_armboot which then calls board_eth_init which calls macb_eth_initialize (in my board source). And macb_eth_initialize takes very long if no cable is plugged.
Please read the docs referred to in the thread mentioned above (especially doc/README.drivers.eth, but there are some pretty explanative comments in the thread, which is why I point you at it) to understand why the implementationon your board is not in line with the intended design.
eth_initialize should NOT wait for a link state.
How could I avoid calling eth_initialize during startup but before using the first net related command?
You ask the wrong question. Ity is perfectly OK to call eth_initialize() which is supposed to register the available network drivers, but this should NOT include to actually initialize the hardware. So it's the lower layers that are wrong in your port.
Best regards,
Wolfgang Denk
Dear Wolgfang,
Am Dienstag, 1. Juni 2010 10:48:25 schrieben Sie:
I think this thread focus on another problem: setting the MAC address. I have a MAC in the ethaddr environment variable which gets used properly.
You are wrong. The thread is exactly discussing the issue you are suffering from. The whole discussion is basicly around the decision which parts of the hardware (especially the Ethernet hardware) should be initialized where and when.
I traced the call graph a bit down. So on every startup eth_initialize is called from start_armboot which then calls board_eth_init which calls macb_eth_initialize (in my board source). And macb_eth_initialize takes very long if no cable is plugged.
Please read the docs referred to in the thread mentioned above (especially doc/README.drivers.eth, but there are some pretty explanative comments in the thread, which is why I point you at it) to understand why the implementationon your board is not in line with the intended design.
eth_initialize should NOT wait for a link state.
How could I avoid calling eth_initialize during startup but before using the first net related command?
You ask the wrong question. Ity is perfectly OK to call eth_initialize() which is supposed to register the available network drivers, but this should NOT include to actually initialize the hardware. So it's the lower layers that are wrong in your port.
This macb driver is fine so far. eth_initialize doesn't startup the hardware e.g. checking for link etc. The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device. But as we have a jffs2 rootfs this could be ignored.
Thanks for your hints and help.
Best regards Alexander
Dear Alexander Stein,
In message 201006011214.46804.alexander.stein@systec-electronic.com you wrote:
The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device.
I don't know this driver, but I smell that the comment might actually be wrong or at least misleading - most likely no PHY reset is needed here but a MAC address needs to be programmed into the controller - which brings us back to the start of this discussion. [And note that you still might need this when you want to use the ethernet interface in Linux].
Best regards,
Wolfgang Denk
Dear Wolfgang,
Am Dienstag, 1. Juni 2010 12:46:03 schrieben Sie:
The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device.
I don't know this driver, but I smell that the comment might actually be wrong or at least misleading - most likely no PHY reset is needed here but a MAC address needs to be programmed into the controller - which brings us back to the start of this discussion. [And note that you still might need this when you want to use the ethernet interface in Linux].
The PHY is explicitly reset in most *_macb_hw_init() on AT91 baords to (re)set the PHY address by straping pins. I think it is debatable if this is really necessary.
The MAC is actually written into hardware in macb_init and afterwards the PHY is initialized in macb_phy_init. So a eth_init seem to be a must from board setup.
The not set MAC is currently (accidently) bypassed in our rootfs as we call
/sbin/ifconfig eth0 hw ether ${MACADDR}
where ${MACADDR} is set by 'fw_printenv ethaddr'
Best regards Alexander
HI Alexander,
On Tue, Jun 1, 2010 at 3:14 AM, Alexander Stein < alexander.stein@systec-electronic.com> wrote:
Dear Wolgfang,
Am Dienstag, 1. Juni 2010 10:48:25 schrieben Sie:
I think this thread focus on another problem: setting the MAC address.
I
have a MAC in the ethaddr environment variable which gets used
properly.
You are wrong. The thread is exactly discussing the issue you are suffering from. The whole discussion is basicly around the decision which parts of the hardware (especially the Ethernet hardware) should be initialized where and when.
I traced the call graph a bit down. So on every startup eth_initialize
is
called from start_armboot which then calls board_eth_init which calls macb_eth_initialize (in my board source). And macb_eth_initialize takes very long if no cable is plugged.
Please read the docs referred to in the thread mentioned above (especially doc/README.drivers.eth, but there are some pretty explanative comments in the thread, which is why I point you at it) to understand why the implementationon your board is not in line with the intended design.
eth_initialize should NOT wait for a link state.
How could I avoid calling eth_initialize during startup but before
using
the first net related command?
You ask the wrong question. Ity is perfectly OK to call eth_initialize() which is supposed to register the available network drivers, but this should NOT include to actually initialize the hardware. So it's the lower layers that are wrong in your port.
This macb driver is fine so far. eth_initialize doesn't startup the hardware e.g. checking for link etc. The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device. But as we have a jffs2 rootfs this could be ignored.
Yes, you've found the root cause. Some (maybe all) AT91 boards call call eth_init() during their initialization, which can take time. My understanding is that this was done to ensure a programmed MAC address.
I added code recently to always program MAC addresses, hoping that we could then get rid of all these calls. I encourage you to either try to make the changes yourself, or I can build you an untested patch to try.
Thanks for your hints and help.
Best regards Alexander
regards, Ben
Ho Ben,
Am Dienstag, 1. Juni 2010 16:46:48 schrieb Ben Warren:
This macb driver is fine so far. eth_initialize doesn't startup the hardware e.g. checking for link etc. The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device. But as we have a jffs2 rootfs this could be ignored.
Yes, you've found the root cause. Some (maybe all) AT91 boards call call eth_init() during their initialization, which can take time. My understanding is that this was done to ensure a programmed MAC address.
I added code recently to always program MAC addresses, hoping that we could then get rid of all these calls. I encourage you to either try to make the changes yourself, or I can build you an untested patch to try.
I would try your patch if you send it to me (and the list maybe too).
Best regards Alexander
Hi Alexander,
On 6/1/2010 7:55 AM, Alexander Stein wrote:
Ho Ben,
Am Dienstag, 1. Juni 2010 16:46:48 schrieb Ben Warren:
This macb driver is fine so far. eth_initialize doesn't startup the hardware e.g. checking for link etc. The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
eth_init(gd->bd);
is called which actually starts the hardwre resulting in timeouts as described. According to the comment above this line (seems to be copied to every at91 board implementation) this is only needed if linux has a NFS root which needs a preinitialized ethernet device. But as we have a jffs2 rootfs this could be ignored.
Yes, you've found the root cause. Some (maybe all) AT91 boards call call eth_init() during their initialization, which can take time. My understanding is that this was done to ensure a programmed MAC address.
I added code recently to always program MAC addresses, hoping that we could then get rid of all these calls. I encourage you to either try to make the changes yourself, or I can build you an untested patch to try.
I would try your patch if you send it to me (and the list maybe too).
I sent the patch, hopefully you'll get it. Please remember to remove the call in your board code to 'eth_init()'. You'll see examples in the patch.
Best regards Alexander
regards, Ben
participants (3)
-
Alexander Stein -
Ben Warren -
Wolfgang Denk