Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b14ee0682ae1f2212ab43977c076687706434ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75557
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d71928 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
forward from Stoneyridge to the newer AMD SoCs.
TEST=On Mandolin the PCI Express Root Complex now shows up in the device
manager on Windows 10 and when switching the view to 'devices by
connection', all PCI(e) devices are shown below it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This differs slightly from picasso. The PCI BAR region is between TOM1
and CONFIG_MMCONF_BASE_ADDRESS. This matches what the Intel platforms
are doing. It also matches what linux derives from the e820 tables:
> [mem 0xd0000000-0xf7ffffff] available for PCI devices
Picasso currently declares the region between TOM and IO_APIC_ADDR.
This region includes MMCONF. We don't want to map any PCI BARs in this
region.
TEST=Boot majolica and check logs
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff]
pci_bus 0000:00: root bus resource [bus 00-3f]
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4ff02012795e2166e3a4197071b1136727089318
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50893
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
