Defer net initialization

U-Boot Alexander Stein 3 participants 12 messages May 31, 2010 – Jun 1, 2010 1 message not in the archive

Share & tools

Alexander Stein

author

2010-05-31 12:58 UTC #0 lore raw

Hello,

during board setup the ethernet is configured including the PHY. This takes an amount of time even if the cable is plugged in. It takes even more time of the initialization runs into a timeout if no cable is put in.
Is there a possibility to defer the net initialization up to that point where the first net access is done, e.g. tftp command and leave the net uninitialized during normal startup using fsload and bootm.

Best regards
Alexander

Wolfgang Denk

2010-05-31 16:08 UTC #1 lore raw

Dear Alexander Stein,

Quoted 7 lines · In message <[email protected]> you wrote:

during board setup the ethernet is configured including the PHY. This takes an amount of time even if the cable is plugged in. It takes even more time of the initialization runs into a timeout if no cable is put in.
Is there a possibility to defer the net initialization up to that point where the first net access is done, e.g. tftp command and leave the net uninitialized during normal startup using fsload and bootm.

Which version of U-Boot and which architecture / board are you talking about?

Best regards,

Wolfgang Denk

Signature · 6 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
PoB = "Prisoner of Bill" -- those held captive, unwillingly or other-
wise, by the contemptible Microsoft monopoly.
         -- Tom Christiansen in <[email protected]>

Alexander Stein

author

2010-06-01 06:17 UTC #2 lore raw

Dear Wolfgang,

Am Montag, 31. Mai 2010 18:08:30 schrieb Wolfgang Denk:

Quoted 10 lines

Quoted 7 lines
during board setup the ethernet is configured including the PHY. This takes an amount of time even if the cable is plugged in. It takes even more time of the initialization runs into a timeout if no cable is put in.
Is there a possibility to defer the net initialization up to that point where the first net access is done, e.g. tftp command and leave the net uninitialized during normal startup using fsload and bootm.
Which version of U-Boot and which architecture / board are you talking about?

Currently I'm using u-boot v2009.11 on at91sam9g20 on our own board (code yet upstream).

Best regards,
Alexander

Alexander Stein

author

2010-06-01 06:24 UTC #3 lore raw

Am Dienstag, 1. Juni 2010 08:17:41 schrieb Alexander Stein:

Quoted 5 lines

Quoted 2 lines
Which version of U-Boot and which architecture / board are you talking about?
Currently I'm using u-boot v2009.11 on at91sam9g20 on our own board (code
yet upstream).

Oh, i forgot. This code is based on the atmel at91sam9g20ek board code which is included in at91sam9260ek.

Best regards
Alexander

Wolfgang Denk

2010-06-01 07:17 UTC #4 lore raw

Dear Alexander Stein,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 3 lines
Currently I'm using u-boot v2009.11 on at91sam9g20 on our own board (code
yet upstream).
Oh, i forgot. This code is based on the atmel at91sam9g20ek board code which is included in at91sam9260ek.

I don't know this port really well (and the AT91 family has been orphaned and without active custodian for a long time), but it should not touch the PHY (and especially not wait for a link) unless a 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).

Best regards,

Wolfgang Denk

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Bus error -- driver executed.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Wolfgang Denk

2010-06-01 08:48 UTC #6 lore raw

Dear Alexander Stein,

please keep the mailing list on Cc:

Quoted 7 lines · In message <[email protected]> you wrote:

Quoted 4 lines
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.

Quoted 4 lines

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.

Quoted 2 lines

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

Signature · 5 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Don't worry about people stealing your ideas. If your ideas are  any
good, you'll have to ram them down people's throats."  - Howard Aiken

Alexander Stein

author

2010-06-01 10:14 UTC #7 lore raw

Dear Wolgfang,

Am Dienstag, 1. Juni 2010 10:48:25 schrieben Sie:

Quoted 21 lines

Quoted 2 lines
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.
Quoted 4 lines
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.

Quoted 7 lines

Quoted 2 lines
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

Quoted 1 line

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

Wolfgang Denk

2010-06-01 10:46 UTC #8 lore raw

Dear Alexander Stein,

Quoted 7 lines · In message <[email protected]> you wrote:

The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
Quoted 1 line
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

Signature · 4 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
 The software required `Windows 95 or better', so I installed Linux.

Alexander Stein

author

2010-06-01 11:12 UTC #9 lore raw

Dear Wolfgang,

Am Dienstag, 1. Juni 2010 12:46:03 schrieben Sie:

Quoted 9 lines

Quoted 8 lines
The problem was a defined CONFIG_RESET_PHY_R. Inside reset_phy
Quoted 1 line
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.

Quoted 6 lines

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

Quoted 1 line

/sbin/ifconfig eth0 hw ether ${MACADDR}

where ${MACADDR} is set by 'fw_printenv ethaddr'

Best regards
Alexander

Ben Warren

2010-06-01 14:46 UTC #10 lore raw

In reply to Alexander Stein

HI Alexander,

Quoted 40 lines · Alexander Stein

Dear Wolgfang,
Am Dienstag, 1. Juni 2010 10:48:25 schrieben Sie:
Quoted 1 line
Quoted 1 line
I think this thread focus on another problem: setting the MAC address.
I
Quoted 1 line
Quoted 1 line
have a MAC in the ethaddr environment variable which gets used
properly.
Quoted 7 lines
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.
Quoted 1 line
I traced the call graph a bit down. So on every startup eth_initialize
is
Quoted 4 lines
Quoted 3 lines
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.
Quoted 9 lines
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.
Quoted 1 line
How could I avoid calling eth_initialize during startup but before
using
Quoted 6 lines
Quoted 1 line
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

Quoted 8 lines

Quoted 1 line
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.

Quoted 1 line

Thanks for your hints and help.

Quoted 3 lines

Best regards
Alexander

regards,
Ben

Alexander Stein

author

2010-06-01 14:55 UTC #11 lore raw

Ho Ben,

Am Dienstag, 1. Juni 2010 16:46:48 schrieb Ben Warren:

Quoted 14 lines

Quoted 5 lines
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
Quoted 8 lines
Quoted 1 line
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.

Quoted 7 lines

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

Ben Warren

2010-06-01 19:04 UTC #12 lore raw

Hi Alexander,

Quoted 23 lines · Alexander Stein

Ho Ben,
Am Dienstag, 1. Juni 2010 16:46:48 schrieb Ben Warren:
Quoted 19 lines
Quoted 6 lines
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
Quoted 9 lines
Quoted 2 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Quoted 3 lines

Best regards
Alexander

regards,
Ben