summaryrefslogtreecommitdiff
path: root/src/soc/amd/common
AgeCommit message (Collapse)Author
2024-07-10cbmem_top: Change the return value to uintptr_tElyes Haouas
Change-Id: Ib757c0548f6f643747ba8d70228b3d6dfa5182cd Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82752 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-04soc/amd/common/acpi/ivrs: use PCI_DEVFN macroFelix Held
Use the PCI_DEVFN macro to make the calculation of the ivhd->device_id value a bit clearer. TEST=Timeless build results in identical binary for Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b7949ad3524790e7d7d527c488a32e785f55bc0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83343 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-28tree: Remove unused <stdarg.h>Elyes Haouas
<stdarg.h> header is used to define macros for handling variable argument lists in functions like printf. It does not depend on the string or memory manipulation functions provided by <string.h>. So let follow conventions and include only the necessary headers in each header file. Change-Id: I07ffc65b7feefb8ec4ab8dd268113f9ed8d24685 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82664 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-13soc/amd/common/block/psp: Comment unused symbolElyes Haouas
This adds a comment for unused AMD_FWM_POSITION_20000_DEFAULT. Change-Id: Id8369f488893e7e5b2e7e7126d1b53199ed1aa77 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81973 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-04-24soc/amd/common/amd_pci_util.h: assign 0 to PIN_A in pcie_swizzle_pinFelix Held
Explicitly assign a value of 0 to the first value of the pcie_swizzle_pin enum. This won't change the behavior, but clarifies that the actual values of the enum elements matter. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I21850e21f859f2079f804d4344a1a11856b27d90 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-04-24soc/amd/common/amd_pci_util.h: rename bridge irq in pci_routing_infoFelix Held
Rename the 'irq' element of the pci_routing_info struct to 'bridge_irq' to better describe what it's doing. This struct element contains the number of the northbridge IOAPIC IRQ input the bridge IRQ is connected to signal power management or error reporting IRQs. Right now, coreboot doesn't put this information into the ACPI bytecode. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6410be673d15d6f9b5eb4c80b51fb705fec5b155 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-04-22vc/amd/opensil/stub/ramstage: add acpi_add_opensil_tables stubFelix Held
In the non-stub openSIL coreboot glue code, this can be used to add the ALIB SSDT. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3ccd2e81211417ad4ac94f208572e0fa4e1cf97c Reviewed-on: https://review.coreboot.org/c/coreboot/+/82012 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-22drivers/intel/fsp2_0: Introduce fsp print helper macrosAppukuttan V K
This patch introduces fsp print helper macros to print `efi_return_status_t' with the appropriate format. These macros are now used for fsp debug prints with return status efi_return_status_t is defined as UINT64 or UNIT32 based on the selected architecture BUG=b:329034258 TEST=Verified on Meteor Lake board (Rex) Change-Id: If6342c4d40c76b702351070e424797c21138a4a9 Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81630 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-12tree: Drop duplicated <device/{path,resource}.h>Elyes Haouas
<device/device.h> is supposed to provide <device/{path,resource}.h> Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-11tree: Drop unused <timestamp.h>Elyes Haouas
Change-Id: Ic690a7543f8a1e072650917d7a1e9e3b9dc371a3 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81823 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Jakub Czapiga <czapiga@google.com>
2024-04-11tree: Drop unused <string.h>Elyes Haouas
Change-Id: I0e216cbc4acf9571c65c345a1764e74485f89438 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81818 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-10tree: Drop unused <stdio.h>Elyes Haouas
Change-Id: I26c2abfce3417ed096d945745770fcae91a1e4ad Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81814 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Dinesh Gehlot <digehlot@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-09tree: Drop unused <post.h>Elyes Haouas
Change-Id: Ic7f6690786661e523292f7382df71ae4ad04d593 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81815 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-04-09tree: Drop unused <console/console.h>Elyes Haouas
Change-Id: Ib1a8fc50217c84e835080c70269ff50fc001392c Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81811 Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm> Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-30soc/amd: Remove blank lines before '}' and after '{'Elyes Haouas
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>
2024-03-28cpu/x86: Link page tables in stage if possibleArthur Heymans
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>
2024-03-28soc/amd/non_car/memlayout_x86.ld: Top align the codeArthur Heymans
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>
2024-03-28security/tpm: resolve conflicts in TSS implementationsSergii Dmytruk
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>
2024-03-23soc/amd/common/noncar/memmap: reduce visibility of memmap_early_dramFelix Held
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>
2024-03-23soc/amd/common/cpu/noncar/memmap: use VGA MMIO defines everywhereFelix Held
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>
2024-03-23soc/amd/common/cpu/noncar/memmap: make local variables constFelix Held
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>
2024-03-23soc/amd/*/memmap: factor out common read_lower_soc_memmap_resourcesFelix Held
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>
2024-02-29soc/amd: move common pci_domain_fill_ssdt implementation to acpi/Felix Held
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>
2024-02-26util/amdfwtool: build amdfwtool only for all tools or AMD CPUsMartin Roth
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>
2024-02-23soc/amd/common/acp: use clrsetbits32p to avoid need for castsFelix Held
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>
2024-02-23arch/x86/ioapic: use uintptr_t for IOAPIC base addressFelix Held
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>
2024-02-18soc: Add SPDX license headers to Kconfig filesMartin Roth
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>
2024-02-10soc/amd: Factor out gpp_clk_setup functionVarshit Pandya
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>
2024-02-08soc/amd/common/data_fabric/domain: drop unneeded parenthesisFelix Held
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>
2024-02-08soc/amd/common/data_fabric/domain: don't report DRAM as MMIO producerFelix Held
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>
2024-02-08cpu/x86/64bit: Turn jumping to long mode into a macroArthur Heymans
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>
2024-02-07soc/amd: drop unneeded data_fabric_set_mmio_npFelix Held
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>
2024-02-02soc/amd: commonize PCI root IOAPIC initializationFelix Held
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>
2024-02-02soc/amd/common/amdblocks/pci_clk_req: remove unneeded includeFelix Held
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>
2024-02-01soc/amd/common/data_fabric/domain: introduce add_pci_cfg_resourcesFelix Held
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>
2024-02-01soc/amd: rework DRAM and fixed resource reportingFelix Held
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>
2024-02-01soc/amd/*/root_complex: use unsigned long for resource indexFelix Held
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>
2024-02-01soc/amd/common/data_fabric/domain: use unsigned long for resource indexFelix Held
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>
2024-02-01soc/amd/common,genoa_poc/domain: rework check for 1st domainFelix Held
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>
2024-01-31soc/amd/noncar/memlayout.ld: Warn about incorrect reset vectorArthur Heymans
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>
2024-01-31device/device.h: Rename busses for clarityArthur Heymans
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>
2024-01-29device/device.h: Drop multiple linksArthur Heymans
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>
2024-01-27soc/amd: move acpi_add_fsp_tables implementation to common FSP codeFelix Held
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>
2024-01-27soc/amd: factor out acpi_add_fsp_tablesFelix Held
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>
2024-01-27soc/amd/picasso: factor out CRAT table generationFelix Held
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>
2024-01-27soc/amd: use common ACPI_SCI_IRQ definitionFelix Held
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>
2024-01-27soc/amd/*/acpi: use common soc_acpi_write_tables prototypeFelix Held
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>
2024-01-27soc/amd/common/include/acpi: add missing device/device.h includeFelix Held
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>
2024-01-27soc/amd/common/fsp: use expected types for add_agesa_fsp_acpi_tableFelix Held
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>
2024-01-26soc/amd: factor out common acpi_add_ivrs_table implementationFelix Held
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>
2024-01-25soc/amd/common: Fix typoVarshit Pandya
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>
2024-01-24soc/amd/*: Rename Makefiles from .inc to .mkMartin Roth
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>
2024-01-20soc/amd/*/chip: factor out FSP-S callFelix Held
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>
2024-01-20soc/amd: factor out non-CAR romstage to common codeFelix Held
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>
2024-01-20soc/amd/*/romstage: factor out FSP-M callFelix Held
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>
2024-01-17tree: More use accessor functions for struct region fieldsNico Huber
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>
2024-01-16device: Add support for multiple PCI segment groupsFelix Held
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>
2024-01-13soc/amd/common/data_fabric/domain: write _SEG method in SSDTFelix Held
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>
2024-01-11soc/amd: move IOMMU_IOAPIC_IDX define to amdblocks/ioapic.hFelix Held
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>
2024-01-11soc/amd/common/acpi: factor out common MADT codeFelix Held
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>
2024-01-10soc/amd: use apm_get_apmc() in APMC SMI handlerFelix Held
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>
2024-01-08arch/x86: introduce HAVE_CONFIGURABLE_APMC_SMI_PORTFelix Held
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>
2024-01-05soc/amd/common/emmc: add Kconfig option to skip powering off eMMCFelix Held
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>
2023-12-26Update vboot submodule to upstream mainJulius Werner
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>
2023-12-26soc/amd/common/pi/agesawrapper: use is_dev_enabled(DEV_PTR())Felix Held
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>
2023-12-15soc/amd: drop fill_fadt_extended_pm_regsFelix Held
Call fill_fadt_extended_pm_io directly from the SoC's acpi_fill_fadt functions instead of calling fill_fadt_extended_pm_regs that only calls fill_fadt_extended_pm_io. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I442bc2801cf74c1d836d3b0d88f281bceb5122b8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79529 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-12-11soc/amd/common/data_fabric: pass PCI segment group to domain codeFelix Held
Return the PCI segment group number from data_fabric_get_pci_bus_numbers via pointer argument so that amd_pci_domain_scan_bus can handle the PCI segment group numbers once coreboot supports more than one PCI segment group. For now, just print an error and return if the buses are on a PCI segment group other than 0. TEST=Mandolin still boots Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia53cda0ba656201c2197d05bc0d4a8fbbe8ad5d9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79412 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-12-06soc/amd/common: Move PCIe CLKREQ programming under fspMatt DeVillier
CLKREQ programming as currently implemented is completely dependent on FSP DXIO descriptors, so move under common/fsp/pci and rename the Kconfig to reflect the move. TEST=build google/{guybrush, skyrim, myst} Change-Id: I87b53d092ddc367b134c25949f9da7670a6a1d88 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79016 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-12-02soc/amd: Add DBG2 ACPI tableZheng Bao
Dump the DBG2 table on Linux console. $> acpidump -s ACPI: DBG2 0x0000000000000000 000054 (v00 COREv4 COREBOOT 00000000 **) $> acpidump > acpidump.bin $> acpixtract -a acpidump.bin $> iasl -d dbg2.dat $> cat dbg2.dsl /* * ACPI Data Table [DBG2] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "DBG2" [Debug Port table type 2] [004h 0004 4] Table Length : 00000054 [008h 0008 1] Revision : 00 [009h 0009 1] Checksum : FA [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 00000000 [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20220331 [024h 0036 4] Info Offset : 0000002C [028h 0040 4] Info Count : 00000001 [02Ch 0044 1] Revision : 00 [02Dh 0045 2] Length : 0028 [02Fh 0047 1] Register Count : 01 [030h 0048 2] Namepath Length : 0002 [032h 0050 2] Namepath Offset : 0026 [034h 0052 2] OEM Data Length : 0000 [Optional field not present] [036h 0054 2] OEM Data Offset : 0000 [Optional field not present] [038h 0056 2] Port Type : 8000 [03Ah 0058 2] Port Subtype : 0012 [03Ch 0060 2] Reserved : 0000 [03Eh 0062 2] Base Address Offset : 0016 [040h 0064 2] Address Size Offset : 0022 [042h 006612] Base Address Register : [Generic Address Structure] [042h 0066 1] Space ID : 00 [SystemMemory] [043h 0067 1] Bit Width : 00 [044h 0068 1] Bit Offset : 00 [045h 0069 1] Encoded Access Width : 03 [DWord Access:32] [046h 0070 8] Address : 00000000FEDC9000 [04Eh 0078 4] Address Size : 00000100 [052h 0082 2] Namepath : "." Raw Table Data: Length 84 (0x54) 00: 44 42 47 32 54 00 00 00 00 FA 43 4F 52 45 76 34 // DBG2T.....COREv4 10: 43 4F 52 45 42 4F 4F 54 00 00 00 00 43 4F 52 45 // COREBOOT....CORE 20: 31 03 22 20 2C 00 00 00 01 00 00 00 00 28 00 01 // 1." ,........(.. 30: 02 00 26 00 00 00 00 00 00 80 12 00 00 00 16 00 // ..&............. 40: 22 00 00 00 00 03 00 90 DC FE 00 00 00 00 00 01 // "............... 50: 00 00 2E 00 // .... BUG=b:303689867 Change-Id: I3c97a78d1889549421baf0bc1a2e8f959a0f47e2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79174 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-28soc/amd/cezanne: Move PSP_VERSTAGE_MAP_ENTIRE_SPIROM configKarthikeyan Ramasubramanian
Select PSP_VERSTAGE_MAP_ENTIRE_SPIROM in Cezanne Kconfig instead of common Kconfig. BUG=None TEST=Build BIOS image and boot to OS in dewatt. Change-Id: I476971700824fed06d17000001afc075105fa1ee Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79306 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-28soc/amd/common/psp_verstage: Make SPI ROM mapping configurableKarthikeyan Ramasubramanian
Earlier entire SPI ROM was mapped to memory. With limited TLB resources in PSP, this approach hit the limit on systems using 32 MiB SPI ROM. Therefore regions in SPI ROM were mapped on need basis. This works well on Picasso, Mendocino and Phoenix SoCs. But unfortunately this causes boot hangs in Cezanne SoC. Add a configuration to map the entire SPI ROM and enable it in Cezanne SoC. For other SoCs, keep the configuration disabled so that only the required SPI ROM region is mapped. BUG=b:309690716 TEST=Build and boot to OS in both Dewatt and Skyrim. Change-Id: I166ac7b50b367c067e1a743fc94686e69dd07844 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79155 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-11-24soc/amd/genoa: Hook up microcode updatingArthur Heymans
Also update the regular expression to find the genoa blobs. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iba0109c049019a22cba1e0358cedbd9c198c6569 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76525 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-11-10device/Kconfig: rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORTFelix Held
Rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORT and add a help text to this Kconfig option to clarify what this option is about. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71e36869c6ebf77f43ca78f5e451aebfb59f1c74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-11-09soc/amd: Remove unnecessary choice symbol name from PSP KconfigMartin Roth
There's no reason to name this choice block. Remove the name. Change-Id: Iebf8b1e7af928b988ab514d9dd85d2e70bf00c09 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78917 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-07soc/amd/common,stoneyridge: drop invalid hda_soc_ssdt_quirksFelix Held
Drop the hda_soc_ssdt_quirks function since it doesn't apply for any of the SoCs supported by the Stoneyridge code which was the only SoC implementing it. This code was added when commit 91a7abf25c72 ("soc/amd/hda: Move HDA PCI device from DSDT to SSDT") rewrote the code originally added in commit 1587dc8a2b4d ("soc/amd/stoneyridge: Add northbridge support") as a copy from northbridge/amd/pi/00670F00. This code was moved around in commit 6580408a7e0a ("amd/pi/hudson: Move audio to northbridge"), since the HDA controller was moved from the FCH to the northbridge complex. When the controller was moved, the PCI config space interface also changed, so those bits are no longer the DisableNoSnoop, DisableNoSnoopOverride, and EnableNoSnoopRequest bits of the Misc Control register of the HDA controller, but some bits within the ClassCodeW field of the ACGAZ Mirrot Reg Ctrl 0 register. BKDG #55072 Rev 3.04 (Stoneyridge), BKDG #50742 Rev 3.08 (family 15h model 60h-6fh / 00670F00), and BKDG #52740 Rev 3.05 (family 16h model 30h-3fh) were used as a reference. Only the SoC with BKDG #52740 still has the HDA controller in the FCH; the other two have it in the northbridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77fc76752b1c7de62ba8a196f15c198f55be3074 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78940 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-06soc/amd/common/block/i2c: add pre-processor guards for ACPIFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8dc93b12b81abee41f6f225f41d1f9953d1d93e1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78898 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2023-11-02soc/amd/common/psp: Remove unnecessary prompts from KconfigMartin Roth
I think this was probably a cut & paste error. We don't want prompts for the "default" Kconfig options. Those should be set by the platform, not the end user. These prompts didn't make sense where they were in the Kconfig menus either. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Idcd2ba84591d31a9a25bcc6cae3ec163939d7836 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78818 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <ericllai@google.com>
2023-10-25soc/amd/common/smm: Add option for late SMM lockingMatt DeVillier
Pre-Zen SoCs like Stoneyridge call into an AGESA binary as part of S3 resume, which will fail if SMM is locked, causing the device to (eventually) cold boot. To mitigate this, add a new Kconfig to enable "late" SMM locking, which restores the previous behavior prior to commit 43ed5d253422 ("cpu/amd: Move locking SMM as part of SMM init"). TEST=tested with rest of patch train Change-Id: I9971814415271a6a107c327523a0a7c188a91df6 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78352 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-25soc/amd/*/Kconfig: rework SPL optionsFelix Held
Move all security patch level (SPL) related Kconfig options to the common AMD PSP Kconfig file. Commit 4ab1db82bb30 ("soc/amd: rework SPL file override and SPL fusing handling") already reworked the SPL handling, but missed that another Kconfig option SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL controlled if the PSP mailbox command to update the SPL fuses was sent by the code that got added to the build when PERFORM_SPL_FUSING was selected. To make things less unexpected, rename PERFORM_SPL_FUSING to SOC_AMD_COMMON_BLOCK_PSP_SPL since it actually controls if the SPL support code is added to the build and also rename SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL to PERFORM_SPL_FUSING. This changes what PERFORM_SPL_FUSING will do from including the code that could do the fusing if another option is set to being the option that controls if the fusing mailbox command will be set. All SoCs that support SPL now select SOC_AMD_COMMON_BLOCK_PSP_SPL in their Kconfig, which won't burn any SPL fuses. The logic in the Skyrim mainboard Kconfig file is reworked to select PERFORM_SPL_FUSING for all boards on which the SPL fuses should be updated; on Guybrush PERFORM_SPL_FUSING default is changed to y for all variants. The option to include the code that checks the SPL fusing conditions and allows sending the command to update the SPL fuses if the corresponding Kconfig is set doesn't need to be added on the mainboard level, since it's already selected at the SoC level. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I12fd8775db66f16fe632674cd67c6af483e8d4e2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78309 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-10-25soc/amd/common: Add ACP device to common block graphics driverCoolStar
Supports a brand new ACP driver for STONEY / Grunt chromebooks. AMD's Audio CoProcessor handles i2s/tdm audio, and is located on the GPU. On Windows the PCIe device for the GPU is owned by the AMD proprietary driver, hence a separate device has to be added for the ACP driver. Fortunately since IOMMU is disabled on STONEY, the driver itself can pull BAR5 from the GPU and use that to initialize, so no special configuration is required in ACPI other than the ID. Change-Id: I0e31c3b31fa9fb99578c04b79fce2d8c1d695561 Signed-off-by: CoolStar <coolstarorganization@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-24soc/amd/common/graphics: Factor out FSP graphics initMatt DeVillier
Factor out the FSP-dependent graphics init call and header into a separate file, so that the common graphics init can be used by non-FSP platforms (eg Stoneyridge) without any preprocessor guards. TEST=build google/skyrim Change-Id: Ib025ad3adec0945b4454892d78c30b4cc79e57a0 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78599 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-20soc/amd/common/psp_verstage: Add PSP_VERSTACK_STACK_IS_MAPPED configKarthikeyan Ramasubramanian
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if a buffer comes from within SRAM address range, then it is passed directly to Crypto Engine. Otherwise a bounce bufer from the stack is used. But on SoCs like Picasso where PSP Verstage stack is mapped to a virtual address space this check fails causing a bounce buffer to be used and hence a stack overflow. Fix this issue by assuming that the buffer comes from the SRAM always in such SoCs and pass the buffer directly to crypto engine. BUG=b:259649666 TEST=Build and boot to OS in Dalboz with unsigned PSP verstage. Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-10-20device/device.h: Rename pci_domain_scan_busArthur Heymans
On all targets the domain works as a host bridge. Xeon-sp code intends to feature multiple host bridges below a domain, hence rename the function to pci_host_bridge_scan_bus. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326 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> Reviewed-by: Yidi Lin <yidilin@google.com>
2023-10-16soc/amd/common/data_fabric_helper: add pre-processor guards for ACPIFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iec6e05bbe9fad7d78002560b78169dc293294af6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78341 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-10-16soc/amd/common/data_fabric/extended_mmio: fix compile errorsFelix Held
This code only gets built when the SOC selects SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO which no SoC before Genoa does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia5495ebf0f157fd0c456ce44acaf1ab222a188dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/78340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-10-09soc/amd/common/vboot: Fix PSP verstage timestamps after TSC adoptionKarthikeyan Ramasubramanian
Commit 26d54b70e282 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP Verstage timestamps (in microseconds) to the x86 TSC rate. But it included only the base_time during the adjustment leaving the individual entry timestamp. This leads to incorrectly adjusted PSP Verstage timestamps. Fix the adjustment logic. BUG=None TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage timestamps in cbmem -t output are adjusted correctly. Before this change: 5:start of verified boot 67,890 (69,936) 503:starting to initialize TPM 67,890 (0) 504:finished TPM initialization 67,902 (12) 505:starting to verify keyblock/preamble (RSA) 67,906 (3) 506:finished verifying keyblock/preamble (RSA) 67,984 (77) 511:starting TPM PCR extend 67,984 (0) 512:finished TPM PCR extend 67,992 (7) 513:starting locking TPM 67,992 (0) 514:finished locking TPM 67,995 (3) 6:end of verified boot 67,995 (0) 11:start of bootblock 572,152 (504,156) After this change: 5:start of verified boot 71,000 (73,040) 503:starting to initialize TPM 71,065 (65) 504:finished TPM initialization 101,506 (30,441) 505:starting to verify keyblock/preamble (RSA) 110,624 (9,118) 506:finished verifying keyblock/preamble (RSA) 297,101 (186,477) 511:starting TPM PCR extend 297,297 (196) 512:finished TPM PCR extend 315,338 (18,041) 513:starting locking TPM 315,341 (3) 514:finished locking TPM 322,922 (7,581) 6:end of verified boot 322,943 (21) 11:start of bootblock 570,296 (247,353) Change-Id: I3e52bef22f65596152f29c511bed680427660ff5 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231 Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-10-04soc/amd: rework SPL file override and SPL fusing handlingFelix Held
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a way to override the default SPL file configured in the SoC's fw.cfg file by passing the '--spl-table' parameter to amdfwtool which will then use the override instead of the SPL file from the fw.cfg file. When SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix call in the makefile will result in no '--spl-table' parameter being passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In order to not pass an SPL override by default, remove the default from the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the same SPL file as in fw.cfg file anyway. Now only when a mainboard sets this option to point to a file, that file will be used as an override. This override is used to include a special SPL file needed for the verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an empty string by default, neither the SPL_TABLE_FILE Kconfig option nor it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE, so remove the dependency in the Kconfig and the ifeq in the Makefile. Before this patch, the HAVE_SPL_FILE option controlled two things that shouldn't be controlled by the same Kconfig option: Only when HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into account, and it also controls if spl_fuse.c got added to the build which when added will send the SPL fusing command to the PSP. So the case of needing an SPL file override, but not updating the SPL fuses wasn't supported before. The SPL file in the amdfw part will be used by the PSP bootloader for the anti-rollback feature which makes sure that the SPL file version isn't lower than what is in the SPL fuses. For this the SPL file needs to be present in the PSP directory table. The SPL version check happens way before we're running code on the x86 cores. The SPL fusing PSP command that can be sent by coreboot will tell the PSP to update the SPL fuses so that the fused minimal SPL version will be updated to the current SPL version. Since the former HAVE_SPL_FILE option now only controls if the SPL fusing command will be sent to the PSP mailbox, rename it to PERFORM_SPL_FUSING to clarify what this will do and update the help text correctly describe what this does. TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman with Phoenix APU and Skyrim result in identical binaries. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-02soc/amd/common/noncar/cpu: simplify get_reserved_phys_addr_bitsFelix Held
Simplify the code a bit by returning 0 early in the function when the SYSCFG_MSR_SMEE bit isn't set. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Jeremy Compostella <jeremy.compostella@intel.com> Change-Id: I7536b82d98e55c51105448090d1206e1ed7f62d8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78176 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-02soc/amd/common: use common physical address bit reservation codeFelix Held
Instead of having the get_usable_physical_address_bits function that only got used in the data fabric domain resource reporting code, drop this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the common AMD non-CAR CPU and rename get_sme_reserved_address_bits to get_reserved_phys_addr_bits so that the common cpu_phys_address_size function will return the correct number of usable physical address bits which now can be used everywhere. The common AMD CAR CPU support is only selected by Stoneyridge which doesn't support secure memory encryption, so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the SOC_AMD_COMMON_BLOCK_CAR Kconfig option. Before only the MMIO region reporting took the reserved physical address bits into account, but now also the MTRR calculation will take those reserved bits into account. See the AMD64 Programmers Manual volume 2 (document number 24593) for details. Chapter 7.10.5 from revision 3.41 of this document was used as a reference. The MTRR handling code in older Linux kernels complains when the upper reserved bits in the MTRR mask weren't set, but sets them after complaining and then continues to boot. This issue is no longer present in version 6.5 of the Linux kernel. The calculation of the TSEG mask however still needs to take all physical bits into account, including the ones reserved for the memory encryption. When not setting the reserved bits in the TSEG mask, the Mandolin board with a Picasso APU won't boot to the OS any more due to not returning from SeaBIOS calling into the VBIOS. Haven't root-caused what exactly causes this breakage, but I think previously when something else was wrong with the SMM initialization, also something went wrong when calling into the VBIOS. TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2 and Windows 10 boots on it via EDK2. TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following warning, but it still continues the boot process as described above: mtrr: your BIOS has configured an incorrect mask, fixing it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-28treewide: convert to tpm_result_tJon Murphy
Convert TPM functions to return TPM error codes(referred to as tpm_result_t) values to match the TCG standard. BUG=b:296439237 TEST=build and boot to Skyrim BRANCH=None Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1 Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-25soc/amd/common/graphics: Update VBIOS cache data before hashingMatt DeVillier
On the first boot after flashing, the data read from the FMAP and stored in vbios_data is not valid, so hashing it produces a value which will not match on the subsequent boot, requiring an additional boot before the vbios_data and hash match / before the GOP driver can be skipped. To fix this, update vbios_data before hashing. BUG=b:271850970 BRANCH=skyrim TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected, verify that GOP driver execution is skipping on 2nd boot after flashing when booting in normal / verified boot mode. Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-09-21soc/amd/*/cpu: factor out common noncar mp_init_cpusFelix Held
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation, factor it out and move it to a common location. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013 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>
2023-09-19soc/amd/cezanne,common: expose eMMC device in ACPI when enabledFelix Held
When the eMMC MMIO device is enabled in the devicetree, it needs to be exposed in ACPI in order for the OS driver to be able to attach to it. The Cezanne eMMC controller isn't used in google/guybrush, so this the code path where the eMMC MMIO device is enabled in the devicetree can't be easily tested. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-18soc/amd: introduce SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGIONFelix Held
Add a separate Kconfig option for adding np_region.c to the build. Only the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call data_fabric_set_mmio_np which is implemented in that file, so only select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option for those. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-18drivers/tpm: Make temp test value naming consistentJon Murphy
Make naming convention consistent across all functions return values. BUG=b:296439237 TEST=Boot to OS on Skyrim BRANCH=None Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-09-18soc/amd/common/data_fabric_helper: factor out data_fabric_set_mmio_npFelix Held
Factor out data_fabric_set_mmio_np and the helper functions it uses into a separate compilation unit. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I58625c5a038f668f8e30ae29f03402e1e2c4bee3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-09-18soc/amd/common/data_fabric_helper: use data_fabric_get_mmio_base_sizeFelix Held
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf instead of open coding the functionality. This will fix the printing of the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO case which wasn't handled properly before. TEST=Console output from this function doesn't change on Mandolin: === 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 0 ffff 90 9 4 fed00000 fed0ffff 93 x x 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 === 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 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If602922648deca0caef23a9999c82acdd128b182 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-18soc/amd/common/data_fabric_helper: make some helper functions staticFelix Held
data_fabric_disable_mmio_reg and data_fabric_find_unused_mmio_reg are only used by data_fabric_set_mmio_np in the same file, so make them static and drop the prototype from the header file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6bf7a868aae2fd01b8adecd3e4cba6ff6d5119af Reviewed-on: https://review.coreboot.org/c/coreboot/+/77985 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-09-14x86: Add .data section support for pre-memory stagesJeremy Compostella
x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-09-09soc/amd/common: Remove __attribute__(())Elyes Haouas
Change-Id: I2866dcdd6900c98310b4b3736b40ebe4eaa77ea2 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77719 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 11:01:02 +0000