| Age | Commit message (Collapse) | Author |
|---|
|
When DEBUG_SMI is selected, common code may use these helpers to handle
addressing and initialising the SoC-specific UART. Therefore, add uart.c
to be compiled into SMM.
Change-Id: If7c6f2346d5f9ffb371d51d1de6f0b695acedf10
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81072
Reviewed-by: Marvin Drees <marvin.drees@9elements.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This refactoring ensures bmp_load_logo() takes logo_size as an
argument, returning a valid logo_ptr only if logo_size is non-zero.
This prevents potential errors from mismatched size assumption.
BUG=b:242829490
TEST=google/rex0 builds successfully.
Change-Id: I14bc54670a67980ec93bc366b274832d1f959e50
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81618
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: I0203e77dd23fa026cd252abbda50f1e9f6892721
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
With SMM holding page tables itself, we can consider SMM support stable
and safe enough for general use.
Also update the respective documentation.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
When switching back and forth between 32 to 64 bit mode, for example to
call a 32-bits FSP or to call the payload, new page tables in the
respective stage will be linked.
The advantages of this approach are:
- No need to determine a good place for page tables in CBFS that does
not overlap.
- Works with non memory mapped flash (however all coreboot targets
currently do support this)
- If later stages can use their own page tables which fits better with
the vboot RO/RW flow
A disadvantage is that it increases the stage size. This could be
improved upon by using 1G pages and generating the pages at runtime.
Note: qemu cannot have the page tables in the RO boot medium and needs
to relocate them at runtime. This is why keeping the existing code with
page tables in CBFS is done for now.
TEST: Booted to payload on google/vilbox and qemu/q35
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When linking in page tables more place is needed. Size the bootblock is
top aligned, this has no impact the final size for existing setups.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I23f176d63d3c303b13331a77ad5ac6c7a19073d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
This does the following:
- Top align the bootblock so that the only the memory needed gets used.
This might slightly reduce the time the PSP needs to decompress the
bootblock in memory
- Use a memory directive to assert that the 16bit code is inside the top
64K segment
- Use the program counter less. While the BDF linker is happy about
running the program counter backwards, LLD is not. There is no
downside to this.
- Use a symbol rather that the program counter for sections. LLD gets
confused when (.) is used along with '<': it places the section at the
start of the memory region, rather than at the program counter. Using
a variable name works around this.
- Use a 'last_byte' section to make sure the first instruction is at
0xfff0. Both the BDF and the LLD linkers seems to work well with this
code
TEST: Both BFD and LLD are able to link the bootblock
Change-Id: I18bdf262f9c358aa01795b11efcb863686edc79c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
No functional changes. Refactor code such that there won't be any
compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled
in.
One might want to support both TPM families for example if TPM is
pluggable, while currently one has to reflash firmware along with
switching TPM device.
Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The memmap_early_dram struct is now only used inside the non-CAR
memmap.c, so move the struct definition there.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id2bb3d3a9e01e9bae9463c582cb105b95c673a38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Only the VGA MMIO range used the VGA_MMIO_* defines, but instead of
using constants for the end of the region before that and the beginning
of the region after that, the VGA_MMIO_* defines can be used.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I45c3888efb942cdd15416b730e36a9fb1ddd9697
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If3424df80655a150f27c7296a5683b528873816b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Since the code for reporting the memory map below cbmem_top is basically
identical for all non-CAR AMD SoCs, factor this out into a common
read_lower_soc_memmap_resources implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id64462b97d144ccdf78ebb051d82a4aa37f8ee98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81389
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
To bring genoa_poc more in line with the other AMD SoCs, move the
reporting of the memory map up to cbmem_top from the openSIL-specific
add_opensil_memmap function to read_soc_memmap_resources. This is a
preparation for making this code common for all newer AMD SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic06282baa3bb9a65d297b5717697a12d08605d2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81388
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move the gpp_bridge_* device functions that are bridges to the external
PCIe ports below the corresponding mpio chip. This avoids the need for
dummy devices and does things in a slightly more coreboot-native way.
TEST=PCIe lane config reported by openSIL is identical
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I7e39bf68d30d7d00b16f943953e8207d6fe9ef41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81340
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Convert the 'select SOC_AMD_OPENSIL_STUB' statement to a config option
and give it a prompt. This allows for internal development of openSIL
and corresponding coreboot source, and controllable using a defconfig.
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I2b48e2bbf71cd94ac7ecec13834ba36aa6c241ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
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>
|
|
When we're building non-AMD processors, don't bother building amdfwtool
unless we're specifically building all of the tools like for abuild.
Change-Id: I9021674a06d65a79e24020790d317ab947c505fe
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80714
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Glinda started as a copy of mendocino and GPP_CLK_OUTPUT_AVAILABLE was
not updated. GPP_CLK_OUTPUT_AVAILABLE should be 7 as per Processor
Programming Reference (PPR) (#57254), table "GPP ClkREQB Mapping".
Change-Id: I26e9dea58b2ddf5cbedbcccb8bcbc5f9efab3165
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80701
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use clrsetbits32p instead of clrsetbits32 to not need to cast the
uintptr_t address to void * in the function call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic29bf04866a7e1d5c831422f31803a724a41069b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
In follow up to commit 0452d0939e7d ("soc/amd: Factor out gpp_clk_setup function") use gpp_clk_setup_common for glinda as well.
Change-Id: If0c1cda0d36de48c7f7315a1b8203b0e53f63f75
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80699
Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use uintptr_t for the IOAPIC base parameter of the various IOAPIC-
related functions to avoid needing type casts in the callers. This also
allows dropping the VIO_APIC_VADDR define and consistently use the
IO_APIC_ADDR define instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I912943e923ff092708e90138caa5e1daf269a69f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80358
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
|
|
This function turns off gpp_clk for the devices which are disabled, and
adds the code to fix up the clock configuration depending on dxio
descriptors. Also this brings glinda in line with cezanne, mendocino,
phoenix and picasso. This also prepares glinda to use the common
function gpp_clk_setup_common.
Change-Id: Id66d1b7f0d8ec9a7cbd378ad6ad7d68eeab531f0
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80415
Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ie7bc4f3ae00bb9601001dbb71e7c3c84fd4f759a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80596
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In follow up to CB:80285 use gpp_clk_setup_common for picasso as well.
Change-Id: I68d498d08d5975037086c84ff2f7fdb265ee84d9
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80414
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This function turns off gpp_clk for the devices which are disabled, and
adds the code to fix up the clock configuration depending on dxio
descriptors. Also this brings picasso in line with cezanne, mendocino
and phoenix. This also prepares picasso to use the common function
gpp_clk_setup_common.
Change-Id: Ice2e3a5a78359da9a438434c7d4aa1eca878d396
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80413
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
gpp_clk_setup code in most AMD SoC is similar and it can moved to common
code. The only thing which is SoC dependent in this function is the SoC
config, hence keep it in SoC code and move everything else in new
gpp_clk_setup_common function which is in soc/amd/common. Picasso and
Glinda don't have pcie_gpp_dxio_update_clk_req_config fixup function so
they are addressed in later patches.
Change-Id: I7d7da4bfe079f07e31212247dbf3acd14daa6447
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80285
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I84a7b7b1b2c45b773c6f10b39e7813db3f96546e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80408
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In commit 30f36c35e75a ("soc/amd: rework DRAM and fixed resource
reporting") the reporting of the DRAM resources was moved from the
northbridge PCI device to the domain device. amd_pci_domain_fill_ssdt
didn't skip those DRAM resources when generation the resource producer
ranges which made Windows 10 very unhappy when it tried to evaluating
the ACPI tables causing it to reboot in a loop. To fix this, add a check
to also skip the resources that have the IORESOURCE_STORED flag set when
generating the resource producer ranges for the PCI root.
TEST=Windows 10 now successfully boots and reboots again on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b6d3fd8c7f89aa4364de7963d745aef8d6b6f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80407
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This makes it easier to reuse, e.g. if you want to do it twice in one
assembly file.
Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Printing the data fabric MMIO decode window configuration might be
useful and it also aligns this SoC more with the other AMD family 17h+
SoCs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I52f6655a5c63e31165549dcb6f5f95d4e74bad3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
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>
|
|
Since the USB configuration data structure is FSP-specific, add guards
on this part of the soc_amd_phoenix_config struct and the corresponding
include.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6c324421fbc3dc7b9a7bf6f5868785e9718147a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80298
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since openSIL configures the APCI IO port addresses, coreboot should not
overwrite them.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If10e5a9f52ab313ad1afebd7f9e722994d48b0a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80297
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add the calls to the openSIL stubs to do the silicon initialization, to
get the APCI IO ports, and to get the memory map.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6f37bf211e130cb44927f8a0e7f9134d246dfc1c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80296
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The configuration of the PCIe clock generators in the FCH was moved from
the FSP to coreboot, since all registers are documented. This
initialization is however tightly integrated in the rest of the PCIe
init code inside the reference code. In the FSP case, this code was
manually removed. openSIL will do that part of the initialization so
that there's no coreboot-specific change needed in openSIL. This will
also avoid the problems caused by mismatching configurations done by the
coreboot code and the PCIe init part of the reference code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6d64285a301ade6860c07e62dcb1a718e7a96644
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
In the FSP case we get this info via a HOB. It's currently unclear if
we'll get a data structure for this from openSIL or if we'll end up
being able to just read the configuration fro the hardware, so add a
get_pci_routing_table stub for now to be able to build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5003e287d6a3a9320922beaffff8a3a846531e14
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add the SOC_AMD_PHOENIX_OPENSIL Kconfig option to be able to build the
Phoenix code using openSIL instead of FSP for initializing the hardware.
Since there's currently no publicly available openSIL code for Phoenix,
SOC_AMD_OPENSIL_STUB is selected to have the stubs added to the build
instead of the actual openSIL code. The code added by selecting
SOC_AMD_COMMON_BLOCK_ACPI_CPPC relies on getting the information it
needs via a HOB, so for only select that option in the FSP case for now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If597ff3dc824ce832399d3efde32352b36354b21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Remove the unused soc/platform_descriptors.h include and add the missing
types.h include.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie0b066aa5dc657f7709f9cce734a025180bf5bfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Only add the vendorcode/amd/fsp/phoenix and vendorcode/amd/fsp/common
folders to the include search path when the SOC_AMD_PHOENIX_FSP Kconfig
option is selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I18668ab8578b297c328fdc647c8a95f540ac6272
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80288
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Provide 3 separate functions for each openSIL time point instead of one,
so that we don't need the xSIM-api header file to be included in
opensil.h to decouple the coreboot code more form the openSIL code. This
will allow to create an openSIL stub implementation to already get most
of the coreboot-side SoC code in place before the openSIL source code is
done and released.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I969bc0862560b7254c48f04e9a03387417f328bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Now that the SoC-specific memory map is reported on the domain device
instead of the northbridge device, factor out the
read_soc_memmap_resources function from root_complex.c to new memmap.c
file. For now each SoC still has its own memmap.c file, but the plan is
to eventually have a common implementation that works for all AMD family
17h+ SoCs. For that I'll still need to look closer into the differences
between the FSP and the openSIL integration though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifd7659e9a55de9df24118b6d6c885a21dc6f14a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Only call read_fsp_resources if PLATFORM_USES_FSP2_0 is selected in
Kconfig.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic63e0904ad04dbecfac1be4d59abbb8d4f9f11d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the
legacy PCI config space access is needed on all AMD SoCs, implement a
common add_pci_cfg_resources function that reports both and gets called
from amd_pci_domain_read_resources and don't report those in the SoC-
specific code any more. The only functional change is that on Genoa now
the IO ports used for the legacy PCI config space access get reserved.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
To make add_opensil_memmap match the other function that are directly or
indirectly called by amd_pci_domain_read_resources, pass the resource
index as a pointer instead of passing it by value and then returning the
new resource index.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a17e488a01cc52b2dab5dd3e3d58bdf3acb554d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Introduce read_soc_memmap_resources which gets called by
amd_pci_domain_read_resources for the first domain of the SoC to report
the DRAM and PCI config space access resources to the allocator. For
Genoa this allows to use amd_pci_domain_read_resources as read_resources
in the genoa_pci_domain_ops instead of needing to wrap that call to be
able to call add_opensil_memmap for the first domain. For the other
family 17h+ SoCs the moves the reporting of the DRAM resources and the
PCI config space access resources from the northbridge device to the
domain device.
TEST=Resources still get reported on Mandolin, but now under the domain
instead of the northbridge PCI device
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib19fd94e06fa3a1d95ade7fafe22db013045a942
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80268
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use an unsigned long as resource index type instead of an int to match
the data type used for the index in the resource struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0f58e32a535326116460545287cc59aaf94166a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Use an unsigned long as resource index type instead of an int to match
the data type used for the index in the resource struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I60ac0e30627001698565b7256421780f9a94bf65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80266
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Previously the code checked if the first downstream bus of the domain
was bus 0 in segment group 0 to only run certain code for the first
domain. Instead check if the domain number is 0 which should make the
code a bit easier to understand.
TEST=add_opensil_memmap still gets called exactly once on Onyx
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id8cc0078843e5e0361a53ba897cde508cee16aad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The x86 core always starts with an IP at 0xfff0. This needs to match in
the code.
Change-Id: Ibced50e4348a2b46511328f9b3f3afa836feb9a5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Only call amd_fsp_silicon_init if PLATFORM_USES_FSP2_0 is selected in
Kconfig. I'm not 100% sure about the data_fabric_set_mmio_np call yet,
but since it doesn't depend on PLATFORM_USES_FSP2_0 to compile, I'll
look into that one later.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2666f1ac0f0354146ffe005b3ce99484defda7a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80242
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
Multiple links are unused throughout the tree and make the code more
confusing as an iteration over all busses is needed to get downstream
devices. This also not done consistently e.g. the allocator does not
care about multiple links on busses. A better way of dealing multiple
links below a device is to feature dummy devices with each their
respective bus.
This drops the sconfig capability to declare the same device multiple
times which was previously used to declare multiple links.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Currently resource allocation starts top down from the default value
0xfe000000. This does not match what ACPI reports, so adapt
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT to reflect that.
Change-Id: I32d08ffd5bbd856b17f7ca2775c5923957d92c85
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The CRAT (Component Resource Attribute Table) isn't used on the APUs
from Renoir on and has also been marked as deprecated in version 6.5 of
the ACPI specification. So remove the 'TODO: look into adding CRAT'
comment from all SoCs from Renoir/Cezanne on.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3ea1e3678608b0ace2a1ff7fc104594e90c91476
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80227
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since the acpi_add_fsp_tables implementation is identical for all SoCs,
factor it out and move it to the common AMD FSP code. Also guard the
acpi_add_fsp_tables call in soc_acpi_write_tables with
if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function
and move the remaining parts of the soc_acpi_write_tables function to
the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with
Genoa and only leaves the FSP-specific code in agesa_acpi.c which will
be made common in a following patch. I decided against also renaming
agesa_acpi.c to acpi_fsp.c, since that would have made the diff less
readable and the files get deleted in a following patch anyway.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Factor out the code to add the CRAT ACPI table into a separate file and
add the acpi_add_crat_table function that can then be called from
soc_acpi_write_tables to better isolate all code specific to the CRAT
table.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4a7853748512811d3d4e124224fcd459e527522c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80223
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
ACPI_SCI_IRQ is defined as 9 for all AMD SoCs, so move the definition to
the common amdblocks/acpi.h. Since all but Stoneyridge's soc/acpi.h are
now empty, delete those files too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8210c98dc4cf2c6001d5273d132053278ff7fea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80222
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
The southbridge_write_acpi_tables function uses a struct device type
parameter, but device/device.h that provides the definition wasn't
included.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5245fa132ec9b84bbc483a31788bcd6fac0736e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
add_agesa_fsp_acpi_table should use the same type for the 'current'
parameter and return value as the calling soc_acpi_write_tables does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9f770b1d847ea28e4dbd96298a723d794b91a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
A pointer to soc_acpi_write_tables gets assigned to the
write_acpi_tables element of the device_operations struct, so make sure
that the function has the expected function signature which in this case
means using unsigned long as type for both the 'current' parameter and
the return value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iee45badb904fa20c6db146edbc00c40ca09361d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80218
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 verstage on PSP files in vendorcode from the fsp subdirectory
to a new psp_verstage subdirectory, since those files aren't specific to
the case of the FSP being used for the silicon initialization.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic47f8b18bc515600add7838f4c7afcb4fff7c004
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80209
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Instead of open-coding this functionality in all AMD SoCs, factor it out
into a common implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idb65c398b747e70ec67107e0a1d4bd6551501347
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80208
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Call setup_opensil, opensil_entry, and fch_init in the right order from
the init method of the SoC's chip operations. This brings this SoC both
more in line with the other SoCs and avoids using boot state hooks for
this which also makes the sequence in which those functions are called
easier to understand. Previously the boot states were used so that
setup_opensil was run before configure_mpio which was run before
opensil_entry(SIL_TP1), but since configure_mpio is called from
setup_opensil, this is no longer necessary.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same. The FCH init code now runs
before the resource allocation like on the AMD SoCs that rely on FSP.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic752635da5eaa9e333cfb927836f0d260d2ac049
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79985
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: Ida6e87908ae6996529057c8df12dbe046ee54b98
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80161
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie449267fe4fdd75110f577e1b9f748cd06140950
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
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>
|
|
Since the romstage code is very similar between all AMD non-CAR SoCs,
factor out a common romstage implementation. All SoCs that select
SOC_AMD_COMMON_BLOCK_PM_CHIPSET_STATE_SAVE call fill_chipset_state, so
this Kconfig option can be used to determine whether to make that call.
In the FSP case, amd_fsp_early_init gets called, while in the case of an
implementation that doesn't rely on an FSP to do the initialization,
cbmem_initialize_empty gets called to set up CBMEM which otherwise would
be done inside the FSP driver code. Since only some SoCs call
fch_disable_legacy_dma_io again in romstage right after
amd_fsp_early_init, introduce the new
SOC_AMD_COMMON_ROMSTAGE_LEGACY_DMA_FIXUP Kconfig option, so that the
SoCs can specify if this call is needed or not.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4a0695714ba08b13a58b12a490da50cb7f5a1ca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80083
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
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 and a preparation to make the
romstage of all non-CAR AMD SoCs common. Without isolating the call into
the FSP-M code, building the common romstage would fail for genoa_poc
due to fsp/api.h not being in the include path.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I30cf1bee2ec1a507dc8e61eaf44067663e2505ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80002
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>
|
|
fsp_m_params.c and fsp_s_params.c only contain FSP-specific code, so
only add those to the build if the SOC_AMD_PHOENIX_FSP Kconfig option is
selected. Other files have FSP-specific parts too, but those will be
reworked in future patches.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ife38ca6a548d7c3c2e765d9c9f30e0a4057bb373
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79984
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Split the SOC_AMD_PHOENIX Kconfig option into SOC_AMD_PHOENIX_BASE that
selects the non-FSP-specific options and SOC_AMD_PHOENIX_FSP that
selects both SOC_AMD_PHOENIX_BASE and the FSP-specific options. This
will help to separate the FSP-specific from the FSP-agnostic code. The
mainboards using this SoC now select SOC_AMD_PHOENIX_FSP instead of
SOC_AMD_PHOENIX.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e95fbfd9d16930ba3e6cc497557d61adba5a6fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79983
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: I18f1e37a06783aecde9024c15876b67bfeed70ee
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This reverts commit acbc4912375085a099c2427def464d6e481f2a90.
Reason for revert: CB:79525 fixes the issue that led to the revert
by not maintaining the heap in the SMM-stored copy of ramstage at all.
Change-Id: I3c8ef785486d275c9341859d34fce12253bd2bb9
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80023
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add initial support for multiple PCI segment groups. Instead of
modifying secondary in the bus struct introduce a new segment_group
struct element and keep existing common code.
Since all platforms currently only use 1 segment this is not a
functional change. On platforms that support more than 1 segment the
segment has to be set when creating the PCI domain.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The PCIE MMCONFIG base address value and size is updated correctly to
access the PCIE config space registers.
TEST=Verified that PCIE enumeration takes place in boot log
and config space registers are accessible.
Change-Id: Ifa8377df7a2973a88d414c217b5ed114c8ae5cc3
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79832
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The IOHUBS0 is a data fabric component which has a fabric id value
specific to SOC. Updated the fabric id for glinda SOC.
TEST=Verified that fabric ID is programmed correctly in boot logs.
Change-Id: I91ea7d7e7d9b247cf479471df287ba8c96b83d75
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79830
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As a preparation for the multi PCI segment group support, use
acpigen_write_BBN to generate the _SEG method that returns the segment
group number of the PCI root. Until the multi PCI segment group support
is enabled in coreboot, it will always return 0.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2a812dcc564c5319385e9ad482d29b2984a71b8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79924
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that Stoneyridge also reports the GNB IOAPIC on the domain and with
the IOMMU_IOAPIC_IDX resource index the common AMD MADT code expects, we
ca switch over to using this common code on Stoneyridge too.
TEST=The resulting MADT doesn't change on Careena
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If4ce71a47827e144c4d4991152101650904901f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Move the GNB IOAPIC resource from being reported in the GNB PCI device
to the domain and use IOMMU_IOAPIC_IDX as resource index, so that the
common AMD MADT code will be able to find the resource.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If6e9aaf4a3fa2c5b0266fd9fb8254285f8555317
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The IOAPIC structure that this function created is for the IOAPIC in the
GNB and not the one in the FCH which is called Kern in this SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6eec02578f2b2e8b8c10dad7eeecff961ef45e76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79883
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move the IOMMU_IOAPIC_IDX define from amdblocks/data_fabric.h to
amdblocks/ioapic.h which is both a more logical place for it to be and
this is also a preparation to use the common AMD MADT code for the
Stoneyridge SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaa20e802cf5ed93f0d05842abb1aea0d43b1cac4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The acpi_fill_madt implementation from the Genoa PoC also works for the
other AMD SoCs that select SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN, so
factor out this function to the common AMD ACPI code and change those
other SoCs to use the new common functionality instead of having their
own implementations.
The old code on the single-domain SoCs used the GNB_IO_APIC_ADDR base
address to create the MADT entry for the additional IOAPIC in the root
complex. The new code iterates over all domains and looks for a resource
with the IOMMU_IOAPIC_IDX index in each domain and if it finds it, it
creates an MADT entry for that IOAPIC. This resource is created earlier
in the boot process when the non-PCI resources are read from the IOHC
registers and reported to the allocator.
TEST=The resulting MADT doesn't change on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cc0d3f30b4e6ba29542dcfde84ccac90820d258
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79861
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of open-coding this functionality, call the apm_get_apmc()
helper function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iac6b614d900e51d91a0c155116a5edc29775ea99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
glinda SOC has 24 maximum CPU threads as per PPR documentation(#57254).
TEST=Boot logs print the CPU initialization happens for 24
threads.
Change-Id: Id48a5c62d6156c046daffd2648aeebeee380bd88
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Introduce the HAVE_CONFIGURABLE_APMC_SMI_PORT Kconfig option that when
not selected will result in a default implementation of
pm_acpi_smi_cmd_port to be included in the build that returns APM_CNT.
SoCs that provide their own pm_acpi_smi_cmd_port implementation, need to
select this Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaceb61b0f2a630d7afe2e0780b6a2a9806ea62f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
|
|
Commit 850b6c6254ab ("soc/amd/picasso: add eMMC MMIO device to
devicetree") broke both S3 resume on Morphius SKUs that use an NVMe SSD
instead of an eMMC and boot on the currently out-of-tree ASRock X370
Killer SLI board. In the latter case, commenting out the
power_off_aoac_device call inside the emmc_enable function fixed things.
TEST=This fixes S3 resume on Morphius with NVMe SSD and an equivalent
change discussed in the patch mentioned above that caused the regression
also fixed boot on the ASRock board.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Change-Id: Id976734c64efe7e0c3d8b073c8009849be291241
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add a Kconfig option to skip powering off the eMMC controller via the
AOAC block in the case where the eMMC controller is disabled in the
devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0dbe819222972d9bf0789671b031ad83648e8917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79825
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To avoid code duplication and to also bring the mainboards using the
Picasso SoC more in line with Cezanne and newer, factor out the SoC-
specific code from the mainboard's dsdt.asl files to the SoC's soc.asl.
TEST=Timeless builds result in identical images for Bilby, Mandolin, and
Zork/Morphius
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4ed3a3d3cb55c8b3b474c66a7c1700e24fe908e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Updating from commit id c0cb4bfa:
2023-12-08 signer: sign_android_image.sh should die when image repacking fails
to commit id 7c3b60bb:
2023-10-13 firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
This brings in 3 new commits:
7c3b60bb firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
8bb2f369 firmware: 2load_kernel: Set data_key allow_hwcrypto flag
2b183b58 vboot_reference: open drive rdonly when getting details
6ee22049 sign_official_build: switch from dgst to pkeyutl
da69cf46 Makefile: Add support for make 4.3
Also update the implementations of the vb2ex_hwcrypto_modexp() callback
to match the API changes made in vboot.
Change-Id: Ia6e535f4e49045e24ab005ccd7dcbbcf250f96ac
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
When an if block has curly braces, the corresponding else block should
also have curly braces.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie1979873142469b1482097f9b4db487541a1b7a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
Since we have chipset devicetrees for all SoCs that include this code in
the build, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5dcd92399e2d3f304352f2170dd3ef8761e86541
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79672
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since we have chipset devicetrees for both SoCs supported by the
Stoneyridge code, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifb787750ebc6aa2fef9d3be0e84e6afcffdc2ac1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79671
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5b692aaa2e3f768cc03bca71eff3ceb1a8733ad3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79670
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Allow SoC code to set LAPIC access mode to X2APIC
Change-Id: I208cca35c328e1566a57aaaa8ee7809e0760261c
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This updates all warnings currently being printed under the files_added
and build_complete targets to the show_notices target.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia14d790dd377f2892f047059b6d24e5b5c5ea823
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79423
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The openSIL code for the Genoa SoC is only a proof of concept, so change
the name of the Kconfig option to include this code in the build from
SOC_AMD_OPENSIL_GENOA to SOC_AMD_OPENSIL_GENOA_POC to clarify that this
is code that isn't intended or ready to be productized.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If91cdaa7c324426964bba2de2109b6c38482fab8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79574
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
