summaryrefslogtreecommitdiff
path: root/src/soc/amd/picasso
AgeCommit message (Collapse)Author
2023-09-21soc/amd/*/cpu: factor out common noncar mp_init_cpusFelix Held
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation, factor it out and move it to a common location. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-19soc/amd/picasso: add eMMC MMIO device to devicetreeFelix Held
Add the eMMC MMIO device to the devicetree and make it use the common AMD eMMC driver. Since there is now a device for this in the devicetree, also use this device to determine if the FSP should be told if the eMMC controller is supposed to be disabled. TEST=On Mandolin the eMMC controller both disappears in the Windows 10 device manager and in dmesg on Ubuntu 2022.04 LTS TEST=Morphius with NVMe SSD still works Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-18soc/amd: introduce SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGIONFelix Held
Add a separate Kconfig option for adding np_region.c to the build. Only the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call data_fabric_set_mmio_np which is implemented in that file, so only select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option for those. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-12soc/amd/*/Makefile: drop wrong EFS diagramsFelix Held
The EFS data structure diagrams in the Makefiles of Picasso and newer SoCs were wrong, since the BIOS directory table pointer is in a different location than shown in the diagram. Since the diagram also wasn't that easy to understand and amdfwtool does all of that handling, drop the wrong diagram from the Makefiles. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-09-06soc/amd: correctly report I2C controller state in ACPIFelix Held
Instead of reporting all I2C controllers in the system as enabled in the corresponding ACPI device's _STA method, report the I2C devices that are disabled in the devicetree as disabled in the corresponding _STA method too. This is done by returning the contents of the STAT variable inside each device's scope in the DSDT that have a default value of 0 (device not present/disabled). For all enabled and hidden I2C devices i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and visible) or 0xb (device enabled, but hidden) to the STAT name inside the same scope, but in the SSDT. This object in the SSDT will then override the default in the DSDT resulting in the _STA method returning the correct status of each device. The code was inspired by commit 7cf9c7451808 ("soc/amd/*: Fix UART ACPI device status"). TEST=On Mandolin all I2C controllers are disabled and with this patch none shows up in the Windows 10 device manager. When enabling an I2C controller in the devicetree for testing, it shows up again in the Windows device manager. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-09-01util/amdfwtool: Deal with psp position in flash offset directlyZheng Bao
It is based on work by Arthur Heymans, 69852. Get rid of the confusing "position index" and use the relative flash offset as the Kconfig setting instead. TEST=binary identical on amd/birman amd/majolica amd/gardenia amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon pcengines/apu2 google/skyrim google/guybrush google/zork google/kahlee google/myst (The test should be done with INCLUDE_CONFIG_FILE=n) Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-08-26soc/amd: Move psp_transfer.h out of each SOC into commonMartin Roth
The psp_transfer.h file was the same under all SoCs, and is really tied to the file common/vboot/transfer.c, not the SOC. This patch makes an include directory under vboot to put the header into and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes the header file available to all platforms, so that new chips that don't use the psp_verstage don't have to make a psp_transfer.h file just to satisfy the compiler. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-15soc/amd/*/root_complex: introduce get_iohc_fabric_idFelix Held
Implement get_iohc_fabric_id for each SoC that translates the coreboot domain number to the fabric ID of the corresponding PCI root. This allows the primary domain to have the number 0 even though the destination data fabric ID will be non-zero. Keeping the primary domain number 0 allows to use config_of_soc() which can be resolved at link time and not need to dynamically find the SoC device to get the config. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6538a777619eed974b449fc70d3fe3084ba447dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/77168 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-09treewide: Get rid of "NO_DDRx" selectionElyes Haouas
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-09soc/amd/picasso/include/data_fabric: add DF PCI config map registerFelix Held
PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide492f4479b85cd885044bbf74d8bf18c12e552b Reviewed-on: https://review.coreboot.org/c/coreboot/+/77075 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-09soc/amd/*: Fix UART ACPI device statusMatt DeVillier
Prior to commit d1c0f958d198 ("acpi: Call acpi_fill_ssdt() only for enabled devices"), uart_inject_ssdt() was used to set the ACPI status (_STA) for both enabled and disabled devices. The aforementioned commit limited it to being called only on enabled devices, which left disabled devices without any _STA method at all -- which the OS assumes means that the device is present and enabled. To fix this, create the _STA method in the UART asl code for each port, and set the return value to a name variable (STAT) which defaults to 0 (not present/disabled). Then, have uart_inject_ssdt() set STAT to present and enabled (0xF) for UARTs actually present on the board. TEST=build/boot google/skyrim (frostflow), dump ACPI tables, and verify that _STA returns 0xF only for UARTs enabled in devicetree. Change-Id: Id89e74c3ea7f53280935898ee35311b7cf3b152a Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77092 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-08soc/amd/picasso/include/data_fabric: add data fabric IO decode registersFelix Held
PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I61d4fca48d71010bbc4bd94a2fb8889bad08f1cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/76935 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-08soc/amd/*/include/data_fabric: add dst_ prefix to fabric_id fieldFelix Held
Rename the fabric_id struct field in the df_mmio_control union to dst_fabric_id to both better match the register definitions and also be a bit clearer about what this is doing. Also use tabs for indentation in the struct inside the df_mmio_control union. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0a17d82a5d7b66a8f84854f21fbbb319da81ac43 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76932 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-08soc/amd/*/include/data_fabric: reorder register definitionsFelix Held
Order the data fabric register definitions by function number and register offset. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia3066ad0f564520cb322a3e41a413eb3bf51260d Reviewed-on: https://review.coreboot.org/c/coreboot/+/76923 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-08soc/amd/*/include/data_fabric: rename D18F0_DRAM_* to DF_DRAM_*Felix Held
Now that the data fabric PCI device functions are included in the register definitions, the remaining data fabric device function numbers can be dropped from the define names. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1a26402b8078d288a7e32c1668591d001fa3ede9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76889 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-08soc/amd/*/include/data_fabric: rename D18F0_MMIO_* to DF_MMIO_*Felix Held
Now that the data fabric PCI device functions are included in the register definitions, the remaining data fabric device function numbers can be dropped from the define names. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia0355838ac1d513ba562fd6fb4672342dd383498 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76888 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-08soc/amd/common/include/data_fabric_defs: introduce & use DF_REG_* macrosFelix Held
To have both the PCI function number and the register offset into the config space of that function of the data fabric device in the data fabric register definitions, introduce and use the DF_REG_ID, DF_REG_FN and DF_REG_REG macros. The DF_REG_ID macro is used for register definitions where both the function number and the register offset are specified, and the DF_REG_FN and DF_REG_REG macros are used to extract the function number and the register offset from the register defines. This will allow having one define for accessing an indexed group of registers that are on different functions of the data fabric device. TEST=MMIO resources read from the data fabric's MMIO decode registers don't change on Mandolin and the ACPI CRAT table is also identical. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I63a284b26081c170a217b082b100c482f6158e7e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76886 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-05src/*/post_code.h: Change post code prefix to POSTCODEYuchen He
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. header="src/soc/amd/common/block/include/amdblocks/post_codes.h \ src/include/cpu/intel/post_codes.h \ src/soc/intel/common/block/include/intelblocks/post_codes.h" array=`grep -r "#define POST_" $header | \ tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2` for str in $array; do splitstr=`echo $str | cut -d '_' -f2-` grep -r $str src | cut -d ':' -f 1 | \ xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g" done Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad Signed-off-by: Yuchen He <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-27soc/amd/common/fsp: factor out read_fsp_resources from root_complex.cFelix Held
Factor out the common FSP-specific code to report the usable and reserved memory resources read from the HOBs that FSP has put into memory. This both reduces code duplication and also moves FSP-specific code out of the SoC code into the FSP-specific common AMD SoC code folder. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib373c52030209235559c9cd383f48ee1b3f8f79b Reviewed-on: https://review.coreboot.org/c/coreboot/+/76759 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-25soc/amd/*/root_complex: introduce and use SMN_IOHC_MISC_BASE_13B1Felix Held
On the mobile SoCs, SMN_IOHC_MISC_BASE_13B1 is the only IOHC misc base address, but on for example Genoa it's the address of the IOHC misc base of the second IOHC. Due to it not being the first one on Genoa, use 13B1 as part of the name instead of using an index of 0 which would look odd in the Genoa case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1db28ec03a3ba1c2040d8a1500ae17aa9705f6e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76756 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/*/root_complex: don't report root complex IOAPIC resource twiceFelix Held
Since the per PCI root IOAPIC is now reported as domain MMIO resource and the IVRS code now again probes for the IOAPIC resource on the domain device, the IOAPIC resource doesn't need to be reported as resource of the northbridge PCI device any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8604bd321ec4239076b1be99dca095e47f8b75a7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76600 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-07-25soc/amd/picasso/root_complex: add non-PCI MMIO registersFelix Held
Add the SoC-specific non-PCI MMIO register list. PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If7bfcdd9b70b71fe6aedcab3694698967d48e18e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76554 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-24soc/amd/*/Makefile.inc: Do not add APOB NV entry when disabledFred Reitberger
Do not add type 0x63 entry to amdfw.rom when APOB_NV cache is disabled. BUG=b:290763369 TEST=boot birman multiple times with/without APOB_NV cache enabled Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Iefe6f56d7dbedd289680f25a5f372eaa12e967b6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76568 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-21vendorcode/amd/fsp/common: Refactor dmi_info.hKonrad Adamczyk
SoC family is able to provide SoC-specific information via amd/fsp/<soc_family>/soc_dmi_info.h. Use common amd/fsp/common/dmi_info.h for all AMD platforms. This way, duplicated dmi_info.h files in vendorcode/amd/fsp/<soc_family>/ can be removed. BUG=b:288520486 TEST=Dump `dmidecode -t 17`. Change-Id: I5e0109af51b78360f7038b20a2975aceb721a7d5 Signed-off-by: Konrad Adamczyk <konrada@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76107 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-18soc/amd/*/root_complex.c: Use newer function for resource declarationsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: If2048c9cade731b2e4464d0670e0578f5f4bcea0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-07-17soc/amd/common/acpimmio: factor out IO port access to PM registersFelix Held
Factor out all functions that use the indirect IO port based access to the PM registers into a new compilation unit and only select it on platforms that support this interface. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9c059e450e2137f7e05441ab89c1f0e7077be9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/76458 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-07soc/amd/*/globalnvs,nvs: remove deprecated & unused CBMC field from GNVSFelix Held
Commit cde4f3b2790d ("acpi/gnvs.c: Drop unused pointer to the cbmem console") removed writing the coreboot memory console pointer to the GNVS and kept the CBMC field as reserved. Since those fields aren't needed any more and there are no dependencies on the absolute position of the different fields in GNVS as long as both GNVS definitions on the C and the ASL side match, remove the deprecated and unused CBMC field from the GNVS structs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iadfaf5a4ec1401b027dbfb6a7c6ce74a1dcecdfa Reviewed-on: https://review.coreboot.org/c/coreboot/+/76351 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-07-07soc/amd/*/Makefile.inc: Use _tohex instead of printfFred Reitberger
Use the _tohex function to convert values to hex instead of 'shell printf' TEST=timeless builds identical for grunt,dalboz,guybrush,chausie,birman Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ic7f7d1b764479088cc0980b208d8d603bc712832 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76314 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-06acpi/gnvs.c: Drop unused pointer to the cbmem consoleArthur Heymans
Change-Id: I7e2018dbccead15fcd84e34df8207120d3a0c57c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64303 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
2023-07-03soc/amd/*: Utilize get_fmap_value() Makefile function where possibleMatt DeVillier
Replace: $(shell awk '$$2 == "xyz" {print $$3}' $(obj)/fmap_config.h) with: $(call get_fmap_value,xyz) to improve code readability/maintainability. Change-Id: If6859108c7d5611a63fc38909dc75195bfb1d59a Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76168 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-19soc/amd/*: Use proper resource function to declare GNB IOAPICsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I296697d579b9ad8e35b22ada939a74a5ef6d6f61 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75828 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-15soc/amd/*/root_complex: reserve IOMMU MMIO areaFelix Held
This makes sure that the resource allocator won't use this address range for anything else. In the systems I looked at, this was between the end of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO region, but better reserve it here so nothing else will get allocated there if this expectation isn't met. TEST=Reserved region is printed in the console logs: update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-14soc/amd/acpi/ivrs: Use specific IOMMU resource index on all SOCArthur Heymans
By adding all DXIO IOAPIC with the same resource index, the IVRS code can always pick that resource which simplifies the code. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I10345e2337dcb709c2c1a8e57a1b7dd9c04adb9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
2023-06-09soc/amd: add ops xhci_pci_ops to XHCI controllers in devicetreeFelix Held
Instead of adding the new PCI IDs of the XHCI controllers in every new chip generation to the pci_xhci driver, bind the driver to the internal PCI devices of the XHCI controllers via the device ops statement in the chipset devicetree. The PCI device function of the XHCI2 controller in Mendocino can be either a dummy device or the XHCI controller, so the device ops are attached to that device in the mainboard devicetree instead. The Glinda code is right now just a copy of the Mendocino code, so it'll change in the future, but for consistency the equivalent changes to those in Mendocino are applied there too. Since the device ops are now attached to the devices via the static devicetree entry, also remove both the xhci_pci_driver struct and the amd_pci_device_ids array from drivers/usb/pci_xhci/pci_xhci.c. TEST=SSDT entries for the XHCI controllers are still generated on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9c455002c6d2aac576fe24eee0c31744b4507bb0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75713 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-06-08soc/amd/picasso/acpi/northbridge: drop _STA method from PCI0 scopeFelix Held
The PCI root complex itself isn't on an enumerable bus, so without providing an _STA method, the device will still be assumed to be present and visible, so this won't change behavior. This also brings Picasso more in line with Cezanne and newer SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Nico Huber <nico.h@gmx.de> Change-Id: Ied48b48113f6e871e90d17cbd216be003f05b5ef Reviewed-on: https://review.coreboot.org/c/coreboot/+/74993 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-07soc/amd/*/root_complex: use VGA_MMIO_* definesFelix Held
Replace the magic constants by using defines. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I16179a37b6ee19bc3b4862b7dcb3bbc4caf63f2e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75668 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-06-07soc/amd/picasso/acpi: rename sb_fch.asl to mmio.aslFelix Held
This file only contain the ACPI code describing the MMIO devices in the FCH, so rename it to mmio.asl. This also brings the Picasso ACPI code a bit more in line with the ACPI code of the newer SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I64490ba8e34ae1fbe6aea1ab6496b5b04ac4d0aa Reviewed-on: https://review.coreboot.org/c/coreboot/+/75591 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/picasso/acpi: move remaining parts of sb_pic0_fch.asl to soc.aslFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I785abfc90c99b58c11d57847573f550fcea1f774 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75590 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-06-07soc/amd/picasso/acpi: use ROOT_BRIDGE macroFelix Held
Instead of having the different static parts of the PCI0 device in northbridge.asl and sb_pci0_fch.asl, instantiate the static parts of the PCI0 device via the ROOT_BRIDGE macro in soc.asl. TEST=Both Ubuntu 2022.4 and Windows 10 still boot successfully and don't show any new ACPI-related error. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2587d8bb270dc3edce9dfa570a5018116fc9187f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75569 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-06-07soc/amd/common/data_fabric/domain: write _BBN method in SSDTFelix Held
Instead of having PCI0's _BBN method in the DSDT that always returns 0, use acpigen_write_BBN to generate the _BBN method that returns the first PCI bus number in the PCI domain/host bridge. TEST=On mandolin the _BBN method in the _SB/PCI0 scope is now in the SSDT instead of the DSDT, but still returns 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8badeb0064b498d3f18217ea24bff73676913b02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74992 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/picasso/chip: use common data fabric domain resource codeFelix Held
Use amd_pci_domain_read_resources function that gets the configured MMIO regions for the PCI root domain from the data fabric's MMIO decode registers instead of using pci_domain_read_resources. This results in the same IO port range being used by the allocator, but makes sure that the allocator will only allocate non-fixed MMIO resources in the address ranges that get decoded to the PCI root complex. In order for the PCI0 _CRS ACPI resource template to match the decoded PCI root domain MMIO windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code instead of having a mostly hard-coded _CRS method in the DSDT. This makes sure that the OS will know about the MMIO regions it is allowed to used. Before this patch, only the region from TOM1 to right below CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the PCI0 _CRS method. Also the resource allocator didn't get any constraint on which address ranges it can use to put the non-fixed MMIO resources. This approach worked until now, since all address range from 0 up to right below TOM1 was filled with either usable or reserved memory and the allocator was allocating beginning right from TOM1, since it was using the bottom-up allocation approach and everything below TOM1 was already in use. The MMIO region from TOM1 to right below CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window configured in the data fabric's MMIO decode registers, so everything seemed to work fine. However, when either selecting RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke badly. This was partially due to the allocator putting non-fixed MMIO resources in regions that weren't decoded to the PCI root, since AMD family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the wrong ranges the allocator used also weren't advertised in ACPI. TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends up with a non-working system when the MMIO ranges aren't reported correctly to the resource allocator due to the reasons descried above, Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2 payload and Windows 10 boots with EDK payload. There's however an EDK2 bug that results the MMCONFIG region not being advertised in the e820 table, which causes Linux to not use the MMCONFIG and fall back to the legacy PCI config access method. This only happens with EDK2 payload and everything works fine when using SeaBIOS as payload. That e820 issue is unaffected by this patch. At the end of the data_fabric_set_mmio_np call, this is the data fabric MMIO register configuration: === Data Fabric MMIO configuration registers === idx base limit control R W NP F-ID 0 fc000000 febfffff 93 x x 9 1 10000000000 ffffffffffff 93 x x 9 2 d0000000 f7ffffff 93 x x 9 3 fed00000 fedfffff 1093 x x x 9 4 0 ffff 90 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 The limit of the data fabric MMIO decode register 1 is configured as 0xffffffffffff although this is way beyond the addressable memory space. add_data_fabric_mmio_regions fixes this up, so the range that gets passed to the allocator in that case is 0x7fcffffffff which takes both the reserved most significant address bits used for the memory encryption and the 12GB reserved data fabric MMIO at the top of the usable address space into account. This results in the following domain ranges passed to the resource allocator: DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff The IO resource producer region is split into two parts to not cover the PCI config IO region resource consumer. This results in these resources being added to the PCI0 _CRS resource template: amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0' PCI0 _CRS: adding busses [0-3f] PCI0 _CRS: adding IO range [0-cf7] PCI0 _CRS: adding IO range [d00-ffff] PCI0 _CRS: adding MMIO range [fc000000-febfffff] PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff] PCI0 _CRS: adding MMIO range [d0000000-f7ffffff] PCI0 _CRS: adding VGA resource Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [bus 00-3f] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window] pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window] pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window] Another noteworthy thing I wasn't aware of at first when testing ACPI changes on Windows 10 is that a normal Windows shutdown and boot cycle won't result in it processing the changed ACPI tables; you have to tell it to reboot to do a proper full boot where it will process the updated ACPI tables (and fail if it dislikes something about the ACPI tables and bytecode). Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-06soc/amd/*/root_complex: reserve PCI config IO portsFelix Held
This makes sure that the resource allocator won't use those ports for anything else. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie42260902ee2b383dd5867ac813cae029f706f2d Reviewed-on: https://review.coreboot.org/c/coreboot/+/75556 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-06-02soc/amd/common/block/cpu: Refactor ucode allocationGrzegorz Bernacki
Move microcode load/unload to pre_mp_init and post_mp_init callbacks. It allows to make sure that ucode is freed only if all APs updated microcode. BUG=b:278264488 TEST=Build and run with additional debug prints added to confirm that data are correctly unmapped Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-05-31soc/amd/picasso/acpi/sb_pci0_fch: replace Memory32Fixed with DWordMemoryFelix Held
This brings the ACPI code more in line with both what the new code for the AMD SoCs will do and also what the current Intel code does. This was mainly done to have a reduced delta to the new AMD domain resource handling functions to debug it, but it might still be useful to upstream this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-05-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide MISC deviceFelix Held
Don't set bit 2 of the return value of the _STA method in order for Windows not to show a warning about an unknown device in the device manager for this device. TEST=The unknown device with device instance path ACPI\AMD0040\3 disappeared from the device manager in Windows 10 build 19045 on a Mandolin board with a Picasso APU. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If005f06843956004c281fd70cf364171148cb9ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: change AAHB's _STA back to methodFelix Held
Commit 396fb3db74db ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB device") didn't only change the visibility of the device, but also changed the _STA method to a name. While this worked, the specification says that _STA is supposed to be a method, so change it back to being a method. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-08soc/amd/*/acpi/northbridge,pci0: don't hide PCI0 root device from OSFelix Held
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates that the device should be shown in the user interface. This ports commit c259d7192806 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS") forward from Stoneyridge to the newer AMD SoCs. TEST=On Mandolin the PCI Express Root Complex now shows up in the device manager on Windows 10 and when switching the view to 'devices by connection', all PCI(e) devices are shown below it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-29sb,soc/amd,intel: Drop include <cpu/x86/smm.h>Kyösti Mälkki
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT entries for SMI architectural"). Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-29ACPI: Make FADT entries for RTC/CMOS architecturalKyösti Mälkki
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY that points to same offset. Since the century field inside RTC falls within the NVRAM space, and could interfere with OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY. There were no reference for the use of offset 0x48 for century. Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-27ACPI: Make FADT entries for SMI architecturalKyösti Mälkki
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-27soc/amd: Drop acpi_fill_madt_irqoverride()Kyösti Mälkki
It is unused. The use of field irq is problematic as it should appear relative to IOAPIC GSI bases in the devicetree. Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-26soc/amd: Use ACPI_COMMON_MADT_IOAPICKyösti Mälkki
Change IRQ #0 to GSI #2 override to positive edge trigger from the bus ISA default (positive edge). Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-26arch/x86/ioapic: Promote ioapic_get_sci_pin()Kyösti Mälkki
Platform needs to implement this to provide information about SCI IRQ pin and polarity, to be used for filling in ACPI FADT and MADT entries. Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-21Drop unused include <version.h>Kyösti Mälkki
Change-Id: I7d0718b5d2e0dd16eb90f63dd9d33329a2d808ba Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74448 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-21ACPI: Obsolete FADT p_lvl2_lat and p_lvl3_lat fieldsKyösti Mälkki
After the obsoletion of Processor() it is necessary to provide _CST package to define P_LVLx IO addresses for C2/C3 transitions. The latency values from _CST will always replace those in FADT. Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-15sb,soc/amd,intel: Add and use ACPI_COMMON_MADT_LAPICKyösti Mälkki
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have special handling for the time being. Change of aopen/dxplplusu is coupled with sb/intel/i82801dx. Change of emulation/qemu-i440fx is coupled with intel/i82371eb. For asus/p2b, this adds MADT LAPIC entries, even though platform has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates the MADT, including an entry for LAPIC address. Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-04soc/amd/*/Makefile: use all_x86 targetFelix Held
Use the newly introduced 'all_x86' make target to add the compilation unit to all stages that run on the x86 cores, but not to verstage on PSP. TEST=Timeless builds for Mandolin without verstage on PSP and Guybrush with verstage on PSP result in identical images with and without this patch applied. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I94de6de5a4c7723065a4eb1b7149f9933ef134a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74151 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: Arthur Heymans <arthur@aheymans.xyz>
2023-04-03soc/amd/cezanne,glinda,mendocino,phoenix,picasso/Kconfig: use all targetFelix Held
The i2c.c compilation unit is added to all stages in all cases, so use the all target instead of adding it to all stages separately. Also order the all targets alphabetically. TEST=Timeless build on Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-31soc/amd/picasso/graphics: use RAVEN2_VBIOS_REV with RAVEN2_VBIOS_VID_DIDFelix Held
In order for the code to find the correct VBIOS file in CBFS, remap the revision ID in the RAVEN2_VBIOS_VID_DID case to the one that matches the CBFS file name. This will make the code work as expected on devices with the PCI ID RAVEN2_VBIOS_VID_DID and a revision != RAVEN2_VBIOS_REV. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I94412dc2e778e7c4f74e475cd49114a00a81b2ce Reviewed-on: https://review.coreboot.org/c/coreboot/+/74045 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-30soc/amd/picasso/graphics: refactor map_oprom_vendev_revFelix Held
Refactor map_oprom_vendev_rev as a preparation to also remap the revision ID in the RAVEN2_VBIOS_VID_DID case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3b81a9464ed49672889fcb767920154fe6efdfcc Reviewed-on: https://review.coreboot.org/c/coreboot/+/74044 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-03-29soc/amd/picasso/Kconfig: update help text for 2nd VBIOS ID detectionFelix Held
The help text for VGA_BIOS_SECOND_ID was outdated and from a time before we found out that just looking at the CPUID doesn't reliably tell us on which type of silicon we're running and which VBIOS file to pick, so we had to use a different method. Update the help text to match what the code does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia568771ed7dfa0c7bb850b0efcd2959d7ddfd4a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73335 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/block/cpu/Kconfig: drop FAM17H_19H suffix from TSC optionFelix Held
The SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option is valid for all SoCs with Zen-based CPU cores including the family 1Ah, so remove the suffix. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I58d29e69a44b7b97fa5cfeb0e461531b926f7480 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74015 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/cpu/tsc: factor out family-specific get_pstate_core_freqFelix Held
Factor out the get_pstate_core_freq function from the SoC's acpi.c files to both avoid duplication and to also be able to use the same function in the TSC frequency calculation in a follow-up patch. The family 17h and 19h SoCs use the same frequency encoding in the P state MSRs while the family 1Ah SoCs use a different encoding. The family 15h and 16h SoCs use another encoding, but since this isn't implemented in Stoneyridge's acpi.c, this will be added in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-27soc/amd: factor out common get_pstate_core_power implementationFelix Held
Now that all get_pstate_core_power implementations in each SoC's acpi.c file is identical, factor it out into a common implementation. This implementation will also work for Stoneyridge which isn't using the common P state code yet. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_pstate_core_uvolts for SVI2 and SVI3Felix Held
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage ID version specific function is needed to get the raw core VID value. This will allow making get_pstate_core_power common for all AMD CPUs in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_uvolts_from_vid for SVI2 and SVI3Felix Held
Instead of implementing the conversion from the raw serial voltage ID value to the voltage in microvolts in every SoC, introduce the SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the correct version, implement get_uvolts_from_vid for both cases and only include the selected implementation in the build. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I344641217e6e4654fd281d434b88e346e0482f57 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-24soc/amd/*/include/msr: add version number to SERIAL_VID_* define namesFelix Held
Picasso and Cezanne use the serial voltage ID 2 standard to communicate the CPU voltage to the voltage regulator module on the mainboard, while Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for this. Both standards encode the voltage in a different way, so add the serial VID version number to the defines to clarify for which version the define is. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-03-24soc/amd/*/include/msr: drop _LO part from PSTATE definition namesFelix Held
The _LO part in the definition names is a leftover from before moving to the pstate_msr union access to the bitfield elements where it still mattered if a bit was in the lower of higher half of the MSR. With the mask-and-shift access to the two parts of the MSR being gone, the _LO part in the name isn't useful any more and possibly a bit misleading, so drop that part. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib43c71e946388c944ecf40659d4c12ca02a27a5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73927 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-24soc/amd: pass pstate_msr union to get_pstate_core_[freq,power]Felix Held
Since we already have and use the pstate_msr union in get_pstate_info, also pass it directly to the get_pstate_core_freq and get_pstate_core_power function calls avoids having to sort-of convert the msr_t type parameter in the implementations of those two functions. In amdblocks/cpu.h a forward declaration of the pstate_msr union is used since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include amdblocks/cpu.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-22soc/amd/*/acpi: assign proper boolean values in get_pstate_core_freqFelix Held
Assign true/false instead of 1/0 to the valid_freq_divisor bool variable in get_pstate_core_freq. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I92d0eb029c55f80a2027ff6d404c63ed84282750 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-20soc/amd/picasso: introduce and use pstate_msr bitfield structFelix Held
Add the pstate_msr union of a bitfield struct and a raw uint64_t to allow easier access of the bitfields of the P state MSRs and use this bitfield struct in get_pstate_core_freq and get_pstate_core_power. The signature of those two function will be changed in a follow-up commit. TEST=The coreboot-generated SSDT containing the P state packages stays identical on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8dc293351f9941cfb8a9c84d9fb9a4fd76361d5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73643 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-15soc/amd: Print amdfwtool debug info if V=1Martin Roth
When doing coreboot builds, we can set V=1 to see all of the make info printed as the compile is happening. Use this flag to set the debug flag for amdfwtool so it doesn't have to be enabled separately. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-03-09soc/amd/common/cpu/Kconfig: use Cxxx as CPU string for all non-CAR SoCsFelix Held
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it being what the AGESA reference code uses. We initially relied on the AGESA/FSP generated SSDT for the P- and C-state support before we had a native implementation for this in coreboot. The Cxxx naming scheme can also be used for the other AMD SoCs except Stoneyridge which is pre-Zen and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of using Cxxx instead of CPxx is that the Cxxx scheme supports systems with more than 256 CPU threads. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-08soc/amd: factor out ACPI_SSDT_PSD_INDEPENDENT to common AMD ACPI KconfigFelix Held
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the Kconfig symbol to the Kconfig file in this directory. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/include/msr: factor out P state MSR enable bit to cpu/amd/msr.hFelix Held
The bit position of the P state enable bit in the 8 P state MSRs is identical for all AMD chips including the family 16h model 30h APU that lives outside of soc/amd. The other bits in those 8 MSRs are more or less family- and model-specific. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-08soc/amd/*/acpi: factor out common get_pstate_info implementationFelix Held
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. The SoC-specific get_pstate_core_freq and get_pstate_core_power functions remain in the SoC-specific code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/*/acpi: factor out common generate_cpu_entries implementationFelix Held
With the exception of the generate_cppc_entries call, the implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. Since all SoCs that support CPPC already select the SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only call generate_cppc_entries for platforms where it is available. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/picasso/acpi: rework C state info table handlingFelix Held
Rework the way the C state info is generated before it gets passed to acpigen_write_CST_package in generate_cpu_entries by separating the data from the code. For this, the newly introduced common get_cstate_info function is used. Separating the data from the code will eventually allow moving generate_cpu_entries to the common AMD code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd: rename ACPI_CPU_CONTROL to ACPI_CSTATE_CONTROL for non-CAR CPUsFelix Held
The legacy ACPI CPU control registers in IO space where the first 4 IO locations control the CPU throttling value don't exist any more on the Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS in set_cstate_io_addr which will cause accesses from the 8 IO addresses beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads from those IO addresses will cause the CPU to enter low C states. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/include/iomap: add comment about ACPI IO assignmentFelix Held
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO addresses from ACPI_CPU_CONTROL on for C state control. This is set up in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into MSR_CSTATE_ADDRESS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/include/southbridge: drop PM_CPU_CTRL defineFelix Held
Picasso and newer don't implement the P_CNT register to control the CPU duty cycle and also trap the C state control IO addresses directly in the CPU, so those won't reach the FCH. This register is unused in the Picasso code and not even defined any more in the Cezanne PPR. The Picasso PPR does define this register, but since it's useless and might even just be a leftover form a pre-Zen CPU generation, drop the define. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/*/acpi: drop unnecessary duty_offset/duty_width field writesFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the duty_offset and duty_width FADT field in acpi_fill_fadt for all SoC except Stoneyridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/acpi: don't announce unimplemented duty cycle controlFelix Held
Picasso neither has the corresponding P_CNT register implemented nor writes a _PTC ACPI object that would specify the P_CNT register. The Picasso UEFI reference code also sets the duty_width FADT entry to 0. This also aligns the Picasso code with the Cezanne code in this regard. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/*/acpi: drop unneeded mon_alrm FADT assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the mon_alrm FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iabb5fc7367f1e4e7acea1a58abdb643fc46ca776 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73418 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-28soc/amd: introduce and use PSTATE_MSR macroFelix Held
Instead of adding the P-state number to the PSTATE_0_MSR number to get the P-state MSR number for the rdmsr call, provide a macro that directly calculates the MSR number for a given power state. Also drop the unused PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs available in the hardware. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-02-28soc/amd/*/acpi: add comment about p_lvl[2,3]_lat FADT field usageFelix Held
The latency values in the _CST package override the values in the p_lvl2_lat and p_lvl3_lat FADT fields. In Picasso, Cezanne, Mendocino, Phoenix and Glinda generate_cpu_entries generates the _CST packages for each CPU device. The coreboot code for Stoneyridge doesn't generate _CST packages for the CPU objects, but those are provided via the PSTATE SSDT binaryPI generates and agesa_write_acpi_tables gets and adds to the ACPI tables. The AGESA reference code also sets those two FADT entries to the equivalents of ACPI_FADT_C2_NOT_SUPPORTED and ACPI_FADT_C3_NOT_SUPPORTED so this also matches the AGESA behavior. From the ACPI 6.4 spec: "Values provided by the _CST object override P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT." Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1116a3013576b18b6f521604d6b0a9d75b971e0b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-28soc/amd/picasso/acpi: use ACPI_SCI_IRQ definitionFelix Held
Since there's a define for the ACPI_SCI_IRQ 9, use the define instead of a magic number in the code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I23c8f62929f3f66192698e10826d10329ef3d8cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/73319 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/picasso,stoneyridge/acpi: drop unneeded res2 FADT assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the res2 FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifa69ae61bea82acf66e7210c4103ef48e36dbdd2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73318 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-22soc/amd/picasso,stoneyridge/acpi: drop x_firmware_ctl_[l,h] assignmentFelix Held
The coreboot-common acpi_create_fadt writes a pointer to the FACS table into both firmware_ctrl and x_firmware_ctl_l FADT fields and sets x_firmware_ctl_h to zero. When x_firmware_ctl_[l,h] is non-zero, the pointer in firmware_ctrl will be ignored, but that's what is already done on Cezanne and newer. TEST=Linux doesn't complain about any new ACPI problem on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib9eab4dcf828f28a60c6312ec96872aac4cfb266 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73190 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-22soc/amd/picasso,stoneyridge/acpi: drop unneeded ARM_boot_arch assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the ARM_boot_arch FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ica968db1228a2d63e83f2b6c4ea57c5f02bf1504 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73187 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-16soc/amd/picasso/Kconfig: update VGA_BIOS_ID's help textFelix Held
map_oprom_vendev_rev is implemented in graphics.c in the SoC directory. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0123cb8ff662445fd0a613711d9e1981272b1235 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73052 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-14amdfwtool: use SoC ID info instead of misleading comboable flagZheng Bao
Since it actually depends on the SoC type whether the old PSP directory table pointer or the new comboable PSP directory table pointer is used in EFS, get this information from the SoC ID instead of passing the comboable flag for the SoCs that need to use the new comboable PSP directory table pointer. TEST=Binary identical on amd/majolica, pcengines/apu2, amd/gardenia Change-Id: I0c3f21065939d1b13c2607aba16cbef74dd8d389 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73020 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-11soc/amd/*/Makefile.inc: remove command line soc-nameZheng Bao
The function has already moved to fw.cfg. 4/5 of split changes of https://review.coreboot.org/c/coreboot/+/58552/28 Change-Id: Idf9e491ed46ae574ccd17f24925e3e5c595039fa Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72467 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-11soc/amd/*: Add SOC_NAME in fw.cfg(s)Zheng Bao
2/5 of split changes of https://review.coreboot.org/c/coreboot/+/58552/28 Change-Id: I18f73462a3995038fe93750320dfc053fec969ba Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-09arch/x86/include/cpu: introduce CPU_TABLE_END CPU table terminatorFelix Held
Instead of having a magic entry in the CPU device ID table list to tell find_cpu_driver that it has reached the end of the list, introduce and use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID instead of the 0 in the CPU_TABLE_END definition. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-09soc/amd/picasso/soc_util.c: Remove unneeded "break"Elyes Haouas
"break" is useless after "return". Change-Id: I84bc506a3d50e937797f42659299bf90ce392e09 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72895 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2023-02-08soc/amd/picasso/soc_util: use cpuid_matchFelix Held
Now that there is a cpuid_match function, we can use it instead of doing basically the same thing manually. In the functions is_fam17_1x and is_fam17_2x both the stepping number and the lower nibble of the model number are masked out. To avoid having magic constants in the code, introduce the CPUID_ALL_STEPPINGS_AND_BASE_MODELS_MASK definition. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I758f9564c08c62c747cc4f93a8d6b540a1834a62 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72860 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/picasso: use CPUID_FROM_FMS macro instead of magic numbersFelix Held
TEST=Resulting image of timeless build for Mandolin doesn't change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I44cb7759206e9e1ce79fd57f62b9a844e52f7394 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72857 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/picasso/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry per family & model combination and not one per stepping. TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81) still finished mpinit and boots successfully even though now only PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as device match mask. When commenting out the line with PICASSO_B0_CPUID as a negative test, mpinit fails as expected. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-21 03:38:04 +0000