summaryrefslogtreecommitdiff
path: root/src/lib/lzma.c
AgeCommit message (Collapse)Author
2022-08-11lib: Add SPDX identifiers to files missing themMartin Roth
This adds SPDX identifiers to the remaining source files in the lib directory that don't already have them. A note on gcov-iov.h - As machine generated content, this file is believed to be uncopyrightable, and therefore in the public domain, so gets the CC-PDDC license even though there is code in the file. Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: Ifcb584d78a55e56c1b5c02d424a7e950a7f115dc Reviewed-on: https://review.coreboot.org/c/coreboot/+/66502 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2020-05-26Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki
After removal of CAR_MIGRATION there are no more reasons to carry around ENV_STAGE_HAS_BSS_SECTION=n case. Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit zero-initializers. Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-02-25lib/lzma: Fix out-of-bounds readAlex Rebert
Fix an out-of-bounds read in the LZMA decoder which happens when the src buffer is too small to contain the 13-byte LZMA header. Change-Id: Id5893e60fc9a48deb83560b7917f5558cd30ef4e Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com> Found-by: Mayhem Reviewed-on: https://review.coreboot.org/c/coreboot/+/39085 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-08-26Split MAYBE_STATIC to _BSS and _NONZERO variantsKyösti Mälkki
These are required to cover the absensce of .data and .bss sections in some programs, most notably ARCH_X86 in execute-in-place with cache-as-ram. Change-Id: I80485ebac94b88c5864a949b17ad1dccdfda6a40 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35003 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-03-07src: Drop unused include <timestamp.h>Elyes HAOUAS
Change-Id: I7e181111cd1b837382929071a350b94c3afc1aaa Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31784 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2018-03-26lib/lzma: Respect dstn argumentPatrick Rudolph
Don't write more bytes than the caller requests. Based on I484b5c1e3809781033d146609a35a9e5e666c8ed. Change-Id: I336de417c7cd6f35cf84947fc4ae161c15bd93ef Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25222 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-03-13src/lib: Wrap lines at 80 columnsLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: line over 80 characters TEST=Build and run on Galileo Gen2 Change-Id: I5fa3f8e950e2f0c60bd0e8f030342dc8c0469299 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18758 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-01lib: remove ulzma()Aaron Durbin
That function is no longer used. All users have been updated to use the ulzman() function which specifies lengths for the input and output buffers. Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15526 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2016-02-22cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner
This patch ports the LZ4 decompression code that debuted in libpayload last year to coreboot for use in CBFS stages (upgrading the base algorithm to LZ4's dev branch to access the new in-place decompression checks). This is especially useful for pre-RAM stages in constrained SRAM-based systems, which previously could not be compressed due to the size requirements of the LZMA scratchpad and bounce buffer. The LZ4 algorithm offers a very lean decompressor function and in-place decompression support to achieve roughly the same boot speed gains (trading compression ratio for decompression time) with nearly no memory overhead. For now we only activate it for the stages that had previously not been compressed at all on non-XIP (read: non-x86) boards. In the future we may also consider replacing LZMA completely for certain boards, since which algorithm wins out on boot speed depends on board-specific parameters (architecture, processor speed, SPI transfer rate, etc.). BRANCH=None BUG=None TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on Oak to be about ~20ms faster (cutting load times for affected stages almost in half). Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13638 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-12lzma: Port size-checking ulzman() version to corebootJulius Werner
We've had a second version of ulzma() that would check the input and output buffer sizes in libpayload for a while now. Since it's generally never a bad idea to double-check for overruns, let's port it to coreboot and use it where applicable. (This requires a small fix in the four byte at a time read optimization we only have in coreboot, since it made the stream counter hit the end a little earlier than the algorithm liked and could trigger an assertion.) BRANCH=None BUG=None TEST=Booted Oak, Jerry and Falco. Change-Id: Id566b31dfa896ea1b991badf5a6ad9d075aef987 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13637 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-06lzma: Return correct amount of decompressed bytesJulius Werner
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>
2015-04-14timestamps: You can never have enough of them!Julius Werner
Now that we have timestamps in pre-RAM stages, let's actually make use of them. This patch adds several timestamps to both the bootblock and especially the verstage to allow more fine-grained boot time tracking. Some of the introduced timestamps can appear more than once per boot. This doesn't seem to be a problem for both coreboot and the cbmem utility, and the context makes it clear which operation was timestamped at what point. Also simplifies cbmem's timestamp printing routine a bit, fixing a display bug when a timestamp had a section of exactly ",000," in it (e.g. 1,000,185). BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show up and contained sane values. Booted Storm (no timestamps here since it doesn't support pre-RAM timestamps yet). Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234063 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9608 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-09Add and consistently use wrapper macro for romstage static variablesJulius Werner
x86 systems run their romstage as execute-in-place from flash, which prevents them from having writable data segments. In several code pieces that get linked into both romstage and ramstage, this has been worked around by using a local variable and having the 'static' storage class guarded by #ifndef __PRE_RAM__. However, x86 is the only architecture using execute-in-place (for now), so it does not make sense to impose the restriction globally. Rather than fixing the #ifdef at every occurrence, this should really be wrapped in a way that makes it easier to modify in a single place. The chromeos/cros_vpd.c file already had a nice approach for a wrapper macro, but unfortunately restricted it to one file... this patch moves it to stddef.h and employs it consistently throughout coreboot. BRANCH=nyan BUG=None TEST=Measured boot time on Nyan_Big before and after, confirmed that it gained 6ms from caching the FMAP in vboot_loader.c. Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203033 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I44dacc10214351992b775aca52d6b776a74ee922 Reviewed-on: http://review.coreboot.org/8055 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-11-19lib/lzma.c: Use header over .c includeEdward O'Callaghan
Change-Id: I904eb1703eaf4f8de1b4ec443173686c7985be12 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7427 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2013-07-10lib: Fix spellingMartin Roth
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3756 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-01lib: Prevent unaligned memory access and fix endianess in LZMA decode library.Hung-Te Lin
LZMA decode library used to retrieve output size by: outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE); 'src' is aligned but LZMA_PROPERTIES_SIZE may refer to an unaligned address like src+5, and using that as integer pointer may fail on platforms like ARM. Also this will fail on systems using big-endian (outSize was encoded in little-endian). To fix this, reconstruct outSize in little-endian way. Change-Id: If678e735cb270c3e5e29f36f1fad318096bf7d59 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2246 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24Shrink the stack sizes we need in corebootRonald G. Minnich
We accomplish this goal by getting rid of the huge auto array in the ram stage. This will in turn let us reduce CONFIG_STACK_SIZE. We have to leave it on the stack in CAR as that's the simple way to keep it private. It does not matter then as there is only one core that is active. Change-Id: Ie37a057ccae088b7f3bb4aab6de2713e64d96df6 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1271 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2010-09-23Fix some wrong capitalizations, reformat comments, fix a typo.Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5829 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-27Since some people disapprove of white space cleanups mixed in regular commitsStefan Reinauer
while others dislike them being extra commits, let's clean them up once and for all for the existing code. If it's ugly, let it only be ugly once :-) Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-22printk_foo -> printk(BIOS_FOO, ...)Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5266 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-28Create lib.h for homeless prototypes.Myles Watson
Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4878 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-27Add few missing prototypes, and remove few unused (thus lonelly) variables.Maciej Pijanka
TODO - x86emu need (imo) some common header with prototypes at least - clog2, ulzma, hardwaremain prototypes added by this patch probably should be moved to some header too. - in src/devices/device_util.c prototype is before function because seems, it is used only within same file, if not it should be moved to debug section of prototypes in include/device/device.h Signed-off-by: Maciej Pijanka <maciej.pijanka@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4871 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-09-25improve lzma error messages. When coreboot panics because lzma decompressionStefan Reinauer
goes wrong, it might not be clear that it's lzma that failed, if the log level is low enough.. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4676 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-04-24Remove the inclusion of lzma.c (which really contains code) Patrick Georgi
from another (rom_stream.c and others), instead linking it like any source file should be linked. The same should (and will) be done with nrv2b.c, but that has some deeper implications as various CAR implementations include that directly, and thus requires more care. It fixes an issue with the cbfs code. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4206 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-08-27If you haveWard Vandewege
option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 option CONFIG_PRECOMPRESSED_PAYLOAD=1 set in Config.lb but accidentally use an uncompressed payload, coreboot (v2) bombs out like this: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! Decoding error = 1 Unexpected Exception: 6 @ 10:04000408 - Halting Code: 0 eflags: 00010057 eax: 00000101 ebx: 04000400 ecx: 000003d4 edx: fffc0000 edi: 04000400 esi: 04000401 ebp: 04000400 esp: 0013dfb4 The attached patch modifies v2's lzma code so that it assumes an uncompressed payload if it fails to find a properly compressed payload. Compare with the fatal error above: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Uncompressing to RAM 0x01000000 Decoder scratchpad too small! olen = 0x00000000 done. Decompression failed. Assuming payload is uncompressed... Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 If you don't have CONFIG_COMPRESSED_PAYLOAD_LZMA and CONFIG_PRECOMPRESSED_PAYLOAD set and use an uncompressed payload, things are as before: elfboot: Attempting to load payload. rom_stream: 0xfffc0000 - 0xfffdefff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 One can argue that this is a case of 'builder beware', but my counter argument is that anything that causes unexpected runtime breakage is really, really, really bad, and should be avoided where possible. This patch also fixes one erroneous comment. Signed-off-by: Ward Vandewege <ward@gnu.org> Acked-by: Myles Watson <mylesgw@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-03-17Clarify LZMA code license.Carl-Daniel Hailfinger
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3161 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-01-18Rename almost all occurences of LinuxBIOS to coreboot. Stefan Reinauer
Due to the automatic nature of this update, I am self-acking. It worked in abuild. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3053 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2006-09-14additions and mods for lzma. Carl-Daniel Hailfinger
Signed-off-by: Carl-Daniel Hailfinger Signed-off-by: Ronald G. Minnich git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2413 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1