[U-Boot-Users] 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
In message 200411040809.16589.kevin.bailey@ind.alcatel.com you wrote:
Metrowerks=> bootp 4000000
0x4000000 is 64 MB - how much RAM is on your board?
Metrowerks=> iminfo ## Checking Image at 04000000 ... Bad Header Checksum
Try:
md 04000000
and post the rsults...
Does one have to build tftp images in a different way ?
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
BTW, I got kermit downloading working and it does the same thing, so I changed the subject to avoid confusing other readers.
On Thursday 04 November 2004 08:39 am, you wrote:
In message 200411040809.16589.kevin.bailey@ind.alcatel.com you wrote:
Metrowerks=> bootp 4000000
0x4000000 is 64 MB - how much RAM is on your board?
256MB
Metrowerks=> iminfo ## Checking Image at 04000000 ... Bad Header Checksum
Try:
md 04000000
and post the rsults...
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...
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.
They're identical.
Maybe you have a memory corruption problem.
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
On Thursday 04 November 2004 12:08 pm, you wrote:
Filename '/tftpboot/EEBE520A.img'.
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..)?
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
participants (3)
-
Andre Renaud -
Kevin Bailey -
Wolfgang Denk