[U-Boot] Defer net initialization

[U-Boot] Defer net initialization

[Alexander Stein]

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

[U-Boot] Defer net initialization

[Wolfgang Denk]

Dear Alexander Stein,

In message <201005311458.18454.alexander.stein@systec-electronic.com> 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

-- 
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 <6abo45$3lc$2@csnews.cs.colorado.edu>

[U-Boot] Defer net initialization

[Alexander Stein]

Dear Wolfgang,

Am Montag, 31. Mai 2010 18:08:30 schrieb Wolfgang Denk:
> > 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

[U-Boot] Defer net initialization

[Alexander Stein]

Am Dienstag, 1. Juni 2010 08:17:41 schrieb Alexander Stein:
> > 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

[U-Boot] Defer net initialization

[Wolfgang Denk]

Dear Alexander Stein,

In message <201006010824.25437.alexander.stein@systec-electronic.com> you wrote:
>
> > 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

-- 
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.

[U-Boot] Defer net initialization

[Wolfgang Denk]

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

-- 
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

[U-Boot] Defer net initialization

[Alexander Stein]

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

[U-Boot] Defer net initialization

[Wolfgang Denk]

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

-- 
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.

[U-Boot] Defer net initialization

[Alexander Stein]

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

[U-Boot] Defer net initialization

[Ben Warren]

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

[U-Boot] Defer net initialization

[Alexander Stein]

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

[U-Boot] Defer net initialization

[Ben Warren]

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