Age | Commit message (Collapse) | Author |
|
Even though it has an 'amd_' prefix, the amd_pci_domain_fill_ssdt
implementation doesn't contain any AMD-specific code and can also be
used by other SoCs. So factor it out, move the implementation to
src/acpi/acpigen_pci_root_resource_producer.c, and rename it to
pci_domain_fill_ssdt. When a SoC now assigns pci_domain_fill_ssdt to its
domain operation's acpi_fill_ssdt function pointer, the PCI domain
resource producer information will be added to the SSDT.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7bd8568cf0b7051c74adbedfe0e416a0938ccb99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80464
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Drop the unneeded data_fabric_set_mmio_np function and the corresponding
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems
with only one FCH, its MMIO region will be subtractively decoded and
there's no need to add a non-posted data fabric MMIO region after the
FSP/openSIL has already configured the data fabric decode windows. In
systems with more than one FCH, openSIL will already take care of
initializing everything for the additional FCH, so we also won't need to
do anything in that case. Since dropping this function also removes both
data_fabric_print_mmio_conf calls before and after adding the unneeded
non-posted MMIO region, replace the data_fabric_set_mmio_np call with a
data_fabric_print_mmio_conf call to still print the data fabric MMIO
decode regions set up by the FSP/openSIL.
TEST=Mandolin still boots successfully
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Make the initialization of the IOAPIC(s) in the PCI root(s) common
across all AMD family 17h+ SoCs. For this the more general
implementation from the Genoa code that supports multiple PC roots is
moved to the common AMD code. All other family 17h+ SoCs are then
adapted to use the common code. For those non-Genoa SoCs, the
initialization of this second IOAPIC is moved from the northbridge
device to the domain device above to match Genoa.
Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized
on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Since the definition is the same for all SoCs, move it to the common
amdblock/acpi.h header. Since the Stoneyridge northbridge.c file also
includes this prototype, remove the static attribute of the function
there.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib9aa215f2b4ba58f43fed2c751d989f1719e0a17
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80221
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's not the AGESA code that generates most of the ACPI tables, so
rename the function. This also aligns the other SoCs more with Genoa.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6b2e6c4cb7139c8bde01b4440ab2e923a1086827
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80217
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move the call into the FSP code to a file in the common AMD FSP code to
isolate the FSP-specific parts of the code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic8236db7ac80275a65020b7e7a9acce8314c831c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Use amd_pci_domain_read_resources function that gets the configured MMIO
regions for the PCI root domain from the data fabric's MMIO decode
registers instead of using pci_domain_read_resources. This results in
the same IO port range being used by the allocator, but makes sure that
the allocator will only allocate non-fixed MMIO resources in the address
ranges that get decoded to the PCI root complex. In order for the PCI0
_CRS ACPI resource template to match the decoded PCI root domain MMIO
windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code
instead of having a mostly hard-coded _CRS method in the DSDT. This
makes sure that the OS will know about the MMIO regions it is allowed to
used.
Before this patch, only the region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the
PCI0 _CRS method. Also the resource allocator didn't get any constraint
on which address ranges it can use to put the non-fixed MMIO resources.
This approach worked until now, since all address range from 0 up to
right below TOM1 was filled with either usable or reserved memory and
the allocator was allocating beginning right from TOM1, since it was
using the bottom-up allocation approach and everything below TOM1 was
already in use. The MMIO region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window
configured in the data fabric's MMIO decode registers, so everything
seemed to work fine. However, when either selecting
RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke
badly. This was partially due to the allocator putting non-fixed MMIO
resources in regions that weren't decoded to the PCI root, since AMD
family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the
wrong ranges the allocator used also weren't advertised in ACPI.
TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends
up with a non-working system when the MMIO ranges aren't reported
correctly to the resource allocator due to the reasons descried above,
Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2
payload and Windows 10 boots with EDK payload. There's however an EDK2
bug that results the MMCONFIG region not being advertised in the e820
table, which causes Linux to not use the MMCONFIG and fall back to the
legacy PCI config access method. This only happens with EDK2 payload and
everything works fine when using SeaBIOS as payload. That e820 issue is
unaffected by this patch.
At the end of the data_fabric_set_mmio_np call, this is the data fabric
MMIO register configuration:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
The limit of the data fabric MMIO decode register 1 is configured as
0xffffffffffff although this is way beyond the addressable memory space.
add_data_fabric_mmio_regions fixes this up, so the range that gets
passed to the allocator in that case is 0x7fcffffffff which takes both
the reserved most significant address bits used for the memory
encryption and the 12GB reserved data fabric MMIO at the top of the
usable address space into account.
This results in the following domain ranges passed to the resource
allocator:
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff
DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff
DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff
The IO resource producer region is split into two parts to not cover the
PCI config IO region resource consumer. This results in these resources
being added to the PCI0 _CRS resource template:
amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0'
PCI0 _CRS: adding busses [0-3f]
PCI0 _CRS: adding IO range [0-cf7]
PCI0 _CRS: adding IO range [d00-ffff]
PCI0 _CRS: adding MMIO range [fc000000-febfffff]
PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff]
PCI0 _CRS: adding MMIO range [d0000000-f7ffffff]
PCI0 _CRS: adding VGA resource
Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-3f]
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 window]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window]
pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window]
pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window]
Another noteworthy thing I wasn't aware of at first when testing ACPI
changes on Windows 10 is that a normal Windows shutdown and boot cycle
won't result in it processing the changed ACPI tables; you have to tell
it to reboot to do a proper full boot where it will process the updated
ACPI tables (and fail if it dislikes something about the ACPI tables and
bytecode).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The device operations for the CPU bus are identical for all AMD SoCs, so
introduce a common device operations struct for this and use it in all
AMD SoC's chipset devicetrees as ops for the CPU cluster.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id32f89b8a33db8dbb747b917eeac3009fbae6631
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The data_fabric_set_mmio_np function is effectively identical, so move
it to common code.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I58e524a34a20e1c6f088feaf39d592b8d5efab58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This removes the need for a lot of boilerplate code in the soc code to
hook up device_operations to devices.
Change-Id: I2afc1855407910f1faa9bdd4e9416dd46474658e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The logic behind I2C bus initialization, I2C MMIO base address getter
and setter, I2C bus ACPI name resolution are identical for all the AMD
SoCs. Hence moving all the SoC agnotic parts of the driver into the
common driver and just configure the SoC specific parts into individual
I2C drivers.
BUG=None
TEST=Build Dalboz and Grunt. Boot to OS in Dalboz. Ensure that the I2C
peripherals are detected as earlier in Dalboz. Verify some I2C
peripheral functionality like trackpad and touchscreen.
Change-Id: Ic9c99ec769d7d8ad7e1e566fdf42a5206657183d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Suggested-by: Kyosti Malkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51509
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that all ACPI names are moved to the corresponding PCI devices, the
functionality in the chip code isn't needed any more.
TEST=No warnings or errors on coreboot console or in the Linux ACPI
parser.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2d39b6d4bd53cd0ca189fb6f55ca26dab68793fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50822
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0f1dce92475ce0ee05a8d090fc3b3d1e613f62c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50821
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5471f7be41683ef4a14107f38e93339080d01bdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50820
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I47415be02571240d3cecfdb91cb9f8097c5b7fde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50819
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7517d81d41422cfa10fabd12ab3da4f61c3f9034
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50818
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This function isn't used outside of the same compilation unit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I332046341bc7a5a499355f2147296e8c09d7e0ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50817
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
ACPI S3 is a global state and it is no longer needed to
pass it as a parameter.
Change-Id: Id0639a47ea65c210b9a79e6ca89cee819e7769b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
acpi_is_wakeup_s3() is defined in acpi/acpi.h
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I53916cd15bb28484eb06be4d43f26152de159391
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50125
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Also move the fch_* functions in the header file in the order they get
called.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9b6c6ad744b26f8488015c38a84d7e21c7d7687a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50093
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The default case is only needed to make the compiler happy.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idf54e7128f9e9d96f15ac7ab121f22621e033fac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49941
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now pci_domain_ops in chip.c can also be marked as static.
Change-Id: Ia92b778a5882d991b391dc29aeee0a5615677913
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48315
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is now a generic xhci driver we can use to generate the xHCI ACPI
nodes.
BUG=b:154756391
TEST=Boot trembyle and look at ACPI table
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3e9973dd416ccd51971f4d9410bed991eb7c3c41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41901
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds a driver pcie_gpp.c which provides device_operations
for external and internal PCIe GPP bridges. These device operations
include standard PCI bridge operations as well as operations for
generating ACPI node for the device and returning appropriate ACPI
name for it.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I9f8809c2735bdc09435deda91a570c89e71e8062
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This reverts commit d5f1e0f9734273f79ebd313bb6a17eda04c22c11.
Reason for revert: FSP-S is now fixed to not touch the SPI
configuration registers. Thus, coreboot does not need to reconfigure
SPI after FSP-S has run.
BUG=b:153506142
TEST=Verified that SPI configuration registers look the same before
and after FSP-S has run. em100 works fine without any additional
changes in coreboot to reconfigure SPI.
Change-Id: I4832e62e0331aa39abe0cca7725915262bb2cf83
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin Frodsham <justin.frodsham@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change reconfigures SPI speeds after FSP-S has run since
FSP-S is currently configuring the SPI frequency when it should
not. Until FSP-S behavior is fixed, this workaround needs to be
applied.
BUG=b:153506142
TEST=Verified that em100 works fine.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id9b8330c6f82c7162ff91e8cc10160fdd8cfedab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This change adds device_operations for UART MMIO devices that provides
following operations:
1. uart_acpi_name: Returns ACPI name of UART device. Generation of
UART device node is not yet moved to SSDT, but will be done in
follow-up CLs.
2. scan_bus: Uses scan_static_bus to scan devices added under the UART
devices. This allows mainboard to add devices under the UART MMIO
device.
Change-Id: I18abbe88952e7006668657eb1d0c177e53e95850
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
We don't use amd_setup_mtrrs, bsp_topmem or bsp_topmem2 in picasso.
BUG=b:147042464
TEST=Boot to OS on trembyle
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1941934975dfea4f189347811b003a33996c887a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change adds a helper function set_mmio_dev_ops() in chip.c which
is used for setting the dev->ops for MMIO devices based on the
comparison of MMIO address in device tree to the pre-defined base
addresses in iomap.h.
Call to i2c_acpi_name() is replaced with set_mmio_dev_ops and scope of
i2c_acpi_name is restricted to i2c.c since it is not required to be
exposed out of that file.
Change-Id: I31f96cfe8267b0df37012baeb7cfcaec9c2280f6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Change-Id: Ia4508a9a087e3996ef7667280f8e2788421e5700
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
AGESA FSP provides additional ACPI tables that are required.
BUG=b:133337564, b:153675915
TEST=Boot trembyle to OS and dump ACPI tables.
ACPI: added table 2/32, length now 44
ACPI: * MCFG
ACPI: added table 3/32, length now 48
ACPI: * TPM2
TPM2 log created at 0xcc513000
ACPI: added table 4/32, length now 52
ACPI: * MADT
ACPI: added table 5/32, length now 56
current = cc635af0
Searching for AGESA FSP ACPI Tables
ACPI: * SSDT (AGESA).
ACPI: added table 6/32, length now 60
ACPI: * CRAT (AGESA).
ACPI: added table 7/32, length now 64
ACPI: * ALIB (AGESA).
ACPI: added table 8/32, length now 68
ACPI: * IVRS (AGESA).
ACPI: added table 9/32, length now 72
ACPI: * HPET
ACPI: added table 10/32, length now 76
Copying initialized VBIOS image from 0x000c0000
ACPI: * VFCT at cc63ca30
ACPI: added table 11/32, length now 80
ACPI: done.
ACPI tables: 102048 bytes.
[ 0.042326] ACPI: Early table checksum verification disabled
[ 0.048621] ACPI: RSDP 0x00000000000F0000 000024 (v02 COREv4)
[ 0.055011] ACPI: XSDT 0x00000000CC6310E0 00007C (v01 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.064506] ACPI: FACP 0x00000000CC634850 000114 (v06 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.073998] ACPI: DSDT 0x00000000CC631280 0035CF (v02 COREv4 COREBOOT 00010001 INTL 20200110)
[ 0.083488] ACPI: FACS 0x00000000CC631240 000040
[ 0.088623] ACPI: SSDT 0x00000000CC634970 00103D (v02 COREv4 COREBOOT 0000002A CORE 20200110)
[ 0.098114] ACPI: MCFG 0x00000000CC6359B0 00003C (v01 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.107606] ACPI: TPM2 0x00000000CC6359F0 00004C (v04 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.117100] ACPI: APIC 0x00000000CC635A40 0000A6 (v03 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.126592] ACPI: SSDT 0x00000000CC635AF0 00119C (v01 AMD AMD CPU 00000001 AMD 00000001)
[ 0.136082] ACPI: CRAT 0x00000000CC636C90 000810 (v01 AMD AMD CRAT 00000001 AMD 00000001)
[ 0.145573] ACPI: SSDT 0x00000000CC6374A0 005419 (v02 AMD AmdTable 00000002 MSFT 02000002)
[ 0.155064] ACPI: IVRS 0x00000000CC63C8C0 000126 (v02 AMD AMD IVRS 00000001 AMD 00000000)
[ 0.164556] ACPI: HPET 0x00000000CC63C9F0 000038 (v01 COREv4 COREBOOT 00000000 CORE 20200110)
[ 0.174047] ACPI: VFCT 0x00000000CC63CA30 00D469 (v01 COREv4 COREBOOT 00000000 CORE 20200110)
Signed-off-by: Matt Papageorge <matt.papageorge@amd.corp-partner.google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ic1e87c0f7a7c736592dd8c5c6765ef9a37ed7a40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41804
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I07100361705ce421131b8a5d772cb5ba2d8722ff
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41672
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I54eda3d51ecda77309841e598f06eb9cea3babc1
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This node is required so we can add child ACPI nodes.
BUG=b:147042464
TEST=Boot trembyle and confirm Bus A has a firmware node
$ cat /sys/bus/pci/devices/0000\:00\:08.1/firmware_node/path
\_SB_.PCI0.PBRA
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I18144a69ed28a913bc9a2523d69edf84a1402e7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This is a squash of the following commits. The original values were
wrong, and had confusing naming.
soc/amd/picasso: Get rid of *_DEVID from pci_devs.h
Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I203449499840bf0a6df8bd879fb7d2e75a16b284
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2153714
src/amd/picasso: Update PCI bridge devices
Orignal-Change-Id: I1fa9d52ce113eacdc5c9ba31ab46b6428a7d6ca9
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Zork: Reorganizing ACPI and adding PCI bridge configs
Signed-off-by: Pranay Shoroff <pshoroff@google.com>
Original-Change-Id: I1e2095567525f302dfd0bce8e39001250523180b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2063536
soc/amd/picasso: Fix soc_acpi_name() to use devfn instead of devid
Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I2486e7e0059e0528f53d5a158c9328636563fe93
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2153712
BUG=b:147042464
TEST=Build trembyle and boot to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I91bf7f9edcddf03027f8fdcaadf4e290ece10df5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Immediately following FSP-S, update the data fabric routing
registers to make the region between HPET and LAPIC as non-posted.
If AGESA is modified to do this, we can delete data_fabric_util.c. If
AGESA is modified to not program the registers, then we can simplify
data_fabric_set_mmio_np().
BUG=b:147042464, b:156296146
TEST=boot trembyle
Change-Id: Idbafaac158f5a4c533d2d88db79bb4d6244e5355
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41268
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Family 17h devices are designed with a new internal architecture,
frequently referred to as the data fabric. Although designed to
behave somewhat like the older integrated northbridge designs,
the D18Fx definitions are completely new.
The previous northbridge.c was copied from stoneyridge which is
completely different.
Change-Id: Id70cbda99657249179fb8cf5e461dd6a37ec9153
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41265
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
pci_domain_set_resources is duplicated in all the SOCs. This change
promotes the duplicated function.
Picasso was adding it again in the northbridge patch. I decided to
promote the function instead of duplicating it.
BUG=b:147042464
TEST=Build and boot trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
AMD has rewritten AGESA (now at v9) for direct inclusion into UEFI
build environments. Therefore, unlike the previous Arch2008
(a.k.a. v5), it can't be built without additional source, e.g. by
combining with EDK II, and it has no entry points for easily
building it into a legacy BIOS.
AGESA in coreboot now relies on the FSP 2.0 framework published
by Intel and uses the existing fsp2_0 driver.
* Add fsp_memory_init() to romstage.c. Although Picasso comes out
of reset with DRAM alive, this call is added to maximize
compatibility and facilitate internal development. Future work
may look at removing it. AGESA reports the memory map to coreboot
via HOBs returned from fsp_memory_init().
* AGESA currently sets up MTRRs, as in most older generations.
Take ownership back immediately before running ramstage.
* Remove cbmem initialization, as the FSP driver handles this.
* Add chipset_handle_reset() for compatibility.
* Top of memory is determined by the FSP driver checking the HOBs
passed from AGESA. Note that relying on the TOM register happens
to be misleading when UMA is below 4GB.
BUG=b:147042464
TEST=Boot trembyle to payload
Change-Id: Iecb3a3f2599a8ccbc168b1d26a0271f51b71dcf0
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34423
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change enables the use of AMD common block SATA driver for
Picasso. Since the common driver provides ACPI device name and PCI
device for SATA in SSDT, these are removed from picasso chip.c and
sb_pci0_fch.asl.
BUG=b:153858769
TEST=Verified that "STCR" device is correctly reported on trembyle in
SSDT.
Change-Id: Icfdcf9f5e08820b565aa9fcdd0cdc7b5c9eadcd5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40770
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change selects common block graphics driver for Picasso and also
adds PCI ID for Family 17h graphics controller to the graphics
driver.
Since the common driver provides .acpi_name() callback for graphics
device, soc_acpi_name() no longer needs to provide the ACPI name for
graphics device.
BUG=b:153858769
Change-Id: Id3ffcb05d8f8a253a0b27407d52d7907c507cabb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
`.read_resources` and `.set_resources` are the only two device
operations that are considered mandatory. Other function pointers
can be left NULL. Having dedicated no-op implementations for the
two mandatory fields should stop the leaking of no-op pointers to
other fields.
Change-Id: I6469a7568dc24317c95e238749d878e798b0a362
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40207
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Providing an explicit no-op function pointer is only necessary for
`.read_resources` and `.set_resources`. All other device-operation
pointers are optional and can be NULL.
Change-Id: I3d139f7be86180558cabec04b8566873062e33be
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40206
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: I22fffa0eab006be2bad4d3dd776b22ad9830faef
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
These two identifiers were always very confusing. We're not filling and
injecting generators. We are filling SSDTs and injecting into the DSDT.
So drop the `_generator` suffix. Hopefully, this also makes ACPI look a
little less scary.
Change-Id: I6f0e79632c9c855f38fe24c0186388a25990c44d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39977
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: David Guckian
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I4c110f60b764c97fab2a29f6f04680196f156da5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
Change-Id: I0c965e598e260ff8129aa07fb9fc5bf6e784e1d8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change to the appropriate device IDs. Remove the ehci resource
call. Remove overcurrent settings, as this will be passed to
AGESA in later change.
Remove unused USB2 ACPI name assignment.
Change-Id: Ic287a05b30ca03e3371cc4a30aaa93b236c6d3fb
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Family 17h will not use the Arch2008 (a.k.a. v5) wrapper. Remove
all source, support functions, and comments related to AGESA.
Family 17h requires v9 which has no similarities to v5 for
integration into a host firmware. AGESA v9 support will be added
via subsequent patches into the appropriate locations.
Change-Id: Iea1a41941a0ba364a6abaaf31cc8e1145db4a236
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33755
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Remove the mailbox call to notify the PSP that DRAM is ready. This
is not supported on Family 17h.
Remove the selectable SMU firmware. This is a feature of the PSP
bootloader and the standard bootloader doesn't contain the ability.
Clean up additional mentions of PSP within picasso.
Change-Id: I8abeb4c375dbff3b438cd18ccaaf66e11c86e72e
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
|
|
Change-Id: Ie9cf361ed0caba9c73727453c4a503557edc854d
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I9d0098082c224bbf5ab2b4f0f41eb8b5b729eec7
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Convert all remaining stoneyridge names to picasso.
Change-Id: I0ed3eaa5b1d2696448ae18b62c7218de59c61883
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
|
|
So that everyone can see what's being updated from stoney, we're
starting with a direct copy of the stoney directory. There are
arguments both for and against doing it this way, but I believe
This the most transparent way. We've moved much of the duplicated
stoney code into the soc/amd/common directory and will continue
that work as it becomes obvious that we have unchanged code between
the SOCs.
Makefile.inc has been renamed as makefile.inc so that it won't
build in jenkins until the directory is updated.
Other than that change, this is an exact copy of the stoneyridge
SOC directory which will be updated in the follow-on commits in
the patch train.
TEST=None
BUG=b:130804851
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|