Currently cbfs stage files that are compressed do not have
the decompressed size readily available. Therefore there's
no good way to know actual size of data after it is
decompressed. Optionally return the decompressed data size
if requested.
Change-Id: If371753d28d0ff512118d8bc06fdd48f4a0aeae7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12173
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This enables more warnings on the cbfstool codebase and fixes the
issues that surface as a result. A memory leak that used to occur
when compressing files with lzma is also found and fixed.
Finally, there are several fixes for the Makefile:
- Its autodependencies used to be broken because the target for
the .dependencies file was misnamed; this meant that Make
didn't know how to rebuild the file, and so would silently
skip the step of updating it before including it.
- The ability to build to a custom output directory by defining
the obj variable had bitrotted.
- The default value of the obj variable was causing implicit
rules not to apply when specifying a file as a target without
providing a custom value for obj.
- Add a distclean target for removing the .dependencies file.
BUG=chromium:461875
TEST=Build an image with cbfstool both before and after.
BRANCH=None
Change-Id: I951919d63443f2b053c2e67c1ac9872abc0a43ca
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 49293443b4e565ca48d284e9a66f80c9c213975d
Original-Change-Id: Ia7350c2c3306905984cfa711d5fc4631f0b43d5b
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257340
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9937
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
cbfstool has diverged between coreboot upstream and the chromium tree.
Bring in some of the chromium changes, in particular the useful remainders
of cbf37fe (https://chromium-review.googlesource.com/176710)
- fix coding style
- mark unused variables explicitly unused
- remove some dead code
Change-Id: I354aaede8ce425ebe99d4c60c232feea62bf8a11
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
When compression fails for whatever reason, the caller should know about it
rather than blindly assuming it worked correctly. That can prevent half
compressed data from ending up in the image.
This is currently happening for a segment of depthcharge which is triggering
a failure in LZMA. The size of the "compressed" data is never set and is
recorded as zero, and that segment effectively isn't loaded during boot.
Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187364
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit be48f3e41eaf0eaf6686c61c439095fc56883cec)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6960
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This was designed as a micro-optimization for x86, but it is only used
once. Let the compiler decide if optimizing this is worth the effort.
Change-Id: I5939efa34f0e9d16643893ca04675247842e7db5
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5085
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When typedef is used with structs, enums, and to create new typenames,
readability suffers. As such, restrict use of typedefs only to
creating new data types.
The 80 character limit is intentionally ignored in this patch in order
to make reviewing easier.
Change-Id: I62660b19bccf234128930a047c754bce3ebb6cf8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5070
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the first patch on a long road to refactor and fix the lzma
code in cbfstool. I want to submit it in small atomic patches, so that
any potential errors are easy to spot before it's too late.
Change-Id: Ib557f8c83f49f18488639f38bf98d3ce849e61af
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4834
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:
commit aa3f7ba36e
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.
Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Aaron Durbin