This board use the LEGACY_SMP_INIT which is to be deprecated after
release 4.18.
Change-Id: Idf37ade31ddb55697df1a65062c092a0a485e175
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69114
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The patch fixes the typecasting issue, that is conversion from 'int' to
'unsigned long long int'. This changes value from '0x8000 0000' to
'0xFFFF FFFF 8000 0000'.
During unit testing, the argument is getting changed to an unexpected
number which is resulting to an exception when IA32_HWP_REQUEST MSR is
updated. In this update, the MSR's reserved bits are getting updated, so
this causes exception.
TEST= Verified the code on the Gimble.
No exception is seen after the fix.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I35d382c792b9df260381b7696f3bbff43d6c4dc2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for Haswell.
Currently BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is selected for
CPU_INTEL_HASWELL (see [2]). However, there seems to be no
particular reason on those platforms. Flashconsole works on Broadwell,
at least, and it writes to flash as early as bootblock. Therefore,
remove BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES, so that VBOOT_VBNV_FLASH
can be enabled.
[1] https://issuetracker.google.com/issues/235293589
[2] commit 6c2568f4f5 (CB:45740)
drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config
BUG=b:235293589
TEST=./util/abuild/abuild -t LENOVO_THINKPAD_T440P -a (with VBOOT)
Change-Id: If1430ffd6115a0bc151cbe0632cda7fc5f6c26a6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
use is_enabled_cpu() on cycles over device list to check
whether the current device is enabled cpu.
TEST: compile test and qemu run successfully with coreinfo
payload
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The µcode updates for Broadwell come from coreboot's blobs submodule
and have not been updated in at least 7 years. Use the µcode updates
available in the intel-microcode submodule. This change forgoes some
µcode updates for old Broadwell ULT/ULX steppings with CPUID 0x306d2
and 0x306d3, as well as an old µcode update for Haswell ULT/ULX CPUs
with CPUID 0x40651 in favor of a newer intel-microcode revision that
was already being used: when the µcode updates are concatenated into
one file, the newer µcode update revision would be placed before the
older revision, so the latter would never be used.
Change-Id: I67f8a58552bd211095c183e6f7a219d60e3be162
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 27126f135d (cpu/intel/haswell: add
Crystal Well CPU IDs) introduced new Haswell CPUIDs but did not include
any µcode updates for them. It is unknown how this could have worked as
the initial µcode inside the CPU can be quite unstable. Intel CPUs with
support for FIT (Firmware Interface Table) can have their µcode updated
before the x86 reset vector is executed.
The µcode updates for Crystal Well CPUID 0x40661 can be found inside the
intel-microcode submodule. There are no publicly available µcode updates
for Crystal Well CPUID 0x40660 as it is a pre-production stepping, which
is not meant to be used anymore. Hook up the available µcode updates for
Crystal Well CPUs.
Change-Id: If5264f333e681171a2ca4a68be155ffd40a1043b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
There are two types of Haswell/Broadwell platforms: Trad(itional) with
separate CPU and PCH packages, and ULT/ULX where the CPU and PCH share
one package. Mainboards can specify which platform type they are using
the `INTEL_LYNXPOINT_LP` Kconfig option. There are so many differences
between Trad and ULT/ULX that it's not worth doing runtime detection.
The CPUIDs are different for Trad and ULT/ULX platforms, and so are the
µcode updates. So, including Trad µcode updates in a coreboot image for
an ULT/ULX mainboard makes no sense, and vice versa.
Adapt the Makefile so that only relevant µcode updates are added. Also,
add a few comments to indicate which updates correspond to which CPUs.
TEST=Run binwalk on coreboot.rom to verify included µcode updates for:
- Asrock B85M Pro4 (Haswell Trad)
- HP Folio 9480M (Haswell ULT/ULX)
- Purism Librem BDW (Broadwell ULT/ULX)
Change-Id: I6dc9e94ce9fede15cbcbe6be577c48c197a9212a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Haswell and Broadwell platforms usually stitch six microcode
patches. It has worked so far with the default value of four thanks a
bug which is being fixed by `util/ifittool: Error out if microcodes do
not fit the FIT table' commit.
BUG=b:245380705
TEST=Jenkins build without failing on the FIT table size
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I23bf79a3e8918499f6c51e6ef829312d5872181a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This moves the die() statement to a common place.
Change-Id: I24c9f00bfee169b4ca57b469c089188ec62ddada
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65812
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch changes the serial message type to BIOS_WARNING as sometimes
it may raise a wrong signal when microcode resides inside other part
of the IFWI instead /CBFS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I714bf74a91c2d783982c5e5ca76a70deed872473
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65316
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an error msg if intel_microcode_find() is unable to
find a microcode for the CPU SKU.
TEST=Able to see the error msg in coreboot serial log in case packed
with wrong microcode binary.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib4865575a44d2c8c6c3a20c2823a546d8f261e52
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65285
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the microcode loading and reloading API with a
helper function that perform the actual MSR write operation after
taking the microcode pointer from the caller function.
Also, convert the microcode loading failure msg type from `BIOS_INFO`
to `BIOS_ERR` to catch the error in proper.
TEST=Able to perform microcode loading on google/kano.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9a7cdc2d2c9211f1e0c7921015126f7a1be87761
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65249
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces a newer API to reload the microcode patch when
SoC selects RELOAD_MICROCODE_PATCH config.
Expected to call this API being independent of CPU MP Init regular
flow hence, doesn't regress the boot time.
BUG=b:233199592
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: If480e44b88d04e5cb25d7104961b70f7be041a23
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65156
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Prior commit hash 0310d34c2 (cpu/intel/microcode: Have provision to
re-load microcode patch) introduces an option to reload the microcode
based on SoC selecting RELOAD_MICROCODE_PATCH config.
This patch might potentially introduce a boot time regression (~30ms)
when RELOAD_MICROCODE_PATCH kconfig is enabled as all cores might end up
reloading the microcode without the proper need.
Note: RELOAD_MICROCODE_PATCH kconfig is not yet selected by any SoC
hence, it doesn't impact any coreboot project.
The idea is reloading microcode depends on specific use case
(for example: Skip FSP doing MP Init from Alder Lake onwards) hence,
a follow up patch will create a newer API to allow reloading of
microcode when RELOAD_MICROCODE_PATCH config is enabled.
BUG=b:233199592
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie320153d25cefe153fc8a67db447384f1f20f31f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
It might be possible to have this used for more than x86, but that
will be for a later commit.
Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch provides an option to reload the microcode patch a.k.a
second microcode patch if SoC selects the required
RELOAD_MICROCODE_PATCH config.
There is a new feature requirement starting with ADL to re-load the
microcode patch as per new Mcheck initialization flow.
BUG=b:233199592
TEST=Build and boot google/taeko to ChromeOS. Able to re-load
microcode patch as below:
[INFO ] microcode: Re-load microcode patch
[INFO ] microcode: updated to revision 0x41b date=2022-03-08
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0a3c29b3c25fccd31280a2a5a8d4fb22a6cf53bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64833
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Starting from Intel Pentium 4, cpus featured SSE2.
This will be used in the follow-up patches to determine whether to use
mfence as this instruction was introduced with the SSE2 feature set.
Change-Id: I8ce37d855cf84a9fb9fe9e18d77b0c19be261407
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The Intel Firmware Interface Table (FIT) is a bit of an annoying outlier
among CBFS files because it gets manipulated by a separate utility
(ifittool) after cbfstool has already added it to the image. This will
break file hashes created for CBFS verification.
This is not actually a problem when booting, since coreboot never
actually loads the FIT from CBFS -- instead, it's only in the image for
use by platform-specific mechanisms that run before coreboot's
bootblock. But having an invalid file hash in the CBFS image is
confusing when you want to verify that the image is correctly built for
verification.
This patch adds a new CBFS file type "intel_fit" which is only used for
the intel_fit (and intel_fit_ts, if applicable) file containing the FIT.
cbfstool will avoid generating and verifying file hashes for this type,
like it already does for the "bootblock" and "cbfs header" types. (Note
that this means that any attempt to use the CBFS API to actually access
this file from coreboot will result in a verification error when CBFS
verification is enabled.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1c1bb6dab0c9ccc6e78529758a42ad3194cd130c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The postcar frame can now be a local variable to that function.
Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Looks like the `set_power_limits()` declaration is copy-pasta leftovers
from `cpu/intel/model_206ax`. As it's unused, get rid of it.
Change-Id: I81704e883e52fea42488f52be116b6fcc2c6af4b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The lowest bound for L2 cache size on Socket P is 512 KiB.
This allows the use of cbfs mcache on all platforms.
This fixes building when some debug options are enabled.
Change-Id: I0d6f7f9151ecd4c9fbbba4ed033dfda8724b6772
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There is plenty of cache available to increase DCACHE_RAM_SIZE to
allow the use of cbfs mcache.
Tested on Gigabyte GA-D510UD, still boots and resumes.
Change-Id: I1487ba9decd3aa22424a3ac111de7fbdb867d38d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
<arch/cpu.h> is chain included through <cpu/cpu.h>.
Change-Id: I54a837394f67ac2a759907c7212ab947d07338dc
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <martinroth@google.com>
When rebuilding coreboot the empty fit table added to added to CBFS
stays the same so the build process sees no reason to update the file.
In the meantime ifittool did update that file for instance to add
microcode update entries. So each time coreboot is rebuilt the entries
are appended to the FIT table which runs out of space at some point.
One way to deal with this is to clear the fit table when setting the
pointer inside the bootblock.
TESTED: Now running 'make' again on prodrive/hermes does not report an
error with a filled FIT table.
Change-Id: Ia20a489dc90a4ae704e9ee6d532766899f83ffcc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63036
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Correct some Quickpath initialisation steps according to findings from
two different Intel reference code binaries as well as MCHBAR register
dump comparisons between vendor firmware and coreboot.
The MSR_TURBO_POWER_CURRENT_LIMIT information comes from EDK2 sources.
Tested on Apple iMac 10,1 (Clarkdale, aka desktop Ironlake), QPI init
now completes successfully instead of causing hangs before raminit.
Also tested on HP ProBook 6550b (Arrandale, aka mobile Ironlake), still
reaches payload (e.g. TianoCore).
Change-Id: Icd0139aa588dc8d948c03132b5c86866d90f3231
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
Leftover from using UDELAY_LAPIC on these platforms.
Change-Id: I718050925f3eb32448fd08e76d259f0fb082d2d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Allow deciding whether to enable VMX through a function parameter. Used
in a follow-up.
Change-Id: I4f932de53207cd4e24cb4c67d20c60f708bfaa89
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
It was only evaluated on LEGACY_SMP_INIT path while model_106cx
has used PARALLEL_MP for a long time.
Change-Id: I90ce838f1041d55a7c77ca80e563e413ef3ff88d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This file is using cpuid_result and cpuid(). I also removed the spinlock
header since it's not used. This is what was previously providing the
cpu.h header.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Idc3daa64562c4a4d57b678f13726509b480ba050
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.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>
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>
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 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>
