The BMC isn't always ready in 60 seconds if it printing debug output.
Give it 90 seconds to finish before timing out in coreboot.
Change-Id: I3932d3e8fad067e8971e82b45b499801fc78079f
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Javier Galindo <javiergalindo@sysproconsulting.com>
Setting registers 64h[19:18] = 2 and 68h[14:13] = 3 enables OBFF, and
setting registers 64h[19:18] = 0 and 68h[14:13] = 0 disables OBFF.
Register at offset 0x64 is DCAP2, and offset 0x68 is DCTL2.
However, current code doesn't account for this. The result is that
register 64h[19:18] = 2 and 68h[14:13] = 0, which means the hardware is
OBFF-capable but support is disabled, which makes no sense. Given that
reference code and Broadwell both disable OBFF, disable it here too.
Change-Id: I6c1cafdb435ee22909b077128b3ae5bde5543039
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Code does not match comment, but this time the comment is right.
Change-Id: I4e277a802c68c8a4e858b2e33e7ec69b41dd9773
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47044
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Testing shows that these registers are backwards. Use the definitions
from Broadwell instead. All affected boards use the same value for both.
Change-Id: Ie47c9fddc2e9e15ce4c64821ea3a69356ac31b1a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It is already done once when enabling PMBASE in early init.
Change-Id: I14289c9164ee1488c192fce721d86c89fa5cc736
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
For all these southbridges, the lower nibble of PCICMD is read-only.
Tested on Asrock B85M Pro4 (Lynxpoint-H), LPC's PCICMD does not change.
Change-Id: Ib3b16b1b9651f7f3bd06ff8bc27dafd8a323e93c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Intel CPX-SP FSP ww45 release annotates default values for FSP-M UPD
variables.
FSPM MemRefreshWatermark option support is present in FB's CPX-SP
FSP binary, but not in Intel's CPX-SP FSP binary. In FB's CPX-SP
FSP binary, this option takes the space of UnusedUpdSpace0[0].
For DeltaLake mainboard, if corresponding VPD variable is set, use it
to control the behavior. Such control is effective when FB's CPX-SP
FSP binary is used.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I57ad01f33b92bf61a6a2725dd1cdbbc99c02405d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
NOC errors detected at runtime in AOP SRAM region
strongly suggested speculative memory accesses were occurring
in memory regions that either don't exist or are device memory
rather than SRAM.
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Change-Id: I6611dc614c80063c7df057b59337417c8f56fd9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The RV1 CPUID is already in the cpu.h file, but was still missing from
the CPU table in cpu.c.
Change-Id: Iad78cbe933b40e946d421e4c93e523f9e31f1089
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Adjust USB2 phy si setting fine tune on DVT for Ezkinil.
BRANCH=zork
BUG=b:156315391
TEST=Measuring scope timing and test usb detection
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Change-Id: Id537b6e9a17f47481b6aedcea0c6a8474d993b6d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Set numerous pads to PAD_NC as per board schematics (they are either
NC, or connected to test pads), and adjust comments as needed.
Change-Id: I4c2ab936256d0031d7a127fbeac42c8951a0b39f
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
On picasso's psp_verstage, the vboot hash is being calculated by
hardware using relatively expensive system calls. By increasing the
block size, we can save roughly 150ms of boot and S3 resume time.
TEST=Build & boot see that boot time has decreased.
BRANCH=Zork
BUG=b:169217270 - Zork: SHA calculation in vboot takes too long
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I6642073357327811b415dcbcad6930ac6d2598f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46903
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Increasing the vboot hash buffer size greatly speeds up the SHA
calculations. Going from a standard 4k buffer to a 36k buffer
takes ~150ms of the boot and resume time.
TEST=Build & boot see that boot time has decreased.
BRANCH=Zork
BUG=b:169217270 - Zork: SHA calculation in vboot takes too long
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ibca868ad7be639c2a0ca1c4ba6d71123d8b83c92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46902
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generally, this size probably doesn't matter very much, but in the
case of picasso's psp_verstage, the hash is being calculated by
hardware using relatively expensive system calls. By increasing the
block size, we can save roughly 140ms of boot and resume time.
TEST=Build & boot see that boot time has decreased.
BRANCH=Zork
BUG=b:169217270 - Zork: SHA calculation in vboot takes too long
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I68eecbbdfadcbf14288dc6e849397724fb66e0b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
The CPU index wasn't getting updated. Confirm MADT sets IOAPIC and CPU
ID numbers.
Change-Id: I72430cc48f4609ac408e723172ba1ed263cca8e3
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Continue Xeon-SP de-duplication.
Move CPU helper functions from skx/ and cpx soc_util.c to common util.c.
Functions only used by util.c are updated to be static.
The following functions are moved:
int get_threads_per_package(void);
int get_platform_thread_count(void);
const IIO_UDS *get_iio_uds(void);
unsigned int soc_get_num_cpus(void);
void get_core_thread_bits(uint32_t *core_bits, uint32_t *thread_bits);
void get_cpu_info_from_apicid(uint32_t apicid, uint32_t core_bits,
uint32_t thread_bits, uint8_t *package, uint8_t *core, uint8_t *thread);
void xeonsp_init_cpu_config(void);
Change-Id: I118a451b9468459cf2c2194f31da1055e1435ebe
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47170
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clean up the header includes.
Change-Id: I9f61d1a82b37bc0ed803967dc64decf18f44adc9
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
The amdfwtool is not available at the beginning of the
building. So it may have error if it is missing.
Change-Id: Id4db70986755cef8e98877c4e92841b25ced5452
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Disable C1 C-state auto demotion to decrease SoC power usage.
When set, processor will conditionally demote C3/C6/C7 requests
to C1 based on uncore auto-demote information.
BUG=b:161215906
TEST=Measure and confirm SoC power usage reduction for key use cases
eg 'Google Meets video call'
Measured on instrumented boards for Volteer EVT and Delbin.
Below measurements for Volteer:
Google meets with 720p w/ auto-demotion w/o auto-demotion
System Power 13.14W 9.4W
SOC Power 7.9W 5.4W
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Signed-off-by: Shweta Malik <shweta.malik@intel.com>
Change-Id: I649cafbaf03917d76521aa5f76ec58d218e1a1b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since the mainboard Kconfig is sourced before the SoC one, it would
still be possible to override this setting at mainboard level, even
though that shouldn't be needed. The maximum CPU count for Picasso is 8,
since the chips have only up to 4 cores with up to two threads each.
Change-Id: I53449b8fa73c5d13e6ea77bee6eed8896b7d3ec3
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47205
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Integrated TypeC MUX is used only in certain SoCs and hence the missing
devicetree configuration is not an error. Remove the check for internal
TypeC MUX device and the associated debug statement.
BUG=b:172186858
TEST=Build and boot to OS in Drawlat.
Change-Id: Ieb76e1ccfd04f1628617b2665b05be6718a25f81
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The PCI ID corresponds to the iGPU, which is disabled in the devicetree.
Also, the VBIOS file does not exist at the specified location.
Change-Id: I4f128d3057dc7218f32320c4e23466eb31af4e54
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45672
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These are generated by inteltool + intelp2m and reflect the
pad configuration of the vendor (AMI) firmware at a specific
point in time, but do not always reflect the correct configuration
of a given pad as per the schematics, so drop them.
Change-Id: Ie337cca5bc0e87a5426cceae8d7ec29ab14a1729
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47200
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This removes some boilerplate like starting the console and also adds
a "start of romstage" timestamp.
Change-Id: Ie85df5d244fa37c41f0b3177ca325c607fa54593
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46658
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Provide necessary romstage hooks to allow unblocking the memory with
SCLEAN. Note that this is slow, and took four minutes with 4 GiB of RAM.
Tested on Asrock B85M Pro4 with tboot. When Linux has tboot support
compiled in, booting as well as S3 suspend and resume are functional.
However, SINIT will TXT reset when the iGPU is enabled, and using a dGPU
will result in DMAR-related problems as soon as the IOMMU is enabled.
However, SCLEAN seems to hang sometimes. This may be because the AP
initialization that reference code does before SCLEAN is missing, but
the ACM is still able to unblock the memory. Considering that SCLEAN is
critical to recover an otherwise-bricked platform but is hardly ever
necessary, prefer having a partially-working solution over none at all.
Change-Id: I60beb7d79a30f460bbd5d94e4cba0244318c124e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the Librem Mini does not run on battery power, SaGv has little
benefits and noticeably slows down testing, since memory training is
run twice. Disabling SaGv cuts the 30-second cold boot time in half.
Change-Id: Ib02e42dcb4f20fdbdca85456c0dceafc59c782d8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
SCLEAN has specific requirements and needs to run in early romstage,
since the DRAM would be locked when SCLEAN needs to be executed.
Change-Id: I77b237342e0c98eda974f87944f1948d197714db
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Only LPT-LP includes this file, so `ISLP` is effectively constant. Thus,
eliminate some unnecessary if-blocks, since only one branch gets taken.
Change-Id: Ie8ba787bf5c021845e1e47256a6303697aa97fe1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46776
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the `GWAK` method into the GPIO device, and have lpc.c include the
LP GPIO code. All usages of `GWAK` on mainboards need to be updated.
Change-Id: Id6a41f553d133f960de8b232205ed43b832a83d2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46775
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename `lpt_lp.asl` and place all Lynxpoint-LP GPIO ASL there. It has
been named `gpio.asl` to ease diffs between Lynxpoint and Broadwell.
Tested with BUILD_TIMELESS=1, Google Panther does not change.
Change-Id: I7cc4ab3371014be783761f110542471a8c0157a3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46774
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Other southbridges such as Lynx Point do it. This eases merging later.
Change-Id: I10196bbc44ce859c2747755845378351f45944ae
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46766
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Nothing should be using this offset.
Change-Id: Ia4736471e2ac53bec18bfe073f4aa49e3fc524a8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46765
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is merely to align ACPI files with Broadwell. It is unused.
Change-Id: I8aa297bd3c3734bbd438ff84742aadfc661adcf7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46764
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These are present in common southbridge ACPI code, and also exist on
Broadwell. Thus, add the definitions to align with common ACPI code.
Change-Id: Ib0ad9da80920fe7c70986e541c50f6adccb49d0c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46761
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This file is no longer specific to 6 and 7 series PCHs.
Change-Id: Ib89378bd6ba1d80281b92a79d37b9fdeaaed40fb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46762
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Marc Jones