Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@Tonux599
Copy link
Contributor

@Tonux599 Tonux599 commented Aug 27, 2025

Replaces #1962

This is based on Dasharo's coreboot instead of coreboot 25.03.

This is draft for the moment, I'll be testing MSI Pro Z790-P DDR5 on Thursday 28th. I'll un-draft post testing.

It should work, as I have been using my custom fork https://github.com/Tonux599/heads/tree/my-custom-msi_z790p_ddr5 for awhile now without issue. However, that fork is not suitable for most as I've customised it for my own uses (like forcing XMP, disabling hyperthreading, etc).

@mblanqui @Hexdigest123 can you test on your boards?

Need to do some commit cleanup pre-merge also.

TODO:

  • Maybe upgrade to Dasharo v1.1.5/v0.9.3

miczyg1 and others added 8 commits August 25, 2025 23:24
Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Żygowski <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Kopeć <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Kopeć <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Michał Kopeć <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
@Tonux599 Tonux599 force-pushed the msi-dasharo-upstream branch from 9cdd697 to 7546d7b Compare August 27, 2025 23:03
@Tonux599
Copy link
Contributor Author

See table below for artefacts ready to be tested.

Board Artefacts
UNTESTED_msi_z690a_ddr4 https://app.circleci.com/pipelines/github/Tonux599/heads/146/workflows/e5e32e13-c5f3-41e8-b965-49accd44880f/jobs/1666/artifacts
UNTESTED_msi_z690a_ddr5 https://app.circleci.com/pipelines/github/Tonux599/heads/146/workflows/e5e32e13-c5f3-41e8-b965-49accd44880f/jobs/1676/artifacts
UNTESTED_msi_z790p_ddr4 https://app.circleci.com/pipelines/github/Tonux599/heads/146/workflows/e5e32e13-c5f3-41e8-b965-49accd44880f/jobs/1667/artifacts
msi_z790p_ddr5 https://app.circleci.com/pipelines/github/Tonux599/heads/146/workflows/e5e32e13-c5f3-41e8-b965-49accd44880f/jobs/1679/artifacts

I have tested msi_z790p_ddr5 myself and it works without issue. A few things to note:

  • No USB keyboard support.
  • PS/2 keyboard work (this was unsupported in Dasharo's release).
  • No HOTP support.
  • There's no bootsplash right now as at one point it was causing hangs. This can be retested later if required.
  • This uses flashprog instead of flashrom. Dasharo's release used their own flashrom branch, but current heads flashprog works fine for my board.

In the future, we can create variants supporting USB keyboard and HOTP if the community requires.

Future issues that need addressing are:

  • Making sure bootsplash works.
  • Avoiding the workaround for >16MiB flash (4125177, bf9708f, and 9be0ce3). A fix to flashtools may help here. The current workaround adds time to boot.

@tlaurion this is good to merge IMO, msi_z790p_ddr5 works great. It's now over to others to test their variants.

@Tonux599 Tonux599 marked this pull request as ready for review August 28, 2025 12:54
Comment on lines +21 to +27
/bin/flashprog -p internal --fmap -i COREBOOT -i FMAP -r /tmp/cbfs-init.rom \
&& CBFS_ARG=" -o /tmp/cbfs-init.rom" \
|| echo "Failed reading Heads configuration from flash! Some features may not be available."
fi

# Load individual files
cbfsfiles=`cbfs -t 50 -l 2>/dev/null | grep "^heads/initrd/"`
cbfsfiles=`cbfs -t 50 -l $CBFS_ARG 2>/dev/null | grep "^heads/initrd/"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tonux599 what happens when calling cbfs on MSI platform? What is the issue that needs this workaround?

Copy link
Contributor Author

@Tonux599 Tonux599 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If my understanding is correct, the cbfs util reads the cbfs from a location in memory. If a flash is >16M then either:

  • Coreboot doesn't map CBFS's larger than 16M into memory. Or,
  • cbfs doesn't have the ability to read a region in memory larger than 16M.

Not sure what it is, but the above workaround is from dasharo's release. Effectively, it uses flashprog to read the flash chip (taking 10s of seconds), and then having the cbfs util read from the resulting file.

Edit: and calling cbfs as normal results in an invalid header magic error (presumably because it's reading garbage).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: and calling cbfs as normal results in an invalid header magic error (presumably because it's reading garbage).

Yes that's why I ask because novacustom boards have spi chips of 32mb and don't need that workaround.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: and calling cbfs as normal results in an invalid header magic error (presumably because it's reading garbage).

Yes that's why I ask because novacustom boards have spi chips of 32mb and don't need that workaround.

Ah yes, whilst the flash for those boards are 32M I presume the CBFS size is <=16M. These boards need a bigger CBFS so we can fit the ROMHOLE in at a specific location (which allows the rom to be flashed from a usb port on the back).

@miczyg1 am I correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. cbfs utility only works for cbfs size or flash size <=16MB. Otherwise you need to dump whole flash to make CBFS parsing work...

Copy link
Collaborator

@tlaurion tlaurion Sep 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tonux599 that deserves a new issue to be tracked/fixed/resolved under Heads and then osresearch/flashtools. After which this thread can be resolved yes, cross-linking those for traceability. Using flashrom/flashprog is a hack here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miczyg1 random thought, could we not have a 16MB CBFS on the 32MB flash and just write the ROMHOLE to where it belongs on the flash? Presuming the ROMHOLE is somewhere past the the first 16MB.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tonux599 you can't do that. heads paylaod is ~8MB in size, it will not fit neither above nor belwo ROMHOLE if CBFS/coreboot is just 16MB. The ROMHOLE fixed address i just that unfortunate, that it cannot be workarounded. By forcefully writing the ROMHOLE you will corrupt the CBFS and make the image unbootable most likely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miczyg1 Thanks. Trying to wrap my brain around this but think I'm getting there. Presumably it collides with the ROMHOLE is because the CBFS (and bootblock) needs to be placed at the end of the 32MB flash chip?

Also trying to look into a fix for the cbfs utility to read the whole CBFS mapped into memory. @miczyg1 is the whole 32MB mapped into memory or just the top 16MB? Having looked at some cbmem logs it looks like FLASH with size 0x2000000 is mapped @ 0xfe000000.

Just trying to work out if this is a limitation in the cbfs utility or coreboot.

Copy link
Contributor

@miczyg1 miczyg1 Sep 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumably it collides with the ROMHOLE is because the CBFS (and bootblock) needs to be placed at the end of the 32MB flash chip?

Exactly.

@miczyg1 is the whole 32MB mapped into memory or just the top 16MB?

Just the top 16MB of the BIOS region.

Having looked at some cbmem logs it looks like FLASH with size 0x2000000 is mapped @ 0xfe000000.

IIRC flashrom prints that, but it is actually bogus info. The MMIO area 0xfe000000 - 0xff000000 has a lot of chipset-specific MMIO (LAPIC, IOAPIC, TXT, TPM and a lot more), so flash can't be mapped there.

The remaining part of the flash is mapped at a separate base address configured in the SPI controller. See details here: https://github.com/coreboot/coreboot/blob/main/src/soc/intel/common/block/fast_spi/mmap_boot.c
(the EXT_BIOS_WIN). Here is base address the programming to the SPI controller PCI space: https://github.com/coreboot/coreboot/blob/main/src/soc/intel/common/block/fast_spi/fast_spi.c#L361

So the cbfs utility would have to look at this PCI register in SPI controllers that support this feature.

Copy link
Collaborator

@tlaurion tlaurion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :)

@aphick
Copy link

aphick commented Sep 17, 2025

Thanks so much for this PR! Testing it on my z790p pro DDR5 and it works great (I enabled USB keyboards)

@Hexdigest123
Copy link

Thanks so much for this PR! Testing it on my z790p pro DDR5 and it works great (I enabled USB keyboards)

Did you have any issues setting the whole thing up or were there any hoops i would try it on my device but the last thing i wanna do is reflash my board with a programmer because the firmware ripped it apart

@Tonux599
Copy link
Contributor Author

@Hexdigest123 what TPM module are you using?

@Tonux599
Copy link
Contributor Author

Looks like Dasharo literally just released new versions for the MSI boards, so will update sometime.
https://docs.dasharo.com/variants/msi_z690/releases/#v115-2025-09-18
https://docs.dasharo.com/variants/msi_z790/releases/#v093-2025-09-18
non-LTS so may not be as stable though.

Both based on coreboot 24.12.

As general advice, use make coreboot helpers to save in defconfig format, remove config lines there that should not be overriden, and then use helper to save back in oldconfig format.

@Tonux599 do you plan on bumping coreboot version soon? Mostly all boards but NV4x seem to have been bumped, which heads share for buildstack for most boards.

Maybe. Added it to a TODO on first post. Will do some testing on my custom branch first, but might leave it to the future as currently this PR has about 2 months of stability testing going for it.

@Tonux599
Copy link
Contributor Author

Before i switch over to the firmware for more then just a few tests does it have the new microcode for 14th Gen Intel CPU's so its not getting fried?

It uses whatever is here https://github.com/Dasharo/dasharo-blobs/tree/main/msi

Of-course, your OS may update it anyway on boot.

@Hexdigest123
Copy link

@Hexdigest123 what TPM module are you using?

I bought this mainboard and I'm not sure, but I believe it should have a TPM 2.0 MSI MS-4462 (9672) module.
https://shop.3mdeb.com/product/msi-pro-z790-p-wifi-ddr5-motherboard-with-dasharo-pro-package/

@Tonux599
Copy link
Contributor Author

@Hexdigest123 what TPM module are you using?

I bought this mainboard and I'm not sure, but I believe it should have a TPM 2.0 MSI MS-4462 (9672) module. https://shop.3mdeb.com/product/msi-pro-z790-p-wifi-ddr5-motherboard-with-dasharo-pro-package/

I can't see on that product page that it ships with a TPM installed? Where you using Dasharo's Heads before and was it working? Can you check to see if the TPM is installed to the motherboard?

The errors in your screenshot show that the TPM can't be found by the kernel. So either it's not installed, or something else is wrong that is hiding it.

@Hexdigest123
Copy link

Hexdigest123 commented Sep 20, 2025

@Hexdigest123 what TPM module are you using?

I bought this mainboard and I'm not sure, but I believe it should have a TPM 2.0 MSI MS-4462 (9672) module. https://shop.3mdeb.com/product/msi-pro-z790-p-wifi-ddr5-motherboard-with-dasharo-pro-package/

I can't see on that product page that it ships with a TPM installed? Where you using Dasharo's Heads before and was it working? Can you check to see if the TPM is installed to the motherboard?

The errors in your screenshot show that the TPM can't be found by the kernel. So either it's not installed, or something else is wrong that is hiding it.

I haven't used Heads before. I used Coreboot with UEFI before, and that might actually be the problem. To be honest, I didn't expect someone to figure out the newest version. Do I need to buy and install the new TPM onto the board?

@Tonux599
Copy link
Contributor Author

I can't see on that product page that it ships with a TPM installed? Where you using Dasharo's Heads before and was it working? Can you check to see if the TPM is installed to the motherboard?
The errors in your screenshot show that the TPM can't be found by the kernel. So either it's not installed, or something else is wrong that is hiding it.

I haven't used Heads before. I used Coreboot with UEFI before, and that might actually be the problem. To be honest, I didn't expect someone to figure out the newest version. Do I need to buy and solder the new TPM onto the board?

Ah right. You'll need the "MS-4462" TPM module for TOTP to work and for the boot to be measured. You don't need to solder it, there is a header on the board.

Maybe just double check to see if one is installed and there isn't something else going on here.

@Hexdigest123
Copy link

I can't see on that product page that it ships with a TPM installed? Where you using Dasharo's Heads before and was it working? Can you check to see if the TPM is installed to the motherboard?
The errors in your screenshot show that the TPM can't be found by the kernel. So either it's not installed, or something else is wrong that is hiding it.

I haven't used Heads before. I used Coreboot with UEFI before, and that might actually be the problem. To be honest, I didn't expect someone to figure out the newest version. Do I need to buy and solder the new TPM onto the board?

Ah right. You'll need the "MS-4462" TPM module for TOTP to work and for the boot to be measured. You don't need to solder it, there is a header on the board.

Maybe just double check to see if one is installed and there isn't something else going on here.

I checked it and no there is non sry for wasting your time im gonna order it real quick but from my last experience it may take some time like a few days maximum a week though everything else you made seemed to work

@Hexdigest123
Copy link

Before i switch over to the firmware for more then just a few tests does it have the new microcode for 14th Gen Intel CPU's so its not getting fried?

It uses whatever is here https://github.com/Dasharo/dasharo-blobs/tree/main/msi

Of-course, your OS may update it anyway on boot.

The problem I addressed was the degradation issue in the Raptor Lake (13th/14th gen) CPUs from Intel. Someone mentioned that Heads didn't include the necessary microcode, and from what I've seen in the blobs, there is a patch, "0x12" that contains some updates but not for my CPU, at least from what I've been able to find online.

@Hexdigest123
Copy link

Hi, so i tried it with the TPM Module installed and everything works fine i resetted the tpm and chose what to boot my OS also works fine as far as i am aware.

@Tonux599
Copy link
Contributor Author

Looks like Dasharo literally just released new versions for the MSI boards, so will update sometime.
https://docs.dasharo.com/variants/msi_z690/releases/#v115-2025-09-18
https://docs.dasharo.com/variants/msi_z790/releases/#v093-2025-09-18
non-LTS so may not be as stable though.

Both based on coreboot 24.12.
As general advice, use make coreboot helpers to save in defconfig format, remove config lines there that should not be overriden, and then use helper to save back in oldconfig format.
@Tonux599 do you plan on bumping coreboot version soon? Mostly all boards but NV4x seem to have been bumped, which heads share for buildstack for most boards.

Maybe. Added it to a TODO on first post. Will do some testing on my custom branch first, but might leave it to the future as currently this PR has about 2 months of stability testing going for it.

Testing this now, v0.9.3 seems to be running well without issue. Will update this PR soon-ish.

@Tonux599
Copy link
Contributor Author

Tonux599 commented Sep 26, 2025

@Tonux599
Copy link
Contributor Author

hi thanks for your work I wanted to test but I can't access the files after 30 days. Can you share it again, please?

Hi @headsx0fng, I've updated that comment with re-built artefacts.

@tlaurion
Copy link
Collaborator

tlaurion commented Oct 29, 2025

hi thanks for your work I wanted to test but I can't access the files after 30 days. Can you share it again, please?

Hi @headsx0fng, I've updated that comment with re-built artefacts.

@headsx0fng : please share which rom/platform was tested in your upcoming test results.

@headsx0fng
Copy link

hi thanks for your work I wanted to test but I can't access the files after 30 days. Can you share it again, please?

Hi @headsx0fng, I've updated that comment with re-built artefacts.

@headsx0fng : please share which rom/platform was tested in your upcoming test results.

Thank you very much for your prompt response. I wanted to test it with the MSI Z790P DDR5 motherboard. I will mention it.

@tlaurion
Copy link
Collaborator

tlaurion commented Nov 3, 2025

@Tonux599 what is satisfactory point for merge here?

@Tonux599
Copy link
Contributor Author

Tonux599 commented Nov 3, 2025

@Tonux599 what is satisfactory point for merge here?

I'm happy with it being merged any time. We've had tests for the Z790-P DDR5 but not the others. I would like to keep them in but as UNTESTED just so others can test them quicker in the future.

I think a big one is the workaround for >32M flash. But that's beyond me currently. Not sure if you have a direct line to @osresearch to see if he could resolve in https://github.com/osresearch/flashtools

@tlaurion
Copy link
Collaborator

tlaurion commented Nov 5, 2025

@Tonux599 what is satisfactory point for merge here?

I'm happy with it being merged any time. We've had tests for the Z790-P DDR5 but not the others. I would like to keep them in but as UNTESTED just so others can test them quicker in the future.

I think a big one is the workaround for >32M flash. But that's beyond me currently. Not sure if you have a direct line to @osresearch to see if he could resolve in https://github.com/osresearch/flashtools

@Tonux599 I don' have a direct line to @osresearch. I opened osresearch/flashtools#10 (comment)

@tlaurion
Copy link
Collaborator

I see microcode uodate PR was merged upstream.

@Tonux599
Copy link
Contributor Author

I see microcode uodate PR was merged upstream.

Yeah, apparently new Dasharo version soon for these boards. Will update then. Best hold off on this PR until then. 🙂

@Hexdigest123
Copy link

I see microcode uodate PR was merged upstream.

Yeah, apparently new Dasharo version soon for these boards. Will update then. Best hold off on this PR until then. 🙂

Please hit me up if you need someone to test it really appreciate your work and until now everything works fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants