[U-Boot-Users] TFTP timeout

[Philippe Villet]

Browsing the mailing list i saw that some people met my problem but i can' find the answer. Here is my problem :

TFTP transfer with u-boot (1.1.4) sometimes ended with timeout (TTT) and then a MAL error.

I'am using a 440EP, with 2 PHY from Micrel (KSZ8001) in SMII mode. Under linux (ELDK 4.0, kernel 2.6.16) we have no problem (nfs, ftp, tftp work well).

We used a Etheral to sniff and found out that u-boot ack one datapackage but when the next datapackage arrives u-boot doesn't seem to hear it. Instead u-boot timesout listening and sends another ack on the previous datapackage. The tftp server then retransmits the last datapackage again witch u-boot doesn't hear, u-boot times out and send another ack on the previous datapackage, and we are stuck in this loop.

A previous discussion "[U-Boot-Users] TFTP times out?" ended with a bad timer implementation.

Could someone help me ?

Thanks - Philippe.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060728/5c973218/attachment.htm

[Philippe Villet]

Browsing the mailing list i saw that some people met my problem but i can' find the answer. Here is my problem :

TFTP transfer with u-boot (1.1.4) sometimes ended with timeout (TTT) and then a MAL error.

I'am using a 440EP, with 2 PHY from Micrel (KSZ8001) in SMII mode. Under linux (ELDK 4.0, kernel 2.6.16) we have no problem (nfs, ftp, tftp work well).

We used a Etheral to sniff and found out that u-boot ack one datapackage but when the next datapackage arrives u-boot doesn't seem to hear it. Instead u-boot timesout listening and sends another ack on the previous datapackage. The tftp server then retransmits the last datapackage again witch u-boot doesn't hear, u-boot times out and send another ack on the previous datapackage, and we are stuck in this loop.

A previous discussion "[U-Boot-Users] TFTP times out?" ended with a bad timer implementation.

Could someone help me ?

Thanks - Philippe.








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060728/530ea319/attachment.htm

[Stefan Strobl]

Hi Philippe

Post by Philippe Villet
TFTP transfer with u-boot (1.1.4) sometimes ended with timeout (TTT) and then a MAL error.

had the same problem in the beginning. In my case it was the switch that
hosted other networks also. I'm using a 'local' switch now. Try out a
cross-over-cable and if that works, it might be your switch also.

Stefan

[Stefan Roese]

Hi Philippe,

Post by Philippe Villet
Browsing the mailing list i saw that some people met my problem but i can'
TFTP transfer with u-boot (1.1.4) sometimes ended with timeout (TTT) and then a MAL error.
I'am using a 440EP, with 2 PHY from Micrel (KSZ8001) in SMII mode. Under
linux (ELDK 4.0, kernel 2.6.16) we have no problem (nfs, ftp, tftp work
well).
We used a Etheral to sniff and found out that u-boot ack one datapackage
but when the next datapackage arrives u-boot doesn't seem to hear it.
Instead u-boot timesout listening and sends another ack on the previous
datapackage. The tftp server then retransmits the last datapackage again
witch u-boot doesn't hear, u-boot times out and send another ack on the
previous datapackage, and we are stuck in this loop.
A previous discussion "[U-Boot-Users] TFTP times out?" ended with a bad
timer implementation.

Timer should be ok for PPC440.

What did you define "CFG_RX_ETH_BUFFER" in your board config file to? Did you
try to enable the debug output in the 4xx ethernet driver "INFO_4XX_ENET"?
Are you using top-of-git UBoot version?

Best regards,
Stefan

[Wolfgang Denk]

Post by Philippe Villet
TFTP transfer with u-boot (1.1.4) sometimes ended with timeout (TTT) and
then a MAL error.

The usual question: is this plain 1.1.4 or current code (top of tree
in git repo)?

Post by Philippe Villet
------_=_NextPart_001_01C6B258.58E521CD
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HTML postings are forbidden on this list.

Best regards,

Wolfgang Denk

[Philippe Villet]

Stefan,

Post by Stefan Roese
What did you define "CFG_RX_ETH_BUFFER" in your board config file to? Did

you

Post by Stefan Roese
try to enable the debug output in the 4xx ethernet driver

"INFO_4XX_ENET"?
<Are you using top-of-git UBoot version?

No i'am using the plain 1.1.4 UBoot version (customized for our board).
I try several values for "CFG_RX_ETH_BUFFER" : 32,31,16 and 8. It does not
change
anything. Here is a trace with debug output. I've also added a trace in
the eneInt
routine to trace interrupts (UIC0MSR and UIC1MSR contents. When it works,
i've got
UIC0MSR : 0x100000, UIC1MSR : 0x0 (=> MRE interrupt)
and just before the MAL error
UIC0MSR : 0x2, UIC1MSR : 0xa0000000 (=> MS + MRDE innterrupts).
Any idea?

Philippe.


[BASE6000]> tftpboot 4000000 pMulti6000
tftpboot 4000000 pMulti6000
About preceeding transfer (eth0):
- Sent packet number 2890
- Received packet number 2898
- Handled packet number 2898
ENET Speed is 100 Mbps - FULL duplex connection
Using ppc_4xx_eth0 device
TFTP from server 10.33.17.251; our IP address is 10.33.17.162
Filename 'pMulti6000'.
Load address: 0x4000000
Loading: send option "timeout 5"
Got OACK: timeout 5
#################################################################
...
#################################################################
#################################################################
#################################################################
###########################################
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 30974
- Received packet number 31059
- Handled packet number 31059

MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 0
- Received packet number 0
- Handled packet number 0
T T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 2
- Received packet number 0
- Handled packet number 0

MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 0
- Received packet number 0
- Handled packet number 0
T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 1
- Received packet number 0
- Handled packet number 0
T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000
About preceeding transfer (eth0):
- Sent packet number 1
- Received packet number 0
- Handled packet number 0
T

[Wolfgang Denk]

Post by Philippe Villet
<Are you using top-of-git UBoot version?
No i'am using the plain 1.1.4 UBoot version (customized for our board).

Then the next thing you should do is updating to top of tree.

You should always use *current* code for new projects.

Best regards,

Wolfgang Denk

[Olivier Vernet]

Post by Wolfgang Denk
Then the next thing you should do is updating to top of tree.
You should always use *current* code for new projects.

Hi everyone,

I'm working with Philippe on the same board, we've just
download top-of-git uboot and we have the same problem with TFTP.

No more idea?

Best regards

Olivier

[Wolfgang Denk]

This post might be inappropriate. Click to display it.

[Olivier Vernet]

Post by Wolfgang Denk
Stefan Roese already recommended to enable the debug output in the
4xx ethernet driver - did you do this? What did it say?

Yes, Philippe had enabled debug output (#define INFO_4XX_ENET).

I've re-enable them with top-of-git u-boot version, trace looks
like previous one.


Best regards

Olivier

Here is the trace:

[BASE6000]> tftpboot 4000000 pMulti6000
tftpboot 4000000 pMulti6000
About preceeding transfer (eth0):
- Sent packet number 2890
- Received packet number 2898
- Handled packet number 2898
ENET Speed is 100 Mbps - FULL duplex connection Using ppc_4xx_eth0
device TFTP from server 10.33.17.251; our IP address is 10.33.17.162
Filename 'pMulti6000'.
Load address: 0x4000000
Loading: send option "timeout 5"
Got OACK: timeout 5
#################################################################
...

#################################################################

#################################################################

#################################################################
###########################################
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 30974
- Received packet number 31059
- Handled packet number 31059

MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 0
- Received packet number 0
- Handled packet number 0
T T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 2
- Received packet number 0
- Handled packet number 0

MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 0
- Received packet number 0
- Handled packet number 0
T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 1
- Received packet number 0
- Handled packet number 0
T
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000
MAL_ERR= e0000000 About preceeding transfer (eth0):
- Sent packet number 1
- Received packet number 0
- Handled packet number 0
T

[Stefan Roese]

Hi Olivier,

Post by Olivier Vernet

Post by Wolfgang Denk
Stefan Roese already recommended to enable the debug output in the
4xx ethernet driver - did you do this? What did it say?

Yes, Philippe had enabled debug output (#define INFO_4XX_ENET).
I've re-enable them with top-of-git u-boot version, trace looks
like previous one.

Thanks. Unfortunately I am quite busy so that I can't dig into this right now.

Did you try to use an "island network" setup, with you target and the server
in a separated network? Or even a point-to-point connection? Does this change
the behavior? (This is not the solution, just another test).

Best regards,
Stefan

[Olivier Vernet]

Post by Stefan Roese
Did you try to use an "island network" setup, with you target and the
server
in a separated network? Or even a point-to-point connection? Does this
change
the behavior? (This is not the solution, just another test).
Best regards,
Stefan

Yes, the behaviour changes with the network topology. On some
switch, timeout occurs more often, but in the manufacturing center,
we have an "island network", and it seems that the problem have not be
reproduced.

Best regards,

Olivier

[Stefan Roese]

Hi Olivier,

Post by Olivier Vernet
Yes, the behaviour changes with the network topology. On some
switch, timeout occurs more often, but in the manufacturing center,
we have an "island network", and it seems that the problem have not be
reproduced.

Do you have lot's of broadcasts on your "main" network connection? Please try
to increase the number of rx-packets again. For example:

#define CFG_RX_ETH_BUFFER 256

And please let me know if this helped. Thanks.

Best regards,
Stefan

[Tolunay Orkun]

On our AMCC 405EP boards, we had problems when CFG_RX_ETH_BUFFER was
greater than or equal to 32. Our boards work fine with this parameter
set to 31.

I had reported this issue in the mail list and exchanged a couple mail
with Stefan but did not have time to investigate to root cause.

Best regards,
Tolunay

Post by Stefan Roese
Hi Olivier,

Post by Olivier Vernet
Yes, the behaviour changes with the network topology. On some
switch, timeout occurs more often, but in the manufacturing center,
we have an "island network", and it seems that the problem have not be
reproduced.

Do you have lot's of broadcasts on your "main" network connection? Please try
#define CFG_RX_ETH_BUFFER 256
And please let me know if this helped. Thanks.
Best regards,
Stefan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[Rune Torgersen]

From: Olivier Vernet
Sent: Wednesday, August 02, 2006 11:11

Post by Stefan Roese
Did you try to use an "island network" setup, with you target and the
server

but in the manufacturing center,
we have an "island network", and it seems that the problem have not be
reproduced.

If it doesn't occur on an isolated network, it sounds like a MAC address
collition... Anoter device on your network has the same MAC as either
your device or the server...

Had this happen a few times... Always hard to track down.

If your devices have unique MAC's, be aware that some cheap NICs use the
same MAC address on multiple cards....

[Olivier Vernet]

Hi Stefan,

First of all, thanks to continue to investigate on this problem.

I've tried to increase the number of rx-packets and fixed it to 256.

The timeout still occurred but without the previous message
MAL error occured.... ISR = c0100010 UIC = = 2 MAL_DEF = e0100000 MAL_ERR= e0000000 About preceeding transfer (eth0)


It's true that there is quite a lot of broadcoasts on the network, and I have the feeling that timeouts are less frequent this week as there is a lot
of people on vacation (and so a lot of computer shutdown).

Perhaps it's a way to investigate.

Best regards

Olivier







-----Message d'origine-----
De?: Stefan Roese [mailto:sr at denx.de]
Envoy??: lundi 7 ao?t 2006 15:03
??: u-boot-users at lists.sourceforge.net
Cc?: Olivier Vernet; Philippe Villet; wd at denx.de
Objet?: Re: [U-Boot-Users] TFTP timeout

Hi Olivier,

Post by Olivier Vernet
Yes, the behaviour changes with the network topology. On some
switch, timeout occurs more often, but in the manufacturing center,
we have an "island network", and it seems that the problem have not be
reproduced.

Do you have lot's of broadcasts on your "main" network connection? Please try
to increase the number of rx-packets again. For example:

#define CFG_RX_ETH_BUFFER 256

And please let me know if this helped. Thanks.

Best regards,
Stefan