-
-
Notifications
You must be signed in to change notification settings - Fork 205
Msi dasharo upstream #1995
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Msi dasharo upstream #1995
Conversation
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]>
Signed-off-by: Matthew Drobnak <[email protected]> Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
9cdd697 to
7546d7b
Compare
|
See table below for artefacts ready to be tested. I have tested
In the future, we can create variants supporting USB keyboard and HOTP if the community requires. Future issues that need addressing are:
@tlaurion this is good to merge IMO, |
| /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/"` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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,
cbfsdoesn'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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
tlaurion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM :)
|
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 |
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
|
Artefacts for v1.1.5 / v0.9.3. |
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. |
|
@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 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 |
Signed-off-by: Thomas Clarke <[email protected]>
Signed-off-by: Thomas Clarke <[email protected]>
@Tonux599 I don' have a direct line to @osresearch. I opened osresearch/flashtools#10 (comment) |
|
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 |
note: no changes to board coreboot config's required. Signed-off-by: Thomas Clarke <[email protected]>
|
Artefacts for v1.1.6 / v0.9.4. |
|
@Tonux599 as known; Dasharo+Heads had bad press on MSI. From what I got (memory based, please correct me) from @zirblazer HCL is important (should be stated in board configs)
At bare minimum, expected to work HCL should point to Dasahro docs, in board configs, prior of merge. Thanks for this work @Tonux599. Not sure how to do this politically, but current dasahro+heads users will want to know existence of these test binaries, in today's Dasahro DUG terms, being a "rapid" release. |
|
@koala0815 re-running here: https://app.circleci.com/pipelines/github/Tonux599/heads/175 Sorry I've been really busy. @tlaurion shall we just merge and open issues after for outstanding issues? |
tlaurion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
@Tonux599 please modify op to reflect current state of merge. |
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: