Building coreboot from source (official script)

Go man go! Let us know if u brick or win


Two questions about coreboot, Intel ME disablement and the Librem 15v2.

  1. I recall having the impression that coreboot was not going to work but the Intel ME could possibly be disabled in the 15v2. If this is correct, can you point me towards info that would let me start learning how to do this?
  2. I keep wondering when the coreboot development for 15v2 will begin. It’s felt like it might be just around the corner for some months now, which tells me I had the wrong expectations. Is there much more to go before that can usefully start? Or is there a particular milestone in porting coreboot to the other systems I should look for to know user testing on the 15v2 can usefully start?

Sorry about the 2nd question, just feeling a bit lost on where we’re at with it and that doesn’t pair well with having a lot of interest in the end goal.

Thanks for the script.
Could you please provide some way of checking the authenticity of it (I know I could read it to see whether it is malicious, but then I still need to trust the hashes contained in it).
I would like to upgrade coreboot to get the disabled ME, but I am reluctant to run an untrusted script downloaded from the internet with root privileges.

yeah, there is a chance. I’d suggest you read carefully all of my previous technical blog post on coreboot just to get familiar with the whole thing. You can find my posts on the right sidebar here :

Well, both coreboot and ME disablement would work on the l15v2, but the ME disablement would be much easier to achieve than the coreboot port, since all you’d need to do is run me_cleaner on it. So ‘steps’ would be : flashrom to dump your ME, run me_cleaner on the rom (use -s to tell it to set the disable bit), then flashrom to flash it back. Then reboot and cross your fingers and start praying that it doesn’t brick it.

Yeah, I don’t know ‘when’. And no, you didn’t have the wrong expectations, because yes, it also felt like it’s right around the corner for me too. I did do one attempt at it. Did the port, thought it would work, flashed it, it bricked the l15v2 that I had. I restored it with the hardware flasher, and was trying to understand why it failed to boot from the log files I had, but didn’t finish that and got sidetracked by something else. For now, I think that the priority is on other tasks and I haven’t had time to go back to that work. It’s really all about man power and how much stuff I can achieve every week. So… “when” will it start… I have no idea, for now my priority is on the FSP reverse engineering, so maybe if enough l15v2 users start bugging us about the coreboot port, the priorities will change.
It’s not that we don’t want to do it, it’s still planned, but since l15v2 isn’t being sold anymore, I think the priority will most often go to the current products in favor of retrofitting older products.

The script builds coreboot from source. You can either trust the script and trust the coreboot source code, or you can read the source to know what it does. The hashes contained in it are just the hashes for the binary blobs themselves, there is nothing that can be checked on those (we don’t know if they are malicious or not) and those files are taken directly from your own machine. The only other hash is the resulting binary of the coreboot rom file after it gets built from source. You don’t need to trust that hash, you only need to trust the source code of coreboot, since the hash verifies the result of the compilation from source.

As for the root privileges, you don’t need to run it as root, but it will call ‘sudo’ for a few commands. You can look up ‘sudo’ in the script, there are 3 instances of it, first is the call to ‘flashrom’ to dump the rom (to extract the binary blobs from it), then a call to ‘sudo dmidecode’ which is used to get the serial number from your current machine, then a final call to ‘flashrom’ to write the built coreboot rom into the flash. The rest is executed without root priviledges, and I usually run it as a normal user.

1 Like

Could you incorporate more recent updates from ?
I fear bricking the device when compiling from mainline but need the librem13v2 fixes.


I was waiting for the coreboot 4.7 release (which was supposed to be last month but got delayed due to lack of time) before I update the script/build and make a new release of coreboot for the librems. I don’t want to make an update to a ‘random’ commit from git then another one a few days/weeks later when coreboot 4.7 is released.

1 Like

Release early, release often :slight_smile:

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:

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.)



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.


Great - thanks!

(so @Kyle_Rankin do you run 3.2 and shut down? 4.0rc1? never turn it off?)

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 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.

1 Like

I’m happy to announce we have successfully added IOMMU (VT-d) support into our coreboot image:
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 :slight_smile:

1 Like

I’m hoping to see officially supported instructions for setting up coreboot with the TianoCore payload.

Thanks @Kyle_Rankin that virt_mode pv did the trick for now!

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.