This reverts commit d94f8bbe9d.
This is a reland of https://review.coreboot.org/57651. The original
change broke parallel abuild runs since the xcompile file was deleted by
every recursive call to abuild. This issue was fixed by rebasing on top
of a change which only regenerates the xcompile on non-recursive calls.
BUG=None
TEST=Parallel abuild run succeeds.
Change-Id: I086ba7b2ae1b8b14459838bd18ce962a84aa306d
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
elogtool was setting the timestamp with the wrong value in the month.
This CL fixes that by incrementing the month by one. This is needed
since gmtime() returns the month value starting at 0.
TEST=pytest elogtool_test.py (see next CL in relation chain)
Change-Id: I00f89ed99b049caafba2e47feae3c068245f9021
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
If abuild called itself recursively, the file already exists and we can
spare us one evaluation of all the makefiles per recursive abuild run.
Change-Id: Id3e2239354ec251c24c03c971987586deeb026c5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Defining defaults for symbols used inside choices is not allowed. Add a
check for this, so we can drop the existent, overly restrictive checks
in the follow-up change.
Change-Id: I45bce2633dbd168fceb81ceae9b68621b28526e8
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Various fixes to gnat and the improved nds32 backend have been merged
into gcc by now, so we don't need to carry those patches anymore.
Change-Id: Icdee2a8beedd109ee1f0eef6f32f7accbf66674b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The migration to the new unified version of spd_tools is complete, so
the old lp4x and ddr4 versions can be removed.
BUG=b:191776301
TEST=None
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I6b1fc297739efc8dc7d7eec64956bf3343984604
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Ensure that the order of entries in each platform manifest is consistent
every time spd_gen is run.
BUG=b:191776301
TEST=Run spd_gen for lp4x and ddr4, check that the manifests are
unchanged.
Change-Id: I7bfea65c8fc781df80a8725c0cf20c7547c857e8
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Update the new variant templates to refer to the new unified version
of spd_tools:
- Update the comments in mem_parts_used.txt
- Change the placeholder SPD in Makefile.inc to 'placeholder'
BUG=b:191776301
TEST=None
Change-Id: I03265de0d1182da81dd25a2fe6f940a0b82e5fa4
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The value of level defined in table is the default one. We now give an
extra option in config file to change this value so some FWs can be
dropped in a more optimized way.
For the non A/B recovery mode, The value could be L1, L2, Lb or Lx,
which are level 1, leve 2, level both and using default value. If it
is empty or Lx, left the level in table unchanged.
Give a redundant field [12bxBX] in regular exprssion for A/B recovery
which will be done later.
Change-Id: I0847bc3793467a2299f14d1d2d2486f3f858d7f3
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57612
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Currently spd_tools treats PCO and PLK as separate platforms. This is
unnecessary since they have the same SPD requirements. Remove PLK, and
use PCO as the platform for all zork variants.
BUG=b:191776301
TEST=None
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I7eeeab53fb3e0d92c3675fb80b4747297d4257ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Combine the existing lp4x and ddr4 READMEs into a single file, and
update it to reflect the new unified version of the tools.
BUG=b:191776301
TEST=None
Change-Id: I866932a1d0b5b6b47b0daff893b37de7a302b4e6
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Add a 'Generated by' string to the generated Makefile.inc and
dram_id.generated.txt, showing the command used to generate the files.
BUG=b:191776301
TEST=Run part_id_gen, check that the generated files contain the string
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: Ic9a7826212a732288f36f111b7bc20365a1f702d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently, one of the arguments to part_id_gen is the directory
containing the SPD files, e.g. spd/lp4x/set-0. This requires the user of
the tool to understand the spd/ directory structure, and manually look
up the set number corresponding to their platform.
Change part_id_gen to take the platform and memory technology as
arguments instead of the SPD directory, and automatically determine the
SPD directory by reading the platforms manifest file generated by
spd_gen.go.
BUG=b:191776301
TEST=Run part_id_gen and check that the generated Makefile.inc and
dram_id.generated.txt are the same as before. Example:
util/spd_tools/bin/part_id_gen \
ADL \
lp4x \
src/mainboard/google/brya/variants/kano/memory \
src/mainboard/google/brya/variants/kano/memory/mem_parts_used.txt
Change-Id: I7cd7243d76b5769e8a15daa56b8438274bdd8e96
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57586
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, the maximum part ID of 15 is enforced only for manually
assigned IDs. Also enforce it for automatically assigned IDs.
BUG=b:191776301
TEST=part_id_gen fails when the number of part IDs which would be
assigned is greater than MaxMemoryId.
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I802190a13b68439ccbcdb28300ccc5fd1b38a9c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57691
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This CL fixes a compilation error that happens in 32-bit platforms.
This error happens because printf() was using %ld instead of %zu to
print size_t variables.
This CL fixes it.
BUG=b:200608182
TEST=emerge-kevin (ARM 32-bit)
TEST=emerge-eve (Intel 64-bit)
Change-Id: I340e108361c052601f2b126db45caf2e35ee7ace
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Currently there are two versions of gen_part_id.go, one for LP4x and one
DDR4. This change implements a unified version of this tool.
The new part_id_gen.go is almost identical to the existing
ddr4/gen_part_id.go. The new version was based on the ddr4 version and
not the lp4x version, since the ddr4 version contains extra logic to
support fixed IDs in the mem_parts_used files.
The only non-trivial change from ddr4/gen_part_id.go is to include the
full paths of SPD files in the generated Makefile.inc. E.g. instead of
SPD_SOURCES += lp4x-spd-1.hex
the full path relative to the coreboot root directory is included:
SPD_SOURCES += spd/lp4x/set-0/spd-1.hex
BUG=b:191776301
TEST=For each variant of brya/volteer/dedede/guybrush/zork, run
part_id_gen and verify that the generated Makefile.inc and
dram_id.generated.txt are identical to those currently in the src tree,
except for the modified SPD file paths in Makefile.inc.
Example:
util/spd_tools/bin/part_id_gen \
spd/lp4x/set-0 \
src/mainboard/google/brya/variants/kano/memory \
src/mainboard/google/brya/variants/kano/memory/mem_parts_used.txt
Change-Id: Ib33d09076f340f688519dae7956a2b27af090c0b
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.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>
This change uses _dev_${ALIAS_NAME} as the name for `struct device` if
the device has an alias. In addition to that, it emits
_dev_${ALIAS_NAME}_ptr which points to the device structure. This
allows developers to directly reference a particular device in the tree
using alias name without having to walk the entire path. In later CLs,
mainboards are transitioned to use this newly emitted device structure
pointers.
Change-Id: I8306d9efba8e5ca5c0bda41baac9c90ad8b73ece
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Currently there are two versions of spd_tools: one for LP4x and one for
DDR4. This change is the first step in unifying these into a single
tool.
This change implements a unified version of the spd_gen tool, by
combining the functionality currently in lp4x/gen_spd.go and
ddr4/gen_spd.go. The unified version takes the memory technology as an
argument, and generates SPD files for all platforms supporting that
technology.
BUG=b:191776301
TEST=Compare the SPDs generated by the old and new versions of the tool
for all supported platforms. For reference, the test script used is
here: https://review.coreboot.org/c/coreboot/+/57511
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: I7fc036996dbafbb54e075da0c3ac2ea0886a6db2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
To save the space for FW, some of the FWs are going to be defined as
LVL2 entries. To be compatible to "flattened" layout, we still drop
the LVL2 entry to level1 if there is only one level.
Change-Id: Ibe8cdd5c14225899352b02bb19aae6059d56d428
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Make neovim the default editor and create an alias for vim.
The NixOS module for neovim is currently broken. Thus, add a note to
`description.md` to switch to that later.
Change-Id: I9345a6e32f3035565e55e50579c97121b4987d83
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57393
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a Nix shell file which provides an environment for compilation of
the coreboot toolchain. The Nix shell can be used by running the
following command:
$ nix-shell --pure util/nixshell/toolchain.nix
The `--pure` parameter is optional, but it makes sure that the
environment is as minimal as possible and does not contain any unrelated
or unneeded software or configuration.
Once compiled, the coreboot toolchain can be used without loading the
shell environment.
If `--pure` is used, SSL connections won't work since the
`SSL_CERT_FILE` environment variable is not configured, which makes the
build tool unable to download the source files. Thus, let it point to
the system certificate store.
Change-Id: I341ee28c5451d2c6cb4ff22de67161d99f4ca77a
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Adds "add" command to elogtool. This command allows adding elog events
manually. It supports event type and, optionally, event data.
If the free buffer space is < 1/4 of the total space, it shrinks the
buffer, making sure that ~1/4 of the free space is available.
BUG=b:172210863
TEST=./elogtool add 0x17 0101
./elogtool add 0x18
Repeated the same tests on buffers that needed to be shrunk.
Change-Id: Ia6fdf4f951565f842d1bff52173811b52f617f66
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This function is "extracted" from cmd_clear().
This new function will be called from cmd_add(), and new command that
will be added in a future CL (see CL chain).
Additional minor fixes:
- calls usage() if no valid commands are passed.
- Slightly improves usage() output. Needed for cmd_clear()
BUG=b:172210863
TEST=elogtool clear
Change-Id: I0d8ecc893675758d7f90845282a588d367b55567
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Install both versions of UEFITool, the one with the old engine and the
new one.
It's not possible to use both packages in the same environment, since
there is a collision between the names of the binary files. To make sure
a specific package is used, a new environment needs to be spawned with
the following command:
$ nix-shell -p <package_name>
The UEFITool binaries can be executed from the shell then.
Change-Id: Ia5d679c6e7cd01c2ab819bd6c085596a926c494d
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
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>
With parser.tab.h depending on parser.tab.c it's possible for make
to initiate the creation of parser.tab.c, then try to compile it,
even though parser.tab.h is still missing.
This isn't normally an issue yet because bison creates them both at
a time but with pre-compiled files this will become a problem.
Pattern rules support (until recently as a special case that no other
type of rule could implement) multiple targets that are actually
treated as "one command creates multiple output files" so use that
to state the relationship properly.
Change-Id: I4aa7eca9d3123808e0665a15a99c04fac7384940
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Manually maintaining a list of fields just to avoid printing some
unnecessary CPP guards isn't worth the maintenance burden. Instead,
always generate these guards, even if they guard nothing.
Change-Id: I6c84180d83ac39a895e02d196acb7074eb052d7f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57459
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adds "clear" command to cbfsutil/elogtool tool.
"clear" clears the RW_ELOG region by using either:
* flashrom if no file is provided
* or using file write if an input file is provided.
The region is filled with ELOG_TYPE_EOL. And a
ELOG_TYPE_LOG_CLEAR event is inserted.
Additionally, it does a minor cleanup to command "list", like:
* use buffer_end()
* add "list" to the cmds struct
* and make elog_read() very similar to elog_write()
Usage:
$ elogtool clear
BUG=b:172210863
TEST=elogtool clear && elogtool list
elogtool clear -f invalid.raw
elogtool clear -f valid.raw
Change-Id: Ia28a6eb34c82103ab078a0841b022e2e5e430585
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
On some platforms, runtime firmware crashes write logs to the CBMEM
console. For those, since a crash reboots the system, by the time we
have a chance to run `cbmem` again the boot where the crash happened
will be the one before the "last" (current) boot. So cbmem -1 doesn't
show the interesting part, and cbmem -c potentially shows a lot that is
cumbersome to dig through. This patch introduces a new option cbmem -2
to explicitly show only the boot cycle before the last one.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6725698f4c9ae07011cbacf0928544cebb4ad6f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
The update_efs_spi_speed allows changing the SPI speed manually in a
binary that has already been built. This will allow binaries not built
for the EM100 SPI ROM emulator to be updated so that they will work.
There is a corresponding change that will check to see if the EFS value
has been modified from the original speed and will prevent coreboot from
updating the SPI speed and mode.
BUG=b:177233017
TEST=Update SPI speed in existing binary. See that SPI speed has
changed.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I905a9fd8bd93a28aab927dffecbbcf24934b9e03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56644
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though `device` entries are children of `chip` entries in the
devicetree source format, the chips in the translated C structures
are only hooked up to device nodes. Hence, any chip with all its
settings will be silently dropped by sconfig if there is no device
node below it.
Let's adapt the parser to ensure that there is at least one `device`
entry. The intermediate `chipchildren_dev` rule applies until the
first `device` entry is found, then everything continues as before
with the `chipchildren` rule.
Change-Id: I54830bc1fc7d00a0605f3fe4d36a83ef57ef3312
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51119
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Haswell has its Mini-HD device and is at card0, so we need to search
for the PCH HD Audio device instead of using card0.
Change-Id: I2bc420fdbe9731ae835f63add85db79f04201da4
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34357
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch also adds LynxPoint and WildcatPoint-LP IOBP registers,
which is used to get the USB and SATA configuration values for
autoport.
Change-Id: I1f11640fdff59a5317f19057476f7e48c2956ab9
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41473
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Add NixOS configurations for bootable live systems containing a set of
tools which might be useful for firmware development in general and for
working on coreboot.
There are two configurations provided. One for console-only and a
graphical one, which is mostly the same as the console image but it
comes with Gnome Shell as window manager and some graphical tools in
addition.
An image can be built using `build-console.sh`, respectively
`build-graphical.sh`. The resulting iso image can be found in
`result/iso/`.
The console image results in ~700MB, while the graphical one results in
~2GB.
Change-Id: Iaf49d198e99781434bd89d2a8a125a4988b77e1c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The patch is to fix "Not a usable UEFI firmware volume" issue when
creating CBFS/flash image. This issue is caused by adding FvNameGuid
in UefiPayloadEntry.fdf in EDKII. There is an ext header between header
of Fv and header of PayloadEntry in Fv with FvNameGuid. The ext header
causes the UefiPayloadEntry to be found incorrectly when parsing Fv.
Commit in EDKII: 4bac086e8e007c7143e33f87bb96238326d1d6ba
Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=3585
Signed-off-by: Dun Tan <dun.tan@intel.com>
Change-Id: Id063efb1c8e6c7a96ec2182e87b71c7e8b7b6423
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57296
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: King Sumo <kingsumos@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the override functionality looks for device match, check that
the probe list for both the devices matches exactly if probe list
exists for the base device. This ensures that if there are two devices
with same identity (e.g. I2C address or USB port #) but using
different properties (registers) controlled by different probe
statements, then the two devices are not incorrectly matched as the
same device.
The check for base device having a probe list is performed before
comparing the probe lists because a base device might not really have
any probe requirements at all. So, when overriding such a device,
there is no need to check for the probe list match.
BUG=b:187193527
TEST=Verified by adding two I2C devices in the override tree with the
same I2C address and chip but different probe statements and confirmed
that both the devices are present in generated static.c file.
Change-Id: Ib18868b336cf4ffc9aa38aee7c6f333a35d32fce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Add buffer_end() function to common.h. This function returns a
pointer to the end of the buffer (exclusive).
This is needed by elogtool util. (See the next CL in the chain).
BUG=b:172210863
Change-Id: I380eecbc89c13f5fe5ab4c31d7a4fef97690a791
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change can make the code be more flexible. And later we will use
amd_cb_config to transfer parameters.
Change-Id: Ic726aa9fc5f67803210af71d3e9cf2438b7e2a9b
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57062
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The issue is reported by Coverity. Using strcpy or strcat copying
string without checking length may cause overflow.
BUG=b:188769921
Reported-by: Coverity (CID:1438964)
Change-Id: I609d9ce405d01c57b1847a6310630ea0341e13be
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54946
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adds the ability to output MSRs dump for the specified range of CPU
cores. This makes it easier to reverse engineer server multicore
processors using the inteltool utility.
The range is set using --cpu-range <start>[-<end>] command line option:
$ sudo ./inteltool -M --cpu-range 0-7
$ sudo ./inteltool -M --cpu-range 7-15
$ sudo ./inteltool -M --cpu-range 32
$ sudo ./inteltool -M will print a register dump for all cores, just
as before.
Change-Id: I3a037cf7ac270d2b51d6e453334c358ff47b4105
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35919
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reka Norman