REGRESSION TESTING for next Dasharo+Heads: v560tu/v540tu dasharo tag 1.0.1, have all Dasharo coreboot based boards use their own tags by tlaurion · Pull Request #2039 · linuxboot/heads

tlaurion · 2026-01-04T22:40:37Z

WiP input for #2062

OLD

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 · 2026-01-04T22:44:30Z

@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:

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 · 2026-01-04T22:44:55Z

config/coreboot-novacustom-v560tu.config

 CONFIG_METEORLAKE_CAR_ENHANCED_NEM=y
 CONFIG_CPU_MAX_TEMPERATURE=110
-CONFIG_IOE_PCR_BASE_ADDRESS=0x60000000
+CONFIG_IOE_PCR_BASE_ADDRESS=0x3fff0000000


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 · 2026-01-04T22:44:55Z

config/coreboot-novacustom-v560tu.config

 #
 CONFIG_DASHARO_PREFER_S3_SLEEP=y
-CONFIG_DASHARO_FIRMWARE_UPDATE_MODE=y
+# CONFIG_DASHARO_FIRMWARE_UPDATE_MODE is not set


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 · 2026-01-04T22:44:56Z

config/coreboot-novacustom-v560tu.config

 # CONFIG_SPI_FLASH_NO_FAST_READ is not set
 CONFIG_TPM_INIT_RAMSTAGE=y
-CONFIG_TPM_PPI=y
+# CONFIG_TPM_PPI is not set


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 · 2026-01-04T22:44:56Z

config/coreboot-nitropad-ns50.config

 #
-CONFIG_COREBOOT_BUILD=y
-CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION="novacustom_v56x_mtl_igpu_v1.0.1-rc3"


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 · 2026-01-04T22:44:56Z

Makefile

+		echo "INFO: Cleaning board-specific build directories to prevent stale artifacts" && \
+		rm -rf "$(build)/$(BOARD)" "$(build)/$($1_base_dir)/$(BOARD)" && \
+		echo "INFO: Recreating board directories" && \
+		mkdir -p "$(build)/$(BOARD)" "$(build)/$($1_base_dir)/$(BOARD)" && \


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 · 2026-01-04T22:44:57Z

modules/coreboot

-coreboot-dasharo_commit_hash := 94e5f5d5b808cf8d8fd5c70d4ef6a08a054f8986
-$(eval $(call coreboot_module,dasharo,24.02.01))
+coreboot-dasharo_commit_hash := 0bc84959aa7f731fa4b666e320ace20889a6af7a
+$(eval $(call coreboot_module,dasharo,))


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))

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 · 2026-01-04T22:44:57Z

modules/coreboot

+# 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


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 · 2026-01-04T22:44:57Z

config/coreboot-novacustom-v560tu.config

 CONFIG_GBE_BIN_PATH="3rdparty/dasharo-blobs/novacustom/v5x0tu/gbe.bin"
-CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x200000
-CONFIG_PCIEXP_DEFAULT_MAX_RESIZABLE_BAR_BITS=36
+CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x40000


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 · 2026-01-04T22:44:57Z

config/coreboot-novacustom-v540tu.config

+# CONFIG_SOFTWARE_CONNECTION_MANAGER is not set
 CONFIG_SOC_INTEL_COMMON_BLOCK_VTD=y
-CONFIG_ENABLE_EARLY_DMA_PROTECTION=y
+# CONFIG_ENABLE_EARLY_DMA_PROTECTION is not set


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

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

Copilot · 2026-01-04T22:44:58Z

config/coreboot-novacustom-v560tu.config

+# CONFIG_SOFTWARE_CONNECTION_MANAGER is not set
 CONFIG_SOC_INTEL_COMMON_BLOCK_VTD=y
-CONFIG_ENABLE_EARLY_DMA_PROTECTION=y
+# CONFIG_ENABLE_EARLY_DMA_PROTECTION is not set


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

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

mkopec · 2026-02-12T15:17:10Z

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

Hi @tlaurion , I've finally had the time to take a look at this. I did find a performance issue on battery power where the CPU gets just half of the nominal performance in single threaded benchmarks. It seems to depend on the power preference set in Windows, so definitely Pstate / Energy Performance Preference related. But performance on AC power is nominal, same as other devices with 155H. Does that match your experience? or are you having different performance issues?

tlaurion · 2026-02-12T17:13:51Z

@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](https://github.com/Dasharo/dasharo-issues/issues/1336)

* [V540TU: phoronix crafty benchmark result is 20% below expectations. Dasharo/dasharo-issues#1711](https://github.com/Dasharo/dasharo-issues/issues/1711)

@mkopec UX is a general slowdown with this PR vs last coreboot+heads release.

With firmware flashed being the only difference:

systemd analyse blame show big increase in boot time of each qubes
GUI slowed
each snapshot rotation takes way longer
compilation time takes longer

cpu/gpu/io perf is slower generally.
You said elsewhere that NUC fixes impacted 540tu/560tu and needed to be separated.

Let's do this inversely: tell me what tets you want me to run on last coreboot+heads release (dasharo coreboot commit 94e5f5d5b808cf8d8fd5c70d4ef6a08a054f8986) against which commit and I can provide results for your specified tests?

tlaurion · 2026-02-16T17:01:46Z

@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](https://github.com/Dasharo/dasharo-issues/issues/1336)

* [V540TU: phoronix crafty benchmark result is 20% below expectations. Dasharo/dasharo-issues#1711](https://github.com/Dasharo/dasharo-issues/issues/1711)
@mkopec UX is a general slowdown with this PR vs last coreboot+heads release.

With firmware flashed being the only difference:

systemd analyse blame show big increase in boot time of each qubes

GUI slowed

each snapshot rotation takes way longer

compilation time takes longer

cpu/gpu/io perf is slower generally.
You said elsewhere that NUC fixes impacted 540tu/560tu and needed to be separated.

Let's do this inversely: tell me what tets you want me to run on last coreboot+heads release (dasharo coreboot commit 94e5f5d5b808cf8d8fd5c70d4ef6a08a054f8986) against which commit and I can provide results for your specified tests?

@mkopec : geek bench test results?

EDIT: i'll swap my debian-13 image i'm currently using for kvm support (way faster, damn should have done that years ago) and post last dasharo-coreboot commit results to geek banch to compare to actual https://browser.geekbench.com/v6/cpu/compare/13177143?baseline=16611470

tlaurion · 2026-02-16T17:50:34Z

@mkopec 30f005e is current Pr simply bumping earlier dasharo-coreboot 1.0.1 rc3 to 1.0.1 release.

Building locally, will flash and post results of v560tu against itself with commit 30f005e

tlaurion · 2026-02-16T18:49:56Z

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

Hi @tlaurion , I've finally had the time to take a look at this. I did find a performance issue on battery power where the CPU gets just half of the nominal performance in single threaded benchmarks. It seems to depend on the power preference set in Windows, so definitely Pstate / Energy Performance Preference related. But performance on AC power is nominal, same as other devices with 155H. Does that match your experience? or are you having different performance issues?

@mkopec 30f005e is current Pr simply bumping earlier dasharo-coreboot 1.0.1 rc3 to 1.0.1 release.

Building locally, will flash and post results of v560tu against itself with commit 30f005e

@mkopec There is no doubt about perf regression between coreboot dasharo 94e5f5d5b808cf8d8fd5c70d4ef6a08a054f8986 (coreboot-heads : same as master, same as last coreboot+heads Dasharo release) and 6de027d1f0a62753182237ce3d793e5ba0395139 (this pr coreboot commit for 1.0.1 mtl igpu) see modules/coreboot changes) as can be seen with geek bench results (-50% single core perf drop, -25% multi core perf drop, on AC not battery).

https://browser.geekbench.com/v6/cpu/compare/16612414?baseline=16611470

1.0.1 coreboot base : https://browser.geekbench.com/v6/cpu/16612414
0.9.0 coreboot base https://browser.geekbench.com/v6/cpu/16611470

CC @macpijan @pietrushnic

If you need more testing let me know; but this PR shows problems with defconfig that were true on 1.0.1 rc3 and I didn't see any changes. If you want to early collaborate on this, let me know how and what you need me to test and with what.

CircleCI built artifacts to flash directly from 30f005e

mkopec · 2026-02-17T09:28:04Z

@tlaurion I did find something in the v1.0.1 code: Dasharo/dasharo-issues#1711

It seems that the default Pstate EPP value set by Linux is too high, resulting in reduced performance. To work around this I was able to simply switch the power profile to performance in GNOME settings. A fix for the default value has been merged: Dasharo/coreboot#847 but there is still some weirdness in the linux driver about how it applies the default setting (Dasharo/coreboot#847 (comment))

If you're not on GNOME, you can also switch the profile using powerprofilesctl. Please check if switching to performance mode fixes the issue. If not, then we'll need to look elsewhere

tlaurion · 2026-02-17T13:06:56Z

@tlaurion I did find something in the v1.0.1 code: Dasharo/dasharo-issues#1711

It seems that the default Pstate EPP value set by Linux is too high, resulting in reduced performance. To work around this I was able to simply switch the power profile to performance in GNOME settings. A fix for the default value has been merged: Dasharo/coreboot#847 but there is still some weirdness in the linux driver about how it applies the default setting (Dasharo/coreboot#847 (comment))

If you're not on GNOME, you can also switch the profile using powerprofilesctl. Please check if switching to performance mode fixes the issue. If not, then we'll need to look elsewhere

That was under KDE with slider set to performance but not move upon boot.

I'll do another rounds of testing switching to given commit and test with powerprofilesctl

…g (Improve performance by lowering the EPP value from the power-on default of 0xb3 (70%) to 0x73 (45%). Lower value = higher performance.) Test fix for Dasharo/dasharo-issues#1711 related: - linuxboot#2039 - Dasharo/dasharo-issues#1711 - linuxboot#1894 Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion · 2026-02-17T14:09:10Z

@mkopec

@tlaurion I did find something in the v1.0.1 code: Dasharo/dasharo-issues#1711
It seems that the default Pstate EPP value set by Linux is too high, resulting in reduced performance. To work around this I was able to simply switch the power profile to performance in GNOME settings. A fix for the default value has been merged: Dasharo/coreboot#847 but there is still some weirdness in the linux driver about how it applies the default setting (Dasharo/coreboot#847 (comment))
If you're not on GNOME, you can also switch the profile using powerprofilesctl. Please check if switching to performance mode fixes the issue. If not, then we'll need to look elsewhere

That was under KDE with slider set to performance but not move upon boot.

I'll do another rounds of testing switching to given commit and test with powerprofilesctl

on https://output.circle-artifacts.com/output/job/21e05e10-91f3-4254-bf44-3ed260bff982/artifacts/0/build/x86/novacustom-v560tu/heads-novacustom-v560tu-v0.2.1-2931-g30f005e.zip (so 30f005e):


user@debian-13:~/heads$ powerprofilesctl 
* performance:
    CpuDriver:  intel_pstate
    Degraded:   no

  balanced:
    CpuDriver:  intel_pstate
    PlatformDriver:     placeholder

  power-saver:
    CpuDriver:  intel_pstate
    PlatformDriver:     placeholder

debian-13 boots into performance mode by default, no mod: it was like this.

tlaurion · 2026-02-17T14:10:09Z

@mkopec 0f7247d includes Dasharo/coreboot#847 i'll test in a bit

tlaurion · 2026-02-17T15:23:29Z

@mkopec 0f7247d includes Dasharo/coreboot#847 i'll test in a bit

this is https://browser.geekbench.com/v6/cpu/16625300

* 0.9.0 coreboot base https://browser.geekbench.com/v6/cpu/16611470

Comparison: https://browser.geekbench.com/v6/cpu/compare/16625300?baseline=16611470

TLDR:

single core perf regression compared to 0.9 : - 59.1% (worse then last comparison)
multi core perf regression compared to 0.9: - 22.9% (better then last comparison)
conclusion: bug still present and on boot (kde):

user@debian-13:~/Downloads/Geekbench-6.5.0-Linux$ powerprofilesctl 
* performance:
    CpuDriver:  intel_pstate
    Degraded:   no

  balanced:
    CpuDriver:  intel_pstate
    PlatformDriver:     placeholder

  power-saver:
    CpuDriver:  intel_pstate
    PlatformDriver:     placeholder
user@debian-13:~/Downloads/Geekbench-6.5.0-Linux$ uname -a
Linux debian-13 6.12.69+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.69-1 (2026-02-08) x86_64 GNU/Linux
user@debian-13:~/Downloads/Geekbench-6.5.0-Linux$

@mkopec @macpijan @pietrushnic

Artifacts to test v540tu/v560tu from CircleCI from 0f7247d will be available in a bit.

Note: https://raw.githubusercontent.com/tlaurion/heads/0f7247d7e315135c16abac1c6d3a8e1ca781e711/config/coreboot-novacustom-v560tu.config has not been changed from changing defconfig -> oldconfig from past 1.0.1 rc3 tests of this PR, please advise is something wrong there (defconfig not right last time I checked, which is why I create this PR for Dasharo team to fix defconfig Kconfig base (top down not working and other things documented in commit logs). As discussed many times in the past; please provide config files expected to be tuned properly or have defconfig do the right thing, otherwise configs used from best knowledge/effort in this PR.

tlaurion · 2026-02-18T01:04:54Z

@mkopec from top of my head, I remember some things NUC related in last coreboot+Heads release needed to be removed. Don't remember the details.

mkopec · 2026-02-23T06:49:31Z

@tlaurion which EC version are you running currently? Could you try the latest from https://github.com/Dasharo/ec/commits/master/ ?

tlaurion · 2026-02-23T15:56:44Z

@tlaurion which EC version are you running currently? Could you try the latest from https://github.com/Dasharo/ec/commits/master/ ?

@mkopec Completely forgot about EC. Instructions to update seem to have vanished from https://docs.dasharo.com/variants/novacustom_ns5x_adl/releases/ , nv4x or v560tu as well, and Heads doesn't even report EC version under "System Information".

@mkopec can we work on building EC firmware with Heads and have EC flashed as part of coreboot internal update?

Otherwise, can you please give specific instructions to build for v540tu/v60tu/nv4x_adl?

tlaurion · 2026-02-23T16:05:14Z

@tlaurion which EC version are you running currently? Could you try the latest from https://github.com/Dasharo/ec/commits/master/ ?

@mkopec Completely forgot about EC. Instructions to update seem to have vanished from https://docs.dasharo.com/variants/novacustom_ns5x_adl/releases/ , nv4x or v560tu as well, and Heads doesn't even report EC version under "System Information".

@mkopec can we work on building EC firmware with Heads and have EC flashed as part of coreboot internal update?

Otherwise, can you please give specific instructions to build for v540tu/v60tu/nv4x_adl?

Found https://docs.dasharo.com/unified/novacustom/recovery/#ec-firmware-recovery

tlaurion · 2026-02-23T16:11:25Z

@mkopec opened issue #2056

tlaurion · 2026-02-23T18:41:49Z

@mkopec opened issue #2056

I added flake.nix requirements to successfully build EC in this PR, see #2056 (comment)

Let me know what are the envisioned next steps here and timeline of possible collaboration there.

tlaurion · 2026-02-25T13:23:35Z

@mkopec from top of my head, I remember some things NUC related in last coreboot+Heads release needed to be removed. Don't remember the details.

@mkopec that was your comment Dasharo/dasharo-issues#1336 (comment):

This will need a closer look. Maybe it'd be possible to make the MTRR changes conditional or board-dependent? That would make both the NUC BOX and laptops happy.

mkopec · 2026-02-26T13:02:47Z

@tlaurion did you manage to update the EC in the end? Did it affect performance after all?

Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com> Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Set CONFIG_LOCALVERSION in coreboot configs to match the Dasharo version tags for each fork: - dasharo_nv4x: v1.8.0 (novacustom-nv4x_adl, nitropad-ns50) - dasharo_msi_z790: v0.9.4 (msi_z790p_ddr4, msi_z790p_ddr5) - dasharo_msi_z690: v1.1.6 (msi_z690a_ddr4, msi_z690a_ddr5) Note: v56 boards (v540tu, v560tu) already had v1.0.1 set correctly. TODO: Investigate if Dasharo forks can share toolchains by using consistent FSP package headers (e.g. MemInfoHob.h, FirmwareVersionInfoHob.h) across forks, which would reduce build times significantly. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Auto-regenerated via 'make BOARD=X coreboot.modify_and_save_oldconfig_in_place': 1. Copies config to coreboot build directory 2. Runs 'make menuconfig' which regenerates config from Kconfig 3. Saves back to original config file This updates configs based on current coreboot source: - Adds new CONFIG_* options - Removes deprecated options - Reorders/standardizes options - Updates VENDOR_* toggles, EC renames (EC_SYSTEM76_EC_* -> EC_DASHARO_EC_*), FSP paths Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Split the original single save_cache job into per-architecture jobs to avoid cache path conflicts when workspaces from different architectures are combined. Changes: - Replace single save_cache job with save_cache_x86 and save_cache_ppc64 jobs - Each job attaches its respective workspace and saves arch-specific caches - Workflow updated: build_and_persist jobs -> save_cache_* -> dependent builds Workspaces combined: - save_cache_x86: x86-musl-cross-make, novacustom-nv4x_adl, librem_14, EOL_t480-hotp-maximized, EOL_librem_l1um, UNTESTED_msi_z690a_ddr4 - save_cache_ppc64: ppc64-musl-cross-make, UNTESTED_talos-2 Toolchain sharing (each Dasharo fork builds its own toolchain): - novacustom-nv4x_adl -> nitropad-ns50 (dasharo_nv4x) - novacustom-v560tu -> v540tu (dasharo_v56) - UNTESTED_msi_z690a_ddr4 -> msi_z690a_ddr5 (dasharo_msi_z690) - UNTESTED_msi_z790p_ddr4 -> msi_z790p_ddr5 (dasharo_msi_z790) - librem_14 -> all librem boards (24.02.01) 3-tier cache per architecture (only uploads if content changed): 1. musl-cross-make cache: if musl-cross-make modules changed 2. coreboot-musl-cross-make cache: if coreboot or patches changed 3. modules cache: if other modules changed Cache key naming convention: {name}-{arch} - musl-cross-make-x86, coreboot-musl-cross-make-x86, modules-x86 - musl-cross-make-ppc64, coreboot-musl-cross-make-ppc64, modules-ppc64 Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…ness Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Add missing common defaults: - CONFIG_ENABLE_EARLY_DMA_PROTECTION=y - CONFIG_SOC_INTEL_COMMON_SPI_LOCKDOWN_SMM=y - CONFIG_BOOTMEDIA_LOCK_CONTROLLER=y - CONFIG_VALIDATE_INTEL_DESCRIPTOR=y - CONFIG_SOFTWARE_CONNECTION_MANAGER=y - # CONFIG_INTEL_CHIPSET_LOCKDOWN is not set Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Save configs in defconfig format for cross-board comparisons. This removes explicit settings that match Kconfig defaults. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Removed lines matching defaults across all boards: - CONFIG_PCIEXP_DEFAULT_MAX_RESIZABLE_BAR_BITS=37 - CONFIG_INCLUDE_HSPHY_IN_FMAP - CONFIG_DEFAULT_CONSOLE_LOGLEVEL_0 - CONFIG_PCIEXP_HOTPLUG_* Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Outlier that matches default. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

These match defaults, not needed in defconfigs. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…gradeability Required for internal flashing with BOOTMEDIA_LOCK_CONTROLLER. NS50 (Nitrokey fork) changed SMBIOS strings requiring recovery console for forced internal flashing with mismatch. Ref: Nitrokey@374f9af Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Repro notes: for board in $(ls -d boards/*/ | sed 's|boards/||g' | sed 's|/$||g'); do ./docker_repro.sh make BOARD=$board coreboot.save_in_defconfig_format_in_place; done Real changes vs origin/master: git diff 061480d Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion · 2026-04-14T20:36:34Z

I would put all coreboot configs in defconfig, otherwise it makes it extremely difficult to compare features pair between boards.

See git diff origin/master and git diff 0d1402b to see what I mean.

Opinion @macpijan @SergiiDmytruk @filipleple ?

example here: msi had no localversion set, and important security features not configured in cc @Tonux599

\I left commit logs verbose so you can understand the process involved

Repro notes: for board in $(ls -d boards/*/ | sed 's|boards/||g' | sed 's|/$||g'); do ./docker_repro.sh make BOARD=$board coreboot.save_in_oldconfig_format_in_place; done Changes vs origin/master (061480d): IMPORTANT - MSI boards security additions: - CONFIG_ENABLE_EARLY_DMA_PROTECTION=y (was not set) - CONFIG_SOC_INTEL_COMMON_SPI_LOCKDOWN_SMM=y (new) - CONFIG_VALIDATE_INTEL_DESCRIPTOR=y (was not set) - CONFIG_BOOTMEDIA_LOCK_CONTROLLER=y (was BOOTMEDIA_LOCK_NONE) - CONFIG_BOOTMEDIA_LOCK_WHOLE_RO=y (new) - CONFIG_SPI_FLASH_SMM=y (new) Console/logging changes: - CONFIG_DEFAULT_CONSOLE_LOGLEVEL=7 (was 0) - CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=y (was not set) - CONFIG_CONSOLE_USE_ANSI_ESCAPES=y (was not set) - CONFIG_HWBASE_DEBUG_CB=y (was DEBUG_NULL) PCIe changes: - CONFIG_PCIEXP_DEFAULT_MAX_RESIZABLE_BAR_BITS=29 (was 37) NS50/NV4X changes: - CONFIG_MAINBOARD_VENDOR changes for internal upgradeability - CONFIG_LOCALVERSION aligned with Dasharo fork tags Signed-off-by: Thierry Laurion <insurgo@riseup.net>

SergiiDmytruk · 2026-04-14T22:23:00Z

Defconfigs are for sure easier to compare, but they too can hide some differences since many options are omitted and those which aren't control what other options are applicable. So neither form is ideal, but defconfigs are simpler to deal with. I wouldn't edit them in any way though or those edits would have to be applied again on the next update and kconfig should know better what options it needs in a defconfig anyway.

tlaurion · 2026-04-14T23:19:03Z

Defconfigs are for sure easier to compare, but they too can hide some differences since many options are omitted and those which aren't control what other options are applicable. So neither form is ideal, but defconfigs are simpler to deal with. I wouldn't edit them in any way though or those edits would have to be applied again on the next update and kconfig should know better what options it needs in a defconfig anyway.

Not sure I got your point @SergiiDmytruk. So like here in each version bump? Going back to save as defconfig with helper, remove overrides to default downstream should not control, and then save back to oldconfig with helper? Just to give output to fork maintainers of what's up for the next one year firmware freeze with lots of inconsistencies otherwise going completely dismissed? This process is flawed to say the least, and for downstream to catch discrepancies uncut upstream? Feature freeze is 2026-04 while tests again started 2026-04 while I tried to start this 2026-01.

How to improve so users are not Guinea pig and I'm not responsible to find all discrepancies before release? We discussed this https://youtu.be/mAb_kHrF6SQ?list=PLuISieMwVBpL5S7kPUHKenoFj_YJ8Y0_d

Copilot AI review requested due to automatic review settings January 4, 2026 22:40

tlaurion marked this pull request as draft January 4, 2026 22:40

Copilot started reviewing on behalf of tlaurion January 4, 2026 22:41 View session

Copilot AI reviewed Jan 4, 2026

View reviewed changes

tlaurion mentioned this pull request Feb 16, 2026

v560tu/v540tu seems slow on IO, needs confirmation #1894

Closed

tlaurion mentioned this pull request Feb 23, 2026

Support building EC firmware for Novacustom #2056

Open

5 tasks

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from 37544e4 to 3b2aeea Compare February 23, 2026 18:37

filipleple and others added 20 commits April 14, 2026 16:29

modules/coreboot: remove redundant sed

aeb2284

Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com> Signed-off-by: Thierry Laurion <insurgo@riseup.net>

MTL release: coreboot revision and updated configs

680f976

Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com> Signed-off-by: Thierry Laurion <insurgo@riseup.net>

flake.nix: prefer IPv4, set wget timeout

b78b81e

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

config/coreboot-talos-2: set LOCALVERSION to match v0.7.0 release

d40a5f1

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

modules/coreboot: revert to Dasharo/mtl_release (no local changes)

42e2b6f

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

bin/fetch_source_archive.sh: log mirror fallbacks for developer aware…

703e0bf

…ness Signed-off-by: Thierry Laurion <insurgo@riseup.net>

.circleci/config.yml: minor adjustment

c66ef7d

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Local fixup commits

da9f025

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

config/coreboot-novacustom-nv4x_adl.config: save_in_oldconfig_format

e6c9e7d

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

config/coreboot-novacustom-v540tu.config: save_in_oldconfig_format

0d1402b

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Convert all coreboot configs to defconfig format

955bb4a

Save configs in defconfig format for cross-board comparisons. This removes explicit settings that match Kconfig defaults. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Remove CONFIG_HEAP_SIZE=0x100000 from legacy configs

a310449

Outlier that matches default. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Remove CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX and CONSOLE_USE_ANSI_ESCAPES

2471916

These match defaults, not needed in defconfigs. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from a8e0c80 to bc3dae9 Compare April 14, 2026 20:32

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch 4 times, most recently from 6cbb178 to e27e337 Compare April 14, 2026 21:18

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from e27e337 to 87d273d Compare April 14, 2026 21:45

	CONFIG_IOE_PCR_BASE_ADDRESS=0x3fff0000000
	CONFIG_IOE_PCR_BASE_ADDRESS=0x60000000

	# CONFIG_DASHARO_FIRMWARE_UPDATE_MODE is not set
	CONFIG_DASHARO_FIRMWARE_UPDATE_MODE=y

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

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

-# 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.

	CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x40000
	CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x200000

	# CONFIG_ENABLE_EARLY_DMA_PROTECTION is not set
	CONFIG_ENABLE_EARLY_DMA_PROTECTION=y

Uh oh!

Conversation

tlaurion commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

OLD

QubesOS gathered logs

Heads gathered logs

Uh oh!

tlaurion commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

tlaurion Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

tlaurion Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

tlaurion Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

mkopec commented Feb 12, 2026

Uh oh!

tlaurion commented Feb 12, 2026

Uh oh!

tlaurion commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Feb 16, 2026

Uh oh!

tlaurion commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkopec commented Feb 17, 2026

Uh oh!

tlaurion commented Feb 17, 2026

Uh oh!

tlaurion commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Feb 17, 2026

Uh oh!

tlaurion commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion commented Feb 18, 2026

tlaurion commented Jan 4, 2026 •

edited

Loading

tlaurion commented Jan 4, 2026 •

edited

Loading

tlaurion commented Feb 16, 2026 •

edited

Loading

tlaurion commented Feb 16, 2026 •

edited

Loading

tlaurion commented Feb 17, 2026 •

edited

Loading

tlaurion commented Feb 17, 2026 •

edited

Loading

mkopec commented Feb 23, 2026 •

edited

Loading

tlaurion commented Feb 25, 2026 •

edited

Loading

tlaurion commented Apr 14, 2026 •

edited

Loading

tlaurion commented Apr 14, 2026 •

edited

Loading