@MrChromebox I looked for a way to disable hyper-threading from inside Windows but was unable to do so, how can I do it with your UEFI firmware for Mini v2?
I might also try to disable C3-C4 states if possible (and easy) because when I change the interrupt timer in Windows there’s a high pitch noise coming from the motherboard.
Also, how can I use the firmware utility script on an offline machine?
there’s no mechanism to do so, you would need to recompile
same here
it’s not set up for that unfortunately
Can you consider releasing a Hyper-Threading-off version of the firmware?
It might sound too much of a hassle but HT is still the main thing used in speculative attacks. The performance degredation (if any) is no problem to some users. Even strangely some have reported better performance with it off.
Moreover, Intel has discontinued HT if I am correct.
Please consider if you have some time and willingness. Thank you.
you can turn it off via kernel command line, the reverse isn’t true however.
I provide coreboot+UEFI builds for 100+ devices, I really can’t deal with the logistics of multiple configurations for each. My sources are on github for anyone who wants a different configuration
you can turn it off via kernel command line
Do you mean I can turn HT off after I reflash my firmware? I use a live linux os to reflash the firmware and then I shut the computer down to install Windows to the disk.
Would it stay turned off that way?
I found this:
Disable SMT/HT at boot time using the kernel command line parameter nosmt:
nosmt [KNL,S390] Disable symmetric multithreading (SMT)
Equivalent to smt=1.
[KNL,x86] Disable symmetric multithreading (SMT)
nosmt=force: Force disable SMT, cannot be undone via the sysfs control file.
Edit: If I understand you correctly, you meant typing this into the grub file: mitigations=auto,nosmt
I can’t easily see a way how it can persist a Windows install though.
If it does, would it require at least a reboot into Linux before I install Windows?
Windows won’t use the Linux kernel, so it won’t make any difference in your case.
Which would leave me with only one option: to compile and flash a Hyper-Threading off UEFI firmware (made by coreboot+seabios I guess?).
It’s above my abilities unfortunately. 
I might try my luck by e-mailing purism support. Hopefully they will be able to show me an easy way to do it.
there isn’t. If you want HT off to run Windows, you need to compile and flash your own build of coreboot, both of which will be wholly unsupported by Purism
I gave the linked Firmware Utility Script a try on my Purism Librem 13 v2. The script correctly detected the device, and happily flashed the firmware with no reported errors. It informed me that I could restart.
… Unfortunately this soft-bricked the device. The machine still POSTs, and the screen + SD card works. However none of the USB ports work, nor the keyboard. So I don’t have any way to interact with the machine.
Now I’m gonna try and figure out how to prepare an OS image that will kick off the official firmware flash utility in some kind of unattended mode on pty0 at boot.
Just a warning to anyone considering using these builds on their Librem 13 v2!
Is the Librem 13 v 4 supported?
Just in case it helps, my Librem 13v2 also became unbootable after using the firmware script. I unbricked it using AsProgrammer, CH341A, and alligator clip to write one of the official prebuilt roms onto the bios chip (near memory and wifi, maybe hiding under black tape).
Very interesting! I’ve always wanted to try my hand at something like this. Since you’ve had success with this exact model, I’m feeling inspired to give it a try.
I’m ordering this CH341a programmer off eBay. Does that standard SOIC8 SOP8 test clip look like it will work?
If you have any links/resources that helped you in this process, I’d be very grateful if you’d share them!
My CH341a programmer arrived today. I was able to successfully reflash my Librem 13 v2 to the official Librem coreboot firmware blob.
I found this post on Purism’s website (1) to understand where the flash chip was located (along with @maccelerated’s tip). The linked image (2) shows a remarkably different logic board layout compared to my v2 - my PCB is black, and a lot of minor components are in completely different locations. The flash chip was roughly in the same place, though.
I followed this Youtube video (3) to understand how to connect the SOP-8 clip in the correct orientation, and to connect the clip’s cable to the CH341a USB programmer.
I found the Purism coreboot blob at this location: (4).
Once I had everything connected, I ran this from the computer connected to the CH341a programmer:
$ sudo flashrom --programmer ch341a_spi
flashrom v1.2 on Linux 6.5.4-arch2-1 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found GigaDevice flash chip "GD25B128B/GD25Q128B" (16384 kB, SPI) on ch341a_spi.
Found GigaDevice flash chip "GD25Q127C/GD25Q128C" (16384 kB, SPI) on ch341a_spi.
Multiple flash chip definitions match the detected chip(s): "GD25B128B/GD25Q128B", "GD25Q127C/GD25Q128C"
Please specify which chip definition to use with the -c <chipname> option.
I then took a close-up photo of the chip in order to verify that my particular Librem 13 v2 had a “GD25Q128C” flash chip.
I did a test to see if I could read off the current firmware:
$ sudo flashrom --programmer ch341a_spi -c GD25Q127C/GD25Q128C -r test.rom
flashrom v1.2 on Linux 6.5.4-arch2-1 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found GigaDevice flash chip "GD25Q127C/GD25Q128C" (16384 kB, SPI) on ch341a_spi.
Reading flash...
done.
It took a couple of minutes after the “Reading flash…” before the “done.” message appeared.
$ strings test.rom | grep MrCh
-MrChromebox-4.20.1
#define COREBOOT_EXTRA_VERSION "-MrChromebox-4.20.1"
-MrChromebox-4.20.1
-MrChromebox-4.20.1
Success!
Writing the official image was as simple as running:
$ sudo flashrom --programmer ch341a_spi -c GD25Q127C/GD25Q128C -w coreboot-librem_13v2-4.21-Purism-2.rom
flashrom v1.2 on Linux 6.5.4-arch2-1 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found GigaDevice flash chip "GD25Q127C/GD25Q128C" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
I’m unable to put more than 2 links in this post…
(1): 2015-08-21 Librem 13: Weekly BIOS Progress Update – Purism
(2): h ttps://i.imgur.com/WmKq3Om.jpg
(3): h ttps://www.youtube.com/watch?v=2Y06x1f22B0
(4): h ttps://source.puri.sm/firmware/releases
@MrChromebox it would be great if you could edit your original comment and warn users to not try the unofficial UEFI builds with their v2, since we now have 2 confirmed reports that it bricks the machine to a point where hardware in-system reprogramming is necessary. Even better would be the utility script refuses to proceed for that hardware revision. If you agree with the latter I’d be happy to open a PR to make that change.
Thanks for the heads up.
Then perhaps someone from the @moderators team could amend the original post?