Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive, and make it constant.
In the case of Intel model 2065x the mca_get_bank_count() call replaces
a magic number.
Change-Id: I245b15f57e77edca179e9e28965383a227617174
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56244
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When accessing the MCA MSRs, the MCA bank number gets multiplied by 4
and added to the IA32_MC0_* define to get the MSR number. Add a macro
that already does this calculation to avoid open coding this repeatedly.
Change-Id: I2de753b8c8ac8dcff5a94d5bba43aa13bbf94b99
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56243
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive.
Change-Id: I70ad423aab484cf4ec8f51b43624cd434647aad4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Commit 1aa60a95bd broke microcode loading for chipsets that have a
microcode blob with a total_size field set to 0. This appears to be
support for older chipsets, where the size was set to 0 and assumed to
be 2048 bytes. The fix is to change the result of the subtraction to a
signed type, and ensure the following comparison is done without
promoting the signed type to an unsigned one.
Resolves: https://ticket.coreboot.org/issues/313
Change-Id: I62def8014fd3f3bbf607b4d58ddc4dca4c695622
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56153
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Ott <coreboot@desire.ch>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add IFITTOOL as a dependency where needed and remove where it is
unneeded.
Change-Id: I88c9fc19cca0c72e80d3218dbcc76b89b04feacf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Allow to compile the experimental x86_64 code.
Tested on Lenovo Thinkpad T410.
Hangs in SMM relocation. When skipped boots into GNU/Linux.
Change-Id: I60f2fccba357cb5fb5d85feb4ee8d02abfe6bc7e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
On x86_64, the default heap size is too small when using 32 CPUs.
Change-Id: Ib4f770a7a54d975d213b2456cc7d1ed9151cb6f9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
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>
To generalise the choice of 32-bit or 64-bit coreboot on x86 hardware,
have platforms select `ARCH_X86` directly instead of through per-stage
Kconfig options, effectively reversing the dependency order.
Change-Id: If15436817ba664398055e9efc6c7c656de3bf3e4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Expand NO_EARLY_BOOTBLOCK_POSTCODES to all of the early assembly code in
bootblock.
BUG=b:191370340
TEST: Build with & without the option enabled
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Idb4a96820d5c391fc17a0f0dcccd519d4881b78c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The `ARCH_POSTCAR_X86_32` and `ARCH_POSTCAR_X86_64` options are already
selected indirectly. There's no need to explicitly select them.
Change-Id: Iaa2e99e6f0765741fc5af67180d116bb6cc23d38
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55757
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds a method called `mainboard_smi_finalize` which provides
a mechanism for a mainboard to execute some code as part of the finalize
method in the SMM stage before SoC does its finalization.
BUG=b:191189275
BRANCH=None
TEST=Implement `mainboard_smi_finalize` on lalala and verify that the
code executes in SMM.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: If1ee63431e3c2a5831a4656c3a361229acff3f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This option is valid for Broadwell as well as Haswell.
Change-Id: I4f1e9663806bae279f6aca36f09a0c989c12e507
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Trigger mode LAPIC_INT_LEVELTRIG was only used with LAPIC_DM_INIT,
specifically for (obsolete) Init Level De-assert.
Level LAPIC_INT_ASSERT is required to be set for all other delivery
modes other than LAPIC_DM_INIT.
This reverts the two above changes that X2APIC mode support introduced
to the IPI for LAPIC_DM_SMI.
Change-Id: I7264f39143cc6edb7a9687d0bd763cb2703a8265
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix compilation on x86_64 by using compatible types.
The MRC blob isn't supported yet as there's no x86_32 wrapper.
Tested on HP8200:
* Still boots on x86_32.
* Boots to payload in x86_64
Change-Id: Iab29a87d52ad3f6c480f21a3b8389a7f49cb5dd8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In x86_64 code every function call consumes 32byte of stack with
no stack local variables being used. That limits the function call depth
in SMM to 32 or less.
Double the stack size to prevent overwriting the stack canary as seen
on HP8200 and x86_64 enabled.
Change-Id: Iee202ba2ae609a474d0eb3b06f49690f33f4eda8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This fixes a hard to debug hang that could occur in any stage, but in
the end it follows simple rules and is easy to fix.
In long mode the 32bit displacement addressing used on 'mov' and 'lea'
instructions is sign-extended. Those instructions can be found using
readelf on the stage and searching for relocation type R_X86_64_32S.
The sign extension is no issue when either running in protected mode or
the code module and thus the address is below 2GiB. If the address is
greater than 2GiB, as usually the case for code in TSEG, the higher
address bits [64:32] are all set to 1 and the effective address is
pointing to memory not paged. Accessing this memory will cause a page
fault, which isn't handled either.
To prevent such problems
- disable R_AMD64_32S relocations in rmodtool
- add comment explaining why it's not allowed
- use the pseudo op movabs, which doesn't use 32bit displacement addressing
- Print a useful error message if such a reloc is present in the code
Fixes a crash in TSEG and when in long mode seen on Intel Sandybridge.
Change-Id: Ia5f5a9cde7c325f67b12e3a8e9a76283cc3870a3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Note that there are assumptions about LAPIC MMIO location
in both AMD and Intel sources in coreboot proper.
Change-Id: I2c668f5f9b93d170351c00d77d003c230900e0b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55194
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Function is needed with PARALLEL_MP and excluding guard will
be added to the source file.
The incompatibilities with X2APIC_SUPPORT have been fixed
so the exclusion is removed here too.
Change-Id: I5696da4dfe98579a3b37a027966b6758f22574aa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
They are not __always_inline and specially enable_lapic()
will become more complex to support X2APIC state changes.
Change-Id: Ic180fa8b36e419aba07e1754d4bf48c9dfddb2f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55258
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allows compile-time optimisation on platforms that do not wish
to enable runtime checking of X2APIC.
Legacy lapic_cpu_init() is incompatible so there is dependency
on PARALLEL_MP. Also stop_this_cpu() is incompatible, so there
is dependency on !AP_IN_SIPI_WAIT.
Since the code actually lacks enablement of X2APIC (apparently
assuming the blob has done it) and the other small flaws pointed
out in earlier reviews, X2APIC_RUNTIME is not selected per
default on any platform yet.
Change-Id: I8269f9639ee3e89a2c2b4178d266ba2dac46db3f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55073
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: Wonkyu Kim <wonkyu.kim@intel.com>
For the purpose of LAPIC IPI messaging it is not required to
evaluate if IOAPIC is enabled. The necessary enable_lapic()
will still be called as part of setup_lapic() within cpu init.
Change-Id: I8b6a34e39f755452f0af63ae0ced7279747c28fc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It was not used, platforms should move away from LEGACY_SMP_INIT
instead of maintaining this.
Change-Id: Id89ec4bb0bdc056ac328f31397e4fab02742e444
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
IO MWAIT redirection is disabled, which means reads to the P_LVL2 and
P_LVL3 "registers" will never produce any C-state transition requests.
Change-Id: Ibbf7b915a9909d6bc8e784a439df751e11ec5bee
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
IO MWAIT redirection is disabled, which means reads to the P_LVL2 and
P_LVL3 "registers" will never produce any C-state transition requests.
Moreover, the register resource descriptors for all reported C-states
use the FFixedHW address space, not I/O.
Change-Id: I026835dd24d7ac1e1bae2d851e011e1670abaad4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Even if IO MWAIT redirection were enabled, the base address is wrong.
Moreover, the register resource descriptors for all reported C-states
use the FFixedHW address space, not I/O.
Change-Id: Ic2faaafbe4928994aeeab8098d8e0fb6703d203d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The MSR only needs to be set when IO MWAIT redirection is to be enabled.
Change-Id: Ie856086babe4dadc690f701bd90a7bbac88cb4ad
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This is a leftover when migrating to C_ENV_BOOTBLOCK
Change-Id: Ibc610cd15448632dc13d87094853d9b981e2679b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c:415:42: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'u32' {aka 'unsigned int'} [-Werror=format=]
415 | printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n",
| ~~^
| |
| long unsigned int
| %x
416 | __func__, stub_params->stack_top - total_stack_size);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| u32 {aka unsigned int}
The size of `size_t` differs between i386-elf (32-bit) and
x86_64-elf/x86_64-linux-gnu (64-bit).
Unfortunately, coreboot hardcodes
src/include/inttypes.h:#define PRIx32 "x"
so `PRIx32` cannot be used.
There use `z` as length modifier, as size_t should be always big enough
to hold the value.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Change-Id: Ib504bc5e5b19f62d4702b7f485522a2ee3d26685
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c: In function 'smm_module_setup_stub':
src/cpu/x86/smm/smm_module_loader.c:360:70: error: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format=]
360 | printk(BIOS_ERR, "%s: state save size: %zx : smm_entry_offset -> %lx\n",
| ~~^
| |
| long unsigned int
| %x
As `size_t` is defined as `long unsigned int` in i386-elf (32-bit), the
length modifier `l` matches there. With x86_64-elf/x86_64-linux-gnu
(64-bit) and `-m32` `size_t` is defined as `unsigned int` resulting in a
type mismatch. So, use the correct length modifier `z` for the type
`size_t`.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Change-Id: I4172e0f4dc40437250da89b7720a5c1e5fbab709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The 64-bit compiler x86_64-linux-gnu-gcc-10 aborts the build with the
format warning below:
CC ramstage/cpu/x86/smm/smm_module_loader.o
src/cpu/x86/smm/smm_module_loader.c: In function 'smm_create_map':
src/cpu/x86/smm/smm_module_loader.c:146:19: error: format '%zx' expects argument of type 'size_t', but argument 3 has type 'uintptr_t' {aka 'long unsigned int'} [-Werror=format=]
146 | " smbase %zx entry %zx\n",
| ~~^
| |
| unsigned int
| %lx
147 | cpus[i].smbase, cpus[i].entry);
| ~~~~~~~~~~~~~~
| |
| uintptr_t {aka long unsigned int}
In coreboot `uintptr_t` is defined in `src/include/stdint.h`:
typedef unsigned long uintptr_t;
As `size_t` is defined as `long unsigned int` in i386-elf (32-bit), the
length modifier `z` matches there. With x86_64-elf/x86_64-linux-gnu
(64-bit) and `-m32` `size_t` is defined as `unsigned int` resulting in a
type mismatch. Normally, `PRIxPTR` would need to be used as a length
modifier, but as coreboot always defines `uintptr_t` to `unsigned long`
(and in `src/include/inttypes.h` also defines `PRIxPTR` as `"lx"`), use
the length modifier `l` to make the code more readable.
Found-by: x86_64-linux-gnu-gcc-10 (Debian 10.2.1-6) 10.2.1 20210110
Fixes: afb7a814 ("cpu/x86/smm: Introduce SMM module loader version 2")
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Change-Id: I32bff397c8a033fe34390e6c1a7dfe773707a4e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Intel CBnT (and Boot Guard) makes the chain of trust TOCTOU safe by
setting up NEM (non eviction mode) in the ACM. The CBnT IBB (Initial
BootBlock) therefore should not disable caching.
Sidenote: the MSR macros are taken from the slimbootloader project.
TESTED: ocp/Deltalake boot with and without CBnT and also a broken
CBnT setup.
Change-Id: Id2031e4e406655e14198e45f137ba152f8b6f567
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
No board currently uses AMD PI 00630F01 so remove it.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: If270c2a979346029748230952caba78a5e763d75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
