Applying the attribute silences the following error and allows
compilation with GCC 15.2.
error: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute
Change-Id: I33cf3219f34e297de03f67d3e73058b10930c9f8
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reference code version 1.9.1 sets `SAPMCTL` bit 0 just before setting
`BIOS_RESET_CPL` bits 0 and 1. Do the same thing in coreboot.
Change-Id: I36e24d2a3bd754e56df59a1e996d285ec6bf5205
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91632
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Intel Document 492662 (Haswell System Agent BIOS Spec), Rev 1.6.0 states
that `ARCHDIS` (VT engine BAR, offset 0xff0) has to be written fully, as
well as several other things that were not done properly in coreboot. As
these steps are Haswell-specific, introduce two helper functions to test
if the CPU is Haswell or Broadwell.
Intel Document 535094 (Broadwell BIOS Spec), Rev 2.2.0 contains the same
steps for Broadwell. To permit unifying Haswell and Broadwell, implement
the Broadwell steps as well.
Change-Id: I077e064754720d9f9f627733c954712a2b24b5b7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91631
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Instead of open-coding function-to-DEVEN-bit mapping thrice (using
a different implementation each time), introduce `deven_for_peg()`
to map the PCI function number to the corresponding DEVEN bit. Use
the PCI function number as primary parameter, instead of passing a
`pci_devfn_t` around and getting the PCI function number from that
using two macros.
Change-Id: Ia2f7cdcff3c95f831269fa51f9bfc60bef0907a1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91630
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These can and will be used in other files in subsequent commits.
Change-Id: Iba0515151252b22f0211e8ab1470c70dfd172929
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
This function prints CPU information, so it makes sense for it to be
part of CPU code. The version in CPU code prints a bit more info but
is otherwise equivalent. After all, this is just logging some info.
Change-Id: I2a9d8a42f78efab6206710fada1d64fa79e8056e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91627
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Abdelkader Boudih <coreboot@seuros.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function prints CPU information, so it makes sense for it to be
part of CPU code. Subsequent commits will update the CPUID table and
make the Haswell northbridge code also use it.
For now, rename the static function in `nb/intel/haswell` to avoid a
name clash. It will be dropped in a follow-up anyway.
Change-Id: I6b26fddd4e899b692f4122921db1c70f4b16b4f2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91624
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The register at MCHBAR offset 0x5418 is named `INTRDIRCTL` on Haswell,
as well as earlier platforms. Sync the Haswell and Broadwell codebases
by renaming `MCH_PAIR` to `INTRDIRCTL` on Broadwell.
Tested with BUILD_TIMELESS=1, Purism Librem 15 v2 remains identical.
Change-Id: I0b37927ebec634b6e48623f75789723cf518c3ef
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91621
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Yes, the "Coding Style" page of the coreboot docs states the following:
Bulk style changes to existing code ("cleanup patches") should
avoid changing existing style choices unless they actually
violate this style guide, or there is broad consensus that the
new version is an improvement. By default the style choices of
the original author should be honored.
However, when attempting to unify two codebases (Haswell and Broadwell),
style differences only make it harder to find the functional differences
between the codebases. So, it makes sense to unify the code style first,
so that only functional differences remain. Especially if these cosmetic
alignment changes are reproducible, i.e. they don't change the resulting
coreboot.rom when using `make BUILD_TIMELESS=1` to build.
Sort includes alphabetically, unbreak some long lines that are less than
96 characters long, combine variable declaration and initialisation, use
C-style comments, use one line for printk strings (easier to use grep to
find them this way), constify some values the compiler already knew they
were constant (they get inlined anyway), remove unnecessary parentheses,
fix space usage around operators, align some comments with Haswell code,
rename a few things for consistency with Haswell, use an early return in
place of an if-block (like Haswell does), drop a few unused includes and
include `types.h` from files that need it.
Tested with BUILD_TIMELESS=1, Purism Librem 15 v2 remains identical.
Change-Id: I872068e93f1960d90a914193ccb346fc77652220
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91620
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The idea is to use Haswell's acpi.c file in the next commit, and this
little difference affects reproducibility.
Change-Id: Ib2641586fbb9e8ed175eeca0bd665057f5049c0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Device NVS is only used in southbridge code. This change is
non-reproducible.
Change-Id: I60ce9a80d6e3e0ce0c13037d4caae473d3d092a9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91402
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Device NVS is only used in southbridge code. Also move the platform.asl
file since it is mostly about southbridge stuff.
Tested with BUILD_TIMELESS=1, Purism Librem 15 v2 remains identical.
Change-Id: Ia0d301f6b77f7084a6d1dfe1238693c76c62ef7a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91401
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since this used to be a SoC (no distinction between CPU/NB/SB parts),
all the headers were in a single place. Move headers about PCH things
to where they belong.
Change-Id: I296f57f5575d026ad87698e972eb9f448d54d09b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
In preparation to unify the Haswell and Broadwell codebases, move the
remaining Broadwell SoC code to the northbridge folder.
This change only moves the files, and does the minimal amount of edits
so that boards still build. Most of those edits boil down to "find and
replace".
Change-Id: I5bde032ee824a90328a78403ea03d39ad20f2b09
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Commit 4c4bd3cd97 ("soc/intel/broadwell: Hook up PCI domain and CPU
cluster ops to devicetree") and commit 600fa266bd ("nb/intel/haswell:
Hook up PCI domain and CPU cluster ops to devicetree") decoupled the CPU
bus device operations from northbridge code. Since Haswell and Broadwell
both use the same CPU code, move the CPU bus ops to CPU code in order to
deduplicate them.
Change-Id: I11cbff3d87e233f40a40f2fc70840f6bf35b0cb9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91463
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If `CONFIG(DEBUG_RAM_SETUP)`, dump the values of the CAPID0_A and
CAPID0_B registers to the log. This is useful debugging information.
Dump the CAPID registers' values before native chipset init, because
dynamic fusing changes the CAPID values.
Tested on ASRock Z97 Extreme6 with a PCIe card plugged into the PCIE4
slot (forcing PEG to be bifurcated as x8+x8). The CPU and PCH are:
CPU id(306c3) ucode:00000028 Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz
AES supported, TXT supported, VT supported
PCH type: Z97, device id: 8cc4, rev id 0
CAPID values before dynamic fusing are shown below:
CAPID0_A: 0x6204e861
DDR3L 1.35V: Yes
DDR Write Vref: No
OC enabled (DSKU): No
DDR overclock: No
Compatibility RID: 0x6
Capability DID: Desktop
DID override: No
Integrated GPU: No
Dual channel: Yes
X2APIC support: Yes
DIMMs per channel: 1
Camarillo device: No
Full ULT info: Yes
DDR 1N mode: Yes
PCIe ratio: No
Max channel size: 16 GiB
PEG Gen2 support: Yes
DMI Gen2 support: Yes
VT-d support: Yes
ECC forced: No
ECC supported: No
DMI width: x4
Width upconfig: Yes
PEG function 0: Yes
PEG function 1: No
PEG function 2: No
Disp HD audio: Yes
CAPID0_B: 0x565400d0
PEG for GFX single: Unlimited width
PEG for GFX multi: Unlimited width
133 MHz ref clock: Up to DDR3-1600
Silicon mode: Production
HDCP capable: Yes
Num PEG lanes: 16
Add. GFX capable: Yes
Add. GFX enable: Yes
CPU Package Type: 0
PEG Gen3 support: No
100 MHz ref clock: Up to DDR3-1600
Soft Bin capable: No
Cache size: 3
SMT support: Yes
OC enabled (SSKU): No
OC controlled by: SSKU
CAPID values after dynamic fusing are shown below, with manually
added arrows to indicate which values have changed:
CAPID0_A: 0x4204a06d
DDR3L 1.35V: Yes
DDR Write Vref: No
OC enabled (DSKU): Yes <-----
DDR overclock: Yes <-----
Compatibility RID: 0x6
Capability DID: Desktop
DID override: No
Integrated GPU: Yes <-----
Dual channel: Yes
X2APIC support: Yes
DIMMs per channel: 2 <-----
Camarillo device: No
Full ULT info: Yes
DDR 1N mode: Yes
PCIe ratio: No
Max channel size: 16 GiB
PEG Gen2 support: Yes
DMI Gen2 support: Yes
VT-d support: Yes
ECC forced: No
ECC supported: No
DMI width: x4
Width upconfig: Yes
PEG function 0: Yes
PEG function 1: Yes <-----
PEG function 2: No
Disp HD audio: Yes
CAPID0_B: 0x564400d0
PEG for GFX single: Unlimited width
PEG for GFX multi: Unlimited width
133 MHz ref clock: Up to DDR3-1600
Silicon mode: Production
HDCP capable: Yes
Num PEG lanes: 16
Add. GFX capable: Yes
Add. GFX enable: Yes
CPU Package Type: 0
PEG Gen3 support: Yes <-----
100 MHz ref clock: Up to DDR3-1600
Soft Bin capable: No
Cache size: 3
SMT support: Yes
OC enabled (SSKU): No
OC controlled by: SSKU
Change-Id: I46f27c54a7ec7fd9fc79fdabaa59a44a591168b8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91478
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Implement an algorithm that performs a simple 1D margin training. This
algorithm is generic, i.e. it can be used with multiple margin params.
Use this algorithm to train three margin parameters: RdT, WrT and RdV.
This algorithm also does per-bit calibration, but only for RdT and WrT
since Haswell does not have per-rank per-bit RdV (c.f. `RX_OFFSET_VDQ`
register). Still, implement support in `change_margin()` for all three
types of per-bit margins (WrTBit, RdTBit, RdVBit) for completeness.
Tested on Asrock Z97 Extreme6 with 2 DIMMs per channel (1R + 2R):
- NRI finishes successfully, board still boots to Arch Linux.
- Both fast training as well as S3 suspend/resume still work.
Change-Id: I382cea8e230aee46a0dc66248f1e678d8a9a0090
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89314
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DDR frequency (in MHz) was doubled for no reason, then doubled again to
convert it to MT/s. Moreover, the calculations assume a reference clock
of 133 MHz, but a 100 MHz reference clock also exists.
Add two functions: `is_100_mhz_refclk()` to check whether the reference
clock is 100 MHz, and `get_ddr_freq_mhz()` to get the DDR frequency, in
MHz. Use both functions in `report_memory_config()` to show the correct
DDR ref. clock and frequency, and use one in `setup_sdram_meminfo()` so
that SMBIOS tables contain the correct memory speed.
Tested on ASRock Z97 Extreme6 with four DDR3-1600 sticks, DDR frequency
is correctly reported as 800 MHz with either reference clock frequency:
Default 133 MHz reference clock:
memcfg DDR3 ref clock 133 MHz
memcfg DDR3 clock 800 MHz
After forcing 100 MHz ref clock for 800 MHz (edit NRI's `init_mpll.c`):
memcfg DDR3 ref clock 100 MHz
memcfg DDR3 clock 800 MHz
Also, SMBIOS type 17 correctly reports memory speeds of 1600 MT/s:
$ sudo dmidecode --type 17 | grep -i speed
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
Speed: 1600 MT/s
Configured Memory Speed: 1600 MT/s
It is expected that behaviour using either MRC binary is the same since
the `MC_BIOS_REQ` and `MC_BIOS_DATA` registers have to be programmed in
order for the DDR clock to start running. The decision to test with NRI
is because one can easily change the chosen reference clock to 100 MHz.
Resolves: https://ticket.coreboot.org/issues/624
Change-Id: Idead9cd55b453d3ff4695c977dee763ff50830f8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Be consistent when printing the channel assignment, and use unsigned
printf specifiers since the values themselves are unsigned.
Change-Id: I66b93233707dec73dc7a25423789a24770ac678f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Currently not all fixed MMIO ranges are advertised to the resource
allocator. This is not an issue as long bottom-up allocation is
used and as long as only small PCI BARs are present on the system.
Tell the PCI resource allocator about active MCH BARs to not overlap
PCI BARs with MCH BARs.
TEST=Can still boot on Lenovo X220. No issues seen in coreboot or Linux.
Change-Id: I9148ce492b3b16542bae2737c98b0e6fd0701745
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Parse the supported voltages from the DDR3 SPD and populate the
corresponding fields in CBMEM_ID_MEMINFO to make sure the SMBIOS
type 17 tables report the actual supported voltages of the DIMM.
Change-Id: I35af7c23f285af10b607a80eab7f4d9df664b3fd
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Call the `report_memory_config()` and `setup_sdram_meminfo()` functions,
which were factored out into shared raminit code in previous patches. As
the SPD data is not readily available where `setup_sdram_meminfo()` gets
called, add a function to get it from the saved data, as it is available
in a global context. Technically speaking, the "mighty ctrl" variable is
also static (thus global), but it is only meant to be used within native
raminit code and is only static to avoid nuking the stack (it is huge).
Change-Id: Ia2c0946f55748e38bb5ccb5cb06721aeb77527e7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89600
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the `report_memory_config()` function to shared raminit code, both
to deduplicate the code and to allow native raminit to make use of it.
Change-Id: I8b3c695c0a266634a42b0303e4f1ea699301c26b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89599
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the `setup_sdram_meminfo()` function to shared raminit code
to deduplicate it as well as to allow native raminit to make use
of it, which will be done in a follow-up.
When consolidating the functions, the only functional difference
is that the Broadwell MRC.bin path reports memory frequencies in
MHz whereas the Haswell MRC.bin path reports them in MT/s. Since
this data is used to populate SMBIOS tables, which expect memory
frequencies in MT/s, using MT/s is the right choice.
Given that SPD data is handled differently in the three RAM init
implementations (Haswell MRC, Broadwell MRC, native raminit), we
have to abstract the SPD data pointers a bit. This is done using
an array of pointers.
While we're at it, add some TODO comments to note limitations of
the code. The idea is to fix those in follow-up commits.
Change-Id: I1f81bf18a9e856d80f8e4d7bda65089e999957f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89598
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Broadwell SoC boards (which use Haswell's northbridge ACPI),
coreboot's resource allocator identifies and uses two MMIO windows
below 4GB, but currently only one is declared in the ACPI _CRS.
Normally this isn't a problem, as coreboot is usually able to allocate
resources entirely in the (declared) lower MMIO window. But, this is
problematic when using top-down allocation, since coreboot assigns
resources to devices starting in the (undeclared) upper MMIO window,
which the OS does not consider a valid space.
Linux will mostly handle this gracefully, and reassign BARs in the
lower MMIO address space. Windows does not, and will simply mark any
devices in the upper window as invalid or malfunctioning.
To resolve this, add the dynamically-sized PM02 PCI MMIO window above
MMCONF to match the region used by coreboot's allocator.
With this change, both MMIO windows are properly reported via _CRS,
allowing the OS to use coreboot's resource allocations properly.
coreboot allocator:
[INFO ] * Base: 80000000, Size: 70000000, Tag: 200 [Window 1: 1.75GB]
[INFO ] * Base: f4000000, Size: a000000, Tag: 200 [Window 2: 160MB]
kernel before:
[mem 0x80000000-0xefffffff window] [PM01: 1.75GB]
[mem 0xf4000000-0xfed44fff window] [TPM]
kernel after:
[mem 0x80000000-0xefffffff window] [PM01: 1.75GB]
[mem 0xf4000000-0xfebfffff window] [PM02: 172MB]
[mem 0xfed40000-0xfed44fff window] [TPM]
BUG=https://ticket.coreboot.org/issues/611
TEST=Build/boot google/lulu with top-down allocation enabled.
Verify kernel sees both MMIO windows and devices keep their coreboot-
assigned BARs. Verify Windows boots with functional i2c devices.
Change-Id: I83fa8ca7f9edfd7d185895f8bbff15ee9895d1ff
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This moves most of the vendor and architecture independent code into
common ACPI code.
Change-Id: I7dca939612a5f3d8d6a148fa67bf0ce891952584
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88034
Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This rework is done gradually, and that means different mainboards will
use different implementations of the verb table. As this code is used by
multiple mainboards we need to keep both implementations and select
whichever implementation matches the one being used by the mainboard
currently being built.
It should be noted that we do not modifiy the verb tables in any case,
as it would break the regression test script mentioned in the TEST
section below.
For an overall rationale for this rework, see CB:88656.
TEST=
1. Timeless build with AZALIA_USE_LEGACY_VERB_TABLE=y produces
identical binaries (tested with google/slippy_falcon)
2. Passed regression test (CB:88763)
Change-Id: I3bf8140a4ceb6edad71d57ab82e0a96f51159985
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88739
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Check if CPU has been replaced before doing ram init. When it
has been replaced disable MRC cache and do a full memory training.
Also use get_us_since_boot() to skip waiting additional 50msec
when not necessary. Setting up NEM in bootblock is so slow that
50msec might already have passed.
Before:
940:waiting for ME acknowledgment of raminit 116,514 (62,804)
After:
940:waiting for ME acknowledgment of raminit 68,708 (7,211)
Boots 48msec faster than before.
Change-Id: I2d9729792c3546dc9bf23192c42619cd7d639d1c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88794
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
TXT SINIT ACM checks the PEG bridge memory ranges whether they are
correctly assigned in the MMIO space. If the bridge is enabled but no
device is attached to it, coreboot will not assign any resources (if
hotplug is not enabled). When SINIT ACM checks the ranges, it fails
on prefetchable range check.
Hide the PEG devices if the bridge is not active. PCIe bridges should
generally be hidden if hotplug is not enabled and there is no
downstream device.
TEST=Perform successful measured launch of Xen with Intel TXT on Dell
OptiPlex 9010.
Change-Id: I0bd104ab416376e96102738f2e47c8ce041497a2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87472
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Use i2c_eeprom_read() to speed up reading the SPD EEPROMs.
TEST=Booted on Lenovo X220 and used cbmem -t:
Before:
940:waiting for ME acknowledgment of raminit 116,514 (62,804)
After:
940:waiting for ME acknowledgment of raminit 110,212 (57,612)
Boots 5msec faster when MRC cache is present.
Change-Id: I500d7ff7a66b08b5036c0031e4fa20746d06df19
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Rename config options 'USE_DDRx' to 'DRAM_SUPPORT_DDRx' to make them
less clunky, and in preparation to expand their use inside SoC code.
Change-Id: Ie6edd730c5cbad679a90fcf7989a942d9b2dd3d8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: <yuchi.chen@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This algorithm minimises the per-channel, per-lane digital COMP offsets
by adjusting the global COMP offset accordingly. The purpose of this is
not fully known, but it is likely to prevent saturation of per-channel,
per-lane registers during subsequent training steps, which NRI does not
implement yet. Some of the COMP offset functions are generic since they
are also used in said training steps.
Tested on Asrock B85M Pro4, still boots to Arch Linux.
Change-Id: Idb03c6c5ed85a522ff1b55905f522211d1472bd9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87833
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For "basic" (initial) memory training, we use larger-than-usual timings
for a few things, namely tCMD and tXP. After basic training is done, we
can switch to the final timings for the training steps that follow (not
many at the moment). Without this, NRI keeps using the training timings
at all times, which results in slightly lower performance (likely to go
unnoticed unless benchmarking the system).
Tested on Asrock B85M Pro4, still boots to Arch Linux.
Change-Id: I625f35adb02b36b1087cd758f983118d0a60b815
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Add some simple execution time measurement code. It only logs execution
times if `DEBUG_RAM_SETUP` is selected. Note that this will fill things
like pre-RAM CBMEM console, but NRI's debug output is already extremely
verbose, and will become even more verbose as additional training steps
get added.
Future plans include measuring the time spent waiting for REUT hardware
to finish testing, as that is what takes most time for complex training
algorithms (which are yet to be published).
Tested on Asrock B85M Pro4, still boots to Arch Linux. Output example:
+------------------+------------+
| Task | msecs |
+------------------+------------+
| PROCSPD | 503 |
| INITMPLL | 33 |
| CONVTIM | 43 |
| CONFMC | 1 |
| MEMMAP | 39 |
| JEDECINIT | 1 |
| PRETRAIN | 23 |
| SOT | 394 |
| RCVET | 1448 |
| RDMPRT | 1088 |
| JWRL | 1975 |
| OPTCOMP | 0 |
| POSTTRAIN | 0 |
| ACTIVATE | 0 |
| SAVE_TRAIN | 0 |
| SAVE_NONT | 0 |
| RAMINITEND | 4 |
+------------------+------------+
| Total | 5558 |
+------------------+------------+
Note: the board had 4x dual-rank DIMMs installed, which gives the worst
possible boot time (more ranks to train, and that means more log output
to push through 115200 baud serial). Without debug logging, training is
substantially faster.
Change-Id: Ie4b6f6246e54f23d03babdb6fa0271538f69984e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87830
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This was kept around to avoid build issues back when the NRI patches
were awaiting review. It is no longer used and to-be-upstreamed code
does not use this define either, so now is a good time to get rid of
it.
Change-Id: Id10d81774b0d679b54d5dc4a15dab5996e3a68c5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87832
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The REUT subsequence control register had a different layout in the
Haswell A0 stepping, so it was initially programmed using bitmasks.
However, NRI does not implement support for the A0 stepping because
it is early pre-production silicon that no one should be using, but
the code kept using the bitmasks approach. But we can do better.
Introduce a bitfield for the REUT subsequence control register, and
use it instead of bitmasks. Put the enum for subsequence types next
to the code using it (no reason to have it in the common header, it
is not used anywhere else). And make a helper function that encodes
the number of cachelines in the format expected by the REUT (7 bits
of value, 1 bit for exponential/linear).
Change-Id: I1609ad010e714b0fc47403df7a71e5fc5ae0f5ac
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87829
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the CPU code exports these PCODE mailbox functions, there is no
reason to retain a copy of them in NRI.
Change-Id: Ic9853cfd6793ecdadf8d2bd15b268f9cf95ba32d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87828
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't generate the IVRS ACPI table if the IOMMU PCI device isn't enabled
in the devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e7f976011da92c0ca69decdca7aa77de24b6a2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add a header with CFR objects for existing configuration options,
so that supported boards can make use of them.
Currently only one option for IGD UMA size, but others can be added
as needed.
Change-Id: I892ffcc74d36a266697cbc7ea3c8880db6b67f44
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Quoting Wikipedia:
A sense amplifier is a circuit that is used to amplify and detect
small signals in electronic systems. It is commonly used in memory
circuits, such as dynamic random access memory (DRAM), to read and
amplify the weak signals stored in memory cells.
In this case, we're calibrating the sense amplifiers in the memory
controller. This training procedure uses a magic "sense amp offset
cancel" mode of the DDRIO to observe the sampled logic levels, and
sweeps Vref to find the low-high transition for each bit lane. The
procedure consists of two stages: the first stage centers per-byte
Vref (to ensure per-bit Vref offsets are as small as possible) and
the second stage centers per-bit Vref.
Because this procedure uses the "sense amp offset cancel" mode, it
does not rely on DRAM being trained. It is assumed that the memory
controller simply makes sense amp output levels observable via the
`DDR_DATA_TRAIN_FEEDBACK` register and that the memory bus is idle
during this training step (so the lane voltage is Vdd / 2).
Note: This procedure will need to be adapted for Broadwell because
it has per-rank per-bit RxVref registers, whereas Haswell only has
a single per-bit RxVref register for all ranks.
Change-Id: Ia07db68763f90e9701c8a376e01279ada8dbbe07
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81948
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
