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

[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

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

[Dale Dunlea]

I wrote:

> 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

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

[Wolfgang Denk]

In message <429A334F.9070408@commergy.com> you wrote:
> 
> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is better to marry than to burn.
                                - Bible ``I Corinthians'' ch. 7, v. 9

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

[Wolfgang Denk]

Dear Dale,

in message <429A6A6C.10106@commergy.com> you wrote:
> 
> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never call a man a fool.  Borrow from him.

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

[Dale Dunlea]

>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

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

[Wolfgang Denk]

In message <429AE902.2000209@commergy.com> you wrote:
> 
> 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).

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hacking's just another word for nothing left to kludge.

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

[Dale Dunlea]

Wolfgang Denk wrote:

>In message <429AE902.2000209@commergy.com> you wrote:
>  
>
>>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 

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

[Wolfgang Denk]

In message <429AEC4E.8040202@commergy.com> you wrote:
>
> The situation, though now in a legal addresses range, is no more 
> pleasant. See below for details:
...
> 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.

> ## Checking Image at 00200000 ...
>    Bad Header Checksum
> Metrowerks=> md 200000
> 00200000: 27051956 32cf8de9 429679c4 000a1b8b    '..V2...B.y.....
...
> 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.)

> --------------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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Thought for the day: What if there were no hypothetical situations?

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

[Wolfgang Denk]

In message <429AEC4E.8040202@commergy.com> you wrote:
>
> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

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

[Dale Dunlea]

>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.
>
>  
>
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.

>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