One idea is the lzma parameters " -lc1 -lp2 -pb2 ", which have been
introduced without any explanation four years ago with r12628. Those differ
from the defaults mentioned in the lzma's built-in help texts, and do differ
from Netgear's build process (which uses the defaults in lzma and version
4.32, not 4.65).
http://nbd.name/gitweb.cgi?p=openwrt.git;a=commitdiff;h=6fb33f05da8ff895875cb8d98a7c18e9c606e205
It might be theoretically possible, that the parameter create a lzma version
that the u-boot chokes on. Why should that surface then now, is then more
problematic to answer...
That parameter selection was made 4 years ago, so it is really old, but is a
deviation from the Netgear's own routines, shown in forum in:
https://forum.openwrt.org/viewtopic.php?pid=183596#p183596
I built 34036 and 34066 fully from scratch and they both worked both in v1
and v2.
Then I built 34085 and it failed in both routers.
I then modified the ar71xx image makefile and removed those non-standard
compression parameters from the lzma command line. And a new 34085 then
booted ok in both routers.
-- trunk/target/linux/ar71xx/image/Makefile (revision 34085)
+++ trunk/target/linux/ar71xx/image/Makefile (working copy)
@@ -69,7 +69,7 @@
endif
define CompressLzma
- $(STAGING_DIR_HOST)/bin/lzma e $(1) -lc1 -lp2 -pb2 $(2)
+ $(STAGING_DIR_HOST)/bin/lzma e $(1) $(2)
endef
define PatchKernelLzma
I will rebuild 34085 once again from scratch and retry. (I made the last
build without clean, as it was supposed change just the image creation...)
Read about the lzma/xz memory consumption here:
http://linux.die.net/man/1/lzma
http://sourceforge.net/projects/lzmautils/forums/forum/708858/topic/3965542
Based on those articles, it might be sensible to either revert to default
parameters, or based on seeing the parameters at staging_dir/host/bin/lzma to
change the default directory size from 23 bits (8 MB) to something smaller,
as the firmware is usually much smaller. (see below from lzma help file.)
perus@ubvb:/Openwrt/trunk$ staging_dir/host/bin/lzma
LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03
Usage: LZMA <e|d> inputFile outputFile [<switches>...]
e: encode file
d: decode file
b: Benchmark
<Switches>
-a{N}: set compression mode - [0, 1], default: 1 (max)
-d{N}: set dictionary size - [12, 30], default: 23 (8MB)
-fb{N}: set number of fast bytes - [5, 273], default: 128
-mc{N}: set number of cycles for match finder
-lc{N}: set number of literal context bits - [0, 8], default: 3
-lp{N}: set number of literal pos bits - [0, 4], default: 0
-pb{N}: set number of pos bits - [0, 4], default: 2
-mf{MF_ID}: set Match Finder: [bt2, bt3, bt4, hc4], default: bt4
-mt{N}: set number of CPU threads
-eos: write End Of Stream marker
-si: read data from stdin
-so: write data to stdout
http://linux.die.net/man/1/lzma
dict=size
Dictionary (history buffer) size indicates how many bytes of the
recently processed uncompressed data is kept in memory. One method to reduce
size of the uncompressed data is to store distance-length pairs, which
indicate what data to repeat from the dictionary buffer. The bigger the
dictionary, the better the compression ratio usually is, but dictionaries
bigger than the uncompressed data are waste of RAM.
Typical dictionary size is from 64 KiB to 64 MiB. The minimum is 4 KiB.
The maximum for compression is currently 1.5 GiB. The decompressor
already supports dictionaries up to one byte less than 4 GiB, which is the
maximum for LZMA1 and LZMA2 stream formats.
Dictionary size has the biggest effect on compression ratio.
Dictionary size and match finder together determine the memory usage of
the LZMA1 or LZMA2 encoder. The same dictionary size is required for
decompressing that was used when compressing, thus the memory usage of the
decoder is determined by the dictionary size used when compressing.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
