Now that the ACP device is always present in DSDT move the
MSG0 method and helper functions into DSDT. This allows to clean
the common ACP code and reduces differences in the runtime code
pathes. The newly introduced DSDT is also verified at compile time.
Change-Id: Ifc55278aa66abcb54691017738cc843e3088d8e8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91159
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the ACP ACPI device called ACPD from SSDT to DSDT so that a SoC
or a mainboard DSDT can extend the ACP configuration.
Therefore, drop acpi_device_write_pci_dev() in SSDT. Introduce a STAT
variable in ASL, which defaults to 3 (present, enabled, hidden, not ok)
when the device is set to "off" in the devicetree.cb, since the PCI
device is not actual disabled by FSP. When not disabled in devicetree.cb,
STAT will be overriden in SSDT with the actual device status. The STAT
variable is returned by _STA method.
The ACP child devices where seen on Phoenix and KrackenPoint and not
seen on Rembrandt, Cezanne or Mendocino.
Assume older platforms do not have ACP child devices in ACPI.
TEST=Booted on AMD birman_plus (glinda) and verified ACP is working.
TEST=Set ACP device to off and verified it's marked hidden on Windows 11
Device Manager.
Change-Id: I31c3f01f83f27d0121f9e003e60a7f12d49427f6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Root complex always resides at 0:0.0 and is always enabled.
Add a static device in DSDT that can be extended later on.
Change-Id: I1d45f7cd732c41343ac154c313a7ca368b0ea2b3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91183
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Select SOC_AMD_SUPPORTS_WARM_RESET on faegon only.
Glinda doesn't currently support warm resets.
Signed-off-by: Patrick Rudolph <patrick.rudolph@amd.com>
Change-Id: Ic7a011827d16685bb3f2a13a576b7832a4929119
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently FSP modifies the AOAC bits of the FCH devices and
thus needs the current status passed via fch_rt_device_enable_map.
By default fch_rt_device_enable_map is 0, effectly disabling all FCH
devices, including the debug UART. This causes a hang at boot.
Fill fch_rt_device_enable_map in SoC code.
TEST=Can boot on amd/birman_plus again.
Change-Id: I00ef35ea6fe11939c4154940fef8cb902955fe27
Signed-off-by: Patrick Rudolph <patrick.rudolph@amd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add all known PCI bridge devices to the DSDT. This allows to reference
the devices from DSDT, allowing to add more SoC DSDT code and it allows
mainboard developers to add board specific ACPI code for devices behind
PCIe bridges (like NVMe D3cold).
Currently this is only possible using SSDT generators. The SSDT ACPI
generation is also broken, since the mainboard SSDT is run before SoC
SSDT, causing the interpreter to complain about missing devices.
TEST=Still boots on amd/birman_plus. No ACPI errors seen in dmesg.
Signed-off-by: Patrick Rudolph <patrick.rudolph@amd.com>
Change-Id: I9d6f84b97fa943bb531d6b7b3f16c0422cd7901f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89456
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Load microcode from CBFS before setting up MTRRs using
x86_setup_mtrrs_with_detect(), since it will remove caching the
SPI flash MMIO area and thus slow down CBFS accesses.
TEST=Booted on AMD/crater with CBFS_VERIFICATION enabled. The system
boots 6msec faster than before.
Change-Id: I3fafb98c1348daa549448707db88954316a12ff2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90891
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In the first boot after coreboot is flashed, ABL FW performs
memory training and passes APOB data to coreboot. coreboot
writes APOB data in SPI flash along with hash of the APOB data.
If APOB signature is not written in CMOS, Memory context is
not restored by ABL in subsequent boot and full training is
initiated which increases boot time.coreboot keeps writing the
APOB data to flash in every boot due to hash mismatch of APOB
data which inturn increases boot time.This change fixes the
issue of ABL FW not doing Memory Context restore due to missing
CMOS signature.On some older platforms FSP writes this signature
unconditionally and hence this coreboot patch doesnt impact
the older platforms.
TEST= Validated on crater platform. APOB write is not initiated
by coreboot on every boot. APOB write to flash happens only once
after the coreboot flash.
Change-Id: Id799d0d2ed9f54e29db7681509f3d66c1638b6ac
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90947
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Turin OpenSIL driver and submodule pointing to turin_poc branch
of github.com/openSIL/openSIL repository.
Change-Id: Idd6d4e78a055926061de330da620c943b42a50a7
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Also removes some dead code below which uses a dongle.py binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ia9b31a79f7637d31bbd824a8f6ad9137df429711
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90818
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The other AMD SoCs already use the XHCI_GEVENT define and since it's
defined as GEVENT_31, this won't change the behavior.
Change-Id: I895f453497f6e03e1aff237ba6d6ec1ebecfaaaf
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Some SoCs may require additional programming to get the SPI TPM
work properly. This hook is especially needed if mainboard selects
TPM_MEASURED_BOOT_INIT_BOOTBLOCK and TPM is initialized before any
vendor silicon initialization code runs (FSP or OpenSIL).
Change-Id: I90dbcbfb554ac3cfbcf23d708c3440d27959c632
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Update the SOC code based on the PPR for C1 stepping, doc 57238.
1. Turin CPU has less USB ports than Genoa, so the chip structure has
to reflect that. The number of ports has been reduced to match the
hardware capabilities.
2. Added early FCH initialization: legacy ISA devices, eSPI, I/O
decoding, UARTs, SMBus and SPI.
3. Updated AOAC device numbers.
4. Updated MMIO and I/O base addresses for CPU internal devices.
5. Added reserved RAM and MMIO reporting.
6. Adjusted root complex layout to match Turin IOHCs base addresses
and fabric IDs.
7. Extended chipset.cb devicetree to match the layout of devices on a
single socket Turin system.
Change-Id: I5272c1f2cd2aa259569d0bc6fa5c4073907b1673
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ESPI1 MMIO is reported in ACPI already, but the resource allocator
must also know about it to avoid the allocation of resources in that
range.
TEST=Boot Gigabyte MZ33-AR1 and verify that ESPI1 address (0xfec30000)
is reported for PCI device 00:00.14.3 in coreboot logs:
dev: PCI: 00:00:14.3, index: 0x3, base: 0xfec30000, size: 0x1000
Change-Id: Ic4024e6aa37bd7568dcecbd7cae29be9ae587a7f
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
More complex systems, such as servers, have multiple IOMMUs. For
example, Turin CPUs have a total of 4 IOMMUs per socket. Abort IVHD
generation only if IOMMU is not present on domain 0. For other domains
simply continue the loop, so that other domains have their IOMMUs
described properly in the IVRS. To keep simple systems working as
before, IVHD generation is aborted, if IOMMU is not present in domain 0.
TEST=See IOMMUs on domains 1,3,4,6 being skipped during IVHD generation
instead of IVHD generation being aborted on domain 1 on
Gigabyte MZ33-AR1 console log.
Change-Id: Icd3a51621908dc3ee5c85aa1e5814f3b3ac69007
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89111
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On AMD glinda up to 3 CS# lines are available. Drive the correct
SPI flash chip select using register 0x1d when necessary. This
allows to modifiy the contents of the "backup" SPI flash when
booting from the primary SPI flash.
TEST=Can access backup SPI flash on AMD Glinda SoC.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I446ef54a27c7a29155948cef9219cdef7b52b776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The PSP can choose the SPI flash to boot from. One such case
would be a corrupted EFS or invalid PSP directory tables.
Read the active SPI CS index from register SPI_ALT_CS_REG and
use it in boot_device_spi_cs().
Register name is taken from Linux kernel.
TEST=Booted on AMD/glinda with EFS on SPI CS0 corrupted. Will
boot from SPI CS2 and log shows:
spi_init: Booting from SPI CS2
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2c806d4d1563aa2403e84dec9f8768081e5e208a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The AMD fTPM uses the CRB interface, but doesn't implement all registers
defined in the TCG specification. Add a new driver that deals with the
reduced register set.
The reduced CRB MMIO register space has:
- A START register to ring the doorbell
- An error STATUS register with only one bit
- DMA address and size register for the CRB
- No other status or control registers
- No way to read current locality (assumption is locality 0)
- No interface ID register
- No read only registers
The TPM interface also assumes that the DRTM is always using locality 0.
The fTPM needs to access the SPI flash and this is currently done using
the PSP SMI handler. Thus the fTPM will only operate after SMM has been
set up.
The fTPM needs the PSP directory files type 0x04 and type 0x54. When
the regions are missing or corrupted the fTPM won't be operational.
Based off https://github.com/teslamotors/coreboot/tree/tesla-4.12-amd
TEST=Works on AMD glinda (Fam 1Ah).
This adds the following new log messages:
[DEBUG] PSP: Querying PSP capabilities...OK
[DEBUG] PSP: Querying fTPM capabilities... OK
[DEBUG] PSP: Querying fTPM capabilities... OK
[DEBUG] TPM: CRB buffer created at 0x7b5ee000
[SPEW ] fTPM: CRB TPM initialized successfully
[INFO ] Initialized TPM device fTPM
...
[DEBUG] PSP: Querying fTPM capabilities... OK
[DEBUG] TPM2 log created at 0x7b5b1000
[DEBUG] PSP: Querying fTPM capabilities... OK
[DEBUG] ACPI: * TPM2
[DEBUG] ACPI: added table 4/32, length now 68
Change-Id: I780bdab621228e12b37f3a89868e16bc62a05e7b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88247
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
The number of MCAX register used inside an MCA BANK changed from phoenix
onwards. Since phoenix all 16 MCAX register are used inside an MCA bank.
According to spec:
The MCA_SYND register stores a syndrome associated with the error logged
in MCA_STATUS or MCA_DESTAT. The “syndrome” may include syndrome values
associated with an error correcting code or other information about the
error. The contents of this register are valid if MCA_STATUS[SYNDV] bit
is set to 1 or MCA_DESTAT[SYNDV] bit is set to 1.
source: AMD64 Architecture Programmers Manual Rev 3.42
Change-Id: I20a31776d4b031c810ef0dc6502c421ade6f4315
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Refactor code to use less redundant PCI accesses to decrease boot time.
Change-Id: Ic2bb610ebf22dd43580ac94360d905b1c782224a
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90641
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Starting with Turin there are 8 IOHCs per SoC. Add new definitions
for the missing IOHCs. Based on Turin C1 PPR (doc 57238).
Change-Id: I31e93e680e3f0ba03d2595f632d6827b4e3042b8
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90368
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Strip quotes from CONFIG_AMDFW_CONFIG_FILE, otherwise the IF condition
may not catch the case when CONFIG_AMDFW_CONFIG_FILE is an empty string.
TEST=Omit PSP blobs when building coreboot for Gigabyte MZ33-AR1 by
clearing the AMDFW_CONFIG_FILE path.
Change-Id: I1ecf61844c03c89b3429e23936172f79c8d4b2f4
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90367
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add PCI I/O-based SMN accessors. These accessors can be used for
early workarounds when the PCI ECAM MMCONF is not working yet.
An example of such workaround is the patching of PCI ECAM MMCONF
base address in Turin SoC, which has to be done via SMN, but it
cannot use PCI ECAM MMCONF to access SMN yet.
Change-Id: I5e0faaa48e4d7b4479e3af9b795ad2a879f569fd
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Move the xxhash lib to commonlib/bsd folder so that it can be
easily included by tools. Update use of standard headers to
allow compilation on POSIX compatible systems as well.
Use the new xxhash lib in cbfstool over the existing duplicated
xxhash lib residing in lz4/lib.
Change-Id: I21041409d5b734cecf43294dcaf3bf17531dbc15
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89682
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FWTS complains on HPET base not being found in DSDT/SSDT:
Test 3 of 4: Test HPET base in DSDT and/or SSDT.
WARNING: Test 3, Test skipped because HPET Device address was not
found in DSDT/SSDT.
Declare HPET device under LPC device to fix the issue.
TEST=Run FWTS on Gigabyte MZ33-AR1 and see no error in HPET tests.
Change-Id: I68b872291dc93320e7a0b33a79e3336e1372b178
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89924
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on AMD doc #48882 PUB Rev 3.10 [1]. Now, the IVHD type 11h and
40h have a second 64bit EFR value that should be filled with IOMMU MMIO
offset 0x1A0 register value if EFR is supported.
[1] https://docs.amd.com/v/u/en-US/48882_IOMMU
Change-Id: I0da79bed8994671c651328cd7a29d9480a122528
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
GCC generates correct code for __builtin_bswapXX() on all architectures,
including ArmV4. It seems that whatever bug caused this to not work back
in commit 879ea7fce8 ("endian: Replace explicit byte swapping with
compiler builtin") has been fixed now. We can eliminate the swabXX()
functions and simplify the code.
All instances that had been calling these functions directly should have
been using real endianness conversions anyway.
Change-Id: I19713fd009aa5c0e01c4a42e0cf012364d6bed60
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90438
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
AMD systems have a TOM2WB bit in SYS_CFG MSR to forcefully cover the
address space between 4GB-TOM2 as WB. Any WB MTRR that falls into that
range may be skipped from programming. It can save a lot of MTRRs when
calculating the MTRR solution. It is especially needed when using a
temporary MTRR to cover the flash as WP, as the MTRR space gets more
fragmented.
Add checks for SYS_CFG TOM2WB in the MTRR driver and skip the WB MTRR
ranges when possible.
TEST=Successfully enable temporary MTRR range for flash on Gigabyte
MZ33-AR1.
Change-Id: Ie9af9b54a1037c843d8f019506af761a8d8769d0
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89199
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use is_dev_enabled() on devicetree device to enable/disable USB4 devices
by updating the corresponding FSP UPDs.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If0ae88eaaf88954159b55fdf030eb96d74ee29f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Glinda and Faegan are closely related and there's only very minimal
difference from the coreboot viewpoint, so Feagan is added as Glianda
variant and not as a new SoC folder. Faegan has a different CPUID, so
it's added to the CPU table, and some GPIO muxes have a few more valid
settings to route the MDIO pins related to the 2 XGBE controllers to
GPIO pins.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I57699089a4a3ac7ddb037f254d42cb043b816c55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90417
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some specific Glinda SoCs support dual 10G PCI ethernet devices.
Add defines and chipset entries for XGBE0 and XGBE1.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7e3bb1819165a7c2f4284b76450f831bb99b1ad3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90416
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Glinda actually supports warm reset, so we don't need to toggle the
PwrGood for all resets.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I70e9a13b84219847795e65b39c52114592a2cb61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90415
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fill in the DIMM voltages as reported by FSP.
Change-Id: I22d6bac93d8e8b8130f89a440be661829c700fe9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
There is ESPI1 fixed resource living 64K above the ESPI0 fixed
resource. Report it if the hardware has ESPI1 bus.
Change-Id: I7245850450cfa9de326f26c83c4f01c8d167f8be
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
On systems with AMD ROM armor enabled the SPI base address register
in LPC bridge PCI device space is not accessible (returns all FFs).
In such case the AML code will not be able to retrieve the SPI BAR
and report it properly. Use fixed bases instead to avoid running
into this problem in the future.
Change-Id: Ia01508e5ddf2da053f9bf4116c5e05b89500f772
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89488
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On AMD non-car system the bootblock is integrated into PSP directories
and copied to host DRAM before reset vector. coreboot knows the exact
DRAM range where the bootblock will be copied to based on
CONFIG_ROMSTAGE_ADDR and CONFIG_C_ENV_BOOTBLOCK_SIZE. The code only
needs to check the exact coreboot program size using linker symbols
measure the right memory range.
Based on the Apollo Lake tspi_soc_measure_bootblock, create an
equivalent implementation for AMD platforms using mem_region_device.
TEST=Bootblock is measured properly on Gigabyte MZ33-AR1 when measured
boot is enabled and CRTM initialization no longer fails.
Change-Id: I163e6b0ef0313e7dbb66ba5b07c35724a14276aa
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89145
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
More complex systems, such as servers, may have scarse space below 4G
for MMIO. With multiple root bridges needing some 32bit MMIO space it
becomes very hard to squeeze all resources. Allow to set 64bit ECAM
MMCONF base address in the MSR to free some space in the 32bit address
space. Of course using 64bit ECAM MMCONF requires the use of x86_64
mode and a proper amount of address space to be mapped with page
tables.
TEST=Set ECAM MMCONF to 0x3ffb00000000 on Gigabyte MZ33-AR1 and observe
the PCI access works in the console output.
Change-Id: I80e5a1bed33e12aa089355df64cc29887acc27f2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89112
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the I3C controllers to the ACPI tables. Most of the ACPI code needed
for that is added to the DSDT, since everything, but the enable status
of the I3C MMIO devices is known at build-time. To handle the I3C
controller enable status, each ACPI device contains the STAT name with
the value of 0 in the DSDT and when the device is enabled this STAT name
will be overridden in the SSDT.
TEST=OS loads the I3C kernel modules on amd/birman_plus.
Change-Id: I309d54c81056486573c32d4da54de61b36b5c378
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The following error is observed in Linux:
[ 30.255680] ACPI Error: Aborting method \_SB.FUR4.AOAC._OFF due to previous error (AE_AML_LOOP_TIMEOUT)
It caused a boot delay issue in the virtualization case above due to
some mmio regions not being passed through and the acpi interpreter
waiting.
reserve MMIO regions which are used by ACPI code in order to fix this
issue.
source: "Address Space Mapping" Table in relevant PPRs.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ia12a3dea0e24ae24fa1f7db7c7f2bd9f7dd6a591
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Adds skeleton code so that the HEST ACPI table is included as part of
the ACPI tables propagated to the OS.
The ACPI table can be included by mainboards by selecting
SOC_AMD_COMMON_BLOCK_ACPI_HEST.
TEST=Select the option, build the mainboard and see the output in Linux:
[ 0.282277] HEST: Table parsing has been initialized.
Change-Id: I69886a19764d6974cbe129a8a6bf717f7808fb08
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88113
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com>
The renoir variant has larger APOB data.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7b7da3b35f2795deb785f82326f3e6c640f6e9ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Renoir actually supports warm reset, so we don't need to toggle the
PwrGood for all resets.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I45d6b559874d67b886c65f7ad722f96eba415399
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90211
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Unable to passthrough the UART0 in domU when UART1 enabled in dom0
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7ccf366dbac556f68096382644f3e72b13e2dbf9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90210
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PSP_ADDR_MSR is programmed into the BSP by FSP, but not always
propagated to the other cores/APs. Add a hook to run a function
which will read the MSR value from the BSP, and program it into the
APs, guarded by a Kconfig.
It only writes the MSRs of the APs if they are not initialized yet.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I45771e596ac4354dd233a47fcae33012d9c0a6c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Its useful if you have some binaries downstream which are not published
yet.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I00f67e6eb93af095e3ae1f4851d13cd7666a9851
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90180
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add FSP folder for Renoir and include it in the build from soc/cezanne
path. Cezanne and Renoir are very similar but there are still enough
changes to justify a separate vendorcode directory.
Change-Id: Id7f51a70c02ea632d87a635e92a6c422ac369bef
Signed-off-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
AMD Renoir soc is very similar to Cezanne and has been used without
differentiation until now. Create the separation between SOCs using
Kconfig option to facilitate the customization of different features.
Also update SOC_AMD_RENOIR use on the crater mainboard.
Change-Id: I4783c4e3b17032b6d26ef67ddf954df3ce68fdf0
Signed-off-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87215
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Convert SATA controller ACPI OperationRegion and Field definitions from
static ASL code to runtime-generated acpigen code. This allows the SATA
registers (STB5, SB5, and port fields P0ER-P3PR) to be conditionally
included in ACPI tables only when the SATA controller (device 00:11.0)
is enabled in the devicetree.
Including them unconditionally when the SATA PCI device is disabled
causes Windows to BSOD (ACPI BIOS ERROR), since the OpRegion references
a non-existent device.
Changes:
- Move SATA OperationRegion generation to sata.c using acpigen APIs
- Remove static SATA fields from acpi/pci_int.asl
- Add stoneyridge_sata_ops with acpi_fill_ssdt callback
- Update chipset_st.cb and chipset_cz.cb to use stoneyridge_sata_ops
- Remove Kconfig for SoC common SATA code, since no longer used
This reduces ACPI table size when SATA is disabled and properly scopes
SATA registers to the SATA device.
TEST=boot Win11 on google/liara without a BSOD
Change-Id: I6e7a9a60e3622368eac83c36efd384c8d92c2b05
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
