summaryrefslogtreecommitdiff
path: root/spd/ddr4/set-0
diff options
context:
space:
mode:
authorMaximilian Brune <maximilian.brune@9elements.com>2023-03-22 16:08:13 +0100
committerLean Sheng Tan <sheng.tan@9elements.com>2023-03-23 22:38:40 +0000
commit586b1c8da06fe34f91c747440730b31428248b34 (patch)
tree90a347073772f321518f0a8a36d773e782760b52 /spd/ddr4/set-0
parent08135332ddf5ad60d922f3bc6742e719d3ceebdd (diff)
mb/prodrive/atlas: Add workaround for CLKREQ pins
Intel Client PCIe* controller expects each device should drive the SRCCLKREQ#. If the GPIO is set to native mode for a device, which does not support SRCCLKREQ#, then during RTD3 exit link would not be established. Because controller samples the SRCCLKREQ# before detecting the device and break L1 as the system might enter L1SS as controller detects SRCCLKREQ# as de-asserted. As a workaround the Pins must not be configured in Native Mode (CLKREQ native function). Therefore here they are not configured at all. source: 689882 (intel document ID) So apparently hardware doesn't sample SRCCLKREQ Pin if it's not configured as such. That workaround suggestion however also brought a patch to FSP, which in turn causes the same bug (even if SRCLKREQ are not configured). Usually in order to make use of root port power saving features (e.g. clock gating), the Root port must either be disabled or a CLKREQ Pin must be configured. The patch however removed that check before enabling power management for the rootport. Workaround (until FSP is fixed): pretend to FSP that the rootports have a CLKREQ Pin attached, by supplying them in the FSP UPDs. That will cause FSP to configure the CLKREQ Pin and enable power management for said rootport, but it will not crash on L1 entry/exit. That has been done on the Atlas board (as workaround) for a short period of time (before applying FSP Fix) like this: // RP 5 (the rootport you want to fix) - memupd->FspmConfig.PcieClkSrcUsage[2] = 4; // e.g. choose a clkreq pin that is not routed out - memupd->FspmConfig.PcieClkSrcClkReq[2] = 0; Furthermore disable CpuPcieRpClockReqMsgEnable FSP-M options to prevent the same issue, but for CPU root ports. If not done the following will happen in coreboot: [DEBUG] PCI: 00:06.2 scanning... [SPEW ] do_pci_scan_bridge for PCI: 00:06.2 [DEBUG] PCI: pci_scan_bus for bus 02 [DEBUG] PCI: 02:00.0 [1344/5410] enabled [INFO ] PCIe: Common Clock Configuration already enabled [INFO ] PCIE CLK PM is not supported by endpoint [INFO ] ASPM: Enabled L1 [EMERG] CPU Index 9 - APIC 32 Unexpected Exception:18 @ 10:76aeb93f - Halting [EMERG] Code: 0 eflags: 00000046 cr2: 00000000 [EMERG] eax: 00000000 ebx: 00000009 ecx: 00000000 edx: 00000000 [EMERG] edi: 00000009 esi: 76b218c4 ebp: 00000000 esp: 76b29100 [EMERG] 0x76aeb8f8: c4 2c 5b 5e 5f 5d c3 56 [EMERG] 0x76aeb900: 53 83 ec 14 65 a1 00 00 This patch is only a workaround for the issue and it will be reverted as soon as FSP is fixed. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I324bc6ab158d4b3b5ae9d3bade21076b44bc8892 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73938 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Diffstat (limited to 'spd/ddr4/set-0')
0 files changed, 0 insertions, 0 deletions