In 64bit movsq is available which moves memory in chunks of 8 bytes
rather than 4 bytes.
Linux uses the same code.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I65f178d2ed3aae54b0c1ce739c2b4af8738b9fcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This is required for compliant ACPI/SMBIOS implementations on AArch64,
and can optionally be displayed to the user.
Change-Id: I7022fc3c0035208bc3fdc716fc33f6b78d8e74fc
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to
set a ramstage CBFS cache size. A cache size of zero disables the
CBFS cache feature. The default size is 16 KB which seems a
reasonable minimal value large enough to satisfy basic needs such as
the decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
To support S3 suspend/resume use-case, the CBFS cache memory cannot be
released to the operating system. There are two options to meet this
requirement:
1. Define a static CBFS cache buffer (located in the .bss section)
2. Create a new CBMEM entry
Option #2 seems more powerful but considering that:
1. The CBFS cache is actually not a cache but just a scratch pad
designed to be isolated between stages
2. postcar is a very short stage not really needing CBFS cache
3. The static initialization of the `cbfs_cache' global
variable (cf. src/lib/cbfs.c) offers a simple and robust design
=> It is simpler to use a static buffer and limit the support to
ramstage.
Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define
a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig
must be set to enable the use of a static buffer as the CBFS cache
scratchpad.
TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map()
Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a function to get the number of substates supported by
an Intel CPU C-state.
Test: Can read out the supported C-state substates.
Change-Id: Ie57e87609ea5d6ec6f37154e8b84f1e9574aa4a9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In the cpuid helper functions eax is always written to
by the cpuid instruction, so add it to the output clobbered list.
This prevents GCC from generating code with undefined behaviour
when the function is inlined.
Test: Verified that the generated assembly is sane and runtime
tests showed no "strange" behaviour when calling cpuid
functions.
Change-Id: I5dc0bb620184a355716b9c8d4206d55554b41ab9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78192
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Since also some AMD CPUs have reserved physical address bits that can't
be used as normal address bits, introduce the
RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets
selected by CPU_INTEL_COMMON, and use the new common option to configure
if the specific SoC/CPU code implements get_reserved_phys_addr_bits or
if the default of this returning 0 is used instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The number of physical address bits and reserved address bits shouldn't
ever be negative, so change the return type of cpu_phys_address_size,
get_reserved_phys_addr_bits, and get_tme_keyid_bits from int to unsigned
int.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9e67db6bf0c38f743b50e7273449cc028de13a8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Use cpuid_get_max_func instead of open-coding the same functionality in
cpu_check_deterministic_cache_cpuid_supported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I590f0c840bc62bbd0b5038c5827367d811e30d10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Before the cpuid(0x80000001) read in smbios_write_type4, it was
previously checked in a slightly convoluted way if the result from
cpu_cpuid_extended_level was larger than 0x80000001, but the check
should be if it is larger or equal to 0x80000001.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabcfdb2b8b90d80baf8f4c4d2fd79f1f44866dc7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78107
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use cpu_cpuid_extended_level instead of open-coding the same
functionality in smbios_write_type4.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib8e20726ea17e8ed94d5ff8f6568758fcfa162ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Use cpuid_eax and cpuid_ecx instead of sort-of open-coding the same
functionality in cpu_check_deterministic_cache_cpuid_supported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib0dc2be4f602bf63183b9096e38403ae2f45d959
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78058
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use cpu_cpuid_extended_level instead of open-coding the same
functionality in cpu_check_deterministic_cache_cpuid_supported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4ea22c3997769179311f3c8822e6d8cc15a8834c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78057
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CONFIG_HAVE_ACPI_SUPPORT does not exist. Replace it with
HAVE_ACPI_TABLES.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icc7c00dc19cae4be13e6c8cc0084a69aed8fb8f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Linux v6.3.5 is able to detect and use ACPI tables on an out of tree
target using hacked version of u-boot to pass ACPI through UEFI.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4f60c546ec262ffb4d447fe6476844cf5a1b756d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76071
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
With commit b7832de026 ("x86: Add .data
section support for pre-memory stages"), the libhwbase and libgfxinit
.data symbols can be moved to the .data section.
Change-Id: I302391e7bc8cb4739e5801d360c57776b0e3eff6
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When more ACPI tables are written than space is available in CBMEM, the
buffer overflow corrupts other CBMEM tables and a successful boot is unlikely.
Upgrade the error message to critical and be more precise what to do.
Change-Id: I152842945f552905729265f7d623cd581dd0a8d0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
commit f8ac3dda02 ("soc/intel/common:
Order the CPUs based on their APIC IDs") sort algorithnm walks all the
`cpu_info' entries without discarding empty ones. Since `cpu_info' is
not initialized, the data that is used is undefined and it generally
results in the creation of invalid `Local x2APIC' entries in the
MADT ("APIC") ACPI table.
Depending on the X2APIC ID value the Linux kernel behavior
changes (cf. arch/x86/kernel/acpi/boot.c::acpi_register_lapic()):
1. If (int)ID >= MAX_LOCAL_APIC (32768), the Linux kernel discards the
entry with the "skipped apicid that is too big" INFO level
message.
2. If (int)ID < MAX_LOCAL_APIC (32768) (including negative) this data
is taken into account and it can lead to undesirable behavior such
as core being disabled as (cf. "native_cpu_up: bad cpu" ERROR
kernel message).
TEST=Verified the MADT does not contain any invalid entries on rex.
Change-Id: I19c7aa51f232bf48201bd6d28f108e9120a21f7e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77615
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
On Intel SoCs, if TME is supported, TME key ID bits are reserved and
should be subtracted from the maximum physical addresses available.
BUG=288978352
TEST=Verified that DMAR ACPI table `Host Address Width` field on rex
went from 45 to 41.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I9504a489782ab6ef8950a8631c269ed39c63f34d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
It makes the detection of this feature accessible without the
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU dependency.
BUG=288978352
TEST=compilation
Change-Id: I005c4953648ac9a90af23818b251efbfd2c04043
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77697
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Arm needs very little of FADT. Just a HW reduced model bit and low power
idle bit set.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I197975f91cd47e418c8583cb0e7b7ea2330363b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76180
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
acpi.c contains architectural specific things like IOAPIC, legacy IRQ,
DMAR, HPET, ... all which require the presence of architectural headers.
Instead of littering the code with #if ENV_X86 move the functions to
different compilation units.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
In VBOOT_STARTS_IN_ROMSTAGE=y case, vboot_run_logic() did not
get called when postcar was loaded from TSEG stage cache on
ACPI S3 resume path. Resume failed as MP init attempts to
access microcode update from unverified FW_MAIN_A/B section.
In a similar fashion, for POSTCAR=n, loading ramstage from
TSEG stage cache would bypass the call to vboot_run_logic().
TEST=samsung/lumpy with VBOOT_STARTS_IN_ROMSTAGE=y is able
to complete S3 resume.
Change-Id: I77fe86d5fd89d22b5ef6f43e65a85a4ccd3259d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Attempting to use X2APIC MSRs before the call to enable_lapic()
is made raises exception and double-faults.
Change-Id: Ib97889466af0fbe639bec2be730784acc015b525
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Option name strings should not end with a period, remove it.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Id61d8961cad2cd311db7d9da3bdb86f0f28b57b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
SMBIOS is not specific to architecture, and this is mostly a generic
implementation. Therefore, move it to common code, having
architecture-specific code define some functions to fill this data.
Change-Id: I030c853f83f8427da4a4c661b82a6487938b24e6
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75886
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
DDR5 spd is not supported read by coreboot. But FSP can read it,
so print the memory information from smbios type17 dimm information.
TEST=check the coreboot log.
memory Channel-0-DIMM-0 type is DDR5
memory part number is MTC8C1084S1SC56BG1
memory max speed is 5600 MT/s
memory speed is 5200 MT/s
memory size is 16384 MiB
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I2b5ca1f4a59598531a6cba500672c2717f2a7b00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75756
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All emulated targets properly compile and boot to the same extent as
with gcc.
Change-Id: I11ddd9347c2638fb7c26cd4939aa96ff8ddd1e66
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74571
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Daniel Maslowski <info@orangecms.org>
Building with clang is currently broken as /usr/bin/ld.bfd is used
rather than the proper crosstoolchain linker.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Idd8006a26b2c2f9f777fdffe231c3c774320d805
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75397
Reviewed-by: Daniel Maslowski <info@orangecms.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clang complains about the stack pointer register variable being
uninitialized. This can remediated by making the variable global. Change
the variable name to be more unambiguous.
Change-Id: I24602372833aa9d413bf396853b223263fd873ed
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74570
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Daniel Maslowski <info@orangecms.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To avoid magic constants in the code, add defines for the VGA MMIO
address range from 0xa0000-0xbffff.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie4a4f39a4e876bbba59620d689cd56c3c286daae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75618
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only the Intel Quark SoC selected this option and that SoC was dropped
in commit 531023285e ("soc/intel/quark: Drop support"), so drop this
Kconfig option too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic4f1c7530cd8ac7a1945b1493a2d53a7904daa06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75473
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCI config space access via IO ports uses two 32 bit IO ports.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie99b4f5fc01fb0405243ff108d813ee1a3d35e5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75408
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though coreboot does not allow floating point operations some
compilers like clang generate code using hw floating point registers,
e.g. SSE %XMMx registers on 64bit code by default. Floating point
operations need to be enabled in hardware for this to work (CR4). Also
in SMM we explicitly need to save and restore floating point registers
for this reason. If we instruct the compiler to not generate code with
FPU ops, this simplifies our code as we can skip that step.
With clang this reduces the binary size a bit. For instance ramstage for
qemu/Q35 drops from 216600 bytes decompressed to 212768.
TEST: See that with x86_64 bit and clang coreboot reaches the payload
without setting the CR4_OSFXSR bit in CR4. Without this change it would
bootloop very early in the bootblock on Qemu Q35.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ib8590c55e7aed1ece2aa23b8ea99463396435e11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75316
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix the error below when running a coreboot image built with
`CONFIG_UBSAN=y`.
PCI: pci_scan_bus for bus 00
shift out of bounds src/arch/x86/include/arch/pci_io_cfg.h:13:20
ubsan: unrecoverable error.
GCC with `-fsanitize=shift` also flags this:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
So, make the constant unsigned.
TEST=emulation/qemu-i440fx with `CONFIG_UBSAN=y` stops later with
[ERROR] unaligned access src/lib/rmodule.c:152:27
[EMERG] ubsan: unrecoverable error.
Change-Id: Ib05d225ab9f22078d765009b4ee6ef0c63231eed
Found-by: UBSAN
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Processing LD flags is done without most warnings enabled, which is why
this never caused problems.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic9d82c1426a1c1d2f21c8e7560685cf9d7106a88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75033
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
walkcbfs_asm is a simple CBFS implementation in assembly to find a file
on a system with memory-mapped SPI flash. It seems to be mostly unused
nowadays and is only still called for early microcode loading on some
old systems (e.g. FSP 1.1 and older).
Using this implementation with CONFIG_CBFS_VERIFICATION is unsafe
because it does not verify the hashes the way the normal CBFS code does.
Therefore, to avoid potential security vulnerabilities from creeping in,
this patch makes sure the code cannot be compiled in when
CBFS_VERIFICATION is active. That means it won't be supported on the old
boards using this for microcode loading.
Ideally CONFIG_CBFS_VERIFICATION should have a `depends on` to make this
dependency more obvious in menuconfig, but the configs actually using
this code are not easy to untangle (e.g. CONFIG_MICROCODE_UPDATE_PRE_RAM
is just set everywhere by default although only very few boards are
really using it, and a lot of different old Intel CPU models are linking
in src/cpu/intel/car/non-evict/cache_as_ram.S without being united under
a single Kconfig so that's not easy to change). To keep things simple,
this patch will just prevent the code from being built and result in a
linker error if a bad combination of Kconfigs is used together. Later
patches can clean up the Kconfigs to better wrap that dependency if the
affected boards are still of enough interest to be worth that effort.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I614a1b05881aa7c1539a7f7f296855ff708db56c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74243
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Instead of having multiple instances of the same magic numbers in the
code, introduce and use the PCI_IO_CONFIG_INDEX and PCI_IO_CONFIG_DATA
definitions.
TEST=Timeless build for Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If6f6f058180cf36cae7921ce3c7aaf1a0c75c7b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
