[U-Boot-Users] tftp timeout

[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

[U-Boot-Users] Re: tftp timeout

[Andre Puschmann]

Jerry Van Baren wrote:
> 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
> 

thanks for your tip ..
sorry i am not that introduced in how autonegotiation works but i guess 
the function dm9161_AutoNegotiate() in dm9161.c does the related stuff.
i mean the switch i am using is a no-name one and with an other 
netg**r-switch it works nice, just tested it ... so it seems to be a bug 
in that fuctions, right??

regards
andre

[U-Boot-Users] Re: tftp timeout

[Jerry Van Baren]

Andre Puschmann wrote:
> Jerry Van Baren wrote:
>> 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
>>
> 
> thanks for your tip ..
> sorry i am not that introduced in how autonegotiation works but i guess 
> the function dm9161_AutoNegotiate() in dm9161.c does the related stuff.
> i mean the switch i am using is a no-name one and with an other 
> netg**r-switch it works nice, just tested it ... so it seems to be a bug 
> in that fuctions, right??
> 
> regards
> andre

As Smokey the Bear says, "Only YOU can debug your hardware."
   <http://en.wikipedia.org/wiki/Smokey_the_bear>
OK, so I'm lying, but it still is true.

Dump the MII registers and determine if your MAC is configured for full 
or half duplex in all situations:
* Powered up with the noname switch connected
* Unplug the noname switch (power applied)
* Plug in the noname switch (power applied)
* Repeat the first three steps with the Netgear switch
* Repeat the first three steps with a direct connection to your PC

Translate and correlate the register values.  The problem will probably 
show up in the differences.  Fix the problem and let us know what it was.

gvb