Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ia3935524e57885ca79586f1f4612020bb05956ab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
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>
|
|
Change-Id: Ib9c404cb55b96dcc5639287c214c5c8f468c0529
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55192
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ife127d6dc8241cccb9d52236a9152da707f0e261
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/+/55191
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I7207a9aadd987b4307ce8b3dd8dbfd47d0a5768e
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/+/55190
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Change-Id: I57c5d85d3098f9d59f26f427fe16829e4e769194
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55187
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
|
|
Change-Id: I7e42519d5bcee95970d366fd64923de874098172
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55189
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is for the !PARALLEL_MP paths.
Change-Id: If4b91834a1b6de2a902ab914610ab76c1423f1e9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55188
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Change-Id: Ibe2c24228045cbf1ed2a6b0cb0a67848cbf03019
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55203
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9833c4f6c43b3e67f95bd465c42d7a5036dff914
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
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>
|
|
This removes the need to include this code separately on each
platform.
Change-Id: I3d848b1adca4921d7ffa2203348073f0a11d090e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Change-Id: I28f262078cf7f5ec4ed707639e845710a8cc56ea
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Fix booting issues on google/kahlee introduced by CB:51723.
Update use inital apic id in smm_stub.S to support xapic mode error.
Check more bits(LAPIC_BASE_MSR BIT10 and BIT11) for x2apic mode.
TEST=Boot to OS and check apicid, debug log for CPUIDs
cpuid_ebx(1), cpuid_ext(0xb, 0), cpuid_edx(0xb) etc
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ia28f60a077182c3753f6ba9fbdd141f951d39b37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This patch removes a call to console_init() and debug print message since
the code is not thread safe. This prevents system hangs (soft hangs)
while in SMM if user drops in a new SOC with more cores or another
socket or as a result of bad configuration. Console is already
initialized after the lock has been acquired so this does not affect any
other functionality.
Tested on DeltaLake mainboard with SMM enabled and 52 CPU threads.
Change-Id: I7e8af35d1cde78b327144b6a9da528ae7870e874
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Some platforms which have large amounts of RAM and also write-combining
regions may decide to drop the WC regions in favor of the default when
preserving MTRRs for the OS. From a data safety perspective, this is
safe to do, but if, say, the graphics framebuffer is the region that is
changed from WC to UC/WB, then the performance of writing to the
framebuffer will decrease dramatically.
Modern OSes typically use Page Attribute Tables (PAT) to determine the
cacheability on a page level and usually do not touch the MTRRs. Thus,
it is believed to be safe to stop reserving MTRRs for the OS, in
general; PentiumII is the exception here in that OSes that still
support that may still require MTRRs to be available. In any case, if
the OS wants to reprogram all of the MTRRs, it is of course still free
to do so (after consulting the e820 table).
BUG=b:185452338
TEST=Verify MTRR programming on a brya (where `sa_add_dram_resources`
was faked to think it had 32 GiB of DRAM installed) and variable MTRR
map includes a WC entry for the framebuffer (and all the RAM):
MTRR: default type WB/UC MTRR counts: 13/9.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x00003fff80000000 type 6
MTRR: 1 base 0x0000000077000000 mask 0x00003fffff000000 type 0
MTRR: 2 base 0x0000000078000000 mask 0x00003ffff8000000 type 0
MTRR: 3 base 0x0000000090000000 mask 0x00003ffff0000000 type 1
MTRR: 4 base 0x0000000100000000 mask 0x00003fff00000000 type 6
MTRR: 5 base 0x0000000200000000 mask 0x00003ffe00000000 type 6
MTRR: 6 base 0x0000000400000000 mask 0x00003ffc00000000 type 6
MTRR: 7 base 0x0000000800000000 mask 0x00003fff80000000 type 6
MTRR: 8 base 0x000000087fc00000 mask 0x00003fffffc00000 type 0
ADL has 9 variable-range MTRRs, previously 8 of them were used, and
there was no separate entry for the framebuffer, thus leaving the
default MTRR in place of uncached.
Change-Id: I2ae2851248c95fd516627b101ebcb36ec59c29c3
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52522
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Coverity detects the control flow UNREACHABLE issue for the printk
usage. This change adds rc to keep the smm_module_setup_stub function
call and returns rc after printk usage.
Found-by: Coverity CID 1452602
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie3b90a8197c3b84c5a1dbca8a9ef566bef35c9ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52574
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As v1 was dropped, rename v2.
Change-Id: I4dd51804e9391284c7624c42ad8180a14b1a4c84
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I536a104428ae86e82977f2510b9e76715398b442
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Use the same stack location during relocation as for the permanent
handler.
When the number of CPUs is too large the stacks during relocation
don't fit inside the default SMRAM segment at 0x30000. Currently the
code would just let the CPU stack base grow downwards outside of the
default SMM segment which would corrupt lower memory if S3 is
implemented.
Also update the comment on smm_module_setup_stub().
Change-Id: I6a0a890e8b1c2408301564c22772032cfee4d296
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Implement x2apic mode as existing code only supports apic mode.
Use info from LAPIC_BASE_MSR (LAPIC_BASE_MSR_X2APIC_MODE) to check
if apic mode or x2apic mode and implement x2apic mode according to
x2apic specfication.
Reference:
https://software.intel.com/content/www/us/en/develop/download/intel-64-architecture-x2apic-specification.html
BUG=None
BRANCH=None
TEST=boot to OS and check apic mode
cat /proc/cpuinfo | grep "apicid"
ex) can see apicid bigger than 255
apicid : 256
apicid : 260
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I0bb729b0521fb9dc38b7981014755daeaf9ca817
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51723
Reviewed-by: Ravishankar Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This fixes an issue introduced in
commit ad0116c0327f575f0af184a2f4861848a49a0e2a
cpu/x86/smm_loaderv2: Remove unused variables
It removed one variable that was needed to set the SMM start address
that is used to set the SMM stack location.
Change-Id: Iddf9f204db54f0d97a90bb423b65db2f7625217f
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51721
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: If67bcbf0c8ffbd041e2e4cab8496f4634de26552
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Global variables are located in .bss and not on the CPU stack.
Overwriting them a per CPU case is bound to cause race conditions. In
this case it is even just plainly wrong.
Note: This variable is set up in the get_smm_info() function.
Change-Id: Iaef26fa996f7e30b6e4c4941683026b8a29a5fd1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The argument provided to the function was always the same as the one
computed inside the function so drop the argument.
Change-Id: I14abf400dce1bd9b03e401b6619a0500a650fa0e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The permanent handler module argument 'save_state_size' now holds the
meaning of the real save state size which is then substracted from the
CPUs save state 'top' to get the save state base.
TESTED with qemu Q35 on x86_64 where the stub size exceeds the AMD64
save state size.
Change-Id: I55d7611a17b6d0a39aee1c56318539232a9bb781
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Remove variables that are either constants or are just assigned but
not used.
Change-Id: I5d291a3464f30fc5d9f4b7233bde575010275973
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I6648d0710bc0ba71cfbaaf4db7a8c1f33bbc9b35
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
With the smm_module_loaderv2 the save state map is not linear so copy
a map from ramstage into the smihandler.
TESTED on QEMU q35: Both SMMLOADER V1 and V2 handle save states properly.
Change-Id: I31c57b59559ad4ee98500d83969424e5345881ee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50769
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Move out smm_create_map as this was not run if concurrent_save_states
is 1. The cpus struct array is used in the smm_get_cpu_smbase()
callback so it is necessary to create this.
TEST: run qemu/q35 with -smp 1 (or no -smp argument)
Change-Id: I07a98bbc9ff6dce548171ee6cd0c303db94087aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50783
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The parameters that the permanent handler requires are pushed directly
to the permanent handlers relocatable module params.
The paremeters that the relocation handler requires are not passed on
via arguments but are copied inside the ramstage. This is ok as the
relocation handler calls into ramstage.
Change-Id: Ice311d05e2eb0e95122312511d83683d7f0dee58
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
struct smm_loader_params is a struct that is passed around in the
ramstage code to set up either the relocation handler or the permanent
handler. At the moment no parameters in the stub 'smm_runtime' are
referenced so it can be dropped. The purpose is to drop the
smm_runtime struct from the stub as it is already located in the
permanent handler.
Change-Id: I09c1b649b5991f55b5ccf57f22e4a3ad4c9e4f03
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Keep a copy of start32_offset into ramstage to avoid needing to pass
arguments, calling from assembly. Doing this in C code is better than
assembly.
Change-Id: Iac04358e377026f45293bbee03e30d792df407fd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50765
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of passing on parameters from the stub to the permanent
handler, add them directly to the permanent handler.
The parameters in the stub will be removed in a later patch.
Change-Id: Ib3bde78dd9e0c02dd1d86e03665fa9c65e3d07eb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The data needed to compute the permanent smbase for a core, when
relocating, is present in the ramstage data which the stub located at
DEFAULT_SMBASE (0x30000) calls back to. There is no need to fetch this
from via the stub params.
Change-Id: I3894c39ec8cae3ecc46b469a0fdddcad2a8f26c4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50763
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is only consumed by the stub and not by the relocation handler or
the permanent handler, so move it out of the runtime struct.
Change-Id: I01ed0a412c23c8a82d88408be058a27e55d0dc4d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I15b433483c36cce04816e8895789997d91702484
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51530
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
These stub params need to be synced with the code in smm_stub.S and
are consumed by both the smmloader and smmloader_v2. So it is better
to have the definition located in one place.
Change-Id: Ide3e0cb6dea3359fa9ae660eab627499832817c9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50761
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since prog_locate() was eliminated, prog_rdev() only ever represents the
loaded program in memory now. Using the rdev API for this is unnecessary
if we know that the "device" is always just memory. This patch changes
it to be represented by a simple pointer and size. Since some code still
really wants this to be an rdev, introduce a prog_chain_rdev() helper to
translate back to that if necessary.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If7c0f1c5698fa0c326e23c553ea0fe928b25d202
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a helper function mp_run_on_all_aps, it allows running a given
func on all APs excluding the BSP, with an added provision to run
func in serial manner per AP.
BUG=b:169114674
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: I74ee8168eb6380e346590f2575350e0a6b73856e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51271
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Generated with a variant of
https://coccinelle.gitlabpages.inria.fr/website/rules/array.cocci
Change-Id: I083704fd48faeb6c67bba3367fbcfe554a9f7c66
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50594
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Also sort includes alphabetically.
Change-Id: I49615434b140601ce599b4a63aa42c82874bd0f7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44315
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is useful to know if MCU have been applied successfully.
On the start of MP init lines similar to:
"AP: slot 1 apic_id 1, MCU rev: 0x0700001d" will be printed.
The example is taken from the log of an ocp/deltalake.
Change-Id: Ia0a6428b41d07f87943f3aa7736b8cb457fdd15a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49840
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Link .init section near the end of bootblock program.
It contains _start16bit, gdtptr and gdt that must be
addressable from realmode, thus within top 64 KiB.
Change-Id: If7b9737650362ac7cd82685cfdfaf18bd2429238
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
It was confusing to have this defined while there was another
symbol bootblock_protected_mode_entry that was not really used
as an entry point.
Change-Id: I3da07ba9c0a9fc15b1515452adfb27f963659951
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48404
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib475f40f950f8cc54f0e3c50a80970ba3d2b628f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47969
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: If2caab67286cf77e37928e03be4f581070e771d8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47968
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I78ecd15716169b58cf6696ff8c5069ac2d5038ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47967
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I7a3a1b63c0ef14b1e24ecce2df66f7970e5eb669
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Unify the debug messages on raised SMIs.
Change-Id: I34eeb41d929bfb18730ac821a63bde95ef9a0b3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49248
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Writing 0 to MSR IA32_BIOS_SIGN_ID before fetching this MSRs content
is required. This is how things are done in
cpu/intel/microcode/microcode.c.
The "Intel® 64 and IA-32 Architectures Software Developer’s Manual"
also recommends this: "It is recommended that this field be preloaded
with 0 prior to executing CPUID" (this field being %edx).
Change-Id: I24a87aff9a699ed8ab2598007c8b8562d0555ac5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Change-Id: I712fca09b1618017412a3d91f81627ec876f2894
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
|
|
Change-Id: I7e7570ff6a4319a0cf583ae5b76e7c24f0241509
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
|
|
Fix C code to match comment and assembly implementation.
Tested on Prodrive hermes:
The microcode spinlock is no longer used.
Change-Id: I21441299f538783551d4d5ba2b2e7567e152d718
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49304
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change affects Intel CPUs only. As most platforms are doing
uCode update using FIT, they aren't affected by this code either.
Update microcode in MP-init using a single spinlock when running on
a Hyper-Threading enabled CPU on pre FIT platforms.
This will slow down the MP-init boot flow.
Intel SDM and various BWGs specify to use a semaphore to update
microcode on one thread per core on Hyper-Threading enabled CPUs.
Due to this complex code would be necessary to determine the core #ID,
initializing and picking the right semaphore out of CONFIG_MAX_CPUS / 2.
Instead use the existing global spinlock already present in MPinit code.
Assuming that only pre-FIT platforms with Hyper-Threading enabled and at
most 8 threads will ever run into this condition, the boot delay is
negligible.
This change is a counterproposal to the previous published patch series
being much more unsophisticated.
Change-Id: I27bf5177859c12e92d6ce7a2966c965d7262b472
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I9971069803a7cd1b9be0ac0cfa410b6e1fdc3eeb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Get rid of using eax and reload counter on race condition.
Change-Id: Ie4b9957d8aa1f272ff1db5caf2c69d1e1f086a03
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47714
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change uses append operation (+=) instead of assignment (:=) for
smm-c-deps to ensure that any earlier assignment is not
overwritten.
Change-Id: Ic1d62b414cfe3f61ee2b80b026b7338faa186904
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
All platforms moved to initialise GNVS at the time
of SMM module loading.
Change-Id: I31b5652a946b0d9bd1909ff8bde53b43e06e2cd9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48699
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I9d7417462830443f9c96273d2cc326cbcc3b17dd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48698
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Followup work forces gdtptr and gdt towards the top of
bootblock. They need to be realmode-addressable, i.e.
within top 64 KiB or same segment with .reset.
Change-Id: Ib6f23b2808d0a7e0d277d00a9b0f30c49fdefdd5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
We have identical gdtptr16 and gdtptr. The reference in
gdtptr_offset calculation is not accounted for when
considering --gc-sections, so to support linking
gdt_init.S separately add dummy use of gdtptr symbol.
Realmode execution already accessed gdt that was located
outside [_start16bit,_estart16bit] region. Remove latter
symbol as the former was not really a start of region,
but entry point symbol.
With the romcc bootblock solution, entry32.inc may have
been linked into romstage before, but the !ENV_BOOTBLOCK
case seems obsolete now.
Change-Id: I0a3f6aeb217ca4e38b936b8c9ec8b0b69732cbb9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Packing bootblock sections is somewhat easier to understand
when these all appear in one .ld file.
Change-Id: Ie8629a89fa47a28db63ecc33c631b29ac5a77448
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I4a4e988d38b548e1c88ffcc5f5ada2e91ff6ba91
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This adds a helper function for long mode to call some code in protected
mode and return back to long mode.
The primary use case is to run binaries that have been compiled for
protected mode, like the FSP or MRC binaries.
Tested on Intel Skylake. The FSP-M runs and returns without error while
coreboot runs in long mode.
Change-Id: I22af2d224b546c0be9e7295330b4b6602df106d6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I9288ede88f822ff78dd9cb91020451dc935203a0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
Adapt the old lapic init code for x86_64.
Change-Id: I5128ed574323025e927137870fb10b23d06bc01d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
On x86_64 the cannary is 8 bytes in size, so write the additional
4 bytes to make SMM handler happy.
Tested on Intel Skylake in long mode. No longer dies in SMM.
Change-Id: Id805c65717ec22f413803c21928d070602522b2c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48215
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The previous code was crashing when jumping back to ramstage, now it
works. The GDT is now using the same values as the other ones in
coreboot.
Change-Id: Id00467d9d8a4138ddea73adbda4b39f12def583f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48214
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Allows to compile the file under x86_64 without errors.
The caller has to make sure to call the functions while in protected
mode, which is usually the case in early bootblock.
Change-Id: Ic6601e2af57e0acc6474fc3a4297e3d2281decd6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48165
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Enter long mode on secondary APs.
Tested on Lenovo T410 with additional x86_64 patches.
Tested on HP Z220 with additional x86_64 patches.
Still boots on x86_32.
Change-Id: I53eae082123d1a12cfa97ead1d87d84db4a334c0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This partially reverts commit 67910db907fb3d5feacdbfaa40952a88f673795a.
The symbol X86_RESET_VECTOR continues to live, for the time being,
under soc/amd/picasso.
Change-Id: Ib6b2cc2b17133b3207758c72a54abe80fc6356b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I2b8c54fd3851d1c2a9f4c3c36828922067bec79f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47071
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Reusing the 'size' variable for a different purpose later on in the
function makes the code harder to read.
Change-Id: Iceb10aa40ad473b41b7da0310554725585e3c2c2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
If the stub size would be larger than the save state size, the stagger
points would overlap with the stub.
The check is placed in the stub placement code. The stub placement
code is called twice. Once for the initial SMM relocatation and for
the permanent handler in TSEG. So the check is done twice, which is
not really needed.
Change-Id: I253e1a7112cd8f7496cb1a826311f4dd5ccfc73a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47069
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently coreboot has limited use for the SMM save state. Typically
the only thing needed is to get or set a few registers and to know
which CPU triggered the SMI (typically via an IO write). Abstracting
away different SMM save states would allow to put some SMM
functionality like the SMMSTORE entry in common places.
To save place platforms can select different SMM save sate ops that
should be implemented. For instance AMD platforms don't need Intel SMM
save state handling.
Some platforms can encounter CPUs with different save states, which
the code then handles at runtime by comparing the SMM save state
revision which is located at the same offset for all SMM save state
types.
Change-Id: I4a31d05c09065543424a9010ac434dde0dfb5836
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44323
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The SMM_ASEG code only supports up to 4 CPUs, so assert this at
buildtime.
Change-Id: I8ec803cd1b76f17f4dccd5c573179d542d54c277
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The ASEG smihandler bails out if an unsupported SMM save state
revision is detected. Now we have code to find the SMM save state
depending on the SMM save state revision so reuse this to do the same.
This also increases the loglevel when bailing out of SMM due to
unsupported SMM save state revision from BIOS_DEBUG to BIOS_WARNING,
given that the system likely still boots but won't have a functioning
smihandler.
Change-Id: I57198f0c85c0f7a1fa363d3bd236c3d41b68d2f0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Fix compilation on x86_64.
Tested on HP Z220:
* Still boots on x86_32.
Change-Id: Id7190d24172803e40acaf1495ce20f3ea38016b0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44675
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This allows for ccopts symbols and preprocessor to be used inside the
smm.ld linker script.
Change-Id: I4262c09ca52c1fca43c1c115530efe489a722c32
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44321
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Clarify what the function does by renaming it from do_lapic_init() to
lapic_virtual_wire_mode_init().
Change-Id: Ie4430bf0f6c6bf0081b6aaeace351092bcf7f4ac
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The assembler is warning that the bts instruction is ambiguous, so use
the correct suffix btsl. See also commit 693315160e
(cpu/x86/sipi_vector.S: Use correct op suffix)
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I2eded0af1258e90926009544683b23961d99887b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Increase timeout for CPUs to check in after 2nd SIPI completion
from 10ms to 100ms.
Update logging level for mp init failure cases from BIOS_DEBUG
to BIOS_ERR.
Without this patch, "mp initialization failure" happens on some
reboots on DeltaLake server. As consequence, not all 52 cpus
come up in Linux:
[root@localhost ~]# lscpu
...
CPU(s): 40
Also following Hardware Errors are seen:
[ 4.365762] mce: [Hardware Error]: Machine check events logged
[ 4.366565] mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 9: ee2000000003110a
[ 4.367561] mce: [Hardware Error]: TSC 0 ADDR fe9e0000 MISC 228aa040101086
[ 4.368563] mce: [Hardware Error]: PROCESSOR 0:5065b TIME 948438164 SOCKET 0 APIC 0 microcode 700001d
With this patch, no such failure is observed with 370 reboots.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Iab10f116dd4af152c24d5d8f999928c038a5b208
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46898
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Integer handling issues:
Potentially overflowing expression "1 << size_msb" with type "int"
(32 bits, signed) is evaluated using 32-bit arithmetic, and then
used in a context that expects an expression of type "uint64_t"
(64 bits, unsigned).
Fixes: CID 1435825 and 1435826
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: If859521b44d9ec3ea744c751501b75d24e3b69e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46711
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On DeltaLake server, there are following entry in MTRR address space:
0x0000201000000000 - 0x0000201000400000 size 0x00400000 type 0
In this case, the base address (with 4k granularity) cannot be held in
uint32_t. This results incorrect MTRR register setup. As the consequence
UEFI forum FWTS reports following critical error:
Memory range 0x100000000 to 0x183fffffff (System RAM) has incorrect attribute Uncached.
Change appropriate variables' data type from uint32_t to uint64_t.
Add fls64() to find least significant bit set in a 64-bit word.
Add fms64() to find most significant bit set in a 64-bit word.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I41bc5befcc1374c838c91b9f7c5279ea76dd67c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|