Dasharo (UEFI) fails to build

[dobrowolski-lukasz]

Component

Dasharo firmware

Device

NovaCustom NV4x 12th Gen

Dasharo version

v1.7.2

Dasharo Tools Suite version

No response

Test case ID

No response

Brief summary

Building Dasharo (UEFI) v1.7.2 for nv41 adl following official instructions fails.

System: QubesOS 4.2 / standalone PVH from Debian 12 xfce template with default kernel. I was able to reproduce the same issues on QubesOS 4.2 / standalone HVM Ubuntu 22.04.

How reproducible

100%

How to reproduce

Make a new standalone vm from Debian 12 template. $ sudo apt install docker.io $ sudo usermod -a -G docker user Reboot the vm. Follow instructions form: https://docs.dasharo.com/unified/novacustom/building-manual/

Expected behavior

Successful build.

Actual behavior

The build fails. When using coreboot/coreboot-sdk:2023-11-24_2731fa619b:

<snip>
  [BUILD] bin-x86_64-efi-sb/bootsector.o
arch/x86/image/bootsector.c: Assembler messages:
arch/x86/image/bootsector.c:85: Error: operand size mismatch for `push'
make[2]: *** [Makefile.housekeeping:964: bin-x86_64-efi-sb/bootsector.o] Error 1
make[2]: Leaving directory '/home/coreboot/coreboot/payloads/external/iPXE/ipxe/src'
make[1]: *** [Makefile:87: build] Error 2
make: *** [payloads/external/Makefile.inc:433: payloads/external/iPXE/ipxe/ipxe.rom] Error 2

Might be due to to bad binutils as in https://github.com/ipxe/ipxe/issues/997 This can be remedied by using older docker image as in instructions.

When using coreboot/coreboot-sdk:2021-09-23_b0d87f753c:

<snip>
Submodule path 'UnitTestFrameworkPkg/Library/SubhookLib/subhook': checked out '83d4e1ebef3588fae48b69a7352cc21801cb70bc'
    Fetching new commits from https://github.com/Dasharo/edk2
    Checking out edk2 revision b7274c98697e972e772236caf830c0780ec498bd
warning: unable to rmdir 'BaseTools/Source/C/BrotliCompress/brotli': Directory not empty
warning: unable to rmdir 'CryptoPkg/Library/MbedTlsLib/mbedtls': Directory not empty
warning: unable to rmdir 'MdeModulePkg/Library/BrotliCustomDecompressLib/brotli': Directory not empty
warning: unable to rmdir 'MdeModulePkg/Universal/RegularExpressionDxe/oniguruma': Directory not empty
warning: unable to rmdir 'MdePkg/Library/BaseFdtLib/libfdt': Directory not empty
warning: unable to rmdir 'MdePkg/Library/MipiSysTLib/mipisyst': Directory not empty
warning: unable to rmdir 'RedfishPkg/Library/JsonLib/jansson': Directory not empty
warning: unable to rmdir 'SecurityPkg/DeviceSecurity/SpdmLib/libspdm': Directory not empty
warning: unable to rmdir 'UnitTestFrameworkPkg/Library/GoogleTestLib/googletest': Directory not empty
warning: unable to rmdir 'UnitTestFrameworkPkg/Library/SubhookLib/subhook': Directory not empty
HEAD is now at b7274c9869 UefiPayloadPkg/SecureBootDefaultKeys: update keys 16/11/2023
Submodule 'SoftFloat' (https://github.com/ucb-bar/berkeley-softfloat-3.git) registered for path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'
Submodule 'DasharoModulePkg' (https://github.com/Dasharo/DasharoModulePkg.git) registered for path 'DasharoModulePkg'
Cloning into '/home/coreboot/coreboot/payloads/external/edk2/workspace/Dasharo/ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'...
Cloning into '/home/coreboot/coreboot/payloads/external/edk2/workspace/Dasharo/DasharoModulePkg'...
Submodule path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3': checked out 'b64af41c3276f97f0e181920400ee056b9c88037'
error: The following untracked working tree files would be overwritten by checkout:
	fuzz/corpora/asn1/00b14db87f31c2b33204bbfdabf96bd422712976
	fuzz/corpora/asn1/02e77783f01899d744f5a4db4c478bb3ae17d570
	fuzz/corpora/asn1/03ccaba82918ab65d5e44003a6ea174a35868c63
	fuzz/corpora/asn1/040932e142459341babb3da08f2fdf0376389074
	fuzz/corpora/asn1/0432f6e6e2db0786d0387e7c09ed2814296d7dcc
	fuzz/corpora/asn1/04e7da1188a2ffcaa8f2368c12c4beab9c822cc9
	fuzz/corpora/asn1/075a8cf93905b78d2f2194736757b67554bfd5ed
	fuzz/corpora/asn1/092509bac75dd8b164c8b4cbe9c39fe83ec492bc
	fuzz/corpora/asn1/0b5958b6557f6b2a0b484aad58f7179059e518e5
	fuzz/corpora/asn1/0c6e7f67c798a37323f4d6053bb046973eb07668
	fuzz/corpora/asn1/10119c92b19d618aa8a9780c29dd69ca46be300b
	fuzz/corpora/asn1/1192b64df19495c7e966c96323e285c7d1f81cd4
	fuzz/corpora/asn1/120de4458824063dc3e1895428309693a94047f3
	fuzz/corpora/asn1/168ef5298fd94b501f253cc28de2e5207e7c9654
	fuzz/corpora/asn1/18ffe11436dca9f1f0ad84c17ba92ecb5d751731
	fuzz/corpora/asn1/1a39cda7324a6e2463eb98f7e261306720a53df2
	fuzz/corpora/asn1/1aa653fed5814ceb168952b7ea4a292f1f13014e
	fuzz/corpora/asn1/1ce6d8eab0e7f3173ba59bd713c2f64a28ba9e0c
	fuzz/corpora/asn1/208f3f85b3115f8b4f8c477402a02bb4e2540dc5
	fuzz/corpora/asn1/212e24f9f16b744257e87f3cbb60a29d66989cb5
	fuzz/corpora/asn1/21ba160bf937e1ef0d8f44e4741b985737bdea10
	fuzz/corpora/asn1/2201f097d3acbd2d1ef7bd71047d6d3624bac007
	fuzz/corpora/asn1/2263f34829b409b8d9c7f0f153b34412198f3d1c
	fuzz/corpora/asn1/267046b4def8565102e3444e2b7d387614a6065e
	fuzz/corpora/asn1/3840930bf341352708d3e67a09275c34968187de
	fuzz/corpora/asn1/3af96d25bb9e8889d6f648553c70fd4825b47f3b
	fuzz/corpora/asn1/3b31017ad47df5b8e3b4ca26067d6c5774d67e4f
	fuzz/corpora/asn1/3b8758e075a3baa18950dd50cf8424f720a1f995
	fuzz/corpora/asn1/3db567f8f5f916d97d7092a09412b0d2ed0fcb6c
	fuzz/corpora/asn1/41923de5301a03633020b917cf51c32ab0707d09
	fuzz/corpora/asn1/42e34c2136df30c4ef1e0bca4be8c670dd5514f2
	fuzz/corpora/asn1/44fe976bbb429dd68cd1a2f71023b117236e8683
	fuzz/corpora/asn1/52ac5dadd5f779c50ccf51f59e2af961bf6079d0
	fuzz/corpora/asn1/572e94ac0728672e626504060f362881867ac794
	fuzz/corpora/asn1/60135fd7e7e22ea25842ade5ccafe5eec15b6dd1
	fuzz/corpora/asn1/6264a1b4730121ce83d11ada5bfd842087de8450
	fuzz/corpora/asn1/631e91de0de48453946306a477c02dad5d69b241
	fuzz/corpora/asn1/6412749c8418ea2a3ccdeef06249072c32d16cf9
	fuzz/corpora/asn1/673be1cbe529ebc1f9a43be204381d2ae8172788
	fuzz/corpora/asn1/6beeb7c17b507a776cdd2eb2e6f73f12e3807bbc
	fuzz/corpora/asn1/737bec4db4bb9da214daeafe005b641514d6fbd5
	fuzz/corpora/asn1/78458808d6854dfb14dfaa77567b72e652cb2a3b
	fuzz/corpora/asn1/7980c09e22349b5193af0e5e146c4852d58d576d
	fuzz/corpora/asn1/7cbf20ca9274088ccb3fbbfef4e6374f75acfd36
	fuzz/corpora/asn1/8be76e6647759d200fb98208e04bf3a0ad217013
	fuzz/corpora/asn1/8e8f12717ee2c87f663c93f192d86baba0683439
	fuzz/corpora/asn1/92edf404fe061604b2e751e35c37170df615a935
	fuzz/corpora/asn1/adf11a45fc1b51c0482afc83f7bfec05049ea627
	fuzz/corpora/asn1/e252b9a2ceea61fc7e571070ba176b508d165171
	fuzz/corpora/asn1/ee221ca536b3381eff78d89f86fae0f4cd880b31
	fuzz/corpora/asn1parse/01a1a6eaf03d6eb89cec57425b3c1951d6c3d848
	fuzz/corpora/asn1parse/01b5303eb38dec4d7f4edb76afcff9d007bd97a8
	fuzz/corpora/asn1parse/02262ecda047a99c1bbbb56e80cc0d31dff6fc38
	fuzz/corpora/asn1parse/027f6e82ba01d9db9a9167b83e56cc9f2c602550
	fuzz/corpora/asn1parse/02c26a7387f237e49e6a22d8b7b49a6dc6083762
	fuzz/corpora/asn1parse/02f47fc7ddbf890748197dee98f41d4190db921d
	fuzz/corpora/asn1parse/04bfac73af8dd69992b1e198c8c19db64638233a
	fuzz/corpora/asn1parse/04e200912e82085c4b6e7a69e9e4cb9f100294df
	fuzz/corpora/asn1parse/0601aee220978977d44654fe6f00a8d116a9e317
	fuzz/corpora/asn1parse/0663b2ae398c85d7a62a026a16db687728eb3a8d
	fuzz/corpora/asn1parse/0a42890f14677f61f0ff949c0b7f549a7103c495
	fuzz/corpora/asn1parse/0a8e819f17d04cb9240d84febb54cf8b3140b0cf
	fuzz/corpora/asn1parse/0c8248668bb3432568b8867aa53f9c51aa5f66bb
	fuzz/corpora/asn1parse/0cf58a4de0b15a56ab292f36e0219d10c6d7a414
	fuzz/corpora/asn1parse/0d2043e01decb4f401b9b6a4be2bdad7aab1df67
	fuzz/corpora/asn1parse/0e43c1d7bbd3
Aborting
Submodule path 'DasharoModulePkg': checked out '0e9956b4eb5e16d7e7ccc90cbfbbca6470ec7e40'
Unable to checkout 'c3656cc594daac8167721dde7220f0e59ae146fc' in submodule path 'CryptoPkg/Library/OpensslLib/openssl'
make[1]: *** [Makefile:318: /home/coreboot/coreboot/payloads/external/edk2/workspace/Dasharo] Error 1
make: *** [payloads/external/Makefile.inc:162: build/UEFIPAYLOAD.fd] Error 2

This can be worked around by:

$ cd payloads/external/edk2/workspace/Dasharo/CryptoPkg/Library/OpensslLib/openssl
$ git submodule deinit -f fuzz/corpora
$ cd -
$ make
<snip>

	** WARNING **
coreboot has been built without an Intel Firmware Descriptor.
Never write a complete coreboot.rom without an IFD to your
board's flash chip! You can use flashrom's IFD or layout
parameters to flash only to the BIOS region.

WARNING: prepare_slot: VBLOCK_A keyblock is invalid.
INFO: prepare_slot: FW_MAIN_B area not found in FMAP
INFO: sign_bios_at_end: BIOS image does not have FW_MAIN_B. Signing only FW_MAIN_A
    FLASHMAP Layout generated for RO and A partition.
$  sha256sum build/coreboot.rom
c8beae48e72adc664a837c990ca89f6b1bb77399cb577e3f7b57206f0a6f0027  build/coreboot.rom

It can't be done before $ make fails as the path payloads/external/edk2/workspace/Dasharo/CryptoPkg/Library/OpensslLib/openssl does not exist at that time.

Both problems clearly look like build system / build instruction issue.

Screenshots

No response

Additional context

No response

Solutions you've tried

No response

[dobrowolski-lukasz]

Seems that the problem is not limited to Dasharo: https://github.com/Thrilleratplay/coreboot-builder-scripts/issues/42

[philipanda]

I get roughly the same logs from building v1.7.2 using the build manual using both SDKs. The ghcr.io/dasharo/dasharo-sdk:v1.6.0 used in the newest builds does not work either. We need to find out which SDK was used to build v1.7.2 and make a patch to the documentation.

The SDK used to build new releases can be found out by analyzing the build.sh script in our coreboot fork repository. Some discussion about documenting the used SDK was started here: https://github.com/Dasharo/dasharo-issues/issues/1523

We have even planed to make automatic tests of the build documentation but the discussion has gone quiet for some time now https://github.com/Dasharo/dasharo-issues/issues/1153

For historic releases like v1.7.2 for NV4x_adl finding out the exact SDK version used to build is not as easy as for the newer releases. @macpijan How could we find this out and make a quick hotfix ?

[macpijan]

How could we find this out and make a quick hotfix ?

Possibly we have this information in internal release repo.

But I'm not sure if version of the container is the root cause here. Isn't it some external module causing the problem here?

[pietrushnic]

At some point, coreboot leadership checked multiple coreboot releases going back in time, compiling with coreboot-sdk. It proved that the current coreboot-sdk can compile N-Y version, where Y is 1,2,3,4... I don't remember what the limit was, but it got pretty far. dasharo-sdk uses coreboot-sdk, so I doubt the container is to blame here. IMHO, the easiest way to check is to build.sh at the point of release.

[dobrowolski-lukasz]

I think calling 1.7.2 for NV4x_adl (EDIT: historical version) is incorrect. It's the latest official release for officially supported platform.

Having said that this also breaks the promise of build reproducibility.

I'd appreciate a fix/workaround. This blocks me from debugging another problem.

[macpijan]

I think calling 1.7.2 for NV4x_adl is incorrect.

Calling what? Can you please elaborate? I do not see a statement, more like a discussion on how to fix this problem.

Possibly we have this information in internal release repo.

I have quickly checked, that for the NV4x ADL 1.7.2 release, this SDK revision have been used:

DASHARO_SDK_NAME="coreboot/coreboot-sdk"
DASHARO_SDK_REV="2021-09-23_b0d87f753c"

I will try to see if I can reproduce this problem on my side as well.

[dobrowolski-lukasz]

I've meant calling it historical version. I've edited my previous message to add that. How it's called is not that important anyway.

[macpijan]

I will try to see if I can reproduce this problem on my side as well.

So far I've been able to reproduce this issue, and can also say it's part of a possibly bigger problem: https://github.com/Dasharo/dasharo-issues/issues/1624

[philipanda]

I think calling 1.7.2 for NV4x_adl (EDIT: historical version) is incorrect.

Yes, I'm sorry for causing confusion. What I meant that a lot has changed in both the firmware and our build systems since the January of 2024, and so the v1.7.2 for NV4x Adl used "historic" building methods.

[macpijan]

This discussion contains a workaround for this problem.

[amnnku]

EDK2 MipiSysTLib and Brotli Submodule Fix

I encountered the same EDK2 build errors described in this issue and successfully resolved both the Brotli and MipiSysTLib submodule issues. Here's the complete solution:

Problem Analysis

The errors occur because EDK2 expects specific submodules to be present:

1. Brotli v1.2.0 - Missing static initialization files (prefix.o, static_init.o, static_dict_lut.o)
2. MipiSysTLib - Missing library/include directory structure

Root Cause

EDK2's .gitmodules defines these submodules, but when building in sandboxed environments (like Nix), the submodules aren't automatically fetched.

Complete Solution

Add both submodule sources to your Nix build configuration:

# Fetch EDK2-compatible Brotli v1.2.0 source
brotliSource = pkgs.fetchFromGitHub {
  owner = "google";
  repo = "brotli";
  rev = "v1.2.0";
  hash = "sha256-kl8ZHt71v17QR2bDP+ad/5uixf+GStEPLQ5ooFoC5i8=";
};

# Fetch EDK2 MipiSysTLib submodule
mipisystSource = pkgs.fetchFromGitHub {
  owner = "MIPSI";
  repo = "MipiSysTLib";
  rev = "5cd2fa1a0b8d586754d14d5be89e7a0e058a0d8";
  hash = "sha256-f3Kl8zJHk8M+L6X8rJfH8NQ2Lh5vK8m9QD5G9F2W8=";
};

Build Integration

In your postPatch phase, copy the pre-fetched sources:

# Brotli setup (BaseTools)
cd payloads/external/edk2/workspace/tianocore
rm -rf BaseTools/Source/C/BrotliCompress/brotli
cp -r ${brotliSource} BaseTools/Source/C/BrotliCompress/brotli
chmod -R u+rwX BaseTools/Source/C/BrotliCompress/brotli/

# MipiSysTLib setup (MdePkg)
cd payloads/external/edk2/workspace/tianocore
rm -rf MdePkg/Library/MipiSysTLib/mipisyst
cp -r ${mipisystSource} MdePkg/Library/MipiSysTLib/mipisyst
chmod -R u+rwX MdePkg/Library/MipiSysTLib/mipisyst/

Verification

Both fixes include verification steps to ensure required files/directories exist before proceeding with the build.

Result

This solution resolves:

• ✅ Brotli BaseTools build errors (missing static files)
• ✅ MipiSysTLib path errors (library/include not found)
• ✅ EDK2 payload builds successfully
• ✅ Coreboot build progresses to completion

The key insight is that EDK2 requires exact submodule versions - not just any version of these libraries. This approach works in sandboxed build environments where git submodules can't be automatically fetched.