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