On the intel/glkrvp
compressed:
- romstage: 29659
- verstage: 31303
non compressed:
- romstage: 46244
- verstage: 47012
On qemu (with some additional patch to not run XIP)
compressed:
- romstage: 11203
non compressed:
- romstage: 13924
Even with a small romstage the size improvements are substantial,
which should result in a speedup when loading the stage. On the
up/squared loading romstage is sped up by 9ms.
TESTED: successfully boot the up/squared & google/vilboz.
Change-Id: I6906c8b6df45f2433d92d2ff1d1748cc4926c73a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
The tool "include-what-you-use" analyzes each file's headers and makes
recommendations for header files to add and remove. There are
additional scripts as part of the package that will make these changes
directly based on the recommendations, but due to the way coreboot
compiles code in/out base on Kconfig options, this isn't really safe for
the project to use.
It is a good starting point though.
To use, set the IWYU kconfig option, then build with the command:
make -k
Because this doesn't actually build any files, the -k option is needed
or make will stop after looking at the first file.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I084813f21a3c26cac1e4e134bf8a83eb8637ff63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On the intel/glkrvp
compressed:
- romstage: 29659
- verstage: 31303
non compressed:
- romstage: 46244
- verstage: 47012
On qemu (with some additional patch to not run XIP)
compressed:
- romstage: 11203
non compressed:
- romstage: 13924
Even with a small romstage the size improvements are substantial,
which should result in a speedup when loading the stage. On the
up/squared loading romstage is sped up by 9ms.
TESTED: successfully boot the up/squared & google/vilboz.
Change-Id: Iac24d243c4bd4cb8c1db14a8e9fc43f508c2cd5d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
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>
Most of the src/soc/Kconfig files are only there for AMD and Intel to
load the main SoC Kconfig files before any common files. That can be
done in src/Kconfig instead. Moving the loads to the lower level allows
the removal of all but the Intel soc/Kconfig file, which can be removed
in a follow-on patch.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5061191fe23e0b7c745e90874bd7b390806bbcfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This adds 2 flags:
* invisible opt-in flag for platforms on which clang seems to work
* visible opt-in flag to allow experimenting
Clang seems to work rather well on x86_32 so it makes sense to start
adding that to Jenkins buildtesting, which this allows.
This allows abuild to differentiate between targets that are known to
build with clang. This makes buildtesting just those targets easier.
Change-Id: I46f1bad59bda94f60f4a141237ede11f6eb93cc2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Read fw_config value from VPD.
This new option can be used where chrome EC is not supported like
pre-silicon platform and fw_config can be updated by VPD tool in OS.
TEST= boot to OS and read fw_config from vpd
1. Boot to OS
2. Write "fw_config" in VPD
ex) vpd -i "RW_VPD" -s "fw_config"="1"
3. reboot and check fw_config value from coreboot log
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I4df7d5612e18957416a40ab854fa63c8b11b4216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Request fw_config values from various sources (as enabled via Kconfig)
until a valid value has been read.
With this change, Chrome EC CBI takes precedence over CBFS fw_config.
TEST=select both configs and check fallback behavior.
1. select both FW_CONFIG_SOURCE_CHROMEEC_CBI and FW_CONFIG_SOURCE_CBFS
2. check log for reading fw_config from CBI and CBFS
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I215c13a4fcb9dc3b94f73c770e704d4e353e9cff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Introduce the `smbios_dev_info` devicetree keyword to specify the
instance ID and RefDes (Reference Designation) of onboard devices.
Example syntax:
device pci 1c.0 on # PCIe Port #1
device pci 00.0 on
smbios_dev_info 6
end
end
device pci 1c.1 on # PCIe Port #2
device pci 00.0 on
smbios_dev_info 42 "PCIe-PCI Time Machine"
end
end
The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using
this syntax to control the generated Type 41 entries. When this option
is enabled, Type 41 entries are only autogenerated for devices with a
defined instance ID. This avoids having to keep track of which instance
IDs have been used for every device class.
Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not
enabled will result in a build-time error, as the syntax is meaningless
in this case. This is done with preprocessor guards around the Type 41
members in `struct device` and the code which uses the guarded members.
Although the preprocessor usage isn't particularly elegant, adjusting
the devicetree syntax and/or grammar depending on a Kconfig option is
probably even worse.
Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
For coreboot proper, I/O APIC programming is not really required,
except for the APIC ID field. We generally do not guard the related
set_ioapic_id() or setup_ioapic() calls with CONFIG(IOAPIC).
In practice it's something one cannot leave unselected, but maintain
the Kconfig for the time being.
Change-Id: I6e83efafcf6e81d1dfd433fab1e89024d984cc1f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
CPU_INFO_V2 changes the behavior of cpu_info(). There is now only 1
cpu_info struct per cpu. This means that we no longer need to allocate
it at the top of each threads stack.
We can now in theory remove the CONFIG_STACK_SIZE alignment on the
thread stack sizes. We can also in theory use threads in SMM if you are
feeling venturesome.
BUG=b:194391185, b:179699789
TEST=Perform reboot stress test on guybrush with COOP_MULTITASKING
enabled.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5e04d254a00db43714ec60ebed7c4aa90e23190a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
It avoids the dependency on bison/flex, minimally speeds up the build
and also works around weird race conditions in some versions of bison
that need more investigation.
The issue this avoids manifests as a build error when creating
parser.tab.c:
input in flex scanner failed
make: *** [util/kconfig/Makefile.inc:66: build/util/kconfig/parser.tab.c] Error 2
Since the error happens within bison the alternative would be to make
bison part of our crossgcc environment to ensure that no broken OS
build is used.
BUG=b:197515860
TEST=things build with bison not installed
Change-Id: Ib35dfb7beafc0a09dc333e962b1e3f33df46a854
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some mainboards need a mainboard-specific mechanism to access option
values. Allow mainboards to implement the option API. Also, add some
documentation about the current option API, and describe when should
one reimplement the option API in mainboard code: only when the code
is mainboard-specific to comply with externally-imposed constraints.
Change-Id: Idccdb9a008b1ebb89821961659f27b1c0b17d29c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Mainboards with variants may not always use the same cmos.layout file.
Turn the hardcoded path into a Kconfig symbol to allow changing it.
Tested with BUILD_TIMELESS=1: Without including the config file in the
coreboot.rom and with `USE_OPTION_TABLE` selected, building for the Asus
P8H61-M PRO produces an identical coreboot image.
Change-Id: I4cc622dcb70855c06cb8a816c34406f8421180df
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54366
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add general debug macros that print resource information.
These are available to select if DEFAULT_CONSOLE_LOGLEVEL_8.
The macros are helpful in debugging complex resource allocation
with multiple buses. The macros are moved from soc/intel/xeon_sp,
where they were originally developed.
Change-Id: I2bdab7770ca5ee5901f17a8af3a9a1001b6702e4
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The USB4 retimer device needs to declare a _DSM with specific functions
that allow for GPIO control to turn off the power when an external
device is not connected. This driver allows the mainboard to provide
the GPIO that is connected to the power control.
BUG=b:156957424
Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change extends the devicetree override one more layer and allows
the chipset to provide the base devicetree. This allows the chipset to
assign alias names to devices as well as set default register values.
This works for both the baseboard devicetree.cb as well as variant
overridetree.cb.
chipset.cb:
device pci 15.0 alias i2c0 off end
devicetree.cb:
device ref i2c0 on end
BUG=b:156957424
Change-Id: Ia7500a62f6211243b519424ef3834b9e7615e2fd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of enabling ASAN_IN_ROMSTAGE from Kconfig file in a
platform's dedicated directory, let's introduce a new config
option HAVE_ASAN_IN_ROMSTAGE to denote if a given platform
supports ASan in romstage.
Similary, use HAVE_ASAN_IN_RAMSTAGE to indicate
if a given platform supports ASan in ramstage. Consequently, we
no longer have to make ASan x86 specific.
Change-Id: I36b144305465052718f245cacf61d3ca44dfb4b4
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44258
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This patch adds ASan support to romstage on x86 architecture.
A Kconfig option is added to enable ASan in romstage. Compiler
flags are updated. A memory space representing the shadow region
is reserved in linker section. And a function call to asan_init()
is added to initialize shadow region when romstage loads.
Change-Id: I67ebfb5e8d602e865b1f5c874860861ae4e54381
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43604
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
An additional compiler flag is added to make use of the shadow
offset callback feature we introduced in our GCC patch. Also,
a comment is added to tell user that this GCC patch needs to be
applied in order to use ASan.
Change-Id: Ia187e4991bf808f4ae137eff0ffdb9baea0085e9
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
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>
If VPD_SMBIOS_VERSION is selected, it would read VPD_RO variable that can
override SMBIOS type 0 version.
One special scenario of using this feature is to assign a BIOS version to
a coreboot image without the need to rebuild from source.
VPD_SMBIOS_VERSION default is n.
Tested=On OCP Delta Lake, dmidecode -t 0 can see the version being updated
from VPD.
Change-Id: Iee62ed900095001ffac225fc629b3f2f52045e30
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: insomniac <insomniac@slackware.it>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Kconfig 4.17 started using the $(..) syntax for environment variable
expansion while we want to keep expansion to the build system.
Older Kconfig versions (like ours) simply drop the escapes, not
changing the behavior.
While we could let Kconfig expand some of the variables, that only
splits the handling in two places, making debugging harder and
potentially messing with reproducible builds (e.g. when paths end up
in configs), so escape them all.
Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change introduces a new top-level interface for interacting with a
bitmask providing firmware configuration information.
This is motivated by Chromebook mainboards that need to support multiple
different configurations at runtime with the same BIOS. In these
devices the Embedded Controller provides a bitmask that can be broken
down into different fields and each field can then be broken down into
different options.
The firmware configuration value could also be stored in CBFS and this
interface will look in CBFS first to allow the Embedded Controller value
to be overridden.
The firmware configuration interface is intended to easily integrate
into devicetree.cb and lead to less code duplication for new mainboards
that make use of this feature.
BUG=b:147462631
TEST=this provides a new interface that is tested in subsequent commits
Change-Id: I1e889c235a81545e2ec0e3a34dfa750ac828a330
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
