[commandlinefan]

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?

[mrspeaker]

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]

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]

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]

Maybe bootloader code?