GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/soc/amd/picasso/acpi.c

360 lines
10 KiB
C
Raw Normal View History

soc/amd: Use SPDX for GPL-2.0-only files Done with sed and God Lines. Only done for C-like code for now. Change-Id: I22fffa0eab006be2bad4d3dd776b22ad9830faef Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-04-04 18:50:57 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
/*
* ACPI - create the Fixed ACPI Description Tables (FADT)
*/
#include <console/console.h>
acpi: Move ACPI table support out of arch/x86 (3/5) This change moves all ACPI table support in coreboot currently living under arch/x86 into common code to make it architecture independent. ACPI table generation is not really tied to any architecture and hence it makes sense to move this to its own directory. In order to make it easier to review, this change is being split into multiple CLs. This is change 3/5 which basically is generated by running the following command: $ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g' BUG=b:155428745 Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-05-02 19:24:23 +02:00
#include <acpi/acpi.h>
#include <acpi/acpigen.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <device/pci_ops.h>
#include <arch/ioapic.h>
soc/amd/picasso: Give the mainboard the ability to modify the MADT table By default legacy ISA IRQs use edge triggering. Depending on what devices are used the IRQ types might need to be changed. We add a setting to the device tree to allow the mainboard to configure the IRS IRQs. BUG=b:145102877 TEST=Booted trembyle and was able to use the keyboard. Change-Id: Ie95e8cc7ca835fb60bee8f10d5f28def6c2801dc Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2033493 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41577 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-01-31 20:53:45 +01:00
#include <arch/smp/mpspec.h>
soc/amd/picasso: Separate CPUID defs into new header Move CPUID definitions out of msr.h into new cpuid.h header. BUG=b:155307433 BRANCH=Zork Change-Id: I2ed5e0a5a6dbdb38fce8bf3e769f680330718653 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48533 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2020-12-10 12:28:38 +01:00
#include <cpu/amd/cpuid.h>
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
#include <cpu/amd/msr.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <cpu/x86/smm.h>
#include <device/device.h>
#include <device/pci.h>
#include <amdblocks/acpimmio.h>
#include <amdblocks/acpi.h>
soc/amd: Move fadt device tree settings into common_config This is ACPI specific config that applies to all the AMD SoCs. Stoney doesn't currently use this, but we can add that functionality later. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I0be7d917d7c5ba71347aa646822a883e2cf55743 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50557 Reviewed-by: Mathew King <mathewk@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-11 18:35:32 +01:00
#include <amdblocks/chip.h>
soc/amd/picasso/cpu: move get_cpu_count to common code Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0690787f492d764a20a4219822eb10fb5cd86de0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50406 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-02-08 22:23:54 +01:00
#include <amdblocks/cpu.h>
soc/amd: introduce and use common IOAPIC IDs Stoneyridge used CONFIG_MAX_CPUS and CONFIG_MAX_CPUS + 1 directly as IOAPIC IDs and Picasso had Kconfig options to configure that, but still used the common SMBus controller code that used CONFIG_MAX_CPUS as ID for the FCH IOAPIC. If a board overrides the PICASSO_FCH_IOAPIC_ID Kconfig option to a value that isn't CONFIG_MAX_CPUS, we'll get a mismatch between the ID that gets written into the FCH IOAPIC register and the ID in the corresponding ACPI table. In order to avoid that add defines to each SOC's southbridge.c and use them in all soc/amd code. Change-Id: I94f54d3e6d284391ae6ecad00a76de18dcdd4669 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50575 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-12 00:43:20 +01:00
#include <amdblocks/ioapic.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <soc/acpi.h>
#include <soc/pci_devs.h>
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
#include <soc/msr.h>
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
#include <soc/southbridge.h>
#include <soc/gpio.h>
#include <version.h>
soc/amd/picasso: Give the mainboard the ability to modify the MADT table By default legacy ISA IRQs use edge triggering. Depending on what devices are used the IRQ types might need to be changed. We add a setting to the device tree to allow the mainboard to configure the IRS IRQs. BUG=b:145102877 TEST=Booted trembyle and was able to use the keyboard. Change-Id: Ie95e8cc7ca835fb60bee8f10d5f28def6c2801dc Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2033493 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41577 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-01-31 20:53:45 +01:00
#include "chip.h"
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
unsigned long acpi_fill_madt(unsigned long current)
{
/* create all subtables for processors */
current = acpi_create_madt_lapics(current);
current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *)current,
soc/amd: introduce and use common IOAPIC IDs Stoneyridge used CONFIG_MAX_CPUS and CONFIG_MAX_CPUS + 1 directly as IOAPIC IDs and Picasso had Kconfig options to configure that, but still used the common SMBus controller code that used CONFIG_MAX_CPUS as ID for the FCH IOAPIC. If a board overrides the PICASSO_FCH_IOAPIC_ID Kconfig option to a value that isn't CONFIG_MAX_CPUS, we'll get a mismatch between the ID that gets written into the FCH IOAPIC register and the ID in the corresponding ACPI table. In order to avoid that add defines to each SOC's southbridge.c and use them in all soc/amd code. Change-Id: I94f54d3e6d284391ae6ecad00a76de18dcdd4669 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50575 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-12 00:43:20 +01:00
FCH_IOAPIC_ID, IO_APIC_ADDR, 0);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
soc/amd/picasso: Add MADT entry for GNB IOAPIC Add the missing entry using new Kconfig symbol for IOAPIC ID. coreboot will always enable the GNB IOAPIC. Cq-Depend: chrome-internal:3247431, chrome-internal:3253044 BUG=b:167421913, b:166519072 TEST=Boot fully to morphius board with and without amd_iommu kernel parameter. Dump MADT and IVRS tables. Cross check ioapic entries in MADT against IVRS. BRANCH=Zork Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Change-Id: Ic4a2e9b71dba948e8a4907e5f97131426d8a4a3e Reviewed-on: https://review.coreboot.org/c/coreboot/+/45056 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-03 01:49:10 +02:00
current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *)current,
soc/amd: introduce and use common IOAPIC IDs Stoneyridge used CONFIG_MAX_CPUS and CONFIG_MAX_CPUS + 1 directly as IOAPIC IDs and Picasso had Kconfig options to configure that, but still used the common SMBus controller code that used CONFIG_MAX_CPUS as ID for the FCH IOAPIC. If a board overrides the PICASSO_FCH_IOAPIC_ID Kconfig option to a value that isn't CONFIG_MAX_CPUS, we'll get a mismatch between the ID that gets written into the FCH IOAPIC register and the ID in the corresponding ACPI table. In order to avoid that add defines to each SOC's southbridge.c and use them in all soc/amd code. Change-Id: I94f54d3e6d284391ae6ecad00a76de18dcdd4669 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50575 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-12 00:43:20 +01:00
GNB_IOAPIC_ID, GNB_IO_APIC_ADDR, IO_APIC_INTERRUPTS);
soc/amd/picasso: Add MADT entry for GNB IOAPIC Add the missing entry using new Kconfig symbol for IOAPIC ID. coreboot will always enable the GNB IOAPIC. Cq-Depend: chrome-internal:3247431, chrome-internal:3253044 BUG=b:167421913, b:166519072 TEST=Boot fully to morphius board with and without amd_iommu kernel parameter. Dump MADT and IVRS tables. Cross check ioapic entries in MADT against IVRS. BRANCH=Zork Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Change-Id: Ic4a2e9b71dba948e8a4907e5f97131426d8a4a3e Reviewed-on: https://review.coreboot.org/c/coreboot/+/45056 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-03 01:49:10 +02:00
soc/amd/picasso,stoneyridge/acpi: use defines for MADT parameters Using existing defines instead of magic values improves readability of the code. Also add comments to the MADT IRQ overrides to make it clearer what those actually do. TEST=Timeless build results in identical binary for amd/gardenia (Stoneyridge), amd/mandolin (Picasso) and amd/majolica (Cezanne) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I224ffbe8eb65bcdd5fc70c0ff8b15d55b3f6be01 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55613 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-06-17 15:48:25 +02:00
/* PIT is connected to legacy IRQ 0, but IOAPIC GSI 2 */
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)current,
MP_BUS_ISA, 0, 2,
MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT);
/* SCI IRQ type override */
current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *)current,
MP_BUS_ISA, 9, 9,
MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW);
soc/amd/picasso: Give the mainboard the ability to modify the MADT table By default legacy ISA IRQs use edge triggering. Depending on what devices are used the IRQ types might need to be changed. We add a setting to the device tree to allow the mainboard to configure the IRS IRQs. BUG=b:145102877 TEST=Booted trembyle and was able to use the keyboard. Change-Id: Ie95e8cc7ca835fb60bee8f10d5f28def6c2801dc Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2033493 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41577 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-01-31 20:53:45 +01:00
soc/amd: Move MADT IRQ override settings into common_config This is another common ACPI setting. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Iefecabae1d83996a9a4aaadd2a53c2432441e1b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50558 Reviewed-by: Mathew King <mathewk@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-11 19:07:11 +01:00
current = acpi_fill_madt_irqoverride(current);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
/* create all subtables for processors */
current += acpi_create_madt_lapic_nmi((acpi_madt_lapic_nmi_t *)current,
soc/amd/picasso,stoneyridge/acpi: use defines for MADT parameters Using existing defines instead of magic values improves readability of the code. Also add comments to the MADT IRQ overrides to make it clearer what those actually do. TEST=Timeless build results in identical binary for amd/gardenia (Stoneyridge), amd/mandolin (Picasso) and amd/majolica (Cezanne) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I224ffbe8eb65bcdd5fc70c0ff8b15d55b3f6be01 Reviewed-on: https://review.coreboot.org/c/coreboot/+/55613 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-06-17 15:48:25 +02:00
ACPI_MADT_LAPIC_NMI_ALL_PROCESSORS,
MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH,
1 /* 1: LINT1 connect to NMI */);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
return current;
}
/*
* Reference section 5.2.9 Fixed ACPI Description Table (FADT)
* in the ACPI 3.0b specification.
*/
soc/amd/stoneyridge,picasso: Select COMMON_FADT Change-Id: I0c98bf7f88c33691401ebc6b174d959dd515dd11 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41921 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-30 17:54:39 +02:00
void acpi_fill_fadt(acpi_fadt_t *fadt)
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
{
soc/amd: Move fadt device tree settings into common_config This is ACPI specific config that applies to all the AMD SoCs. Stoney doesn't currently use this, but we can add that functionality later. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I0be7d917d7c5ba71347aa646822a883e2cf55743 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50557 Reviewed-by: Mathew King <mathewk@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-11 18:35:32 +01:00
const struct soc_amd_common_config *cfg = soc_get_common_config();
soc/amd/picasso: use FADT devicetree configuration options Two of the items in the FADT ACPI table frequently are partially board- specific, so let's make it easy to update them via devicetree settings. - fadt_boot_arch 0="legacy free" which while reasonable, probably isn't what will be wanted by most mainboards, so this should generally get updated in the specific devicetree. - In fadt_flags all chipset-specific flags get set while the mainboard has to set all other flags that it needs to have set. This patch changes the default for fadt_boot_arch. Change-Id: I6e8d0c60cadfdd24b6926703b252abbc56d436de Signed-off-by: Martin Roth <martinroth@chromium.org> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43418 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-12-02 00:49:19 +01:00
soc/amd/picasso: remove PICASSO_ACPI_IO_BASE Kconfig option This was the only I/O base address in Kconfig, no board changed it and if a board changed it, it needs to make sure that it won't overlap with other I/O resources, so just use the same value as constant in the define instead of the value from Kconfig. Also remove the PICASSO_ prefix from ACPI_IO_BASE. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7ea62f1101ddefa8785da92de5ba2aaf7945694a Reviewed-on: https://review.coreboot.org/c/coreboot/+/50287 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-02-04 21:31:49 +01:00
printk(BIOS_DEBUG, "pm_base: 0x%04x\n", ACPI_IO_BASE);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->sci_int = 9; /* IRQ 09 - ACPI SCI */
arch/x86: Declare permanent_smi_handler() Advertising SMI triggers in FADT is only valid if we exit with SMI installed. There has been some experiments to delay SMM installation to OS, yet there are new platforms that allow some configuration access only to be done inside SMM. Splitting static HAVE_SMI_HANDLER variable helps to manage cases where SMM might be both installed and cleared prior to entering payload. Change-Id: Iad92c4a180524e15199633693446a087787ad3a2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41910 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-08-11 00:22:28 +02:00
if (permanent_smi_handler()) {
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->smi_cmd = APM_CNT;
fadt->acpi_enable = APM_CNT_ACPI_ENABLE;
fadt->acpi_disable = APM_CNT_ACPI_DISABLE;
}
fadt->pm1a_evt_blk = ACPI_PM_EVT_BLK;
fadt->pm1a_cnt_blk = ACPI_PM1_CNT_BLK;
fadt->pm_tmr_blk = ACPI_PM_TMR_BLK;
fadt->gpe0_blk = ACPI_GPE0_BLK;
fadt->pm1_evt_len = 4; /* 32 bits */
fadt->pm1_cnt_len = 2; /* 16 bits */
fadt->pm_tmr_len = 4; /* 32 bits */
fadt->gpe0_blk_len = 8; /* 64 bits */
fadt->p_lvl2_lat = ACPI_FADT_C2_NOT_SUPPORTED;
fadt->p_lvl3_lat = ACPI_FADT_C3_NOT_SUPPORTED;
fadt->duty_offset = 1; /* CLK_VAL bits 3:1 */
fadt->duty_width = 3; /* CLK_VAL bits 3:1 */
soc/amd/picasso,stoneyridge/acpi: use define for RTC_DATE_ALARM 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-18 20:41:40 +01:00
fadt->day_alrm = RTC_DATE_ALARM;
soc/amd/picasso/acpi: Set missing RTC offsets The RTC Date Alarm and RTC AltCentury fields are supported on picasso. These get consumed by the linux kernel: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/third_party/kernel/v5.4/drivers/rtc/rtc-cmos.c;l=1243 BUG=b:160277722 TEST=Boot kernel and make sure suspend stress test works. Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ie83d7e0a06107a6de095f3e4c521d91e90920c0b Reviewed-on: https://review.coreboot.org/c/coreboot/+/44448 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2020-08-12 20:13:35 +02:00
fadt->mon_alrm = 0;
soc/amd/picasso: use FADT devicetree configuration options Two of the items in the FADT ACPI table frequently are partially board- specific, so let's make it easy to update them via devicetree settings. - fadt_boot_arch 0="legacy free" which while reasonable, probably isn't what will be wanted by most mainboards, so this should generally get updated in the specific devicetree. - In fadt_flags all chipset-specific flags get set while the mainboard has to set all other flags that it needs to have set. This patch changes the default for fadt_boot_arch. Change-Id: I6e8d0c60cadfdd24b6926703b252abbc56d436de Signed-off-by: Martin Roth <martinroth@chromium.org> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43418 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-12-02 00:49:19 +01:00
fadt->iapc_boot_arch = cfg->fadt_boot_arch; /* legacy free default */
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->res2 = 0; /* reserved, MUST be 0 ACPI 3.0 */
soc/amd/picasso: use FADT devicetree configuration options Two of the items in the FADT ACPI table frequently are partially board- specific, so let's make it easy to update them via devicetree settings. - fadt_boot_arch 0="legacy free" which while reasonable, probably isn't what will be wanted by most mainboards, so this should generally get updated in the specific devicetree. - In fadt_flags all chipset-specific flags get set while the mainboard has to set all other flags that it needs to have set. This patch changes the default for fadt_boot_arch. Change-Id: I6e8d0c60cadfdd24b6926703b252abbc56d436de Signed-off-by: Martin Roth <martinroth@chromium.org> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43418 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-12-02 00:49:19 +01:00
fadt->flags |= ACPI_FADT_WBINVD | /* See table 5-34 ACPI 6.3 spec */
ACPI_FADT_C1_SUPPORTED |
ACPI_FADT_S4_RTC_WAKE |
ACPI_FADT_32BIT_TIMER |
ACPI_FADT_PCI_EXPRESS_WAKE |
ACPI_FADT_PLATFORM_CLOCK |
ACPI_FADT_S4_RTC_VALID |
ACPI_FADT_REMOTE_POWER_ON;
fadt->flags |= cfg->fadt_flags; /* additional board-specific flags */
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
[acpi]{include,soc/amd,southbridge/amd}: Clarify ARM_boot_arch in comments 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-16 14:42:19 +01:00
fadt->ARM_boot_arch = 0; /* Must be zero if ACPI Revision <= 5.0 */
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->x_firmware_ctl_l = 0; /* set to 0 if firmware_ctrl is used */
fadt->x_firmware_ctl_h = 0;
fadt->x_pm1a_evt_blk.space_id = ACPI_ADDRESS_SPACE_IO;
fadt->x_pm1a_evt_blk.bit_width = 32;
fadt->x_pm1a_evt_blk.bit_offset = 0;
fadt->x_pm1a_evt_blk.access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
fadt->x_pm1a_evt_blk.addrl = ACPI_PM_EVT_BLK;
fadt->x_pm1a_evt_blk.addrh = 0x0;
fadt->x_pm1a_cnt_blk.space_id = ACPI_ADDRESS_SPACE_IO;
fadt->x_pm1a_cnt_blk.bit_width = 16;
fadt->x_pm1a_cnt_blk.bit_offset = 0;
acpi: Bump FADT to revision 6 Some of the revision 4 FADT fields were already updated to ACPI spec revision 6, but not all of them. In addition the advertised FADT revision was 3. Implement all fields as defined in version 6 and bump the advertised FADT revision to 6. Also set all used access_size fields and x_gpe0_blk to sane values as Windows 10 verifies those fields starting with FADT revision 5. Fixes: https://ticket.coreboot.org/issues/109 Tested on Windows 10. Change-Id: Ic649040025cd09ed3e490a521439ca4e681afbbf Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39805 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2020-02-28 10:19:41 +01:00
fadt->x_pm1a_cnt_blk.access_size = ACPI_ACCESS_SIZE_WORD_ACCESS;
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->x_pm1a_cnt_blk.addrl = ACPI_PM1_CNT_BLK;
fadt->x_pm1a_cnt_blk.addrh = 0x0;
fadt->x_pm_tmr_blk.space_id = ACPI_ADDRESS_SPACE_IO;
fadt->x_pm_tmr_blk.bit_width = 32;
fadt->x_pm_tmr_blk.bit_offset = 0;
fadt->x_pm_tmr_blk.access_size = ACPI_ACCESS_SIZE_DWORD_ACCESS;
fadt->x_pm_tmr_blk.addrl = ACPI_PM_TMR_BLK;
fadt->x_pm_tmr_blk.addrh = 0x0;
fadt->x_gpe0_blk.space_id = ACPI_ADDRESS_SPACE_IO;
fadt->x_gpe0_blk.bit_width = 64; /* EventStatus + Event Enable */
fadt->x_gpe0_blk.bit_offset = 0;
src: Report byte-sized access for GPE0 According to the ACPI specification, version 6.3: OSPM accesses GPE registers through byte accesses (regardless of their length). So, reporting dword-sized access is wrong and means nothing anyway. Tested on Asus P8Z77-V LX2, Windows 10 still boots. Change-Id: I965131a28f1a385d065c95f286549665c3f9693e Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42671 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-21 20:47:54 +02:00
fadt->x_gpe0_blk.access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS;
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
fadt->x_gpe0_blk.addrl = ACPI_GPE0_BLK;
fadt->x_gpe0_blk.addrh = 0x0;
}
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
static uint32_t get_pstate_core_freq(msr_t pstate_def)
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
{
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
uint32_t core_freq, core_freq_mul, core_freq_div;
bool valid_freq_divisor;
/* Core frequency multiplier */
core_freq_mul = pstate_def.lo & PSTATE_DEF_LO_FREQ_MUL_MASK;
/* Core frequency divisor ID */
core_freq_div =
(pstate_def.lo & PSTATE_DEF_LO_FREQ_DIV_MASK) >> PSTATE_DEF_LO_FREQ_DIV_SHIFT;
if (core_freq_div == 0) {
return 0;
} else if ((core_freq_div >= PSTATE_DEF_LO_FREQ_DIV_MIN)
&& (core_freq_div <= PSTATE_DEF_LO_EIGHTH_STEP_MAX)) {
/* Allow 1/8 integer steps for this range */
valid_freq_divisor = 1;
} else if ((core_freq_div > PSTATE_DEF_LO_EIGHTH_STEP_MAX)
&& (core_freq_div <= PSTATE_DEF_LO_FREQ_DIV_MAX) && !(core_freq_div & 0x1)) {
/* Only allow 1/4 integer steps for this range */
valid_freq_divisor = 1;
} else {
valid_freq_divisor = 0;
}
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
if (valid_freq_divisor) {
/* 25 * core_freq_mul / (core_freq_div / 8) */
core_freq =
((PSTATE_DEF_LO_CORE_FREQ_BASE * core_freq_mul * 8) / (core_freq_div));
} else {
printk(BIOS_WARNING, "Undefined core_freq_div %x used. Force to 1.\n",
core_freq_div);
core_freq = (PSTATE_DEF_LO_CORE_FREQ_BASE * core_freq_mul);
}
return core_freq;
}
static uint32_t get_pstate_core_power(msr_t pstate_def)
{
uint32_t voltage_in_uvolts, core_vid, current_value_amps, current_divisor, power_in_mw;
/* Core voltage ID */
core_vid =
(pstate_def.lo & PSTATE_DEF_LO_CORE_VID_MASK) >> PSTATE_DEF_LO_CORE_VID_SHIFT;
/* Current value in amps */
current_value_amps =
(pstate_def.lo & PSTATE_DEF_LO_CUR_VAL_MASK) >> PSTATE_DEF_LO_CUR_VAL_SHIFT;
/* Current divisor */
current_divisor =
(pstate_def.lo & PSTATE_DEF_LO_CUR_DIV_MASK) >> PSTATE_DEF_LO_CUR_DIV_SHIFT;
/* Voltage */
if ((core_vid >= 0xF8) && (core_vid <= 0xFF)) {
/* Voltage off for VID codes 0xF8 to 0xFF */
voltage_in_uvolts = 0;
} else {
voltage_in_uvolts =
SERIAL_VID_MAX_MICROVOLTS - (SERIAL_VID_DECODE_MICROVOLTS * core_vid);
}
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
/* Power in mW */
power_in_mw = (voltage_in_uvolts) / 1000 * current_value_amps;
switch (current_divisor) {
case 0:
break;
case 1:
power_in_mw = power_in_mw / 10L;
break;
case 2:
power_in_mw = power_in_mw / 100L;
break;
case 3:
/* current_divisor is set to an undefined value.*/
printk(BIOS_WARNING, "Undefined current_divisor set for enabled P-state .\n");
power_in_mw = 0;
break;
}
return power_in_mw;
}
/*
* Populate structure describing enabled p-states and return count of enabled p-states.
*/
static size_t get_pstate_info(struct acpi_sw_pstate *pstate_values,
struct acpi_xpss_sw_pstate *pstate_xpss_values)
{
msr_t pstate_def;
size_t pstate_count, pstate;
uint32_t pstate_enable, max_pstate;
pstate_count = 0;
max_pstate = (rdmsr(PS_LIM_REG).lo & PS_LIM_MAX_VAL_MASK) >> PS_MAX_VAL_SHFT;
for (pstate = 0; pstate <= max_pstate; pstate++) {
pstate_def = rdmsr(PSTATE_0_MSR + pstate);
pstate_enable = (pstate_def.hi & PSTATE_DEF_HI_ENABLE_MASK)
>> PSTATE_DEF_HI_ENABLE_SHIFT;
if (!pstate_enable)
continue;
pstate_values[pstate_count].core_freq = get_pstate_core_freq(pstate_def);
pstate_values[pstate_count].power = get_pstate_core_power(pstate_def);
pstate_values[pstate_count].transition_latency = 0;
pstate_values[pstate_count].bus_master_latency = 0;
pstate_values[pstate_count].control_value = pstate;
pstate_values[pstate_count].status_value = pstate;
pstate_xpss_values[pstate_count].core_freq =
(uint64_t)pstate_values[pstate_count].core_freq;
pstate_xpss_values[pstate_count].power =
(uint64_t)pstate_values[pstate_count].power;
pstate_xpss_values[pstate_count].transition_latency = 0;
pstate_xpss_values[pstate_count].bus_master_latency = 0;
pstate_xpss_values[pstate_count].control_value = (uint64_t)pstate;
pstate_xpss_values[pstate_count].status_value = (uint64_t)pstate;
pstate_count++;
}
return pstate_count;
}
void generate_cpu_entries(const struct device *device)
{
int logical_cores;
size_t pstate_count, cpu, proc_blk_len;
struct acpi_sw_pstate pstate_values[MAX_PSTATES] = { {0} };
struct acpi_xpss_sw_pstate pstate_xpss_values[MAX_PSTATES] = { {0} };
uint32_t threads_per_core, proc_blk_addr;
uint32_t cstate_base_address =
rdmsr(MSR_CSTATE_ADDRESS).lo & MSR_CSTATE_ADDRESS_MASK;
const acpi_addr_t perf_ctrl = {
.space_id = ACPI_ADDRESS_SPACE_FIXED,
.bit_width = 64,
.addrl = PS_CTL_REG,
};
const acpi_addr_t perf_sts = {
.space_id = ACPI_ADDRESS_SPACE_FIXED,
.bit_width = 64,
.addrl = PS_STS_REG,
};
acpi/acpigen: Constify CST functions' pointers The `acpigen_write_CST_package` and `acpigen_write_CST_package_entry` functions don't modify the provided C-state information. So, make the pointer parameters read-only to enforce this. Also constify arguments where possible. Change-Id: I9e18d82ee6c16e4435b8fad6d467e58c33194cf4 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58391 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-10-17 12:59:43 +02:00
const acpi_cstate_t cstate_info[] = {
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
[0] = {
.ctype = 1,
.latency = 1,
.power = 0,
.resource = {
.space_id = ACPI_ADDRESS_SPACE_FIXED,
.bit_width = 2,
.bit_offset = 2,
.addrl = 0,
.addrh = 0,
},
},
[1] = {
.ctype = 2,
.latency = 400,
.power = 0,
.resource = {
.space_id = ACPI_ADDRESS_SPACE_IO,
.bit_width = 8,
.bit_offset = 0,
.addrl = cstate_base_address + 1,
.addrh = 0,
.access_size = ACPI_ACCESS_SIZE_BYTE_ACCESS,
},
},
};
soc/amd/cezanne,picasso,sabrina: factor out get_threads_per_core This code is common to at least all Zen-based APUs (Picasso, Cezanne, Sabrina) and is also useful outside of the SoC-specific dynamic ACPI table generation code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie96d4429fb6ed9223efed9b3c754e04052d7ca7c Reviewed-on: https://review.coreboot.org/c/coreboot/+/61357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Rob Barnes <robbarnes@google.com> Reviewed-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Reviewed-by: Eric Peers <epeers@google.com>
2022-01-25 04:14:05 +01:00
threads_per_core = get_threads_per_core();
soc/amd/picasso: Generate ACPI pstate and cstate objects in cb Add code to generate p-state and c-state SSDT objects to coreboot. Publish objects generated in native coreboot, rather than the ones created by FSP binary. BUG=b:155307433 TEST=Boot morphius to shell and extract and compare objects created in coreboot with tables generated by FSP. Confirm they are equivalent. BRANCH=Zork Change-Id: I5f4db3c0c2048ea1d6c6ce55f5e252cb15598514 Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2020-09-14 14:22:47 +02:00
pstate_count = get_pstate_info(pstate_values, pstate_xpss_values);
logical_cores = get_cpu_count();
for (cpu = 0; cpu < logical_cores; cpu++) {
if (cpu == 0) {
/* BSP values for \_SB.Pxxx */
proc_blk_len = 6;
proc_blk_addr = ACPI_GPE0_BLK;
} else {
/* AP values for \_SB.Pxxx */
proc_blk_addr = 0;
proc_blk_len = 0;
}
acpigen_write_processor(cpu, proc_blk_addr, proc_blk_len);
acpigen_write_pct_package(&perf_ctrl, &perf_sts);
acpigen_write_pss_object(pstate_values, pstate_count);
acpigen_write_xpss_object(pstate_xpss_values, pstate_count);
if (CONFIG(ACPI_SSDT_PSD_INDEPENDENT))
acpigen_write_PSD_package(cpu / threads_per_core, threads_per_core,
HW_ALL);
else
acpigen_write_PSD_package(0, logical_cores, SW_ALL);
acpigen_write_PPC(0);
acpigen_write_CST_package(cstate_info, ARRAY_SIZE(cstate_info));
soc/amd/picasso/acpi: fix domain argument of acpigen_write_CSD_package Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I50e88ac946b9d8797571f9e3d4b325db760e423f Reviewed-on: https://review.coreboot.org/c/coreboot/+/51932 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-30 02:04:02 +02:00
acpigen_write_CSD_package(cpu / threads_per_core, threads_per_core,
CSD_HW_ALL, 0);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
acpigen_pop_len();
}
soc/amd: Drop PCNT from GNVS It's a static value that is neither referenced from SMI handler nor needs to be updated on S3 resume path. Change-Id: Iab2741242b0e2df8a0429ffaad270ce21882588c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50119 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2021-01-27 19:22:33 +01:00
soc/amd/picasso/acpi: generate PPKG object in generate_cpu_entries call 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 Picasso with Cezanne and Sabrina. 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=Mandolin still boots successfully to Linux desktop and dmesg doesn't show any any possibly related problems. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifb84435345c6d8c5d11a8b42e5538cfb86432780 Reviewed-on: https://review.coreboot.org/c/coreboot/+/62517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-03-02 15:00:59 +01:00
acpigen_write_processor_package("PPKG", 0, logical_cores);
soc/amd/picasso: Create picasso as a copy of stoneyridge So that everyone can see what's being updated from stoney, we're starting with a direct copy of the stoney directory. There are arguments both for and against doing it this way, but I believe This the most transparent way. We've moved much of the duplicated stoney code into the soc/amd/common directory and will continue that work as it becomes obvious that we have unchanged code between the SOCs. Makefile.inc has been renamed as makefile.inc so that it won't build in jenkins until the directory is updated. Other than that change, this is an exact copy of the stoneyridge SOC directory which will be updated in the follow-on commits in the patch train. TEST=None BUG=b:130804851 Signed-off-by: Martin Roth <martinroth@chromium.org> Change-Id: I6809bd1eea304f76dd9000c079b3ed09f94dbd3b Reviewed-on: https://review.coreboot.org/c/coreboot/+/32407 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-04-22 22:55:16 +02:00
}
Reference in a new issue Copy permalink