| Age | Commit message (Collapse) | Author |
|---|
|
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: 3f01cd14533f ("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>
|
|
The makefiles don't like cbfs file names with spaces in them so update
the file name with '_' instead of spaces. To keep the master header at
the top of cbfs, add a placeholder.
This removes the need to handle the cbfs master header in cbfstool.
This functionality will be dropped in a later CL.
On x86 reserve some space in the linker script to add the pointer.
On non-x86 generate a pointer inside a C struct file.
As a bonus this would actually fix the master header pointer mechanism
on Intel/APL as only the bootblock inside IFWI gets memory mapped.
TESTED on thinkpad X201: SeaBIOS correctly finds the cbfs master
header.
Change-Id: I3ba01be7da1f09a8cac287751497c18cda97d293
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Clang complains about this.
Change-Id: I421d6c5daa373d1537e4ac2243438e7f1f6208d1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63067
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move ASL POST code declarations into a common file to avoid redundancy.
Also, provide a dummy implementation when `POST_IO` is not enabled, as
the value of `CONFIG_POST_IO_PORT` can't be used.
Change-Id: I891bd8754f10f16d618e76e1ab88c26164776a50
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
To pave the way for future refactoring commits, drop POST code elements
from the debug.asl file. Only msi/ms7721 includes debug.asl and it does
not use any of it anyway.
Change-Id: Icd73e5c1f700fd7e735bed1668f02da8f9a3adf3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
With the purpose of linking ramstage inside the bootblock we likely
want to skip some ramstage CBMEM hooks and keep those only for
recovering data from earlier stages.
Change-Id: I317173d468073906d76228d1c8cc7bc28aae9e75
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
<arch/cpu.h> is chain included through <cpu/cpu.h>.
Change-Id: I54a837394f67ac2a759907c7212ab947d07338dc
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
|
|
The printed address ranges in the tree (resource allocator and even
some MTRR code) usually shows the range inclusive (meaning from start
address to the real end address of the range). Though there is still
some code in the MTRR context which prints the ranges with an exclusive
end. This patch aligns the printing of ranges in the MTRR code to be
consistent among the tree so that the shown end addresses are now
inclusive.
Change-Id: I0ca292f9cf272564cb5ef1c4ea38f5c483605c94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
Add a stack in .bss for C execution. This will make it easier to move
the setup of MTRRs in C code.
Change-Id: I67cbc988051036b1a0519cec9ed614acede31fd7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
On x86 ramstage is always relocated at runtime in cbmem so there is no
need to have this configurable in Kconfig.
Change-Id: I01b2335d0b82bea8f885ee5ca9814351bbf2aa3c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63215
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is passing through a cb_err from cbfs_prog_stage_load(), so it
should be declared to return that as well.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5510d05953fe8c0e2cb511f01f862b66ced154ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62656
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
These helpers are not architecture dependent and it might be used for
different platform.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: Ic13a94d91affb7cf65a2f22f08ea39ed671bc8e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Both the HPET_BASE_ADDRESS define from arch/x86/include/arch/hpet.h and
the HPET_ADDRESS Kconfig option define the base address of the HPET MMIO
region which is 0xfed00000 on all chipsets and SoCs in the coreboot
tree. Since these two different constants are used in different places
that however might end up used in the same coreboot build, drop the
Kconfig option and use the definition from arch/x86 instead. Since it's
no longer needed to check for a mismatch of those two constants, the
corresponding checks are dropped too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia797bb8ac150ae75807cb3bd1f9db5b25dfca35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62307
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
All x86 chipsets and SoCs have the HPET MMIO base address at 0xfed00000,
so define this once in arch/x86 and include this wherever needed. The
old AMD AGESA code in vendorcode that has its own definition is left
unchanged, but sb/amd/cimx/sb800/cfg.c is changed to use the new common
definition.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifc624051cc6c0f125fa154e826cfbeaf41b4de83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Some Intel southbridges have HPET_MIN_TICKS in their Kconfig files, but
the CONFIG_HPET_MIN_TICKS symbol is used in the common acpi code in
acpi/acpi.c, so define this option in arch/x86/Kconfig to have it
defined in all cases where the function that ends up using this
information gets called. Since we now have the type information for this
Kconfig option in a central place, it can be dropped from the Kconfig
file of the Intel southbridges that change the default value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe012069dd4b51c15a8fbc6459186ad2ea405a03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62298
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit b433d26ef11b78dda353723ff7c8797d06f76f21 (arch/x86: Define
HPET_ADDRESS_OVERRIDE) added this Kconfig option and referenced the
via/cx700 chipset which has been dropped before the 4.9 release. No SoC
in the current tree selects HPET_ADDRESS_OVERRIDE and all SoCs have
their HPET mapped at 0xfed00000, so drop this unused and no longer
needed Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4021ed6f84473c7a9223323fc8aa5d3f935d8084
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62276
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit 0e688b113d7fd98dfdb69cd0a407c8efcd968456 (arch/x86/id.S: Fix
building with clang) broke building with GCC 8.3 so this approach
should work for both GCC 8.3 and clang. The clang error is:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Change-Id: Ide3d313800641d4d9b5f79127f84d9fdb4ec2b96
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
This reverts commit 0e688b113d7fd98dfdb69cd0a407c8efcd968456.
Reason for revert: Breaks building with GCC 8.3 which is currently
needed to build bootable coreboot images for Ironlake boards:
src/arch/x86/id.S: Assembler messages:
src/arch/x86/id.S:14: Error: value of 4294967344 too large for field of 4 bytes at 48
src/arch/x86/id.S:15: Error: value of 4294967327 too large for field of 4 bytes at 52
src/arch/x86/id.S:16: Error: value of 4294967318 too large for field of 4 bytes at 56
Change-Id: I9e13b15c062bc6598717382b1fedfa120c6d7209
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
The following error message is now gone:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Tested with BUILD_TIMELESS=1 on x86_32 with gcc. The binary stays the
same.
Change-Id: I930e7b96c4428bcb95ff1903e6a3e7679171ffee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Replace `LEqual(a, b)` with `a == b`.
Change-Id: Iabfaaee22011a75cc981607d366d61660838ab21
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
It's available in %r3 in bootblock and needs to be passed to payload in
%r27. We use one of two hypervisor's special registers as a buffer,
which aren't used for anything by the code.
Change-Id: I0911f4b534c6f8cacfa057a5bad7576fec711637
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
|
|
Change-Id: I309be370d66a808b355241fcee880883631f38ce
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
"hb-mode" is a -machine flag for QEMU. "hb" stands for Hostboot, which
is OpenPower firmware created by IBM.
QEMU for PPC64 can run initial program in two different modes:
* hb-mode=off with load address 0x00000000
* hb-mode=on with load address 0x08000000
Real hardware always loads firmware at 0x08000000 and coreboot shouldn't
require a special build to be run on QEMU.
Memory layout is updated to reflect change of load address.
Change-Id: I1bdc97a095bd46fccc862985b3bd24f4fa5bc054
Signed-off-by: Yaroslav Kurlaev <yaroslav.kurlaev@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Change-Id: I9895fc0dcc0ab72151f3b2bde409c8556525433d
Signed-off-by: Yaroslav Kurlaev <yaroslav.kurlaev@3mdeb.com>
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57080
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
BSS is loaded as part of the bootblock, it is zeroed in the file so it
doesn't have to be cleared explicitly by the code.
Code for clearing is left as a comment along with a warning about alignment
requirements.
Vector operations are sometimes generated for code such as
'uint8_t x[32] = {0}', this results in an exception when vector registers
(VR) are not enabled. VSR (vector-scalar register) operations are also
enabled, there is no reason not to.
Change-Id: I878ef61619eb4a191805c8911d001312a0d717a0
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Change-Id: I4a244df01f6d15cbefb3b01079f6eec943136983
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: Ib555ce51294c94b22d9a7c0db84d38d7928f7015
Signed-off-by: Igor Bagnucki <igor.bagnucki@3mdeb.com>
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Change-Id: I58419450dbe34741b4f5b4920f435fdb91e9df22
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Found using:
diff <(git grep -l '<cbfs.h>' -- src/) <(git grep -l 'cbfs_allocator_t\|cbfs_load\|cbfs_ro_load\|cbfs_type_load\|cbfs_ro_type_load\|cbfs_unverified_area_load\|cbfs_map\|cbfs_ro_map\|cbfs_type_map\|cbfs_ro_type_map\|cbfs_unverified_area_map\|cbfs_alloc\|cbfs_ro_alloc\|cbfs_type_alloc\|cbfs_ro_type_alloc\|cbfs_unverified_area_alloc\|cbfs_cbmem_alloc\|cbfs_ro_cbmem_alloc\|cbfs_type_cbmem_alloc\|cbfs_ro_type_cbmem_alloc\|cbfs_unverified_area_cbmem_alloc\|cbfs_preload\|cbfs_unmap\|cbfs_prog_stage_load\|cbfs_get_size\|cbfs_ro_get_size\|cbfs_get_type\|cbfs_ro_get_type\|cbfs_type\|cbfs_file_exists\|cbfs_ro_file_exists\|mem_pool\|cbfs_cache\|cbfs_boot_device\|cbfs_boot_device_find_mcache\|cbfs_boot_device\|cbfs_get_boot_device\|cbfs_init_boot_device\|cbfs_boot_lookup\|cbfs_alloc\|cbfs_unverified_area_alloc\|cbfs_default_allocator_arg\|cbfs_default_allocator\|cbfs_cbmem_allocator\|cbfs_alloc\|cbfs_ro_alloc\|cbfs_type_alloc\|cbfs_ro_type_alloc\|cbfs_unverified_area_alloc\|cbfs_map\|cbfs_ro_map\|cbfs_type_map\|cbfs_ro_type_map\|cbfs_unverified_area_map\|cbfs_load\|cbfs_type_load\|cbfs_ro_load\|cbfs_ro_type_load\|cbfs_unverified_area_load\|cbfs_cbmem_alloc\|cbfs_ro_cbmem_alloc\|cbfs_type_cbmem_alloc\|cbfs_ro_type_cbmem_alloc\|cbfs_unverified_area_cbmem_alloc\|cbfs_get_size\|cbfs_ro_get_size\|cbfs_get_type\|cbfs_ro_get_type\|cbfs_file_exists\|cbfs_ro_file_exists\|cbfs_mdata\|cbfs_find_attr\|cbfs_file_hash' -- src/)|grep "<"
Change-Id: Ib4dca6da1eb66bbba5b6e94fd623f4fcfc2f0741
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Each time the spinlock is acquired a byte is decreased and then the
sign of the byte is checked. If there are more than 128 cores the sign
check will overflow. An easy fix is to increase the word size of the
spinlock acquiring and releasing.
TEST: See that serialized SMM relocation is still serialized on
systems with >128 cores.
Change-Id: I76afaa60669335090743d99381280e74aa9fb5b1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60539
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<types.h> already provides <commonlib/bsd/cb_err.h>, <limits.h>,
<stdbool.h>, <stdint.h> and <stddef.h> headers.
Change-Id: I700b3f0e864ecce3f8b3b66f3bf6c8f1040acee1
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60437
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Replace `Increment(a)` with `a++`.
Change-Id: I45ce13509f3e93d7d8cd69689604f24b926bcfbc
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Replace `Index (FOO, 0)` with `FOO[0]`.
Change-Id: Ief0f855a449d67542d6b1b56a2b76919c4cb8e2c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60562
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Replace `Add (a, b, c)` with `c = a + b`.
Change-Id: I10a94406aa7e66eed4fec22f56b7a8802252e781
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
According to util/kbc1126/README.md, for these ECs to work, the
address and size of their two firmware should be written to $s-0x100`
(`$s` means the image size, done with kbc1126_ec_insert), which means
that every existing section (especially those used to store code)
should not overlap this address, otherwise the bootblock will get
damaged when inserting firmwares of the EC.
In this commit, ecfw_ptr is a structure initialized at build time
according to CONFIG_KBC1126_FW1_OFFSET and CONFIG_KBC1126_FW2_OFFSET
(to do so, they should be redefined as hex), and linked to
CONFIG_ECFW_PTR_ADDR within bootblock, so kbc1126_ec_insert is not
needed at build time any more.
Test passed on Elitebook Folio 9470m.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I4f0de0c4d7283e630242fbe84a46e0547783c49e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ib1be1db6f475ad0e1f34703bfe1257d02b86742c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The commit d023909b "treewide: Disable R_AMD64_32S relocation support"
clflush the address stored in _cbmem_top_ptr, which is the same address
cbmem_top() returns, instead of clflush _cbmem_top_ptr itself.
Fix that by providing the correct address to clflush.
Change-Id: If74591e7753cd9c3c097516430a212d416f53e4d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The cpu_relax method is defined for x86. This CL adds a no-op method so
that it can be used in common code.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcb4546ceb2894eeb37589d0282b7e076d7a4747
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
arch/ppc64/include/arch/io.h: use proper instructions for IO operations
Those instrunctions are:
* Load {byte,half,word} and Zero Caching Inhibited indeXed (l*zcix)
* Store {byte,half,word} Caching Inhibited indeXed (st*cix)
for in* and out*, respectively.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
arch/ppc64/include/arch/io.h: implement istep reporting
Change-Id: Ib65c99888ba2e616893a55dff47d2b445052fa7c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
CONFIG(SMP) was an invalid condition to use in cases where one
stage requires spinlocks and another one does not. The
stage not requiring spinlock still required <smp/spinlock.h>
to be implemented with no-op stubs.
This reverts commit 037ee4b556
soc/amd/picasso: Add dummy spinlock for psp_verstage
Change-Id: Iba52febdeee78294f916775ee9ce8a82d6203570
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
There is no platform in our tree that requires the PCI MMIO ops but
doesn't want the pci_s_* definitions. The only case where we include
the `pci_mmio_cfg.h` header but don't want the pci_s_* functions to
use MMIO is on older x86 platforms, so move the guard there.
Change-Id: Iaeed6ab43ad61b7c0e14572b12bf4ec06b6a26af
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
AMD platforms require the SPI contents to be 64 byte aligned in order to
use the SPI DMA controller.
BUG=b:179699789
TEST=Build guybrush and verify cbfs was invoked with -a 64
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I842c85288acd8f7ac99b127c94b1cf235e264ea2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
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>
|
|
The commit 04a40379b has a wrongly written variable, which sets an
IOAPIC register to a wrong value and makes the Linux kernel unable to
boot.
Tested on HP EliteBook 2760p, the kernel boots after this patch.
Change-Id: Ifda7bb61a431dbf9c2df2f738aa806dd6d8097b8
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Remove the test for count=0 that leaked from drivers/generic/ioapic
implementation. See commit ea2fb8d80 and commit 8cc25d229.
Change-Id: I26944b930851fbea160c844ea46e2faa61c9af8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The number of redirection table entries (aka interrupt vectors) inside
an I/O APIC may depend of the SKU, with the related register being of
type read/write-once. Provide support utilities to either lock or set
this registers value.
Change-Id: I8da869ba390dd821b43032e4ccbc9291c39e6bab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add system wake-up type in smbios type 1 - system information.
TESTED=On S9S, can override original value and show expected result
using "dmidecode -t 1".
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: If79ba65426f1f18ebb55a0f3ef022bee83c1a93b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
|
|
There are two possible code sections where the cpu_info macros can be
included: .code32 and .code64
Doing a `push %eax` while in a .code64 section will result in a compiler
error. This macro manually pushes the 32-bit register onto the stack so
we can share the code between 32 and 64 bit builds.
We also can't implicitly dereference per_cpu_segment_selector because
it's a 32-bit address. Trying to do this results in the following:
E: Invalid reloc type: 11
E: Illegal use of 32bit sign extended addressing at offset 0x1b2
If we load the address first, then dereference it, we can work around
the limitation.
With these fixes, 64-bit builds can now use CPU_INFO_V2.
BUG=b:179699789
TEST=Boot qemu 64 bit build with CPU_INFO_V2 and 4 CPUs. See AP init
work as expected.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4e72a808c9583bb2d0f697cbbd9cb9c0aa0ea2dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
With the recent addition of SMBIOS table 20, the cbmem area on
google/brya0 overflows and
ERROR: Increase SMBIOS size
SMBIOS tables: 2128 bytes.
is seen in the logs.
Therefore, double the size of the SMBIOS area from 2 KiB to 4 KiB to
accomodate more tables as needed. This happens during ramstage so 2k
is not a big deal at this point.
Change-Id: I43aa6a88d176e783cc9a4441b35b8d608c4101cd
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Since cpu_info() is no longer required to use threads, we no longer need
to initialize it in romstage or earlier. This code was also incomplete
since it didn't initialize the %gs segment.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I615b718e9f035ca68ecca9f57d7f4121db0c83b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
We only ever start and execute threads on the BSP. By explicitly
checking to see if the CPU is the BSP we can remove the dependency on
cpu_info. With this change we can in theory enable threads in all
stages.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS and verify coop multithreading still works
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iea4622d52c36d529e100b7ea55f32c334acfdf3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58199
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I640d17cdee2bdaa4fe7049ce66a327b58924bc6f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55288
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
All boards with DRIVERS_GENERIC_IOAPIC select it.
Presumably the related configuration of routing IRQ0 when
IOAPIC is enabled should be always done to provide i8259
legacy compatibility for payloads.
Change-Id: Ie87816271fa63bba892c8615aa5e72ee68f6ba93
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
If available, use data from MEMINFO CBMEM table and saved handles
from type 17/19 tables to generate type 20 (Memory Device Mapped
Address) SMBIOS table.
Windows 10/11 and some other OSes use this table to report the total
memory available on a given device.
Change-Id: I2574d6209d973a8e7f112eb3ef61f5d26986e47b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58271
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is currently a fundamental flaw in the current cpu_info()
implementation. It assumes that current stack is CONFIG_STACK_SIZE
aligned. This assumption breaks down when performing SMM relocation.
The first step in performing SMM relocation is changing the SMBASE. This
is accomplished by installing the smmstub at 0x00038000, which is the
default SMM entry point. The stub is configured to set up a new stack
with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point
of smm_do_relocation located in RAMSTAGE RAM.
This means that when smm_do_relocation is executed, it is running in SMM
with a different sized stack. When cpu_info() gets called it will be
using CONFIG_STACK_SIZE to calculate the location of the cpu_info
struct. This results in reading random memory. Since cpu_info() has to
run in multiple environments, we can't use a compile time constant to
locate the cpu_info struct.
This CL introduces a new way of locating cpu_info. It uses a per-cpu
segment descriptor that points to a per-cpu segment that is allocated on
the stack. By using a segment descriptor to point to the per-cpu data,
we no longer need to calculate the location of the cpu_info struct. This
has the following advantages:
* Stacks no longer need to be CONFIG_STACK_SIZE aligned.
* Accessing an unconfigured segment will result in an exception. This
ensures no one can call cpu_info() from an unsupported environment.
* Segment selectors are cleared when entering SMM and restored when
leaving SMM.
* There is a 1:1 mapping between cpu and cpu_info. When using
COOP_MULTITASKING, a new cpu_info is currently allocated at the top of
each thread's stack. This no longer needs to happen.
This CL guards most of the code with CONFIG(CPU_INFO_V2). I did this so
reviewers can feel more comfortable knowing most of the CL is a no-op. I
would eventually like to remove most of the guards though.
This CL does not touch the LEGACY_SMP_INIT code path. I don't have any
way of testing it.
The %gs segment was chosen over the %fs segment because it's what the
linux kernel uses for per-cpu data in x86_64 mode.
BUG=b:194391185, b:179699789
TEST=Boot guybrush with CPU_INFO_V2 and verify BSP and APs have correct
%gs segment. Verify cpu_info looks sane. Verify booting to the OS
works correctly with COOP_MULTITASKING enabled.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I79dce9597cb784acb39a96897fb3c2f2973bfd98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
<clocks.h> and smp_processor_id() aren't used anywhere anymore. Get rid
of them.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1a8c892b066e6ac0e7cec5316633d44165344e78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The %fs and %gs segment are typically used to implement thread local
storage or cpu local storage. We don't currently use these in coreboot,
so there is no reason to map them. By setting the segment index to 0,
it disables the segment. If an instruction tries to read from one of
these segments an exception will be raised.
The end goal is to make cpu_info() use the %gs segment. This will remove
the stack alignment requirements and fix smm_do_relocation.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iaa376e562acc6bd1dfffb7a23bdec82aa474c1d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Currently, static analyzers don't recognize that hlt() doesn't return,
so they show errors like uninitialized variables assuming that it does
return. This takes care of that problem.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ia2325700b10fe1f89d749edfe5aee72b47d02f2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This will help reduce duplication and make it easier to add new members
to the cpu_info struct.
BUG=b:194391185, b:179699789
TEST=Compare assembly of romstage and ramstage before and after
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I31f264f4bb8b605fa3cb3bfff0d9bf79224072aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
SBI comes with its own memset implementation (under a slightly
different name) that gcc11 "helpfully" tries to replace with a call
to memset(). Since we don't provide a memset, the linker isn't happy,
so prevent gcc from doing that.
Change-Id: I3459a519d46a123f873306000b8b2261bd64e0c3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Both bool and uintptr_t types are used in this file, so include types.h
to have the definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I647d9f50cd6edaf08bebf5d713cd05731fadfc1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This file uses the asmlinkage macro.
BUG=b:179699789
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id5b73c174aa946b8205b4172609729b0548cbd8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
If a device is disabled, do not call the `get_smbios_data` code.
Change-Id: I8960f869e0864f7c82d5fe507f96b62cbd045569
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The call to the `get_smbios_data` device operation is followed by
calls to unconditional default functions, which lacks flexibility.
Instead, have devices that implement `get_smbios_data` call these
default functions as needed.
Most `get_smbios_data` implementations are in mainboard code, and are
bound to the root device. The default functions only operate with PCI
devices because of the `dev->path.type != DEVICE_PATH_PCI` checks, so
calling these functions for non-PCI devices is unnecessary. QEMU also
implements `get_smbios_data` but binds it to the domain device, which
isn't PCI either.
Change-Id: Iefbf072b1203d04a98c9d26a30f22cfebe769eb4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Rename two functions that have `walk` in their name but do not perform
any walk. The new names are derived from the comments just above these
functions' definitions. Also, remove these now-redundant comments.
Change-Id: I380a5b60b3f4e820e8f6d6f960826de97c0446be
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57361
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch updates debug message to specifically the case when SMBIOS
table 7 write would abort due to either `unknown` CPU or CPU `doesn't
have support for deterministic cache cpuid leaf`.
Change-Id: I288593b3f78ab858bf66c689e7cfb6ba2ff746d0
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Don't attempt to fill the SMBIOS table if the CPU doesn't support
deterministic cache CPUID.
TEST=Able to fix the hang issue seen on ASRock E350M1 with commit hash
e2b5fee.
Change-Id: Id65dc963e235f7080370a32cf69bcc4bee94d28f
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57306
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
`cpu_get_cache_info_leaf()` function is responsible to report leaf
value for CPU that have support for deterministic cache cpuid. As per
available datasheets from AMD and Intel the supported CPUID leafs are
0x8000_001d for AMD and 0x04 for Intel. Hence, this CL skips returning
default leaf value as `0`.
TEST=Verified fixes: e2b5fee3b006 (arch/x86: smbios write 7 table using
deterministic cache functions) hang issue on ASRock E350M1.
Change-Id: Iee33b39298e7821ac5280d998172b58a70c8715b
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57305
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ic7396b8429e29739e18a189dacea3a76e571cd58
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57049
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The `smbios_get_device_type_from_dev()` function is only called once
from the `smbios_walk_device_tree_type41()` function. Put the former
function's definition above the latter function's, instead of having
them a thousand lines apart.
Change-Id: Idc6175324ca8a14841eaf7d6904712efb75f2d26
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57205
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch makes use of deterministic cache helper functions, for
example: cpu_get_cache_type(), cpu_get_cache_level() etc. helper
functions from arch/x86/cpu_common.c file.
Also, changed argument for get_number_of_caches() function that receives
cpu_get_max_cache_share() data directly.
Drop unused variables partitions, cache_line_size and number_of_sets as
struct cpu_cache_info.size would provide the cache size directly.
TEST=Able to dump SMBIOS Table 7 with this CL, no changes seen in output.
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Handle 0x0005, DMI type 7, 27 bytes
Cache Information
Socket Designation: CACHE1
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Unknown
Location: Internal
Installed Size: 288 kB
Maximum Size: 288 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Unknown
System Type: Data
Associativity: 12-way Set-associative
Handle 0x0006, DMI type 7, 27 bytes
Cache Information
Socket Designation: CACHE1
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Unknown
Location: Internal
Installed Size: 192 kB
Maximum Size: 192 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Unknown
System Type: Instruction
Associativity: 8-way Set-associative
Handle 0x0007, DMI type 7, 27 bytes
Cache Information
Socket Designation: CACHE2
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Unknown
Location: Internal
Installed Size: 1280 kB
Maximum Size: 1280 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: Unknown
Handle 0x0008, DMI type 7, 27 bytes
Cache Information
Socket Designation: CACHE3
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Unknown
Location: Internal
Installed Size: 12288 kB
Maximum Size: 12288 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: 12-way Set-associative
Change-Id: Iedbd3b745629dea57c3ad6b0d187eab2bcc3f7d3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This patch creates helper function that internally detects the CPU
type (AMD or Intel) and pick the leaf to send CPUID instruction with
different cache level to retrieve deterministic cache parameters.
Lists of helper functions generated as part of this CL :
1. cpu_check_deterministic_cache_cpuid_supported => if CPU has support
for deterministic cache using CPUID instruction.
2. cpu_get_cache_ways_assoc_info => Get cache ways for associativity.
3. cpu_get_cache_type => Get cache type.
4. cpu_get_cache_level => Get cache level.
5. cpu_get_cache_phy_partition_info => Get cache physical partitions.
6. cpu_get_cache_line_size => Get cache line size.
7. cpu_get_cache_sets => Get cache number of sets.
8. cpu_is_cache_full_assoc => Check if cache is fully associative.
9. cpu_get_max_cache_share => Cores are sharing this cache.
10. get_cache_size => Calculate the cache size.
11. fill_cpu_cache_info => Fill cpu_cache_info structure.
Change-Id: I0dd701fb47460092448b64c7fa2162f762bf3095
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
The x86 thread code is all x86_32 specific. It needs to be updated to
work with 64 bit. For now just throw an error when compiling.
BUG=b:179699789
TEST=none
Suggested-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I96187ad84bdec40c6883748afa41e217bc389b79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This change does the following:
* Pushes the cpu_info struct into the top of the stack (just like
c_start.S). This is required so the cpu_info function works correctly.
* Adds the thread.c to the romstage build.
I only enabled this for romstage since I haven't done any tests in other
stages, but in theory it should work for other stages.
BUG=b:179699789
TEST=Boot guybrush with threads enabled in romstage
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8e32e1c54dea0d0c85dd6d6753147099aa54b9b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The alignment for `struct cpu_info` is wrong on x86_64. c_start.S uses
the `push` instruction when setting up the cpu_info struct. This
instruction will push 8 bytes but `unsigned int` is 4 bytes. By making
it a `size_t` we get the correct size for both x86_32 and x86_64.
BUG=b:179699789
TEST=Boot guybrush to the OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8ef311aaa8333ccf8a5b3f1f0e852bb26777671c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The structure and function are not currently used or implemented. x86 is
the only arch that currently implements it. It is currently used for
COOP_MULTITASKING and mp_init.
Keeping around the unused definitions leads to confusion.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0775ef03168f7f9c41b1b05cb8f12724d0458ba5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
There is no reason this needs to be done in asm. It also allows
different stages to use threads. If threads are no used in a specific
stage, the compiler will garbage collect the space.
BUG=b:179699789
TEST=Boot guybrush to the OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib5a84a62fdc75db8ef0358ae16ff69c20cbafd5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56531
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Switching threads while holding a spinlock can lead to a deadlock. This
happens if you have two thread trying to print to the serial console
because the uart code uses udelay.
BUG=b:179699789
TEST=Boot guybrush and no longer see a deadlock when printing to
console from a second thread.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1b929070b7f175965d4f37be693462fef26be052
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
All of the build configuration is set to produce big endian image on PPC64.
In addition, the toolchain produced by coreboot-sdk does not include little
endian libraries so it is not possible to build LE image even when that
configuration is changed.
This patch changes byte order definition which is required for proper work
of functions that deal with endianness, like read_{le,be}*() or
{le,be}*toh().
It also revealed bugs related to the endianness on BE targets that are
addressed in the following patches.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Change-Id: Id31328a832d11db20822733304b0ae477e858d25
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In x86_64, the first function parameter is passed in rdi register, and
the 32-bit code after exiting long mode reads the resume vector in
4(%esp), so it's needed to save the resume vector from rdi to 4(%rsp).
Also note that the function attribute "regparm" only works on x86-32
targets according to the GCC manual, so "asmlinkage" doesn't change
the ABI of an x86_64 function.
Tested on HP EliteBook 2560p. The laptop can resume from S3 in x86_64
mode after this change.
Change-Id: I45f2678071b2511c0af5dce9d9b73ac70dfd7252
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55947
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested on Intel Sandybridge x86_64 and x86_32.
Change-Id: I152483d24af0512c0ee4fbbe8931b7312e487ac6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
In order to disable X86_TOP4G_BOOTMEDIA_MAP it requires the definition
to be overridden. This makes it a little less ergonomic to use. Instead
introduce the inverse option that can be selected. I chose to leave
X86_TOP4G_BOOTMEDIA_MAP since it keeps the Makefiles simple.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I65bbc118bde88687a7d7749c87acf1cbdc56a269
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Introduce `USE_EXP_X86_64_SUPPORT` in `src/arch/x86/Kconfig` and guard
it with `HAVE_EXP_X86_64_SUPPORT`. Replace the per-CPU implementations
of the same functionality with the newly-added Kconfig options. Update
documentation and the config file for QEMU accordingly.
Change-Id: I550216fd2a8323342d6b605306b0b95ffd5dcd1c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically
select the per-stage arch options. Subsequent commits will leverage
this to allow choosing between 32-bit and 64-bit coreboot where all
stages are x86. AMD Picasso and AMD Cezanne are the only exceptions
to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set
the per-stage arch options accordingly.
Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Introduce the `smbios_full_table_len` function to consolidate table
length calculation. The case where the length of a table equals the
length of the structure happens when a table has no strings.
Change-Id: Ibc60075e82eb66b5d0b7132b16da000b153413f9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
|
|
Change-Id: I949da86605e76b186ef2fdbfbc112b71544b694a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
