coreboot-gerrit April 2023

coreboot-gerrit@coreboot.org

1 participants
5761 discussions

[L] Change in coreboot[master]: util/crossgcc: Update binutils from 2.37 to 2.40
by Felix Singer (Code Review) 18 Apr '23

18 Apr '23

Felix Singer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/66920 ) Change subject: util/crossgcc: Update binutils from 2.37 to 2.40 ...................................................................... Patch Set 27: (1 comment) Patchset: PS27: > Hi Felix, […] Hi Nick! Not a specific bug I am aware of. We are just frequently updating the toolchain components so that we stay not too much behind and updating doesn't end in pain. I know some distros even needed additional compiler flags to make the old toolchain compiling. Also, some people want to continue working on RISC-V. GCC 12 and binutils 2.38 introduce some major changes for that. For now, there is probably no urgent need to update your toolchain and you can keep using the one from coreboot 4.19. -- To view, visit https://review.coreboot.org/c/coreboot/+/66920 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I34a20a999f7ea624c1add4750fcd116166953dd8 Gerrit-Change-Number: 66920 Gerrit-PatchSet: 27 Gerrit-Owner: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Elyes Haouas <ehaouas(a)noos.fr> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: 9elements QA <hardwaretestrobot(a)gmail.com> Gerrit-CC: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Comment-Date: Mon, 17 Apr 2023 21:00:33 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: payloads: Add target to download depthcharge source
by Martin L Roth (Code Review) 17 Apr '23

17 Apr '23

Martin L Roth has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/74480 ) Change subject: payloads: Add target to download depthcharge source ...................................................................... payloads: Add target to download depthcharge source This lets the user manually download the source for a payload before running the full make. This can be used to apply patches against a specific version, or to download the payload for offline use later. This can also be used as a part of the build system to download the payloads for testing before the coreboot build is started (and can no longer access the internet). If the payload is currently specified as a part of the .config, the tag will be checked out after the source tree is fetched. Otherwise the source for depthcharge will be downloaded and no tag will be checked out. If this seems useful, I can add it to the rest of the payloads, and add a download-all-payloads target or something as well. Signed-off-by: Martin Roth <gaumless(a)gmail.com> Change-Id: I60bf04bbadccc1a0692958b17e2b66b7ad47a396 --- M payloads/external/Makefile.inc M payloads/external/depthcharge/Makefile 2 files changed, 39 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/80/74480/1 diff --git a/payloads/external/Makefile.inc b/payloads/external/Makefile.inc index effab43..1683dd2 100644 --- a/payloads/external/Makefile.inc +++ b/payloads/external/Makefile.inc @@ -141,6 +141,13 @@ endif # Depthcharge +download-depthcharge: + $(MAKE) -C payloads/external/depthcharge download_tag \ + MFLAGS= MAKEFLAGS= \ + DEPTHCHARGE_MASTER=$(CONFIG_DEPTHCHARGE_MASTER) \ + DEPTHCHARGE_STABLE=$(CONFIG_DEPTHCHARGE_STABLE) \ + DEPTHCHARGE_REVISION=$(CONFIG_DEPTHCHARGE_REVISION) \ + DEPTHCHARGE_REVISION_ID=$(CONFIG_DEPTHCHARGE_REVISION_ID) payloads/external/depthcharge/depthcharge/build/depthcharge.elf depthcharge: $(DOTCONFIG) $(CBFSTOOL) $(MAKE) -C payloads/external/depthcharge \ diff --git a/payloads/external/depthcharge/Makefile b/payloads/external/depthcharge/Makefile index 687e9f0..5dd10e2 100644 --- a/payloads/external/depthcharge/Makefile +++ b/payloads/external/depthcharge/Makefile @@ -62,6 +62,12 @@ touch $(project_dir)/.version_$(TAG-y) endif +download_tag: fetch +ifneq ($(TAG-y),) + $(MAKE) $(project_dir)/.version_$(TAG-y) +endif + @echo "$(project_name) downloaded." + $(libpayload_install_dir): $(project_dir) test -f $(libpayload_config) || \ (echo "Error: $(libpayload_config) is not present" && \ @@ -104,3 +110,4 @@ echo "$(project_git_repo) $(project_dir)" .PHONY: checkout config build clean distclean clone fetch print-repo-info +.PHONY: download_tag -- To view, visit https://review.coreboot.org/c/coreboot/+/74480 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I60bf04bbadccc1a0692958b17e2b66b7ad47a396 Gerrit-Change-Number: 74480 Gerrit-PatchSet: 1 Gerrit-Owner: Martin L Roth <gaumless(a)gmail.com> Gerrit-MessageType: newchange

1 0

[L] Change in coreboot[master]: [RFC] drivers/option: Add option list in cbtable
by Angel Pons (Code Review) 17 Apr '23

17 Apr '23

Attention is currently required from: Benjamin Doron, Maximilian Brune. Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74121 ) Change subject: [RFC] drivers/option: Add option list in cbtable ...................................................................... Patch Set 1: (7 comments) File src/commonlib/include/commonlib/coreboot_tables.h: https://review.coreboot.org/c/coreboot/+/74121/comment/05df6c54_5fbc3341 PS1, Line 99: LB_TAG_CFR_STRING = 0x0102, > Unused? Is the CFR string structure intended to tag itself (as in, CFR implementation or service con […] This is currently unused, as CFR strings are not a cbtables record. However, it makes little sense: CFR sinks (consumers) need to handle CFR strings specially (they don't have a record header, and the string length needs to be rounded up to find the next CFR structure). So, this will be used. File src/drivers/option/cfr.h: https://review.coreboot.org/c/coreboot/+/74121/comment/ad25d042_de848482 PS1, Line 48: struct cfr_string { : uint32_t length; : uint8_t str[]; : }; > Note: This cannot be a cbtables record because `length` does not store the actual length of the stru […] Even if it's redundant, making this a cbtables record means CFR sinks (consumers) can be simpler (no need to specially handle CFR strings' length) and more robust (everything is a cbtables record, so the tag can be used for runtime type-checking aka validating the syntax). ``` struct lb_cfr_string { uint32_t tag; uint32_t size; uint32_t str_length; uint8_t str[]; }; ``` https://review.coreboot.org/c/coreboot/+/74121/comment/6a925269_b4851072 PS1, Line 56: /* struct cfr_string ui_name; */ Hmmmmm, the relations between records should be documented. The whole thing is a tree (records inside other records' size are children of the enclosing record), but the children of each node can't be whatever. (syntax? grammar? can't English today...) Records and their children can be thought of as function signatures (which can be variable-length). https://review.coreboot.org/c/coreboot/+/74121/comment/e0f02408_6611b4c0 PS1, Line 68: uint32_t size; We might want to add an "option ID" value here, which could be used in the future to reference options in some dependency expression mechanism (e.g. do not show `gfx_uma_size` if the iGPU is disabled by some other option). Even if we currently don't provide any constructs to express such dependencies. Otherwise, we'd need to add new tags to cbtables. https://review.coreboot.org/c/coreboot/+/74121/comment/dac3592e_8e72e09f PS1, Line 71: /* struct cfr_string opt_name; */ : /* struct cfr_string ui_name; */ : /* struct lb_cfr_enum_value enum_values[]; */ > Ah, possibly 'string length' and 'actual length' fields? I think it's fine though: just need to alig […] Yes, CFR strings (and byte buffers, if added in the future) would either need the two length fields you mentioned or CFR sinks (consumers) need to round up the "string length" value to obtain the "actual length" after which the next cbtables record resides. That being said, it's very odd to have CFR strings *not* be a cbtables record, unlike everything else. In that case, we would use the record's size as "actual length" and we'd have an additional field for "string/data length" (for strings/byte buffers, respectively). OK, decision made: even if it means storing additional data (8 bytes), CFR strings should be cbtables records like everything else. https://review.coreboot.org/c/coreboot/+/74121/comment/c3bca06b_81a228e0 PS1, Line 80: struct lb_cfr_form forms[]; Should be commented out too. Accessing elements other than the first using this member will result in undefined behavior, as the array stride does not account for all the variable-length stuff in here. There's the flexible array members in CFR strings, as well as variable-length record lists (e.g. enum values for an option, options in a form). File src/drivers/option/cfr.c: https://review.coreboot.org/c/coreboot/+/74121/comment/85f1be60_d94bb940 PS1, Line 127: write_body(header); : : menu->size = sm_compute_record_size((char *)menu, header); > I should be sleeping at 2am instead - this would fragment the CFR into 'actual' tags rather than one […] Not sure if cbtables can contain multiple records with the same tag. This is currently not a problem because `LB_TAG_CFR` is meant to be unique, and the other CFR tags are only used within the CFR-root record (the record tagged as `LB_TAG_CFR`). Since the CFR-root record's size contains all other CFR records, existing cbtables consumers will only see a huge record tagged as `LB_TAG_CFR` and simply skip it. The current implementation allows CFR sinks (consumers) to traverse the entire structure in order, which should be possible without needing variable length temporary buffers (the destination buffer is still variable length). This should also minimise the amount of global state that needs to be kept track of. Heck, one could implement a CFR writer in a functional programming style. If CFR structures are written in multiple chunks (e.g. each chunk contains a form for chipset/board/etc.), one could still process each form in order, but the ordering of forms wouldn't necessarily be stable (no idea which form is written first to cbtables). Then again, if it's that much of an issue, CFR sinks could build an array of references to the forms and sort it. However, the main drawback of this approach would be lack of flexibility: options would need to be grouped by coreboot compilation unit. Another idea would be to replace forms as a cbtables record with a "form ID" value in options. This would provide a lot of flexibility, but the resulting structures would not be in order anymore. Computationally speaking, this gets expensive: one would either need to walk through all CFR structures for each form (after figuring out which forms there are, which would probably involve walking through all CFR structures), or store references to options in a variable-length array of lists (each array element corresponds to a form ID and contains a list of the options for that form). If the CFR structures are fragmented, one would then need to walk through the entire cbtables instead. It would seem that splitting the generation of CFR structures is a no-go on the grounds of data entropy (the information is no longer sorted). However, note that CB:74122 doesn't write CFR structures directly: option data is stored in various `struct sm_*` variables (mostly constants, but `pch_pm_pcie_pll_ssc_values` is run-time generated), and then passed to the CFR writer code (this change). [Note: the following paragraphs use `gfx_uma_size` as an example, but this applies to other options as well] Although option values aren't always known in advance (e.g. the value for `gfx_uma_size` may be stored in CMOS), options themselves are known at build time (the code being built contains some reference to `gfx_uma_size`, currently a string literal passed to `get_uint_option()`; enum values are in mainboards' `cmos.layout`). After fully decoupling options from CMOS (e.g. declaring the `gfx_uma_size` option and its enum values once in chipset code, and having mainboards' `cmos.layout` reference the option declared in chipset code), one would have several "option descriptor" chunks of data scattered around the tree. Hmmm, we already have a bunch of "chunks of data scattered around the tree" of a different kind: PCI drivers. We could hook up our option descriptors to device drivers (we might want to have options for non-PCI devices, too). This would allow us to override the visibility of some settings from mainboard code (which CB:74122 doesn't do yet, but will need to for `ATLAS_PROF_REALTIME_PERFORMANCE`). This would also allow us to only show the options for enabled devices (e.g. suppress the `gfx_uma_size` option if the board does not have an iGPU; we still want to show the option when the iGPU is disabled but could be enabled later, to allow configuring `gfx_uma_size` after changing some other setting that will result in the iGPU being enabled next boot). Dynamically suppressing `gfx_uma_size` depending on the state of other options is something that cannot be described using CFR structures; additional structures could be added to describe such dependencies, but it would be best to add a numeric "option ID" field to avoid having to compare strings (option names). If we're going to bind options to devices, we might as well go the extra mile and declare options in the (chipset) devicetree. We would then use SCONFIG to generate the option descriptors at build time. If per-device options ever become a thing, we could even hook up option descriptors to devices, so that something like this is possible: ``` static void pch_pcie_init(struct device *dev) { /* TODO: needs NULL check, might need a cast too */ const struct southbridge_intel_lynxpoint_pcie_rp_dynopts *dynopts = dev->dynopts; const enum pcie_aspm aspm = get_uint_option(dynopts->aspm, ASPM_NONE); program_magic_aspm_registers(aspm); const bool obff = get_uint_option(dynopts->obff, true); program_magic_obff_registers(obff); const bool ltr = get_uint_option(dynopts->ltr, true); program_magic_ltr_registers(ltr); } ``` Where the `pch_pcie_init()` function is used as the `.init` device operation of a driver. Said driver is the same for all PCIe root port devices of the PCH (up to 8 on Lynx Point; the next generation PCH, Sunrise Point, has up to 24 PCIe root ports). -- To view, visit https://review.coreboot.org/c/coreboot/+/74121 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I304de7d26d79245a2e31a6d01f6c5643b31cb772 Gerrit-Change-Number: 74121 Gerrit-PatchSet: 1 Gerrit-Owner: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Benjamin Doron <benjamin.doron00(a)gmail.com> Gerrit-Reviewer: Maximilian Brune <maximilian.brune(a)9elements.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Daniel Maslowski <info(a)orangecms.org> Gerrit-CC: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Benjamin Doron <benjamin.doron00(a)gmail.com> Gerrit-Attention: Maximilian Brune <maximilian.brune(a)9elements.com> Gerrit-Comment-Date: Mon, 17 Apr 2023 20:06:21 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Benjamin Doron <benjamin.doron00(a)gmail.com> Comment-In-Reply-To: Angel Pons <th3fanbus(a)gmail.com> Gerrit-MessageType: comment

1 0

[M] Change in coreboot[master]: amdfwtool: Add --fsp-version option
by Karthik Ramasubramanian (Code Review) 17 Apr '23

17 Apr '23

Attention is currently required from: Jason Glenesk, Raul Rangel, Matt DeVillier, Paul Menzel, Grzegorz Bernacki, Arthur Heymans, Fred Reitberger, Felix Held. Karthik Ramasubramanian has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74266 ) Change subject: amdfwtool: Add --fsp-version option ...................................................................... Patch Set 1: (1 comment) File util/amdfwtool/amdfwtool.c: https://review.coreboot.org/c/coreboot/+/74266/comment/536ea0df_38cb803e PS1, Line 214: FSP blobs > Ok, so to summarize requested changes: […] Sounds good. Version info for more binaries can be supported on need basis. -- To view, visit https://review.coreboot.org/c/coreboot/+/74266 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idaa3a02ace524f44cfa656e34308bd896016dff6 Gerrit-Change-Number: 74266 Gerrit-PatchSet: 1 Gerrit-Owner: Grzegorz Bernacki Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Fred Reitberger <reitbergerfred(a)gmail.com> Gerrit-Reviewer: Jakub Czapiga <jacz(a)semihalf.com> Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com> Gerrit-Reviewer: Karthik Ramasubramanian <kramasub(a)google.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)amd.corp-partner.google.com> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Jason Glenesk <jason.glenesk(a)gmail.com> Gerrit-Attention: Raul Rangel <rrangel(a)chromium.org> Gerrit-Attention: Matt DeVillier <matt.devillier(a)amd.corp-partner.google.com> Gerrit-Attention: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Grzegorz Bernacki Gerrit-Attention: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Attention: Fred Reitberger <reitbergerfred(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Mon, 17 Apr 2023 20:06:09 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Raul Rangel <rrangel(a)chromium.org> Comment-In-Reply-To: Matt DeVillier <matt.devillier(a)amd.corp-partner.google.com> Comment-In-Reply-To: Paul Menzel <paulepanter(a)mailbox.org> Comment-In-Reply-To: Grzegorz Bernacki Comment-In-Reply-To: Arthur Heymans <arthur(a)aheymans.xyz> Comment-In-Reply-To: Karthik Ramasubramanian <kramasub(a)google.com> Comment-In-Reply-To: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-MessageType: comment

1 0

[M] Change in coreboot[master]: soc/intel/meteorlake: Don't offer D3Cold when it's disabled
by Sean Rhodes (Code Review) 17 Apr '23

17 Apr '23

Sean Rhodes has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74479 ) Change subject: soc/intel/meteorlake: Don't offer D3Cold when it's disabled ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/74479 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ifa55a19727e6adb6864158c2c323d08a0c22b996 Gerrit-Change-Number: 74479 Gerrit-PatchSet: 2 Gerrit-Owner: Sean Rhodes <sean(a)starlabs.systems> Gerrit-Comment-Date: Mon, 17 Apr 2023 19:46:56 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: soc/intel/meteorlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT
by Sean Rhodes (Code Review) 17 Apr '23

17 Apr '23

Sean Rhodes has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74478 ) Change subject: soc/intel/meteorlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/74478 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I08930ef84438140a13df74900570b126088bd1cb Gerrit-Change-Number: 74478 Gerrit-PatchSet: 3 Gerrit-Owner: Sean Rhodes <sean(a)starlabs.systems> Gerrit-Comment-Date: Mon, 17 Apr 2023 19:46:42 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: soc/intel/alderlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT
by Sean Rhodes (Code Review) 17 Apr '23

17 Apr '23

Attention is currently required from: Tarun Tuli, Subrata Banik. Hello Tarun Tuli, Subrata Banik, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/74477 to look at the new patch set (#4). Change subject: soc/intel/alderlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT ...................................................................... soc/intel/alderlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT Remove the `TcssD3ColdDisable` option in devicetree, as it exists in globally in Kconfig. The setting is currently unused. Signed-off-by: Sean Rhodes <sean(a)starlabs.systems> Change-Id: I2590e8dec0a308e0dc3d467cb3dd2bb97e877492 --- M src/soc/intel/alderlake/chip.h M src/soc/intel/alderlake/fsp_params.c 2 files changed, 14 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/77/74477/4 -- To view, visit https://review.coreboot.org/c/coreboot/+/74477 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I2590e8dec0a308e0dc3d467cb3dd2bb97e877492 Gerrit-Change-Number: 74477 Gerrit-PatchSet: 4 Gerrit-Owner: Sean Rhodes <sean(a)starlabs.systems> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-MessageType: newpatchset

1 0

[L] Change in coreboot[master]: util/crossgcc: Update binutils from 2.37 to 2.40
by Nick Vaccaro (Code Review) 17 Apr '23

17 Apr '23

Nick Vaccaro has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/66920 ) Change subject: util/crossgcc: Update binutils from 2.37 to 2.40 ...................................................................... Patch Set 27: (1 comment) Patchset: PS27: Hi Felix, Is there a bug that this uprev is fixing? This change breaks building of Intel's FSP package. I'd like to better understand the reason behind this uprev so we can determine the best way to deal with this issue for chromium OS. Thanks. -- To view, visit https://review.coreboot.org/c/coreboot/+/66920 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I34a20a999f7ea624c1add4750fcd116166953dd8 Gerrit-Change-Number: 66920 Gerrit-PatchSet: 27 Gerrit-Owner: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Elyes Haouas <ehaouas(a)noos.fr> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: 9elements QA <hardwaretestrobot(a)gmail.com> Gerrit-CC: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Comment-Date: Mon, 17 Apr 2023 19:46:13 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: soc/intel/alderlake: Remove tcss_d3_cold_disable devicetree option
by Sean Rhodes (Code Review) 17 Apr '23

17 Apr '23

Sean Rhodes has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74477 ) Change subject: soc/intel/alderlake: Remove tcss_d3_cold_disable devicetree option ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/74477 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I2590e8dec0a308e0dc3d467cb3dd2bb97e877492 Gerrit-Change-Number: 74477 Gerrit-PatchSet: 3 Gerrit-Owner: Sean Rhodes <sean(a)starlabs.systems> Gerrit-Comment-Date: Mon, 17 Apr 2023 19:45:46 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

[S] Change in coreboot[master]: soc/intel/tigerlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT
by Sean Rhodes (Code Review) 17 Apr '23

17 Apr '23

Sean Rhodes has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74476 ) Change subject: soc/intel/tigerlake: Replace TcssD3ColdDisable with D3COLD_SUPPORT ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/74476 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I50e49e900c96748edd5b678765e47cc0e0d9b280 Gerrit-Change-Number: 74476 Gerrit-PatchSet: 3 Gerrit-Owner: Sean Rhodes <sean(a)starlabs.systems> Gerrit-Comment-Date: Mon, 17 Apr 2023 19:45:36 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit April 2023