The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie7038712de8cc646632d5e7d29550e3260bf2c62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80103
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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: Ie442f82cd1abcf7fa18295e782cccf26a7d30079
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39033
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Allocating a 15980-byte scratchpad on the stack when your default stack
size is set to 16KB is really not a great idea. We're regularly
overflowing into the end of our heap when using LZMA in libpayload, and
just happen not to notice it because the heap rarely gets filled up all
the way. Of course, since we always *have* a heap in libpayload, the
much saner solution is to just use it directly to allocate the
scratchpad rather than accidentally grow backwards into it anyway.
Change-Id: Ibe4f02057a32bd156a126302178fa6fcab637d2c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16089
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Martin Roth