This change adds sub-regions to SI_ME in chromeos.fmd. These are
required to support stitching of CSE components.
BUG=b:189177538
Change-Id: Ife48aafcec43555175aad44f8b6307beeaea9184
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58592
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Since all x86 CPUs in tree have MTRR support, there is no need to guard
the DISPLAY_MTRRS option with HAVE_DISPLAY_MTRRS. Also all x86 CPUs/SoCs
have a display_mtrrs call at least somewhere in their code, so selecting
the DISPLAY_MTRRS option will always have an effect. All SoCs that don't
select RESET_VECTOR_IN_RAM have the postcar stage where it gets called.
The two AMD SoCs that select RESET_VECTOR_IN_RAM use the FSP2 driver
which contains plenty of display_mtrrs calls.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2894689ce58e7404d9d5a894f3c288bc4016ea19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51575
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
All x86 CPUs in the coreboot tree have a local APIC, so the
corresponding code can be unconditionally included in the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifc354fb386977b0fca4caa72c03aa77a20bc348e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The Intel Quark SoC does have a LAPIC on its x86 CPU core, so we should
select CPU_X86_LAPIC. This will additionally include the Makefile from
cpu/x86/lapic. Since none of AP_IN_SIPI_WAIT, LEGACY_SMP_INIT and
UDELAY_LAPIC gets selected, only the boot_cpu.c and lapic.c targets will
be added to the build. Since SMP isn't set, adding the boot_cpu.c target
won't change the resulting binary of a timeless build, since the only
function inside will be removed by the compiler's pre-processor in the
!SMP case. So the only thing that will change the resulting binary is
the addition of the lapic.c target. From this target only the function
cpu_get_lapic_addr will be used which overrides the weak implementation
in acpi/acpi.c. The call in arch/x86/mpspec.c can be ignored, since
GENERATE_MP_TABLE isn't selected. So this change will result in the
LAPIC address in the MADT being changed from 0 to to LAPIC_DEFAULT_BASE.
Since the documentation of the Quark SoC mentions that it has a LAPIC on
its one x86 core, this should work.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2f163bd608f0548abb0e8de90843d2a796b8ef6c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Half of the AMD PCI device ID definitions were below the ATI vendor ID,
so move those below the AMD PCI vendor ID definition. The entries are
kept in the order they were before and added before the existing AMD
device ID definitions below the AMD vendor ID definition.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I34ffdc49884737541b8653bebf023a68050375d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The definitions isn't used in either spelling.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6faea2b9c89f0bd3c164a6dc76fac5ea712d313
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Initialize the pad_cfg_lock_offset field for the various gpio
pad_community structures in the adl_communities.
BUG=b:201430600
TEST='emerge-brya coreboot' and verify it compiles successfully.
Change-Id: I2cd3e43a84b0140bb2aeae5de1e299db714d419b
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Update api name and comments to be more generic as spi destination
id is not DMI specific.
Update api name as soc_get_spi_psf_destination_id and comments.
And move PSF definition from pcr_ids.h as it's not pcr id.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ie338d05649d23bddae5355dc6ce8440dfb183073
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Since all multi-core x86 CPUs need to have LAPICs, this option should be
selected for soc/example/min86.
TEST=The example/min86 mainboard still builds.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5aa6e850f0b4dca27309385ba889b04335fe4f0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58549
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
With using a Kconfig option to add the x86 LAPIC support code to the
build, there's no need for adding the corresponding directory to subdirs
in the CPU/SoC Makefile. Comparing which CPU/SoC Makefiles added
(cpu/)x86/mtrr and (cpu/)x86/lapic before this and the corresponding
MTRR code selection patch and having verified that all platforms
added the MTRR code on that patch shows that soc/example/min86 and
soc/intel/quark are the only platforms that don't end up selecting the
LAPIC code. So for now the default value of CPU_X86_LAPIC is chosen as y
which gets overridden to n in the Kconfig of the two SoCs mentioned
above.
Change-Id: I6f683ea7ba92c91117017ebc6ad063ec54902b0a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The code for these CPU models isn't present in coreboot. These lines
have been commented-out since they where added, so drop them.
Change-Id: I8fc53fea4225217bc5bb70d839c280ebb64fd3a6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Move the selection of CPU_X86_CACHE_HELPER to the Kconfig file of the
CPU models which call the x86_enable_cache function that gets added to
the build by selecting this option.
Change-Id: Ie75682f5d20a79fc2f3aab9b8a2c3ccf79d1ad5c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
There's no need to have an overridetree with a single board variant.
TEST=Compare static.c and observe only device order has changed.
Change-Id: I2097e247c27d5d0c5479cb533b477cd490a4c827
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There's no need for relative paths with Kconfig options.
Change-Id: Ib9b9b29a158c34a30480aaabf6d0b23819d28427
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Some CPUs don't use the ramstage-only x86_enable_cache helper function
to call enable_cache with some added port 0x80 and console output.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: Ia44c7b150cd12d76e463903966f67d86750cbdd9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
No SoC uses the ramstage-only x86_enable_cache helper function to call
enable_cache with some added port 0x80 and console output.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I7c5039e1341fd4089078ad7ffb2fe6584a94045c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This change is required as part of HECI Interface initialization in order
to put the host and CSE into a known good state for communication. Please
refer ME BIOS specification for more details. The change adds HECI
interface reset flow in the CSE driver. It enables coreboot to send HECI
commands before DRAM Init.
BUG=b:175516533
TEST=Run 50 cold reset cycles on Brya
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: Ie078beaa33c6a35ae8f5f460d4354766aa710fba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
MBP Hob is being generated by FSP after getting data from ME.
coreboot does not consume this HOB and FSP provides an option
for bootloader to skip generation of MBP HOB. This will help in
saving ~14 ms of boot time.
Here is the data from Brya P1 Board:
Before: 955 returning from FspSiliconInit 879,432 (99,156)
After: 955 returning from FspSiliconInit 1,177,513 (84,506)
BUG=b:188577893
BRANCH=None
TEST=No functional impact on Brya system and boot time is reduced
with this patch.
Change-Id: Ibb64e4d0f4ae7212defb6704b05a78e754f75cd7
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58289
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
turn off WLAN ASPM L1.1/L1.2 as a short-term w/a for WLAN AP probe failure.
BUG=b:198258604
BRANCH=guybrush
TEST=emerge-guybrush coreboot chromeos-bootimage
AP is able to be probed by wlan module
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Change-Id: Ic7be523626b0ff6e4b1c66ba6af13b15061ef4cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Use the verstage_x86 class for the spi_dma.c target instead of using the
verstage class and guarding it with !VBOOT_STARTS_BEFORE_BOOTBLOCK.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9b8cafd1ef17df8c485f6594bc0928cea88e436b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since cpu/x86/Makefile.inc already adds the pae sub-directory, there is
no need to include it in the Makefile of a CPU or SoC, so remove it from
those Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I78368f7eb880fb64f511a2fa8c8acde222d0dca3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All x86-based CPUs and SoCs in the coreboot tree end up including the
Makefile in cpu/x86/mtrr, so include this directly in the Makefile in
cpu/x86 to add it for all x86 CPUs/SoCs. In the unlikely case that a new
x86 CPU/SoC will be added, a CPU_X86_MTRR Kconfig option that is
selected be default could be added and the new CPU/SoC without MTRR
support can override this option that then will be used in the Makefile
to guard adding the Makefile from the cpu/x86/mtrr sub-directory.
In cpu/intel all models except model 2065X and 206AX are selcted by a
socket and rely on the socket's Makefile.inc to add x86/mtrr to the
subdirs, so those models don't add x86/mtrr themselves. The Intel
Broadwell SoC selects CPU_INTEL_HASWELL and which added x86/mtrr to the
subdirs. The Intel Xeon SP SoC directory contains two sub-folders for
different versions or generations which both add x86/mtrr to the subdirs
in their Makefiles.
Change-Id: I743eaac99a85a5c712241ba48a320243c5a51f76
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch fixes regression introduced by commit bee4bb5f0
(soc/intel/common/cse: Late sending EOP msg if !HECI_DISABLE_USING_SMM)
FAFT test case fail when doing `firmware_DevMode` test.
If CSE is already hidden then accessing CSE registers would be wrong
and will receive junk, hence, return as CSE is already disabled.
BUG=b:203061531
TEST=Brya system can boot to OS with recovery mode.
Change-Id: I2046eb19716c397a066c2c41e1b027a256bd6cf9
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There are manual timeout-loops which use a fixed value and udelay().
In all cases there is a debug printk() inside this loop which, when
enabled, takes way longer than the counted microsecond delay. This
leads to the result that e.g. a 1 second delay takes nearly an eternity
if the debug messages are enabled due to the longer function execution
time.
This patch uses the stopwatch scheme for the timeout-loops which still
makes sure that the timeout period is maintained while it takes longer
function calls like printk() into account. In order to keep the minimum
delay between two register accesses on the TPM keep the udelay(1)-call.
TEST=Enable TPM debug messages on a board where the TPM hits a timeout
by failure and make sure that the debug messages occur in the log
just in the timeout period. It still works as expected if the debug
messages are disabled.
Change-Id: I8fd261c9d60a9a60509c847dbc4983bc05f41d48
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58240
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>
This CL adds a python test for elogtool.
It tests the basic functionality of elogtool: list, clear and add.
A future CL will include more complex tests.
BUG=b:172210863
TEST=pytest elogtool_test.py
Change-Id: If1241ad070d1c690c84f5ca61c0487ba27c2a287
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The commit 04a40379b has a wrongly written variable, which sets an
IOAPIC register to a wrong value and makes the Linux kernel unable to
boot.
Tested on HP EliteBook 2760p, the kernel boots after this patch.
Change-Id: Ifda7bb61a431dbf9c2df2f738aa806dd6d8097b8
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
After adding code to handle the case of missing the link/bus on the CPU
cluster device in mp_cpu_bus_init, there's no need to have the LAPIC
device in the devicetree any more.
TEST=Mandolin still boots successfully.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icfc4fb61b373129f3bf4f4de09c38076a8f66733
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
After adding the functionality to add a bus/link on the CPU cluster
device in mp_cpu_bus_init if it is missing due to no LAPIC device being
present in the devicetree below the CPU cluster device, we can use
mp_cpu_bus_init as init function in cpu_bus_ops and implement
mp_init_cpus.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I76aebeca1b3227cfd310b6c45f506c042b35ae04
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
When a chipset or mainboard devicetree doesn't have any LAPIC devices in
its CPU cluster, not only the LAPIC device, but also the link/bus
between the CPU cluster device and the LAPIC devices will be missing and
the CPU cluster's dev->link_list will be NULL. This patch handles this
case in the common code like
commit 3c0ecd57c1 (soc/intel/common/cpu:
Handle non-zero BSP APIC ID in init_cpus) and
commit ba936ce5db (soc/intel/denverton_ns:
Ensure CPU device has a valid link) already did in the common Intel SoC
and the Denverton code. With this change all CPUs and SoC that use the
common mp_cpu_bus_init as init function in the CPU cluster's device
operations struct won't require having at least one LAPIC device in the
chipset or mainboard device tree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib0d85de5cafb6390b8fbd512186899d6a815e972
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since PSE devices could be initialized as either host owned
(PCI devices) or PSE owned (will be hidden from coreboot and
only visible to PSE interface), add all PSE devices in PCI
list header file for future usage.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Iaa40cdcb021d05e50504dd85f94e9c021e284d00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58466
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For coreboot proper, I/O APIC programming is not really required,
except for the APIC ID field. We generally do not guard the related
set_ioapic_id() or setup_ioapic() calls with CONFIG(IOAPIC).
In practice it's something one cannot leave unselected, but maintain
the Kconfig for the time being.
Change-Id: I6e83efafcf6e81d1dfd433fab1e89024d984cc1f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
For SMP operation IOAPIC needs to be configured.
For a build with MAX_CPUS=1 emulation might still decode
the IOAPIC MMIO window, it does not really matter to have
it always reserved.
Change-Id: Ia340fc418cd9ceda56a2a10972e130d9f289c589
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This adds delivery of PIC/i8259 interrupts via ExtNMI on the
affected platfoms.
Change-Id: If99e321fd9b153101d71e1b995b43dba48d8763f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Remove the test for count=0 that leaked from drivers/generic/ioapic
implementation. See commit ea2fb8d80 and commit 8cc25d229.
Change-Id: I26944b930851fbea160c844ea46e2faa61c9af8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The number of redirection table entries (aka interrupt vectors) inside
an I/O APIC may depend of the SKU, with the related register being of
type read/write-once. Provide support utilities to either lock or set
this registers value.
Change-Id: I8da869ba390dd821b43032e4ccbc9291c39e6bab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Implement mp_init_cpus and use mp_cpu_bus_init as init function in
cpu_bus_ops.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2adcb1e1d79ced804925c81095cc5c0c2e6f9948
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Implement mp_init_cpus and use mp_cpu_bus_init as init function in
cpu_bus_ops.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I057ae8d95bdc510e9e7afb144b692531107fa45d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Each CPU/SoC checks the return value of the mp_init_with_smm and prints
the same error message if it wasn't successful, so move this check and
printk to mp_init_with_smm. For this the original mp_init_with_smm
function gets renamed to do_mp_init_with_smm and a new mp_init_with_smm
function is created which then calls do_mp_init_with_smm, prints the
error if it didn't return CB_SUCCESS and passes the return value of
do_mp_init_with_smm to its caller.
Since no CPU/SoC code handles a mp_init_with_smm failure apart from
printing a message, also add a comment at the mp_init_with_smm call
sites that the code might want to handle a failure.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I181602723c204f3e43eb43302921adf7a88c81ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Furquan Shaikh