[U-Boot-Users] iminfo - Bad Header Checksum

[Dale Dunlea]

Hi All,

I started using U-Boot about 3 days ago, so apologies in advance if I
have missed something obvious in the documentation.

I'm using a Metrowerks MPC8540 test board, which came pre-installed with
U-Boot 1.0.1(eval-20040206-0-pre4). I suspect that this may be part of
the problem i.e. that I have an old version of U-Boot burned to flash. I
do not currently have the means to re-flash the board back to its
current state, and so I am reluctant to try and upgrade U-Boot just yet.

I downloaded ELDK 3.1.1 and built the kernel, using make uImage. I then
downloaded the uImage via TFTP to the board. Running iminfo results in
"Bad Header Checksum". I ran mkimage -l to verify that there was a valid
header in place, and there does seem to be.

Also, I know that there is no problem with my TFTP setup as I have been
able to download and execute the "Hello World" example program.

I would appreciate any pointers on where I am going wrong.

Thanks in advance,
Dale Dunlea

[Dale Dunlea]

Post by Dale Dunlea
I'm using a Metrowerks MPC8540 test board, which came pre-installed
with U-Boot 1.0.1(eval-20040206-0-pre4). I suspect that this may be
part of the problem i.e. that I have an old version of U-Boot burned
to flash. I do not currently have the means to re-flash the board back
to its current state, and so I am reluctant to try and upgrade U-Boot
just yet.

I've done a little bit more digging and have discovered the following:

If I zero out the CRC block on my downloaded image and run the crc32
command, it generates the same CRC that was already in there, implying
that it is correct. I then copied the Linux image which is stored in
flash down into ram, and ran iminfo. The image passed. I then zeroed the
CRC block of this image, and ran the crc32 command. The CRC it generated
was different from the one that had been there.

It appears to me that Metrowerks have flashed a modified version of
U-Boot which uses a different checksum function when verifying the
header. If this is the case, then presumably under the terms of the GPL,
they have to publish their changes? I've not been able to find anything
to this effect though.

Has anyone else used this board? Further searching of the archives led
me to this thread:

http://sourceforge.net/mailarchive/message.php?msg_id=9964369

Which seems to be exactly the problem I am having. Unfortunately, that
thread seems to end without a resolution.

Again, thanks to anyone who can shed light on the situation.

Regards,
Dale Dunlea

[Wolfgang Denk]

Post by Dale Dunlea
It appears to me that Metrowerks have flashed a modified version of
U-Boot which uses a different checksum function when verifying the
header. If this is the case, then presumably under the terms of the GPL,

Instead of starting wild speculations you rather provide some more
detailed informatioon, like the EXACT commands you used on your board
to download the image and to verify that it was consistent. Did you -
for example try to "md" the header part of the image? And maybe you
tries a hex dump of the image on your host system, too?

Best regards,

Wolfgang Denk

[richard]

huomenta
(morning ;o)


Needed to clean my head off a little...
...so what's better than a quick hack of u-boot (o;


http://www.uclinux.net/forum/viewtopic.php?t=112


...now back to my work and to everyone a good start (o;


best regards
rick

[Wolfgang Denk]

Dear Dale,

Apolgies if I was not clear earlier. I downloaded my image over TFTP (as
metioned in my first post) and subsequently via kermit and Srecord. The
results were identical in each case.

Please don't describe what you did, but instead post the EXACT
commands you used.

Whilst verifying the downloaded images, as mentioned earlier, I examined
the CRC and Magic Number elements of the downloaded images, using MD,

And what was the exact output?

ordering, on both the host system and the target board. To my mind,
there is a definite inconsistency in the fact that a CRC generated by
the crc32 command on my installation of U-Boot fails to pass a CRC test
performed by U-Boot on the self-same board.

You provide a lot of description of things you did or think without
showing any exact data - it's impossible to help you this way. Please
try to answer the questions we ask, and provide EXACT the information
we ask for.

Best regards,

Wolfgang Denk

[Dale Dunlea]

Post by Wolfgang Denk
Please don't describe what you did, but instead post the EXACT
commands you used.

Once more with feeling then: In the following, test.img is the uImage of
the Linux kernel as created by "make uImage"

U-Boot 1.0.1(eval-20040206-0-pre4) (Jun 18 2004 - 20:17:00)

Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
Board: Motorola MPC8540ADS Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: DDR module detected, total size:256MB.
256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: MOTO ETHERNET
Hit any key to stop autoboot: 3

Metrowerks=> setenv serverip 10.82.190.3

Metrowerks=> tftpboot 0 test.img

Enet starting in Full Duplex
Enet starting in 1000BT
TFTP from server 10.82.190.3; our IP address is 10.82.190.238
Filename 'test.img'.
Load address: 0x0
Loading: *packetHandler changed.
#################################################################
#################################################################
done
Bytes transferred = 662475 (a1bcb hex)

// Image has been transferred over TFTP.

Metrowerks=> imi

## Checking Image at 00000000 ...
Bad Header Checksum

// Image passes magic number, but fails header checksum

Metrowerks=> md 0
00000000: 27051956 32cf8de9 429679c4 000a1b8b '..V2...B.y.....
00000010: 00000000 00000000 fbc58b91 05070201 ................
00000020: 4c696e75 782d322e 342e3235 00000000 Linux-2.4.25....
00000030: 00000000 00000000 00000000 00000000 ................
00000040: 1f8b0808 c4799642 0203766d 6c696e75 .....y.B..vmlinu
00000050: 7800e45a 7b705455 9aff6e3f 4847b2da x..Z{pTU..n?HG..
00000060: 03371848 0889526e 82198c2b d4deee0e .7.H..Rn...+....
00000070: cd0d32b5 8d61a65a 2aa133cc ba760cd6 ..2..a.Z*.3..v..
00000080: 90c1a965 30ccded1 db7d6f27 714a843f ...e0....}o'qJ.?
00000090: 3ae96417 356ae3a3 4b468b8d 33503ef0 :.d.5j..KF..3P>.
000000a0: 7179e8ca e254b53a e06311c3 80250833 qy...T.:.c...%.3
000000b0: 1305c6f0 cadddf77 bb034978 84dd2a2d .......w..Ix..*-
000000c0: 7793aad4 bde73be7 7ce77bfc bec7b949 w.....;.|.{....I
000000d0: 9888c2d9 5f552b54 d4c7af57 d4d76e54 ...._U+T...W..nT
000000e0: d4bdb728 ea699fe2 033d40a5 0d2a510a ...(.i...=@..*Q.
000000f0: 6b2ad542 7baa8a0c ac2fe953 a7d8530b k*.B{..../.S..S.

// Magic number 27051956 can be seen, and checksum of 32cf8de9 is
located at offset 4

Metrowerks=> mw 4 0
Metrowerks=> crc32 0 40
CRC32 for 00000000 ... 0000003f ==> 32cf8de9

// Checksum returned by above command matches the checksum that had been
stored.

Metrowerks=> cp ff800000 0 100000
// Copy pre-existing kernel image from flash
Metrowerks=> imi 0

## Checking Image at 00000000 ...
Image Name: Linux-2.4.25-mpc8540eval-20040322
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 921746 Bytes = 900.1 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK

// This image verifies ok - examine header structure

Metrowerks=> md 0
00000000: 27051956 2ae32b83 40d31f5f 000e1092 '..V*.+. at .._....
00000010: 00000000 00000000 4f26d374 05070201 ........O&.t....
00000020: 4c696e75 782d322e 342e3235 2d6d7063 Linux-2.4.25-mpc
00000030: 38353430 6576616c 2d323030 34303332 8540eval-2004032
00000040: 32000000 00000000 00000000 1f8b0808 2...............
00000050: 5e1fd340 0203766d 6c696e75 7800d45a ^.. at ..vmlinux..Z
00000060: 7b741455 9affaad3 0d792995 a2814042 {t.U.....y)... at B
00000070: a8c48809 844ca361 a8ee8450 019c2948 .....L.a...P..)H
00000080: 764e1313 8880330d 09ca233b 1b21ccd6 vN....3...#;.!..
00000090: e0edaaea a49c05e4 9ced24cd 1c0ea006 ..........$.....
000000a0: 85121975 5189c328 380dcb22 cacc1e60 ...uQ..(8.."...`
000000b0: 80519ce3 468505c4 3d071086 4c107bbf .Q..F...=...L.{.
000000c0: af3b0d51 303acf03 7fdcf3fb eefb77bf .;.Q0:........w.
000000d0: d7bdd589 0f00989e a1b2a7ee 52d9aed1 ............R...
000000e0: 2afbc37d 2abb52ac 1663bb02 e060fb6d *..}*.R..c...`.m
000000f0: 16eb04ab eac4ff7c c1ce255b 55a78c2c .......|..%[U..,
Metrowerks=> mw 4 0
Metrowerks=> crc32 0 40
CRC32 for 00000000 ... 0000003f ==> e28791ee

// Recalculated CRC doesn't match old working CRC

Metrowerks=> mw 4 e28791ee
Metrowerks=> md 0
00000000: 27051956 e28791ee 40d31f5f 000e1092 '..V.... at .._....
00000010: 00000000 00000000 4f26d374 05070201 ........O&.t....
00000020: 4c696e75 782d322e 342e3235 2d6d7063 Linux-2.4.25-mpc
00000030: 38353430 6576616c 2d323030 34303332 8540eval-2004032
00000040: 32000000 00000000 00000000 1f8b0808 2...............
00000050: 5e1fd340 0203766d 6c696e75 7800d45a ^.. at ..vmlinux..Z
00000060: 7b741455 9affaad3 0d792995 a2814042 {t.U.....y)... at B
00000070: a8c48809 844ca361 a8ee8450 019c2948 .....L.a...P..)H
00000080: 764e1313 8880330d 09ca233b 1b21ccd6 vN....3...#;.!..
00000090: e0edaaea a49c05e4 9ced24cd 1c0ea006 ..........$.....
000000a0: 85121975 5189c328 380dcb22 cacc1e60 ...uQ..(8.."...`
000000b0: 80519ce3 468505c4 3d071086 4c107bbf .Q..F...=...L.{.
000000c0: af3b0d51 303acf03 7fdcf3fb eefb77bf .;.Q0:........w.
000000d0: d7bdd589 0f00989e a1b2a7ee 52d9aed1 ............R...
000000e0: 2afbc37d 2abb52ac 1663bb02 e060fb6d *..}*.R..c...`.m
000000f0: 16eb04ab eac4ff7c c1ce255b 55a78c2c .......|..%[U..,
Metrowerks=> imi

## Checking Image at 00000000 ...
Bad Header Checksum

// Recalculated checksum differs


I hope this clarifies matters.

Regards,
Dale Dunlea

[Wolfgang Denk]

Post by Dale Dunlea
Metrowerks=> tftpboot 0 test.img

This CANNOT work. You are overwriting U-Boot exception vectors that
way. You are really, really lucky if this doesn';t crash your system
(it should crash).

Post by Dale Dunlea
I hope this clarifies matters.

Yes, it makes it pretty clear that this is a plain pilot error.

Try "tftp 200000 test.img" instead.



[Do you now understand why I insist in a log of the exact commands
instead of a description in prose?]

Best regards,

Wolfgang Denk

[Dale Dunlea]

Post by Wolfgang Denk

Post by Dale Dunlea
Metrowerks=> tftpboot 0 test.img

This CANNOT work. You are overwriting U-Boot exception vectors that
way. You are really, really lucky if this doesn';t crash your system
(it should crash).
Try "tftp 200000 test.img" instead.

The situation, though now in a legal addresses range, is no more
pleasant. See below for details:

U-Boot 1.0.1(eval-20040206-0-pre4) (Jun 18 2004 - 20:17:00)

Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
Board: Motorola MPC8540ADS Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: DDR module detected, total size:256MB.
256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: MOTO ETHERNET
Hit any key to stop autoboot: 3
Metrowerks=> setenv servrerip 10.82.190.3
Metrowerks=> tftpboot 200000 test.img
Enet starting in Full Duplex
Enet starting in 1000BT
TFTP from server 10.82.190.3; our IP address is 10.82.190.238
Filename 'test.img'.
Load address: 0x200000
Loading: *packetHandler changed.
#################################################################
#################################################################
done
Bytes transferred = 662475 (a1bcb hex)
Metrowerks=> imi

## Checking Image at 00200000 ...
Bad Header Checksum
Metrowerks=> md 200000
00200000: 27051956 32cf8de9 429679c4 000a1b8b '..V2...B.y.....
00200010: 00000000 00000000 fbc58b91 05070201 ................
00200020: 4c696e75 782d322e 342e3235 00000000 Linux-2.4.25....
00200030: 00000000 00000000 00000000 00000000 ................
00200040: 1f8b0808 c4799642 0203766d 6c696e75 .....y.B..vmlinu
00200050: 7800e45a 7b705455 9aff6e3f 4847b2da x..Z{pTU..n?HG..
00200060: 03371848 0889526e 82198c2b d4deee0e .7.H..Rn...+....
00200070: cd0d32b5 8d61a65a 2aa133cc ba760cd6 ..2..a.Z*.3..v..
00200080: 90c1a965 30ccded1 db7d6f27 714a843f ...e0....}o'qJ.?
00200090: 3ae96417 356ae3a3 4b468b8d 33503ef0 :.d.5j..KF..3P>.
002000a0: 7179e8ca e254b53a e06311c3 80250833 qy...T.:.c...%.3
002000b0: 1305c6f0 cadddf77 bb034978 84dd2a2d .......w..Ix..*-
002000c0: 7793aad4 bde73be7 7ce77bfc bec7b949 w.....;.|.{....I
002000d0: 9888c2d9 5f552b54 d4c7af57 d4d76e54 ...._U+T...W..nT
002000e0: d4bdb728 ea699fe2 033d40a5 0d2a510a ...(.i...=@..*Q.
002000f0: 6b2ad542 7baa8a0c ac2fe953 a7d8530b k*.B{..../.S..S.
Metrowerks=> mw 200004 0
Metrowerks=> md 200000
00200000: 27051956 00000000 429679c4 000a1b8b '..V....B.y.....
00200010: 00000000 00000000 fbc58b91 05070201 ................
00200020: 4c696e75 782d322e 342e3235 00000000 Linux-2.4.25....
00200030: 00000000 00000000 00000000 00000000 ................
00200040: 1f8b0808 c4799642 0203766d 6c696e75 .....y.B..vmlinu
00200050: 7800e45a 7b705455 9aff6e3f 4847b2da x..Z{pTU..n?HG..
00200060: 03371848 0889526e 82198c2b d4deee0e .7.H..Rn...+....
00200070: cd0d32b5 8d61a65a 2aa133cc ba760cd6 ..2..a.Z*.3..v..
00200080: 90c1a965 30ccded1 db7d6f27 714a843f ...e0....}o'qJ.?
00200090: 3ae96417 356ae3a3 4b468b8d 33503ef0 :.d.5j..KF..3P>.
002000a0: 7179e8ca e254b53a e06311c3 80250833 qy...T.:.c...%.3
002000b0: 1305c6f0 cadddf77 bb034978 84dd2a2d .......w..Ix..*-
002000c0: 7793aad4 bde73be7 7ce77bfc bec7b949 w.....;.|.{....I
002000d0: 9888c2d9 5f552b54 d4c7af57 d4d76e54 ...._U+T...W..nT
002000e0: d4bdb728 ea699fe2 033d40a5 0d2a510a ...(.i...=@..*Q.
002000f0: 6b2ad542 7baa8a0c ac2fe953 a7d8530b k*.B{..../.S..S.
Metrowerks=> crc32 200000 40
CRC32 for 00200000 ... 0020003f ==> 32cf8de9

Regards,
Dale Dunlea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20050530/c8061217/attachment.htm

[Wolfgang Denk]

Post by Dale Dunlea
The situation, though now in a legal addresses range, is no more

...

Post by Dale Dunlea
Metrowerks=> tftpboot 200000 test.img
Enet starting in Full Duplex
Enet starting in 1000BT
TFTP from server 10.82.190.3; our IP address is 10.82.190.238
Filename 'test.img'.
Load address: 0x200000
Loading: *packetHandler changed.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This message is suspicious. It is not part of the standard U-Boot code.

Post by Dale Dunlea
## Checking Image at 00200000 ...
Bad Header Checksum
Metrowerks=> md 200000
00200000: 27051956 32cf8de9 429679c4 000a1b8b '..V2...B.y.....

...

Post by Dale Dunlea
Metrowerks=> crc32 200000 40
CRC32 for 00200000 ... 0020003f ==> 32cf8de9

This makes little sense to me. I seriously doubt that different
implementations of the CRC32 code would be used in the imi and bootm
commands.

Can you please send me a copy of your test.img file? (Send it to me
only, not to the list.)

Post by Dale Dunlea
--------------070409080405020000000002
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>

And please don't post HTML here!

Best regards,

Wolfgang Denk

[Wolfgang Denk]

Post by Dale Dunlea
Metrowerks=> tftpboot 200000 test.img
Enet starting in Full Duplex
Enet starting in 1000BT
TFTP from server 10.82.190.3; our IP address is 10.82.190.238
Filename 'test.img'.
Load address: 0x200000
Loading: *packetHandler changed.
#################################################################
#################################################################
done
Bytes transferred = 662475 (a1bcb hex)
Metrowerks=> imi
## Checking Image at 00200000 ...
Bad Header Checksum
Metrowerks=> md 200000
00200000: 27051956 32cf8de9 429679c4 000a1b8b '..V2...B.y.....
00200010: 00000000 00000000 fbc58b91 05070201 ................
00200020: 4c696e75 782d322e 342e3235 00000000 Linux-2.4.25....
00200030: 00000000 00000000 00000000 00000000 ................
00200040: 1f8b0808 c4799642 0203766d 6c696e75 .....y.B..vmlinu
00200050: 7800e45a 7b705455 9aff6e3f 4847b2da x..Z{pTU..n?HG..

...


=> tftp 200000 test.img
Using FEC ETHERNET device
TFTP from server 192.168.1.1; our IP address is 192.168.160.4
Filename 'test.img'.
Load address: 0x200000
Loading: #################################################################
#################################################################
done
Bytes transferred = 662475 (a1bcb hex)
=> imi

## Checking Image at 00200000 ...
Image Name: Linux-2.4.25
Created: 2005-05-27 1:37:08 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 662411 Bytes = 646.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> md 200000
00200000: 27051956 32cf8de9 429679c4 000a1b8b '..V2...B.y.....
00200010: 00000000 00000000 fbc58b91 05070201 ................
00200020: 4c696e75 782d322e 342e3235 00000000 Linux-2.4.25....
00200030: 00000000 00000000 00000000 00000000 ................
00200040: 1f8b0808 c4799642 0203766d 6c696e75 .....y.B..vmlinu
00200050: 7800e45a 7b705455 9aff6e3f 4847b2da x..Z{pTU..n?HG..
...


I didn't want to believe it, but it seems that you are right:
Metrowerks seems to have changed U-Boot in some incompatible way. As
them for the source code of the version they distribute, and please
let me know if there should be any problems with that.

My recommendation: get rid of their crippled version.

Best regards,

Wolfgang Denk

[Dale Dunlea]

Post by Wolfgang Denk
Metrowerks seems to have changed U-Boot in some incompatible way. As
them for the source code of the version they distribute, and please
let me know if there should be any problems with that.

I was reluctant to believe it myself. Thank you for taking the time to
investigate what must have seemed like a rather outlandish claim from a
newbie. I will contact Metrowerks immediately.

Post by Wolfgang Denk
My recommendation: get rid of their crippled version.

I should have access to a flash programmer sometime tomorrow, at which
point, I fully intend to nuke the existing version and replace it with
the version I have built from the ELDK.

Regards,
Dale Dunlea