After removing GDB from crossgcc in commit f32eed16 (buildgcc: Remove
GDB from crossgcc), there is no target named all_without_gdb anymore
and we should always build crossgcc with target all.
But in util/docker/Makefile, we still try to build crossgcc with
target all_without_gdb as default and will cause a build failure.
Set CROSSGCC_PARAM from all_without_gdb to all to fix this issue.
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I06c6d8e36dfd4e6a00ddec8b640b608ab1ba614c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This restricts availability of non-standard functions (such as memmem)
on FreeBSD and macOS. It also isn't necessary on glibc.
Change-Id: Iaee1ce7304c89f128a35a385032fce16a2772b13
Signed-off-by: Alex James <theracermaster@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
flashmap/fmap.c includes commonlib/bsd/sysincludes.h, which already
includes the necessary header for endian(3) functions (endian.h on
Linux and sys/endian.h on FreeBSD). This also resolves a compilation
error on macOS (tested on 10.5.7), as macOS does not provide endian.h.
Change-Id: I0cb17eacd253605b75db8cf734e71ca3fe24ad6c
Signed-off-by: Alex James <theracermaster@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The intel-spi driver maps the BIOS region of the flash as an mtd device
at /dev/mtdX. Since this system is intended for development purposes,
disable its write protection.
Change-Id: Ib73d14eb4e7df6e29433b8dfbeb77dbab4a85f08
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Config options and package names might change from channel to channel.
Thus, don't let nix-build depend on the locally configured NixOS
channel, but instead let `nixpkgs` point to a specific channel to ensure
that always a compatible channel is used.
For now, let `nixpkgs` point to NixOS 21.11, which is currently the
latest stable release. This needs to be updated after a new release.
Change-Id: Ia77c34f93f0e2c3d351ae229830adfce75a56ae4
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Merge build scripts to `build.sh`. The new one takes the desired NixOS
config as an argument.
Example:
$ build.sh console.nix
Change-Id: I49360a5c57954a205c697a4ae07361779db2aa83
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60372
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
futility actually depends on flashrom. Previously it
was of the form of subprocess and now uses the libflashrom
API directly. Due to the previous subprocess decoupling it
was not obvious that the dependency existed however not
the runtime requirement is also a strict buildtime requirement.
Therefore update the Makefile accordingly.
BUG=b:203715651,b:209702505
TEST=builds
Change-Id: Id9744424f75299eb8335c1c0c2aca2808bde829d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Address Mode 0: Physical Address, bit 63~56: 0x00
Address Mode 1: Relative Address to entire BIOS image, bit 63~56: 0x40
Address Mode 2: Relative Address to PSP/BIOS directory, bit 63~56: 0x80
Address Mode 3: Relative Address to slot N, bit 63~56: 0xC0
It is the expanding mode for simple relative address mode, for which
address_mode equals 1.
Only mode 2 is added. We need to record current table base address and
calculate the offset. The ctx.current_table is zero outside the
table. When it goes into the function to integrate the table, it
should backup the old value and get current table base. Before it goes
out the function, it should restore the value.
If the table address mode is 2, the address in each entry should be
also add address mode information. If not, the address mode in entry
is meanless.
The old mode 0,1 should be back compatible.
Change-Id: I29a03f4381cd0507e2b2e3b359111e3375a73de1
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
`cbfstool locate` and the associated -T switch were removed a looong
time ago (2015 in CB:11671). However, getopt and the help text weren't
cleaned up correctly. Fix that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib098278d68df65d348528fbfd2496b5737ca6246
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The whole point of moving do_cbfs_locate() later (CB:59877) was that it
could use the file size that is actually going to be inserted into CBFS,
rather than the on-disk file size. Unfortunately, after all that work I
forgot to actually make it do that. This patch fixes that.
Since there is no more use case for do_cbfs_locate() having to figure
out the file size on its own, and that generally seems to be a bad idea
(as the original issue shows), also remove that part of it completely
and make the data_size parameter mandatory.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1af35e8e388f78aae3593c029afcfb4e510d2b8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The second generation EFS (offset 0x24[0]=0) uses "binary relative"
offsets and not "x86 physical MMIO address" like gen1.
The field additional_info in table header can tell if the absolute or
relative address is used.
Chips like Cezanne can run in both cases, so no problem
comes up so far.
The related change in psp_verstage has been uploaded.
https://review.coreboot.org/c/coreboot/+/58316
The relative mode is the mode 1 of four address modes. The absolute
mode is the mode 0. Later we will implement mode 2. Not sure if mode 3
is needed.
It needs to be simple to work with psp_verstage change to make SOC
Cezanne work quickly. This patch is defacto a subset of
https://review.coreboot.org/c/coreboot/+/59308
which implements the framework of address mode and covers mode
0,1,2. Some hardcode value like 29 can be removed in 59308.
BUG=b:188754219
Test=Majolica (Cezanne)
Change-Id: I7701c7819f03586d4ecab3d744056c8c902b630f
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
In cbfs_add_component(), the |offset| variable confusingly jumps back
and forth between host address space and flash address space in some
cases. This patch tries to clean that logic up a bit by converting it
to flash address space very early in the function, and then keeping it
that way afterwards. convert() implementations that need the host
address space value should store it in a different variable to reduce
the risk of confusion. This should also fix a tiny issue where
--gen-attribute might have previously encoded the base address as given
in CBFS -- it probably makes more sense to always have it store a
consistent format (i.e. always flash address).
Also revert the unnecessary check for --base-address in
add_topswap_bootblock() that was added in CB:59877. On closer
inspection, the function actually doesn't use the passed in *offset at
all and uses it purely as an out-parameter. So while our current
Makefile does pass --base-address when adding the bootblock, it actually
has no effect and is redundant for the topswap case.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idf4721c5b0700789ddb81c1618d740b3e7f486cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Currently, `checkpatch.pl`, imported from the Linux project, checks for
75 characters per line [2]:
> Suggest line wrapping at 75 columns so the default git commit log
> indentation of 4 plus the commit message text still fits on an 80
> column screen.
But Gerrit’s Web interface and its commit hooks use with 72 characters
per line [2]:
remote: commit 35bb56d: warning: too many message lines longer than 72 characters; manually wrap lines
remote:
remote: SUCCESS
remote:
remote: https://review.coreboot.org/c/coreboot/+/60004 [DO NOT SUBMIT] Gerrit commit msg line length test [NEW]
So, decrease the suggested length from 75 to 72 characters per line.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a076f40d8c9be95bee7bcf18436655e1140447f
[2]: https://review.coreboot.org/60004
Change-Id: Ic9c686cb1a902259b18377b76b5c999e94660fed
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
As part of the `what-jenkins-does` target, combine the code coverage
data from all unit tests (currently just coreboot and libpayload).
BUG=b:203800199
TEST=`make what-jenkins-does && ls -l coreboot-builds/coverage.info`
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Id99615ca8279f80a402d5371221b8fd36fb91d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
The placement calculation logic in cbfs_add_component() has become quite
a mess, and this patch can only fix that to a limited degree. The
interaction between all the different pathways of how the `offset`
variable can be set and at what point exactly the final placement offset
is decided can get quite convoluted. In particular, one existing problem
is that the offset for a file added with the --align flag is decided
before the convert() function is called, which may change the form (and
thereby the size) of the file again after its location was found --
resulting in a location that ends up being too small, or being unable to
find a location for a file that should fit. This used to be okay under
the assumption that forced alignment should really only be necessary for
use cases like XIP where the file is directly "used" straight from its
location on flash in some way, and those cases can never be compressed
-- however, recent AMD platforms have started using the --align flag to
meet the requirements of their SPI DMA controller and broken this
assumption.
This patch fixes that particular problem and hopefully eliminates a bit
of the convolution by moving the offset decision point in the --align
case after the convert() step. This is safe when the steps in-between
(add_topswap_bootblock() and convert() itself) do not rely on the
location having already been decided by --align before that point. For
the topswap case this is easy, because in practice we always call it
with --base-address (and as far as I can tell that's the only way it was
ever meant to work?) -- so codify that assumption in the function. For
convert() this mostly means that the implementations that do touch the
offset variable (mkstage and FSP) need to ensure they take care of the
alignment themselves. The FSP case is particularly complex so I tried to
rewrite the code in a slightly more straight-forward way and clearly
document the supported cases, which should hopefully make it easier to
see that the offset variable is handled correctly in all of them. For
mkstage the best solution seems to be to only have it touch the offset
variable in the XIP case (where we know compression must be disabled, so
we can rely on it not changing the file size later), and have the extra
space for the stage header directly taken care of by do_cbfs_locate() so
that can happen after convert().
NOTE: This is changing the behavior of `cbfstool add -t fsp` when
neither --base-address nor --xip are passed (e.g. FSP-S). Previously,
cbfstool would implicitly force an alignment of 4K. As far as I can tell
from the comments, this is unnecessary because this binary is loaded
into RAM and CBFS placement does not matter, so I assume this is an
oversight caused by accidentally reusing code that was only meant for
the XIP case.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia49a585988f7a74944a6630b77b3ebd79b3a9897
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59877
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Update configs so that they work with NixOS 21.11. Drop `iasl` package
since it was replaced with `acpica-tools`.
Change-Id: Icb9a382b83b3b3e55126bb0bb508659d11497a05
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
endian.h wasn't included (although it probably came in as an indirect
include) but in some header sets _XOPEN_SOURCE overrides _DEFAULT_SOURCE
whereas the latter is a super set of the former:
We should get the same things as with _XOPEN_SOURCE (such as memccpy for
which it has been defined) but also extra features like htole32.
Change-Id: Iaee7495b2ae64fdc719ae0879ea95fe7df286212
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59891
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Libpayload requires cbmem_id.h file to support extracting values from
CBMEM IMD entries of coreboot tables. Libpayload use BSD-3-Clause
license, and all of its files used to compile a static library have to
use it too.
Change-Id: I97c080e34ebdbcdf14fe3a3c9515b1dea8ede179
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Commit 796aeeba96 (util/cse_fpt: Add a new tool for managing Intel CSE
FPT binaries) and commit d7fb6a90e1 (util/cse_serger: Add a new tool
for stitching CSE components) add two utilities, and building cbfstool
also generates executables for them. When building cbfstool standalone,
these executables are placed in `util/cbfstool/`, and Git should never
track them.
Specify these executables' file names in .gitignore in order to prevent
unintentional inclusion of these files in commits, which is very likely
to happen when using `git add` on directories.
Change-Id: I285a4d7aeee642822eaae2eb69e5d52efb4bc8c0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59670
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of maintaining two complete Makefiles, reuse the coreboot
build system rules in the stand-alone Makefile.
Change-Id: I5d894a1f079799478bce0bd200ac735097f3806b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59669
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure that the separate Makefile doesn't break.
Change-Id: I0fbe37dc01e46022c5e6de5629eb99f6b86b0b14
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Commit f1e401c6cb (util/cbfstool/flashmap/fmap.c: fix fmaptool
endianness bugs on BE) makes use of endianness conversion macros
in cbfstool's FMAP code, which is also used by ifdtool. At least
on Linux, the <endian.h> header provides these helpers, but only
when `__USE_MISC` is defined, which is defined in the <ctypes.h>
header when `_DEFAULT_SOURCE` is defined. This was accounted for
in `Makefile.inc`, but not in `Makefile`. As a result, trying to
build ifdtool as a standalone tool (i.e. not as part of building
a coreboot image) results in build errors because the endianness
conversion macros are not defined.
Define `_DEFAULT_SOURCE` in `Makefile` to fix the build errors.
Change-Id: I8c2bbc07ddd87d885e2d6f5c7f2bd501e5c4e3b0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59663
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without manual handling, when 3rdparty/intel-sec-tools isn't around,
`make what-jenkins-does` reports only
go: go.mod file not found in current directory or any parent directory; see 'go help modules'
which isn't meaningful or actionable. Instead check that the go.mod file
exists and bail out with a better error message before trying to run
`go mod vendor`.
Change-Id: I035747746ca5fd54841bd67352044dde12a28185
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch makes all accesses to the FMAP fields explicitly little endian.
It fixes issue where build on BE host produced different binary image than
on LE.
Signed-off-by: Marek Kasiewicz <marek.kasiewicz@3mdeb.com>
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Change-Id: Ia88c0625cefa1e594ac1849271a71c3aacc8ce78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add events for Chrome OS diagnostics in eventlog tool:
* ELOG_TYPE_CROS_DIAGNOSTICS(0xb6): diagnostics-related events
* ELOG_CROS_LAUNCH_DIAGNOSTICS(0x01): sub-type for diagnostics boot
These events are not added anywhere currently. They will be added in
another separate commit.
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I1b67fdb46f64db33f581cfb5635103c9f5bbb302
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Document 319973-003 (ICH10 datasheet) and document 324645-006 (6-series
PCH datasheet) indicate that the name of this register is `GP_LVL3`,
not `GPIO_LVL3`. Correct the name.
Change-Id: I44cc41843c9f7cd0796bd198fb89447d787f155a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Add the PCI device ID for the ICH10D southbridge. While we're at it,
also fix up whitespace in inteltool.h of an adjacent definition.
Change-Id: I98d88a9ce27d3ddaafd7123ee51b2111a8bef019
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Related to https://review.coreboot.org/c/coreboot/+/58555
commit-id: 35b7e0a2d82ac
In 58555, we added the SOC ID for Stoneyridge in amdfwtool
command line. But it raised building error because it then called
"set_efs_table" without setting SPI mode. So we skipped calling that.
But in set_efs_table, it has case for Stoneyridge. The boards also
need to have this setting. So we remove the skipping and give the
proper SPI mode in mainboard Kconfig.
Change-Id: I24499ff6daf7878b12b6044496f53379116c598f
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Fix the CL:
https://review.coreboot.org/c/coreboot/+/58942
The type comboable was int but set as true.
Change-Id: Id2c43378735c089a27a5aa683b55a0f7ec3677de
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
For combo layout, this is for combo header.
For non-combo layout, this is for PSP directory.
Change-Id: Ie7b5aec6b511ad61972908d1d22a13aeb7dd73a9
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Begin comments with # instead of ## to match the Makefile.inc generated
by spd_tools.
BUG=None
TEST=None
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: If2d716a7338fd5af8216b2bcd894fc88a9df137e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
For the stoneyridge, soc_name is not set in Makefile, so set_efs_table
is not called. Keep it unchanged.
Change-Id: I0e82188ce64733420a578446e22a077ef789be92
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Need to check the FWs number limit several times. So pack the
duplicated steps into a function. And do it before access the new
entry.
Change-Id: I71117d1c817c0b6ddaea4ea47aea91672cc6d55a
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add documentation describing how to add support for a new memory
technology to spd_tools:
- Add a section to the README.
- Document the memTech interface in spd_gen.go.
BUG=b:191776301
TEST=None
Signed-off-by: Reka Norman <rekanorman@google.com>
Change-Id: Ie710c1c686ddf5288db35cf43e5f1ac9b1974305
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59005
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This error prevented the last line of the Kconfig tree from being
printed or added to the output file. This is a significant problem if
you try to use the generated file as the kconfig source, because it
changes CONFIG_HAVE_RAMSTAGE from defaulting to yes to defaulting to
NO. This causes the build to stop working.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I3ec11f1ac59533a078fd3bd4d0dbee9df825a97a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add COV=1 and the `coverage-report` target to unit test build rules
in `what-jenkins-does` so that we get code coverage data from the
coreboot and libpayload unit tests.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: I96669c47d1a48e9ab678a4b9cb1d0c8032d727f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add LP5 support to spd_tools. Currently, only Intel Alder Lake (ADL) is
supported.
The SPDs are generated based on a combination of:
- The LPDDR5 spec JESD209-5B.
- The SPD spec SPD4.1.2.M-2 (the LPDDR3/4 spec is used since JEDEC has
not released an SPD spec for LPDDR5).
- Intel recommendations in advisory #616599.
BUG=b:201234943, b:198704251
TEST=Generate the SPD and manifests for a test part, and check that the
SPD matches Intel's expectation. More details in CB:58680.
Change-Id: Ic1e68d44f7c0ad64aa9904b7e1297d24bd5db56e
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58679
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Introduce the `smbios_dev_info` devicetree keyword to specify the
instance ID and RefDes (Reference Designation) of onboard devices.
Example syntax:
device pci 1c.0 on # PCIe Port #1
device pci 00.0 on
smbios_dev_info 6
end
end
device pci 1c.1 on # PCIe Port #2
device pci 00.0 on
smbios_dev_info 42 "PCIe-PCI Time Machine"
end
end
The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using
this syntax to control the generated Type 41 entries. When this option
is enabled, Type 41 entries are only autogenerated for devices with a
defined instance ID. This avoids having to keep track of which instance
IDs have been used for every device class.
Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not
enabled will result in a build-time error, as the syntax is meaningless
in this case. This is done with preprocessor guards around the Type 41
members in `struct device` and the code which uses the guarded members.
Although the preprocessor usage isn't particularly elegant, adjusting
the devicetree syntax and/or grammar depending on a Kconfig option is
probably even worse.
Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Order functionally:
* first "all" and build-$tools
* followed by clean
* followed by the architecture targets
The order was chosen this way because the architecture targets are
the mostly likely to continue to grow.
While at it, also fix the build_nasm mention (it was build-nasm)
and add build_make.
Change-Id: Id58338a512d44111b41503d4c14c08be50d51cde
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58796
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Upstream's changes only affect a script that we don't use.
Still, this keeps us in sync with the official version.
Change-Id: I39cbbfb8dc816b4f36f92e6bd53f40c733691242
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Hsuan Ting Chen