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.
The rest of the Makefiles will be renamed in following commits.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idaf69c6871d0bc1ee5e2e53157b8631c55eb3db9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80063
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>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We've had issues in the past where building with a sufficient number of
processors would expose a previously hidden timing issue in the build.
Those have frequently been in the path of a single chip or architecture,
so this adds a few different builds.
I'd like to have a representative sampling without increasing the build
time too much so maybe in the future, we can modify the clang build
targets to be different than the GCC targets.
These can be updated to different targets over time.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I51e39bc1ce6b9b7c257d0170ce3d2b5ab99d35df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
With the addition of the clang tests, the jenkins builds are taking a
really long time to run the tests. This change allows the
"what-jenkins-does" build to be split into separate builds on jenkins.
Additionally, some jenkins builds like coverity don't need (or want)
to build clang or even the linters.
Update help with the variables.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0f8ac68c1bc8f8ff9be62d80db850355e742ee74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This tests building a single target with scanbuild so to make sure that
option hasn't been broken. Since it's a different type of build, it
hasn't previously been tested with what-jenkins-does.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8a74dac203f4d38c0cb30a0b64724e6f9095b9dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This gets rid of the duplicated directory and xml filename and uses the
--name argument to abuild instead, which also updates the test name in
the junit xml file.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ibe538da42280696190b0a7a0c63fd86a63e40214
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-tools target, make test-tools from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id62d6bb1e729892ec123ea970ca8a31e03a812d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-abuild target, make test-abuild from what-jenkins-does.
The test-abuild target had not been updated to use the ABUILD_OPTIONS
variable, so update it with the commands from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4552193894c16301defb851eb3db4bdfbfa49803
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-lint target, make test-lint with the --junit argument from
what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2f90df76126f453fbcd91f4c4af5d784ac2dbe88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having the what-jenkins-does target clean up before building,
have it call the test_cleanup target.
Clean the tegra targets.
Remove distclean from test_cleanup target - I don't think that's
expected, and people might be upset by having their .config deleted.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia9d585df05343365c89e49b1c01dba9ba865003f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch introduces new target: junit.xml-unit-tests, which builds and
runs unit-tests. It also creates build log containing build logs. This
feature allows for one to see build failures in Jenkins dashboard.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I94184379dcc2ac10f1a47f4a9d205cacbeb640fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67372
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Firmware is typically delivered as one large binary image that gets
flashed. Since this final image consists of binaries and data from
a vast number of different people and companies, it's hard to
determine what all the small parts included in it are. The goal of
the software bill of materials (SBOM) is to take a firmware image
and make it easy to find out what it consists of and where those
pieces came from. Basically, this answers the question, who supplied
the code that's running on my system right now? For example, buyers
of a system can use an SBOM to perform an automated vulnerability
check or license analysis, both of which can be used to evaluate
risk in a product. Furthermore, one can quickly check to see if the
firmware is subject to a new vulnerability included in one of the
software parts (with the specified version) of the firmware.
Further reference:
https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
- Add Makefile.inc to generate and build coswid tags
- Add templates for most payloads, coreboot, intel-microcode,
amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
intel ME and compiler (gcc,clang,other)
- Add Kconfig entries to optionally supply a path to CoSWID tags
instead of using the default CoSWID tags
- Add CBFS entry called SBOM to each build via Makefile.inc
- Add goswid utility tool to generate SBOM data
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Amdfwtool creates AMD firmware images however there is currently no way
to get information from an existing image. This commit adds amdfwread to
support that functionality. At the moment only reading PSP soft fuse
flags is supported. Example usage: `amdfwread --soft-fuse bios.bin`,
example output: `Soft-fuse:0x400000030000041`.
BUG=b:202397678
TEST=Ran amdfwread and verified that it correctly reads the soft fuse
bits, verified that built AMD FW still boots on DUT
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I15fa07c9cad8e4640e9c40e5539b0dab44424850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
As part of the `what-jenkins-does` target, combine the code coverage
data from all unit tests (currently just coreboot and libpayload).
BUG=b:203800199
TEST=`make what-jenkins-does && ls -l coreboot-builds/coverage.info`
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Id99615ca8279f80a402d5371221b8fd36fb91d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Martin Roth
Felix Singer
Arthur Heymans
Jakub Czapiga
Maximilian Brune
Robert Zieba
Martin Roth
Paul Fagerburg
Patrick Georgi