Is it possible to flash with external programming device (such as beaglebone black as documented in other coreboot support pages.) Programming this way can set write protection and prevent certain maleware from overwriting bootloader.
An example using external programmer:
https://www.coreboot.org/Board:lenovo/x200
Is it possible to do this in Windows 10? My coreboot is corrupted and I can’t install or boot into linux it just hangs. I was only able to install and boot into Windows 10 I’m using a Librem 15 v3.
Hi @kakaroto! Now that coreboot 4.7 is out, can we possibly get a build for Librem 13v2 that includes IOMMU/VT-d support?
It would be great if my brand new librem+qubes laptop could actually… be a laptop: on v3.2 it won’t resume from suspend, and on v4 it resumes, but no VMs work without IOMMU/VT-d support. (So I’m stuck on 3.2 at the moment, fully shutting down and starting up the system any time I go anywhere.)
Thanks!
Hi @quban. We are definitely aware of the IOMMU issue (as a Qubes user myself I feel your pain) and it’s a super high priority for us to add it to the Purism coreboot image. We are actively working on it and hope to have an update soon.
I’m a hybrid at the moment. I have a personal Librem 13v1 that was part of the original crowdfunding campaign and endorsed/supported by Qubes. It still has the original AMI BIOS as coreboot wasn’t out for it when I got it. It runs Qubes 3.2 and suspends OK.
Along with that I’ve been helping test Qubes for Purism on the newer Librem 13v2/15v3 (first on the side, now as a full-time employee) and so I’ve tested both 3.2 and the various 4.0 release candidates and saw first-hand the problems you are talking about.
@quban The main problem IOMMU seems to cause in the Qubes 4 series is in the fact that everything defaults to HVM where in the past VMs were typically running in PV mode. This means after you boot none of the VMs start because they depend on the sys-net VM which, when set to HVM mode, won’t start without IOMMU because it has PCI devices assigned to it. Other than that it seems to Suspend/Resume OK and install OK (if you ignore the IOMMU warnings). I’ve had success in Qubes 4 by opening a dom0 terminal and changing the VMs that have PCI devices attached (sys-net and sys-usb) to PV mode:
qvm-prefs sys-net virt_mode pv
qvm-prefs sys-usb virt_mode pv
I tried this on a fresh Qubes 4.0rc3 install and once I rebooted my VMs came up fine. Now it’s true that you lose all of the security benefits of IOMMU in this case, but at least the VMs run and it suspends/resumes. Also, this is just a temporary workaround until we complete IOMMU support.
Is it okay to boot Debian from USB in order to flash build_coreboot.sh or would you discourage that in order to avoid a brick?
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.
Step by step guide with pictures will be appreciated by most 
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!
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!
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.
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.