Change the Stoney Ridge SOC to a more modern method for setting up
the multiple cores.
Add a new cpu.c file for most of the processor initiliazation. Build
mp_ops with the necessary callbacks. Note also that this patch removes
cpu_bus_scan. Rather than manually find CPUs and add them to the
devicetree, allow this to be done automatically in the generic
mp_init.c file.
SMM information is left blank in mp_ops to avoid having mp_init.c
install a handler at this time. A later patch will add TSEG SMM
capabilities for the APU.
This patch also contains a hack to mask the behavior of AGESA which
configures the MTRRs and Tom2ForceMemTypeWB coming out of AmdInitPost.
The hack immediately changes all WB variable MTRRs, on the BSP, to UC
so that all writes to memory space will make it to the DRAM.
BUG=b:66200075
Change-Id: Ie54295cb00c6835947456e8818a289b7eb260914
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Call into commmon SGX code to configure core PRMRR and follow
other SGX init seqeuence.
- Enable SOC_INTEL_COMMON_BLOCK_SGX for both GLK
- Enable SOC_INTEL_COMMON_BLOCK_CPU_MPINIT for GLK, as MP init needs
to be completed before calling into fsp-s for SGX.
Change-Id: I9331cf5b2cbc86431e2749b84a55f77f7f3c5960
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/21276
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Use a single define and set the CROS GPIO ASL device to match the
Stoney Ridge GPIO HID. Update the GPIO number to 142. Also, add a DDN
field in the GPIO ASL. This addresses the TEST indicated below.
BUG=b:65597554
BRANCH=none
TEST=grep ^ /sys/devices/platform/chromeos_acpi/GPIO.*/* reports AMD0030.
Change-Id: I1d6c42c6c9a0eef25e0e99aed6d838c767f5e01f
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Refactor the GPIO functions to use GPIO numbers. This is more consistent
with other GPIO code in coreboot.
BUG=b:66462235
BRANCH=none
TEST=Build and boot Kahlee
Change-Id: I6d6af7f6a0ed9ba1230342e1ca024535c4f34d47
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21684
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use reserved_ram_resource to help ensure the UMA memory is typed
as WB.
BUG=b:65856868
TEST=Inspect MTRRs and compare with UMA memory
Change-Id: Ifa54d9b1c206d2ee6dc4b8f90b445a6820ceb8fd
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21606
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The EXT_CONF_SUPPORT symbol doesn't exist for the Stoney Ridge SoC.
Clean up northbridge.c by removing the check for the config value set.
Remove the CPU initialization code that clears the EnableCf8ExtCfg
bit. The location where it was set was removed in
c1d72942 Disable PCI_CFG_EXT_IO
BUG=b:66202622
Change-Id: Ic58c47fc5f568d17f5027c96d4152b0e5b3e1d14
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21497
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Delete the obselete Kconfig symbols regarding the memory hole. Integrate
the hole check into domain_set_resources(). The hardware configuration
is done by AGESA, so only discover the setting and adjust the mmio_basek
accordingly.
BUG=b:66202887
TEST=Check settings with HDT
Change-Id: Id15a88897e29bff28ab7c498dc4d3818834f08b2
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There have been discussions about removing this since it does not seem
to be used much and only creates troubles for boards without defaults,
not to mention that it was configurable on many boards that do not
even feature uart.
It is still possible to configure the baudrate through the Kconfig
option.
Change-Id: I71698d9b188eeac73670b18b757dff5fcea0df41
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch implements soc override function to calculate reserve memory
size (PRMRR, TraceHub, PTT etc). System memory should reserve those
memory ranges.
BRANCH=none
BUG=b:63974384
TEST=Ensures DRAM based resource allocation has taken care
of intel soc reserved ranges.
Change-Id: I19583f7d18ca11c3a58eb61c927e5c3c3b65d2ec
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/21540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch uses BIOS EBDA area to store relevent details
like cbmem top during romstage after MRC init is done.
Also provide provision to use the same EBDA data across
various stages without reexecuting memory map algorithm.
BRANCH=none
BUG=b:63974384
TEST=Ensures HW based memmap algorithm is executing once in romstage
and store required data into EBDA for other stage to avoid redundant
calculation and get cbmem_top start from EBDA area.
Change-Id: Ib1a674efa5ab3a4fc076fc93236edd911d28b398
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/21424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the support for Kabylake Celeron base SKU
with PCH ID 0x9d50.
BRANCH=none
BUG=b:65709679
TEST=Ensure coreboot could recognize the Kabylake Celeron base
SKU and boot into OS.
Change-Id: I9c6f7bf643e0dbeb132fb677fcff461244101a55
Signed-off-by: Tsai, Gaggery <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/21617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: David Wu <david_wu@quantatw.com>
Reviewed-by: T.H. Lin <T.H_Lin@quantatw.com>
The System Control Interrupt is routed per default to IRQ 9. Some
mainboards use IRQ 9 for different purpose. Therefore it is necessary to
make the SCI configurable on Apollo Lake.
Change-Id: Ib4a7ce7d68a6f1f16f27d0902d83dc8774e785b1
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/21584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are a lot errors reported by AER driver for root port 0.
The erors are being caused by an unsupported request from the
device to the upstream port. Enabling LTR on the root port stops
these errors, it is because LTR is enabled on the device side but
not on the root port and hence root port was logging the LTR messages
from the device as unsupported.
The PCIe base spec (v3.1a) section 6.18 also states that:
LTR support is discovered and enabled through reporting and control
registers described in Chapter 7. Software must not enable LTR in an
Endpoint unless the Root Complex and all intermediate Switches indicate
support for LTR. Note that it is not required that all Endpoints support
LTR to permit enabling LTR in those Endpoints that do support it. When
enabling the LTR mechanism in a hierarchy, devices closest to the
Root Port must be enabled first.
If an LTR Message is received at a Downstream Port that does not
support LTR or if LTR is not enabled, the Message must be treated
as an Unsupported Request. FSP has a UPD for enabling/disabling
LTR on root port, use the same for configuring LTR on PCIe root ports.
BUG=b:65570878
TEST=After enbaling LTR on port 0 on the MB devicetree, No errors reported
by AER driver for root port 0.
Change-Id: Ica97faa78fcd991dad63ae54d2ada82194b4202a
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/21547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In coreboot commit bcd0bdabed (soc/intel/cannonlake: add rtc failure
checking), the function soc_get_rtc_failed was supposed to be moved,
but the old function was not removed, causing a build error.
BUG=b:63054105
Change-Id: I31c1966af413df3f5a5492a5dd891a6eb26a1fc4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/21616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's an occasional issue on machines which use CMOS for their
vbnv storage. The machine that just powers up from complete G3
would have had their RTC rail not held up. The contents of vbnv
in CMOS could pass the crc8 though the values could be bad. In
order to fix this introduce two functions:
1. vbnv_init_cmos()
2. vbnv_cmos_failed()
At the start of vboot the CMOS is queried for failure. If there
is a failure indicated then the vbnv data is restored from flash
backup or reset to known values when there is no flash backup.
BUG=b:63054105
Change-Id: I8bd6f28f64a116b84a08ce4779cd4dc73c0f2f3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ic4bf99dc3a26fbc3bd508e484963b9298ef1b24b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1d90cc557225ddbba1787bf95eae0de623af487e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I88bf9bdba8c1f3a11bc8301869e3da9f033ec381
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21554
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred. In addition actually
provide soc_get_rtc_failed() which properly indicates to the common
code that RTC failure did occur in the cmos_init() path.
BUG=b:63054105
Change-Id: I9dcb9377c758b226ee7bcc572caf11b7b2095425
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ia0a38f00d2a5c7270e24bdd35ecab7fbba1016d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21552
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1b02028a1830ff9b28b23da7a4a1fd343f329f0d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having each potential caller deal with the differences
of cmos_init() and init_vbnv_cmos() when VBOOT is enabled put the
correct logic within the callee, cmos_init(), for handling the
vbnv in CMOS. The internal __cmos_init() routine returns when the
CMOS area was cleared.
BUG=b:63054105
Change-Id: Ia124bcd61d3ac03e899a4ecf3645fc4b7a558f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21549
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add PMC pci driver on top of PMC common code, also include pmc init code
reference from skylake.
Change-Id: I95895a3e26cdebd98a4e54720bd4730542707d7e
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/21251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
UNCORE PRMRR BASE and MASK MSRs are not common, so move to
SOC specific header file and rename the #define to start with MSR_*
Change-Id: I799c43f0b7a9eec5b3b69ab0f5100935c7f3f170
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/21247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use soc_get_uncore_prmmr_base_and_mask() API to get PRMRR base and mask.
Change-Id: I2fd96607c4f5fed97e38087b60d47d6daacc7646
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/21246
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To remove chip.h dependency from SGX common code
- Create API soc_fill_sgx_param() and use it in sgx.c
- Implement same API for skylake/kabylake
- define sgx_param structure
Also include intelblocks/sgx.h instead of soc/msr.h
Change-Id: I358f0817bec5dd6cd147a645675b5688969a04e0
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/21528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's no reason to mutate the struct device when determining
the ACPI name for a device. Adjust the function pointer
signature and the respective implementations to use const
struct device.
Change-Id: If5e1f4de36a53646616581b01f47c4e86822c42e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There were two copies of the same definitions in the file.
Change-Id: Iafb10476f32505f6b4ad7b5ba6fa5de2c4648836
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
The Stoney Ridge APU can never be used in a multi-node system. Reduce
the feature set to a single node.
Remove the static variables for each D18Fn device and replace the routines
with coreboot config read and write functions.
Strip down domain_set_resources() to consider only a single node. A
follow-on patch will further simplify this.
Change-Id: I1982b3fbf8dbb44ca75112c57afa59a2b4e4cf5a
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
