[U-Boot-Users] tftpboot question

[U-Boot-Users] tftpboot question

[eagle keeper]

Hi all, and sorry for disturbing you again.
I'm trying to load an image from a tftp server using tftpboot.
Server is reachable, and running. Address of image is correct.
U-boot contacts the right IP, then tries to load the image and intead
of printing "#" as documented, prints "T" (it means timeout I
suppose).
But I continue getting an error message: "Retry count exceeded"
Then the procedure starts again.

What this behaviour can depend from?
I excluded tftp configuration problems and network problems.

Thanks in andvance

[U-Boot-Users] tftpboot question

[richard at uclinux.net]

> Hi all, and sorry for disturbing you again.
> I'm trying to load an image from a tftp server using tftpboot.
> Server is reachable, and running. Address of image is correct.
> U-boot contacts the right IP, then tries to load the image and intead
> of printing "#" as documented, prints "T" (it means timeout I
> suppose).
> But I continue getting an error message: "Retry count exceeded"
> Then the procedure starts again.
> 
> What this behaviour can depend from?
> I excluded tftp configuration problems and network problems.

1. You can ping your server from within u-boot, right?

2. You can tftp download your image locally on your server, right?


best regards
rick

[U-Boot-Users] tftpboot question

[Jerry Van Baren]

eagle keeper wrote:
> Hi all, and sorry for disturbing you again.
> I'm trying to load an image from a tftp server using tftpboot.
> Server is reachable, and running. Address of image is correct.
> U-boot contacts the right IP, then tries to load the image and intead
> of printing "#" as documented, prints "T" (it means timeout I
> suppose).
> But I continue getting an error message: "Retry count exceeded"
> Then the procedure starts again.
> 
> What this behaviour can depend from?
> I excluded tftp configuration problems and network problems.
> 
> Thanks in andvance

I would suspect your ethernet receiver is having problems with larger 
packets (probably a hardware configuration issue).  I don't know what 
processor you are using, but a classic problem is that short packets 
(pings) work because the packet fits entirely in the ethernet FIFO 
buffer, but long packets (tftp data) break because the ethernet FIFO 
cannot buffer the whole packet and the at-speed store to SDRAM is broken 
(cannot keep up with packets of length 1500 or so bytes and/or SDRAM 
bursting is broken).

gvb

[U-Boot-Users] tftpboot question

[Bharath]

Hi,

>Hi all, and sorry for disturbing you again.
>I'm trying to load an image from a tftp server using tftpboot.
>Server is reachable, and running. Address of image is correct.
>U-boot contacts the right IP, then tries to load the image and intead
>of printing "#" as documented, prints "T" (it means timeout I
>suppose).
>But I continue getting an error message: "Retry count exceeded"
>Then the procedure starts again.

>What this behaviour can depend from?
>I excluded tftp configuration problems and network problems.


Are you running tftpd on a linux box?  Try turning off your firewall !
Sometimes UDP packets are blocked .... 

Try Tftping small files 1K and see if they work ... And If by chance you are
using montavista binaries for tftpd , in all probability they wont work with
u-boot.It did not work with a PQ2FADS-ZU board for me (even for their
customer support here in INDIA).

Cheers,

.Bharath.


EGO iS NotHinG wIthOuT ArrOgAncE tO BaCk iT uP..."




DISCLAIMER 
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to 
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, 
please notify the sender immediately by return e-mail and delete it from your computer

[U-Boot-Users] tftpboot question

[Reeve Yang]

I'm trying to use tftpboot to copy linux image into flash starting address
is 0xff300000, so I defined CFG_DIRECT_FLASH_TFTP. It looks data have been
written into flash since there is no any error. However, when I try to boot
linux, it returns gunzip error. If I download the same image using xmodem,
the kernel just boots fine. Do I need to do anything special for tftp direct
to flash? If I tftp image into ram(0x800000) then boot, it's just fine too.

### main_loop: bootcmd="bootm $loadaddr"
Hit any key to stop autoboot:  0
## Booting image at ff300000 ...
## Current stack ends at 0x0F5D0BB8 => set upper limit to 0x00800000
bd address  = 0x0F5D0FB8
memstart    = 0x00000000
memsize     = 0x10000000
flashstart  = 0xFF000000
flashsize   = 0x01000000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xE0000000
bootflags   = 0x00000001
intfreq     =    264 MHz
busfreq     =    132 MHz
ethaddr     = 00:04:9F:11:22:33
eth1addr    = 00:E0:0C:00:7D:01
IP addr     = 10.1.0.10
baudrate    = 115200 bps
## Transferring control to Linux at ff300000 with bd at 007fffb0 ...

loaded at:     FF300000 FFA94124
relocated to:  00800000 00F94124
board data at: 007FFFB0 007FFFF8
relocated to:  00805114 0080515C
zimage at:     008058D5 00904243
initrd at:     00905000 00F91864
avail ram:     00F95000 01395000

Linux/PPC load: mem=248M
Uncompressing Linux...inflate returned FFFFFFFD
exit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061031/0c746d7e/attachment.htm 

[U-Boot-Users] tftpboot question

[Wolfgang Denk]

In message <198592450610311513h50d4598awc0666aac00643c50@mail.gmail.com> you wrote:
>
> I'm trying to use tftpboot to copy linux image into flash starting address
> is 0xff300000, so I defined CFG_DIRECT_FLASH_TFTP. It looks data have been

Why are you doing this? The recommended method is to load the image to
RAM first, and then use "cp" to write it to flash.

> written into flash since there is no any error. However, when I try to boot

Did you use the "iminfo" command after writing the image  tpo  flash?
What does it say?

> linux, it returns gunzip error. If I download the same image using xmodem,
> the kernel just boots fine. Do I need to do anything special for tftp direct
> to flash? If I tftp image into ram(0x800000) then boot, it's just fine too.
> 
> ### main_loop: bootcmd="bootm $loadaddr"
> Hit any key to stop autoboot:  0
> ## Booting image at ff300000 ...
> ## Current stack ends at 0x0F5D0BB8 => set upper limit to 0x00800000
> bd address  = 0x0F5D0FB8
> memstart    = 0x00000000
> memsize     = 0x10000000
> flashstart  = 0xFF000000
> flashsize   = 0x01000000
> flashoffset = 0x00000000
> sramstart   = 0x00000000
> sramsize    = 0x00000000
> immr_base   = 0xE0000000
> bootflags   = 0x00000001
> intfreq     =    264 MHz
> busfreq     =    132 MHz
> ethaddr     = 00:04:9F:11:22:33
> eth1addr    = 00:E0:0C:00:7D:01
> IP addr     = 10.1.0.10
> baudrate    = 115200 bps
> ## Transferring control to Linux at ff300000 with bd at 007fffb0 ...
> 
> loaded at:     FF300000 FFA94124
> relocated to:  00800000 00F94124
> board data at: 007FFFB0 007FFFF8
> relocated to:  00805114 0080515C
> zimage at:     008058D5 00904243
> initrd at:     00905000 00F91864
> avail ram:     00F95000 01395000

This does not look like normal "bootm" command output to me. Are  you
sure  your  image was started by a bootm command? And are you sure it
is an uImage file in the first place?

To me this looks as if you were using the  Linux  kernel's  bootstrap
loader, which you must not do.

> Linux/PPC load: mem=248M
> Uncompressing Linux...inflate returned FFFFFFFD
> exit

This is NOT an U-Boot error message.

> ------=_Part_14139_17937139.1162336433719
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline

And please, don't post HTML here.

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