• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 1501 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

tftpboot timeout problem

Helmut Forren
Mastermind 6805 points
Other Parts Discussed in Thread: OMAPL138, AM1808

Custom board derived from DM6467T EVM, aka Spectrum Digital HD1080P EVM.  

I have gotten tftpboot to work many times in the past, but I always have trouble with timeouts.  Right now, the trouble is overwhelming and I can't get the tftpboot to complete. The retry count gets exceeded and the transfer starts again.  I haven't had the patience to wait long enough to see if it ever works.  

Note that I'm using a Linksys WRT610N Ver 2 Gigabit router.  The router includes connections to a cable modem, the target board, my desktop WinMCE pc hosting VMWare with Ubuntu client running the TFTP server atftpd, as well as a couple laptops on wireless.

I found this link: http://www.denx.de/wiki/DULG/TFTPTimeout

Question 1 seems germane.  It suggests "The software (U-Boot/Linux) needs to poll the PHY chip for duplex mode 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 problems like described above."

But I don't understand how to follow that advice.  Any suggestions would be greatly appreciated.

Thanks,

Helmut

  • 0
    Guru 26430 points

    I find that TFTP on bootloaders don't like to be on networks with a lot of background chatter. Something to do with unexpected asynchronous packets that reset the link. I usually find that I have have the target and TFTP server on their own router. Seems that most people just work around it rather than fixing the U-Boot code.

  • 0 in reply to Norman Wong
    Expert 1985 points

    I modified some codes in u-boot, just set the mode, and I never see any timeout at all. might be something wrong with the hardware?

    I'm using external 50M clock to supply PHY and CPU.

  • 0 in reply to Power Pan
    Mastermind 6805 points

    Power Pan,

    Thanks very much for your input.  Would you please be so kind as to answer a couple of specific questions for me.

    1) At exactly what web address did you get your copy of the u-boot source code?

    2) You said you set the mode.  Please tell me exactly what you did; perhaps include a code snippet with the changed lines noted.  Also, was this change related to any timeout possibility?  That is, I've seen mention of half- vs full-duplex.  Is this what you changed?

    Please note that I don't get timeouts either when I direct cable to my host PC, but this is a complicated procedure for me vs my normal computer setup.  It's when I'm connected through a router that I have the trouble.  Elsewhere in this post I've mentioned a .de link where it's suggested that the problem is miscellaneous traffic confusing u-boot, where u-boot is running half-duplex.

    Finally, just out of curiosity, I ask:  "Are you running the CPU with a 50MHz clock?  I thought it was only supposed to run with 33MHz?  Are you changing the CPU PLL so that it still runs at 1GHz or lower (DM6467T), or are you truly overclocking successfully?

    Thanks again,

    Helmut

  • 0 in reply to Helmut Forren
    Expert 1985 points

    Hi, Helmut,

     

    I'm using OMAPL138/AM1808 u-boot, link could be found in the product page. I don't think TI will change a lot on the code so that I reply.

    there's a patch for u-boot, don't know if you patch or not. (for MDIO)

    I modified the code in ether.c to manual set the mode to "auto all, full duplex"(so that I could save some space for the setting resisters), but I have to say I did not test in a busy traffic environment cause most of the time I use direct cable link with my PC.

    I found some posts on this forum telling timeout using bad clock supply, that's why I said I use 50MHz clock, I'm using RMII interface that needs 50MHz clock supply, nothing related with the CPU. and I found some hardware design bugs that will cause the PLL output unstable clock to make the communication broken sometimes.

    that's all I have at this time.

    good luck!

    Best regards,

    Power Pan

     

  • 0 in reply to Power Pan
    Mastermind 6805 points

    This problem went away last year, but it just came back all of a sudden.  I did tftpboot successfully this morning.  Then, because the Ubuntu VM was running slow and I could hear the disk thrashing, I shut down the Ubuntu VM, closed VMware, rebooted my host Win7, restarted VMware, and restarted the Ubuntu VM.  I have done this same thing before, including moving from a dead WinXP host to a new Win7 host with new VMware install, and had no problem.    So I don't see why these restarts should be the cause of the problem.  Also, this particular target board has done numerous tftpboot's.  But now...

    After 20 or 30 minutes, my log is reading:

    tftpboot
    Using DaVinci EMAC device
    TFTP from server 192.168.123.18; our IP address is 192.168.123.19
    Filename 'uImage-HHS'.
    Load address: 0x80700000
    Loading: ##T #checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ##T #checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ###T #checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ###T #checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ##T T #T ##checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    #T ###checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    #T #checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ###checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ######checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ####T #T #T #########checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    checksum bad
    ##T #T ###T T #T #T ###T #####
             #########
    

    And, of couse, I did control-c in Teraterm to copy this out.  I forgot that Teraterm uses alt-c, and it sent a control-c to tftpboot and killed it... it was maybe getting close to done.  Darn.
    
			
    

		
		
		
		
	
    
	
    
		
    
			
		
    
	
    

	            
                	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
			
		
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    • 

		
	
  • 
		
    
			 


	
		
	
	









    
	
    
		
    
							
					
    
		
    
			
													0
							
			
				
									
							
						
				
			
			
			
												
						in reply to Helmut Forren
					
									
    
	
    
	                                    
                      
    
                        
                          Mastermind
                        6805 points
                      
    
                          
                   		
		
    
					
    ...I just restarted my router/switch/wireless and extra switch and cable modem.  The problem went away.  Dunno...  Maybe some computer was going hog wild over the Internet.  Haven't been able to ask others on this network if they started something different today...
    
			
    

		
		
		
		
	
    
	
    
		
    
			
		
    
	
    

	            
                	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
			
		
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    • 

		
	
  • 
		
    
			 


	
		
	
	









    
	
    
		
    
							
					
    
		
    
			
													0
							
			
				
									
							
						
				
			
			
			
												
						in reply to Helmut Forren
					
									
    
	
    
	                                    
                      
    
                        
                          Mastermind
                        6805 points
                      
    
                          
                   		
		
    
					
    info reference for next time (see "I had problems using tftpd in a VMware virtual machine"):   http://e2e.ti.com/support/embedded/linux/f/354/t/61432.aspx#221309
    
			
    

		
		
		
		
	
    
	
    
		
    
			
		
    
	
    

	            
                	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
			
		
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    •