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.
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 :
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.
Hi, I’m getting the ’ hash does not match as expected ’ error and have been advised to ask here. Can you please advise how I can resolve this? I’m using Librem13 v2.
Hi,
Depending on when you downloaded the build script, it might be possible because I was updating the git branch yesterday and there was a short interval of time (an hour or two?) where those who downloaded the script would have generated the image with the wrong hash. I have updated the script since then with the new and proper hashes and it should work. Please re-download the script and re-run it to see if it works now.
If it doesn’t, can you upload the resulting file (coreboot-l13v2.rom) somewhere for me to look at ?
Thanks for your reply and for your time. I tried this about 4 days ago and have just tried again today with the same error. I have uploaded the file here as requested.
Thank sim for sending over the file. You can delete it now from the server.
the major difference that I see is mostly in the revision of the image :
- #define COREBOOT_ORIGIN_GIT_REVISION "83ed1b0f01"
+ #define COREBOOT_ORIGIN_GIT_REVISION "83ed1b0"
What is the result that you see if you type ‘git describe’ in the coreboot directory that the build script created ? Also, what’s your version of git because I think that’s probably what’s causing an issue. Here is my result :
$ git describe
4.7-12-g83ed1b0f01
$ git --version
git version 2.14.3
I have also tried it on the latest PureOS which has a different version and it gives the same result :
$ git describe
4.7-12-g83ed1b0f01
$ git --version
git version 2.16.1
I think once I get your git version, I could set a minimum git version requirement to avoid others encountering this issue that causes the hash mismatch.
After the update to coreboot 4.7-1, my fan seems to act up more often. I tried to set its threshold to a different value, given that the temperature that is being read out by the hardware monitors sometimes (when connected to the power supply) overshoots by more than 30 degrees, kicking the fan into a frenzy. However, lm_sensor cannot find any fans, and none of the suggestions I’ve found pointed me to the fan’s location.
Hence, my question is twofold:
Is this a known problem relating to coreboot/Librem laptops, or just some random error?
Will access to the BIOS be possible in the future? Right now, I just get errors, and fixing these things usually starts at the BIOS-level.
I get the following;
$ git describe
4.7-12-g83ed1b0
$ git --version
git version 2.7.4
I did run the command outlined in the OP to ensure I had all dependencies required to build coreboot. From this it seems I may be using an older git version. I update my machine daily so it must not have been added into my available repositories yet.
If I update to git version 2.16.1, will this allow me to upgrade coreboot?
EDIT: I went ahead and updated to git version 2.16.2 and was then able to successfully upgrade coreboot. Thanks again kakaroto for your time.