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>
Versions of expat before 2.4.0 have been renamed to prevent their
use, due to some kind of vulnerability. without updating this
dependency it is currently not possible to build crossgcc with GDB.
Change-Id: Iec2cf560902dc556a41206d7dcd65c22cf3e1215
Signed-off-by: Mackenzie May <ky0ko@disroot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56868
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The lp4x spd_tools also support Alder Lake (ADL), so update the the
README to reflect this fact.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iedb1ea1c3558e5f179feac2c725667db5b327b2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56857
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the binary output of the new elogtool to the .gitignore, so that
running "make -C util/cbfstool" keeps the tree clean.
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I806338a4b33abbc3d55e4edef2736c19d56fa005
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Even though pkg-config might be installed, it might or will not return
true in the checks whether 'PKG' or 'PKG2' is installed.
Extend the script to look in another location for ncurses.h
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I4344ba2116c0b8618357db4248d993509cbb666e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Add a new tool that that prints elog events.
The tool, as input, accepts either a file with the RW_ELOG contents, or
if the file is not provided it reads the contents of RW_ELOG by calling
the "flashrom" tool.
The tool is based on "mosys eventlog list"[1]. For the moment it only
supports "list", but future commits will add additional functionality.
This commit also adds missing ELOG defines needed for the tool. These
defines are added with the rest of the ELOG defines, in
include/commonlib/bsd/elog.h
The tool is placed inside util/cbfstool. The rationale behind the
decision, is that this tool shares a lot in common with the other tools
located in cbfstool: vboot dependency, shared files like common.o and
valstr.o, and in spirit is similar to some of the tools located in
cbfstool/.
As an example, you call the tool like the following:
$ elogtool list -f rw_elog_dump.bin
[1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Our documentation claims that the DEFCONFIG make variable, used for
targets such as savedefconfig, defaults to 'defconfig'.
With the update to kconfig 5.13 we lost this default, so bring it back.
Fixes: 53ea1d44f0 ("util/kconfig: Uprev to Linux 5.13's kconfig")
Resolves: https://ticket.coreboot.org/issues/317
Change-Id: Idb88b69ffa855fa97df8c821601308e717575550
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56718
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When looking for C compilers, xcompile uses the "" prefix to "gcc" and
"clang" as a last-resort option. This fails in environments where such
default names are blocked to prevent "unclean" builds - such as Chrome
OS.
Allow overriding this prefix using the GENERIC_COMPILER_PREFIX variable
that is hopefully both descriptive enough to suggest what it is for and
unusual enough to not trigger by chance.
Change-Id: I16239f66730f1dbcb7482f223cea4ee5957af10c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This change adds the following memory parts to LP4x global list and
generates SPDs using gen_spd.go for ADL:
1. H54G46CYRBX267
2. H54G56CYRBX247
3. K4U6E3S4AB-MGCL
4. K4UBE3D4AB-MGCL
BUG=b:194686484 b:194765811
TEST=build.
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Change-Id: If85088f843ab11cc531a3975b5cac3e36b573970
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
It only leads to missing symbol errors.
Change-Id: Idbce93232ba2b54561abab5b2747c418d6efa92b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Initially APL was considered as IFDv2 platform irrespective being
added into ifd_2_platforms[], hence commit hash 621ed4c had migrated
APL into IFDv1 which break its FLMSTR1/FLMSTR2/FLMSTR3 Read/Write
access. This change adds APL into the list of IFDv2 platforms to fix
booting issue on the LeafHill board.
Change-Id: Ied59ddb2fe05b421266a6b119fd6eab17b8beedc
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56300
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Rick Lee <rick.lee@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ESPI & LPC keywords were added for the zork program, but it was
found that they weren't needed, so they were never used.
BUG=None
TEST=Build
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I3a78afc55477d62eac8056e2ca4bcdd3ab12ea47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56197
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was originally several commits that had to be squashed into one
because the intermediate states weren't able to build coreboot:
- one to remove everything that wasn't our own code, leaving only
regex.[ch], toada.c, description.md and Makefile.inc.
- one to copy in Linux 5.13's scripts/kconfig and adapt Makefile.inc
to make the original Makefile work again.
- adapt abuild to use olddefconfig, simplifying matters.
- apply patches in util/kconfig/patches.
- Some more adaptations to the libpayload build system.
The patches are now in util/kconfig/patches/, reverse applying them
should lead to a util/kconfig/ tree that contains exactly the Linux
version + our own 5 files.
Change-Id: Ia0e8fe4e9022b278f34ab113a433ef4d45e5c355
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
I a file in configs/* has no suffix, then the default configuration
will override the results of the build generated by the configfile
from configs/*. Fix this by adding a '_' to the buildname.
Change-Id: Ic47105fafca41f1905a6569943079623bec5405a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The second generation EFS (offset 0x24[0]=0) uses
"binary relative" offsets and not "x86 physical
MMIO address" like gen1.
Chips like Cezanne can run in both cases, so no problem
comes up so far.
BUG=b:188754219
Test=Majolica (Cezanne)
Change-Id: I3a54f8ce5004915a7fa407dcd7d59a64d88aad0d
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently ifdtool breaks the descriptor because it treats it as IFDv1.
This change adds it to the list of IFDv2 platforms.
Fixes boot for X11SSH-LN4F.
Fixes: 8c082e5fef ("util/ifdtool: Use -p platform name to detect IFDv2 platform and chipset")
Change-Id: I3f92b090e929336b5c18b442d1504ee1000f5594
Signed-off-by: Jan Tatje <jan@jnt.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56070
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Redirect stdout and stderr from grep to check for unknown timestamps,
when no timestamps are stored, which is already logged earlier.
Failed to run "/root/coreboot/util/cbmem/cbmem -t", ignoring
Getting remote dmesg
grep: /tmp/coreboot_board_status.dXmbUIBP/emulation/qemu-i440fx/4.14-876-gdb28040ee1/2021-07-02T23_14_33Z/coreboot_timestamps.txt: No such file or directory
Change-Id: Ib5400d4bd17e957b4cc1bf75bbd332d60ad226f5
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The -a flag was already implemented, it just wasn't exposed for the
add-payload command.
Setting the alignment of the payload will enable using the SPI DMA
controller to read the payload on AMD devices.
BUG=b:179699789
TEST=cbfstool foo.bin add-payload -a 64 ...
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9f4aea5f0cbeaa8e761212041099b37f4718ac39
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
There is no need to repeat "import" for each module in GoLang. Use
this keyword only once in each file for code cleanliness.
Change-Id: Ibb24fafd409b31b174946a39ca1f810d59b87e76
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55985
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The dereferced parameter is never updated so passing a copy would work
too.
Change-Id: Ie36f64f55d4fc7034780116c28aaed65aa304d5e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55792
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates the intel-sec-tools submodule pointer to include a fake
acm binary to be included for buildtesting.
Change-Id: Id4a9e177f71306b8c5538a578da229a53d19487a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55609
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Vboot's Makefile is controlled by a ${DEBUG} environment variable.
As the name is very generic, it may be set by accident without any
intention to change the build. Having it set would break reproduci-
bility at least but it also turns out that the hostlib build would
be incomplete so that linking cbfstool fails due to internal calls
to vb2api_fail() which is not built in.
Change-Id: I2a9eb9a645c70451a320c455b8f24bfed197117c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
After commit 8c082e5fe (util/ifdtool: Use -p platform name
to detect IFDv2 platform and chipset) w/o this xeon_sp/cpx would be
detected as IFDv1 and see build error.
Fixes: 8c082e5fe ("util/ifdtool: Use -p platform name to detect IFDv2 platform and chipset")
Change-Id: I444e7d35a85d9d42fc25d654e57386f38cf1ec85
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The null-termination of `filetypes` was added after the code was
written, obviously resulting in NULL dereferences. As some more
code has grown around the termination, it's hard to revert the
regression, so let's update the code that still used the array
length.
This fixes commit 7f5f9331d1 (util/cbfstool: fix buffer over-read)
which actually did fix something, but only one path while it broke
two others. We should be careful with fixes, they can always break
something else. Especially when a dumb tool triggered the patching
it seems likely that fewer people looked into related code.
Change-Id: If2ece1f5ad62952ed2e57769702e318ba5468f0c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We moved from gitweb to cgit to gitiles and some of the URL schemes
were lost during the transitions. Update to the gitiles scheme so
board-status links work again.
Change-Id: Id2a840bf89fab172e0eab21e303ac0c4666b6751
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>