Platform blobs, collaborators/maintainers/testers for faster problems resolution

[tlaurion]

Coreboot specs

Intel

xxx0: gm45 bridge, Montevina: no FSP, no ME: X200, T400, T500, R500, X300 : no QubesOS support there (no proper vt-d2)
xx20: Sandy bridge, no FSP. ME<10: BUP module required only: X220/T420/T520
xx30: Ivy bridge, no FSP. ME<10: ROMP and BUP required: X230/T430/W530 Z220 CMT and others

Additional required Intel blobs:

FSP is present in all Broadwell+ platforms
MRC: Memory Reference Code blob required in Broadwell+ (T440p/w541) : follow ongoing coreboot Native Ram Initialization (NRI effort)

ME status on different boards models

Removed in ME <=6 (xxx0)
Deactivated+Neutered ME in ME 6 <= 10 (xx20 BUP/xx30 BUP+ROMP)
Deactivate+Partially Neutered (BUP, RBE, Kernel and syslibs modules REQUIRED in ME > 11)
Soft disable/HAP disable bit possible on ME 12+ (PoC BE CAUTIOUS)

xx30, xx20: ME 6 <= 10
Skylake, Kabylake, Whiskeylake and newer: ME >= 11
Intel ME then changed its name to Converged Security Management Engine (CSME), where HAP bit can be flipped, but modules cannot be removed anymore.

AMD

AMD fam15h (eg: kgpe-d16)
PSP in all models after fam15h

Power9

Blobless.

---

Boards and willing testers

Laptops

x200 (xxx0): @irelativism
t400 (xxx0): @irelativism
r500 (xxx0): @fhvyhjriur
x220 (xx20): @Thrilleratplay @BlackMaria @srgrint
t420 (xx20): @alexmaloteaux @natterangell (iGPU) @akfhasodh @doob85
t430 (xx30): @nestire(t430-legacy, t430-maximized) @Thrilleratplay @alexmaloteaux @lsafd @bwachter(iGPU maximized) @shamen123 @eganonoa(iGPU) @nitrosimon @jans23 @icequbes1 (iGPU) @weyounsix (t430-dgpu)
t430-dgpu (xx30): @weyounsix (t430-dgpu)
t520 (xx30): NOBODY
t530 (xx30): @3hhh
w530 (xx30): @eganonoa @zifxify @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU)
w530-dgpu (xx30): @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU)
x230 (xx30): @nestire(x230-legacy, x230-maximized) @tlaurion(maximized) @osresearch @merge @jan23 @MrChromebox @shamen123 @eganonoa @bwachter @Thrilleratplay @jnscmns @doob85
X230i (x230): @natterangell
x230-fhd/edp variant: @n4ru @computer-user123 (nitro caster board) @Tonux599 @househead @pcm720 (eDP 4.0 board and 1440p display)
t440p: @ThePlexus @srgrint @akunterkontrolle @rbreslow
w541 (similar to t440p): @resende-gustavo @gaspar-ilom
Librem 11(JasperLake): @JonathonHall-Purism
Librem 13v2 (Skylake): @JonathonHall-Purism
Librem 13v4 (Kabylake): @JonathonHall-Purism
Librem 14 (CometLake): @JonathonHall-Purism
Librem 15v3 (Skylake): @JonathonHall-Purism
Librem 15v4 (Kabylake): @JonathonHall-Purism
Nitropad NS50 (AlderLake) : @daringer
Nitropad NV41 (AlderLake) : @daringer

Servers

coreboot based

kgpe-d16 (AMD fam15h) (dropped in coreboot 4.12): @tlaurion @Tonux599 @zifxify @blobless
kcma-d8 AMD fam15h (dropped in coreboot 4.12): @59iosl30
Supermicro x11ssh: @osresearch @citypw @MrChromebox @root-hardenedvault ?
Librem L1UM v1 (Broadwell): @JonathonHall-Purism
Librem L1Um v2 (CoffeeLake): @JonathonHall-Purism
Talos II: @tlaurion

linuxboot based

Leopard OCP node: @osresearch others?
Winterfell OCP node: @osresearch others?
Intel S2600wf : @osresearch others?
r630: @osresearch others?

Desktop

coreboot based

kgpe-d16 AMD fam15h (dropped in coreboot 4.12): @0rb677 @Tonux599 @zifxify @blobless
kcma-d8 AMD fam15h (dropped in coreboot 4.12): @59iosl30
Librem Mini (Whiskeylake): @JonathonHall-Purism
Librem Mini 2 (Whiskeylake): @JonathonHall-Purism
Talos II: @tlaurion
ASUS P8Z77 M PRO (Ivy bridge): @ThePlexus
HP Z220 CMT (Ivy bridge): @d-wid

Integration/Test

Reproducibility expertise: @osresearch @flammit others?
Integration expertise: @tlaurion @osresearch @flammit others @JonathonHall-Purism
qemu: @osresearch @flammit others @JonathonHall-Purism
Continuous Integration environments: @SergiiDmytruk @tlaurion @Tonux599 ?

Please add where you can help so that you are comfortable being tagged in issues.

[snmcmillan]

t430: @flawedworld is the owner of the current PR and is the one that actually owns a T430.

[flawedworld]

@tlaurion happy with the T430, I also have an X230

[techge]

Actually, I only have two x220 here. Unfortunately, I do not have a T420.

[MrChromebox]

I have:

• Librem 13v2
• Librem 13v4
• Librem 15v3
• Librem 15v4
• x230

[ThePlexus]

x230 and x220 here. Im also waiting for when we roll to next coreboot version to maintain/support p8h61m-pro desktop

[Tonux599]

Happy with kgpe-d16, will be purchasing an additional SPI chip for testing soon as its my main workhorse. Also have an x220 and a FHD modded x230.

[Thrilleratplay]

I have a dedicated x230 tablet for heads.

Additionally, I have:

• T430
• X220
• X220T
• X230 loose motherboards

and a Carbon X1 Gen1 but haven't have success flashing coreboot on it.

My main machine is a X230 with Nitrocaster FHD mod but that has a fully encrypted drive.

[MrChromebox]

Librem 13v4 (skylake): @MrChromebox
Librem 15v4 (skylake): @MrChromebox

those two boards are Kabylake, not skylake

[tlaurion]

@MrChromebox @Thrilleratplay OP modified. Thanks

[Thrilleratplay]

@tlaurion Can you remove the X1 Carbon Gen 1 from my name. Until I can successfully coreboot it, I will not be able to provide any assistant with it and do not want to create any confusion.

[tlaurion]

On CBFS region, neutering ME, expending BIOS region in IFD after having reduced ME region

[bwachter]

I'm mainly on the x230 (with several of them). I have a t430 which I'm currently not flashing due to initial setup issues trying to get to a working version - I do have a spare t430 board+CPU, though, but I need to get my hands on a fan for it first. After that it'd be usable for testing with an external display.

[tlaurion]

Add HP Z220 CMT added, adding @d-wid for board owner.

[tlaurion]

@daringer added nv41/ns50 on op and tagged you as tester. Reused those lines under #1522 for testing.

[lethedata]

I can test x230 (xx30) (x220 keyboard mod) and x230-fhd/edp variant (edp 1080p display)

[tlaurion]

I can test x230 (xx30) (x220 keyboard mod) and x230-fhd/edp variant (edp 1080p display)

@lethedata can you detail a little more what edp mod it is? This is what seems to be confusing for all for fhd/edp mod, even more if there is a reboot issue from OS if only difference is that edp mod, preventing shutdown of power lines on the x230 which was never reported before.

[jtf7]

@tlaurion
I would like to be tagged in all things KGPE-D16!

I have 8 of these boards so far and have done extensive research and testing relating to building a stable kgpe-d16 system that is as open source and blob free as possible. That being said, most of what I’ve done is hardware based testing. Programming is definitely not my strong suit but I’m happy to help in whatever ways I can.

This board is rock solid—once you figure out how to get it running. Based on what I’ve seen in the forums, it seems like a lot of people would like to be using this board (especially with Qubes) but aren’t because of the initial technicalities associated with getting up and running. I think this board (and its KCMA-D8 little brother) have enormous potential and the number of users would grow significantly if there was a dedicated place for users to document how to build a working system. So...is there a good place for an up-to-date dedicated KGPE-D16 wiki page for this? What would be the best way to go about setting this up?

I would like to download a compiled ROM image of Heads for the KGPE-D16 although I am not familiar with GitHub. How do I do this? It appears there are numerous flavors of Heads that can be used, such as: Dasharo/Heads, linuxboot/Heads, Nitrokey/Heads, tlaurion/Heads, and many more. The Winbond chips I am currently using I purchased pre-flashed with Heads Workstation PS/2 (Dasharo flavor I think, pull 1565?) so I’m not entirely sure how to obtain ROM images. Assistance with this would be greatly appreciated.

I’m open to testing whichever ROM images seem promising for the KGPE-D16—a “Sampler Pack” would be awesome :)

And most importantly. Thank you to everyone who has devoted their time towards developing open source software. I thoroughly believe that open source devices are a very good thing for society and supporting open source helps support things like democracy, free speech, equality, and all the other good stuff.

[jtf7]

Hardware Write Protection

A number of users have had issues getting this working so here are some tips and using hardware write protection

Hardware write protection is only available on eeprom chips that explicitly support it and typically requires setting specific fuse settings appropriately to enable this function. This information is found in the manufacturer’s documentation for the specific part # of chip you intend to use.

Winbond W25Q128FVAIG

The Winbond W25Q128FVAIG is a 16MB eeprom chip capable of hardware write protection and is compatible with the KGPE-D16. This chip is physically engraved with the abbreviated text 25Q128FVIG.

Fuse Settings
Fuse settings required to activate the hardware write protection feature for this specific part number of Winbond chip are as listed below:

[S18=WPS=0]
[S14=CMP=0]

[S9=QE=0]
[S8=SRP1=0]
[S7=SRP0=1]

[S6=SEC=0]
[S5=TB=0]
[S4=BP2=1]
[S3=BP1=1]
[S2=BP0=1]

Experts can tweak these settings to fine tune the chip’s configuration however, the settings listed above have worked well for me and should work well for most users.

Connecting pin 3 (/WP) and pin 4 (GND) together with these fuse settings will enable hardware write protection. It may be required to power off the system before connecting/disconnecting these pins in order for the correct write state to be recognized.

Many users have a similar version of Winbond chip with part number W25Q128FVAIQ however, it should be noted that this alternate Q version chip is not capable of hardware write protection.

Additional Fuse Settings: Security Register Lock Bits
You may also want to set S11, S12, and S13 as listed below in order to permanently lock the security register as read-only. This is where manufacturer’s info, security related information, and hard coded data for the chip is stored. This is a separate location on the chip from where your ROM image is stored. The vibe I got from reading the Winbond documentation is that this could be a great place for backdoor related shenanigans and it’s probably a good idea to set these fuses in order to lock as read-only. That being said, I’m not entirely sure. I set mine as listed below and it worked for me however, as always, use at your own risk.

[S13=LB3=1]
[S12=LB2=1]
[S11=LB1=1]

@tlaurion I wasn’t sure where to post the info I have. Feel free to cut and paste as necessary or correct me on my improper GitHub posting etiquette. Thanks

[tlaurion]

Hardware Write Protection

A number of users have had issues getting this working so here are some tips and using hardware write protection

Hardware write protection is only available on eeprom chips that explicitly support it and typically requires setting specific fuse settings appropriately to enable this function. This information is found in the manufacturer’s documentation for the specific part # of chip you intend to use.

Winbond W25Q128FVAIG

The Winbond W25Q128FVAIG is a 16MB eeprom chip capable of hardware write protection and is compatible with the KGPE-D16. This chip is physically engraved with the abbreviated text 25Q128FVIG.

Fuse Settings Fuse settings required to activate the hardware write protection feature for this specific part number of Winbond chip are as listed below:

[S18=WPS=0] [S14=CMP=0]

[S9=QE=0] [S8=SRP1=0] [S7=SRP0=1]

[S6=SEC=0] [S5=TB=0] [S4=BP2=1] [S3=BP1=1] [S2=BP0=1]

Experts can tweak these settings to fine tune the chip’s configuration however, the settings listed above have worked well for me and should work well for most users.

Connecting pin 3 (/WP) and pin 4 (GND) together with these fuse settings will enable hardware write protection. It may be required to power off the system before connecting/disconnecting these pins in order for the correct write state to be recognized.

Many users have a similar version of Winbond chip with part number W25Q128FVAIQ however, it should be noted that this alternate Q version chip is not capable of hardware write protection.

Additional Fuse Settings: Security Register Lock Bits You may also want to set S11, S12, and S13 as listed below in order to permanently lock the security register as read-only. This is where manufacturer’s info, security related information, and hard coded data for the chip is stored. This is a separate location on the chip from where your ROM image is stored. The vibe I got from reading the Winbond documentation is that this could be a great place for backdoor related shenanigans and it’s probably a good idea to set these fuses in order to lock as read-only. That being said, I’m not entirely sure. I set mine as listed below and it worked for me however, as always, use at your own risk.

[S13=LB3=1] [S12=LB2=1] [S11=LB1=1]

@tlaurion I wasn’t sure where to post the info I have. Feel free to cut and paste as necessary or correct me on my improper GitHub posting etiquette. Thanks

@jtf7 This definitely needs proper documentation, but is more related to documentation as of now and would require automatization and love under Heads #985. Note that flashrom work has been done, and specifically for kgpe-d16 is https://shop.3mdeb.com/shop/adapters/flash-chip-adapters/asus-kgpe-d16-flash-chip-adapter/ with documentation at https://docs.dasharo.com/variants/asus_kgpe_d16/spi-wp/. Desktops with socketed SPI chips offer this capability more easily than on other platforms, limiting applicability of this solution to other platforms.

To be able to do the same with soldered in SPI chips, soldering is currently needed by end users/OEM which is why this solution is not pushed forward as of now without proper gadget easing the process.

The easier solution that was pushed on Intel for pre-Skylake is PR0 SMI enabled platform locking bits per #1373. This makes Heads the only internal flasher, where OS can read SPI but cannot write to it and where Heads prevent access to recovery shell and booting from USB without GPG detached signed authentication with either USB Security Dongle or USB Thumb drive encrypted backup of key material created at OEM Factory Reset/Re-Ownership wizard per #1515.

[lethedata]

I can test x230 (xx30) (x220 keyboard mod) and x230-fhd/edp variant (edp 1080p display)

@lethedata can you detail a little more what edp mod it is? This is what seems to be confusing for all for fhd/edp mod, even more if there is a reboot issue from OS if only difference is that edp mod, preventing shutdown of power lines on the x230 which was never reported before.

@tlaurion the mod kit I have appears to be an a.gain X220_X230 FHD RevA1.0 . Still looking into things regarding the power issue.

I compiled a small list of different mod kits and information regarding them here, will be communicating with upstream coreboot regarding any issues specific to the patch as it is out of scope for heads.

Note: Deleted comment info moved to above info page as a more appropriate location for the conversation

[pcm720]

@lethedata

I compiled a small list of different mod kits and information regarding them here.

Are you sure nitrocaster mod doesn't work with the VBT patch?
We have people with this mod using x230-fhd_edp without any issues, and coreboot's Gerrit discussion mentions nothing of the sort.

[tlaurion]

@lethedata

I compiled a small list of different mod kits and information regarding them here.

Are you sure nitrocaster mod doesn't work with the VBT patch?
We have people with this mod using x230-fhd_edp without any issues, and coreboot's Gerrit discussion mentions nothing of the sort.

@lethedata if that fact came from me and prior comment, that's my fault since I modified prior comment after revising the facts and I'm sorry for misleading you. The vbt patch is supposed to work with the vbt commit from the coreboot variant selection made from which the edp board under Heads comes from.

[tlaurion]

@lethedata

I compiled a small list of different mod kits and information regarding them here.

Are you sure nitrocaster mod doesn't work with the VBT patch?
We have people with this mod using x230-fhd_edp without any issues, and coreboot's Gerrit discussion mentions nothing of the sort.

@lethedata if that fact came from me and prior comment, that's my fault since I modified prior comment after revising the facts and I'm sorry for misleading you. The vbt patch is supposed to work with nitro aster, the vbt commt from the coreboot variant selection made from which the edp board under Heads comes from is supposed to be compatible with those mods as well, just as the patch says both upstream and downstream here.

[tlaurion]

@pcm720 @lethedata: note that comments here will be lost forever since they have nothing to do with edp/fhd per se and whatever was useful here should not only be echoed back to proper issues under Heads, but upstream to be useful to all and actionable. That is, the coreboot merge request which is still unmerged. Otherwise all happening under heads is just a small echo chamber that needs to echo to larger user base (coreboot) of that fhd/, edp mod which have issues merging it for the same reasons we are debating here with doubts:this needs to be documented properly and subsets of nods targeted by the edp/fhd limited to mods on which the patch is applicable.

Downstream is #1603

This issue is about discussions on blobs status and board owners of platforms in time. Nothing to do per fhd/edp outside of board owners.

[arhabd]

i can test kgpe-d16 see #1395 for HCL

HCL
RAM 2x Crucial 16GB CT16G3ERSLD4160B
CPU 2x AMD Opteron 6282 SE
GPU 1x GeForce GTX 650 Ti

[tlaurion]

#1723 includes a new BOARD_OWNERS.md file. Once this PR is merged, I will remove board testers from here. This issue will become more targeted at adding willing board testers (owning an external programmer) when coreboot/linux version bumps occur, removing maintainership burden of editing this with bonus of being able to track over time boards losing/gaining testers from the community.