This patch adds a new CBFS implementation that is intended to replace
the existing commonlib/cbfs.c. The new implementation is designed to
meet a bunch of current and future goals that in aggregate make it
easier to start from scratch than to adapt the exisiting implementation:
1. Be BSD-licensed so it can evetually be shared with libpayload.
2. Allow generating/verifying a metadata hash for future CBFS per-file
verification (see [1][2]).
3. Be very careful about reading (not mmaping) all data only once, to be
suitable for eventual TOCTOU-safe verification.
4. Make it possible to efficiently implement all current and future
firmware use cases (both with and without verification).
The main primitive is the cbfs_walk() function which will traverse a
CBFS and call a callback for every file. cbfs_lookup() uses this to
implement the most common use case of finding a file so that it can be
read. A host application using this code (e.g. coreboot, libpayload,
cbfstool) will need to provide a <cbfs_glue.h> header to provide the
glue to access the respective CBFS storage backend implementation.
This patch merely adds the code, the next patch will integrate it into
coreboot.
[1]: https://www.youtube.com/watch?v=Hs_EhewBgtM
[2]: https://osfc.io/uploads/talk/paper/47/The_future_of_firmware_verification_in_coreboot.pdf
(Note: In early discussions the metadata hash was called "master hash".)
Change-Id: Ica64c1751fa37686814c0247460c399261d5814c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38421
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The AM335X is a SoC, so should be in the soc tree.
This moves all the existing am335x code to soc/ and updates any
references. It also adds a soc.c file as required for the ramstage.
Change-Id: Ic1ccb0e9b9c24a8b211b723b5f4cc26cdd0eaaab
Signed-off-by: Sam Lewis <sam.vr.lewis@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Commit 991ee05 ("mb/gigabyte/ga-h61m-s2pv: rename to ga-h61m-series")
renamed the mainboard folder from `ga-h61m-s2pv` to `ga-h61m-series`,
but the MAINTAINERS file was not updated accordingly. Correct that.
Change-Id: I8119e29912e04ab57bebb96f37a4147afbb4d56e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
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>
The MIPS architecture port has been added 5+ years ago in order to
support a Chrome OS project that ended up going nowhere. No other board
has used it since and nobody is still willing or has the expertise and
hardware to maintain it. We have decided that it has become too much of
a mainenance burden and the chance of anyone ever reviving it seems too
slim at this point. This patch eliminates all MIPS code and
MIPS-specific hacks.
Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This board runs well with coreboot. The documentation part of this
commit lists what works and what doesn't.
Tested with GRUB 2.02 as a payload, loading SeaBIOS 1.12.0 which then
boots FreeBSD 11.2. It has also been tested with GRUB directly booting
Debian GNU/Linux 9.6 (kernel 4.9).
Change-Id: I291573d4651bdffe24eb841033ea6189fcbf8502
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/c/30357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add myself as a maintainer of the four mainboards I ported. For those
which were added as a variant, add myself as a maintainer of the whole
mainboard group.
Change-Id: I0e1b54279027fae82ea9f2825e6f27d38ef3c746
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
POWER8 is a specific implementation of ppc64, which is by now outdated
(POWER9 has been on the market for a while). Rename arch/power8/ to
potentially cover a wider range of hardware.
TEST=Toolchains built before/after this commit can build coreboot for
emulation/qemu-power8 from before/after this commit.
Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/29943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
The reason for this code cleanup is the legacy
Google Purin board which isn't available anymore
and AFAIK never made it into the stores.
* Remove broadcom cygnus SoC support
* Remove /util/broadcom tool
* Remove Google Purin mainboard
* Remove MAINTAINERS entries
Change-Id: I148dd7eb0192d396cb69bc26c4062f88a764771a
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29905
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add myself as a maintainer for legacy Intel-based ChromeOS devices
for which I provide coreboot images as a comminuty member, and
as a maintainer for Purism devices in a professional capacity.
Change-Id: I70df3b9e4e36c2e5d73f8888fe0ec220aa8a91b7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The semantics in util/scripts/maintainers.go have changed in that a
file can be part of multiple components. This means that all files
are part of "the rest" now, which doesn't make much sense.
Change-Id: I220afe27e78aa5358fca61851242812f2d763992
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/29657
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Remove FSP Sandy/Ivybrige which are unused.
* Open Source implementation isn't final but
good enough to replace FSP version.
* For new ports use NORTHBRIDGE_INTEL_IVYBRIDGE
and NORTHBRIDGE_INTEL_SANDYBRIDGE
Change-Id: I7b6bc4bfdd0481c8fe5b2b3d8f8b2eb9aa3c3b9e
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/29402
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<vendor> seems to be confused about the meaning of our maintainers list.
I get the feeling some use it to organize corporate internal teams and
branches, adding names to the list that don't show up in Gerrit and even
if, often don't react to reviewing requests (within months). Maybe they
even don't know that this is about coreboot.org?
To clarify this:
o Add an introductory paragraph mentioning development on coreboot.org.
o Explicitly state that maintainers should be registered to Gerrit.
o If a topic is tagged as `Supported` or `Maintained`, expect that
somebody reacts to review requests.
Change-Id: I9ee038dc5ee1f4993ba1d230ef6e737f20e2ff8a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/29471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Guckian
