tftp produces bad header checksum ?

I'm using u-boot 1.0.1 on a Metroworks MPC8540ADS board. I think I've set-up bootp and tftp correctly, but after download, u-boot says the image has a bad header checksum.

Here's what the download looks like:

Metrowerks=> bootp 4000000
Enet starting in Full Duplex
Enet starting in 100BT
BOOTP broadcast 1
packetHandler changed.
TFTP from server 10.82.190.239; our IP address is 10.82.190.238 Filename '/tftpboot/EEBE520A.img'.
Load address: 0x4000000
Loading: packetHandler changed.
#################################################################
#################################################################

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

done
Bytes transferred = 906528 (dd520 hex)
Metroworks=> bootm 4000000
## Booting Image at 04000000
Bad Header Checksum
Metrowerks=> iminfo
## Checking Image at 04000000 ...
Bad Header Checksum
Metrowerks=> crc32 4000000 dd520
CRC32 for 04000000 ... 040dd51f ==> d315f12f
Metrowerks=>

I initially tried it at address 1000000 with the same result.

I'm building the image with 'make uImage'. Here's the last few lines of output:

make[2]: Entering directory `/opt/linuxppc-2.4/arch/ppc/boot/images' powerpc-603e-linux-gnu-objcopy --strip-all -S -O
binary /opt/linuxppc-2.4/vmlinux vmlinux
gzip -vf9 vmlinux
vmlinux: 55.0% -- replaced with vmlinux.gz
make[2]: Leaving directory `/opt/linuxppc-2.4/arch/ppc/boot/images' /bin/sh /opt/linuxppc-2.4/scripts/mkuboot.sh -A ppc -O linux -T kernel \
-C gzip -a 00000000 -e 00000000 \
-n 'Linux-2.4.26-pre5-moto-pq3-2004_06_04-0' \
-d images/vmlinux.gz images/vmlinux.UBoot

Image Name:   Linux-2.4.26-pre5-moto-pq3-2004_
Created:      Tue Nov  2 10:37:34 2004
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:    906464 Bytes = 885.22 kB = 0.86 MB
Load Address: 0x00000000
Entry Point:  0x00000000

ln -sf vmlinux.UBoot images/uImage
rm -f ./mkuboot
make[1]: Leaving directory `/opt/linuxppc-2.4/arch/ppc/boot'

Does one have to build tftp images in a different way ?

krb

0x4000000 is 64 MB - how much RAM is on your board?

Try:

	md 04000000

and post the rsults...

This looks OK to me. Try a hexdump of the first 64 bytes of the image on your build host, and then of the loaded file in U-Boot. Compare.

Maybe you have a memory corruption problem.

Best regards,

Wolfgang Denk

See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I don't document something, it's usually either for a good reason,
or a bad reason.  In this case it's a good reason.  :-)
                 - Larry Wall in <[email protected]>

BTW, I got kermit downloading working and it does the same thing, so I changed the subject to avoid confusing other readers.

256MB

Here's the one at 0x01000000. It's the same everywhere I try it.

01000000: 27051956 3f6f2360 418155cd 0004c42d    '..V?o#`A.U....-
01000010: 00000000 00000000 27cee1e0 05070201    ........'.......
01000020: 4c696e75 782d322e 342e3235 00000000    Linux-2.4.25....
01000030: 00000000 00000000 00000000 00000000    ................
01000040: 1f8b0808 cc558141 0203766d 6c696e75    .....U.A..vmlinu
01000050: 7800e45b 0d705455 963eaf7f 42b7c1d0    x..[.pTU.>..B...

They're identical.

It runs the built-in Linux image ok. Perhaps the vendor changed the loader or the crc algorithm ? I don't know why, I just can't think of anything else.

Thanks,
krb

So what is /tftpboot/EEBE420A.img a copy of/symlink to? Is it the resultant uImage, or one of the other kernel images (zImage etc..)?

Andre

vmlinux.UBoot. I've also tried an image from another build, 8245 based, in case there's something wrong with this mkimage, but it doesn't work either. Yet, both images pass crc on the 8245 based board.

I'll try upgrading the u-boot on the vendor's board.

Thanks,
krb