coreboot-gerrit April 2023

coreboot-gerrit@coreboot.org

1 participants
5761 discussions

[L] Change in coreboot[master]: util/inteltool: Add support for Jasper Lake
by Maciej Pijanowski (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Michał Żygowski, Jakub Czapiga, Karol Zmyslowski, Stefan Reinauer, Michal Zygowski. Maciej Pijanowski has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/73934 ) Change subject: util/inteltool: Add support for Jasper Lake ...................................................................... Patch Set 10: (15 comments) Patchset: PS10: Still not all of my comments were worked on in the patchset #10 File util/inteltool/gpio_names/jasperlake.h: https://review.coreboot.org/c/coreboot/+/73934/comment/c52aac35_d4e73834 PS9, Line 190: const char *const jasperlake_pch_community1_jtag_names[] = { > If you see at others, the naming convention is typically: "emmitsburg_group_jtag ", We can drop the […] Done https://review.coreboot.org/c/coreboot/+/73934/comment/5f382d0e_dc15895e PS9, Line 203: .display = "------- GPIO Group GPP_SYS_JTAG -------", > As far as I can see, others uarchs typically use: "------- GPIO Group JTAG -------" Done https://review.coreboot.org/c/coreboot/+/73934/comment/a59e8d12_5e29a4d9 PS9, Line 281: "GSPI2_CLK_LOOPBK", "GSPI2_CLK_LOOPBK", > This can probably be included in a group. See alderlake_p.h for example, as a reference. I still don't see this being changed https://review.coreboot.org/c/coreboot/+/73934/comment/f313f524_6527dd65 PS9, Line 292: const char *const jasperlake_pch_group_spi0_names[] = { > "jasperlake_pch_group_spi_names" should be enough Done https://review.coreboot.org/c/coreboot/+/73934/comment/13024391_2f699c41 PS9, Line 305: .display = "------- GPIO Group GPP_H -------", > This should be: "------- GPIO Group SPI -------" Done https://review.coreboot.org/c/coreboot/+/73934/comment/66398fac_cb7d7b8e PS9, Line 312: "GSPI0_CLK_LOOPBK", "GSPI0_CLK_LOOPBK", > Another instance that can probably be included in already existing group, and this group can be then […] Still not done https://review.coreboot.org/c/coreboot/+/73934/comment/43650ec9_02de7bda PS9, Line 359: const char *const jasperlake_pch_group_sys_comm2_names[] = { > This should be "jasperlake_pch_group_cpu_names". Consult alderlake_h.h as an example. Still not done https://review.coreboot.org/c/coreboot/+/73934/comment/22143970_ce9dcfb9 PS9, Line 378: .display = "------- GPIO Group GPP_SYS_COMM2 -------", > "------- GPIO Group CPU -------" Done https://review.coreboot.org/c/coreboot/+/73934/comment/cef8887e_6a475d62 PS9, Line 384: const char *const jasperlake_pch_group_sys_pcie_names[] = { > "jasperlake_pch_group_pcie_vgpio_names" fits probably better Done https://review.coreboot.org/c/coreboot/+/73934/comment/b8a6fe99_2f8892c1 PS9, Line 467: .display = "------- GPIO Group GPP_SYS_PCIE -------", > "------- GPIO Group PCIe vGPIO -------" Done https://review.coreboot.org/c/coreboot/+/73934/comment/f4bd0b18_104d9f0e PS9, Line 473: const char *const jasperlake_pch_group_sys_vusb_names[] = { > maybe "jasperlake_pch_group_vgpio_usb_names", or similar Done https://review.coreboot.org/c/coreboot/+/73934/comment/498fe06e_6f7239f0 PS9, Line 496: const char *const jasperlake_pch_group_dsw_names[] = { > This should be: "jasperlake_pch_group_gpd_names" Done https://review.coreboot.org/c/coreboot/+/73934/comment/81dd3996_e4269799 PS9, Line 510: const struct gpio_group jasperlake_pch_group_dsw = { > This should be: jasperlake_pch_group_gpd Done https://review.coreboot.org/c/coreboot/+/73934/comment/3d9f3fa4_0892a647 PS9, Line 511: .display = "------- GPIO Group GPP_S -------", > This should be: "------- GPIO Group GPD -------: Done -- To view, visit https://review.coreboot.org/c/coreboot/+/73934 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: If4134bd03f5544b5845cde998ee526e5ddd5b51d Gerrit-Change-Number: 73934 Gerrit-PatchSet: 10 Gerrit-Owner: Karol Zmyslowski Gerrit-Reviewer: Jakub Czapiga <jacz(a)semihalf.com> Gerrit-Reviewer: Maciej Pijanowski <maciej.pijanowski(a)3mdeb.com> Gerrit-Reviewer: Michal Zygowski <miczyg94(a)gmail.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Attention: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Attention: Jakub Czapiga <jacz(a)semihalf.com> Gerrit-Attention: Karol Zmyslowski Gerrit-Attention: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Michal Zygowski <miczyg94(a)gmail.com> Gerrit-Comment-Date: Wed, 05 Apr 2023 10:03:12 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Maciej Pijanowski <maciej.pijanowski(a)3mdeb.com> Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: nb/intel/gm45: Prevent null-deref in get_blc_pwm_freq_value()
by Jakub Czapiga (Code Review) 05 Apr '23

05 Apr '23

Jakub Czapiga has submitted this change. ( https://review.coreboot.org/c/coreboot/+/74179 ) Change subject: nb/intel/gm45: Prevent null-deref in get_blc_pwm_freq_value() ...................................................................... nb/intel/gm45: Prevent null-deref in get_blc_pwm_freq_value() IF its first call is get_blc_pwm_freq_value(NULL), null dereference will occur. Now when the parameter is NULL, it will return the value of the static blc_pwm_freq directly, so the original behavior is kept. Signed-off-by: Bill XIE <persmule(a)hardenedlinux.org> Change-Id: I32354aa0fe1a3ca725c2031f973ffad0bda81ad5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74179 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Arthur Heymans <arthur(a)aheymans.xyz> --- M src/northbridge/intel/gm45/gma.c 1 file changed, 21 insertions(+), 1 deletion(-) Approvals: build bot (Jenkins): Verified Arthur Heymans: Looks good to me, approved diff --git a/src/northbridge/intel/gm45/gma.c b/src/northbridge/intel/gm45/gma.c index 7df9106..8043822 100644 --- a/src/northbridge/intel/gm45/gma.c +++ b/src/northbridge/intel/gm45/gma.c @@ -67,7 +67,8 @@ int i; int blc_array_len; - if (blc_pwm_freq > 0) + /* Prevent null-deref on strcmp() below */ + if (blc_pwm_freq > 0 || !edid_ascii_string) return blc_pwm_freq; blc_array_len = get_blc_values(&blc_pwm); -- To view, visit https://review.coreboot.org/c/coreboot/+/74179 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I32354aa0fe1a3ca725c2031f973ffad0bda81ad5 Gerrit-Change-Number: 74179 Gerrit-PatchSet: 2 Gerrit-Owner: Bill XIE <persmule(a)hardenedlinux.org> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Jakub Czapiga <jacz(a)semihalf.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[S] Change in coreboot[master]: soc/intel/xeon_sp/spr: Drop devicetree setting X2apic
by Angel Pons (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Patrick Rudolph, Jonathan Zhang, Daocheng Bu, Johnny Lin, Ziang Wang, Christian Walter, Tim Chu. Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74185 ) Change subject: soc/intel/xeon_sp/spr: Drop devicetree setting X2apic ...................................................................... Patch Set 2: Code-Review+1 -- To view, visit https://review.coreboot.org/c/coreboot/+/74185 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I65152b0696a45b62a5629fd95801187354c7a93b Gerrit-Change-Number: 74185 Gerrit-PatchSet: 2 Gerrit-Owner: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: Daocheng Bu <daocheng.bu(a)intel.com> Gerrit-Reviewer: Johnny Lin <Johnny_Lin(a)wiwynn.com> Gerrit-Reviewer: Jonathan Zhang <jon.zhixiong.zhang(a)gmail.com> Gerrit-Reviewer: Tim Chu <Tim.Chu(a)quantatw.com> Gerrit-Reviewer: Ziang Wang <ziang.wang(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Attention: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Attention: Jonathan Zhang <jon.zhixiong.zhang(a)gmail.com> Gerrit-Attention: Daocheng Bu <daocheng.bu(a)intel.com> Gerrit-Attention: Johnny Lin <Johnny_Lin(a)wiwynn.com> Gerrit-Attention: Ziang Wang <ziang.wang(a)intel.com> Gerrit-Attention: Christian Walter <christian.walter(a)9elements.com> Gerrit-Attention: Tim Chu <Tim.Chu(a)quantatw.com> Gerrit-Comment-Date: Wed, 05 Apr 2023 10:01:50 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: util/spd_tools: Add support for Phoenix platform
by Jakub Czapiga (Code Review) 05 Apr '23

05 Apr '23

Jakub Czapiga has submitted this change. ( https://review.coreboot.org/c/coreboot/+/74125 ) Change subject: util/spd_tools: Add support for Phoenix platform ...................................................................... util/spd_tools: Add support for Phoenix platform Update spd_gen and part_id_gen utilities to accommodate Phoenix platform so that SPD can be generated for the memory parts used in that platform. SPD requirements for Phoenix and Mendocino platforms are identical. BUG=b:273383819 TEST=Run spd_gen and ensure that both Mendocino and Phoenix platforms share the platform manifest for LP5 memory parts. Change-Id: I7a12f73065864f08db8922c1a69eb503865a25b1 Signed-off-by: Karthikeyan Ramasubramanian <kramasub(a)google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74125 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Jon Murphy <jpmurphy(a)google.com> --- M spd/lp5/platforms_manifest.generated.txt M util/spd_tools/src/part_id_gen/part_id_gen.go M util/spd_tools/src/spd_gen/lp5.go M util/spd_tools/src/spd_gen/spd_gen.go 4 files changed, 26 insertions(+), 1 deletion(-) Approvals: build bot (Jenkins): Verified Jon Murphy: Looks good to me, approved diff --git a/spd/lp5/platforms_manifest.generated.txt b/spd/lp5/platforms_manifest.generated.txt index b971e66..a52acdc 100644 --- a/spd/lp5/platforms_manifest.generated.txt +++ b/spd/lp5/platforms_manifest.generated.txt @@ -3,4 +3,5 @@ MTL,set-0 ADL,set-0 +PHX,set-1 MDN,set-1 diff --git a/util/spd_tools/src/part_id_gen/part_id_gen.go b/util/spd_tools/src/part_id_gen/part_id_gen.go index 7a22f6c..699905d 100644 --- a/util/spd_tools/src/part_id_gen/part_id_gen.go +++ b/util/spd_tools/src/part_id_gen/part_id_gen.go @@ -42,6 +42,7 @@ "CZN", "MDN", "MTL", + "PHX", } var supportedMemTechs = [...]string{ diff --git a/util/spd_tools/src/spd_gen/lp5.go b/util/spd_tools/src/spd_gen/lp5.go index 3c6495c..65a7a57 100644 --- a/util/spd_tools/src/spd_gen/lp5.go +++ b/util/spd_tools/src/spd_gen/lp5.go @@ -177,7 +177,7 @@ var LP5PlatformSetMap = map[int][]int{ 0: {PlatformMTL, PlatformADL}, - 1: {PlatformMDN}, + 1: {PlatformPHX, PlatformMDN}, } var LP5SetInfo = map[int]LP5Set{ diff --git a/util/spd_tools/src/spd_gen/spd_gen.go b/util/spd_tools/src/spd_gen/spd_gen.go index d254905..9f9c6f5 100644 --- a/util/spd_tools/src/spd_gen/spd_gen.go +++ b/util/spd_tools/src/spd_gen/spd_gen.go @@ -74,6 +74,7 @@ PlatformCZN PlatformMDN PlatformMTL + PlatformPHX PlatformMax ) @@ -94,6 +95,7 @@ PlatformCZN: "CZN", PlatformMDN: "MDN", PlatformMTL: "MTL", + PlatformPHX: "PHX", } var memTechMap = map[string]memTech{ -- To view, visit https://review.coreboot.org/c/coreboot/+/74125 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I7a12f73065864f08db8922c1a69eb503865a25b1 Gerrit-Change-Number: 74125 Gerrit-PatchSet: 2 Gerrit-Owner: Karthik Ramasubramanian <kramasub(a)google.com> Gerrit-Reviewer: Jakub Czapiga <jacz(a)semihalf.com> Gerrit-Reviewer: Jon Murphy <jpmurphy(a)google.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Reka Norman <rekanorman(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[L] Change in coreboot[master]: soc/intel/cmn/cse: Handle EOP completion asynchronously
by Subrata Banik (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Tarun Tuli, Jérémy Compostella, Nick Vaccaro. Hello Tarun Tuli, Jérémy Compostella, Nick Vaccaro, Nick Vaccaro, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/74214 to look at the new patch set (#2). Change subject: soc/intel/cmn/cse: Handle EOP completion asynchronously ...................................................................... soc/intel/cmn/cse: Handle EOP completion asynchronously coreboot supports three instances of sending EOP: 1. At CSE `.final' device operation 2. Early as with Alder Lake in chip_operations.init if `SOC_INTEL_CSE_SEND_EOP_EARLY' is selected 3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if `SOC_INTEL_CSE_SEND_EOP_LATE' is selected Currently, Alder Lake uses #3 as it results in better and more stable boot time. However, what would deliver even better result is to not actively wait for CSE completion. This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig which split the action of sending EOP request and receiving EOP completion response from the CSE. This patch used in conjunction with #1 can significantly improves the overall boot time on a Raptor Lake design. For example `SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36 ms boot time improvement as illustrated below. | # | Late EOP | Async EOP | |----------+----------+-----------| | 1 | 1020.052 | 971.272 | | 2 | 1015.911 | 971.821 | | 3 | 1038.415 | 1021.841 | | 4 | 1020.657 | 993.751 | | 5 | 1065.128 | 1020.951 | | 6 | 1037.859 | 1023.326 | | 7 | 1042.010 | 984.412 | |----------+----------+-----------| | Mean | 1034.29 | 998.20 | | Variance | 4.76 % | 5.21 % | The improvement is not stable but comparing coreboot and FSP performance timestamps demonstrate that the slowness is caused by a lower memory frequency (SaGv point) at early boot which is not an issue addressed by this patch. We also observe some improvement on an Alder Lake design. For example, the same configuration on a kano board can deliver up to 10 ms boot time improvement as illustrated below. | # | Late EOP | Async EOP | |----------+----------+-----------| | 0 | 1067.719 | 1050.106 | | 1 | 1058.263 | 1056.836 | | 2 | 1064.091 | 1056.709 | | 3 | 1068.614 | 1055.042 | | 4 | 1065.749 | 1056.732 | | 5 | 1069.838 | 1057.846 | | 6 | 1066.897 | 1053.548 | | 7 | 1060.850 | 1051.911 | |----------+----------+-----------| | Mean | 1065.25 | 1054.84 | The improvement is more limited on kano because a longer PCIe initialization delays EOP in the Late EOP configuration which make it faster to complete. CSME team confirms that: 1. End-Of-Post is a blocking command in the sense that BIOS is requested to wait for the command completion before loading the OS or second stage bootloader. 2. The BIOS is not required to actively wait for completion of the command and can perform other operations in the meantime as long as they do not involve HECI commands. On Raptor Lake, coreboot does not send any HECI command after End-Of-Post. FSP-s code review did not reveal any HECI command being sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or `END_OF_FIRMWARE' notifications. If any HECI send and receive command has been sent the extra code added in `cse_receive_eop()' should catch it. According to commit 387ec919d9f7 ("soc/intel/alderlake: Select SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first boot after flashing of a Marasov board for instance) request coreboot to perform a global request out of AFTER_PCI_ENUM notification. Global request relies on a HECI command. Even though, we tested that it does not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent potential a global reset command to "conflict" with the EOP command. Additionally, introduced new code logic to detect if CSE is at correct state for responding to the EOP cmd otherwise use the prescribed method to make the CSE function disable. The typical scenario is the ChromeOS recovery boot where CSE stays in RO partition and EOP cmd should be avoided in that case. ``` [DEBUG] BS: BS_PAYLOAD_LOAD exit times (exec / console): 0 / 14 ms [INFO ] HECI: coreboot in recovery mode; found CSE in expected SOFT TEMP DISABLE state, skipping EOP [INFO ] Disabling Heci using PMC IPC [WARN ] HECI: CSE device 16.0 is hidden [WARN ] HECI: CSE device 16.1 is disabled [WARN ] HECI: CSE device 16.2 is disabled [WARN ] HECI: CSE device 16.3 is disabled [WARN ] HECI: CSE device 16.4 is disabled [WARN ] HECI: CSE device 16.5 is disabled ``` BUG=b:276339544 BRANCH=firmware-brya-14505.B TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show End-Of-Post sent soon after FSP-s and EOP message receive at `BS_PAYLOAD_BOOT'. Verify robustness by injecting a `GET_BOOT_STATE' HECI command with or without `heci_reset'. The implementation always successfully completed the EOP before moving to the payload. As expected, the boot time benefit of the asynchronous solution was under some injection scenario undermined by this unexpected HECI command. Signed-off-by: Jeremy Compostella <jeremy.compostella(a)intel.com> Signed-off-by: Subrata Banik <subratabanik(a)google.com> Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a --- M src/soc/intel/common/block/cse/Kconfig M src/soc/intel/common/block/cse/cse.c M src/soc/intel/common/block/cse/cse_eop.c 3 files changed, 258 insertions(+), 45 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/74214/2 -- To view, visit https://review.coreboot.org/c/coreboot/+/74214 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a Gerrit-Change-Number: 74214 Gerrit-PatchSet: 2 Gerrit-Owner: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-MessageType: newpatchset

1 0

[S] Change in coreboot[master]: mb/google/brya: Enable asynchronous End-Of-Post
by Subrata Banik (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Tarun Tuli, Jérémy Compostella. Hello Jérémy Compostella, I'd like you to do a code review. Please visit https://review.coreboot.org/c/coreboot/+/74215 to review the following change. Change subject: mb/google/brya: Enable asynchronous End-Of-Post ...................................................................... mb/google/brya: Enable asynchronous End-Of-Post Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post right after PCI enumeration and handle the command response at `BS_PAYLOAD_BOOT'. With these settings we have observed a boot time reduction of about 20 to 30 ms on brya0. BUG=b:268546941 BRANCH=firmware-brya-14505.B TEST=Tests on brya0 with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show End-Of-Post after PCI initialization and EOP message received at `BS_PAYLOAD_BOOT'. Signed-off-by: Jeremy Compostella <jeremy.compostella(a)intel.com> Change-Id: Ib850330fbb9e84839eb1093db054332cbcb59b41 --- M src/mainboard/google/brya/Kconfig M src/soc/intel/alderlake/Kconfig 2 files changed, 25 insertions(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/15/74215/1 diff --git a/src/mainboard/google/brya/Kconfig b/src/mainboard/google/brya/Kconfig index 9ae944d..e588524 100644 --- a/src/mainboard/google/brya/Kconfig +++ b/src/mainboard/google/brya/Kconfig @@ -32,6 +32,7 @@ select PMC_IPC_ACPI_INTERFACE select SOC_INTEL_COMMON_BLOCK_PCIE_RTD3 select SOC_INTEL_CSE_LITE_SKU + select SOC_INTEL_CSE_SEND_EOP_ASYNC select SOC_INTEL_ENABLE_USB4_PCIE_RESOURCES if SOC_INTEL_ALDERLAKE_PCH_P select SOC_INTEL_COMMON_BASECODE_DEBUG_FEATURE select SOC_INTEL_CRASHLOG diff --git a/src/soc/intel/alderlake/Kconfig b/src/soc/intel/alderlake/Kconfig index 1bc84ce..2887439 100644 --- a/src/soc/intel/alderlake/Kconfig +++ b/src/soc/intel/alderlake/Kconfig @@ -122,7 +122,7 @@ select SOC_INTEL_COMMON_FSP_RESET select SOC_INTEL_COMMON_PCH_CLIENT select SOC_INTEL_COMMON_RESET - select SOC_INTEL_CSE_SEND_EOP_LATE + select SOC_INTEL_CSE_SEND_EOP_LATE if !BOARD_GOOGLE_BRYA_COMMON select SOC_INTEL_CSE_SET_EOP select SOC_INTEL_MEM_MAPPED_PM_CONFIGURATION select HAVE_INTEL_COMPLIANCE_TEST_MODE -- To view, visit https://review.coreboot.org/c/coreboot/+/74215 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ib850330fbb9e84839eb1093db054332cbcb59b41 Gerrit-Change-Number: 74215 Gerrit-PatchSet: 1 Gerrit-Owner: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-MessageType: newchange

1 0

[L] Change in coreboot[master]: soc/intel/cmn/cse: Handle EOP completion asynchronously
by Subrata Banik (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Jérémy Compostella. Hello Jérémy Compostella, I'd like you to do a code review. Please visit https://review.coreboot.org/c/coreboot/+/74214 to review the following change. Change subject: soc/intel/cmn/cse: Handle EOP completion asynchronously ...................................................................... soc/intel/cmn/cse: Handle EOP completion asynchronously coreboot supports three instances of sending EOP: 1. At CSE `.final' device operation 2. Early as with Alder Lake in chip_operations.init if `SOC_INTEL_CSE_SEND_EOP_EARLY' is selected 3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if `SOC_INTEL_CSE_SEND_EOP_LATE' is selected Currently, Alder Lake uses #3 as it results in better and more stable boot time. However, what would deliver even better result is to not actively wait for CSE completion. This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig which split the action of sending EOP request and receiving EOP completion response from the CSE. This patch used in conjunction with #1 can significantly improves the overall boot time on a Raptor Lake design. For example `SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36 ms boot time improvement as illustrated below. | # | Late EOP | Async EOP | |----------+----------+-----------| | 1 | 1020.052 | 971.272 | | 2 | 1015.911 | 971.821 | | 3 | 1038.415 | 1021.841 | | 4 | 1020.657 | 993.751 | | 5 | 1065.128 | 1020.951 | | 6 | 1037.859 | 1023.326 | | 7 | 1042.010 | 984.412 | |----------+----------+-----------| | Mean | 1034.29 | 998.20 | | Variance | 4.76 % | 5.21 % | The improvement is not stable but comparing coreboot and FSP performance timestamps demonstrate that the slowness is caused by a lower memory frequency (SaGv point) at early boot which is not an issue addressed by this patch. We also observe some improvement on an Alder Lake design. For example, the same configuration on a kano board can deliver up to 10 ms boot time improvement as illustrated below. | # | Late EOP | Async EOP | |----------+----------+-----------| | 0 | 1067.719 | 1050.106 | | 1 | 1058.263 | 1056.836 | | 2 | 1064.091 | 1056.709 | | 3 | 1068.614 | 1055.042 | | 4 | 1065.749 | 1056.732 | | 5 | 1069.838 | 1057.846 | | 6 | 1066.897 | 1053.548 | | 7 | 1060.850 | 1051.911 | |----------+----------+-----------| | Mean | 1065.25 | 1054.84 | The improvement is more limited on kano because a longer PCIe initialization delays EOP in the Late EOP configuration which make it faster to complete. CSME team confirms that: 1. End-Of-Post is a blocking command in the sense that BIOS is requested to wait for the command completion before loading the OS or second stage bootloader. 2. The BIOS is not required to actively wait for completion of the command and can perform other operations in the meantime as long as they do not involve HECI commands. On Raptor Lake, coreboot does not send any HECI command after End-Of-Post. FSP-s code review did not reveal any HECI command being sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or `END_OF_FIRMWARE' notifications. If any HECI send and receive command has been sent the extra code added in `cse_receive_eop()' should catch it. According to commit 387ec919d9f7 ("soc/intel/alderlake: Select SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first boot after flashing of a Marasov board for instance) request coreboot to perform a global request out of AFTER_PCI_ENUM notification. Global request relies on a HECI command. Even though, we tested that it does not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent potential a global reset command to "conflict" with the EOP command. Additionally, introduced new code logic to detect if CSE is at correct state for responding to the EOP cmd otherwise use the prescribed method to make the CSE function disable. The typical scenario is the ChromeOS recovery boot where CSE stays in RO partition and EOP cmd should be avoided in that case. BUG=b:276339544 BRANCH=firmware-brya-14505.B TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show End-Of-Post sent soon after FSP-s and EOP message receive at `BS_PAYLOAD_BOOT'. Verify robustness by injecting a `GET_BOOT_STATE' HECI command with or without `heci_reset'. The implementation always successfully completed the EOP before moving to the payload. As expected, the boot time benefit of the asynchronous solution was under some injection scenario undermined by this unexpected HECI command. Signed-off-by: Jeremy Compostella <jeremy.compostella(a)intel.com> Signed-off-by: Subrata Banik <subratabanik(a)google.com> Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a --- M src/soc/intel/common/block/cse/Kconfig M src/soc/intel/common/block/cse/cse.c M src/soc/intel/common/block/cse/cse_eop.c 3 files changed, 245 insertions(+), 45 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/74214/1 diff --git a/src/soc/intel/common/block/cse/Kconfig b/src/soc/intel/common/block/cse/Kconfig index f1f53d6..33d703f 100644 --- a/src/soc/intel/common/block/cse/Kconfig +++ b/src/soc/intel/common/block/cse/Kconfig @@ -67,6 +67,25 @@ Starting with Jasper Lake, coreboot sends EOP before loading payload hence, this config is applicable for those platforms. +config SOC_INTEL_CSE_SEND_EOP_ASYNC + bool + depends on SOC_INTEL_COMMON_BLOCK_CSE + depends on !SOC_INTEL_CSE_SEND_EOP_LATE + depends on !SOC_INTEL_CSE_SEND_EOP_EARLY + help + Use this config to handle End Of Post (EOP) completion + asynchronously. The EOP command is sent first and the result + is checked later leaving time to CSE to complete the + operation while coreboot perform other activities. + Performing EOP asynchronously reduces the time spent + actively waiting for command completion which can have a + significant impact on boot time. + + Using this asynchronous approach comes with the limitation + that no HECI command should be sent between the time the EOP + request is posted (at CSE .final device operation) and the + time coreboot check for its completion (BS_PAYLOAD_LOAD). + config SOC_INTEL_CSE_LITE_SKU bool default n diff --git a/src/soc/intel/common/block/cse/cse.c b/src/soc/intel/common/block/cse/cse.c index 9902094..6c4bb73 100644 --- a/src/soc/intel/common/block/cse/cse.c +++ b/src/soc/intel/common/block/cse/cse.c @@ -1407,7 +1407,8 @@ */ void cse_late_finalize(void) { - if (!CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE)) + if (!CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE) && + !CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC)) return; if (!CONFIG(USE_FSP_NOTIFY_PHASE_READY_TO_BOOT)) @@ -1431,6 +1432,14 @@ if (CONFIG(SOC_INTEL_CSE_SET_EOP)) cse_send_end_of_post(); + /* + * In asynchronous mode, the EOP command has most likely not been + * completed yet. Finalization steps will be run once the EOP command + * has successfully been completed. + */ + if (CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC)) + return; + if (!CONFIG(USE_FSP_NOTIFY_PHASE_READY_TO_BOOT)) cse_final_ready_to_boot(); diff --git a/src/soc/intel/common/block/cse/cse_eop.c b/src/soc/intel/common/block/cse/cse_eop.c index 53a4fa5..00d51f4 100644 --- a/src/soc/intel/common/block/cse/cse_eop.c +++ b/src/soc/intel/common/block/cse/cse_eop.c @@ -67,13 +67,54 @@ return CSE_CMD_RESULT_SUCCESS; } -static enum cse_cmd_result cse_send_eop(void) +static enum cse_cmd_result cse_receive_eop(void) { - enum cse_tx_rx_status ret; enum { EOP_REQUESTED_ACTION_CONTINUE = 0, EOP_REQUESTED_ACTION_GLOBAL_RESET = 1, }; + enum cse_tx_rx_status ret; + struct end_of_post_resp { + struct mkhi_hdr hdr; + uint32_t requested_actions; + } __packed resp = {}; + size_t resp_size = sizeof(resp); + + ret = heci_receive(&resp, &resp_size); + if (ret) + return decode_heci_send_receive_error(ret); + + if (resp.hdr.group_id != MKHI_GROUP_ID_GEN || + resp.hdr.command != MKHI_END_OF_POST) { + printk(BIOS_ERR, "HECI: EOP Unexpected response group or command.\n"); + if (CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC)) + printk(BIOS_ERR, "HECI: It could be a HECI command conflict.\n"); + return CSE_CMD_RESULT_ERROR; + } + + if (resp.hdr.result) { + printk(BIOS_ERR, "HECI: EOP Resp Failed: %u\n", resp.hdr.result); + return CSE_CMD_RESULT_ERROR; + } + + printk(BIOS_INFO, "CSE: EOP requested action: "); + + switch (resp.requested_actions) { + case EOP_REQUESTED_ACTION_GLOBAL_RESET: + printk(BIOS_INFO, "global reset\n"); + return CSE_CMD_RESULT_GLOBAL_RESET_REQUESTED; + case EOP_REQUESTED_ACTION_CONTINUE: + printk(BIOS_INFO, "continue boot\n"); + return CSE_CMD_RESULT_SUCCESS; + default: + printk(BIOS_INFO, "unknown %u\n", resp.requested_actions); + return CSE_CMD_RESULT_ERROR; + } +} + +static enum cse_cmd_result cse_send_eop(void) +{ + enum cse_tx_rx_status ret; struct end_of_post_msg { struct mkhi_hdr hdr; } __packed msg = { @@ -82,21 +123,6 @@ .command = MKHI_END_OF_POST, }, }; - struct end_of_post_resp { - struct mkhi_hdr hdr; - uint32_t requested_actions; - } __packed resp = {}; - size_t resp_size = sizeof(resp); - - /* For a CSE-Lite SKU, if the CSE is running RO FW and the board is - running vboot in recovery mode, the CSE is expected to be in SOFT - TEMP DISABLE state. */ - if (CONFIG(SOC_INTEL_CSE_LITE_SKU) && vboot_recovery_mode_enabled() && - cse_is_hfs1_com_soft_temp_disable()) { - printk(BIOS_INFO, "HECI: coreboot in recovery mode; found CSE in expected SOFT " - "TEMP DISABLE state, skipping EOP\n"); - return CSE_CMD_RESULT_SUCCESS; - } /* * Prerequisites: @@ -119,28 +145,22 @@ printk(BIOS_INFO, "HECI: Sending End-of-Post\n"); - ret = heci_send_receive(&msg, sizeof(msg), &resp, &resp_size, HECI_MKHI_ADDR); + ret = heci_send(&msg, sizeof(msg), BIOS_HOST_ADDR, HECI_MKHI_ADDR); if (ret) return decode_heci_send_receive_error(ret); - if (resp.hdr.result) { - printk(BIOS_ERR, "HECI: EOP Resp Failed: %u\n", resp.hdr.result); - return CSE_CMD_RESULT_ERROR; - } + return CSE_CMD_RESULT_SUCCESS; +} - printk(BIOS_INFO, "CSE: EOP requested action: "); +static enum cse_cmd_result cse_send_and_receive_eop(void) +{ + enum cse_cmd_result ret; - switch (resp.requested_actions) { - case EOP_REQUESTED_ACTION_GLOBAL_RESET: - printk(BIOS_INFO, "global reset\n"); - return CSE_CMD_RESULT_GLOBAL_RESET_REQUESTED; - case EOP_REQUESTED_ACTION_CONTINUE: - printk(BIOS_INFO, "continue boot\n"); - return CSE_CMD_RESULT_SUCCESS; - default: - printk(BIOS_INFO, "unknown %u\n", resp.requested_actions); - return CSE_CMD_RESULT_ERROR; - } + ret = cse_send_eop(); + if (ret != CSE_CMD_RESULT_SUCCESS) + return ret; + + return cse_receive_eop(); } static enum cse_cmd_result cse_send_cmd_retries(enum cse_cmd_result (*cse_send_command)(void)) @@ -199,11 +219,12 @@ } } -static void do_send_end_of_post(void) +static void do_send_end_of_post(bool wait_for_completion) { - static bool eop_sent = false; + static bool eop_sent = false, eop_complete = false; + enum cse_cmd_result ret; - if (eop_sent) { + if (eop_complete) { printk(BIOS_WARNING, "EOP already sent\n"); return; } @@ -222,26 +243,65 @@ return; } - set_cse_device_state(PCH_DEVFN_CSE, DEV_ACTIVE); + if (!eop_sent) { + set_cse_device_state(PCH_DEVFN_CSE, DEV_ACTIVE); + timestamp_add_now(TS_ME_END_OF_POST_START); + ret = cse_send_cmd_retries(cse_send_eop); + if (ret == CSE_CMD_RESULT_SUCCESS) + eop_sent = true; + } - timestamp_add_now(TS_ME_END_OF_POST_START); - handle_cse_eop_result(cse_send_cmd_retries(cse_send_eop)); + if (!wait_for_completion) + return; + + set_cse_device_state(PCH_DEVFN_CSE, DEV_ACTIVE); + ret = cse_receive_eop(); + if (ret != CSE_CMD_RESULT_SUCCESS) { + ret = cse_send_cmd_retries(cse_send_and_receive_eop); + handle_cse_eop_result(ret); + } timestamp_add_now(TS_ME_END_OF_POST_END); set_cse_device_state(PCH_DEVFN_CSE, DEV_IDLE); - eop_sent = true; + eop_complete = true; +} + +/* + * Don't send EOP if below conditions being met + * 1. "The platform is running CSE-Lite SKU" AND + * 2. 'The CSE is running the RO FW" AND + * 3. "The board is in recovery mode" + * + * The above conditions summarized that the CSE is in "SOFT TEMP DISABLE" state, + * hence, don't send the EOP command to CSE. + */ +static bool is_cse_eop_supported(void) +{ + if (CONFIG(SOC_INTEL_CSE_LITE_SKU) && vboot_recovery_mode_enabled() && + cse_is_hfs1_com_soft_temp_disable()) { + printk(BIOS_INFO, "HECI: coreboot in recovery mode; found CSE in expected SOFT " + "TEMP DISABLE state, skipping EOP\n"); + return false; + } + return true; } void cse_send_end_of_post(void) { - return do_send_end_of_post(); + if (!is_cse_eop_supported()) + return; + + return do_send_end_of_post(!CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC)); } static void send_cse_eop_with_late_finalize(void *unused) { - do_send_end_of_post(); - if (CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE)) + if (is_cse_eop_supported()) + do_send_end_of_post(true); + + if (CONFIG(SOC_INTEL_CSE_SEND_EOP_LATE) || + CONFIG(SOC_INTEL_CSE_SEND_EOP_ASYNC)) cse_late_finalize(); } -- To view, visit https://review.coreboot.org/c/coreboot/+/74214 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a Gerrit-Change-Number: 74214 Gerrit-PatchSet: 1 Gerrit-Owner: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Attention: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-MessageType: newchange

1 0

[M] Change in coreboot[master]: soc/intel/common: Order the different types of cores based on APIC IDs
by Sridhar Siricilla (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Subrata Banik, Paul Menzel, Kyösti Mälkki, Jan Samek, Elyes Haouas. Sridhar Siricilla has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/72132 ) Change subject: soc/intel/common: Order the different types of cores based on APIC IDs ...................................................................... Patch Set 18: (5 comments) Commit Message: https://review.coreboot.org/c/coreboot/+/72132/comment/0876e7c7_e31ee4f3 PS15, Line 24: Existing code presents mix of different cores to OS and causes CPU load : balancing and power/performance impact. > Please refer the patches for media dynamic cgroup: […] Ack Commit Message: https://review.coreboot.org/c/coreboot/+/72132/comment/949a7d6b_ee431acb PS17, Line 13: cat > Not the cat, please. Ack https://review.coreboot.org/c/coreboot/+/72132/comment/27e38820_841c8b05 PS17, Line 13: cpu$c > This variable is now undefined. Use glob (`cpu*`) instead. I missed to update the command output here as is. https://review.coreboot.org/c/coreboot/+/72132/comment/0b00da0d_a3ad12bb PS17, Line 14: 0-1 : 4 : 5 : 6 : 7 : 0-1 : 2-3 : 2-3 > This will now also look different if you run the command, e.g.: […] Ack https://review.coreboot.org/c/coreboot/+/72132/comment/4ad9de52_034f82e6 PS17, Line 37: grep . cat /sys/devices/system/cpu/cpu$c/topology/thread_siblings_list > ditto Ack -- To view, visit https://review.coreboot.org/c/coreboot/+/72132 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I21487a5eb0439ea0cb5976787d1769ee94777469 Gerrit-Change-Number: 72132 Gerrit-PatchSet: 18 Gerrit-Owner: Sridhar Siricilla <sridhar.siricilla(a)intel.com> Gerrit-Reviewer: Elyes Haouas <ehaouas(a)noos.fr> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Ronak Kanabar <ronak.kanabar(a)intel.com> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Sukumar Ghorai <sukumar.ghorai(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Jan Samek <jan.samek(a)siemens.com> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-Attention: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Attention: Jan Samek <jan.samek(a)siemens.com> Gerrit-Attention: Elyes Haouas <ehaouas(a)noos.fr> Gerrit-Comment-Date: Wed, 05 Apr 2023 09:25:46 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Paul Menzel <paulepanter(a)mailbox.org> Comment-In-Reply-To: Sridhar Siricilla <sridhar.siricilla(a)intel.com> Comment-In-Reply-To: Jan Samek <jan.samek(a)siemens.com> Gerrit-MessageType: comment

1 0

[M] Change in coreboot[master]: mb/google/rex: Add DTT thermal settings for policies
by Sumeet R Pawnikar (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Tarun Tuli, Subrata Banik, Ravishankar Sarawadi, Kapil Porwal, John Zhao, Ivy Jian, Eric Lai, Peter Ou. Sumeet R Pawnikar has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/71166 ) Change subject: mb/google/rex: Add DTT thermal settings for policies ...................................................................... Patch Set 6: (2 comments) Commit Message: https://review.coreboot.org/c/coreboot/+/71166/comment/db6dc31c_59d1c8a6 PS5, Line 13: =Built and tested on Rex board > wondering if u can add more specific test details to support this work? Done File src/mainboard/google/rex/variants/rex0/overridetree.cb: https://review.coreboot.org/c/coreboot/+/71166/comment/258222ee_dae41a4e PS5, Line 129: # TODO: below values are initial reference values only > can u please keep a bug open for tracking purpose and add here as `FIXME`? Yes, I'll keep this b:270664854 for tracking purpose. Updated FIXME tag here. -- To view, visit https://review.coreboot.org/c/coreboot/+/71166 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I00dd97b759c8c68edaeeb4d64422b83c5e86981d Gerrit-Change-Number: 71166 Gerrit-PatchSet: 6 Gerrit-Owner: Sumeet R Pawnikar <sumeet.r.pawnikar(a)intel.com> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Ivy Jian <ivy.jian(a)quanta.corp-partner.google.com> Gerrit-Reviewer: John Zhao <john.zhao(a)intel.com> Gerrit-Reviewer: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Reviewer: Peter Ou <peter.ou(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.corp-partner.google.com> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-Attention: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Attention: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Attention: John Zhao <john.zhao(a)intel.com> Gerrit-Attention: Ivy Jian <ivy.jian(a)quanta.corp-partner.google.com> Gerrit-Attention: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Attention: Peter Ou <peter.ou(a)quanta.corp-partner.google.com> Gerrit-Comment-Date: Wed, 05 Apr 2023 09:22:59 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Subrata Banik <subratabanik(a)google.com> Gerrit-MessageType: comment

1 0

[M] Change in coreboot[master]: mb/google/rex: Add DTT thermal settings for policies
by Sumeet R Pawnikar (Code Review) 05 Apr '23

05 Apr '23

Attention is currently required from: Tarun Tuli, Ravishankar Sarawadi, Kapil Porwal, John Zhao, Sumeet R Pawnikar, Ivy Jian, Eric Lai, Peter Ou. Hello build bot (Jenkins), Tarun Tuli, Subrata Banik, Ravishankar Sarawadi, John Zhao, Kapil Porwal, Ivy Jian, Eric Lai, Peter Ou, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/71166 to look at the new patch set (#6). Change subject: mb/google/rex: Add DTT thermal settings for policies ...................................................................... mb/google/rex: Add DTT thermal settings for policies Add DTT thermal settings for policies for rex0 board BRANCH=None BUG=b:262498724, b:270664854 TEST=Built and verified thermal entries in ACPI SSDT on Rex board Change-Id: I00dd97b759c8c68edaeeb4d64422b83c5e86981d Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar(a)intel.com> --- M src/mainboard/google/rex/variants/rex0/overridetree.cb 1 file changed, 136 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/66/71166/6 -- To view, visit https://review.coreboot.org/c/coreboot/+/71166 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I00dd97b759c8c68edaeeb4d64422b83c5e86981d Gerrit-Change-Number: 71166 Gerrit-PatchSet: 6 Gerrit-Owner: Sumeet R Pawnikar <sumeet.r.pawnikar(a)intel.com> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Ivy Jian <ivy.jian(a)quanta.corp-partner.google.com> Gerrit-Reviewer: John Zhao <john.zhao(a)intel.com> Gerrit-Reviewer: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Reviewer: Peter Ou <peter.ou(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.corp-partner.google.com> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Ravishankar Sarawadi <ravishankar.sarawadi(a)intel.com> Gerrit-Attention: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Attention: John Zhao <john.zhao(a)intel.com> Gerrit-Attention: Sumeet R Pawnikar <sumeet.r.pawnikar(a)intel.com> Gerrit-Attention: Ivy Jian <ivy.jian(a)quanta.corp-partner.google.com> Gerrit-Attention: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Attention: Peter Ou <peter.ou(a)quanta.corp-partner.google.com> Gerrit-MessageType: newpatchset

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit April 2023