U-boot 脚本坏头 CRC

Question

我有一个“闪烁”脚本正在通过 sdp 从主机 PC 加载到 iMX6 上的 Uboot。脚本已运行完毕mkimage ，所以它有一个图像标题。这是 mkimage 命令:

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "U-Boot script" -d $files_dir$flash_txt $files_dir$flash_scr

我可以用 binwalk 解析标题:

$ binwalk -B flash.scr

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x315E128A, created: 2021-09-13 14:52:46, image size: 2406 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x7B909BAE, OS: Linux, CPU: ARM, image type: Script file, compression type: none, image name: "U-Boot script"

它无法执行，uboot 显示“Bad Header CRC”。因此，我试图至少在设备上通过使用内置的 crc32 工具在现场更正 CRC 来强制它工作。它仍然行不通。
这是我正在尝试的 uboot 命令(在脚本已经在内存中地址 0x10100000 之后):

# display the script bytes
md 0x10100000

# reset the crc
mw 0x10100004 0x0 1

# verify the change
md 0x10100000

# recalc the crc
crc32 0x10100000 64

# write the crc
#mw 0x10100004 <VALUE> 1

# example:
mw 0x10100004 0x3a833d99 1

# run the script
source 0x10100000

当我这样做时，我仍然收到可怕的“Bad Header CRC”错误!
我发现了许多显示/指示哪些字节包含“ header CRC”的来源。我已经看到多个消息来源说在尝试计算之前需要“重置”校验和。这一切看起来都是有效的逻辑。我究竟做错了什么？

更新
正确的 uboot 输入/结果
来自锯末的帮助

...
Bad header crc
CTRL+C - Operation aborted.
SDP ended
uboot# md 0x10100000
10100000: 56190527 229a2e76 f4f64161 66090000    '..Vv.."aA.....f
10100010: 00000000 00000000 0533a380 00060205    ..........3.....
10100020: 6f422d55 7320746f 70697263 00000074    U-Boot script...
10100030: 00000000 00000000 00000000 00000000    ................
10100040: 5e090000 00000000 20766e65 61666564    ...^....env defa
10100050: 20746c75 2d20662d 65730a61 766e6574    ult -f -a.setenv
10100060: 7a697320 79625f65 685f6574 725f7865     size_byte_hex_r
10100070: 66746f6f 33352073 35453937 65730a41    ootfs 5379E5A.se
10100080: 766e6574 7a697320 6c625f65 5f6b636f    tenv size_block_
10100090: 5f786568 746f6f72 32207366 30444239    hex_rootfs 29BD0
101000a0: 7465730a 20766e65 657a6973 7479625f    .setenv size_byt
101000b0: 65685f65 62755f78 20746f6f 30433337    e_hex_uboot 73C0
101000c0: 65730a30 766e6574 7a697320 6c625f65    0.setenv size_bl
101000d0: 5f6b636f 5f786568 6f6f6275 39332074    ock_hex_uboot 39
101000e0: 730a0a45 6e657465 6f722076 7366746f    E..setenv rootfs
101000f0: 6c5f615f 6c656261 6f722220 7366746f    _a_label "rootfs
uboot# mw 0x10100004 0x0 1
uboot# crc32 0x10100000 0x40 0x10100004
crc32 for 10100000 ... 1010003f ==> 94926f83
uboot# md 0x10100000                   
10100000: 56190527 836f9294 f4f64161 66090000    '..V..o.aA.....f
10100010: 00000000 00000000 0533a380 00060205    ..........3.....
10100020: 6f422d55 7320746f 70697263 00000074    U-Boot script...
10100030: 00000000 00000000 00000000 00000000    ................
10100040: 5e090000 00000000 20766e65 61666564    ...^....env defa
10100050: 20746c75 2d20662d 65730a61 766e6574    ult -f -a.setenv
10100060: 7a697320 79625f65 685f6574 725f7865     size_byte_hex_r
10100070: 66746f6f 33352073 35453937 65730a41    ootfs 5379E5A.se
10100080: 766e6574 7a697320 6c625f65 5f6b636f    tenv size_block_
10100090: 5f786568 746f6f72 32207366 30444239    hex_rootfs 29BD0
101000a0: 7465730a 20766e65 657a6973 7479625f    .setenv size_byt
101000b0: 65685f65 62755f78 20746f6f 30433337    e_hex_uboot 73C0
101000c0: 65730a30 766e6574 7a697320 6c625f65    0.setenv size_bl
101000d0: 5f6b636f 5f786568 6f6f6275 39332074    ock_hex_uboot 39
101000e0: 730a0a45 6e657465 6f722076 7366746f    E..setenv rootfs
101000f0: 6c5f615f 6c656261 6f722220 7366746f    _a_label "rootfs
uboot# source 0x10100000    
## Executing script at 10100000

... SUCCESS!!!!!

预上传 PC 补丁
运行 mkimage 后，我以这种方式修复了 CRC。我敢肯定，这可以以更优雅的方式编写 - 但这至少证明是实用的:

# The mkimage "header CRC" is invalid for some reason, so it needs to be corrected!

$files_dir=files/
$flash_scr=flash.scr
$flash_hdr=flash.hdr

chmod 644 $files_dir$flash_scr

# zero the current crc, and copy the 64 byte header to a separate file
printf '\x00\x00\x00\x00' | dd of=$files_dir$flash_scr bs=1 seek=4 count=4 conv=notrunc
head -c 64 $files_dir$flash_scr > $files_dir$flash_hdr

# calculate the correct crc
crc=$(crc32 $files_dir$flash_hdr)
b1=$(echo $crc | cut -c 1,2)
b2=$(echo $crc | cut -c 3,4)
b3=$(echo $crc | cut -c 5,6)
b4=$(echo $crc | cut -c 7,8)

# update the script, with the correct value
printf "\x${b1}\x${b2}\x${b3}\x${b4}" | dd of=$files_dir$flash_scr bs=1 seek=4 count=4 conv=notrunc

# clean up 
rm $files_dir$flash_hdr

mkimage 的根本缺陷
理想情况下， mkimage 首先会正确地完成它的工作。为什么它出现故障仍然是一个谜......

Answer 1

What am I doing wrong?

U-Boot 几乎总是假设命令参数为十六进制值，因此使用 0x...前缀实际上是多余的。 AFAIK 无法输入十进制值。

# recalc the crc
crc32 0x10100000 64

因此，当您在 crc32 中指定标题的长度时命令为 64 ，您指定了不正确的( header )长度 0x64 或十进制 100。
查看 U-Boot 命令响应确认您的错误:

=> crc32 0x10100000 64                                                          
CRC32 for 10100000 ... 10100063 ==> 9988c6ca

0x10100000 到 0x10100063 的地址范围是 100 字节的跨度。

附录 (有修订)
当您安装计算值时，您可能会引入 endian(字节顺序)问题。

# write the crc
#mw 0x10100004 <VALUE> 1

计算的 CRC32 值可能需要在 mw 中以反向字节顺序指定(假设 i.MX6 为小端模式)。命令。

例如， mkimage 命令安装原始报头 CRC32 值 d8bc0e3a 3a0ebcd8在第二个字中(以小端顺序):

=> md 20000000                                                                  
20000000: 56190527 3a0ebcd8 a0284161 1f000000    '..V...:aA(.....               
20000010: ...

=> imi 20000000                                                                 
                                                                                
## Checking Image at 20000000 ...                                               
   Legacy image found                                                           
   Image Name:   U-Boot script                                                  
   Image Type:   PowerPC Linux Script (uncompressed)                            
   Data Size:    ...                                            

将第二个字归零后，CRC32 命令产生(相同)值(如预期)(但作为 4 字节字符串而不是整数):

=> crc32 20000000 40                                                            
crc32 for 20000000 ... 2000003f ==> d8bc0e3a                                    

如果您使用 mw 从字面上安装此值命令，则字节顺序不是 32 位字值所需的顺序。

=> mw 20000004 d8bc0e3a                                                         
=> md 20000000                                                                  
20000000: 56190527 d8bc0e3a a0284161 1f000000    '..V:...aA(.....               
20000010: ...

=> imi 20000000                                                                 
                                                                        
## Checking Image at 20000000 ...                                               
   Legacy image found                                                           
   Bad Header Checksum                                                          
=> 

mw命令将要写入的值视为 byte string而不是整数值整数值，因此不执行字节重新排序(即使这是一个小端 CPU)，需要对 CRC32 值进行字节重新排序。

附录 2
对上面关于 U-Boot 命令在小端模式下显示结果的小幅修正。 md假设存储的值处于小端模式，命令正在显示字值。
要查看内存中的真实字节顺序，请使用 md.b命令。

=> md 20000000 4                                                                
20000000: 56190527 3a0ebcd8 a0284161 1f000000    '..V...:aA(.....               

=> md.b 20000000 10                                                             
20000000: 27 05 19 56 d8 bc 0e 3a 61 41 28 a0 00 00 00 1f    '..V...:aA(.....   
=>

因此， mkimage 命令安装原始报头 CRC32 值 3a0ebcd8在第二个字中(以小端顺序)。
CRC32 命令生成 4 字节值作为字节字符串(即已经按小端顺序)。 mw命令知道这是一个小端 CPU，并且确实将要写入的值视为整数值。
由于 CRC32 结果是 byte string (而不是整数值)，这些字节必须使用 mw 重新排序以供输入命令。
了解？

避免这种字节序混淆的一种可能方法是使用 CRC32 命令的自动写入功能。
将 header CRC 的地址附加到您的 crc32命令，并且计算出的值将以正确的顺序为您存储，例如

crc32 0x10100000 0x40 0x10100004

仍然想知道为什么你一开始就没有一个好的 CRC32 使用 mkimage ，以及为什么你不得不求助于这个黑客。