On 2012-06-28 12:41 PM, Rafał Miłecki wrote:
> I've noticed that OpenWRT's Makefile-s tend to use -si and -so
> together with pipe (|) and output redirecting (>).
>
> It was causing problem for my WNDR4500 image - the one generated from
> stdin didn't work. I've started comparing output of that two methods
> and I'm attaching results.
>
> 1) Using stdin
> cat vmlinux | ~/openwrt.git/staging_dir/host/bin/lzma e -d16 -si
> vmlinux-from-si.lzma
>
> 2) Using inputFile
> ~/openwrt.git/staging_dir/host/bin/lzma e -d16 vmlinux vmlinux-from-file.lzma
>
> The one generated from stdin has some 0xFF-s in LZMA header and is
> longer by 5 bytes visible at the end
>
> 1) stdin:
>> hexdump -C vmlinux-from-si.lzma | head
> 5d 00 00 01 00 ff ff ff ff ff ff ff ff 00 30 09 |].0.|
>> hexdump -C vmlinux-from-si.lzma | tail
> 0010db00 3a 39 d8 2f e2 d9 cf ac 62 ff fb 14 38 48|:9./b...8H
>
> 2) inputFile
>> hexdump -C vmlinux-from-file.lzma | head
> 5d 00 00 01 00 f4 04 30 00 00 00 00 00 00 30 09 |]..0..0.|
>> hexdump -C vmlinux-from-file.lzma | tail
> 0010db00 3a 39 d8 2f e2 b1 89 f0 16 |:9./.|
>
> Honestly, I'm not really going to analyze that anytime soon. I want to
> focus on different bugs first. If someone has time for this - would be
> great.
The LZMA header has a field that contains the uncompressed size. The
LZMA tool only fills this if it knows the filesize ahead of time (which
does not work with stdin). If it can't know the uncompressed size, it
fills the field with 0xff and generates an end-of-stream tag in the
compressed bitstream instead.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
