Since FSP doesn't support disabling bridges and has no UPDs for that,
they must be enabled in DT to make sure they are properly initialized
during PCI enumeration as expected by the payload (EDK2 for example).
It might be OK to have them set to off when all devices behind the
bridge are also off and FSP disables those secondary devices.
In general something that cannot be hidden/shut off shouldn't be marked
as such, as later stages (payload/OS) might find it active, but
unconfigured.
Change-Id: Ie34bb2abc0211963b2613d1b50b1767df31c1062
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
AMD SoC from family 17h share common cpu init code.
Move those to common/block/cpu/noncar/cpu.c
TEST=Build for glinda SoC & check for boot.
Change-Id: If53455f359302f368f7c979defa2c1088c5c2f16
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
FMAP should not contain information about the memory map.
Done with the following command:
"find -name \*.fmd -exec sed -i 's/\(FLASH\).* \(.*\) /\1 \2 /' {} \;"
for AMD:
All addresses that amdfwtool expects as command line parameter have the
ADDR_REL_BIOS (flash address) address_mode setting. One exception is
the *_FW_A_POSITION and *_FW_B_POSITION addresses. But amdfwtool checks
if memory or flash addresses are passed and converts accordingly. So
changing the address from memory -> flash doesn't matter for the
resulting binary.
Since commit 41a162b7a8 ("soc/amd/phoenix/Makefile.inc: Pass APOB_NV
address as offset") and therefore since phoenix SOC, APOB_NV is passed
as flash offset. But before that the memory ABL always assumed a MMIO
address (no matter the address_mode) so we need to add a little quirk
for that.
tested: boot glinda based mainboard and also check that memory training
is still cached successfully in APOB_NV.
Change-Id: Iac86ef9be6b14817a65bf3a7ccb624d205ca3f99
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Must have been accidentally happened when copying phoenix to glinda.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I78996cd35085c7649c4952d9b121957c8cedd84b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86865
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
MSR definition in soc/amd/*/include/soc/msr.h are the same & hence move
them to common header src/include/cpu/amd/msr.h
Change-Id: Ic0cb54b13320f8a38e70c0a76d9b9a51ba0ea01d
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87124
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Also remove include folders that don't even exist.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ic64f5187e50b903af5461bfa4d57bb4951d3b501
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86864
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The arch include files are overshadowed by PSP verstage include files.
The reason is that psp_verstage implements its own set of inb() and
outb() functions, which use a runtime configurable IO base address
instead of a built time constant.
But this works at the moment only because of the order in which the
include files are added. Since that is very error prone, this patch
introduces another solution to the problem.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I16fa4a4cb5168024aaef30119e9aa8a34dbaacbe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
A glinda based platform reports:
[WARN] RAM APOB data is too large (3b3b0 + 8) > 1e000
APOB NV size is not enough on recent platforms to cache memory training,
which causes the same amount of boot time on subsequent boots as on the
first boot.
This time increase the size properly by adjusting the base address of
the components that come after the APOB region.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I070cf766b98825cd5ff37674e1f9651fa71159c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This reverts commit 362232d236.
Reason for revert:
This introduced an overlap between APOB DRAM region and SHAREDMEM
region used for PSP verstage. Our linker scripts would have caught that,
but we don't have any glinda based mainboards using VBOOT in the tree
at the moment so there is no actual overlap on any upstream mainboards
at the moment. Still if VBOOT based mainboards are added in the future
it would cause a build error for them.
The next patch in the train will increase the APOB NV size properly by
increasing all the other addresses in the chain too.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I4b4cb4104a59f72491a941dc1d13018f2389bb03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86861
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Determine CPU frequency & voltage for use in smbios type 4 table.
Reference:
AMD PPR 57254 v1.59 Section 2.1.15 CPUID Instruction
TEST=Build for glinda SoC & verify output to reflect CPU frequency
& voltage.
Sample Output:
dmidecode -t
...
Voltage: 1.2 V
...
Current Speed: 2600 MHz
...
Change-Id: Ibd7c7f1e299a0a8d294e7e30ae3130faae16ae22
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86757
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the generic x86 SPI flash mmap driver is being used when not
using DMA and when not on GENOA. It only works for ROM_SIZE of 16 MiB
or less and prevents boot when the ROM is bigger than that.
Use the genoa_poc SPI MMAP driver on all platforms by default as it
allows to use a ROM_SIZE greater than 16MiB. The newly introduced
Kconfig SOC_AMD_COMMON_BLOCK_SPI_MMAP is used for all platforms when
the SPI DMA driver is not in use.
This doesn't allow to access the whole SPI flash using the ROM2 MMIO
window, but it no longer prevents boot when the mainboard specifies
the correct SPI flash size in Kconfig.
TEST: Booted an AMD/birman+ with 64MiB ROM specified in Kconfig.
TEST: Booted on AMD/onyx with 32MiB ROM specified in Kconfig.
Change-Id: I39e33c71d27179212ddb1f5bcca4c5d4a39d47e4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86618
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add functions to return the position and size of the ROM2 and ROM3
MMIO windows that mmap the SPI flash. Starting from AMD Family 17h
Model 30h (Zen 2) the ROM3 BAR is available.
ROM3 is not supported on picasso or stoneyridge.
Document ID: 56780
TEST: Verified that both functions return sane values.
Change-Id: I10d4f0fe8a38e0ba2784a9839270d5dd3398d47a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add the LPC PCI device to make sure common code builds.
Document ID: 55898
Change-Id: I52b129b47f98d88cad1d656dab4d4562c7ce3394
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86706
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PSP_SOFTFUSE_BITs were probably copy&pasted during initial
SoC bringup and need to be adjusted:
* Drop PSP_SOFTFUSE_BIT BIT28 as it causes PSP to hang.
* Drop PSP_SOFTFUSE_BIT BIT34 as it's not required.
This also moves coreboot closer to the UEFI reference firmware.
Document #55758 Rev. 2.04
TEST: Booted on amd/birman_plus with default PSP_SOFTFUSE_BITS.
Change-Id: Ic7b2b0ac01fe0ac0ed2535254f242a8068f9b02a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86840
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Don't map more than 16MiB in ROM2 decode window when the SPI ROM
size is bigger than 16MiB.
TEST: amd/birman+ still boots with bigger SPI flash sizes.
Change-Id: Ie811f6a38363f2e900611b3f3f407a94d8137c89
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86582
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change eliminates the HAVE_FSP_LOGO_SUPPORT Kconfig option.
It was initially used to control BMP_LOGO selection within the FSP2.0
driver. However, upcoming refactoring will move BMP_LOGO and its
implementation to the `lib` directory therefore, BMP_LOGO can be
used by both FSP and non-FSP SoC platforms.
BUG=b:400738815
TEST=Able to build and boot google/brox.
Change-Id: I899bbfcf7e747abe69ff0866c4594a42278891b9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86719
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Add the MSG0 method to the ACP's SSDT entry, so that the ACP driver can
talk to a two different mailbox interfaces via this ACPI MSG0 method
interface. This is used by some drivers to configure the ACP's clock
source and to notify the PSP that the audio DSP firmware has been loaded
so that the PSP can validate the firmware and set the qualifier bit to
enable running it.
TEST=The AML code sequence written by this decompiles to the expected
ASL code and the driver is able to initialize the ACP correctly by
calling the MSG0 method twice with different parameters.
Change-Id: I34f641fbfe40b5df7f0ff2fc173510c5cf2a7f61
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add two ACPI methods to access a PSP mailbox interface via an SMN
register pair in the host bridge.
TEST=The AML code sequence written by this decompiles to the expected
ASL code.
Change-Id: I282f1fa2898f76659700450ee1f4b11f79d2d030
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some SoCs require adding SoC-specific methods to the ACP's SSDT entry.
In order to not add SoC-specific code to the common ACP code, add the
'acp_soc_write_ssdt_entry' callback into the SoC-specific code and guard
it via the 'SOC_AMD_COMMON_BLOCK_ACP_SOC_SPECIFIC_SSDT_ENTRY' Kconfig
symbol to neither need weak functions or stubs in every SoC code.
Change-Id: I0ca5272d28938c8b90b645884a0d8b306a77d473
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add an ACPI OperationRegion to access an SMN access index/data register
pair in the root complex. To access the PCI config space registers, the
ECAM MMCONF MMIO region is used which matches the UEFI reference
implementation.
TEST=The AML code sequence written by this decompiles to the expected
ASL code.
Change-Id: I4d00c86647e51e5cae621fe788f0a1b06471a443
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All AMD SoCs from family 17h on, so all using a non-CAR configuration
to boot, have a reference clock of 100 MHz, so report this for all of
them in the SMBIOS tables.
Change-Id: I9573cbb8ec816c797314415d0c60c72abf23a094
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86690
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit fe107c1ad2.
I have strong doubts that this is Glinda-specific, so this likely should
have been made common after verifying.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib7282e2bec4d6aa5b74efa5621c825bc234cca82
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86689
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 00b4a61dc5.
I have strong doubts that this is Glinda-specific, so this probably
should have been made common after verifying.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie7fa0dca4c92f7bb0d49956aa9f1588b5fcba585
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86688
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
A glinda based platform reports:
[WARN] RAM APOB data is too large (3b3b0 + 8) > 1e000
APOB NV size is not enough on recent platforms to cache memory training,
which causes the same amount of boot time on subsequent boots as on the
first boot.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I8cc1f1e4f8d6f99c8e2b717926b66a5a683bffdc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Recent PI releases have been distributing the ucode patch files as sbin
files instead of bin files. The sbin uses a 256 byte amd_fw_header to
wrap the bin file.
Offset 0x14 of the header is the size field. The can be extracted with
od to get the size of the ucode bin file. The bin file can then be
extracted with dd and placed in the build directory for inclusion as a
cbfs file.
In the case where both an sbin and bin ucode file are present, the bin
file will be added and a note will print at the start of the build about
the sbin file being skipped.
TEST=builds with only bin, only sbin, non-matching bin and sbin,
matching bin and sbin files
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I29768ea19543bdc76662e687f59bf31b76f555ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68122
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code compiles and works fine in x86_64. Thus allow the user
to use x86_64.
TEST: Booted on amd/birman+ to OS using EDK2 as payload.
Change-Id: If1b5d91a376770c0f0e1a4ee46dd625b401fbfa6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The x86 (AMD and Intel) spec defines it as Page-Map Level-4 Entry.
It is annoying when searching for the wrong abbreviation in the spec so
fix it everywhere it occurs.
source: Intel 64 spec April 2022 and AMD64 spec April 2024.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I730235beea69b3720f080bbade083c2eeed26587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86587
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Refactor the vendorcode openSIL memory map code and move all common
calls that do not require any openSIL headers to the driver. Improve
the legibility of the logic to return memory hole type string.
Change-Id: I80b9bdd7fd633c7b12d695ced5d4b9b518570d80
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since FSP doesn't support disabling bridges and has no UPDs for that,
they must be enabled in DT to make sure they are properly initialized
during PCI enumeration as expected by the payload (EDK2 for example).
It might be OK to have them set to off when all devices behind the
bridge are also off and FSP disables those secondary devices.
In general something that cannot be hidden/shut off shouldn't be marked
as such, as later stages (payload/OS) might find it active, but
unconfigured.
Change-Id: Ife30f73495d44c98717e147602de10f5a6a89358
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since FSP doesn't support disabling bridges and has no UPDs for that,
they must be enabled in DT to make sure they are properly initialized
during PCI enumeration as expected by the payload (EDK2 for example).
It might be OK to have them set to off when all devices behind the
bridge are also off and FSP disables those secondary devices.
In general something that cannot be hidden/shut off shouldn't be marked
as such, as later stages (payload/OS) might find it active, but
unconfigured.
Change-Id: Ic226fd93b431467c7fa3a53140102ff4fd327f40
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86271
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since FSP doesn't support disabling bridges and has no UPDs for that,
they must be enabled in DT to make sure they are properly initialized
during PCI enumeration as expected by the payload (EDK2 for example).
It might be OK to have them set to off when all devices behind the
bridge are also off and FSP disables those secondary devices.
In general something that cannot be hidden/shut off shouldn't be marked
as such, as later stages (payload/OS) might find it active, but
unconfigured.
Change-Id: Id28a29481f9a1bc570e47a9cb75613d3621b0d44
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86270
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the VBIOS checksum code into the soc/amd folder, as it's
specific to AMD's FSP. The code now fixes the VBIOS in place
instead only fixing it for the VFCT table.
TEST: VBIOS has correct checksum after loading in BS_DEV_RESOURCES.
VBIOS checksum is invalid entering graphics_dev_init().
VBIOS checksum is correct leaving graphics_dev_init().
Change-Id: I63aaaefaf01ea456e2ed39cd0891e552a7fb5135
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86384
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
On glinda the IGD is no longer VGA compatible. It doesn't
advertise itself as a VGA compatible devices and doesn't decode
the legacy VGA ranges 0x3C0-0x3CF, 0x3D4.
Introduce a new Kconfig and select it where necessary to keep
existing behaviour on older SoC while fixing FSP GOP init on
glinda. The VBIOS will get loaded into the D-segment instead
the C-segment, which is typically used by VGA.
TEST: FSP GOP on amd/birman+ is able to find the VBIOS.
amdgpu driver still doesn't work as the VFCT table isn't
generated on amd/glinda.
Change-Id: I6ab28aab74f3169d45d7d852a37ddfcfc75b7c88
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86300
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement vbt_get() on AMD and return the VBIOS location. This allows
to drop the hardcoded addresses used in various places and return an
address in DRAM that is reserved for FSP use.
TEST: amd/birman+ still gets passed the correct VBIOS address.
Change-Id: I92d76fc4df88fbce792b9d7c912c6799617704a0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86299
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
The code flow isn't that obvious in the beginning. You pass an address
of the VBIOS to FSP, but don't load any VBIOS until BS_DEV_RESOURCES
phase.
Add comments to document what is done and when. This will help to
improve the code in the next step.
Change-Id: I643bc9088306d99cc0fbb79648809e16b068fb33
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Refactor to factor out and route ACPI calls through the openSIL driver
interface to separate main SoC code from vendorcode.
Change-Id: I9fa4f60164333ec7a268702fa3e94979a1b83594
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since commit 64d9e85681
("cpu/x86/smm_module_hander: Set up a save state map"), the
smm_get_save_state() function can return a NULL pointer. Therefore, it
is crucial to ensure that code properly handles the potential for a
NULL pointer return value from smm_get_save_state().
Change-Id: Ie263393ca7d9d6b5e9868c5f73240fc788116cd0
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86040
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Glinda SoC PSP MBOX offset is 0x10970 & hence update the same in Kconfig
TEST=Tested with Birman Plus and it solved the issue for psp timeout
Before:
[DEBUG] PSP: Notify SMM info... error: PSP command timeout
After:
[DEBUG] PSP: Notify SMM info... OK
Change-Id: I328959513228fe0f9e78070eb6b302ef89857b42
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85627
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor vendorcode MPIO configuration functions to be invoked from
the openSIL driver.
Change-Id: I8b1f92f08565216dd93203a06015e3eec1e7bb69
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some SoC like Glinda use different PSP MBOX offset.
Add config to allow SoC Kconfig to override PSP MBOX offset.
Change-Id: Iefcc7d3b75689b43399a7a7b612417c155619211
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85626
Reviewed-by: Ana Carolina Cabral
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add a devicetree option to disable the 48MHz clock output of the FCH
when an I2S audio codec uses a separate oscillator for its 48 MHz
master clock instead of the FCH clock output. This code was ported
from the Picasso code base.
Change-Id: I0c1bee121f528d28d591dace260507b345dfec26
Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Place openSIL timepoints 1, 2 and 3 calls in the driver, which will
serve as the central point for invoking SoC-specific vendorcode
implementations. TP1 and TP2 will initialize silicon pre- and post-PCIe
enumeration, respectively. TP3 then performs late SoC IPs programming
and register locking closer to payload load prior to OS handoff. Add a
Kconfig option for selecting and including the openSIL driver source
code in the build.
Change-Id: If0559fc0ff0ec55e9ef131e5ed20dfb5baa651da
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85631
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This matches the size used in the reference code and required by the
corresponding document #55758 Rev. 2.04. This doesn't seem to make any
difference in runtime behavior, but I'd rather waste a kilobyte of SMM
RAM, than debugging possible problems caused from not following the
corresponding specification.
Change-Id: I2ee30d6d1255317efcd3960016069dfe50885aa7
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
