The LZMA functions are supposed to return the decompressed size, but
what they actually return is just an unaltered field from the LZMA
header that is *supposed* to contain the decompressed size. Apparently
some encoders just overshoot that for no good reason. This patch changes
the code such that the actual amount of decompressed bytes is returned.
BRANCH=smaug
BUG=None
TEST=Printed output bytes when decompressing kernels with LZMA in
depthcharge, noted that amounts now make sense.
Change-Id: Icdd8f782aa87841f770eff4c14a08973530c7446
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24b2fa8c9a342ca4288dad1430c8965395f00263
Original-Change-Id: Ib4cf8673846aedd34656e594ce7b8ea875b56099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282742
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10777
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This new version is used to implement the version which doesn't take the
input and output buffer sizes.
Old-Change-Id: I8935024aca0849bc939263d7fc3036c586e63c68
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65510
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 465d167ad2f6a67d0b2c91fb6c68c8f9a09dd395)
libpayload: Make lzma truncation non-fatal.
If the size the lzma header claims it needs is bigger than the space we have,
print a message and continue rather than erroring out. Apparently the encoder
is lazy sometimes and just puts a large value there regardless of what the
actual size is.
This was the original intention for this code, but an outdated version of the
patch ended up being submitted.
Old-Change-Id: Ibcf7ac0fd4b65ce85377421a4ee67b82d92d29d3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66235
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 30c628eeada274fc8b94f8f69f9df4f33cbfc773)
Squashed two related commits and updated the commit message to be
more clear.
Change-Id: I484b5c1e3809781033d146609a35a9e5e666c8ed
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6408
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Use memcpy to access a uint32_t that's inherently unaligned due to the layout
of the LZMA header format.
Built and booted on Daisy and saw a data abort go away. Built and booted
into developer mode on Link and verified that bitmaps were
decompressed/displayed correctly.
Change-Id: Id3ae746c04d23bcb0345cb71797bfa219479cc8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2670
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I9a16331dedc97f17af94bf2cf535a9c93d1729a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2667
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add cbfs core from coreboot into libpayload, and to support lzma decode,
add coreboot's lzma code, too. Carl-Daniel agreed to relicense the
lzmadecode wrapper as BSD-l, solving licensing problems.
Change-Id: Id28990fe7e951d99447e265a4880d70a8f208dd2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/115
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Julius Werner