Sure, you could do that, although I’d suggest booting PureOS in live USB mode instead, since that’s what I tested but as far as I know, PureOS and Debian are pretty much the same.
I’m happy to announce we have successfully added IOMMU (VT-d) support into our coreboot image:
https://puri.sm/posts/qubes4-fully-working-on-librem-laptops/
We are finishing up testing and cleaning up the code a bit, and then we will publish it so you can update.
6 Likes
Step by step guide with pictures will be appreciated by most 
1 Like
I’m hoping to see officially supported instructions for setting up coreboot with the TianoCore payload.
Hey everyone!
The build script was just updated to build the newest update to coreboot. The Changelog.txt shows what has changed, with the most important/requested feature being the support for IOMMU/VT-d for all of you Qubes 4.0 users out there. The new image also adds TPM support for those of you who ordered the machine with the TPM module installed.
I’ll update the first post in this thread in a couple of days (I can’t edit it now due to a time limit for edits in the forum’s configuration), but the main changes to take note of is that there’s a new dependency that was added : python2.7. The image version is now “4.7-Purism-1”.
There should be a blog post soon that explains this release with a little more details.
Enjoy!
4 Likes
I managed to upgrade to the new 4.7 coreboot image. I had to hack around the python 2/3 thing in ME Cleaner again but since I already knew what to do that wasn’t a big deal. So far so good. My Librem 15 V3 is working just fine. Did you guys manage to fix the ATA boot up issue with this version? So far I haven’t seen any of the “normal” ATA errors from the last version (as described here: https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/)
Thanks!
Thanks for the effort and updates!
I’m having an issue running this however. I’ve gone through the thread and don’t think I missed anything, but certainly possible.
I’m on a Librem 13v2. I did a fresh install of PureOS 8, ran the apt-get steps listed above including python2.7, ran the script specifying 13v2 and then all the default options. It ran fine up until it asked about flashing. Which I responded yes to. Here is the output of that:
Built coreboot image hash matches the expected reproducible build hash
Do you want to flash the built image now (y/N) ? y
Coreboot flashing in progress. Do NOT interrupt this process.
Initializing internal Flash Programmer
ERROR!!! Error flashing coreboot!
There are a 16M coreboot-l13v2.rom and coreboot-orig.rom file in the directory.
I don’t see any obvious log files generated. Should I try to run this manually? Are there verbose options I can use if trying to run manual? I’m out of my league here with flashing ROMs, I don’t want to risk bricking this thing obviously.
Ok, so I dove a bit deeper here. I went ahead and ran the flashrom manually after understanding it a bit better.
Problem it that it is detecting that my mainboard is a 15v3 instead of a 13v2.
Manufacturer: Purism
Mainboard ID: Librem 13 v2
This coreboot image (Purism:Librem 13 v2) does not appear to
be correct for the detected mainboard (Purism:Librem 15 v3).
Aborting. You can override this with -p internal:boardmismatch=force.
This is also the output of dmidecode:
System Information
Manufacturer: Purism
Product Name: Librem 15 v3
Version: 3.0
Serial Number: xxx
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Librem 15
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Purism
Product Name: Librem 15 v3
Version: 3.0
This is certainly not the computer I have
So… not sure what to make of that. I assume that is not normal?
I can override it here I suppose given the out of the flashrom instructions, would that be recommended in this case? Or, do I have bigger issues here?
Yes, actually! I forgot to add that to the Changelog. I’ll do that now, thanks for reminding me! Yes, with the FSP 2.0 update, there’s a new option to limit the speed of the ATA bus to 3Gbps, this makes it limit the speed properly instead of just changing it in Seabios with Linux resetting it to 6Gbps. This removes all of the errors you saw before.
Why not install python2? Did you get any issues with running the SplitFspBin.py script as well ?
Very good point. I should definitely make it save a log file for the flashrom process at least, specifically for cases like yours. It does sound very scary indeed, especially if the flashing failed, you don’t know if you could reboot (or even suspend) your laptop without bricking it.
argggg, one of those again… actually, it’s a new “issue”, I’ve seen a few L5v3 laptops “in the wild” that appear as being L13v2 but this is the first time I see a L13v2 appearing as a L15v3. That’s fine, it’s a “human bug” in the supply chain or something where the technician flashing coreboot mistakenly flashes the wrong image. Thankfully, there are no big differences between the L13v2 and L15v3 (other than the name that appears in dmidecode and USB port configuration so some USB ports may or may not work correctly).
That’s actually the big reason why I ask in the script to choose which machine it is, rather than try to detect it automatically using dmidecode (Even though that would be safer). The real danger would be to flash the librem 13 v1 image on a v2, or vice versa, but yes, in your case, go ahead and use the boardmistach force argument to flashrom and fix your machine!
/me adds reminder to fix this use case in the script…
Makes sense. Definitely got a vote from me on it now!
Success, verified!
…And, now I also have Qubes 4.0rc4 running. I’m beyond excited today!
Thanks so much for the effort here with coreboot and being on top of issues in the forums too!
1 Like
I do have python 2 installed. On Arch Linux though python2 lives at /usr/bin/python2 instead of /usr/bin/python which is where python 3 lives. /usr/bin/python is referenced in the top line of the me_cleaner.py script. Changing it to python2 temporarily “resolves” the issue for me however.
1 Like
Ah ok, thanks for the info. I’ve fixed it now in the script.
For the SplitFspBin.py I was using ‘python2 SplitFspBin.py’ already, that’s why you had no issues there.
1 Like
Thanks for the hard work!
Quick note in case anybody runs into the same thing:
When I first ran tpm_version after updating it did not work. I don’t remember the exact error message now, sorry.
But, once I entered the ‘t’ option at the boot menu, then hit esc, no need to actually do anything, just enter the menu. Now my tpm_version is showing the appropriate info.
Quick confirm: Coreboot updated just fine on my 13v2, Running Qubes 4 rc4 right now without any problems so far. Thanks a lot Mr. Alaoui! 
I tried executing the script on my Librem 13 running Archlinux.
I am 90% sure I have Librem 13 v1 – but don’t know how to verify this.
When running the script I get an error message that i don’t understand. Does it mean I have not installed all dependencies, or does it mean something different?
Enabling flash write… Error accessing ICH RCRB, 0x4000 bytes at 0x00000000fed1c000
/dev/mem mmap failed: Operation not permitted
FAILED!
FATAL ERROR!
Unhandled programmer parameters (possibly due to another failure): ich_spi_mode=hwseq
Error: Programmer initialization failed.
When prompted I said:
1: Librem 13 v1
and
1: extract from current machine
Any hint is appreciated.
You need to be 100% sure because if you flash the wrong image, the result is that your laptop won’t boot anymore and you’d need to open it up and use a hardware flasher and a SOIC8 clip connected to the motherboard to re-flash the BIOS ROM.
Ways to verify if it’s indeed a Librem 13 v1 or v2 :
- The L13 v1 has no markings in the bottom cover, while the L13 v2 has “Librem 13 v2” written on it
- The L13 v1 coms with a Broadwell chipset while the L13 v2 comes with a Skylake chipset (cat /proc/cpuinfo and check which model of CPU you have)
- If you received the machine originally with AMI BIOS, then it was a Librem 13 v1, if you received it pre-flashed with coreboot, then it was Librem 13 v2
- You can use dmidecode to see it using the command : sudo dmidecode | grep “Product Name”
Once you verify that all of the conditions above are consistent and that you do have a Librem 13 v1, then you can select it. I would like to also mention that the 4.7 release is only for Librem 13 v2 and Librem 15 v3. We are still working on bringing the update (as well as porting the IOMMU implementation to Broadwell) to the librem 13 v1. You can do ‘sudo dmidecode -t 0 | grep Version’ to see which version of coreboot you currently have. I have updated the script to show which version it’s going to build. If you already have the last version, then you don’t need to rebuild/flash it.
As for your error with flashread, the issue is that the kernel is preventing access to some MMIO registers as a way to increase security, and that makes it impossible to read or write the flash. You can fix this by rebooting and adding ‘iomem=relaxed’ to the kernel boot arguments in grub. You can read more about it here : https://github.com/purism/purism-librem-coreboot-updater/issues/6
This is the kind of thing that makes us say that the build script is not really ‘user-friendly’, the real updater script is supposed to add a systemd target, reboot into it with the proper configurations to prevent this kind of issue, verify everything for you, then install coreboot and reboot again. Besides the updater script is supposed to just update coreboot, not re-build it.
Hi avog, keen to understand what steps you took to make this work in Qubes 4 rc4.
I’ve been able to update coreboot using pureOS live USB on my purism 15v3 running Qubes 4-rc4 and all seems to be ok so far. Great job to those working hard to keep us happy.