[U-Boot-Users] Yucca ethernet timeout

[U-Boot-Users] Yucca ethernet timeout

[Dale Dunlea]

Hi,

I'm using the Yucca board from AMCC and recently re-built u-boot to
take advantage of the changes regarding SPD configuration enabling the
use of DIMMs other than those supplied with the Yucca platform.

Since the upgrade, I'm seeing timeouts during TFTP. Has anyone else
seen this? Sometimes the transfer will complete, but more often, it
won't. Here is a dump of what happens at boot:

U-Boot 1.2.0 (Mar  9 2007 - 12:53:34)

CPU:   AMCC PowerPC 440SPe Rev. B at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
       RAID 6 support
       I2C boot EEPROM enabled
       Bootstrap Option D - Boot ROM Location I2C (Addr 0x50)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Yucca - AMCC 440SPe Evaluation Board
I2C:   ready
DRAM: 512 MB (ECC not enabled)
In:    serial
Out:   serial
Err:   serial
Net:   ppc_4xx_eth0

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot:  0
Waiting for PHY auto negotiation to complete.. done
ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server 10.0.2.141; our IP address is 10.0.2.205
Filename 'uImage'.
Load address: 0x1000000
Loading: #####################################T ############################
         #################################################################
         #################################################################
         ########T T T T T T T T T
Retry count exceeded; starting again
Using ppc_4xx_eth0 device
TFTP from server 10.0.2.141; our IP address is 10.0.2.205
Filename 'uImage'.
Load address: 0x1000000
Loading: ############################################T T

[U-Boot-Users] Yucca ethernet timeout

[Stefan Roese]

On Friday 09 March 2007 15:01, Dale Dunlea wrote:
> I'm using the Yucca board from AMCC and recently re-built u-boot to
> take advantage of the changes regarding SPD configuration enabling the
> use of DIMMs other than those supplied with the Yucca platform.
>
> Since the upgrade, I'm seeing timeouts during TFTP. Has anyone else
> seen this? Sometimes the transfer will complete, but more often, it 
> won't. Here is a dump of what happens at boot:

Hmmm. I have not seen this. But I tested much more intensive on the Katmai 
than on the Yucca. Could you please tell me which versions of U-Boot didn't 
show this problem, so that we can better try to find the source of the 
problem.

How often does it happen? Has your network lot's of broadcast messages?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

[U-Boot-Users] Yucca ethernet timeout

[Mike Scheutzow]

Stefan Roese wrote:
 > On Friday 09 March 2007 15:01, Dale Dunlea wrote:
 >> Since the upgrade, I'm seeing timeouts during TFTP.

 > How often does it happen? Has your network lot's of broadcast messages?

I see this timeout problem on my mpc8343 port, using 1.1.4 network code.

Prior to my workaround, it happened on 99% of the tftp transfers. My 
u-boot test network is tiny (3 machines, 100 Mbps), and has almost no 
traffic on it.  The bug appears when code optimization (-Os) is on, but 
does not occur with no optimization.

My workaround was to add a delay of 100 usec at the bottom of the 
receive polling loop (in net/net.c, I believe.)  A delay of 10 usec did 
not cure the symptom.

-- 
Mike Scheutzow
scheutzow at alcatel-lucent.com

[U-Boot-Users] Yucca ethernet timeout

[Stefan Roese]

On Saturday 10 March 2007 15:45, Mike Scheutzow wrote:
> I see this timeout problem on my mpc8343 port, using 1.1.4 network code.

That's most likely a different problem. It's not a problem of the U-Boot 
common networking code, but the chip specific ethernet driver.

> Prior to my workaround, it happened on 99% of the tftp transfers. My
> u-boot test network is tiny (3 machines, 100 Mbps), and has almost no
> traffic on it.  The bug appears when code optimization (-Os) is on, but
> does not occur with no optimization.

Hmmm. When a problem disappears upon changing the optimization options, that's 
not a good sign.

> My workaround was to add a delay of 100 usec at the bottom of the
> receive polling loop (in net/net.c, I believe.)  A delay of 10 usec did
> not cure the symptom.

As you already mentioned, that's only a workaround. Did you try a recent 
version of U-Boot?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================

[U-Boot-Users] Yucca ethernet timeout

[Dale Dunlea]

On 3/9/07, Stefan Roese <sr@denx.de> wrote:
> On Friday 09 March 2007 15:01, Dale Dunlea wrote:
> > I'm using the Yucca board from AMCC and recently re-built u-boot to
> > take advantage of the changes regarding SPD configuration enabling the
> > use of DIMMs other than those supplied with the Yucca platform.
> >
> > Since the upgrade, I'm seeing timeouts during TFTP. Has anyone else
> > seen this? Sometimes the transfer will complete, but more often, it
> > won't. Here is a dump of what happens at boot:
>
> How often does it happen? Has your network lot's of broadcast messages?

It turns out that at the same time we upgraded u-boot, somewhere on
the network, a switch was replaced, and the new one was faulty.
Unfortunate timing indeed, but we seem to be back up and running now.

Regards,
Dale

[U-Boot-Users] Yucca ethernet timeout

[Mike Scheutzow]

Stefan Roese wrote:
> On Saturday 10 March 2007 15:45, Mike Scheutzow wrote:
>> I see this timeout problem on my mpc8343 port, using 1.1.4 network code.
> 
> That's most likely a different problem. It's not a problem of the U-Boot 
> common networking code, but the chip specific ethernet driver.

I agree that the ethernet driver is likely the cause.  At the moment, 
other bugs have higher priority, but this one is on my list.  I'll post 
a fix if I figure it out.

--
Mike Scheutzow