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

Time spent on #2039 #2062 #2082 : 60h and counting since january (ec, performace regression etc)

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

+		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

-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

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

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

filipleple · 2026-04-15T11:21:12Z

@tlaurion I think both points are valid, defconfigs are a lot clearer to compare and evaluate the functionality of a platform, but also they are just diffs from default settings. Since the defaults can change and expand, to avoid a sort of configuration drift it's useful to keep and monitor explicit oldconfigs.

So I'd propose to keep them both, and to keep them automatically up to date we could add a CI job that would regenerate oldconfigs from defconfigs, and fail if there's a diff between the oldconfig and what's in the repo. If you see such fail you run e.g. make update_oldconfigs, check the diff for potentially problematic changes, if OK then commit.

That is of course a redundancy of sorts, including technically lots of lines of "code", but it boils down to ~3MB of disk space in the ~6GB active Heads workspace, and I think people (and AI) generally know just not to try read through it

macpijan · 2026-04-15T11:58:12Z

We use defconfigs (not full configs) for all UEFI releases, and we have had 0 issues with that I suppose?

Why not using defconfigs here as well?

I suppose the main reason using full config was that it was already a thing in heads, and we followed the convention that was already in place.

I think the only important point is not to modify defconfig them directly in text editor, rather via Kconfig menu and saving them?

filipleple · 2026-04-15T13:50:29Z

 CONFIG_DIMM_SPD_SIZE=512
 CONFIG_FMDFILE=""
 # CONFIG_NO_POST is not set
 CONFIG_MAINBOARD_VENDOR="Notebook"


Same as https://github.com/linuxboot/heads/pull/2039/changes#r3086945248

filipleple · 2026-04-15T13:58:48Z

 # CONFIG_DRIVERS_PS2_KEYBOARD is not set
 CONFIG_DRIVERS_MC146818=y
-# CONFIG_USE_PC_CMOS_ALTCENTURY is not set
+CONFIG_USE_PC_CMOS_ALTCENTURY=y


@tlaurion I think we wanted to keep it disabled, as per #2082 (comment) and following. Also doesn't match V540TU's config, where it's disabled

SergiiDmytruk · 2026-04-15T14:04:39Z

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?

@tlaurion, I don't understand what you're describing here and I'm not really suggesting an approach (other than warning against editing defconfigs). Just pointing out that if you want to have visibility in what options change, defconfigs will help with reviewing changes but won't show complete list of options. If you want to have both (diff against default and against previous version), then I would go with @filipleple's suggestion of keeping both forms in the repository.

We use defconfigs (not full configs) for all UEFI releases, and we have had 0 issues with that I suppose?

There were cases of unexpected configuration, but that could happen with full configs as well (make olddefconfig normalizes options and drops/flips conflicting ones if you add them manually).

Disabling CMOS_ALTCENTURY was decided in PR #2082 discussion. These two boards regressed from origin/master where it is disabled. Matches v540tu and ns50 which are already disabled. Note: SMBIOS strings (MAINBOARD_VENDOR, MAINBOARD_SMBIOS_MANUFACTURER, MAINBOARD_SMBIOS_PRODUCT_NAME) are intentionally preserved as-is per origin/master. These values are required by flashprog for ROM identification (current ROM vs ROM to flash) and must not change. Fixes: unaddressed comment by filipleple on PR #2039 Signed-off-by: Thierry Laurion <insurgo@riseup.net>

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

tlaurion · 2026-04-15T17:20:01Z

 CONFIG_FMDFILE=""
 # CONFIG_NO_POST is not set
-CONFIG_MAINBOARD_VENDOR="Clevo"
+CONFIG_MAINBOARD_VENDOR="Notebook"


fix to match origin/master otherwise cannot internally upgrade without flashprog -p internal:mismatch

tlaurion · 2026-04-15T17:20:16Z

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


Still unknown

tlaurion · 2026-04-15T17:20:39Z

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


tlaurion · 2026-04-15T17:21:41Z

 CONFIG_INTEL_GMA_VERSION_2=y
 CONFIG_DRIVERS_INTEL_PMC=y
 # CONFIG_DRIVERS_NXP_UWB_SR1XX is not set
+# CONFIG_DRIVERS_PS2_KEYBOARD is not set


unknown for all boards

tlaurion · 2026-04-15T17:25:49Z

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?

@tlaurion, I don't understand what you're describing here and I'm not really suggesting an approach (other than warning against editing defconfigs). Just pointing out that if you want to have visibility in what options change, defconfigs will help with reviewing changes but won't show complete list of options. If you want to have both (diff against default and against previous version), then I would go with @filipleple's suggestion of keeping both forms in the repository.

We use defconfigs (not full configs) for all UEFI releases, and we have had 0 issues with that I suppose?

There were cases of unexpected configuration, but that could happen with full configs as well (make olddefconfig normalizes options and drops/flips conflicting ones if you add them manually).

@filipleple @SergiiDmytruk added helper and *.config_defconfig per 196e576

tlaurion · 2026-04-15T17:36:12Z

not sure wwhy circleci doesn't update tests here but its happening under https://app.circleci.com/pipelines/gh/tlaurion/heads/3735/details?useNewPipelines=true with hopefully proper per arch workspace reusal

…nfig Add coreboot.save_in_defconfig_format_backup target that runs savedefconfig and saves the result as .config_defconfig alongside the original .config file. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…m Dasharo/mtl_release Command trail: ./docker_repro.sh make BOARD=UNTESTED_nitropad-ns50 coreboot.save_in_oldconfig_format_in_place ./docker_repro.sh make BOARD=UNTESTED_nitropad-ns50 coreboot.save_in_defconfig_format_backup git difftool -d sudo cp config/coreboot-nitropad-ns50.config_defconfig config/coreboot-nitropad-ns50.config ./docker_repro.sh make BOARD=UNTESTED_nitropad-ns50 coreboot.save_in_oldconfig_format_in_place ./docker_repro.sh make BOARD=UNTESTED_nitropad-ns50 coreboot.save_in_defconfig_format_backup Preserve smbios strings from origin/master while reducing unnecessary defconfig changes to only critical deviations: - Use RaptorLake FSP headers (MTL release) - Set CONFIG_USE_PC_CMOS_ALTCENTURY=n - Enable console loglevel/ansi prefixes - Fix debug output: HWBASE_DEBUG_NULL -> HWBASE_DEBUG_CB Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion · 2026-04-15T20:19:22Z

b6e69a2 accounts for minimal required changes to build vs defaults kconfig for that branch tag under modules/coreboot. hopefully next version bumps will be easier to track with *.config_defconfig see commit messsage

building https://app.circleci.com/pipelines/gh/tlaurion/heads/3739/details?useNewPipelines=true&job=c261dd7e-a650-40d6-8ac5-f5a899aee32f&buildNumber=93881&jobType=build&workflowId=3cf64050-912d-4919-a765-193549d605a5

tlaurion · 2026-04-15T20:24:34Z

not sure wwhy circleci doesn't update tests here but its happening under https://app.circleci.com/pipelines/gh/tlaurion/heads/3735/details?useNewPipelines=true with hopefully proper per arch workspace reusal

failed because ns50 fsp were pointing to alder lake not raptor as fixed per b6e69a2

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

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from 87d273d to 39fe72e Compare April 15, 2026 13:19

filipleple reviewed Apr 15, 2026

View reviewed changes

Comment thread config/coreboot-novacustom-nv4x_adl.config

filipleple reviewed Apr 15, 2026

View reviewed changes

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from eb948e2 to 2e764cb Compare April 15, 2026 14:29

tlaurion added 5 commits April 15, 2026 13:08

circleci: per-architecture workspace cache and docker v0.2.9

22befc0

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

bin/fetch_source_archive.sh: log mirror fallbacks

a5e36ec

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

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

6163c0e

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

MSI/Nitropad boards: add common security settings

d03aa09

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

Dasharo boards: update coreboot configs

3b0745d

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

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from 8ea5b47 to 196e576 Compare April 15, 2026 17:18

tlaurion commented Apr 15, 2026

View reviewed changes

tlaurion marked this pull request as ready for review April 15, 2026 17:31

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from e1ac932 to 2f44fa0 Compare April 15, 2026 20:09

tlaurion added 2 commits April 15, 2026 16:10

tlaurion force-pushed the pre_release_dasharo_101_rc3 branch from 2f44fa0 to b6e69a2 Compare April 15, 2026 20:10

	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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

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

filipleple commented Apr 15, 2026 •

edited

Loading

tlaurion Apr 15, 2026 •

edited

Loading