[U-Boot-Users] TFTP timeout

[U-Boot-Users] TFTP timeout

[Olivier Vernet]

>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

[U-Boot-Users] TFTP timeout

[Stefan Roese]

Hi Olivier,

On Wednesday 02 August 2006 17:06, Olivier Vernet wrote:
> >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

[U-Boot-Users] TFTP timeout

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

On Wednesday 02 August 2006 18:11, Olivier Vernet wrote:
> 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

[U-Boot-Users] TFTP timeout

[Olivier Vernet]

>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

[U-Boot-Users] TFTP timeout

[Rune Torgersen]

> From: Olivier Vernet
> Sent: Wednesday, August 02, 2006 11:11
> 
> >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....

[U-Boot-Users] TFTP timeout

[Stefan Roese]

Hi Olivier,

On Wednesday 02 August 2006 18:11, Olivier Vernet wrote:
> 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

[U-Boot-Users] TFTP timeout

[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

Stefan Roese wrote:
> Hi Olivier,
> 
> On Wednesday 02 August 2006 18:11, Olivier Vernet wrote:
>> 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
> 
> -------------------------------------------------------------------------
> 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

[U-Boot-Users] TFTP timeout

[Olivier Vernet]

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

[U-Boot-Users] TFTP timeout

[Wolfgang Denk]

In message <0507D414482B204FA4848540C2656A381BD631@ENIEXCH01.ds.jdsu.net> you wrote:
>
> 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.

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

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Clothes make the man. Naked people have little  or  no  influence  on
society.                                                 - Mark Twain

[U-Boot-Users] TFTP timeout

[Philippe Villet]

Stefan,


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

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

[U-Boot-Users] TFTP timeout

[Wolfgang Denk]

In message <OFAFE46708.DE40F363-ONC12571BC.004554D2-C12571BC.00474EB1@acterna.com> you wrote:
>
> <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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offence.
          -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

[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 

[U-Boot-Users] TFTP timeout

[Stefan Roese]

Hi Philippe,

On Friday 28 July 2006 17:13, Philippe Villet wrote:
> 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.

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

[U-Boot-Users] TFTP timeout

[Wolfgang Denk]

In message <F9D1A9212590B640B744B50EF9E01686037BC5@ENIEXCH01.ds.jdsu.net> you wrote:
> 
> 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)?

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is better to marry than to burn.
                                - Bible ``I Corinthians'' ch. 7, v. 9

[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/530ea319/attachment.htm 

[U-Boot-Users] TFTP timeout

[Stefan Strobl]

Hi Philippe

Philippe Villet wrote:
> 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

[U-Boot-Users] tftp timeout

[Andre Puschmann]

hallo,
i know this newsgroup already talked about this subject and of course i
read this stuff but there are still some questions ..

i am currently trying to download a kernel image via tftp from a
tftp-server on my hostpc which is connected through a ethernet-switch.
but i always get timeouts .. look at this:

<log>
Load address: 0x20800000
Loading: *\0x08#######T ##################################T
###################T ####T ##T #
\0x09 ###T #T #########T ########T #############T ##T #############T
########T #############T
\0x09 #####T ###T ######T #######T #######T #############T ##T
##############T ###########
\0x09 ###########
done
</log>

i mean .. the transfer is ok .. but it takes ages :-)


it looks like this if i connect my board directly to my hostpc.

<log>
Load address: 0x20800000
Loading: *\0x08T
#################################################################
\0x09 #################################################################
\0x09 #################################################################
\0x09 ###########
done
</log>


does anybody got the same issues?
i mean there is no huge traffic on the net and my local tftp client 
loads the 1MB kernel-image in seconds.
i am using u-boot-1.1.1 and i also tried u-boot-1.1.4!

regards
andre

[U-Boot-Users] tftp timeout

[Jerry Van Baren]

Andre Puschmann wrote:
> hallo,
> i know this newsgroup already talked about this subject and of course i
> read this stuff but there are still some questions ..
> 
> i am currently trying to download a kernel image via tftp from a
> tftp-server on my hostpc which is connected through a ethernet-switch.
> but i always get timeouts .. look at this:
> 
> <log>
> Load address: 0x20800000
> Loading: *\0x08#######T ##################################T
> ###################T ####T ##T #
> \0x09 ###T #T #########T ########T #############T ##T #############T
> ########T #############T
> \0x09 #####T ###T ######T #######T #######T #############T ##T
> ##############T ###########
> \0x09 ###########
> done
> </log>
> 
> i mean .. the transfer is ok .. but it takes ages :-)
> 
> 
> it looks like this if i connect my board directly to my hostpc.
> 
> <log>
> Load address: 0x20800000
> Loading: *\0x08T
> #################################################################
> \0x09 #################################################################
> \0x09 #################################################################
> \0x09 ###########
> done
> </log>
> 
> 
> does anybody got the same issues?
> i mean there is no huge traffic on the net and my local tftp client 
> loads the 1MB kernel-image in seconds.
> i am using u-boot-1.1.1 and i also tried u-boot-1.1.4!
> 
> regards
> andre

My guess is that you have a full duplex/half duplex problem.  Verify 
that your board/u-boot is setting your ethernet to the proper duplex 
(full/half).  I'm guessing your board is half duplex but your switch is 
full (typical of a switch ;-).

The switch sends traffic to your board while your board is 
transmitting... that is a collision (late collision at that) to your 
board but is OK to the switch.  This doesn't happen nearly as much with 
your PC since you have a dedicated link without much asynchronous traffic.

This is a FAQ type problem where the software (u-boot/linux) needs to 
poll the PHY chip for duplex and then (re)configure the MAC chip 
(separate or built into the CPU) to match.  If the poll isn't happening 
or has a bug, you have a problem.

gvb

[U-Boot-Users] tftp timeout

[Wolfgang Denk]

In message <443CEA56.8010701@smiths-aerospace.com> you wrote:
>
> This is a FAQ type problem where the software (u-boot/linux) needs to 
> poll the PHY chip for duplex and then (re)configure the MAC chip 

Thanks for this nice summary. It is now indeed a FAQ problem:
http://www.denx.de/wiki/DULG/TFTPTimeout

Thanks again!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A conservative is a man who believes that nothing should be done for
the first time.                                   - Alfred E. Wiggam