coreboot uses TianoCore interchangeably with EDK II, and whilst the
meaning is generally clear, it's not the payload it uses. EDK II is
commonly written as edk2.
coreboot builds edk2 directly from the edk2 repository. Whilst it
can build some components from edk2-platforms, the target is still
edk2.
[1] tianocore.org - "Welcome to TianoCore, the community supporting"
[2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform
firmware development environment for the UEFI and UEFI Platform
Initialization (PI) specifications."
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently, running abuild in a fresh checkout without having built the
toolchain results in the following confusing behaviour:
1. Run abuild. It fails due to the missing coreboot toolchain, and the
error message suggests running `make crossgcc`.
2. Run `make crossgcc`. It succeeds.
3. Re-run abuild. It still fails due to a missing coreboot toolchain.
This happens because the first abuild run generates an xcompile file
which uses the system toolchain. The second abuild run doesn't
regenerate the xcompile, so it still fails due to the non-coreboot
toolchain.
To avoid this confusing behaviour, regenerate the xcompile file every
time abuild is run.
BUG=None
TEST=Perform the steps above in a clean checkout. The second abuild run
now succeeds.
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I78a7702c45cecbfe8460ec55df03741e5ced94b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Like USE_AMD_BLOBS and USE_QC_BLOBS in the case of the AMD and Qualcomm
repos, FSP_USE_REPO controls if the Intel FSP repo will get checked out
and will be available during the Jenkins runs. ADD_FSP_BINARIES will get
selected in drivers/intel/fsp2_0/Kconfig when FSP_USE_REPO is selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I72faa6f9e5f2b06ab7cd43595ae0b49bf4d39630
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This was originally several commits that had to be squashed into one
because the intermediate states weren't able to build coreboot:
- one to remove everything that wasn't our own code, leaving only
regex.[ch], toada.c, description.md and Makefile.inc.
- one to copy in Linux 5.13's scripts/kconfig and adapt Makefile.inc
to make the original Makefile work again.
- adapt abuild to use olddefconfig, simplifying matters.
- apply patches in util/kconfig/patches.
- Some more adaptations to the libpayload build system.
The patches are now in util/kconfig/patches/, reverse applying them
should lead to a util/kconfig/ tree that contains exactly the Linux
version + our own 5 files.
Change-Id: Ia0e8fe4e9022b278f34ab113a433ef4d45e5c355
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
I a file in configs/* has no suffix, then the default configuration
will override the results of the build generated by the configfile
from configs/*. Fix this by adding a '_' to the buildname.
Change-Id: Ic47105fafca41f1905a6569943079623bec5405a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit 3ac3c4ebac ("abuild: Allow disabling mainboards").
This mechanism helped getting Chrome OS' coreboot divergence sorted
out in the 2015/2016 timeframe but hasn't been used by anybody since
then. Let's not encourage people to push non-working builds without
good reason and discussion (the result of which could be that we
re-introduce this mechanism).
Change-Id: I8e2f2e1a5d4617baa49cbcb1a640a1ea270007ef
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50518
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sometimes boards enable it by default, making the Kconfig option
impossible to disable without messing with the Kconfig files. This
shouldn't happen, so report on such occurrences early.
TEST=Tried building GOOGLE_KOHAKU through abuild with -x, without
-x and both cases after having added a "select CHROMEOS" for testing
and it failed in the "without -x with select" scenario while properly
configuring and passing all other builds.
Change-Id: Ieb6bcbf3e9ca8cd4ced85c7c9ffaa39505f5a9b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This file was being written to the root src directory. It is the only
file being written to src during a normal build, while all others are
being written to $(obj). I added a new variable to allow specifying the
xcompile path. This allows generating a single file if building multiple
boards. I also moved the default location into $(obj) so we don't
pollute the src directory by default.
I also cleaned up the generation of xcompile by removing the unnecessary
eval and NOCOMPILE check.
I also left .xcompile in distclean so it cleans up stale files.
Since .xcompile is written into $(obj), `make clean` will now remove it.
The tegra Makefiles are outside of the normal build process, so I just
updated those Makefiles to point to the default xcompile location of a
normal build. The what-jenkins-does target had to be updated to support
these special targets. We generate an xcompile specifically for these
targets and pass it into the Makefile. Ideally we should get these
targets added to the main build.
BUG=b:112267918
TEST=ran `emerge-grunt coreboot` and `make what-jenkins-does`
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia83f234447b977efa824751c9674154b77d606b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/28101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds a separate blobs repository for Qualcomm blobs,
analogous to the existing AMD blobs. Qualcomm's binary licenses allow
files to be redistributed and used by anyone, but they explicitly
require the user to agree to the license terms when just *downloading*
the binary (even if they're not using them to build any firmware). Some
community members do not like to have to agree to licenses for files
they're not actually using, so we are keeping these files separate from
the main blobs repository and adding an extra Kconfig to make sure the
user is aware of and must explicitly agree to this before downloading
these files.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I247746c1b633343064c9f32ef1556000475d6c4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit 9ff4029db9.
Pulling the toplevel Makefile into a tiny one has all sorts of side
effects. For instance, the toplevel (random) .config is also included
so the results depend on the board that is selected there. What finally
broke it is a line that is unconditionally printed for AMD Picasso
boards resulting in lots of lines like this:
skipping LENOVO_W520 because we're missing compilers for \
(Adding PSP c7ce61492157d3237f679c4a40a08b79 \
.../coreboot/3rdparty/amd_blobs/picasso/PSP/PspBootLoader_prod_RV.sbin)
While both issues, the random .config and amd/picasso, could be worked
around easily, it seems hard to predict what other pitfalls are lurking
in the Makefile inclusion. Also, the problem solved by its inclusion
can be fixed by a much simpler `make .xcompile`.
Change-Id: I2ff70f561d717eb30e5f3c06c83e83468e174ec5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To provide sane defaults for most of the user base, this patch switches
on the USE_BLOBS option by default. Since it only changes the default,
this behaviour can still be easily disabled.
With this abuild doesn't have to select USE_BLOBS any more, so what
abuild tests becomes the coreboot default again.
Change-Id: Ia0632b9ae7a1f212a8640b3faec2695d17d238c5
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>