This change provides hooks for the SoC so it can perform any
initialization and cleanup in the SMM handler.
For example, if we have a UART enabled firmware with DEBUG_SMI, the UART
controller could have been powered off by the OS. In this case we need
to power on the UART when entering SMM, and then power it off before we
exit. If the OS had the UART enabled when entering SMM, we should
snapshot the UART register state, and restore it on exit. Otherwise we
risk clearing some interrupt enable bits.
BUG=b:221231786, b:217968734
TEST=Build test guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I946619cd62a974a98c575a92943b43ea639fc329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change will allow the SMI handler to write to the cbmem console
buffer. Normally SMIs can only be debugged using some kind of serial
port (UART). By storing the SMI logs into cbmem we can debug SMIs using
`cbmem -1`. Now that these logs are available to the OS we could also
verify there were no errors in the SMI handler.
Since SMM can write to all of DRAM, we can't trust any pointers
provided by cbmem after the OS has booted. For this reason we store the
cbmem console pointer as part of the SMM runtime parameters. The cbmem
console is implemented as a circular buffer so it will never write
outside of this area.
BUG=b:221231786
TEST=Boot non-serial FW with DEBUG_SMI and verified SMI messages are
visible when running `cbmem -1`. Perform a suspend/resume cycle and
verify new SMI events are written to the cbmem console log.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia1e310a12ca2f54210ccfaee58807cb808cfff79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This reverts commit ceaf959678.
The AMD Picasso SoC doesn't support x2APIC and neither advertises the
presence of its support via bit 21 in EAX of CPUID leaf 1 nor has the
bit 10 in the APIC base address MSR 0x1b set, but it does have 0xd CPUID
leaves, so just checking for the presence of that CPUID leaf isn't
sufficient to be sure that EDX of the CPUID leaf 0xb will contain a
valid APIC ID.
In the case of Picasso EDX of the CPUID leaf 0xb returns 0 for all cores
which causes coreboot to get stuck somewhere at the end of MP init.
I'm not 100% sure if we should additionally check bit 21 in EAX of CPUID
function 1 is set instead of adding back the is_x2apic_mode check.
TEST=Mandolin with a Picasso SoC boots again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If1e3c55ce2d048b14c08e06bb79810179a87993d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Implementation for setup_lapic() did two things -- call
enable_lapic() and virtual_wire_mode_init().
In PARALLEL_MP case enable_lapic() was redundant as it
was already executed prior to initialize_cpu() call.
For the !PARALLEL_MP case enable_lapic() is added to
AP CPUs.
Change-Id: I5caf94315776a499e9cf8f007251b61f51292dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The options X2APIC_ONLY and X2APIC_RUNTIME were already user-visible
choices in menuconfig, but the functionality was not actually provided
except for platforms where FSP presumably enabled X2APIC.
Add the logic and related logging for switching to X2APIC operation.
TEST: qemu-system-x86_64 -M Q35 -accel kvm -bios coreboot.rom -serial
stdio -smp 2
PARALLEL_MP, and either X2APIC_ONLY or X2APIC_RUNTIME, need to be
selected for the build of emulation/qemu-q35.
Change-Id: I19a990ba287d21ccddaa64601923f1c4830e95e9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Selecting CPU_X86_CACHE_HELPER only added the x86_enable_cache wrapper
function around enable_cache which additionally wrote a POST code to
port 0x80 and printed a message to the console. This function was only
called during multi-processor initialization in ramstage via the init
function pointer in the CPU's device operations struct and was run on
all cores, so the message on the console was printed once per CPU core.
This patch replaces all x86_enable_cache calls by calls to enable_cache
and removes the wrapper function and the Kconfig symbol
CPU_X86_CACHE_HELPER which was used to only add this when the
corresponding CPUs used the x86_enable_cache wrapper function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I5866b6bf014821ff9e3a48052a5eaf69319b003a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58579
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using cb_err as return type of mp_run_on_aps, mp_run_on_all_aps,
mp_run_on_all_cpus and mp_park_aps clarifies the meaning of the
different return values. This patch also adds the types.h include that
provides the definition of the cb_err enum and checks the return value
of all 4 functions listed above against the enum values instead of
either checking if it's non-zero or less than zero to handle the error
case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4b3f03415a041d3ec9cd0e102980e53868b004b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Using cb_err as return type clarifies the meaning of the different
return values. This patch also adds the types.h include that provides
the definition of the cb_err enum and checks the return value of
mp_init_with_smm against the enum values instead of either checking if
it's non-zero or less than zero to handle the error case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibcd4a9a63cc87fe176ba885ced0f00832587d492
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Remove code, which was only needed for B and C2 stepping
of P54C. The linux kernel source has commentary on X86_BUG_11AP:
* See if we have a good local APIC by checking for buggy Pentia,
* i.e. all B steppings and the C2 stepping of P54C when using their
* integrated APIC (see 11AP erratum in "Pentium Processor
* Specification Update")
Change-Id: Iec10335f603674bcef2e7494831cf11200795d38
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There is currently a fundamental flaw in the current cpu_info()
implementation. It assumes that current stack is CONFIG_STACK_SIZE
aligned. This assumption breaks down when performing SMM relocation.
The first step in performing SMM relocation is changing the SMBASE. This
is accomplished by installing the smmstub at 0x00038000, which is the
default SMM entry point. The stub is configured to set up a new stack
with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point
of smm_do_relocation located in RAMSTAGE RAM.
This means that when smm_do_relocation is executed, it is running in SMM
with a different sized stack. When cpu_info() gets called it will be
using CONFIG_STACK_SIZE to calculate the location of the cpu_info
struct. This results in reading random memory. Since cpu_info() has to
run in multiple environments, we can't use a compile time constant to
locate the cpu_info struct.
This CL introduces a new way of locating cpu_info. It uses a per-cpu
segment descriptor that points to a per-cpu segment that is allocated on
the stack. By using a segment descriptor to point to the per-cpu data,
we no longer need to calculate the location of the cpu_info struct. This
has the following advantages:
* Stacks no longer need to be CONFIG_STACK_SIZE aligned.
* Accessing an unconfigured segment will result in an exception. This
ensures no one can call cpu_info() from an unsupported environment.
* Segment selectors are cleared when entering SMM and restored when
leaving SMM.
* There is a 1:1 mapping between cpu and cpu_info. When using
COOP_MULTITASKING, a new cpu_info is currently allocated at the top of
each thread's stack. This no longer needs to happen.
This CL guards most of the code with CONFIG(CPU_INFO_V2). I did this so
reviewers can feel more comfortable knowing most of the CL is a no-op. I
would eventually like to remove most of the guards though.
This CL does not touch the LEGACY_SMP_INIT code path. I don't have any
way of testing it.
The %gs segment was chosen over the %fs segment because it's what the
linux kernel uses for per-cpu data in x86_64 mode.
BUG=b:194391185, b:179699789
TEST=Boot guybrush with CPU_INFO_V2 and verify BSP and APs have correct
%gs segment. Verify cpu_info looks sane. Verify booting to the OS
works correctly with COOP_MULTITASKING enabled.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I79dce9597cb784acb39a96897fb3c2f2973bfd98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Alder Lake onwards IA SoC to select CAR_HAS_L3_PROTECTED_WAYS from SoC
Kconfig and here is modified flow as below:
Add new MSR 0xc85 IA32_L3_PROTECTED_WAYS
Update eNEM init flow:
- Set MSR 0xC85 L3_Protected_ways = (1 << data ways) - 1
Update eNEM teardown flow:
- Set MSR 0xC85 L3_Protected_ways = 0x00000
BUG=b:168820083
TEST=Verified filling up the entire cache with memcpy at the beginning
itself and then running the entire bootblock, verstage, debug FSP-M
without running into any issue. This proves that code caching and
eviction is working as expected in eNEM mode.
Change-Id: Idb5a9ec74c50bda371c30e13aeadbb4326887fd6
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
As per TGL EDS, two ways will be controlled with one bit of SF QoS
register hence, this patch introduces SF_MASK_2WAYS_PER_BIT Kconfig to
allow SoC users to select SF_MASK_2WAYS_PER_BIT to follow the EDS
recommendation.
Calculate SF masks 2:
1. if CONFIG_SF_MASK_2WAYS_PER_BIT:
a. data_ways = data_ways / 2
Also, program SF Mask#2 using below logic:
2. Set SF_MASK_2 = (1 << data_ways) - 1
Change-Id: I442bed75f13d26f357cfb32c54c5fe9efa4b474b
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move post_codes.h from include/console to
commonlib/include/commonlib/console.
This is because post_codes.h is needed by code from util/
(util/ code in different commit).
Also, it sorts the #include statements in the files that were
modified.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ie48c4b1d01474237d007c47832613cf1d4a86ae1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56403
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes all local `CPUID_` macros from SoC directories and
creates a common cpu_ids.h inside include/cpu/intel/cpu_ids.h. SoC
users are expected to add any new CPUID support into cpu_ids.h and
include 'cpu/intel/cpu_ids.h' into respective files that look for
`CPUID_` macro.
Note: CPUIDs for HSW, BDW and Quark are still inside the respective
directory.
Change-Id: Id88e038c5d8b1ae077c822554582410de6f4a7ca
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
Those registers are architectural MSR and this also gets them in line
with IA32_MC0_CTL and IA32_MC0_STATUS. Also move them below the
definitions for IA32_MC0_STATUS, so that the numbers of the MSRs are
ascending.
Change-Id: Icef6526c896720248f5b648ddf1a271bdf46917c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56235
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In multiple locations within the coreboot tree the IA32_MCG_CAP MSR gets
read and masked with MCA_BANKS_MASK to get the number of available MCA
banks on the CPU, so add this to the common code to avoid duplication
of code.
Change-Id: Id118a900edbe1f67aabcd109d2654c167b6345ea
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Bootguard sets up CAR/NEM on its own so the only thing needed is to
find free MTRRs for our own CAR region and clear that area to fill in
cache lines.
TESTED on prodrive/hermes with bootguard enabled.
Change-Id: Ifac5267f8f4b820a61519fb4a497e2ce7075cc40
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.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>
