SELF has the fields wired up for 64bit, but adding flat images cuts the
upper half.
Change-Id: I3b48b8face921e942fb0e01eace791ad3e1669a0
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80576
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
currently the HiFive Unmatched mainboard produces the following error:
```
util/crossgcc/xgcc/lib/gcc/riscv64-elf/13.2.0/rv64imafdc/lp64d/libgcc.a
(_clzsi2.o): in function `__clzdi2':
util/crossgcc/gcc-13.2.0/libgcc/libgcc2.c:690:(.text+0x1e): relocation
truncated to fit: R_RISCV_HI20 against symbol `__clz_tab' defined in
.rodata section in util/crossgcc/xgcc/lib/gcc/riscv64-elf/13.2.0/
rv64imafdc/lp64d/libgcc.a(_clz.o)
```
This is due to the fact that the libgcc.a library is compiled with the
medlow code model but the mainboards are compiled with the medany code
model.
Changing the code model of the GCC libraries to the medany code model
fixes the issue.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If5f07ce034686dd7fec160ea76838507c0ba7fa0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80139
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since linux commit f9ba70535dc12d9eb57d466a2ecd749e16eca866
"[PATCH] Increase number of e820 entries hard limit from 32 to 128"
made in 2005 the number of e820 entries passed from the bootloader
is 128. Use the boot protocol version to check for support of
128 entries and use them if necessary.
Tested on IBM/SBP1:
Fixes booting a Linux payload when more than 32 entries are present
in the memory table, which can easily happen on a 4 socket platform.
Change-Id: Iec0a832fff091b6c3ae7050ef63e743a30618f25
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These strings didn't match the license names exactly, so update them
to match.
Change-Id: Ib946eb15ca5fa64cbd6b657350b989b4a4c1b7b7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
This tool doesn't have a makefile, when trying to compile it manually
with the given instructions it even fails to compile after fixing the
paths in the given command, and it references the non-existing
PCI_BUS_SEGN_BITS Kconfig symbol, so just drop this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ca75db281a215bf3f194ab72a107f666dc0694e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79934
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The device IDs were taken from the 200 series datasheet (page 24).
Change-Id: I34b5cb61dd7b561778cc8506858cd436e6f04f9a
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80419
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GMP and IASL don't compile with the default compiler and linker flags:
- GMP's check for the MacOS architecture hard coded x86_64 but it also
needs to know about arm64.
- iasl does some trickery on pointer alignment to save space(?), so we
need to tell clang about it.
Change-Id: If4cca9d3e55051a6121d992e5320bee1df17af9f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80435
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just a memory leak fix in Linux 6.7.
Change-Id: I1ff302dafa01e78429a30ff18e21ffe0b45ce46e
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80263
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch switches the cbmem utility from its own IP checksum
implementation to the commonlib version (which is good because the old
one had a couple of bugs: doesn't work on odd sizes and may overflow
its carry accumulator with input larger than 64K).
Change-Id: I0bef2c85c37ddd3438b7ac6389e9daa3e4955b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80256
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for the new command-line option `-E` to
the ifdtool, which enables users (primarily factory users) to
protect GPR0.
Additionally, this patch refactors some code while adding support for
enabling GPR0 protection.
For more information on the scope of GPR0 (General Protection Range 0),
please refer to the Intel Meteor Lake-U Type 4 Client Platform SPI
Programming Guide, Document Number 768150.
BUG=b:270275115
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
> ifdtool -p mtl -E image.bin -O image.bin_lock
...
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
...
GPR0 protection is now enabled
Change-Id: I27c533ae4109c79299f4e7ff75e750d7cc64280f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
GCC_OPTIONS is only used for target specific options right now,
so rename to TARGET_GCC_OPTIONS and only use them in the
non-bootstrap build.
Adapt BINUTILS_OPTIONS for consistency, even though it doesn't
have the same problem.
Change-Id: I5e4f54b758dd7daf4e69101c19dfa1212fa64cf6
Signed-off-by: Patrick Georgi <patrick@georgi.software>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80229
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Multiple links are unused throughout the tree and make the code more
confusing as an iteration over all busses is needed to get downstream
devices. This also not done consistently e.g. the allocator does not
care about multiple links on busses. A better way of dealing multiple
links below a device is to feature dummy devices with each their
respective bus.
This drops the sconfig capability to declare the same device multiple
times which was previously used to declare multiple links.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch refactors GPR0 unlock function to add few important
logic as below
1. Perform GPR0 unlock if GPR0 is locked.
2. While unlocking dump the GPRD PCH strap details
3. Additionally, print the GPR start and end range if GPR0
protection is enabled.
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
Exp 1: Trying to unlock GPR0 protection for a locked image
> ifdtool -p mtl -g image.bin -O image.bin_unlock
File image.bin is 33554432 bytes
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Writing new image to image.bin_unlock
Exp 2: Trying to unlock GPR0 protection for a unlocked image
> ifdtool -p mtl -g image.bin_unlock -O image.bin_unlock
File image.bin_unlock is 33554432 bytes
GPR0 protection is already disabled
Change-Id: Id35ebdefe83182ad7a3e735bdd2998baa0ec3ed7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80216
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2a6a4d1eb7e0d0cd32c8690caf3eff340cdb0d8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80124
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Make sure that any new files generated get the Makefile.mk name.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3880d5911ff8de01751befdffc99ba5a961416f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80113
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Now that the files are renamed, make sure all references to Makefile.inc
are updated as well.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I09e235eecf0c32c80a41bfcbbd3580cce6555e10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie7038712de8cc646632d5e7d29550e3260bf2c62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80103
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
The rest of the Makefiles will be renamed in following commits.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idaf69c6871d0bc1ee5e2e53157b8631c55eb3db9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80063
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reformat alternate dump output to show default values before read
values, and to use brackets to visually indicate which values differ
from the defaults.
old output:
Register dump:
idx val def
0x07: 0x0b (0x00)
0x10: 0xff (0xff)
0x11: 0xff (0xff)
...
new output:
Register dump:
idx def val
0x07: 0x00 [0x0b]
0x10: 0xff 0xff
0x11: 0xff 0xff
...
TEST=build/dump registers from Erying SRMJ4 w/Nuvoton NCT6796D.
Change-Id: Idef2cc136151328b114620eb297ab8fd62b71bcd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80004
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Registers and default values taken from public datasheet:
https://www.nuvoton.com/resource-files/NCT6796D_Datasheet_V0_6.pdf
TEST=build/dump SIO registers on Erying SRMJ4 mainboard
Change-Id: I0ff940a17b0c38a5ca66e90dd4e075a2b04dcfc1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80003
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently autoport fills in USB current '0' if the detected setting
isn't one of the known settings. This works as 0 is a valid setting
from C point of view, but it's not supported on desktop PCs and on
mobile platform results in the lowest possible USB PHY gain. Thus
this might cause instabilities as the original firmware had stronger
USB drive currents and gain settings.
Add more known USB current fields to the map and generate a FIXME
as comment when the detected current isn't one of the known entries
instead of defaulting to 0.
Change-Id: I48f4d636ce3401ba188f5519b5ff45fccf13f080
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78828
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: Iaae116a1ab2da3b2ea2a5ebcd0c300b238582834
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
As per Intel Meteor Lake SPI programming doc, the BIOS region should
have a read access enabled for device expansion 2 region
(aka region 9).
This patch ensures that BIOS region is able to read the device
expansion 2 region for Intel Meteor Lake platform as known as
SPI padding region.
BUG=b:274356894
BRANCH=firmware-rex-15709.B
TEST=Able to flash screebo AP FW image using flashrom on DUT.
Without this patch:
> flashrom -p internal -r /tmp/bios.rom
flashrom 1.4.0-devel on Linux 6.1.67-09255-ge8ae3115f8b0 (x86_64)
...
...
Found Winbond flash chip "W25Q256JW_DTR" (32768 kB, Programmer-specific)
on internal.
Reading flash... Transaction error between offset 0x0072f000 and
0x0072f03f (= 0x0072f000 + 63)!
read_flash: failed to read (0x72f000..0x7fffff).
Read operation failed!
FAILED.
FAILED
With this patch:
> flashrom -p internal -r /tmp/bios.rom
flashrom 1.4.0-devel on Linux 6.1.68-09294-g001fdda5287d (x86_64)
...
...
Found Winbond flash chip "W25Q256JW_DTR" (32768 kB, Programmer-specific)
on internal.
Reading flash... done.
SUCCESS
Change-Id: I18c44aa9a0f890f01a889247da118b69a58936e8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Eric Lai <ericllai@google.com>
A following error occurred when I commit, it seems that the extra `\`
after `\.md$` is unnecessary.
File Binary file src/mainboard/google/guybrush/data.apcb matches has
lines ending with whitespace.
File Binary file src/mainboard/google/skyrim/data.apcb matches has
lines ending with whitespace.
File Binary file src/mainboard/google/zork/data.apcb matches has
lines ending with whitespace.
test failed
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I315a37ccc3c6ebb67f7a250402549761c699dd1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79782
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
On ChromeOS devices with updateable CSE firmware, the GPR0 (Global
Protected Range) register is used to ensure the CSE RO is write
protected even when the FLMSTR-based protection is temporarily disabled
by coreboot to allow updating the CSE RW. For more details see
Documentation/soc/intel/cse_fw_update/cse_fw_update.md
Therefore to allow modifying the CSE firmware from the CPU, the
descriptor must have both the FLMSTR-based protection disabled (which
can be done using ifdtool --unlock), and GPR0 disabled.
Add an ifdtool option for disabling GPR0. For now I've added support for
all platforms for which I have the SPI programming guide. Support for
more platforms can be added in the future if needed.
BUG=b:270275115
TEST=Run `ifdtool -p adl -g image.bin -O image-unlocked.bin` on a locked
craask image, check the GPR0 field is set to 0.
Change-Id: Iee13ce0b702b3c7a443501cb4fc282580869d03a
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79788
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The package 'bluezFull' got superseded by 'bluez'. So just remove the
related line since 'bluez' is the default.
Change-Id: Ibf72c37205017b27012064b311a9510136351c0f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marvin Evers <marvin.n.evers@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Following commands were used to test if everything builds:
* make crossgcc
* make clang
* make what-jenkins-does
Change-Id: I8d04c570f91215f534f173db2ae559b64b58012f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Use same indent levels for switch/case in order to comply with the
linter.
Change-Id: I2dd0c2ccc4f4ae7af7dd815723adf757244d2005
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Eric Lai <ericllai@google.com>
.apcb files are binary configuration data and not human readable;
exclude them from license, newline, and whitespace checks.
Change-Id: Idc1ddd5067cb97ef8b5758a0b8bf040d1e421871
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
To quote its repo[0]: Wuffs is a memory-safe programming language (and
a standard library written in that language) for Wrangling Untrusted
File Formats Safely. Wrangling includes parsing, decoding and encoding.
It compiles its library, written in its own language, to a C/C++ source
file that can then be used independently without needing support for
the language. That library is now imported to src/vendorcode/wuffs/.
This change modifies our linters to ignore that directory because
it's supposed to contain the wuffs compiler's result verbatim.
Nigel Tao provided an initial wrapper around wuffs' jpeg decoder
that implements our JPEG API. I further changed it a bit regarding
data placement, dropped stuff from our API that wasn't ever used,
or isn't used anymore, and generally made it fit coreboot a bit
better. Features are Nigel's, bugs are mine.
This commit also adapts our jpeg fuzz test to work with the modified
API. After limiting it to deal only with approximately screen sized
inputs, it fuzzed for 25 hours CPU time without a single hang or
crash. This is a notable improvement over running the test with our
old decoder which crashes within a minute.
Finally, I tried the new parser with a pretty-much-random JPEG file
I got from the internet, and it just showed it (once the resolution
matched), which is also a notable improvement over the old decoder
which is very particular about the subset of JPEG it supports.
In terms of code size, a QEmu build's ramstage increases
from 128060 bytes decompressed (64121 bytes after LZMA)
to 172304 bytes decompressed (82734 bytes after LZMA).
[0] https://github.com/google/wuffs
Change-Id: If8fa7da69da1ad412f27c2c5e882393c7739bc82
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Based-on-work-by: Nigel Tao <nigeltao@golang.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78271
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using the --skip_set and --skip_unset arguments, the config line
looked like a statement that the build was being skipped instead of
abuild just printing the configuration.
This updates those config statements to better show that it's the
config and not stating that this particular build is being skipped.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6cc59f9b33dcda51aeb3640d449037a0aa054e36
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76936
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Following commands were used to test if everything builds:
* make crossgcc
* make clang
* make what-jenkins-does
Change-Id: Iab15fe908aa6ca81724ed7557caf70c38817ad25
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Following commands were used to test if everything builds:
* make crossgcc
* make clang
* make what-jenkins-does
Change-Id: I60e00932332801c0f62d88b7860afb330d9469e4
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Rename Dockerfile to Dockerfile.base since additional Dockerfiles basing
on this one will be added later.
Change-Id: I70f2c89f739068749e1017524b6f8ef1b03d6456
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79344
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zebreus <lennarteichhorn@googlemail.com>
Following commands were used to test if everything builds:
* make crossgcc
* make clang
* make what-jenkins-does
Change-Id: I757e6dbac557bcb640777b819529a978bf54ed93
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Integration for additional container images might be added to the
Makefile at some later point. However, in order to build and test new
images just add a simple script which fulfills that requirement until
then.
Change-Id: Ibd0a6d59f395e074c784452849650d7f03b4f1d8
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Rename Dockerfile to Dockerfile.base since additional Dockerfiles basing
on this one will be added later.
Change-Id: I611feca234ae7600f9c17ae397f9f3903879c057
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Inteltool is GPLv2 licensed so all files that link to it should be GPLv2
by default. In addition, the contents of several of these headers were
originally moved directly from gpio_groups.c, which is explicitly marked
as GPL-2.0-only.
Change-Id: Ie897cb238c0c9e89fe677c999cbf1803f5f4609a
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Felix Singer