Did I miss a easy to identify statement that and when the Coreboot update for older (like Librem 13 v1) products will be available?
This would be a strong statement that the customers of that versions will indeed receive something that was promised from the beginning. Not like the keyboard-layout that never what delivered nor compensated.
The librem 13 v1 coreboot image is ready and you should be able to give it a try by doing as @mladen suggested (the iomem=relaxed boot option or boot into the old 4.7 kernel if you still have it on your boot menu) then run the script.
The one that gets installed when you do sudo apt-get install purism-librem-coreboot-updater is I think outdated, but you’d need to install it so it can bring all the dependencies with it.
The reason that this has not been publicly announced yet is because we need to go through a round of beta testing first, just to be extra sure there are no issues. I was also caught up on testing NVMe support which seems to be working fine apart from one user (who is also having issues on the original BIOS, but I don’t know if it’s a problem with his NVMe drive or it’s something that can be fixed in coreboot).
The librem 15 v2 coreboot port is not yet done, as it was a higher priority to get the latest hardware working so they can be shipped with coreboot preloaded on them. But I’ve learned so much in doing these ports that I don’t expect the L15v2 port to take very long (probably a day or two).
Wow, if one day there would be coreboot for the L15v2, that would be just amazing! Actually, I’d already given up all hopes, now I’m dreaming again!
On a side note for those not running PureOS: on new kernels, there is a new safety feature that forces you to recompile your kernel in order to be able to flash the bios. Since the encrypted partitions support was buggy (at least in Debian), that means that a newly compiled kernel can not support your encrypted partitions. As you’ve guessed, that makes it a complete mess. So the easiest option might be to keep a PureOS partition for this purpose.
Humm… that’s a good point, I hadn’t thought of that and thanks for bringing it to my attention. No, the purism-librem-coreboot-updater hasn’t been updated yet (and won’t be for a few more weeks as there’s a lot of work needed on that script before it’s ready) and looking at the build script, it indeed expects coreboot to be already installed otherwise it doesn’t work. What I used during my testing was a librem 13 v1 coreboot image and I select the “Extract from a pre-built coreboot image” option in the script.
If you can hack around the updater script to make it build the librem 13 v1 image (and NOT flash it), that would work. Otherwise, I guess you have to be a little more patient while I sort out this mess.
Well, I must say that the CoreBoot update of my Librem15v2
is a SUCCESS !!!
I was a bit scared before launching the flashrom command, but what a relief to see the Purism logo at reboot !
The idea to start with the L13v1 coreboot dump was good.
The only thing, due to a SHA mismatch, I had to manually copy the extracted vgabios.bin to the blobs dir.
The build_coreboot script then happily constructed a new coreboot-l15v2.rom
Now I need to change the boot order to have it boot from nvme instead of hdd…
Without either a Librem13 or the binary blobs, I could obviously not test CoreBoot on my Librem15v2. But at least, I have some initial feedback:
* if no git user and email was configured, the script fails (some files are missing, so building the cbtools fails with a missing include). It would be nice to at least warn the user to do so before running the script. For those who ended up with such a failure, the git checkout has to be deleted before running the script again (otherwise, it still fails);
* for those of us not having anything to extract the binary blobs from, don’t you think that Purism could provide the said binaries? In terms of security, this is not worst than the current situation (since the same stuff is already packaged into the AMI Bios, so if Purism wanted to mess up with us, it would have already been possible). That could be a temporary solution at least, until something better gets set up.
PS: since I am using Debian and since flashroom is a not usable without a special kernel, I created a temporary PureOS partition to prepare and install Coreboot. Therefore, I had not already defined a git user…
No, this is not specific to Librem, this is because of the CONFIG_IO_STRICT_DEVMEM kernel option (for example, see https://libreboot.org/faq.html#flashrom-complains-about-devmem-access). It was for a while possible to pass the iomem=relaxed kernel command line argument but on newer kernels, this command line argument is not supported anymore (as it could be used as the first step in an attack). Unless this has changed again, you would have to recompile your kernel in order to allow flashrom to operate…