-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
WIP - Z690 A DDR5 / Msi ms7d25 TPM2 #1371
Conversation
@ThePlexus just a few moments ago I pushed slightly better approach to flash the board: https://docs.dasharo.com/variants/msi_z690/development/ WSON8 clip is not needed anymore. The BIOS flash CS pin is exposed on JTPM1 pin5 (reserved), so basically any 1.8V level capable programmer should do the work by connecting 2mm to 2.54mm dupont wires to JTPM1 header. Also the board may come with Winbond chip too, not that it is relevant for internal programmer dTPM is not supported for now, because coreboot can work only with one TPM type, either fTPM or dTPM and will need code modifications and fiddling with ME to switch to dTPM. |
Thanks for the knowledge share @miczyg1 . Thats great news to hear - I shall modify the top post here to record the change in header status. Re dTPM - thanks for the info I suspected that was the case. I had to do something similar for the P8H61 (though a lot less effort :P ) |
@ThePlexus some notes from what I can see
|
#Enable DEBUG output | ||
export CONFIG_DEBUG_OUTPUT=y | ||
export CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT=y | ||
export CONFIG_TPM2_CAPCTURE_PCAP=y |
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.
Remove this for release (as other debug and trace output) This one only useful to have pcap traces under /tmp
|
||
CONFIG_LINUX_USB=y | ||
|
||
export CONFIG_TPM=y |
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.
This is tpm1 enablement. Remove otherwise unsure of Heads behavior.
export CONFIG_BOOTSCRIPT=/bin/generic-init | ||
export CONFIG_BOOT_REQ_HASH=n | ||
export CONFIG_BOOT_REQ_ROLLBACK=n | ||
export CONFIG_BOOT_KERNEL_ADD="intel_iommu=on intel_iommu=igfx_off debug console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200" |
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.
console=tty needs to he the last one to tell what is main console (VGA).
KERNEL_ADD options are passed to Heads' kexec'ed kernel
CONFIG_PAYLOAD_LINUX=y | ||
CONFIG_PAYLOAD_FILE="@BOARD_BUILD_DIR@/bzImage" | ||
CONFIG_LINUX_INITRD="@BOARD_BUILD_DIR@/initrd.cpio.xz" | ||
CONFIG_LINUX_COMMAND_LINE="intel_iommu=on intel_iommu=igfx_off debug console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200" |
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.
Same here. Swap consoles so last is desired main console
FSP GOP works the same way as libgfxinit. The result is a coreboot framebuffer saved in LB tags for use by payload. If heads Linux kernel does not initialize i915 properly, then maybe the Linux version is too old? |
modules/flashrom
Outdated
@@ -1,34 +1,39 @@ | |||
modules-$(CONFIG_FLASHROM) += flashrom |
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.
We might need to separate flashrom module from dasharo-flashrom. Not all older boards will be able to have this new flashrom version which is bigger. Good for PoC, but this is why it's not merged to replace currently used flashrom version: boards that would benefit from WP (without TPM: x200 etc) are also unfortunately really size constrained in term of available SPI space.
EDIT: conclusion is that passing to newer dasharo/flashrom (ast1100 + WP support) would cost 0.01mb. Will leave point open for now, but not really a concern with even t520-hotp-maximized board havig still 0.87mb of free space after the merge (still concerning after newer gpg2 PR merge etc) but not an emergency, where kernel modules could be trimmed a bit more, as planned.
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.
Z690 chipset is available in upstream flashrom already: https://github.com/flashrom/flashrom/blob/master/chipset_enable.c#L2178
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 : build of master flashrom happening under https://app.circleci.com/pipelines/github/tlaurion/heads/1604/workflows/f7a74cfc-72f2-4de7-aedc-e8a7c24cc5aa for commit tlaurion@0d49979 (building Heads flashrom to be as flashrom flashrom/flashrom@f3c21c6) EDIT: test was bogus for size comparison since both DUMMY and AST1100 were removed.
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.
Building on flashrom master at https://app.circleci.com/pipelines/github/tlaurion/heads/1606/workflows/e7adbb7b-4112-4017-b9c4-e419397386c9 for tlaurion@9b03e72 which only removes AST1100 to be comparable to https://app.circleci.com/pipelines/github/tlaurion/heads/1605/workflows/26753865-ac5a-4097-8e06-eccc85d748bf which builds for dasharo/flashrom with ast1100
Will edit this comment to compare free space for single board to have clear comparison ground.
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 : Clearer and direct builds are happening here:
- flashrom/flashrom master on top of heads master: https://app.circleci.com/pipelines/github/tlaurion/heads/1607/workflows/23f6c9f3-926f-478f-a709-70be6d87bae4
- https://app.circleci.com/pipelines/github/tlaurion/heads/1607/workflows/23f6c9f3-926f-478f-a709-70be6d87bae4/jobs/20838?invite=true#step-103-745 (empty space: 4910808)
- dasharo/flashrom (WP+ast1100 support) on top of heads master: https://app.circleci.com/pipelines/github/tlaurion/heads/1605/workflows/26753865-ac5a-4097-8e06-eccc85d748bf
I'm now even more confused. Is ast1100 merged in master? How come adding more does not increase size?
EDIT:
Unbelievable until tested, but downloading both initrd.cpio.xz have the exact same size.
flashrom master:
user@heads-tests:/tmp/flashrom_master$ wget https://output.circle-artifacts.com/output/job/1a4f9a85-50c1-4fc9-be79-0fdf3a432d75/artifacts/0/build/x86/x230-hotp-maximized/initrd.cpio.xz
user@heads-tests:/tmp/flashrom_master$ ls -al initrd.cpio.xz
-rw-r--r-- 1 user user 4125696 Apr 13 11:01 initrd.cpio.xz
user@heads-tests:/tmp/flashrom_master$ xz -d initrd.cpio.xz
user@heads-tests:/tmp/flashrom_master$ cpio -i < initrd.cpio
user@heads-tests:/tmp/flashrom_master$ ls -al bin/flashrom
-rwx------ 1 user user 674552 Apr 13 11:41 bin/flashrom
user@heads-tests:/tmp/flashrom_master$ strings bin/flashrom | grep ast1100
user@heads-tests:/tmp/flashrom_master$
dasharo/flashrom from other PR:
user@heads-tests:/tmp/dasharo_flashrom$ wget https://output.circle-artifacts.com/output/job/6a254451-086a-4521-a2ad-8834a699a7d2/artifacts/0/build/x86/x230-hotp-maximized/initrd.cpio.xz
user@heads-tests:/tmp/dasharo_flashrom$ ls -al initrd.cpio.xz
-rw-r--r-- 1 user user 4125696 Apr 13 10:52 initrd.cpio.xz
user@heads-tests:/tmp/dasharo_flashrom$ xz -d initrd.cpio.xz
user@heads-tests:/tmp/dasharo_flashrom$ cpio -i < initrd.cpio
user@heads-tests:/tmp/dasharo_flashrom$ ls -al bin/flashrom
-rwx------ 1 user user 703224 Apr 13 11:41 bin/flashrom
user@heads-tests:/tmp/dasharo_flashrom$ strings bin/flashrom | grep ast1100
ast1100
ast1100_spi_send_command
So xz is just doing an amazing job at compressing heads.cpio, tools.cpio and modules.cpio where no difference at all is shown when only flashrom is involved as of today.
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.
So let's take a clean view now into space differences comparing actual heads master using old flashrom/flashrom and dasharo/flashrom.
- Last master commit's build log https://app.circleci.com/pipelines/github/osresearch/heads/573/workflows/cab20f48-dfb8-43ca-a7a9-cc9d3c3ee5e8/jobs/9088?invite=true#step-103-819 (empty: 4922008)
- dasharo/flashrom (WP+ast1100 support) last buildlog https://app.circleci.com/pipelines/github/tlaurion/heads/1605/workflows/26753865-ac5a-4097-8e06-eccc85d748bf/jobs/20837?invite=true#step-103-790 (empty space: 4910808)
cost of passing to dasharo/flashrom: 11200bytes
@tlaurion interesting. As its present in both the corebot config and board config linux lines. When im next home ill dive into this. hopefully just something ive done somewhere in the ports. But, if not, well...things to look into.
Agree. I would personally advise we use a dTPM, which is going to take some work. ive not really given much effort to using the fTPM at the moment, as, well, i prefer something discreet over something on-die that i cant stick a SPI probe in between and verify. Maybe being too paranoid? i dunno |
When expending (oldconfig) current defconfig saved linux config from librem_common, the following expends:
As written (sorry for all the debugging info there) under #1351 and under other issues, I am totally not convinced of saving either coreboot nor linux in defconfig format anymore. As one can see today under #1373, the coreboot config there are plain @ThePlexus I would recommend saving in oldconfig format. @JonathonHall-Purism i'm being confused though, since one quick check of config/coreboot-librem_14.config shows: So are you seeing Edit: @JonathonHall-Purism confirms he sees the same on init ouput, but also confirms that he sees "DMAR: Disable GFX device mapping" in the logs, confirming that kernel is applying the option. Again sorry for the noise. |
@ThePlexus can you provide full serial console log please? |
@simonbunny I edited previous posts. |
385a055
to
59972f3
Compare
Closing this out for now, as it will require (at minimum) some significant coreboot modifications and has some less desirable outputs. I will open anew PR with work so far (it does post and gets display) but there are some significant upstream blockers to this
@tlaurion what is the view on using the fTPM in these families, assuming a dead end on dTPM and ME? Ill do a new PR with the work so far at some point. |
Can you turn that into an issue? @ThePlexus ? |
TBH I haven't verified how chipset behaves when ME is disabled with HAP (I have no MSI compliant SPI dTPM to check if TPM can be switched from PTT to SPI dTPM). I know for sure that fTPM stops working with whatever method you use to disable ME.
Yes, we need the patches that unify the TPM drivers in coreboot: https://review.coreboot.org/q/topic:%22tpm-unification%22
With the patches above, there should be no need for TPM_CRB option anymore. |
@tlaurion I took a quick look at what happens to the PTT state when HAP is enabled aaand... It looks like ME/chipset automatically switches to the next available and enabled/configured TPM interface. In case of MSI, I have checked this register: https://github.com/coreboot/coreboot/blob/master/src/security/intel/txt/txt_register.h#L98 which indicates currently active TPM bus/interface and it indicated SPI TPM. So that's a good news, that we don't have to use HECI to disable PTT explicitly if we use HAP. However, we still need that patches unifying TPM drivers in coreboot to land. |
@ThePlexus most URLs in OP are 404 |
@miczyg1 something to track? |
@ThePlexus I see that last force push removed the PR content. Would be nice if you forced push your PoC state here so this PR could be used to collaborate into creating this community driven port! |
This is my attempt so far to bring the Z690-A DDR5 into Heads. This is a WIP. The board seems to have all regions unlocked for internal programmer.
status
It boots to serial console only and we see hello world;
connections
Requirements
ME
Findings/WIP stuff
** TPM error**
even though it seems coreboot creates a TPM log and TPM measurements do present.