PAYLOAD_INFO is a very old feature that can add a key/value information
section to a payload file. It seems to have only ever been generated by
coreinfo and never really read by anything.
Since CB:1721 in 2012, the feature has been inadvertently broken in
practice since the `.note.pinfo` sections that contain the information
get discarded from the payload before cbfstool gets to see them. Since
CB:28647 in 2018, support for the section in the SELF loader was
(inadvertently?) dropped, so if someone actually fed cbfstool a payload
ELF that did have a `.note.pinfo` section, modern coreboot would refuse
to boot the payload entirely (which is probably not a good state to
leave things in).
This patch removes the code to generate PAYLOAD_INFO entries entirely,
but leaves the support to parse and extract those sections from old
payloads in place in cbfstool.
Change-Id: I40d8e9b76a171ebcdaa2eae02d54a1ca5e592c85
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If the host directory of a bind mount does not exist, Docker will create
it. However, the newly created directory will be owned by root due to
the Docker service running within a root context. The docker command in
the recipe for docker-build-docs binds Documentation/_build to /data-out
within the container, so if it doesn't already exist, the documentation
builder will be unable to copy the HTML output into /data-out since it
runs with the same UID and GID as the host user.
By creating, if necessary, the _build directory before the `docker run`
command, there should always be an existing directory owned by the host
user for docker to bind /data-out to (ignoring the case of an existing
_build directory the current user does not have permission to write to),
avoiding the issue where it cannot write the output.
TEST: make -C util/docker docker-build-docs completes without issues
with and without an existing Documentation/_build directory
Change-Id: I6be9bc1fdca48f4d924f5c07cc261189ab6862fd
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81127
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Input file is parsed for FMAP and SMMSTORE region which is used if
found. Otherwise, the whole file is assumed to be the region. Passing
an image with FMAP that lacks SMMSTORER is an error.
Change-Id: Ieab555d7bbcfa4dadf6a5070d1297acd737440fb
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Cleanup the messy code. The code left in main is all about filling
tables.
To help to do this,
1. Some local variables are put into global struct.
2. Add some functions. Set some functions to global.
TEST=Identical test on all AMD platforms
Change-Id: Ia25c3fd5de7ae48054359f0f6551d91d7a4f6828
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The space defined by size of the L1 table can not overlap with ISH
header. For other cases, the size defines the directory and its
content.
The PSP spec does not say it quite clearly. This change is partly
based on guess and can make extraction tool work so far.
Change-Id: Id4fbc6d57d7ea070a9478649a96af92be9441289
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This changes the virt target so that it can be run with the -bios option
and a pflash backend for the flash. QEMU can now be run as follows:
qemu -M virt -m 1G -nographic -bios build/coreboot.rom \
-drive if=pflash,file=./build/coreboot.rom,format=raw
coreboot will start in DRAM, but still have a flash to put CBFS onto and
to load subsequent stages and payload from.
Tested bootflow:
coreboot -> OpenSBI -> Linux -> u-root
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I009d97fa3e13068b91c604e987e50a65e525407d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Philipp Hug <philipp@hug.cx>
When updating the Makefiles, to keep from having to update two files at
the same time, import Makefile.mk into the external Makefile. This
allows the bulk of the settings to be in a single location.
While I'm here, I adjusted the print statements to match the rest of
coreboot.
Change-Id: Id5b869f49b34b22e6a02fc086e7b42975141a87e
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
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>
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>
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>
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>
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>
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>
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>
