3 ms·

From the output I see: 23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes,

From the output I see: 23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 97476 bytes 64968 0xFDC8 XML document, version: "1.0" So it looks like the size of the bootloader should be 64968 - 23296 = 41672. But he extracts 41162: $ dd if=archer-c7.bin of=u-boot.bin.lzma bs=1 skip=23296 count=41162 Curious if anybody knows why 41162; is this a block-size alignment requirement?

zerocrates 7y ago
The 41162 bytes comes from the preceding uImage header, you'll see it listed in that big description. I'm not sure what the 510 bytes of padding are, though. Just padding? A checksum?
- jschwartzi 7y ago
  Maybe bootloader code?
mrspeaker 7y ago
I'm wondering how these values are determined too. I'm "following along at home" without any idea what I'm doing (though all the files, bytes, and offsets are matching with the tutorial... Also, if the original author finds this thread: amazing write-up - got me really interested in the topic!). At the step where they remove the header with dd if=uImage of=Image.lzma bs=1 skip=72 It results in a file that if I try and un compress it with `unlzma Image.lzma` it complains with "Compressed data is corrupt" I don't know where the magic number "72" comes from. Is it likely that could be different on my machine (a mac)? [edit: I think there's something else wrong - if I use `mkImage` to examine the uImage file I only get: mkimage -l uImage GP Header: Size 27051956 LoadAddr 78a267ff Instead of image information]
- syntheticnature 7y ago
  The 72 bytes is from the difference between the uImage header and the lzma inside, from the post. 0x132b8-0x13270 = 72 (dec). So you'll need to check what binimage says about your image, the uImage header isn't necessarily fixed in size. Also see the comment above about the --dd switch, though mind the reply to that pointing out you might want to check what it finds before just letting it write a pile of files.

zerocrates 7y ago

The 41162 bytes comes from the preceding uImage header, you'll see it listed in that big description. I'm not sure what the 510 bytes of padding are, though. Just padding? A checksum?

jschwartzi 7y ago
Maybe bootloader code?

mrspeaker 7y ago

I'm wondering how these values are determined too. I'm "following along at home" without any idea what I'm doing (though all the files, bytes, and offsets are matching with the tutorial... Also, if the original author finds this thread: amazing write-up - got me really interested in the topic!). At the step where they remove the header with dd if=uImage of=Image.lzma bs=1 skip=72 It results in a file that if I try and un compress it with `unlzma Image.lzma` it complains with "Compressed data is corrupt" I don't know where the magic number "72" comes from. Is it likely that could be different on my machine (a mac)? [edit: I think there's something else wrong - if I use `mkImage` to examine the uImage file I only get: mkimage -l uImage GP Header: Size 27051956 LoadAddr 78a267ff Instead of image information]

syntheticnature 7y ago
The 72 bytes is from the difference between the uImage header and the lzma inside, from the post. 0x132b8-0x13270 = 72 (dec). So you'll need to check what binimage says about your image, the uImage header isn't necessarily fixed in size. Also see the comment above about the --dd switch, though mind the reply to that pointing out you might want to check what it finds before just letting it write a pile of files.