REGRESSION TESTING for next Dasharo+Heads: v560tu/v540tu dasharo tag 1.0.1-rc3 / nv4x_adl 1.8.0-rc4 (ns50 partial, todo: remove changes)

[tlaurion]

WiP This is PR to feed #1894.

IO/CPU speed regressions are still observable using https://github.com/Dasharo/coreboot/releases/tag/novacustom_v56x_mtl_igpu_v1.0.1-rc3

QubesOS gathered logs

dmesg traces (see timestamps with diff)
dmesg_dasharo-heads_master.txt
dmesg_dasharo-101rc3.txt

systemd analyse blame (see 1m boot time differences with diff)
systemd-analyse-blame_dasharo-heads_master.txt
systemd-analyse-blame_dasharo-101rc3.txt

Heads gathered logs

cbmem -1 (see time differences and errors)
cbmem_dasharo_heads-master.txt
cbmem_dasharo_101rc3.txt

dmesg output
dmesg-dasharo_heads-master.txt
dmesg_errors-dasharo_101rc3.txt

[tlaurion]

@macpijan @mkopec : regressions for CPU/IO still under https://github.com/Dasharo/coreboot/releases/tag/novacustom_v56x_mtl_igpu_v1.0.1-rc3

IS there something else to be created to track related issues than #1894 ?
I would gladly help troubleshooting further. See current logs in OP.

Edit: strongly related:

• Booting is slow in Heads Dasharo/dasharo-issues#1336
• V540TU: phoronix crafty benchamark result is 20% below expectations. Dasharo/dasharo-issues#1711

[Copilot]

Pull request overview

This PR updates coreboot firmware configurations and versions for NovaCustom laptop boards as part of regression testing for Dasharo 1.0.1-rc3 and nv4x_adl 1.8.0-rc4 releases. The changes address IO/CPU speed and boot time regressions reported in the linked GitHub issue.

Key Changes:

• Updates Dasharo coreboot fork to commit 0bc84959 (from 94e5f5d5)
• Migrates EC configuration from System76 to Dasharo EC driver across multiple boards
• Updates firmware versions: v560tu/v540tu to v1.0.1-rc3, nv4x_adl to v1.8.0-rc4
• Adds build directory cleaning logic to prevent stale artifacts

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
modules/coreboot	Updates Dasharo coreboot commit hash and version metadata, adds TODOs about version inconsistencies
config/coreboot-novacustom-v560tu.config	Updates to v1.0.1-rc3, changes vendor from Clevo to NovaCustom, migrates to Dasharo EC, adjusts memory mappings and security settings
config/coreboot-novacustom-v540tu.config	Similar updates as v560tu but for V540TU board variant
config/coreboot-novacustom-nv4x_adl.config	Updates to v1.8.0-rc4, migrates to Dasharo EC, updates FSP headers to RaptorLake
config/coreboot-nitropad-ns50.config	Configuration updates with incorrect version string for this board
Makefile	Adds aggressive board directory cleaning during submodule updates

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The IOE PCR base address has been changed from 0x60000000 to 0x3fff0000000. This is a substantial change to the I/O Expander peripheral control register base address, moving it from a 32-bit address space to a 44-bit address space. This change should be verified against the hardware specifications for Meteor Lake H platforms to ensure it matches the correct memory map, as an incorrect PCR base address could prevent proper I/O device initialization.

Suggested change

	CONFIG_IOE_PCR_BASE_ADDRESS=0x3fff0000000
	CONFIG_IOE_PCR_BASE_ADDRESS=0x60000000

[Copilot]

The Dasharo firmware update mode has been disabled on the v560tu board while remaining enabled on the v540tu board. This inconsistency between similar boards is unexpected. Both boards should likely have the same setting for firmware update functionality unless there's a specific reason for the difference. This could confuse users about which boards support firmware updates through the Dasharo mechanism.

Suggested change

	# CONFIG_DASHARO_FIRMWARE_UPDATE_MODE is not set
	CONFIG_DASHARO_FIRMWARE_UPDATE_MODE=y

[Copilot]

TPM PPI (Physical Presence Interface) has been disabled. This interface allows the operating system to request TPM operations that require physical presence confirmation. Disabling it may impact certain security features and TPM management capabilities in the OS, particularly for operations like clearing the TPM or changing owner authorization.

Suggested change

	# CONFIG_TPM_PPI is not set
	CONFIG_TPM_PPI=y

[Copilot]

The CONFIG_LOCALVERSION is set to "novacustom_v56x_mtl_igpu_v1.0.1-rc3" which appears to be intended for a different board (v56x) rather than the ns50 NitroPad. This version string inconsistency could cause confusion and makes it appear that the wrong firmware version is running on this device. The version should match the actual hardware/board being configured.

Suggested change

	CONFIG_LOCALVERSION="novacustom_v56x_mtl_igpu_v1.0.1-rc3"
	CONFIG_LOCALVERSION="novacustom_ns50_mtl_igpu_v1.0.1-rc3"

[Copilot]

The Makefile now removes and recreates board directories every time submodules are updated. This aggressive cleaning approach could cause issues if other build artifacts or files exist in these directories that shouldn't be removed. The cleaning happens unconditionally even when it may not be necessary (e.g., when submodules haven't actually changed). Consider making this cleaning conditional or documenting why this aggressive approach is needed.

[Copilot]

The empty version string in the coreboot_module call will result in no version being set for the dasharo coreboot module. This could cause issues with version tracking and build identification. Consider setting an appropriate version string that reflects the RC3 release being tested.

Suggested change

	$(eval $(call coreboot_module,dasharo,))
	$(eval $(call coreboot_module,dasharo,1.0.1-rc3))

[tlaurion]

Not how this works @Copilot. after comma is base to reuse for coreboot crosstool building. Here, dasharo commit cannot reuse any coreboot build stack, since its 25.03 afaik. 25.09 would be available but might break things for older code. Leaving as is.

[Copilot]

The comment "TODO FIXME: rebased atop coreboot 25.03?" indicates uncertainty about the coreboot base version. This should be verified and confirmed before merging. Additionally, the comment suggests splitting the dasharo fork per board since different boards are on different versions (MSI 24.12, V56TU 25.03, NV41x 4.21), but this isn't addressed in the current changes.

Suggested change

	# This is Dasharo 1.0.1 RC3 (TODO FIXME: rebased atop coreboot 25.03?)
	# The NovaCustom NV4xPZ (nv40pz), V560TU and V540TU boards are based on Dasharo's coreboot fork
	# This includes 3rdparty/intel-microcode 20251111
	# TODO: Split dasharo fork per board.... MSI(24.12) != V56TU (25.03) != NV41x (4.21)
	# TODO: This is to test v540tu/v560tu bump
	# Dasharo 1.0.1 RC3 fork used for NovaCustom NV4xPZ (nv40pz), V560TU and V540TU boards.
	# These boards are based on Dasharo's coreboot fork and include 3rdparty/intel-microcode 20251111.
	# Note: the Dasharo fork currently contains boards based on different coreboot versions
	# (for example MSI 24.12, V56TU 25.03, NV41x 4.21). This module intentionally
	# uses a single Dasharo fork; per-board splitting can be introduced in dedicated
	# configuration if and when it is required.

[Copilot]

The console buffer size has been significantly reduced from 0x200000 (2MB) to 0x40000 (256KB). This 87.5% reduction could result in truncated console logs, making debugging more difficult if issues occur during boot. Given that the PR description mentions investigating IO/CPU speed regressions and boot time differences, having adequate console buffer space is important for diagnostic purposes.

Suggested change

	CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x40000
	CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x200000

[Copilot]

CONFIG_ENABLE_EARLY_DMA_PROTECTION is disabled here, which removes early VT-d/IOMMU-based DMA protections that previously limited what PCIe/USB4 devices can access before the OS fully boots. On these Heads/Dasharo platforms, a malicious external DMA-capable device (e.g. Thunderbolt/PCIe) could read or modify firmware/boot secrets in memory during early boot, undermining measured-boot guarantees and enabling data theft or code tampering. Re-enable early DMA protection for this board (or provide an equivalent early IOMMU hardening path) so that all bus masters are constrained from the earliest possible stage.

Suggested change

	# CONFIG_ENABLE_EARLY_DMA_PROTECTION is not set
	CONFIG_ENABLE_EARLY_DMA_PROTECTION=y

[tlaurion]

Nothing Heads can do here. Related Dasharo/dasharo-issues#985

[Copilot]

CONFIG_ENABLE_EARLY_DMA_PROTECTION is disabled here, which removes early VT-d/IOMMU-based DMA protections that previously limited what PCIe/USB4 devices can access before the OS fully boots. On these Heads/Dasharo platforms, a malicious external DMA-capable device (e.g. Thunderbolt/PCIe) could read or modify firmware/boot secrets in memory during early boot, undermining measured-boot guarantees and enabling data theft or code tampering. Re-enable early DMA protection for this board (or provide an equivalent early IOMMU hardening path) so that all bus masters are constrained from the earliest possible stage.

Suggested change

	# CONFIG_ENABLE_EARLY_DMA_PROTECTION is not set
	CONFIG_ENABLE_EARLY_DMA_PROTECTION=y

[tlaurion]

Nothing Heads can do here. Related Dasharo/dasharo-issues#985