Change a86d1b8 (soc/intel/common: Add SMM common code for Intel
Platforms) moved APL to use common SMM code. However, smi.c and smm.h
files under soc/intel/apollolake/ were not removed. This change
removes the dead files since they are not used anymore.
BUG=b:110836465
Change-Id: I1ff213372521fd47e2335de6a4b438d16c74ecd3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Call to pmc_disable_all_gpe is required before enabling SMIs to ensure
that we do not end up in a recursive SMI handler loop as mentioned in
change 74145f7 (intel/common/pmc: Disable all GPEs during
pmc_init). Thus, this call was added at the end of
pmc_fill_power_state as we want to ensure that all the GPE registers
are backed up before being cleared for identifying the wake source in
ramstage.
This resulted in a side-effect on APL where pmc_fixup_power_state was
called much later in the boot process. Even though we have got rid of
pmc_fixup_power_state, this change moves the call to
pmc_disable_all_gpe to happen just before enabling SMIs. This helps to
keep the disabling of GPEs logically before the enabling of SMIs and
any clean ups that happen in pmc or soc-specific code should not
affect the state of GPEs.
BUG=b:110836465
TEST=Verified that wake sources are correctly identified on KBL and
APL. Also, no SMI handler issues observed when resuming.
Change-Id: I122a8118edcec117f25beee71a23c0a44ae862ed
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that APL does not need pmc_fixup_power_state, this function can be
removed from the PMC common code as well.
BUG=b:110836465
Change-Id: I94de41f3e52228bca4b7a5579afe5a23719429be
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27250
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On APL, call to pmc_fixup_power_state was added because GPE0_EN
registers did not have the right bits set on resume from S3 -- this
was a result of GPE_CFG registers getting reset to their default state
on resume. GPE_CFG registers are programmed as part of pmc_gpe_init
which was previously done only in ramstage.
However, with change a673d1c (soc/intel/apollolake: Initialize GPEs in
bootblock), call to pmc_gpe_init was added to bootblock which means
that GPE_CFG registers will have the right state by the time control
reaches romstage where pmc_fill_power_state is called. Thus, call to
pmc_fixup_power_state is totally redundant and in fact leads to
side-effects because of the call to pmc_disable_all_gpe at the end of
pmc_fill_power_state.
BUG=b:110836465
TEST=Verified on yorp that wake source is correctly identified on
resume from S3.
Change-Id: Ia63ddbe381ce8a59736c231d745fd71d008d5d92
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
%edx gets clobbered before the c handler is invoked. This is just a
cleanup cl to make the next cl look clean.
BUG=b:80539294
TEST=verified SMI still works on grunt.
Change-Id: I21bf41ed4fdeaaa8737c883f202a39cb57c2b517
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27228
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When generating a backtrace we need an indicator when we have hit the
beginning of the stack. The i386 ABI states that %ebp points to the next
stack frame. NULL can be used to indicate the end of the stack.
We could add a NULL return pointer at %ebp+4, but I decided to omit it
since a NULL stack pointer can be used as an indicator that there is no
return pointer.
BUG=b:80539294
TEST=built and tested on grunt
Change-Id: I8a48114d31a5c716335d264fa4fe4da41dc5bf11
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27226
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reduces the cognitive overhead of referencing locals via esp since
it changes with every push.
BUG=b:80539294
TEST=built and booted on grunt.
Change-Id: Ib7eb98ce3483d4fc803696c1b2496d8384317536
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This makes it easier to spot unused RAM.
BUG=b:80539294
TEST=built and tested on grunt. Verified unused memory was set to 0xcdcdcdcd
Change-Id: I335eaf642bd8526f31819eaac95ce80c2df3c300
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Type of vbt_len should be size_t, change to fix compiler error
Change-Id: I22798fa0edb98fcb9acc1b2dd52f34a61bc511e9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/27224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
An unidentified combination of speculative reads and branch
predictions inside WRPROT-cacheable memory can cause invalidation of
cachelines and loss of stack on models based on NetBurst
microarchitecture.
Therefore disable WRPROT region entirely for all family F models.
As an extreme example, just changing the location of a constant string
passed to printk() has been witnessed to make a the boot fail early on
in romstage.
Change-Id: I1df84ad55e2d8d6d4e8dca10125131b5f525f0d7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
For cases with POSTCAR_STAGE=y this reference pulled
in the implementation of run_ramstage() which we would
not call.
Using _program results with the same region being marked
as WRPROT-cacheble.
Change-Id: Ie1eaf6f5bb8baa13e946112c4fc3d854dbf750a3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/27232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Don't consume CBMEM for stage cache when we would
never use it.
Change-Id: I606e0457ff3085822554c4041fc56f0d28cc9c2d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/27230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Disabling the MMU with proper cache behavior is a bit tricky on ARM64:
you can flush the cache first and then disable the MMU (like we have
been doing), but then you run the risk of having new cache lines
allocated in the tiny window between the two, which may or may not
become a problem when those get flushed at a later point (on some
platforms certain memory regions "go away" at certain points in a way
that makes the CPU very unhappy if it ever issues a write cycle to
them again afterwards).
The obvious alternative is to first disable the MMU and then flush the
cache, ensuring that every memory access after the flush already has the
non-cacheable attribute. But we can't just flip the order around in the
C code that we have because then those accesses in the tiny window
in-between will go straight to memory, so loads may yield the wrong
result or stores may get overwritten again by the later cache flush.
In the end, this all shouldn't really be a problem because we can do
both operations purely from registers without doing any explicit memory
accesses in-between. We just have to reimplement the function in
assembly to make sure the compiler doesn't insert any stack accesses at
the wrong points.
Change-Id: Ic552960c91400dadae6f130b2521a696eeb4c0b1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some arm64 files that were imported from other projects use the
__ASSEMBLY__ macro to test whether a header is included from a C or an
assembly file. This patch switches them to the coreboot standard
__ASSEMBLER__, which has the advantage of being a GCC builtin so that
the including file doesn't have to supply it explicitly.
Change-Id: I1023f72dd13857b14ce060388e97c658e748928f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file has been dead since commit 7dcf9d51 (arm64: tegra132:
tegra210: Remove old arm64/stage_entry.S), I just forgot to remove it.
Change-Id: I0dd6666371036ecd42c1b256dbbe22a01ae959b8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/27236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
TPM config items added upstream before ready
SPI/TPM is not functional on Cheza yet
Change-Id: I302e00014dc31279fe2574765763ecdbf326b449
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/27213
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Limit is the maximum number of bits to be tested, however it's being checked
against the number of bytes of uint32_t. when it should be number of bits.
Create a macro to provide the number of bits, and use it instead of sizeof.
BUG=b:75996437
TEST=Add debug messages to see code passing beyond the check, build and
boot grunt, check that it passed the limit check, remove debug code.
Change-Id: Id1dfda26d789183b346b20c37fec923d996b80db
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/27162
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Adds Open Cellular rotundu mainboard supports.
Working:
- 2x Ethernet support
- MSATA support
- CPU init
- Memory init
- USB support
- EMMC but disabled
Not working:
- TPM support
Create directory structure and Kconfig files for OpenCellular
Rotundu and copy sources from intel/minnowmax.
Change-Id: I391d4bdd485f4bf5396c764fe3f11d98369593e4
Signed-off-by: Hong Gan <hgan@fb.com>
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/22894
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This adds another camelbackmountain_fsp derivative, along with a .fmd
file for the board. For now it's been tested to build and boot.
Change-Id: I9e8804264967c19f6b51fc44575b0db36f600f88
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/25884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Put the PCIe clock pins in power-saving mode for the BayHub eMMC bridge to
save power. This requires use of an additional register (Misc control
register 2) and another bit in the existing 'protect' register. The naming
of bit 0 of that register is incorrect, based on the latest datasheet
(14 June 2018) so fix that too.
BUG=b:73726008
BRANCH=none
TEST=boot without this patch:
iotools mem_read32 0xfed80e00
0x0046ffff
With this patch:
$ iotools mem_read32 0xfed80e00
0x00463fff
Also see that the PCIe clock stops when eMMC is idle and can be started by
starting disk activity.
Change-Id: I5ad1467b2e2e151215d2dfd2ce48cd4a451fe480
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/26515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Now that sconfig is able to support variant-specific override trees,
this change updates octopus boards to use this feature. Following
devices are moved from baseboard devicetree to variant specific
devicetree:
1. Touchscreen
2. Trackpad
3. Digitizer
4. Audio codec
BUG=b:80081934
TEST=Verified that the right devices show up in static.c for each
variant.
Change-Id: I8df0cdf4dbcd7613aa4ef4042c272eca2915da9e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27219
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a new config option OVERRIDE_DEVICETREE that allows
variants to provide an override devicetree file to override the
registers and/or add new devices on top of the ones provided by
baseboard devicetree using CONFIG_DEVICETREE.
BUG=b:80081934
Change-Id: Ica046b7e0d70d0f1e8d94da714d1e62032277916
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/26691
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We found GPP_C3 keeps high when system in S0ix mode. It caused 1.8V
leakage. To fix this problem, add GPP_C3 into config for Pantheon
Synaptics touchscreen.
BUG=b:78436458
BRANCH=None
TEST=Let DUT in S0ix mode and check GPP_C3 is normal.
Change-Id: Idb2dab93178af1dae54265e49522b473b69a35af
Signed-off-by: Crystal Lin <crystal_lin@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/27177
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recent patches in coreboot have fixed the freeze issues related to the
use of me_cleaner on Nehalem.
However, at least on the Lenovo X201, with me_cleaner some PCIe devices
(like the SATA and USB controllers) disappear. In particular, setting
the AltMeDisable bit ("-S" or "-s" flag) makes them disappear
completely, while unsetting it makes them disappear only during cold
boots.
This kind of behaviour was already observed by Youness Alaoui on the
Purism Librem laptops ([1]), and it seems related to some required
board-specific PCIe configuration in the ME's MFS partition.
For this reason, on the Lenovo X201, "-w EFFS" has been added to the
me_cleaner arguments, which whitelists the MFS-equivalent partition for
ME generation 2. This fixes all the issues, and the PCIe devices work as
expected.
[1] https://puri.sm/posts/deep-dive-into-intel-me-disablement/
Change-Id: Ie77a80d2cb4945cf1c984bdb0fb1cc2f18e82ebc
Signed-off-by: Nicola Corna <nicola@corna.info>
Reviewed-on: https://review.coreboot.org/27178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
During Speaker playback, quad Channel I/V feedback data is
captured from SSP0 Rx. Out of these 4-channels, Stereo V-Sense data
needs to be given as echo ref stream.
So, adding stereo capture config to max98373_capture_formats.
BUG=b:110074225
TEST='Audio playback and Capture Stereo echo ref data'
Change-Id: I6fe619ece94d5011caffe37ef10b48f956938db9
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/27182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
i2c/alps driver implementation is an exact copy of the i2c/hid driver
with only the addition of ALPS0001_HID. This can be supported by the
i2c/hid driver using the hid field in devicetree which is what glkrvp
mainboard does. So, this change removes the i2c/alps driver which is
anyways unused.
Change-Id: I60761c384f3d800532b2b346272da7be28b77acd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This change fixes the issue reported by Coverity CID 1393576 to ensure
that config is checked for NULL before it is actually used.
Change-Id: I5f0cd2bf2437fc640f4cf8d8203a971daf1f8d17
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Enrico Granata <egranata@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested with GRUB 2.02 as a payload, booting Arch Linux as
well as Debian. This code is based on the output of autoport
as well as other mainboards supported in coreboot already.
Working:
- Serial port I/O
- S3 suspend/resume. Untested with SeaBIOS since it failed
to resume on a similar board. It is likely to be due to
low memory corruption, but I have not worked on it.
- USB ports and headers
- USB3 ports attached to the ASM1042 controller. SeaBIOS can
boot from them, and it is likely GRUB can detect devices on
those ports as well. The chip has a small SPI flash nearby,
which seems to hold an Option ROM.
- Gigabit Ethernet
- Integrated graphics (libgfxinit)
- VGA BIOS for integrated graphics init
- PCIe x16 graphics
- PCIe x1
- SATA controller
- Hardware Monitor
- Fan Control (fancontrol on linux works well)
- Native raminit
- flashrom, using the internal programmer. Tested with coreboot,
as well as with the vendor firmware.
- NVRAM settings. Only debug_level has been tested.
Untested:
- DVI port. It can detect a "fake" display, that is, an
EEPROM connected to the DVI port. Thus, gma-mainboard.ads
has been setup accordingly.
- PS/2 port.
- Audio: Only rear output (green) has been tested.
- EHCI debug.
- Parallel port header.
- Non-Linux OSes
- ACPI thermal zone and fan control (probably not working)
Not working:
- Booting from devices attached to the ASM1061 controller.
Devices on ports work fine once Linux has loaded.
- Any SATA devices with Tianocore (payload issue)
Change-Id: I7e89ebe43a2e1ff0308f4876e98bbf2f5a0d85f2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/26419
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Regarding "Intel 945G/945GZ/945GC/945P/945PL Express Chipset Family",
Document Number: 307502-005, page 91, if Channel B is empty,
all of the C1DRBs are programmed with the same value as C0DRB3.
Mobile 945 express chipset datasheet doesn't mention this specific case.
Change-Id: Ic26103aac7f920e5696b445e125d33405df4f43b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27204
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This configures a GPIO pin for enabling/disabling bluetooth on the
next version of the atlas board. The default is for bluetooth to be
enabled at this point.
BUG=b:110614620,b:110613353
BRANCH=none
TEST=none
Change-Id: I4ba940e89b1dc03548b7ab44b8f84dc9a3097acb
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/27185
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures serial debug is not enabled by default on Cannonlake
platform.
Change-Id: Id925c8c73971a027e45ea3c61e878f134bc9feff
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/27205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC under each variant config and
select it for bip and fleex only.
Functional change in this CL is that EC SW sync will be enabled for
phaser.
BUG=b:110523400
Change-Id: If6f37c6b2ee71130b9ed5b10ce92fb23fa1c39fc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Bootblock has grown beyond 32K, grow to 40K
Change-Id: Iedc52151e223ebf4ff5b35a419b5378a6f1c661b
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/26760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit 77034fa [intel/common: compress VBT] compressed vbt.bin in
CBFS, but only changed the loader in soc/intel/common, forgetting
the separate one used by FSP 1.1.
As the soc/intel/common loader has now been rolled into the one in
drivers/intel/gma, replace the VBT loader used by FSP 1.1 with the GMA one.
Also, remove 2 now-unused header files.
Test: build/boot google/chell, observe display initialized prior
to OS load, no FSP warning in cbmem console due to invalid VBT signature.
Change-Id: Iba882ee4d9e83dcd88bdf7dd2f5591f66005a3fe
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/27169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a new driver for the SX9310 proximity detector device.
The purpose of this is to enable the device's calibration information
to be stored in firmware, and then transferred over to the kernel
via ACPI.
This device has more than 10 individual configuration parameters,
so they would not fit in the generic driver's properties table.
Change-Id: Id8c434eec9fe2da731e142442503a12e88db2236
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://review.coreboot.org/27173
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Alternative buffer communication support for PTT is no longer
needed for CNL onwards and coreboot does not need to reserve additional
4KiB memory for PTT support.
Change-Id: I11993cef77fd5e879eedabc1ed344f91f8257c90
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/27176
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SoC users from IOTG team is looking forward for a solution to skip
coreboot AP initialization flow and make use of FSPS-UPD to
perform AP reset.
TEST=Assign use_fsp_mp_init=1 to ensure coreboot is not bringing APs
out of reset.
Change-Id: Ibc8cd411e802fb682436a933073922b2693ba994
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/26644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use SPI_BASE_ADDRESS instead of PRERAM_SPI_BASE_ADDRESS like
big core in order make common code implementation straightforward.
Change-Id: Ibcb013fc95de29234253e89c9ca100cc468d44f6
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/27097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Select all Kconfig belongs into Intel SoC Family basecode/stage files
and include required headers from include/intelbasecode/ files.
BUG=None
BRANCH=none
TEST=Code is compiling with cannonlake configurations and also booting
on cannonlake RVP.
Change-Id: Iac99b4346e8bf6e260b00be9fefede5ad7b3e778
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Furquan Shaikh