Based on DMTF SMBIOS Specification 3.5.0
Signed-off-by: Erik van den Bogaert <ebogaert@eltan.com>
Change-Id: I710124ca88dac9edb68aab98cf5950aa16c695d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67926
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on DMTF SMBIOS Specification 3.1.0.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ia2db29f8bc4cfbc6648bb2cabad074d9ea583ca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64048
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
use is_enabled_cpu() on cycles over device list to check
whether the current device is enabled cpu.
TEST: compile test and qemu run successfully with coreinfo
payload
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Fix the warning below when building GA-945GCM-S2L with 64-bit:
src/arch/x86/idt.S:216: Warning: no instruction mnemonic suffix given and no register operands; using default for `iret'
Change-Id: Ibbc106714e25293951a71d84fea0a660f41f9c02
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61336
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
gcc12+ will require riscv architecture selection to come not only with
featurei suffixd charactersa, it also comes with feature_ful suffix_ed
words_mith. Much creative, very appreciate.
To accommodate for this madness, enable the already existing (but off by
default) support for that in our gcc11 build, support using by detecting
the compiler's behavior in xcompile and pass that knowledge along to our
build system.
Then cross our fingers and hope for the best!
Change-Id: I5dfeed766626e78d4f8378d9d857b7a4d61510fd
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
That's 3 years of development, including adapting to new, shiny,
Cascade of Attention-Deficit Teenagers[0] induced incompatible
assembler syntaxes.
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
[0] https://web.archive.org/web/20220824045741/https://www.jwz.org/doc/cadt.html
Change-Id: I8606700149ca74e93b85d78546a29df2916d39b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The header file `rules.h` is automatically included in the build by the
top level makefile using the command:
`-include src/soc/intel/common/block/scs/early_mmc.c`.
Similar to `config.h` and 'kconfig.h`, this file does not need to be
included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I23a1876b4b671d8565cf9b391d3babf800c074db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67348
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clear the SMBIOS region before writing SMBIOS tables.
On librem_mini and librem_mini_v2, CBMEM allocations are offset by 4K
for reboots relative to the cold boot. This means the unused SMBIOS
region could contain the first 4K of the ACPI tables from the last boot
(including the signature), which prevents Linux from booting.
The CBMEM 4K offset appears to be due to FSP allocating memory
differently between cold boot and reboot, this appears to be normal and
causes the CBMEM base address to change.
It is not clear why Linux examines an ACPI signature found in this
region, but boot logs over serial confirm that it sees the corrupt
table. The table is supposed to be found just below 1M, and kernel
source appears to look in this region, but it is definitely finding the
corrupt table in CBMEM.
Normal cold boot:
[ 0.008615] ACPI: RSDP 0x00000000000F6190 000024 (v02 COREv4)
[ 0.008619] ACPI: XSDT 0x0000000099B480E0 00005C (v01 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008624] ACPI: FACP 0x0000000099B4A2A0 000114 (v06 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008634] ACPI: DSDT 0x0000000099B48280 00201F (v02 COREv4 COREBOOT 20110725 INTL 20220331)
...
Reboot with corrupt table:
[ 0.008820] ACPI: RSDP 0x00000000000F6190 000024 (v02 COREv4)
[ 0.008823] ACPI: XSDT 0x0000000099B480E0 00005C (v01 COREv4 COREBOOT 00000000 CORE 20220331)
[ 0.008828] ACPI: ???G 0x0000000099B4A2A0 20002001 (v00 ?G?$ 47020100 ?, 47020100)
[ 0.008831] ACPI: �y 0x0000000099B4A3C0 54523882 (v67 ?_HID? A�? 65520D4E al T 20656D69)
...
There are no specific errors but it returns to the firmware soon after,
presumably due to a fault. This appears to be so early in the boot
that panic=0 on the kernel command line has no effect.
Test: build/boot Librem Mini, Librem Mini v2 and reboot.
Change-Id: Ia20d0b30160e89e8d96add34d7e0e881f070ec61
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66377
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
fix the following checkpatch errors:
WARNING:BRACES: braces {} are not necessary for any arm of this statement
354: FILE: src/arch/x86/smbios.c:354:
+ if (CONFIG_ROM_SIZE >= 1 * GiB) {
[...]
+ } else {
[...]
WARNING:BRACES: braces {} are not necessary for single statement blocks
561: FILE: src/arch/x86/smbios.c:561:
+ if (leaf_b_threads == 0) {
+ leaf_b_threads = 1;
+ }
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: I14c29e4358cad4cd5ef169ebab7079db2129d8fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This makes inspection of linker scripts in the build dir a little
easier.
Change-Id: I509faa4cee2c9f066f4e20f6038349e1165a619a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Prepare platforms for linking romstage code in the bootblock.
Change-Id: Ic20799b4d6e3f62cd05791a2bd275000a12cc83c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This moves the die() statement to a common place.
Change-Id: I24c9f00bfee169b4ca57b469c089188ec62ddada
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since there are many identifiers whose name contain "__unused" in
headers of musl libc, introducing a macro which expands "__unused" to
the source of a util may have disastrous effect during its compiling
under a musl-based platform.
However, it is hard to detect musl at build time as musl is notorious
for having explicitly been refusing to add a macro like "__MUSL__" to
announce its own presence.
Using __always_unused and __maybe_unused for everything may be a good
idea. This is how it works in the Linux kernel, so that would at least
make us match some other standard rather than doing our own thing
(especially since the other compiler.h shorthand macros are also
inspired by Linux).
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I547ae3371d7568f5aed732ceefe0130a339716a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
It might be possible to have this used for more than x86, but that
will be for a later commit.
Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch contains several minor cleanups related to compiler.h:
- Replace __always_unused() (which is a Linux-specific concept that
doesn't make sense without also having __maybe_unused(), and had zero
uses in the codebase) with __unused() which moves here from helpers.h
- Add __underscores__ to the names of all attributes in the compiler
attribute shorthand macros. This is necessary to make them work in
files where the same name was already used for an identifier (e.g.
cbfstool/cbfs.h's `unused` array of file types).
- Remove libpayload's own copy of compiler.h and make it directly pull
in the commonlib/bsd copy.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9644da594bb69133843c6b7f12ce50b2e45fd24b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
There are too many "FIT" in firmware land. In order to reduce possible
confusion of CBFS_TYPE_FIT with the Intel Firmware Interface Table, this
patch renames it to CBFS_TYPE_FIT_PAYLOAD (including the cbfstool
argument, so calling scripts will now need to replace `-t fit` with `-t
fit_payload`).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I826cefce54ade06c6612c8a7bb53e02092e7b11a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, the log message contains an unwanted trailing space, so
remove it.
[ERROR] Null dereference at eip: 0x3ffad01a
Change-Id: I64509ca4bad94c7db4279cc4c1e6fee2bba2e035
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This adds 2 flags:
* invisible opt-in flag for platforms on which clang seems to work
* visible opt-in flag to allow experimenting
Clang seems to work rather well on x86_32 so it makes sense to start
adding that to Jenkins buildtesting, which this allows.
This allows abuild to differentiate between targets that are known to
build with clang. This makes buildtesting just those targets easier.
Change-Id: I46f1bad59bda94f60f4a141237ede11f6eb93cc2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Systems have a lot more cores now and 4KiB is not cutting it. E.g.
for a system with 255 cores more than 16KiB is needed.
We could also make this a Kconfig parameter but it's probably not
worth having such micro optimizations to save a few KiB.
Change-Id: Idd47e55d8d679cc70eae996ee1af3ad7eaa1d0cc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that all AGESA codebases have been fixed to not use the .data
section, the warning workaround can be disabled.
Change-Id: I675d169a5d2f16e1e9ae05f95e045e9ef3d12208
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
With CBFS verification, cbfstool (CB:41121) needs bootblock to be
present in coreboot.pre in order to locate the metadata hash stored in
it. Therefore we have to ensure that bootblock is added to CBFS before
other CBFS files are added.
To solve the problem, create the 'add_bootblock' function, and call it
in the coreboot.pre recipe. Because bootblock.bin is now a prerequisite
of coreboot.pre, it will get built even if CONFIG_BOOTBLOCK_IN_CBFS=n.
BUG=b:233263447
TEST=emerge-guybrush coreboot
TEST=emerge-corsola coreboot chromeos-bootimage
TEST=cbfstool image-kingler.bin print -v
TEST=Kingler booted successfully
BRANCH=none
Change-Id: I385deb8231e44310ee139c3f69f449e75b92b2be
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
All targets now use cbmem for the BERT region, so the implementation can
be common.
This also drops the obsolete comment about the need to have bert in a
reserved region (cbmem gets fixed to be in a reserved region).
Change-Id: I6f33d9e05a02492a1c91fb7af94aadaa9acd2931
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
AGESA has a lot of code in the .data section (initialized data). However
there is no such section in CAR stages as the code runs in XIP mode and
CAR is too small to contain the data section. When the linker can not
match code to a section it will just append it, which is why AGESA
worked at all.
Follow-up patches will attempt to fix AGESA and set Kconfig parameter to
'n'. After all AGESA sources have been fixed, this can be removed.
Change-Id: I311ee17e3c0bd283692194fcee63af4449583d74
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Now that the bootblock isn't added to cbfs anymore, on some targets it's
only conditionally build. One example would be Intel APL where it only
gets build when stitched into an IFWI. This is always done when
compiling for real targets but not by the CI builder. This adds a dummy
target to make sure the bootblock always gets buildtested.
Change-Id: I60601e01a2c370b5c21493b71d51f495bb42f41d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
device.c should not hold arch specific code.
Change-Id: I9dfdb905a83916c0e9d298e1c38da89f6bc5e038
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The MP_IRQ flags can be used in the MP table and the ACPI MADT table.
Move them into acpi.h to avoid pulling in the full mpspec.h which is
only available on x86.
BUG=b:218874489, b:160595155
TEST=Build
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4f1091b7629a6446fa399720b0270556a926401a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63845
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The postcar frame can now be a local variable to that function.
Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some functions are only called locally.
Change-Id: I96a4e40a225536f62abb2a15c55d333b8604e8cc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61963
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Setting up postcar MTRRs is done when invd is already called so there
is no reason to do this in assembly anymore.
This also drops the custom code for Quark to set up MTRRs.
TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set
in postcar & ramstage.
Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If a payload did any NULL dereferencing it would be broken and jump
back to coreboot code. This fixes the SeaBIOS, FILO and possibly other
payloads too.
Fixes: 3f01cd1453 ("arch/x86: Add support for catching null
dereferences through debug regs")
TESTED on qemu/i440fx.
Change-Id: I80f69b71f4d0fab3126e4b9f8c8dc7737b372174
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64345
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Stefan Ott <coreboot@desire.ch>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for catching null dereferences and execution
through x86's debug registers. This is particularly useful when running
32-bit coreboot as paging is not enabled to catch these through page
faults. This commit adds three new configs to support this feature:
DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and
DEBUG_NULL_DEREF_HALT.
BUG=b:223902046
TEST=Ran on nipperkin device, verifying that HW breakpoints work as
expected.
Change-Id: I113590689046a13c2a552741bbfe7668a834354a
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some targets don't need this as the bootblock is loaded differently.
Change-Id: Ia42448f7e9dd0635c72857fbc1fab54508932721
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some platforms don't need a top aligned bootblock in cbfs like Intel
APL or modern AMD platforms as the bootblock is loaded differently.
So they don't need the top aligned cbfs bootblock.
To not clutter the main make file move out adding the bootblock.
Change-Id: I4de9d7fedf1ae5a37a3310dd42eb07b44c030930
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
