This patch creates a new commonlib/bsd subdirectory with a similar
purpose to the existing commonlib, with the difference that all files
under this subdirectory shall be licensed under the BSD-3-Clause license
(or compatible permissive license). The goal is to allow more code to be
shared with libpayload in the future.
Initially, I'm going to move a few files there that have already been
BSD-licensed in the existing commonlib. I am also exracting most
contents of the often-needed <commonlib/helpers.h> as long as they have
either been written by me (and are hereby relicensed) or have an
existing equivalent in BSD-licensed libpayload code. I am also
relicensing <commonlib/compression.h> (written by me) and
<commonlib/compiler.h> (same stuff exists in libpayload).
Finally, I am extracting the cb_err error code definitions from
<types.h> into a new BSD-licensed header so that future commonlib/bsd
code can build upon a common set of error values. I am making the
assumption here that the enum constants and the half-sentence fragments
of documentation next to them by themselves do not meet the threshold of
copyrightability.
Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
It is possible that 'malloc_fo_sub' and 'remalloc_fo' can
fail, so add appropriate error checks for those cases.
This incidentally fixes a possible memory leak when
'malloc_fo_sub' succeeds but 'remalloc_fo' does not.
Found-by: Coverity Scan #1396050
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I944b67f5cdcfd7a687e81d8bb01a209c9dc9b0b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
VBT on Intel(R) systems is available via sysfs as
/sys/kernel/debug/dri/0/i915_vbt
However the size of this file reads as 0 causing
intelvbttool to fail. This patch implements incremental reads
with realloc for such cases or whenever the file size is not
available (e.g. reading from stdin).
After this patch is applied, intelvbttool can be used as follows:
sudo intelvbttool -f /sys/kernel/debug/dri/0/i915_vbt -d
Change-Id: I5d17095a5747550b7115a54a7619b7294a846196
Signed-off-by: Alex Feinman <alexfeinman@hotmail.com>
Reviewed-on: https://review.coreboot.org/c/31531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
* Clear remalloced memory
* Fix check for invalid VBT offset in header
* Fix VBIOS checksum generation
* Fix VBIOS size field
* Align VBIOS size to multiple of 512
* Reassign pointers after use of remalloc
* Don't leak on error path
Current version is enough to allow the proprietary Windows Intel GMA
driver to find the VBT in the legacy VBIOS area and it doesn't BSOD
any more.
The LVDS screen remains black, due to an unknown issue with the
proprietary driver, while the VGA works.
Tested with libgfxinit and native graphics init.
Change-Id: If07b1bb51d8fb3499d13102f70fedb36c020fb72
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/29099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* Add Makefile dependency to source file
* Add argument support
* Add help support
* Print usage on wrong arguments
* Add support for parsing VBT binary file
* Add support for parsing PCI Option ROM
* Add support for writing VBT binary file
* Add support for patching PCI Option ROM
* Keep support for accessing legacy VGA area Option ROM
* Keep support for dumping VBT contents to stdout
Allows to extract VBT, analyse VBT and patch PCI Option ROMs as needed.
The required arguments have been changed:
./intelvbttool --<SOURCECMD> [filename] --<DESTCMD> [filename]
SOURCECMD set the VBT source. Supported:
inlegacy : Legacy BIOS area at phys. memory 0xc0000
invbt : Read raw Intel VBT file
inoprom : Read VBT from Intel Option ROM file
DESTCMD set the VBT destination. Supported:
outdump : Print VBT in human readable form
outvbt : Write raw Intel VBT file
patchoprom: Patch existing Intel Option ROM
Any combination of SOURCECMD and DESTCMD is possible.
Change-Id: I8cbde042c7f5632f36648419becd23e248ba6f76
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/18902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Descriptions are taken from the files themselves or READMEs. Description
followed by a space with the language in marked up as code.
Change-Id: I5f91e85d1034736289aedf27de00df00db3ff19c
Signed-off-by: Tom Hiller <thrilleratplay@gmail.com>
Reviewed-on: https://review.coreboot.org/27563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add minimal Makefile based on cbmem’s Makefile.
The make target `junit.xml` is removed as this is handled differently
since commit de9adebb (Add junit.xml code to top Makefile.inc instead of
utils).
Also the `junit.xml` is removed in the make target `clean`.
Additionally, the make target `distclean` is added, as the current
junit.xml code in the top `Makefile.inc` requires that.
Change-Id: I164b1f7733505bca6248d0711d7ad71d635fa926
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11876
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Julius Werner