summaryrefslogtreecommitdiff
path: root/src/soc/amd/stoneyridge
AgeCommit message (Collapse)Author
2022-09-14cpu/amd/smm: Move MP & SMM init in a common placeArthur Heymans
Change-Id: I7c457ab69581f8c29f2d79c054ca3bc7e58a896e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64870 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-09-14soc/amd/common: Add common function to get cpu countArthur Heymans
This is the same for all supported AMD hardware. Change-Id: Ic6b954308dbb4c5a2050f1eb8f15acb41d0b81bd Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67617 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-09-01amd/*/Makefile.inc: Put common words into common Makefile.incZheng Bao
Definition of FIRMWARE_LOCATION, POUND_SIGN, DEP_FILES, amd_microcode_bins are moved to common Makefile.inc. Change-Id: I5a0ea27002e09d0b879bafad37a5d418ddb4e644 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62658 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com>
2022-08-25soc/amd: rework SPI flash MMIO region handlingFelix Held
Only 16 MByte of the SPI flash can be mapped right below the 4 GB boundary. In case of a larger SPI flash size, still only the 16 MByte region starting at 0xff000000 can be configured as WRPROT and be reserved for the MMIO mapped SPI flash region. The next 16 MByte MMIO region starting at address 0xfe000000 contain for example the LAPIC MMIO region, the ACPIMMIO region and the UART/I2C controller MMIO regions which shouldn't be configured as WRPROT. Reserving this region for the MMIO mapped SPI flash would also result in an overlap with the MMIO resources mentioned above. In the case of a smaller SPI flash, reserving the full 16 MByte flash MMIO region makes sure that the resource allocator won't try to put anything else in the lower parts of the 16 MByte SPI mapping region. To avoid the issues described above, always reserve/cache the maximum amount of 16 MBytes of flash that can be mapped below 4 GB. TEST=On boards with 16 MByte SPI flash chips, the resulting image of a timeless build doesn't change with this patch. Verified this on Chausie (Mendocino), Majolica (Cezanne), Cereme (Picasso) and Google/Careena (Stoneyridge). On Mandolin (Picasso) with an 8 MByte flash, the resulting image of a timeless build is different, but neither the coreboot console output nor the Linux dmesg output shows any errors that might be related to this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie12bd48e48e267a84dc494f67e8e0c7a4a01a320 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66700 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-20soc/amd/stoneyridge: move early I2C init to early_fch.cFelix Held
Since the I2C controller is part of the FCH, move the early initialization from bootblock.c to early_fch.c which also matches what the newer AMD SoCs do. TEST=Successfully boots on google/liara and all I2C/cr50/TPM functions appear to work properly Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I22d3a8888eaa34ea612da719c408c0083769e806 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66866 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-20soc/amd/stoneyridge/early_fch: use common lpc_early_init functionFelix Held
The functionality of sb_enable_lpc is implemented in the common LPC support code as lpc_enable_controller. This gets called by the common lpc_early_init which also calls lpc_disable_decodes and lpc_set_spibase. The lpc_set_spibase call was already done in bootblock_fch_early_init, so the main change in code behavior is that now lpc_disable_decodes gets called during early FCH initialization. The lpc_enable_port80 and sb_lpc_decode calls after the lpc_early_init code will reenable some of the decodes. TEST=Successfully boots on google/liara, cbmem and dmesg logs look clean Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia58a6f609fa149a6c09ed99f08bdc4f05eb56f96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66841 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-15soc/amd/*: move reset_i2c_peripherals call after early GPIO setupFelix Held
Since bootblock_soc_early_init gets called before bootblock_mainboard_early_init which does the early GPIO setup, external I2C level shifters that are controlled by GPIOs might not be enabled yet. Moving the reset_i2c_peripherals call to bootblock_soc_init makes sure that the early GPIO setup is already done when reset_i2c_peripherals is called. Haven't probed any SCL signal on the non-SoC side of the I2C level shifters yet, but the waveform on the SCL pin of I2C3 on the SoC of a barla/careena Chromebook doesn't have the longer than expected SCL pulses any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If02140aef56ed6db7ecee24811724b5b24e54a91 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-07-17soc/amd: Fix some white spaces issuesElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Ibe20d48bdd8c776f9658620a13814f96e564dabc Reviewed-on: https://review.coreboot.org/c/coreboot/+/65907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-07-17soc/amd/*/include/soc/iomap.h: Fix some white spaces issuesElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I7b6e41fa3b7cd8c8f7327c690212ec4990e8baf5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/65895 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-07-14arch/x86: Mark prepare_and_run_postcar noreturnArthur Heymans
This moves the die() statement to a common place. Change-Id: I24c9f00bfee169b4ca57b469c089188ec62ddada Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65812 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-06-22device/resource: Add _kb postfix for resource allocatorsKyösti Mälkki
There is a lot of going back-and-forth with the KiB arguments, start the work to migrate away from this. Change-Id: I329864d36137e9a99b5640f4f504c45a02060a40 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64658 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-06-21soc/amd/*: Move selection of DRIVERS_I2C_DESIGNWARE to common blockMatt DeVillier
All AMD SoCs which select SOC_AMD_COMMON_BLOCK_I2C also select DRIVERS_I2C_DESIGNWARE, so make the pairing explicit by moving the selection into SOC_AMD_COMMON_BLOCK_I2C. This will facilitating adding the Designware I2C bus ops handler in a subsequent commit. Change-Id: Ice30c8806766deb9a6ba617c3e633ab069af3b46 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-06-20soc/amd/stoneyridge: Align get_cpu_count to other targetsArthur Heymans
The CPUID function to get the number of cores on a package is common across multiple generations of AMD cpus. Change-Id: I28bff875ea2df7837e4495787cf8a4c2d522d43d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64869 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2022-06-20soc/amd/*: Make mtrr decision based on syscfgArthur Heymans
The syscfg has to option to automatically mark the range between 4G and TOM2, which contains DRAM, as WB. Making it generally not necessary to allocate MTRRs for memory above 4G if no PCI BARs are placed up there. Change-Id: Ifbacae28e272ab2f39f268ad034354a9c590d035 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64868 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2022-06-07arch/x86: Add a common romstage entryArthur Heymans
It might be possible to have this used for more than x86, but that will be for a later commit. Change-Id: I4968364a95b5c69c21d3915d302d23e6f1ca182f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55067 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-06-07Replace some ENV_ROMSTAGE with ENV_RAMINITKyösti Mälkki
With a combined bootblock+romstage ENV_ROMSTAGE might no longer evaluate true. Change-Id: I733cf4e4ab177e35cd260318556ece1e73d082dc Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63376 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-25arch/x86/acpi_bert_storage.c: Use a common implementationArthur Heymans
All targets now use cbmem for the BERT region, so the implementation can be common. This also drops the obsolete comment about the need to have bert in a reserved region (cbmem gets fixed to be in a reserved region). Change-Id: I6f33d9e05a02492a1c91fb7af94aadaa9acd2931 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64602 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-05-24soc/amd/stoneyridge: Move BERT into a cbmem regionArthur Heymans
This removes the need to align BERT so that TSEG remains aligned. Change-Id: I21b55a87838dcb4bd4099f051ba0a011a4d41eea Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64601 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-05-20CBMEM: Change declarations for initialization hooksKyösti Mälkki
There are efforts to have bootflows that do not follow a traditional bootblock-romstage-postcar-ramstage model. As part of that CBMEM initialisation hooks will need to move from romstage to bootblock. The interface towards platforms and drivers will change to use one of CBMEM_CREATION_HOOK() or CBMEM_READY_HOOK(). Former will only be called in the first stage with CBMEM available. Change-Id: Ie24bf4e818ca69f539196c3a814f3c52d4103d7e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63375 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-16arch/x86/postcar_loader.c: Change prepare_and_run_postcar signatureArthur Heymans
The postcar frame can now be a local variable to that function. Change-Id: I873298970fff76b9ee1cae7da156613eb557ffbc Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61964 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-16soc/amd/stoneyridge: Use common prepare_and_run_postcarArthur Heymans
This reduces boilerplate postcar frame setup. Change-Id: I8e258113c90ee49864ceddf36ea296ba6f83afe4 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61961 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-05-16arch/x86/postcar: Set up postcar MTRR in C codeArthur Heymans
Setting up postcar MTRRs is done when invd is already called so there is no reason to do this in assembly anymore. This also drops the custom code for Quark to set up MTRRs. TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set in postcar & ramstage. Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-05-12soc/amd/*/Makefile.inc: Do some cosmeticsArthur Heymans
The first target for the add_intermediate targets is always $(obj)/coreboot.pre. Change-Id: Iea2322ca1abd43900f3631b7965f07fed4235ca0 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56117 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Martin L Roth <gaumless@tutanota.com>
2022-04-29soc/{amd/stoneyridge,intel}: Don't select VBOOT_SEPARATE_VERSTAGEArthur Heymans
Now the bootblock is not limited to 64K so integrating vboot into the bootblock reduces the binary size. intel/apl is an exception since the bootblock size is limited to 32K. Change-Id: I5e02961183b5bcc37365458a3b10342e5bc2b525 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52788 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2022-04-22soc/amd: Remove unused <cbmem.h>Elyes HAOUAS
Change-Id: Ic8fea24f5f830294ce5b94374ce64d7ca2013c9c Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/61055 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2022-03-09soc/amd/*/lpc: rename SPIROM_BASE_ADDRESS_REGISTERFelix Held
Rename SPIROM_BASE_ADDRESS_REGISTER to SPI_BASE_ADDRESS_REGISTER to clarify that this isn't the address the SPI flash gets mapped, but the address of the SPI controller MMIO region. This also aligns the register name with the PPR. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifd9f98bd01b1c7197b80d642a45657c97f708bcd Reviewed-on: https://review.coreboot.org/c/coreboot/+/62578 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-03-07src: Make PCI ID define names shorterFelix Singer
Shorten define names containing PCI_{DEVICE,VENDOR}_ID_ with PCI_{DID,VID}_ using the commands below, which also take care of some spacing issues. An additional clean up of pci_ids.h is done in CB:61531. Used commands: * find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]\{2\}\([_0-9A-Za-z]\{8\}\)*[_0-9A-Za-z]\{0,5\}\)\t/PCI_\1ID_\3\t\t/g' * find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]*\)/PCI_\1ID_\3/g' Change-Id: If9027700f53b6d0d3964c26a41a1f9b8f62be178 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39331 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
2022-03-03soc/amd/*/northbridge,root_complex: add comment about PCI BARsFelix Held
Add a comment to point out that the read_resources functions aren't missing a pci_dev_read_resources call that would add the resources for the BARs of the PC device. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie480832e0d7954135d2171dda986e477ef7b6c09 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-03soc/amd/*/northbridge,root_complex: simplify GNB IOAPIC resource indexFelix Held
In the northbridge's and root complex' read_resources function, the GNB IOAPIC resource used MMIO base address of the GNB IOAPIC as index which might be misleading. Instead use idx++ as a unique index for this resource. TEST=Resource allocator doesn't complain and no related warnings or errors in dmesg. The update_constraints console output changes like expected: Before: PCI: 00:00.0 fec01000 base fec01000 limit fec01fff mem (fixed) After: PCI: 00:00.0 0d base fec01000 limit fec01fff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8061364879d772469882fc060f92676de6f600a9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62546 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-03soc/amd/*/northbridge,root_complex: simplify mmconf_resource indexFelix Held
In the northbridge's and root complex' read_resources function, the mmconf resource used the number of the MMIO_CONF_BASE MSR as index which might be misleading. Instead use idx++ as a unique index for this resource. TEST=Resource allocator doesn't complain and no related warnings or errors in dmesg. The update_constraints console output changes like expected: Before: PCI: 00:00.0 c0010058 base f8000000 limit fbffffff mem (fixed) After: PCI: 00:00.0 06 base f8000000 limit fbffffff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id66c6153fad86bed36db7bd2455075f4a0850750 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62545 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-03soc/amd/stoneyridge/acpi: rename cpu.asl to pnot.aslFelix Held
After the patch that moved the generation of the PPKG object to Stoneyridge's acpi.c, only the PNOT object remained in its cpu.asl, so rename it to pnot.asl. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0deb2d75cae98b8fcd31297d7fac5f27525efe65 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62540 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-03soc/amd/stoneyridge/acpi: generate PPKG object in generate_cpu_entriesFelix Held
Generate the PPKG object in the generate_cpu_entries function instead of generating the PCNT object that is the used in the PPKG method in cpu.asl to provide the PPKG object. This both simplifies the code and aligns Stoneyridge with the other AMD SoCs. This will also make the code behave correctly in a case where the number of CPU cores/threads isn't a power of two. TEST=None, but equivalent change on Picasso was verified to not break anything on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib42d718102151a72a5fe812e83eb2eb4f9e7b611 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-02-25arch/x86: consolidate HPET base address definitionsFelix Held
Both the HPET_BASE_ADDRESS define from arch/x86/include/arch/hpet.h and the HPET_ADDRESS Kconfig option define the base address of the HPET MMIO region which is 0xfed00000 on all chipsets and SoCs in the coreboot tree. Since these two different constants are used in different places that however might end up used in the same coreboot build, drop the Kconfig option and use the definition from arch/x86 instead. Since it's no longer needed to check for a mismatch of those two constants, the corresponding checks are dropped too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia797bb8ac150ae75807cb3bd1f9db5b25dfca35e Reviewed-on: https://review.coreboot.org/c/coreboot/+/62307 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Lance Zhao Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-25arch/x86: factor out and commonize HPET_BASE_ADDRESS definitionFelix Held
All x86 chipsets and SoCs have the HPET MMIO base address at 0xfed00000, so define this once in arch/x86 and include this wherever needed. The old AMD AGESA code in vendorcode that has its own definition is left unchanged, but sb/amd/cimx/sb800/cfg.c is changed to use the new common definition. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifc624051cc6c0f125fa154e826cfbeaf41b4de83 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62304 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-02-24treewide: Write minor version at acpi_create_fadt() functionElyes Haouas
When "fadt->FADT_MinorVersion" is not explicitly set to the right value, gcc sets it up to "0". So set it correctly for treewide. Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Ic9a8e097f78622cd78ba432e3b1141b142485b9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/62221 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Lance Zhao
2022-02-24soc/amd/*/include/soc/iomap.h: rework HPET base address checkFelix Held
The AMD SoCs had a check to make sure that HPET_ADDRESS_OVERRIDE isn't set so that the HPET_ADDRESS Kconfig option will have the right default value. Instead check if the HPET_ADDRESS Kconfig value matches the HPET_BASE_ADDRESS define in the SoC code which is the case if HPET_ADDRESS_OVERRIDE isn't selected. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icf1832eb36c031e93ba24f342e9a8a7bf13faecc Reviewed-on: https://review.coreboot.org/c/coreboot/+/62275 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-02-21[acpi]{include,soc/amd,southbridge/amd}: Clarify ARM_boot_arch in commentsElyes Haouas
Change-Id: I8b209da90b5a591f62e760961c64c4c63e6ef65b Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62040 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-02-21src/acpi: Add macro for FADT Minor Version and use itElyes Haouas
Change-Id: I6a0e9b33c6a1045a3a4a6717487525b82d41e558 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62036 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lance Zhao
2022-02-07treewide: Remove "ERROR: "/"WARN: " prefixes from log messagesJulius Werner
Now that the console system itself will clearly differentiate loglevels, it is no longer necessary to explicitly add "ERROR: " in front of every BIOS_ERR message to help it stand out more (and allow automated tooling to grep for it). Removing all these extra .rodata characters should save us a nice little amount of binary size. This patch was created by running find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';' and doing some cursory review/cleanup on the result. Then doing the same thing for BIOS_WARN with 's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi' Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Lance Zhao Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2022-02-05cpu/x86/lapic: Move LAPIC configuration to MP initKyösti Mälkki
Implementation for setup_lapic() did two things -- call enable_lapic() and virtual_wire_mode_init(). In PARALLEL_MP case enable_lapic() was redundant as it was already executed prior to initialize_cpu() call. For the !PARALLEL_MP case enable_lapic() is added to AP CPUs. Change-Id: I5caf94315776a499e9cf8f007251b61f51292dc5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2022-01-13soc/amd/*/chip.h: add missing gpio.h includeFelix Held
Since we need the GPIO defines in the devicetree settings, include gpio.h in each SoC's chip.h file which will indirectly include the soc-specific soc/gpio.h header instead of having it indirectly included via soc/i2c.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id26721a6b8ae94784d4a90d7ccac28fef2be36dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/60977 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2022-01-10src/soc/amd: Remove unused <console/console.h>Elyes HAOUAS
Found using: diff <(git grep -l '#include <console/console.h>' -- src/) <(git grep -l 'console_time_report\|console_time_get_and_reset\|do_putchar\|vprintk\|printk\|console_log_level\|console_init\|get_log_level\|CONSOLE_ENABLE\|get_console_loglevel\|die_notify\|die_with_post_code\|die\|arch_post_code\|mainboard_post\|post_code\|RAM_SPEW\|RAM_DEBUG\|BIOS_EMERG\|BIOS_ALERT\|BIOS_CRIT\|BIOS_ERR\|BIOS_WARNING\|BIOS_NOTICE\|BIOS_INFO\|BIOS_DEBUG\|BIOS_SPEW\|BIOS_NEVER' -- src/) |grep "<" Change-Id: Iff7fdd679ac31a121d56746ed8efa1b3da932638 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60924 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-01-05soc/amd: Remove unused <string.h>Elyes HAOUAS
Change-Id: Ibd3e7a62a2e833017f550eddd915b7dfb539d019 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/60558 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-12-20soc/amd/stoneyridge/fch: add GNVS-related TODOsFelix Held
The AOAC device states shouldn't be stored in GNVS, but be read from the AOAC registers during runtime. Same for the EHCI controller's BAR0. The location and size of the XHCI firmware can either be statically determined at build-time or have coreboot generate ACPI objects that contain the needed addresses. Since I can't easily test changes that require booting to a desktop on Stoneyridge at the moment, only add TODOs for now. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: I3691b05606b9430cb60923780a6131993a9887d4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/60196 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-20soc/amd/stoneyridge: split southbridge codeFelix Held
Split the southbridge code into a bootblock and a ramstage part to align it more with Picasso and Cezanne. Also move the implementation of fch_clk_output_48Mhz to the end of early_fch.c since it's not really related to the functions that were previously around it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib660fbef8dc25ba0fab803ccd82b3408878d1588 Reviewed-on: https://review.coreboot.org/c/coreboot/+/60142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-20soc/amd/stoneyridge: factor out AGESA-wrapper related FCH functionsFelix Held
Split the code that gets called from the AGESA wrapper from the rest of the FCH/southbridge code that directly interacts with the hardware. Since the remaining parts of southbridge.c aren't used in romstage, drop it from the list of build targets for romstage. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6197add0e1396a82545735653110e1e17bf9c303 Reviewed-on: https://review.coreboot.org/c/coreboot/+/60141 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-20soc/amd/stoneyridge: factor out early AOAC initializationFelix Held
Factor out enable_aoac_devices out of southbridge.c to aoac.c to align Stoneyridge more with Picasso and Cezanne. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ied4d821138507639cad1794f6c5017b5873b761f Reviewed-on: https://review.coreboot.org/c/coreboot/+/60140 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-20soc/amd: remove root of SoC directory from include pathFelix Held
We shouldn't be providing -I include paths to the root of the soc specific directory. It allows for lazy includes that can collide, but there's no way of knowing the winning path since the winning path is determined by Makefile.inc parsing order. This is taken from CB:41355 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I45ed219e4e0cccf3d4f04cc70dc1ef77c518afff Reviewed-on: https://review.coreboot.org/c/coreboot/+/60201 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-12-20soc/amd/stoneyridge/include/southbridge: remove unneeded chip.h includeFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9b37efc89e505c2de99536b59e7d7e2bb1d54bff Reviewed-on: https://review.coreboot.org/c/coreboot/+/60199 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-12-09soc/amd/stoneyridge: use common fch_spi_early_initFelix Held
All SPI interface setup related functionality that Stoneyridge implemented in its southbridge code is already present in the common AMD SoC code, so use that code instead. The common fch_spi_early_init function requires the SPI controller's base address to be set, so call lpc_set_spibase(SPI_BASE_ADDRESS) right before it. fch_spi_early_init then calls lpc_enable_spi_rom and lpc_enable_spi_prefetch which can be removed from the board code now. Next it calls fch_spi_configure_4dw_burst which does the same as the now removed sb_disable_4dw_burst function when SOC_AMD_COMMON_BLOCK_SPI_4DW_BURST is set to n which is the default. This option can also only be set to y for SoCs that aren't Stoneyridge. Finally fch_spi_early_init calls fch_spi_config_modes which configures the SPI mode and speed settings according to the Kconfig settings and the settings in the amdfw part. On Kahlee this was done by calls to sb_read_mode and sb_set_spi100 before. The previous patch added the remaining Kconfig settings, so the resulting register values don't change in the non-EM100 case. In the EM100 case the TPM speed is changed from 64 to 16 MHz. TEST=Both the non-EM100 mode with a real SPI flash and the EM100 mode with a first-generation EM100 results in Google/Barla reaching the payload and the show_spi_speeds_and_modes call in bootblock prints the expected settings: relevant bootblock console output in non-EM100 case: SPI normal read speed: 33.33 MHz SPI fast read speed: 66.66 Mhz SPI alt read speed: 66.66 Mhz SPI TPM read speed: 66.66 Mhz SPI100: Enabled SPI Read Mode: Dual IO (1-2-2) relevant bootblock console output in EM100 case: SPI normal read speed: 16.66 MHz SPI fast read speed: 16.66 MHz SPI alt read speed: 16.66 MHz SPI TPM read speed: 16.66 MHz SPI100: Enabled SPI Read Mode: Normal Read (up to 33M) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8f37a3b040808d6a5a8e07d39b6d4a1e1981355c Reviewed-on: https://review.coreboot.org/c/coreboot/+/59968 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-08soc/amd/{cezanne,picasso,stoney,common}: Don't clear PM1 on resumeRaul E Rangel
According to https://uefi.org/specs/ACPI/6.4/04_ACPI_Hardware_Specification/ACPI_Hardware_Specification.html#pm1-event-grouping > For ACPI/legacy systems, when transitioning from the legacy to the G0 > working state this register is cleared by platform firmware prior to > setting the SCI_EN bit (and thus passing control to OSPM). For ACPI > only platforms (where SCI_EN is always set), when transitioning from > either the mechanical off (G3) or soft-off state to the G0 working > state this register is cleared prior to entering the G0 working state. This means we don't want to clear the PM1 register on resume. By clearing it the linux kernel can't correctly increment the wake count when the power button is pressed. The AMD platforms implement the _SWS ACPI methods, but the linux kernel doesn't actually use these methods. BUG=b:172021431 TEST=suspend zork and push power button and verify power button wake_count increments. Verified other wake sources still work. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iaa886540d90f4751d14837c1485ef50ceca48561 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59929 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-12-08soc/amd/stoneyridge/southbridge: drop ENV_X86 checkFelix Held
Stoneyridge selects ARCH_X86 unconditionally and all coreboot code will run on the x86 cores. On Picasso and later, the Chromebooks run verstage on the PSP which is an ARM V7 core which needs some special handling cases in the code, but this doesn't apply to Stoneyridge. TEST=Timeless build results in an identical image for Google/Careena. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I013efd13b56c0191af034a8c4b58e9b26a31c6e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59960 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-12-08soc/amd/{cezanne,picasso,stoney}: Clear PM/GPE when enabling ACPIRaul E Rangel
According to https://uefi.org/specs/ACPI/6.4/16_Waking_and_Sleeping/sleeping-states.html?highlight=power%20states# > For ACPI/legacy systems, when transitioning from the legacy to the G0 > working state this register is cleared by platform firmware prior to > setting the SCI_EN bit. This change makes sure we clear the PM/GPE blocks are cleared before enabling the SCI_EN bit. BUG=b:172021431 TEST=Boot guybrush and morphius to OS and verify suspend resume still works. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Icc6f542185dc520f8d181423961b74481c0b5506 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59928 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-12-08soc/amd/stoneyridge/southbridge: fix setting SPI_USE_SPI100Felix Held
Use a read modify write sequence when setting the SPI_USE_SPI100 bit in the SPI100_ENABLE register. This avoids clearing other bits in the register which might cause instabilities of the SPI interface. The reference code for Stoneyrige also only sets the SPI_USE_SPI100 bit and doesn't zero out the other bits. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4d32fc2084bb34ea57924bae68511c6836587790 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-11-30soc/amd/stoneyridge/psp: move soc_get_mbox_address to common psp_gen1Felix Held
Despite Stoneyridge being one only SoC in soc/amd that uses the first generation of the PSP mailblox interface, this code is common for all SoCs that use the first PSP mailbox interface generation, so move it to the common PSP generation 1 code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I78126cb710a6ee674b58b35c8294685a5965ecd6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59701 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-11-29soc/amd/stoneyridge/psp: use PSP_MAILBOX_BAR defineFelix Held
PSP_MAILBOX_BAR is defined as PCI_BASE_ADDRESS_4, so use it instead of PCI_BASE_ADDRESS_4 in the code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8658b674b9adea85dfc71d7036ccf3ae17464b58 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59700 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-25soc/amd/stoneyridge: use SOC_AMD_COMMON_BLOCK_ACPI_GPIOFelix Held
Stoneyridge uses the same GPIO bank peripheral as Picasso and Cezanne so we can use the common AMD SoC GPIO ACPI code. TEST=none Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifa1fc923cd5b779765917b171b5a7222f18a176a Reviewed-on: https://review.coreboot.org/c/coreboot/+/59596 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-11-24soc/amd/picasso,stoneyridge/acpi: use define for RTC_DATE_ALARMFelix Held
Cezanne already uses a define for this and it's better to define and use constants instead of magic values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifa4b3b3cdb161670128b284a3396fc5a85545608 Reviewed-on: https://review.coreboot.org/c/coreboot/+/59586 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-11-18amdfwtool: Call the set_efs_table for StoneyridgeZheng Bao
Related to https://review.coreboot.org/c/coreboot/+/58555 commit-id: 35b7e0a2d82ac In 58555, we added the SOC ID for Stoneyridge in amdfwtool command line. But it raised building error because it then called "set_efs_table" without setting SPI mode. So we skipped calling that. But in set_efs_table, it has case for Stoneyridge. The boards also need to have this setting. So we remove the skipping and give the proper SPI mode in mainboard Kconfig. Change-Id: I24499ff6daf7878b12b6044496f53379116c598f Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58871 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-11-15amdfwtool: Set soc name for StoneyridgeZheng Bao
For the stoneyridge, soc_name is not set in Makefile, so set_efs_table is not called. Keep it unchanged. Change-Id: I0e82188ce64733420a578446e22a077ef789be92 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58555 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-11-15soc/amd/stoneyridge/include/pci_devs: remove unused DEVID definesFelix Held
None of the *_DEVID defines was used in the code, so drop those. The SoC code uses the PCI ID defines from include/device/pci_ids.h instead. Since it might still be useful to have the PCI device IDs as a reference in the SoC's pci_devs.h, add those as comments instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7c77d648dac57b15b56f631bd8b2494676c00a8b Reviewed-on: https://review.coreboot.org/c/coreboot/+/59268 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-10Rename ECAM-specific MMCONF KconfigsShelley Chen
Currently, the MMCONF Kconfigs only support the Enhanced Configuration Access mechanism (ECAM) method for accessing the PCI config address space. Some platforms have a different way of mapping the PCI config space to memory. This patch renames the following configs to make it clear that these configs are ECAM-specific: - NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT - MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT - MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS - MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER - MMCONF_LENGTH --> ECAM_MMCONF_LENGTH Please refer to CB:57861 "Proposed coreboot Changes" for more details. BUG=b:181098581 BRANCH=None TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max Make sure Jenkins verifies that builds on other boards Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2 Signed-off-by: Shelley Chen <shchen@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-11-05soc/amd/*/include/smi: move NUMBER_SMITYPES definition to the topFelix Held
Since all other defines for the number of certain things are at the top of the file, move NUMBER_SMITYPES there as well to keep things consistent. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idfb599531d6cc382ab258bd1eae89e7b35fa9e79 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58953 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-05soc/amd/*/include/smi: fix off-by-one in SCIMAPS definesFelix Held
SCIMAPS is the total number of SCI to GEVENT mappings. configure_scimap returns early when the scimap is greater or equal than SCIMAPS, so for SMITYPE_ACDC_TIMER it returned early without doing what was expected from it to do despite that being a valid value, so fix this off-by-one. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibaf8c5618ddbf0b8d4cd612a7f1347d8562bbfcb Reviewed-on: https://review.coreboot.org/c/coreboot/+/58952 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-04amd/i2c: Remove the weak functionZheng Bao
BUG=b:140165023 Change-Id: Ieedd6c9f3abeed9839892e5d07127862cd47d57f Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58771 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-11-03soc/amd/*/cpu: handle mp_init_with_smm failureFelix Held
When the mp_init_with_smm call returns a failure, coreboot can't just continue with the initialization and boot process due to the system being in a bad state. Ignoring the failure here would just cause the boot process failing elsewhere where it may not be obvious that the failed multi-processor initialization step was the root cause of that. I'm not 100% sure if calling do_cold_reset or calling die_with_post_code is the better option here. Calling do_cold_reset likely here would likely result in a boot-failure loop, so I call die_with_post_code here. BUG=b:193809448 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifeadffb3bae749c4bbd7ad2f3f395201e67d9e28 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58859 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-11-03cpu/amd/mtrr: Remove topmem global variablesArthur Heymans
The comments are not correct anymore. With AGESA there is no need to synchronize TOM_MEMx msr's between AP's. It's also not the best place to do so anyway. Change-Id: Iecbe1553035680b7c3780338070b852606d74d15 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58693 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-11-03cpu/x86/Kconfig: Remove unused CPU_ADDR_BITSArthur Heymans
Change-Id: I88f62c18b814ac0ddd356944359e727d6e3bba5a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58688 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
2021-11-03soc/amd/stoneyridge/cpu: remove unneeded line break in get_cpu_countFelix Held
The line length is no longer limited to 80 characters, so there's no need for that line break any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7a8fb472f00e039f25a71ee526a3dd0bc6c754f6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-26cpu/x86: Introduce and use `CPU_X86_LAPIC`Felix Held
With using a Kconfig option to add the x86 LAPIC support code to the build, there's no need for adding the corresponding directory to subdirs in the CPU/SoC Makefile. Comparing which CPU/SoC Makefiles added (cpu/)x86/mtrr and (cpu/)x86/lapic before this and the corresponding MTRR code selection patch and having verified that all platforms added the MTRR code on that patch shows that soc/example/min86 and soc/intel/quark are the only platforms that don't end up selecting the LAPIC code. So for now the default value of CPU_X86_LAPIC is chosen as y which gets overridden to n in the Kconfig of the two SoCs mentioned above. Change-Id: I6f683ea7ba92c91117017ebc6ad063ec54902b0a Signed-off-by: Angel Pons <th3fanbus@gmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44228 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-10-26soc/*/Makefile: don't add cpu/x86/cacheFelix Held
No SoC uses the ramstage-only x86_enable_cache helper function to call enable_cache with some added port 0x80 and console output. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I7c5039e1341fd4089078ad7ffb2fe6584a94045c Reviewed-on: https://review.coreboot.org/c/coreboot/+/58547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-10-25cpu,soc/amd/*/Makefile: don't add cpu/x86/pae a second timeFelix Held
Since cpu/x86/Makefile.inc already adds the pae sub-directory, there is no need to include it in the Makefile of a CPU or SoC, so remove it from those Makefiles. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I78368f7eb880fb64f511a2fa8c8acde222d0dca3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58546 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-10-25cpu,soc/x86: always include cpu/x86/mtrr on x86 CPUs/SoCsFelix Held
All x86-based CPUs and SoCs in the coreboot tree end up including the Makefile in cpu/x86/mtrr, so include this directly in the Makefile in cpu/x86 to add it for all x86 CPUs/SoCs. In the unlikely case that a new x86 CPU/SoC will be added, a CPU_X86_MTRR Kconfig option that is selected be default could be added and the new CPU/SoC without MTRR support can override this option that then will be used in the Makefile to guard adding the Makefile from the cpu/x86/mtrr sub-directory. In cpu/intel all models except model 2065X and 206AX are selcted by a socket and rely on the socket's Makefile.inc to add x86/mtrr to the subdirs, so those models don't add x86/mtrr themselves. The Intel Broadwell SoC selects CPU_INTEL_HASWELL and which added x86/mtrr to the subdirs. The Intel Xeon SP SoC directory contains two sub-folders for different versions or generations which both add x86/mtrr to the subdirs in their Makefiles. Change-Id: I743eaac99a85a5c712241ba48a320243c5a51f76 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44230 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-10-22arch/x86/ioapic: Select IOAPIC with SMPKyösti Mälkki
For coreboot proper, I/O APIC programming is not really required, except for the APIC ID field. We generally do not guard the related set_ioapic_id() or setup_ioapic() calls with CONFIG(IOAPIC). In practice it's something one cannot leave unselected, but maintain the Kconfig for the time being. Change-Id: I6e83efafcf6e81d1dfd433fab1e89024d984cc1f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-22cpu/x86/mp_init: move printing of failure message into mp_init_with_smmFelix Held
Each CPU/SoC checks the return value of the mp_init_with_smm and prints the same error message if it wasn't successful, so move this check and printk to mp_init_with_smm. For this the original mp_init_with_smm function gets renamed to do_mp_init_with_smm and a new mp_init_with_smm function is created which then calls do_mp_init_with_smm, prints the error if it didn't return CB_SUCCESS and passes the return value of do_mp_init_with_smm to its caller. Since no CPU/SoC code handles a mp_init_with_smm failure apart from printing a message, also add a comment at the mp_init_with_smm call sites that the code might want to handle a failure. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I181602723c204f3e43eb43302921adf7a88c81ed Reviewed-on: https://review.coreboot.org/c/coreboot/+/58498 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-21cpu/x86/mp_init: use cb_err as mp_init_with_smm return typeFelix Held
Using cb_err as return type clarifies the meaning of the different return values. This patch also adds the types.h include that provides the definition of the cb_err enum and checks the return value of mp_init_with_smm against the enum values instead of either checking if it's non-zero or less than zero to handle the error case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibcd4a9a63cc87fe176ba885ced0f00832587d492 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58491 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-10-16soc/amd/stoneyridge/include/iomap: rename I2C[ABCD]_BASE_ADDRESS definesFelix Held
Picasso and Cezanne define and use APU_I2C[01234]_BASE for the base addresses of the I2C controllers, so align Stoneyridge with this. The ACPI device names aren't changed from I2C[ABCD] to I2C[0123] for now since this might change behavior in the OS and would also change the resulting binary of a timeless build. TEST=Timeless build results in identical image for Google/Treeya. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9c400c073eba5c14bd35703b717f75df89a8719d Reviewed-on: https://review.coreboot.org/c/coreboot/+/58370 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-15soc/amd/stoneyridge/acpi/sb_fch: use I2C[ABCD]_BASE_ADDRESS definesFelix Held
Now that the I2C[ABCD]_BASE_ADDRESS defines aren't macros that calculate the MMIO addresses any more, those defines can also be used in the ACPI code. TEST=Timeless build results in identical image for Google/Treeya. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7de2f83dc2f8061d8f1735caf10314bcddb2d3fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/58337 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-15soc/amd/stoneyridge/include/iomap: drop I2C_BUS_ADDRESS(x) macroFelix Held
The I2C_BUS_ADDRESS(x) macro isn't used to iterate over the I2C controller base addresses, so drop this and use the fixed MMIO address for the I2C[ABCD]_BASE_ADDRESS defines instead which also allows using those defines in the ACPI code. TEST=Timeless build results in identical image for Google/Treeya. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idd7484a0322dc5167cbb7fdcd9a2583f0dbed50e Reviewed-on: https://review.coreboot.org/c/coreboot/+/58336 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-15soc/amd/common/block/i2c: implement proper read_resourceFelix Held
Before this patch the reservation of the MMIO region of the I2C controllers was done in the LPC controller PCI device despite the I2C controllers already being devices in the devicetree. This patch implements this functionality as read_resources function of the I2C device instead. This will only reserve the memory when the I2C devices are enabled in devicetree which is a change from the previous behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I67c853df3be2f593ecfa113ae2f74e5df7cf74e0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58307 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-10-13soc/amd/*: Enable ACPIMMIO decode first in fch_pre_initFelix Held
Since the GPIO mux/control MMIO regions are within the ACPIMMIO region, we need to call enable_acpimmio_decode_pm04 here first so that accessing the GPIO registers will work. BUG=None TEST=Build and boot to OS in Guybrush. Change-Id: I4bc076261c72cf999a5f2464b74cff6bf694d473 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57782 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-05src/soc to src/superio: Fix spelling errorsMartin Roth
These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ieafbc93e49fcef198ac6e31fc8a3b708c395e08e Reviewed-on: https://review.coreboot.org/c/coreboot/+/58082 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-24soc/amd/common: move block/pi out of the block folderFelix Held
Since the binaryPI glue code is specific to a binary interface, but not for a hardware block, move it out of the common blocks directory. This also brings the binaryPI support in line with the FSP support which is used on the newer generations. This also drops the SOC_AMD_COMMON_BLOCK_PI Kconfig option and makes use of the already existing SOC_AMD_PI Kconfig option instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I014e538f2772938031950475e456cc40dd05d74c Reviewed-on: https://review.coreboot.org/c/coreboot/+/57884 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-09-24soc/amd/common/block: move binaryPI S3 block into PI blockFelix Held
The code in soc/amd/common/block/s3 is specific to the AMD binaryPI coreboot integration, so move the code to soc/amd/common/block/pi. This drops the SOC_AMD_COMMON_BLOCK_S3 Kconfig option and integrates the dependencies and selections into the SOC_AMD_COMMON_BLOCK_PI Kconfig option. Since only selecting SOC_AMD_COMMON_BLOCK_PI but not SOC_AMD_COMMON_BLOCK_S3 resulted in missing functions in the linking process, we don't lose support for any working configuration by only having one Kconfig option for both parts. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib2bd99a88d8b05216688bc45d9c4f23a007ce870 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57883 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-09-23soc/amd/common/blocks/include: rename gpio_banks.h to gpio.hFelix Held
This brings the AMD SoC GPIO code in line with the Intel SoC code and removes the not really needed suffix. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie2dbec81dfe503869beb2872b01a7475e2b88b33 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57842 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-09-09soc/amd/common/block/include/i2c: introduce I2C_RESET_SCL_PIN macroFelix Held
Add and use the I2C_RESET_SCL_PIN macro for populating the i2c_scl_pins array that is used for the sb_reset_i2c_peripherals call to bring the I2C buses into a defined state. TEST=Timeless build results in identical image for Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ifedc09d0bf745545fa0510df7d5037f02b9012a6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57479 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-09-08cpu/x86/tsc: Deduplicate Makefile logicAngel Pons
The code under `cpu/x86/tsc` is only compiled in when its `Makefile.inc` is included from platform (CPU/SoC) code and the `UDELAY_TSC` Kconfig option is enabled. Include `cpu/x86/tsc/Makefile.inc` once from `cpu/x86/Makefile.inc` and drop the now-redundant inclusions from platform code. Also, deduplicate the `UDELAY_TSC` guards. Change-Id: I41e96026f37f19de954fd5985b92a08cb97876c1 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57456 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-08soc/amd/*/bootblock,early_fch: rework i2c_scl_pins configurationFelix Held
drive_scl in soc/amd/common/block/i2c/i2c.c writes the raw GPIO MMIO configuration register and drives it as output, so don't initially configure the GPIO as input with no pull up/down. This is a preparation to use the common AMD GPIO access functions instead of the raw register accesses, since the gpio_set function only sets the output value, but doesn't reconfigure the direction. Using gpio_output there instead would reconfigure the direction as well, but would result in doubling the number of MMIO accesses, so just configure the GPIOs correctly right away to avoid that. TEST=The waveform on the SCL pin of I2C3 on a barla/careena Chromebook looks exactly the same as before during the reset_i2c_peripherals call. This was probed at the SCL pad of the unpopulated I2C level shifter on the side that is connected to the SoC. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8e94afe0c755a02abcc722d5094e220d8781f8f5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56807 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-09-03src/*: Specify type of `DIMM_SPD_SIZE` onceAngel Pons
Specify the type of the `DIMM_SPD_SIZE` Kconfig symbol once. Change-Id: I619833dbce6d2dbe414ed9b37f43196b4b52730e Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57257 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-08-31soc/amd/*/include/soc/gpio: remove GPIO_2_EVENTFelix Held
commit de7262f82cdc1a7c868dbc9ca41e186e885eb2ba (soc/amd: remove special GPIO_2 override soc_gpio_hook) removed the workaround that needed those definitions, so remove the now unused GPIO_2_EVENT definitions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3f3e3061eade0e0cd25e2263451ccf6cefdc4ea4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56812 Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-08-30soc/amd: Show SPI settings in bootblockMartin Roth
BUG=b:194919326 TEST=See SPI settings in bootblock Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I8ee8981986990240b09414cde8b84d9b109cb5b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56961 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2021-08-19acpi: Fill fadt->century based on KconfigNico Huber
Change-Id: I916f19e022633b316fbc0c6bf38bbd58228412be Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56218 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lance Zhao Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-07-26soc/amd/common/block/acpimmio: add Kconfig option for biosram accessorsFelix Held
The biosram accessor support in soc/amd/common/block/acpimmio/biosram.c is only used on Stoneyridge and the old amd/southbridge code and not on Picasso or Cezanne. It also only builds as a 32 bit binary and breaks when trying to build as a 64 bit binary, since the size of an uintptr_t is different on those two. There is no support for using the 32 bit binaryPI with a 64 bit coreboot while there is code to use a 32 bit FSP with 64 bit coreboot, so not building this for FSP-based SoC support moves us one step closer to be able to build coreboot as 64 bit binary for Picasso and Cezanne. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2d87ec2fa1b217eaf55d865e4390308812502e56 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56570 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-07-23soc/amd/stoneyridge/fch: change sb prefix of sb_clk_output_48Mhz to fchFelix Held
Stoneyridge has an integrated FCH and no south bridge, so change the sb prefix to fch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5154ae1158f864d4a2aca55e6bcce6a742c6afe1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/56527 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-15soc/amd/stoneyridge/mca: implement and use mca_has_expected_bank_countFelix Held
This aligns the mca_check_all_banks implementation in the common mca.c with the one in the common mcax.c file. Do the MCA bank count check before the !is_warm_reset() check, so that a mismatch also gets printed on the cold boot path. Change-Id: Idbd3e9ce9c7483f84f87adab7adac47335cd59aa Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56311 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2021-07-15soc/amd/*/mca: factor out common MCA/MCAX check & print functionalityFelix Held
For Cezanne stubs are added for the functions that the SoC-specific code needs to provide. Since the mca_is_valid_bank stub on Cezanne always returns false, the checks get skipped for it at the moment. The actual functionality will be added in a later patch. Change-Id: Ic31e9b1ca7f8fac0721c95935c79150d7f774aa4 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56290 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2021-07-15soc/amd/*/mca: factor out BERT entry generation to soc/amd/commonFelix Held
Change-Id: I960a2f384f11e4aa5aa2eb0645b6046f9f2f8847 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56283 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-14soc/amd: factor out check_mca to common codeFelix Held
Change-Id: I139d1fe41bad5213da8890c2867f275b6847e3e1 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56281 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-14soc/amd: move check_mca prototype to soc/amd/common/blocks/includeFelix Held
Change-Id: Ia489dbfba59c334cf29f96a4000cef73b9b797d4 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56279 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-14soc/amd/stoneyridge: add and use mca_is_valid_bank & mca_get_bank_nameFelix Held
This patch changes the way how the not implemented MCA bank 3 gets skipped. For the not implemented bank 3 the name gets set to NULL resulting in mca_is_valid_bank returning false causing the bank to get skipped. This is a preparation for commonizing the MCA(X) handing in the soc/amd sub-tree. Change-Id: I40d6a6752504d804c45b445fce7e763e80161211 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56277 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 13:28:09 +0000