To build a CrOS-style zephyr, we need a couple of u-boot tools, so add
them here instead of rebuilding them on every zephyr build (which is
also harder to get right because search paths are no strength of python)
Change-Id: Ib95fcb644ac87c5f35f2228fe081c922452b5213
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This fixes the following issues:
bincfg.l: In function ‘parsehex’:
error: declaration of ‘val’ shadows a global declaration
bincfg.y: In function ‘generate_binary_with_gbe_checksum’:
error: comparison of integer expressions of different signedness
bincfg.y: In function ‘yyerror’:
bincfg.y:408:28: error: unused parameter ‘fp’
bincfg.y: In function ‘main’:
bincfg.y:452:15: error: unused variable ‘pos’
bincfg.y:451:16: error: unused variable ‘c’
BUG=None
TEST=Build outputs and make sure they're identical.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I60039b741c226a6b6ba53306f6fa293da89e5355
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Gets rid of these 4 warnings:
archive.c: In function ‘set_file_name’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘add_file’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘archive_files’:
warning: comparison of integer expressions of different signedness
archive.c: In function ‘convert_endian’:
warning: comparison of integer expressions of different signedness
BUG=None
TEST=Build and run
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I57ee8b31bbc9e97168e3b818c4d053eadf8a4f84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add method to disable warnings as errors
- Add help target
- Add phony targets to .PHONY
BUG=None
TEST=make all; make help; make all WERROR=""
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Icd0cfd3e2579c9016ebb616e371d1076a5a171b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fixes these warnings:
warning: alignment 1 of 'struct _psp_directory_table' is less
than 16 [-Wpacked-not-aligned]
warning: alignment 1 of 'struct _psp_combo_directory' is less
than 16 [-Wpacked-not-aligned]
In function 'find_register_fw_filename_bios_dir':
warning: implicit conversion from 'enum _amd_fw_type' to
'amd_bios_type' {aka 'enum _amd_bios_type'} [-Wenum-conversion]
BUG=None
TEST=Build and verify binaries are identical.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I761d9893ac6737b42af96c4b2a57c5a4fc61ab05
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix regression from commit 0dcc0662f3 util/cbfstool: Introduce
concept of mmap_window.
Use of region_end() wraps around at 4 GiB, if utility is run in
32bit userspace. The build completes with an invalid coreboot.rom,
while one can find error message in stdout or make.log:
E: Host address(ffc002e4) not in any mmap window!
Change-Id: Ib9b6b60c7b5031122901aabad7b3aa8d59f1bc68
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.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>
Datasheet is not publicly available. Derive which registers to dump from
IT8625E, since there are mainboards that can use either chip depending
on BOM configuration. Default values are taken from an HP 280 G2 running
a coreboot build that does not configure the Super I/O.
Change-Id: Icc8c56e9cd19e940e85176ac51b8ef978275eb71
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
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>
* Add comments to mem_parts_used.txt to point out that the order of
the entries matters when assigning IDs, so always add a new part
to the end of the file.
* Update existing mem_parts_used.txt to add the same comment.
* No updates to Zork variants, because they use an optional ID, so
the order actually doesn't matter there.
BUG=b:175898902
TEST=create a new variant of dalboz, trembyle, volteer, waddledee,
or waddledoo, and observe that mem_parts_used.txt has the new
verbiage.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Iffbd8e69a89b1b7c810c5d25c7a6148d459d8b02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
It's not obvious how to set specific byte of a multi-byte field in the
set file. Add an example (and a template) for setting MAC address.
Change-Id: Iea983071682ffebd61757497d43c70cc8214043d
Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Drop unnecessary leading empty lines in comment.
Change-Id: Idc0f9d1548336dc2df2d59b18af8d717efa60b68
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Make sure that any new directories added to the util directory
get documentation added.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I8bb415c72cf05b91c84f0a945d7767134a74c44c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48967
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is the new output of the util_readme.sh script.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ia46924474f75692192ef4b52aab714f5071f9534
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48966
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are efforts to replace Chrome EC with Zephyr. To ensure
Chromebook specific Zephyr developments (that can eventually be
built as part of a coreboot build just like Chrome EC now, and are
built with coreboot-sdk) don't break with Zephyr's toolchain, add
the toolchain to our builders so we can do some sanity checking.
Change-Id: I645a298bc350ebe7651c08aea630bdc6b93856aa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Take the test build entirely out of the image creation process. This
also allows splitting up the build steps a bit, providing more break
points in case some build/test fails.
Change-Id: Ie05d4a09f79350fd3e5415430da1edbcb3bcb443
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The test expects a README file to exist under revision control, but we
converted it to markdown, together with a rename over 2 years ago in
commit ee8780eb78.
Change-Id: I7768e116a10cb373ca35fa1c874a5949dabaa111
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The test-tools make target requires it.
Change-Id: I20819f8d587e6b3a472cdc32751e9edf505d5ba6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of hardcoding paths to the executables, use the version in the
path. This allows the scripts to work on more systems, and allows the
binary version to be changed more easily if needed.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ifcc56aa21092cd3866eacb6a02d198110ec6051d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This file was added here before util/docker existed. Anyone using this
dockerfile should use the coreboot-sdk docker container instead.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I7114abc9c91ba2d6fcfef80ae6e7d1a7a3d253cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When updating the variables in the dockerfile, if there were two or more
variables on a line, only the first would be updated. This fixes that
issue.
Change-Id: I011ccb299c7c8527b79d234075cab18be998ab43
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
SMBIOS slot information in overrridetree is not overriden
if device already exist in devicetree.
Add support to handle this information from override.
BUG= N/A
TEST= Verify generated static.c on Intel Coffee Lake CRB
Change-Id: I532436aee1d71b79171463124f7b205c145d5b05
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49738
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
[ 84s] /usr/lib/gcc/i586-suse-linux/10/../../../../i586-suse-linux/bin/ld: msrutils.o:(.bss+0x0): multiple definition of `PresentTypes'; msrtool.o:(.bss+0x14): first defined here
[ 84s] /usr/lib/gcc/i586-suse-linux/10/../../../../i586-suse-linux/bin/ld: msrutils.o:(.bss+0x4): multiple definition of `MsrTypes'; msrtool.o:(.bss+0x18): first defined here
There should be typedefs, not variable definitions.
Change-Id: I663a011e9f1fc169126570d5eac7abe82d204a90
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
It would seem that `pres` is an abbreviation for `presence`. Personally,
over the last ~2.5 years, I have seen checkpatch complaints about `pres`
on several occasions, and all of them were abbreviations for `presence`.
Given the high false positive rate for this entry, comment it out.
Change-Id: I72f1811fb1f766e7de7c4957fd9ba844c0728029
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49463
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Compilation has been broken in commit I022468f6957415ae68a7a7e70428ae6f82d23b06
Adding a missing define solved this. See https://cgit.freebsd.org/src/tree/sys/sys/fcntl.h#n319
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I3433e4c9269880d3202dd494e5b2e962757a6b87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When building as part of the coreboot build system, use the same
mechanism as other tools (cbfstool, amdfwtool, ...) so that abuild
builds ifdtool once into sharedutils instead of once per board (while
avoiding other race conditions, too).
Change-Id: I42c7b43cc0859916174d59cba6b62630e70287fd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Registers and their default values are from the datasheet ("IT8720F",
"Preliminary Specification V0.1").
Tested on an Acer G43T-AM3.
Signed-off-by: Michael Büchler <michael.buechler@posteo.net>
Change-Id: I69987be4f5cb50b3c20f06733f30b308891d5ad0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
This change emits chip config pointers for PCI devices on root bus in
static_devices.h so that the config structure can be accessed directly
without having to reference the device structure. This allows the
linker to optimize out unused parts of the device tree from early
stages like bootblock.
Change-Id: I1d42e926dbfae14b889ade6dda363d8607974cae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49214
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There were several default values given for GPIO data and status
registers. As all GPIO are configured as inputs by default, we
can't predict the values of these registers, hence set their
default values to NANA.
Change-Id: I0507dd75e0f2a5c7e4d2e9cdbe1f860b544deac3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49241
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Clay Daniels <clay.daniels.jr@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Without this target some spurious errors occurred when running make
distclean at the top level of coreboot.
Change-Id: I3d3061b386fc5b4a043cfc7ff8fd3c0da33c0e83
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49227
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit 8c99c27df1 removed util/genprof,
so it needs to be dropped here as well to avoid spurious breakages of
the build.
Change-Id: I420b5c43e2d97373a8e665f457463a06e16ecfb9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49226
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Trying to do multiple operations on the same CBFS image at the same time
likely leads to data corruption. For this reason, add BSD advisory file
locking (flock()) to cbfstool (and ifittool which is using the same file
I/O library), so that only one process will operate on the same file at
the same time and the others will wait in line. This should help resolve
parallel build issues with the INTERMEDIATE target on certain platforms.
Unfortunately, some platforms use the INTERMEDIATE target to do a direct
dd into the CBFS image. This should generally be discouraged and future
platforms should aim to clearly deliminate regions that need to be
written directly by platform scripts with custom FMAP sections, so that
they can be written with `cbfstool write`. For the time being, update
the legacy platforms that do this with explicit calls to the `flock`
utility.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I022468f6957415ae68a7a7e70428ae6f82d23b06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
They aren't specific to AC power operation anymore. Also adapt autoport.
Change-Id: Ib04d0a08674b7d2773d440d39bd6dfbd4359e0fb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49089
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All mainboards use the same values for AC and battery, even desktop
boards without a battery. Use the AC values everywhere and drop the
battery values. Subsequent commits will rename the AC power options
accordingly, and will also clean up the corresponding acpigen code.
This is intentional so as to ease reviewing the devicetree changes.
Also update util/autoport accordingly.
Change-Id: I581dc9b733d1f3006a4dc81d8a2fec255d2a0a0f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
https://qa.coreboot.org/job/untested-coreboot-files reports a bunch of
untouched Makefiles, so we never even attempt to build those tools.
Change-Id: I70ca658d9642b84fa8388c72ecb83327a6a74291
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Currently, use of the VPD driver to read VPD tables from flash
requires the use of a custom FMAP with one or more VPD regions.
Extend this funtionality to boards using the default FMAP by
creating a dedicated VPD region when the driver is selected.
Test: build qemu target with CONFIG_VPD selected, verify entry
added to build/fmap.fmd.
Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
New util directories have been added with no description.md file.
The description file for supermicro was added at a secondary level,
which doesn't help a user find the util since no path was added. Move
it up to the top level.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I40b4c25dd7706513e96c6b8078a34160f8bb901e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tom Hiller <thrilleratplay@gmail.com>
Add the stdint.h header, and drop the GLIBC section from amdfwtool.h to build this tool on FreeBSD as well as Linux.
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I295fd308b0f5e2902931f02c9455823a614976de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48977
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes the build with an external (coreboot) toolchain. When
the toolchain is not under util/crossgcc/xgcc, setting XGCCPATH to
/path/to/toolchain results in the error:
toolchain.inc:169: The coreboot toolchain version of iasl '<date>' was
not found
The reason is that the xcompile script incorrectly assumes XGCCPATH to
have a trailing slash.
Change-Id: Ifcc4bd2b081fa3603420dc0a8cab3b47967ebc65
Signed-off-by: Michele Guerini Rocco <rnhmjoj@inventati.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Introduce a new device `gpio` that is going to be used for generic
abstraction of gpio operations in the devicetree.
The general idea behind this is that every chip can have gpios that
shall be accessible in a very generic way by any driver through the
devicetree.
The chip that implements the chip-specific gpio operations has to assign
them to the generic device operations struct, which then gets assigned
to the gpio device during device probing. See CB:48583 for how this gets
done for the SoCs using intelblocks/gpio.
The gpio device then can be added to the devicetree with an alias name
like in the following example:
chip soc/whateverlake
device gpio 0 alias soc_gpio on end
...
end
Any driver that requires access to this gpio device needs to have a
device pointer (or multiple) and an option for specifying the gpio to be
used in its chip config like this:
struct drivers_ipmi_config {
...
DEVTREE_CONST struct device *gpio_dev;
u16 post_complete_gpio;
...
};
The device `soc_gpio` can then be linked to the chip driver's `gpio_dev`
above by using the syntax `use ... as ...`, which was introduced in
commit 8e1ea52:
chip drivers/ipmi
use soc_gpio as gpio_dev
register "bmc_jumper_gpio" = "GPP_D22"
...
end
The IPMI driver can then use the generic gpio operations without any
knowlege of the chip's specifics:
unsigned int gpio_val;
const struct gpio_operations *gpio_ops;
gpio_ops = dev_get_gpio_ops(conf->gpio_dev);
gpio_val = gpio_ops->get(conf->bmc_jumper_gpio);
For a full example have a look at CB:48096 and CB:48095.
This change adds the new device type to sconfig and adds generic gpio
operations to the `device_operations` struct. Also, a helper for getting
the gpio operations from a device after checking them for NULL pointers
gets added.
Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with
CB:48711 and OCP DeltaLake with CB:48672.
Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786
Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Generates de-duplicated SPD files using a global memory part
list provided by the mainboard in JSON format.
BUG=b:173132516
Change-Id: I4964ec28d74ab36c6b6f2e9dce6c923d1df95c84
Signed-off-by: Amanda Huang <amanda_hwang@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48526
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the option to cache DIMM SPD data in an FMAP region
is closely coupled to a single board (google/hatch) and requires
a custom FMAP to utilize.
Loosen this coupling by introducing a Kconfig option which adds
a correctly sized and aligned RW_SPD_CACHE region to the default FMAP.
Add a Kconfig option for the region name, replacing the existing hard-
coded instance in spd_cache.h. Change the inclusion of spd_cache.c to
use this new Kconfig, rather than the board-specific one currently used.
Lastly, have google/hatch select the new Kconfig when appropriate to
ensure no change in current functionality.
Test: build/boot WYVERN google/hatch variant with default FMAP, verify
FMAP contains RW_SPD_CACHE, verify SPD cache used via cbmem log.
Also tested on an out-of-tree Purism board.
Change-Id: Iee0e7acb01e238d7ed354e3dbab1207903e3a4fc
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48520
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We took the assumption the APCB(0x60) and APCB_BK(0x68) are the
same file. For picasso, they are. For later programe, they are not.
Change-Id: Idea7847691c2b511b489c306f04a8cb8945fd057
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The DWORD used to indicate the Embedded Firmware Structure's generation
uses 1 to indicate a first-gen structure, e.g. a SPI device's erased
value of 0xffffffff. A 0 in bit 0 is how Client PSPs will interpret
the structure as designed for second-gen.
This change and the original addition should have no effects on
any current products as none interpret offset 0x24.
BUG=b:158755102
TEST=inspect EFS in coreboot.rom
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: If391f356a1811ed04acdfe9ab9de2e146f6ef5fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47769
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support in fmaptool to generate a macro in C header
file that provides a list of section names that do not have any
subsections. This is useful for performing build time tests on these
sections.
BUG=b:171534504
Change-Id: Ie32bb8af4a722d329f9d4729722b131ca352d47a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
All x86 platforms until now have memory mapped up to a maximum of
16MiB of SPI flash just below 4G boundary in host address space. For
newer platforms, cbfstool needs to be able to accommodate additional
windows in the host address space for mapping SPI flash size greater
than 16MiB.
This change adds two input parameters to cbfstool ext-win-base and
ext-win-size which a platform can use to provide the details of the
extended window in host address space. The extended window does not
necessarily have to be contiguous with the standard decode window
below 4G. But, it is left upto the platform to ensure that the fmap
sections are defined such that they do not cross the window boundary.
create_mmap_windows() uses the input parameters from the platform for
the extended window and the flash size to determine if extended mmap
window is used. If the entire window in host address space is not
covered by the SPI flash region below the top 16MiB, then mapping is
assumed to be done at the top of the extended window in host space.
BUG=b:171534504
Change-Id: Ie8f95993e9c690e34b0e8e792f9881c81459c6b6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47882
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds the concept of mmap_window to describe how the SPI
flash address space is mapped to host address space on x86
platforms. It gets rid of the assumption that the SPI flash address
space is mapped only below the 4G boundary in host space. This is
required in follow up changes to be able to add more decode windows
for the SPI flash into the host address space.
Currently, a single mmap window is added i.e. the default x86 decode
window of maximum 16MiB size living just below the 4G boundary. If the
window is smaller than 16MiB, then it is mapped at the top of the host
window.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: I8dd3d1c922cc834c1e67f279ffce8fa438d8209c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change renames the macro `IS_TOP_ALIGNED_ADDRESS` to
`IS_HOST_SPACE_ADDRESS` to make it clear that the macro checks if
given address is an address in the host space as opposed to the SPI
flash space.
BUG=b:171534504
Change-Id: I84bb505df62ac41f1d364a662be145603c0bd5fa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47830
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool overloads baseaddress to represent multiple things:
1. Address in SPI flash space
2. Address in host space (for x86 platforms)
3. Offset from end of region (accepted as negative number)
This was done so that the different functions that use these
addresses/offsets don't need to be aware of what the value represents
and can use the helper functions convert_to_from* to get the required
values.
Thus, even if the user provides a negative value to represent offset
from end of region, it was stored as an unsigned integer. There are
special checks in convert_to_from_top_aligned which guesses if the
value provided is really an offset from the end of region and converts
it to an offset from start of region.
This has worked okay until now for x86 platforms because there is a
single fixed decode window mapping the SPI flash to host address
space. However, going forward new platforms might need to support more
decode windows that are not contiguous in the host space. Thus, it is
important to distinguish between offsets from end of region and
addresses in host/SPI flash space and treat them separately.
As a first step towards supporting this requirement for multiple
decode windows on new platforms, this change handles the negative
offset provided as input in dispatch_command before the requested cbfs
operation is performed.
This change adds baseaddress_input, headeroffset_input and
cbfsoffset_input to struct param and converts them to offsets from
start of region before storing into baseaddress, headeroffset and
cbfsoffset if the inputs are negative.
In follow up changes, cbfstool will be extended to add support
for multiple decode windows.
BUG=b:171534504
TEST=Verified using abuild with timeless option for all coreboot
boards that there is no change in the resultant coreboot.rom file.
Change-Id: Ib74a7e6ed9e88fbc5489640d73bedac14872953f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47829
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION
feature. It's not useful to end-users in this stage so it cannot be
selected in menuconfig (and should not be used other than for
development) yet. With this patch coreboot can verify the metadata hash
of the RO CBFS when it starts booting, but it does not verify individual
files yet. Likewise, verifying RW CBFSes with vboot is not yet
supported.
Verification is bootstrapped from a "metadata hash anchor" structure
that is embedded in the bootblock code and marked by a unique magic
number. This anchor contains both the CBFS metadata hash and a separate
hash for the FMAP which is required to find the primary CBFS. Both are
verified on first use in the bootblock (and halt the system on failure).
The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes
to show some paths that need to be different when full protection
against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For
normal verification it is sufficient to check the FMAP and the CBFS
metadata hash only once in the bootblock -- for TOCTOU verification we
do the same, but we need to be extra careful that we do not re-read the
FMAP or any CBFS metadata in later stages. This is mostly achieved by
depending on the CBFS metadata cache and FMAP cache features, but we
allow for one edge case in case the RW CBFS metadata cache overflows
(which may happen during an RW update and could otherwise no longer be
fixed because mcache size is defined by RO code). This code is added to
demonstrate design intent but won't really matter until RW CBFS
verification can be supported.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the upcoming introduction of CBFS verification, a lot more CBFS
files will have hashes. The current cbfstool default of always printing
hash attributes when they exist will make cbfstool print very messy.
Therefore, hide hash attribute output unless the user passed -v.
It would also be useful to be able to get file attributes like hashes in
machine parseable output. Unfortunately, our machine parseable format
(-k) doesn't really seem designed to be extensible. To avoid breaking
older parsers, this patch adds new attribute output behind -v (which
hopefully no current users pass since it doesn't change anything for -k
at the moment). With this patch cbfstool print -k -v may print an
arbitrary amount of extra tokens behind the predefined ones on a file
line. Tokens always begin with an identifying string (e.g. 'hash'),
followed by extra fields that should be separated by colons. Multiple
tokens are separated by the normal separator character (tab).
cbfstool print -k -v may also print additional information that applies
to the whole CBFS on separate lines. These lines will always begin with
a '[' (which hopefully nobody would use as a CBFS filename character
although we technically have no restrictions at the moment).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9e16cda393fa0bc1d8734d4b699e30e2ae99a36d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function name clashes with cbfs_walk() in the new commonlib CBFS
stack, so rename it to cbfs_legacy_walk(). While we could replace it
with the new commonlib implementation, it still has support for certain
features in the deprecated pre-FMAP CBFSes (such as non-standard header
alignment), which are needed to handle old files but probably not
something we'd want to burden the commonlib implementation with. So
until we decide to deprecate support for those files from cbfstool as
well, it seems easier to just keep the existing implementation here.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I37c7e7aa9a206372817d8d0b8f66d72bafb4f346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch reduces some code duplication in cbfstool by switching it to
use the CBFS data structure definitions in commonlib rather than its own
private copy. In addition, replace a few custom helpers related to hash
algorithms with the official vboot APIs of the same purpose.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
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>
The template for overridetree.cb includes HeciEnabled, which has
been removed from the CNL config struct, so remove it from the
overridetree.
BUG=b:174360951
TEST=`new_variant_fulltest.sh puff` succeeds
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: I87f67c53cc75d9ddd40b4960739180a95de6ecd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Add MT53D512M64D4NW-046 WT:F memory part to LP4x global list of
available LP4x parts and to the global JSON file containing LP4x parts
and their characteristics.
BUG=b:172993397
TEST=none
Change-Id: I09c6eab640c169dbdb451964967d14a31e314496
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47980
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Print whether the SOC supports TME/MKTME. If the SOC supports the
feature, print the status of enable and lock bit from TME_ACTIVATE
MSR. -t option prints this status.
Sample output:
If TME/MKTME is supported:
============= Dumping INTEL TME/MKTME status =============
TME supported : YES
TME locked : YES
TME enabled : YES
====================================================
If TME/MKTME is not supported:
============= Dumping INTEL TME status =============
TME supported : NO
====================================================
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Change-Id: I584ac4b045ba80998d454283e02d3f28ef45692d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Our current cbfstool has always added a compression attribute to the
CBFS file header for all files that used the cbfstool_convert_raw()
function (basically anything other than a stage or payload), even if the
compression type was NONE. This was likely some sort of oversight, since
coreboot CBFS reading code has always accepted the absence of a
compression attribute to mean "no compression". This patch fixes the
behavior to avoid adding the attribute in these cases.
Change-Id: Ic4a41152db9df66376fa26096d6f3a53baea51de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Update url for docker install instructions.
- Update docker-cleanall target to require verification.
- Update docker-jenkins-attach target to check for docker and
use docker variable.
- Update spaces to tabs in the docs targets.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ic1e1a545024fe1fdc37d7d8c7e6f54f124d1697b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For whatever reason, I've had buildgcc fail to download packages a
number of times. Adding 2 additional retries before failing helps
with that problem.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I060eaa5a0da955436169e2199c1c62044dcfd5ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes (https://nasm.us/doc/nasmdocc.html):
Version 2.15.05:
Correct %ifid $ and %ifid $$ being treated as true.
Add --reproducible option to suppress NASM version numbers and
timestamps in output files.
Version 2.15.04:
Correct the encoding of the ENQCMDS and TILELOADT1 instructions.
Fix case where the COFF backend (the coff, win32 and win64 output
formats) would add padding bytes in the middle of a section if a
SECTION/SEGMENT directive was provided which repeated an
ALIGN= attribute. This neither matched legacy behavior, other
backends, or user expectations.
Fix SSE instructions not being recognized with an explicit memory
operation size (e.g. movsd qword [eax],xmm0).
Change-Id: I3f9aa8e743f2dc50fce1ce68718c0ae17209a509
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44694
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MR0 may not always be programmed in the training result registers. Thus,
do not rely on its values. Also account for per-channel differences.
Change-Id: Iaf3b545ea55735b46caf1bd62d5859f2b3efa159
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This field is only 4 bits wide.
Change-Id: I2cb746e98176d58fc5be423e18babdaa8801b096
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In order to allow override trees to hide/unhide a device copy
the hidden state to the base device. This allows a sequence
of states like:
chipset.cb: mark device 'off' by default
devicetree.cb: mark device 'hidden' (to skip resource allocation)
overridetree.cb: mark device 'on' for device present on a variant
BUG=b:159143739
BRANCH=volteer
TEST=build volteer variants with TCSS RP0 either hidden or on
and check the resulting static.c to see if the hidden bit is
set appropriately.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Iebe5f6d2fd93fbcc4329875565c2ebf4823da59b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47197
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Martin Roth