coreboot-gerrit April 2025

coreboot-gerrit@coreboot.org

1 participants
3140 discussions

[XS] Change in coreboot[main]: soc/mediatek/mt8189: Reserve DRAM buffers for HW TX TRACKING
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87039?usp=email ) Change subject: soc/mediatek/mt8189: Reserve DRAM buffers for HW TX TRACKING ...................................................................... soc/mediatek/mt8189: Reserve DRAM buffers for HW TX TRACKING HW TX tracking works by writing a pattern to the designated DRAM buffer and then reading it back automatically to calculate the appropriate TX time delay. To avoid writing the pattern to system-used memory, we need to permanently reserve last 64KB memory on each rank for the HW TX tracking feature. BUG=b:379008996 BRANCH=none TEST=Reserve memory ok Firmware shows the following log : 000000013fff0000-000000013fffffff: RESERVED 000000023fff0000-000000023fffffff: RESERVED Signed-off-by: Mike Lin <mike.lin(a)mediatek.corp-partner.google.com> Change-Id: I2ecfe42dc9f1882163d03f50cf9b5ff8e98c2972 Reviewed-on: https://review.coreboot.org/c/coreboot/+/87039 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Yidi Lin <yidilin(a)google.com> --- M src/soc/mediatek/mt8189/Makefile.mk M src/soc/mediatek/mt8189/soc.c 2 files changed, 8 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Yidi Lin: Looks good to me, approved diff --git a/src/soc/mediatek/mt8189/Makefile.mk b/src/soc/mediatek/mt8189/Makefile.mk index bdee1fb..7631bc6 100644 --- a/src/soc/mediatek/mt8189/Makefile.mk +++ b/src/soc/mediatek/mt8189/Makefile.mk @@ -19,6 +19,7 @@ romstage-y += ../common/memory.c ../common/memory_test.c romstage-y += ../common/mmu_operations.c ../common/mmu_cmops.c +ramstage-y += ../common/dramc_info.c ramstage-y += ../common/emi.c ramstage-y += ../common/memory.c ramstage-y += ../common/mmu_operations.c ../common/mmu_cmops.c diff --git a/src/soc/mediatek/mt8189/soc.c b/src/soc/mediatek/mt8189/soc.c index e4dfc23..e53136d 100644 --- a/src/soc/mediatek/mt8189/soc.c +++ b/src/soc/mediatek/mt8189/soc.c @@ -1,9 +1,16 @@ /* SPDX-License-Identifier: GPL-2.0-only OR MIT */ +#include <bootmem.h> #include <device/device.h> +#include <soc/dramc_info.h> #include <soc/emi.h> #include <symbols.h> +void bootmem_platform_add_ranges(void) +{ + reserve_buffer_for_dramc(); +} + static void soc_read_resources(struct device *dev) { ram_range(dev, 0, (uintptr_t)_dram, sdram_size()); -- To view, visit https://review.coreboot.org/c/coreboot/+/87039?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I2ecfe42dc9f1882163d03f50cf9b5ff8e98c2972 Gerrit-Change-Number: 87039 Gerrit-PatchSet: 3 Gerrit-Owner: Vince Liu <vince-wl.liu(a)mediatek.com> Gerrit-Reviewer: Hung-Te Lin <hungte(a)chromium.org> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Yidi Lin <yidilin(a)google.com> Gerrit-Reviewer: Yu-Ping Wu <yupingso(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[XS] Change in coreboot[main]: mb/google/skywalker: Add DRAM calibration init entry
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87038?usp=email ) Change subject: mb/google/skywalker: Add DRAM calibration init entry ...................................................................... mb/google/skywalker: Add DRAM calibration init entry Add DRAM calibration entry in romstage. BUG=b:379008996 BRANCH=none TEST=Boot up pass 3200 LPDDR5 chan0(x16) rank0: memory test pass 3200 LPDDR5 chan0(x16) rank1: memory test pass 3200 LPDDR5 chan1(x16) rank0: memory test pass 3200 LPDDR5 chan1(x16) rank1: memory test pass Signed-off-by: Mike Lin <mike.lin(a)mediatek.corp-partner.google.com> Change-Id: Iabdcabefc77a262c548019e801daf5b269eaa97a Reviewed-on: https://review.coreboot.org/c/coreboot/+/87038 Reviewed-by: Yidi Lin <yidilin(a)google.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M src/mainboard/google/skywalker/romstage.c 1 file changed, 2 insertions(+), 1 deletion(-) Approvals: build bot (Jenkins): Verified Yidi Lin: Looks good to me, approved diff --git a/src/mainboard/google/skywalker/romstage.c b/src/mainboard/google/skywalker/romstage.c index 7758dfa..74cfb1b 100644 --- a/src/mainboard/google/skywalker/romstage.c +++ b/src/mainboard/google/skywalker/romstage.c @@ -1,8 +1,9 @@ /* SPDX-License-Identifier: GPL-2.0-only OR MIT */ #include <arch/stages.h> +#include <soc/emi.h> void platform_romstage_main(void) { - /* TODO: add romstage main function */ + mtk_dram_init(); } -- To view, visit https://review.coreboot.org/c/coreboot/+/87038?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: Iabdcabefc77a262c548019e801daf5b269eaa97a Gerrit-Change-Number: 87038 Gerrit-PatchSet: 3 Gerrit-Owner: Vince Liu <vince-wl.liu(a)mediatek.com> Gerrit-Reviewer: Hung-Te Lin <hungte(a)chromium.org> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Yidi Lin <yidilin(a)google.com> Gerrit-Reviewer: Yu-Ping Wu <yupingso(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[L] Change in coreboot[main]: Documentation: Reformat fw_config.md
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87190?usp=email ) Change subject: Documentation: Reformat fw_config.md ...................................................................... Documentation: Reformat fw_config.md This doesn't change any text - it just reformats the existing document. - reflow paragraphs to 72 characters - Put examples inside pre-formatted text blocks - Adds spacing before section markers Change-Id: I83925a4469e264da5887334e2584466cef089503 Signed-off-by: Martin Roth <gaumless(a)gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/87190 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Nicholas Chin <nic.c3.14(a)gmail.com> --- M Documentation/lib/fw_config.md 1 file changed, 288 insertions(+), 200 deletions(-) Approvals: Nicholas Chin: Looks good to me, approved build bot (Jenkins): Verified diff --git a/Documentation/lib/fw_config.md b/Documentation/lib/fw_config.md index 884ba3f..bb7f4fb 100644 --- a/Documentation/lib/fw_config.md +++ b/Documentation/lib/fw_config.md @@ -2,225 +2,284 @@ ## Motivation -The firmware configuration interface in coreboot is designed to support a wide variety of -configuration options in that are dictated by the hardware at runtime. This allows a single -BIOS image to be used across a wide variety of devices which may have key differences but are -otherwise similar enough to use the same coreboot build target. +The firmware configuration interface in coreboot is designed to support +a wide variety of configuration options in that are dictated by the +hardware at runtime. This allows a single BIOS image to be used across a +wide variety of devices which may have key differences but are otherwise +similar enough to use the same coreboot build target. -The initial implementation is designed to take advantage of a bitmask returned by the Embedded -Controller on Google ChromeOS devices which allows the manufacturer to use the same firmware -image across multiple devices by selecting various options at runtime. See the ChromiumOS +The initial implementation is designed to take advantage of a bitmask +returned by the Embedded Controller on Google ChromeOS devices which +allows the manufacturer to use the same firmware image across multiple +devices by selecting various options at runtime. See the ChromiumOS [Firmware Config][1] documentation for more information. -This firmware configuration interface differs from the CMOS option interface in that this -bitmask value is not intended as a user-configurable setting as the configuration values must -match the actual hardware. In the case where a user was to swap their hardware this value -would need to be updated or overridden. +This firmware configuration interface differs from the CMOS option +interface in that this bitmask value is not intended as a +user-configurable setting as the configuration values must match the +actual hardware. In the case where a user was to swap their hardware +this value would need to be updated or overridden. + ## Device Presence -One common example of why a firmware configuration interface is important is determining if a -device is present in the system. With some bus topologies and hardware mechanisms it is -possible to probe and enumerate this at runtime: +One common example of why a firmware configuration interface is +important is determining if a device is present in the system. With some +bus topologies and hardware mechanisms it is possible to probe and +enumerate this at runtime: - PCI is a self-discoverable bus and is very easy to handle. - I2C devices can often be probed with a combination of bus and address. -- The use of GPIOs with external strap to ground or different voltages can be used to detect -presence of a device. +- The use of GPIOs with external strap to ground or different voltages + can be used to detect presence of a device. However there are several cases where this is insufficient: -- I2C peripherals that require different drivers but have the same bus address cannot be -uniquely identified at runtime. -- A mainboard may be designed with multiple daughter board combinations which contain devices -and configurations that cannot be detected. -- While presence detect GPIOs are a convenient way for a single device presence, they are -unable to distinguish between different devices so it can require a large number of GPIOs to -support relatively few options. +- I2C peripherals that require different drivers but have the same bus + address cannot be uniquely identified at runtime. +- A mainboard may be designed with multiple daughter board combinations + which contain devices and configurations that cannot be detected. +- While presence detect GPIOs are a convenient way for a single device + presence, they are unable to distinguish between different devices so + it can require a large number of GPIOs to support relatively few + options. This presence detection can impact different stages of boot: + ### ACPI -Devices that are not present should not provide an ACPI device indicating that they are -present or the operating system may not be able to handle it correctly. +Devices that are not present should not provide an ACPI device +indicating that they are present or the operating system may not be able +to handle it correctly. -The ACPI devices are largely driven by chips defined in the mainboard `devicetree.cb` and -the variant overridetree.cb. This means it is important to be able to specify when a device -is present or not directly in `devicetree.cb` itself. Otherwise each mainboard needs custom -code to parse the tree and disable unused devices. +The ACPI devices are largely driven by chips defined in the mainboard +`devicetree.cb` and the variant overridetree.cb. This means it is +important to be able to specify when a device is present or not directly +in `devicetree.cb` itself. Otherwise each mainboard needs custom code to +parse the tree and disable unused devices. + ### GPIO -GPIOs with multiple functions may need to be configured correctly depending on the attached -device. Given the wide variety of GPIO configuration possibilities it is not feasible to -specify all combinations directly in `devicetree.cb` and it is best left to code provided by -the mainboard. +GPIOs with multiple functions may need to be configured correctly +depending on the attached device. Given the wide variety of GPIO +configuration possibilities it is not feasible to specify all +combinations directly in `devicetree.cb` and it is best left to code +provided by the mainboard. + ### FSP UPD -Enabling and disabling devices may require altering FSP UPD values that are provided to the -various stages of FSP. These options are also not easy to specify multiple times for -different configurations in `devicetree.cb` and can be provided by the mainboard as code. +Enabling and disabling devices may require altering FSP UPD values that +are provided to the various stages of FSP. These options are also not +easy to specify multiple times for different configurations in +`devicetree.cb` and can be provided by the mainboard as code. + ## Firmware Configuration Interface -The firmware configuration interface can be enabled by selecting `CONFIG_FW_CONFIG` and also -providing a source for the value by defining an additional Kconfig option defined below. +The firmware configuration interface can be enabled by selecting +`CONFIG_FW_CONFIG` and also providing a source for the value by defining +an additional Kconfig option defined below. -If the firmware configuration interface is disabled via Kconfig then all probe attempts will -return true. +If the firmware configuration interface is disabled via Kconfig then all +probe attempts will return true. + ## Firmware Configuration Value -The 64-bit value used as the firmware configuration bitmask is meant to be determined at runtime -but could also be defined at compile time if needed. +The 64-bit value used as the firmware configuration bitmask is meant to +be determined at runtime but could also be defined at compile time if +needed. -There are two supported sources for providing this information to coreboot. +There are two supported sources for providing this information to +coreboot. + ### CBFS -The value can be provided with a 64-bit raw value in CBFS that is read by coreboot. The value -can be set at build time but also adjusted in an existing image with `cbfstool`. +The value can be provided with a 64-bit raw value in CBFS that is read +by coreboot. The value can be set at build time but also adjusted in an +existing image with `cbfstool`. -To enable this select the `CONFIG_FW_CONFIG_CBFS` option in the build configuration and add a -raw 64-bit value to CBFS with the name of the current prefix at `CONFIG_FW_PREFIX/fw_config`. +To enable this select the `CONFIG_FW_CONFIG_CBFS` option in the build +configuration and add a raw 64-bit value to CBFS with the name of the +current prefix at `CONFIG_FW_PREFIX/fw_config`. -When `fw_config_probe_device()` or `fw_config_probe()` is called it will look for the specified -file in CBFS use the value it contains when matching fields and options. +When `fw_config_probe_device()` or `fw_config_probe()` is called it will +look for the specified file in CBFS use the value it contains when +matching fields and options. + ### Embedded Controller -Google ChromeOS devices support an Embedded Controller interface for reading and writing the -firmware configuration value, along with other board-specific information. It is possible for -coreboot to read this value at boot on systems that support this feature. +Google ChromeOS devices support an Embedded Controller interface for +reading and writing the firmware configuration value, along with other +board-specific information. It is possible for coreboot to read this +value at boot on systems that support this feature. This option is selected by default for the mainboards that use it with -`CONFIG_FW_CONFIG_CHROME_EC_CBI` and it is not typically necessary to adjust the value. It is -possible by enabling the CBFS source and coreboot will look in CBFS first for a valid value -before asking the embedded controller. +`CONFIG_FW_CONFIG_CHROME_EC_CBI` and it is not typically necessary to +adjust the value. It is possible by enabling the CBFS source and +coreboot will look in CBFS first for a valid value before asking the +embedded controller. -It is also possible to adjust the value in the embedded controller *(after disabling write -protection)* with the `ectool` command in a ChromeOS environment. +It is also possible to adjust the value in the embedded controller +*(after disabling write protection)* with the `ectool` command in a +ChromeOS environment. -For more information on the firmware configuration field on ChromeOS devices see the Chromium -documentation for [Firmware Config][1] and [Board Info][2]. +For more information on the firmware configuration field on ChromeOS +devices see the Chromium documentation for [Firmware Config][1] and +[Board Info][2]. [1]: http://chromium.googlesource.com/chromiumos/docs/+/HEAD/design_docs/firmwar… [2]: http://chromium.googlesource.com/chromiumos/docs/+/HEAD/design_docs/cros_bo… + ## Firmware Configuration Table -The firmware configuration table itself is defined in the mainboard `devicetree.cb` with -special tokens for defining fields and options. +The firmware configuration table itself is defined in the mainboard +`devicetree.cb` with special tokens for defining fields and options. -The table itself is enclosed in a `fw_config` token and terminated with `end` and it contains -a mix of field and option definitions. +The table itself is enclosed in a `fw_config` token and terminated with +`end` and it contains a mix of field and option definitions. -Each field is defined by providing the field name and the start and end bit marking the exact -location in the bitmask. Field names must be at least three characters long in order to -satisfy the sconfig parser requirements and they must be unique with non-overlapping masks. +Each field is defined by providing the field name and the start and end +bit marking the exact location in the bitmask. Field names must be at +least three characters long in order to satisfy the sconfig parser +requirements and they must be unique with non-overlapping masks. - field <name> <start-bit> <end-bit> [option...] end +```text +field <name> <start-bit> <end-bit> [option...] end +``` For single-bit fields only one number is needed: - field <name> <bit> [option...] end +```text +field <name> <bit> [option...] end +``` -A field definition can also contain multiple sets of bit masks, which can be dis-contiguous. -They are treated as if they are contiguous when defining option values. This allows for -extending fields even after the bits after its current masks are occupied. +A field definition can also contain multiple sets of bit masks, which +can be dis-contiguous. They are treated as if they are contiguous when +defining option values. This allows for extending fields even after the +bits after its current masks are occupied. - field <name> <start-bit0> <end-bit0> | <start-bit1> <end-bit1> | ... +```text +field <name> <start-bit0> <end-bit0> | <start-bit1> <end-bit1> | ... +``` For example, if more audio options need to be supported: - field AUDIO 3 3 - option AUDIO_0 0 - option AUDIO_1 1 - end - field OTHER 4 4 - ... - end +```text +field AUDIO 3 3 + option AUDIO_0 0 + option AUDIO_1 1 +end +field OTHER 4 4 + ... +end +``` the following can be done: - field AUDIO 3 3 | 5 5 - option AUDIO_FOO 0 - option AUDIO_BLAH 1 - option AUDIO_BAR 2 - option AUDIO_BAZ 3 - end - field OTHER 4 4 - ... - end +```text +field AUDIO 3 3 | 5 5 + option AUDIO_FOO 0 + option AUDIO_BLAH 1 + option AUDIO_BAR 2 + option AUDIO_BAZ 3 +end +field OTHER 4 4 + ... +end +``` In that case, the AUDIO masks are extended like so: - #define FW_CONFIG_FIELD_AUDIO_MASK 0x28 - #define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x0 - #define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH_VALUE 0x8 - #define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20 - #define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAz_VALUE 0x28 +```c +#define FW_CONFIG_FIELD_AUDIO_MASK 0x28 +#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x0 +#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH_VALUE 0x8 +#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20 +#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAz_VALUE 0x28 +``` -Each `field` definition starts a new block that can be composed of zero or more field options, -and it is terminated with `end`. +Each `field` definition starts a new block that can be composed of zero +or more field options, and it is terminated with `end`. -Inside the field block the options can be defined by providing the option name and the field -value that this option represents when the bit offsets are used to apply a mask and shift. -Option names must also be at least three characters for the sconfig parser. +Inside the field block the options can be defined by providing the +option name and the field value that this option represents when the bit +offsets are used to apply a mask and shift. Option names must also be at +least three characters for the sconfig parser. - option <name> <value> +```text +option <name> <value> +``` -It is possible for there to be multiple `fw_config` blocks and for subsequent `field` blocks -to add additional `option` definitions to the existing field. These subsequent definitions -should not provide the field bitmask as it has already been defined earlier in the file and +It is possible for there to be multiple `fw_config` blocks and for +subsequent `field` blocks to add additional `option` definitions to the +existing field. These subsequent definitions should not provide the +field bitmask as it has already been defined earlier in the file and this is just matching an existing field by name. - field <name> [option...] end +```text +field <name> [option...] end +``` -This allows a baseboard to define the major fields and options in `devicetree.cb` and a board -variant to add specific options to fields in or define new fields in the unused bitmask in -`overridetree.cb`. +This allows a baseboard to define the major fields and options in +`devicetree.cb` and a board variant to add specific options to fields in +or define new fields in the unused bitmask in `overridetree.cb`. -It is not possible to redefine a field mask or override the value of an existing option this -way, only to add new options to a field or new fields to the table. +It is not possible to redefine a field mask or override the value of an +existing option this way, only to add new options to a field or new +fields to the table. + ### Firmware Configuration Table Example -In this example a baseboard defines a simple boolean feature that is enabled or disabled -depending on the value of bit 0, and a field at bits 1-2 that indicates which daughter board -is attached. +In this example a baseboard defines a simple boolean feature that is +enabled or disabled depending on the value of bit 0, and a field at bits +1-2 that indicates which daughter board is attached. -The baseboard itself defines one daughter board and the variant adds two more possibilities. -This way each variant can support multiple possible daughter boards in addition to the one -that was defined by the baseboard. +The baseboard itself defines one daughter board and the variant adds two +more possibilities. This way each variant can support multiple possible +daughter boards in addition to the one that was defined by the +baseboard. + #### devicetree.cb - fw_config - field FEATURE 0 - option DISABLED 0 - option ENABLED 1 - end - field DAUGHTER_BOARD 1 2 - option NONE 0 - option REFERENCE_DB 1 - end +```text +fw_config + field FEATURE 0 + option DISABLED 0 + option ENABLED 1 end + field DAUGHTER_BOARD 1 2 + option NONE 0 + option REFERENCE_DB 1 + end +end +``` + #### overridetree.cb - fw_config - field DAUGHTER_BOARD - option VARIANT_DB_ONE 2 - option VARIANT_DB_TWO 3 - end +```text +fw_config + field DAUGHTER_BOARD + option VARIANT_DB_ONE 2 + option VARIANT_DB_TWO 3 end +end +``` -The result of this table defined in `devicetree.cb` is a list of constants that can be used -to check if fields match the firmware configuration options determined at runtime with a -simple check of the field mask and the option value. +The result of this table defined in `devicetree.cb` is a list of +constants that can be used to check if fields match the firmware +configuration options determined at runtime with a simple check of the +field mask and the option value. + #### static.h @@ -246,73 +305,96 @@ #define FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_TWO_VALUE 0x00000006 ``` + ## Device Probing -One use of the firmware configuration interface in devicetree is to allow device probing to be -specified directly with the devices themselves. A new `probe` token is introduced to allow a -device to be probed by field and option name. Multiple `probe` entries may be present for -each device and any successful probe will consider the device to be present. +One use of the firmware configuration interface in devicetree is to +allow device probing to be specified directly with the devices +themselves. A new `probe` token is introduced to allow a device to be +probed by field and option name. Multiple `probe` entries may be present +for each device and any successful probe will consider the device to be +present. + ### Probing Example -Continuing with the previous example this device would be considered present if the field -`DAUGHTER_BOARD` was set to either `VARIANT_DB_ONE` or `VARIANT_DB_TWO`: +Continuing with the previous example this device would be considered +present if the field `DAUGHTER_BOARD` was set to either `VARIANT_DB_ONE` +or `VARIANT_DB_TWO`: + #### overridetree.cb - chip drivers/generic/example - device generic 0 on - probe DAUGHTER_BOARD VARIANT_DB_ONE - probe DAUGHTER_BOARD VARIANT_DB_TWO - end +```text +chip drivers/generic/example + device generic 0 on + probe DAUGHTER_BOARD VARIANT_DB_ONE + probe DAUGHTER_BOARD VARIANT_DB_TWO end +end +``` -If the field were set to any other option, including `NONE` and `REFERENCE_DB` and any -undefined value then the device would be disabled. +If the field were set to any other option, including `NONE` and +`REFERENCE_DB` and any undefined value then the device would be +disabled. + ### Probe Overrides -When a device is declared with a probe in the baseboard `devicetree.cb` and the same device -is also present in the `overridetree.cb` then the probing information from the baseboard -is discarded and the override device must provide all necessary probing information. +When a device is declared with a probe in the baseboard `devicetree.cb` +and the same device is also present in the `overridetree.cb` then the +probing information from the baseboard is discarded and the override +device must provide all necessary probing information. -In this example a device is listed in the baseboard with `DAUGHTER_BOARD` field probing for -`REFERENCE_DB` as a field option, It is also defined as an override device with the field -probing for the `VARIANT_DB_ONE` option instead. +In this example a device is listed in the baseboard with +`DAUGHTER_BOARD` field probing for `REFERENCE_DB` as a field option, It +is also defined as an override device with the field probing for the +`VARIANT_DB_ONE` option instead. -In this case only the probe listed in the override is checked and a field option of -`REFERENCE_DB` will not mark this device present. If both options are desired then the -override device must list both. This allows an override device to remove a probe entry that -was defined in the baseboard. +In this case only the probe listed in the override is checked and a +field option of `REFERENCE_DB` will not mark this device present. If +both options are desired then the override device must list both. This +allows an override device to remove a probe entry that was defined in +the baseboard. + #### devicetree.cb - chip drivers/generic/example - device generic 0 on - probe DAUGHTER_BOARD REFERENCE_DB - end - end +```text +chip drivers/generic/example + device generic 0 on + probe DAUGHTER_BOARD REFERENCE_DB + end +end +``` + #### overridetree.cb - chip drivers/generic/example - device generic 0 on - probe DAUGHTER_BOARD VARIANT_DB_ONE - end - end +```text +chip drivers/generic/example + device generic 0 on + probe DAUGHTER_BOARD VARIANT_DB_ONE + end +end +``` + ### Automatic Device Probing -At boot time the firmware configuration interface will walk the device tree and apply any -probe entries that were defined in `devicetree.cb`. This probing takes effect before the -`BS_DEV_ENUMERATE` step during the boot state machine in ramstage. +At boot time the firmware configuration interface will walk the device +tree and apply any probe entries that were defined in `devicetree.cb`. +This probing takes effect before the `BS_DEV_ENUMERATE` step during the +boot state machine in ramstage. -Devices that have a probe list but do do not find a match are disabled by setting -`dev->enabled = 0` but the chip `enable_dev()` and device `enable()` handlers will still -be executed to allow any device disable code to execute. +Devices that have a probe list but do do not find a match are disabled +by setting `dev->enabled = 0` but the chip `enable_dev()` and device +`enable()` handlers will still be executed to allow any device disable +code to execute. -The result of this probe definition is to provide an array of structures describing each -field and option to check. +The result of this probe definition is to provide an array of structures +describing each field and option to check. + #### fw_config.h @@ -325,40 +407,43 @@ * @value: Value of the option within the mask. */ struct fw_config { - const char *field_name; - const char *option_name; - uint64_t mask; - uint64_t value; + const char *field_name; + const char *option_name; + uint64_t mask; + uint64_t value; }; ``` + #### static.c ```c STORAGE struct fw_config __devN_probe_list[] = { - { - .field_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_NAME, - .option_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_ONE_NAME, - .mask = FW_CONFIG_FIELD_DAUGHTER_BOARD_MASK, - .value = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_ONE_VALUE - }, - { - .field_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_NAME, - .option_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_TWO_NAME, - .mask = FW_CONFIG_FIELD_DAUGHTER_BOARD_MASK, - .value = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_TWO_VALUE - }, - { } + { + .field_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_NAME, + .option_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_ONE_NAME, + .mask = FW_CONFIG_FIELD_DAUGHTER_BOARD_MASK, + .value = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_ONE_VALUE + }, + { + .field_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_NAME, + .option_name = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_TWO_NAME, + .mask = FW_CONFIG_FIELD_DAUGHTER_BOARD_MASK, + .value = FW_CONFIG_FIELD_DAUGHTER_BOARD_OPTION_VARIANT_DB_TWO_VALUE + }, + { } }; ``` + ### Runtime Probing -The device driver probing allows for seamless integration with the mainboard but it is only -effective in ramstage and for specific devices declared in devicetree.cb. There are other -situations where code may need to probe or check the value of a field in romstage or at other -points in ramstage. For this reason it is also possible to use the firmware configuration -interface directly. +The device driver probing allows for seamless integration with the +mainboard but it is only effective in ramstage and for specific devices +declared in devicetree.cb. There are other situations where code may +need to probe or check the value of a field in romstage or at other +points in ramstage. For this reason it is also possible to use the +firmware configuration interface directly. ```c /** @@ -372,18 +457,21 @@ The argument provided to this function can be created from a macro for easy use: - FW_CONFIG(field, option) +```text + FW_CONFIG(field, option) +``` -This example has a mainboard check if a feature is disabled and set an FSP UPD before memory -training. This example expects that the default value of this `register` is set to `true` in -`devicetree.cb` and this code is disabling that feature before FSP is executed. +This example has a mainboard check if a feature is disabled and set an +FSP UPD before memory training. This example expects that the default +value of this `register` is set to `true` in `devicetree.cb` and this +code is disabling that feature before FSP is executed. ```c #include <fw_config.h> void mainboard_memory_init_params(FSPM_UPD *mupd) { - if (fw_config_probe(FW_CONFIG(FEATURE, DISABLED)) - mupd->ExampleFeature = false; + if (fw_config_probe(FW_CONFIG(FEATURE, DISABLED)) + mupd->ExampleFeature = false; } ``` -- To view, visit https://review.coreboot.org/c/coreboot/+/87190?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I83925a4469e264da5887334e2584466cef089503 Gerrit-Change-Number: 87190 Gerrit-PatchSet: 5 Gerrit-Owner: Martin L Roth <gaumless(a)gmail.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Nicholas Chin <nic.c3.14(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[M] Change in coreboot[main]: soc/intel/alderlake: drop ALDERLAKE_CONFIGURE_DESCRIPTOR
by Alicja Michalska (Code Review) 09 Apr '25

09 Apr '25

Attention is currently required from: Michał Kopeć, Nick Vaccaro, Subrata Banik. Alicja Michalska has posted comments on this change by Michał Kopeć. ( https://review.coreboot.org/c/coreboot/+/78911?usp=email ) Change subject: soc/intel/alderlake: drop ALDERLAKE_CONFIGURE_DESCRIPTOR ...................................................................... Patch Set 3: (1 comment) Patchset: PS3: Is this still needed? It needs unlocked IFD to do it, and coreboot already has a mechanism in place to soft-disable ME -- To view, visit https://review.coreboot.org/c/coreboot/+/78911?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I1dd059462c876728c7009a472d837a1bc7892a67 Gerrit-Change-Number: 78911 Gerrit-PatchSet: 3 Gerrit-Owner: Michał Kopeć <michal.kopec(a)3mdeb.com> Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Alicja Michalska <ahplka19(a)gmail.com> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-Attention: Michał Kopeć <michal.kopec(a)3mdeb.com> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)chromium.org> Gerrit-Comment-Date: Wed, 09 Apr 2025 17:49:00 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[XS] Change in coreboot[main]: mb/google/skywalker: Set up USB host in ramstage
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87022?usp=email ) Change subject: mb/google/skywalker: Set up USB host in ramstage ...................................................................... mb/google/skywalker: Set up USB host in ramstage Add USB host function support. BUG=b:379008996 BRANCH=none TEST=boot to kernel successfully from USB drive Signed-off-by: Liu Liu <ot_liu.liu(a)mediatek.corp-partner.google.com> Change-Id: I3f77d116033338f979d14ce34ddf03e00d024e5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/87022 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Yidi Lin <yidilin(a)google.com> --- M src/mainboard/google/skywalker/mainboard.c 1 file changed, 2 insertions(+), 1 deletion(-) Approvals: build bot (Jenkins): Verified Yidi Lin: Looks good to me, approved diff --git a/src/mainboard/google/skywalker/mainboard.c b/src/mainboard/google/skywalker/mainboard.c index 9ab352c..257faa1 100644 --- a/src/mainboard/google/skywalker/mainboard.c +++ b/src/mainboard/google/skywalker/mainboard.c @@ -1,10 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0-only OR MIT */ #include <device/device.h> +#include <soc/usb.h> static void mainboard_init(struct device *dev) { - /* TODO: add mainboard init */ + setup_usb_host(); } static void mainboard_enable(struct device *dev) -- To view, visit https://review.coreboot.org/c/coreboot/+/87022?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I3f77d116033338f979d14ce34ddf03e00d024e5d Gerrit-Change-Number: 87022 Gerrit-PatchSet: 3 Gerrit-Owner: Vince Liu <vince-wl.liu(a)mediatek.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Yidi Lin <yidilin(a)google.com> Gerrit-Reviewer: Yu-Ping Wu <yupingso(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Liu Liu <ot_liu.liu(a)mediatek.corp-partner.google.com> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org>

1 0

[S] Change in coreboot[main]: soc/intel/elkhartlake/pmc,gpio: Fix PMC GPE GPIO routes
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Attention is currently required from: Intel coreboot Reviewers, Jérémy Compostella, Michał Żygowski, Werner Zeh. Matt DeVillier has posted comments on this change by Michał Żygowski. ( https://review.coreboot.org/c/coreboot/+/87050?usp=email ) Change subject: soc/intel/elkhartlake/pmc,gpio: Fix PMC GPE GPIO routes ...................................................................... Patch Set 2: Code-Review+2 (3 comments) Commit Message: https://review.coreboot.org/c/coreboot/+/87050/comment/b04eb0cd_b9badfe5?us… : PS1, Line 7: elkahrtalake > elkhartlake Done https://review.coreboot.org/c/coreboot/+/87050/comment/933e1c7b_52d8d6e8?us… : PS1, Line 10: R&DC > R&DC is not necessary. The document title and number is the reference. Done https://review.coreboot.org/c/coreboot/+/87050/comment/f50de797_ca698e46?us… : PS1, Line 13: non-existent GPIO groups > I mean, GPP_S exists, but there is no value for it in the PMC and GPIO GPE DW registers. […] Acknowledged -- To view, visit https://review.coreboot.org/c/coreboot/+/87050?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I910f3c4c0d31b8d24b83cd2c3a28688b898b5d9f Gerrit-Change-Number: 87050 Gerrit-PatchSet: 2 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Intel coreboot Reviewers <intel_coreboot_reviewers(a)intel.com> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Intel coreboot Reviewers <intel_coreboot_reviewers(a)intel.com> Gerrit-Attention: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Attention: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Attention: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Comment-Date: Wed, 09 Apr 2025 17:34:18 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Comment-In-Reply-To: Michał Żygowski <michal.zygowski(a)3mdeb.com> Comment-In-Reply-To: Jérémy Compostella <jeremy.compostella(a)intel.com>

1 0

[S] Change in coreboot[main]: soc/intel/elkhartlake/pmc,gpio: Fix PMC GPE GPIO routes
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Attention is currently required from: Intel coreboot Reviewers, Michał Żygowski, Werner Zeh. Matt DeVillier has uploaded a new patch set (#2) to the change originally created by Michał Żygowski. ( https://review.coreboot.org/c/coreboot/+/87050?usp=email ) Change subject: soc/intel/elkhartlake/pmc,gpio: Fix PMC GPE GPIO routes ...................................................................... soc/intel/elkhartlake/pmc,gpio: Fix PMC GPE GPIO routes Based on the description of PMC GPIO_CONF register from EHL EDS Vol 2 Book 2 rev 2.3 #614109. Some of the groups had incorrect values or even defined non-existent GPIO groups. TEST=Boot Protectli VP2420 to Ubuntu 24.04. Change-Id: I910f3c4c0d31b8d24b83cd2c3a28688b898b5d9f Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com> --- M src/soc/intel/elkhartlake/gpio.c M src/soc/intel/elkhartlake/include/soc/gpio_soc_defs.h M src/soc/intel/elkhartlake/include/soc/pmc.h 3 files changed, 10 insertions(+), 13 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/50/87050/2 -- To view, visit https://review.coreboot.org/c/coreboot/+/87050?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I910f3c4c0d31b8d24b83cd2c3a28688b898b5d9f Gerrit-Change-Number: 87050 Gerrit-PatchSet: 2 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Intel coreboot Reviewers <intel_coreboot_reviewers(a)intel.com> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Reviewer: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Intel coreboot Reviewers <intel_coreboot_reviewers(a)intel.com> Gerrit-Attention: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Attention: Werner Zeh <werner.zeh(a)siemens.com>

1 0

[M] Change in coreboot[main]: Documentation/mainboard/lenovo: Add ThinkCentre M700/M900 Tiny
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87044?usp=email ) Change subject: Documentation/mainboard/lenovo: Add ThinkCentre M700/M900 Tiny ...................................................................... Documentation/mainboard/lenovo: Add ThinkCentre M700/M900 Tiny Heavily based on M710s documentation. Change-Id: I8c3860ba6254919769082c9ed749f8bb287a5f5e Signed-off-by: Michał Kopeć <michal.kopec(a)3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/87044 Reviewed-by: Nicholas Chin <nic.c3.14(a)gmail.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M Documentation/mainboard/index.md A Documentation/mainboard/lenovo/thinkcentre_m900_tiny.md A Documentation/mainboard/lenovo/thinkcentre_m900_tiny_spi_location.jpg 3 files changed, 89 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Nicholas Chin: Looks good to me, approved diff --git a/Documentation/mainboard/index.md b/Documentation/mainboard/index.md index 870f0c6..c66b119 100644 --- a/Documentation/mainboard/index.md +++ b/Documentation/mainboard/index.md @@ -186,6 +186,7 @@ Hardware Maintenance Manual of ThinkPads <lenovo/thinkpad_hmm.md> R60 <lenovo/r60.md> ThinkCentre M710s <lenovo/thinkcentre_m710s.md> +ThinkCentre M700 / M900 Tiny <lenovo/thinkcentre_m900_tiny.md> T4xx common <lenovo/t4xx_series.md> X2xx common <lenovo/x2xx_series.md> M920 Tiny <lenovo/m920q.md> diff --git a/Documentation/mainboard/lenovo/thinkcentre_m900_tiny.md b/Documentation/mainboard/lenovo/thinkcentre_m900_tiny.md new file mode 100644 index 0000000..7c9f41c --- /dev/null +++ b/Documentation/mainboard/lenovo/thinkcentre_m900_tiny.md @@ -0,0 +1,88 @@ +# Lenovo ThinkCentre M700 / M900 Tiny + +This page provides technical documentation on [Lenovo ThinkCentre M700 / M900 Tiny]. + +M700 Tiny and M900 Tiny are twin designs using the same exact mainboard, with +the following differences: + +```{eval-rst} ++------------------------+------+------+ +| Feature | M700 | M900 | ++========================+======+======+ +| Chipset | B150 | Q170 | ++------------------------+------+------+ +| Intel AMT | No | Yes | ++------------------------+------+------+ +| Intel TXT | No | Yes | ++------------------------+------+------+ +| PCIe lanes in M.2 slot | No | Yes | ++------------------------+------+------+ +``` + +## Flash chip + +```{eval-rst} ++----------+--------------------------+ +| Type | Value | ++==========+==========================+ +| Socketed | no | ++----------+--------------------------+ +| Model | W25Q128.V or MX25L12873F | ++----------+--------------------------+ +| Size | 16MiB | ++----------+--------------------------+ +| Package | SOIC-8 | ++----------+--------------------------+ +``` + +The flash chip is divided into the following regions. + + 00000000:00000fff fd + 00001000:00002fff gbe + 00003000:007fffff me + 00800000:00ffffff bios + +## Flashing + +The flash chip cannot be flashed internally when running vendor firmware, and must +be flashed externally using a programmer of your choice. + +Steps on how to open the chassis and get access to the mainboard are described +in the [hardware maintenance manual]. Follow the steps shown from +"[Removing the computer cover]" until "[Replacing the M.2 storage drive]". + +The SPI flash should be easy to identify and the location is shown in the image +below. See the [datasheet] and [flashing firmware tutorial] for more information. + +![](thinkcentre_m900_tiny_spi_location.jpg) + +## Status + +### Working + + * Debian 12 (Linux 6.1.0) using MrChromebox' EDK II fork (uefipayload_2502) + * M.2 SATA + NVMe slot + * M.2 Wi-Fi slot + * Display ports + * USB + * Audio + * LAN + * CPU fan + * Discrete TPM 1.2 + * Internal flashing (from coreboot) + * COM1 header + * DisplayPort header + * Power LED + * S3 Suspend + +### Untested + + * PS/2 header + * PCIe + SATA "2L" expansion header + +[Lenovo ThinkCentre M700 / M900 Tiny]: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCentre_M900_Tiny/… +[hardware maintenance manual]: https://download.lenovo.com/pccbbs/thinkcentre_pdf/m700_m900_m900x_tiny_hmm… +[Removing the computer cover]: https://download.lenovo.com/pccbbs/thinkcentre_pdf/m700_m900_m900x_tiny_hmm… +[Replacing the M.2 storage drive]: https://download.lenovo.com/pccbbs/thinkcentre_pdf/m700_m900_m900x_tiny_hmm… +[datasheet]: https://www.mouser.com/datasheet/2/949/w25q128jv_revf_03272018_plus-1489608… +[flashing firmware tutorial]: ../../tutorial/flashing_firmware/index.md diff --git a/Documentation/mainboard/lenovo/thinkcentre_m900_tiny_spi_location.jpg b/Documentation/mainboard/lenovo/thinkcentre_m900_tiny_spi_location.jpg new file mode 100644 index 0000000..65fdaaa --- /dev/null +++ b/Documentation/mainboard/lenovo/thinkcentre_m900_tiny_spi_location.jpg Binary files differ -- To view, visit https://review.coreboot.org/c/coreboot/+/87044?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I8c3860ba6254919769082c9ed749f8bb287a5f5e Gerrit-Change-Number: 87044 Gerrit-PatchSet: 5 Gerrit-Owner: Michał Kopeć <michal.kopec(a)3mdeb.com> Gerrit-Reviewer: Krystian Hebel <krystian.hebel(a)3mdeb.com> Gerrit-Reviewer: Maciej Pijanowski <maciej.pijanowski(a)3mdeb.com> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Nicholas Chin <nic.c3.14(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[S] Change in coreboot[main]: soc/mediatek/common: Move DRAMC function declarations to common header
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87209?usp=email ) Change subject: soc/mediatek/common: Move DRAMC function declarations to common header ...................................................................... soc/mediatek/common: Move DRAMC function declarations to common header To promote code reuse and maintainability, this commit moves the DRAMC parameter function declarations to the common folder. BUG=b:379008996 BRANCH=none TEST=build passed Signed-off-by: Vince Liu <vince-wl.liu(a)mediatek.corp-partner.google.com> Change-Id: Iab24f07b4c02da22779ea1c76f3237c144d92b98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/87209 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Yidi Lin <yidilin(a)google.com> --- M src/soc/mediatek/common/include/soc/dramc_param_common.h M src/soc/mediatek/mt8186/include/soc/dramc_param.h M src/soc/mediatek/mt8188/include/soc/dramc_param.h M src/soc/mediatek/mt8192/include/soc/dramc_param.h M src/soc/mediatek/mt8195/include/soc/dramc_param.h M src/soc/mediatek/mt8196/include/soc/dramc_param.h 6 files changed, 5 insertions(+), 26 deletions(-) Approvals: Yidi Lin: Looks good to me, approved build bot (Jenkins): Verified diff --git a/src/soc/mediatek/common/include/soc/dramc_param_common.h b/src/soc/mediatek/common/include/soc/dramc_param_common.h index a1fac9a..f7cf83a 100644 --- a/src/soc/mediatek/common/include/soc/dramc_param_common.h +++ b/src/soc/mediatek/common/include/soc/dramc_param_common.h @@ -103,5 +103,10 @@ }; const struct sdram_info *get_sdram_config(void); +struct dramc_param *get_dramc_param_from_blob(void *blob); +void dump_param_header(const void *blob); +int validate_dramc_param(const void *blob); +int is_valid_dramc_param(const void *blob); +int initialize_dramc_param(void *blob); #endif diff --git a/src/soc/mediatek/mt8186/include/soc/dramc_param.h b/src/soc/mediatek/mt8186/include/soc/dramc_param.h index 29380c2..773d6af 100644 --- a/src/soc/mediatek/mt8186/include/soc/dramc_param.h +++ b/src/soc/mediatek/mt8186/include/soc/dramc_param.h @@ -78,8 +78,4 @@ struct dramc_data dramc_datas; }; -struct dramc_param *get_dramc_param_from_blob(void *blob); -void dump_param_header(const void *blob); -int initialize_dramc_param(void *blob); - #endif /* __SOC_MEDIATEK_MT8186_DRAMC_PARAM_H__ */ diff --git a/src/soc/mediatek/mt8188/include/soc/dramc_param.h b/src/soc/mediatek/mt8188/include/soc/dramc_param.h index 740e27b..58241f4 100644 --- a/src/soc/mediatek/mt8188/include/soc/dramc_param.h +++ b/src/soc/mediatek/mt8188/include/soc/dramc_param.h @@ -98,10 +98,4 @@ struct dramc_data dramc_datas; }; -struct dramc_param *get_dramc_param_from_blob(void *blob); -void dump_param_header(const void *blob); -int validate_dramc_param(const void *blob); -int is_valid_dramc_param(const void *blob); -int initialize_dramc_param(void *blob); - #endif /* __SOC_MEDIATEK_MT8188_DRAMC_PARAM_H__ */ diff --git a/src/soc/mediatek/mt8192/include/soc/dramc_param.h b/src/soc/mediatek/mt8192/include/soc/dramc_param.h index fca82be..b0f9f45 100644 --- a/src/soc/mediatek/mt8192/include/soc/dramc_param.h +++ b/src/soc/mediatek/mt8192/include/soc/dramc_param.h @@ -73,9 +73,4 @@ struct dramc_data dramc_datas; }; -struct dramc_param *get_dramc_param_from_blob(void *blob); -void dump_param_header(const void *blob); -int validate_dramc_param(const void *blob); -int is_valid_dramc_param(const void *blob); -int initialize_dramc_param(void *blob); #endif /* __SOC_MEDIATEK_MT8192_DRAMC_PARAM_H__ */ diff --git a/src/soc/mediatek/mt8195/include/soc/dramc_param.h b/src/soc/mediatek/mt8195/include/soc/dramc_param.h index 0885ee0..3ca7d81 100644 --- a/src/soc/mediatek/mt8195/include/soc/dramc_param.h +++ b/src/soc/mediatek/mt8195/include/soc/dramc_param.h @@ -73,9 +73,4 @@ struct dramc_data dramc_datas; }; -struct dramc_param *get_dramc_param_from_blob(void *blob); -void dump_param_header(const void *blob); -int validate_dramc_param(const void *blob); -int is_valid_dramc_param(const void *blob); -int initialize_dramc_param(void *blob); #endif /* __SOC_MEDIATEK_MT8195_DRAMC_PARAM_H__ */ diff --git a/src/soc/mediatek/mt8196/include/soc/dramc_param.h b/src/soc/mediatek/mt8196/include/soc/dramc_param.h index 13a4dff..819b1af 100644 --- a/src/soc/mediatek/mt8196/include/soc/dramc_param.h +++ b/src/soc/mediatek/mt8196/include/soc/dramc_param.h @@ -105,10 +105,4 @@ struct dramc_data dramc_datas; }; -struct dramc_param *get_dramc_param_from_blob(void *blob); -void dump_param_header(const void *blob); -int validate_dramc_param(const void *blob); -int is_valid_dramc_param(const void *blob); -int initialize_dramc_param(void *blob); - #endif /* __SOC_MEDIATEK_MT8196_DRAMC_PARAM_H__ */ -- To view, visit https://review.coreboot.org/c/coreboot/+/87209?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: Iab24f07b4c02da22779ea1c76f3237c144d92b98 Gerrit-Change-Number: 87209 Gerrit-PatchSet: 2 Gerrit-Owner: Vince Liu <vince-wl.liu(a)mediatek.com> Gerrit-Reviewer: Hung-Te Lin <hungte(a)chromium.org> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Xi Chen <xixi.chen(a)mediatek.com> Gerrit-Reviewer: Yidi Lin <yidilin(a)google.com> Gerrit-Reviewer: Yu-Ping Wu <yupingso(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[S] Change in coreboot[main]: soc/mediatek/mt8196: Move TX TRACKING from MT8196 to common folder
by Matt DeVillier (Code Review) 09 Apr '25

09 Apr '25

Matt DeVillier has submitted this change. ( https://review.coreboot.org/c/coreboot/+/87036?usp=email ) ( 2 is the latest approved patch-set. No files were changed between the latest approved patch-set and the submitted one. )Change subject: soc/mediatek/mt8196: Move TX TRACKING from MT8196 to common folder ...................................................................... soc/mediatek/mt8196: Move TX TRACKING from MT8196 to common folder The configuration method of the reserved DRAM buffer used for HW TX TRACING on MT8196 is also applicable to other SoCs, such as MT8189. To facilitate reuse, we move the relevant files to the common directory. BUG=b:379008996 BRANCH=none TEST=Reserve memory ok Firmware shows the following log with 12GB DDR board: 00000001ffff0000-00000001ffffffff: RESERVED 000000037fff0000-000000037fffffff: RESERVED Change-Id: I3fdd9d2f7ab1bbdcc097510556929da2134f7d95 Signed-off-by: Mike Lin <mike.lin(a)mediatek.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/87036 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Yidi Lin <yidilin(a)google.com> --- R src/soc/mediatek/common/dramc_info.c A src/soc/mediatek/common/include/soc/dramc_info.h M src/soc/mediatek/mt8196/Makefile.mk D src/soc/mediatek/mt8196/include/soc/dramc_info.h 4 files changed, 9 insertions(+), 9 deletions(-) Approvals: build bot (Jenkins): Verified Yidi Lin: Looks good to me, approved diff --git a/src/soc/mediatek/mt8196/dramc_info.c b/src/soc/mediatek/common/dramc_info.c similarity index 100% rename from src/soc/mediatek/mt8196/dramc_info.c rename to src/soc/mediatek/common/dramc_info.c diff --git a/src/soc/mediatek/common/include/soc/dramc_info.h b/src/soc/mediatek/common/include/soc/dramc_info.h new file mode 100644 index 0000000..a0be640 --- /dev/null +++ b/src/soc/mediatek/common/include/soc/dramc_info.h @@ -0,0 +1,8 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __SOC_MEDIATEK_COMMON_DRAMC_INFO_H__ +#define __SOC_MEDIATEK_COMMON_DRAMC_INFO_H__ + +void reserve_buffer_for_dramc(void); + +#endif /* __SOC_MEDIATEK_COMMON_DRAMC_INFO_H__ */ diff --git a/src/soc/mediatek/mt8196/Makefile.mk b/src/soc/mediatek/mt8196/Makefile.mk index 1793104..fa0e3fe 100644 --- a/src/soc/mediatek/mt8196/Makefile.mk +++ b/src/soc/mediatek/mt8196/Makefile.mk @@ -60,7 +60,7 @@ ramstage-y += ../common/dpm_v2.c ramstage-y += ../common/dp/dptx_common.c ../common/dp/dptx_hal_common.c ramstage-y += dptx.c dptx_hal.c dp_intf.c -ramstage-y += dramc_info.c +ramstage-y += ../common/dramc_info.c ramstage-y += ../common/early_init.c ramstage-y += ../common/emi.c ramstage-y += gpueb.c diff --git a/src/soc/mediatek/mt8196/include/soc/dramc_info.h b/src/soc/mediatek/mt8196/include/soc/dramc_info.h deleted file mode 100644 index ccc7ff9..0000000 --- a/src/soc/mediatek/mt8196/include/soc/dramc_info.h +++ /dev/null @@ -1,8 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ - -#ifndef __SOC_MEDIATEK_MT8196_DRAMC_INFO_H__ -#define __SOC_MEDIATEK_MT8196_DRAMC_INFO_H__ - -void reserve_buffer_for_dramc(void); - -#endif /* __SOC_MEDIATEK_MT8196_DRAMC_INFO_H__ */ -- To view, visit https://review.coreboot.org/c/coreboot/+/87036?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: I3fdd9d2f7ab1bbdcc097510556929da2134f7d95 Gerrit-Change-Number: 87036 Gerrit-PatchSet: 4 Gerrit-Owner: Vince Liu <vince-wl.liu(a)mediatek.com> Gerrit-Reviewer: Hung-Te Lin <hungte(a)chromium.org> Gerrit-Reviewer: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-Reviewer: Yidi Lin <yidilin(a)google.com> Gerrit-Reviewer: Yu-Ping Wu <yupingso(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit April 2025