Successfully ran the script and flashed coreboot on my Librem 13 v4 running NixOS 19.03, by applying some minor expected tweaks. I used the command below:
The first call will fail since the script pulls a binary build of cbfstool from Purism, however, we can patch it in the standard NixOS way 1 (I am pretty sure we could use the cbfstool Nix package, but I am not taking any chances when flashing hardware).
This of course will change the hash of the binary, so then remove the cbfstool hash check from coreboot_util.sh. Now run the first command again and it will succeed. Note that this will only work if you are flashing with the binaries provided by Purism, some more hacking is needed to build from source. It would be tempting to package this properly at some point, but for now I am content not to have to boot a more standard Linux distribution from USB to update the BIOS.
I could add a check in the script to use the host cbfstool, like I do with flashrom – it just didn’t occur to me at the time.
A fair suggestion, but given how clean the code was, I really should not complain. I actually assumed that the reason you did not use the same strategy for cbfstool as for flashrom was that the former did not give a clear version when called with -h.
hash check is for the compressed download, not the binary therein, so this isn’t needed
Admittedly, it is the middle of the night, but I think this line 1 does check the hash of the tool/cbfstool binary itself. Mind you, the archive is checked as well 2, just like you said.
While we wait for “Submit firmware to “Linux Vendor Firmware Service” (LVFS) for easy updating”, I have tried the manual update process. It’s kind of scary: it’s basically curl https://puri.sm/something | sudo bash seemingly without any cryptographic verification beyond HTTPS. I would have expected some validation like OpenPGP signatures or something more at least. But let’s leave that aside for the moment.
I’m writing here to report a regression that was introduced in this upgrade. I’m having a bit of trouble figuring out which version I updated from (I seem to remember I was running SeaBIOS 1.11) but since the upgrade (to SeaBIOS 1.12), the resolution of the splash screen is a little out of whack. While the first Purism logo that pops up after the SeaBIOS bit used to be all nice and shiny, now it’s bigger and blurry. It looks like the resolution of the display doesn’t get initialized properly. This also affects my grub display, which is “bigger” than it was before, and also leaves a blank aread on the right of the screen.
I’d be happy to provide screenshots or videos – although I’m not sure how to do that at boot time short of using an external camera – if you tell me where to put those (here?)…
It’s not a deal breaker: the machine still boots and the display is readable. It’s just too bad because it was looking much better before and it doesn’t feel like much of an upgrade at all.
(It would be great if the updater script would also show which versions we’re upgrading from and to, along with release notes, by the way…)
Thanks in advance,
PS: I’m writing here because that’s what i was told to do in the coreboot post, let me know if I should send this somewhere else.
With the 4.11 release, we switched from using the VGA BIOS to coreboot native display init. One of the side effects of this is that a single fixed resolution is used from firmware display init until the OS driver takes over. Under the VGA BIOS init, the display would change modes/resolutions several times throughout the boot process (640x400 for SeaBIOS banner, to 1280x1024 for boot logo, back to 640x400 for boot menu/boot text, then to whatever grub specified); now, there’s a single mode change from firmware init (480p) to native panel res (1080p or 2160p).
Since we’re locked into a single resolution for boot, I decided to try and keep the SeaBIOS menu text close to the same size as before, and scaled the boot logo down to match. If enough people disagree with that approach, it’s something we can look into changing
Awesome. I was expecting something like this, I just wanted to make sure it wasn’t a weird regression. I personally preferred the older setting (native panel resolution) but it’s fine to leave it that way too.
I didn’t know I could configure grub to have the right resolution. A vanilla Debian install doesn’t do such things by default – for obvious reasons: it wouldn’t know which res to set – so I like the idea that the BIOS sets the right resolution out of the box and grub just picks on that. That way there’s (the possibility of) no flicker in the entire boot process as soon as the first splash screen comes up…
we weren’t using native panel res before, because the VGA BIOS can only set VGA text mode (640x400) and VESA 2.0 modes, not any extended modes (which is why we used 1280x1024 for the boot logo – was the highest option available). Personally, my preference would be to set the boot resolution to 720p or 1080p and deal with the smaller text
I run into issues after upgrading with your script for a librem13v2 :
The resolution is weird, ok, but it’s not all, for running a pureOS live, grub now print in a square, black outside.
I am also now totally unable to use a MX19 live as graphical fails.
I updated from the latest pureOS. I tried update and compile from source for the same result.
I noticed than my computer is now unable to understand well a sudo shutdown +0 or the reboot at the end of the script : screen will go black but there is nor reboot nor shutdown…
I dunno if this is related … dmesg prints this [ 1.718544] i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
If there is no others solutions at my scope, can I use the old script for getting back my old coreboot which was functional?
grub is using a 640x400 frame inside of the 848x480 screen. That’s normal/expected with the new native display init
well, that’s more on MX for assuming graphical capabilities vs querying what’s available, but I understand from the user perspective it doesn’t really matter whose fault it is. I’ll test and see if I can come up with a workaround
good! the sha256 hash is supposed to be the same for both the precompiled and built-from-source options. That’s the whole idea, you can validate what we’re providing.
doesn’t sound related to the firmware update at all
it’s not related, and it’s completely normal/expected when running PureOS. It’s telling you it couldn’t load an optional driver blob (because PureOS doesn’t use/include them)
of course, everything is available on our gitlab repo. I don’t expect that reverting to the previous version will resolve most of your issues though.
Some feedback about the last version of coreboot/SeaBIOS.
The version I still have is from March 2019. I wanted the fix for the SATA speed.
As I setup my Librem 15 V.3 again anyway, I decided to update the BIOS again as described at https://source.puri.sm/coreboot/utility
In short, the process worked flawless, but the software had problems.
I have two disks in my Librem (NVMe 1. disk and AHCI/SSD /dev/sda as 2. disk). Apart from the already described reduced display size for GRUB in the top left corner, the latest BIOS version was no longer able to boot from the 2. disk /dev/sda. I had PureOS installed on a partition on the second disk and it worked with the old BIOS. Even giving the full 2. disk in a new PureOS installation didn’t work after the change. If I selected the 2. disk to boot it hanged. I don’t know if that was related with the SATA problems.
Anyway, I had a backup of the old working ROM and reverted back to it. Now everything works as usual again.
I have Librem 14 with coreboot/seaBIOS and when I do sudo bash ./coreboot_util.sh in order to update firmware using precompiled images (either coreboot/seaBIOS or coreboot/Heads) I get Unhandled programmer parameters: ich_spi_mode=hwseq.
Here’s the full log:
flashrom v1.2 on Linux 5.10.0-6-amd64 (x86_64)
flashrom was built with libpci 3.7.0, GCC 9.3.0, little endian
Command line (7 args): /usr/sbin/flashrom -p internal:ich_spi_mode=hwseq -w ./firmware/pureboot-librem_14-Release-17.1.rom -V -o ./flashrom-20210520-194517.log
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
/sys/class/mtd/mtd0 does not exist
Found candidate at: 00000500-00000528
Found coreboot table at 0x00000500.
Found candidate at: 00000000-000004c4
Found coreboot table at 0x00000000.
coreboot table found at 0x99b76000.
coreboot header(24) checksum: 80ab table(1196) checksum: e8d5 entries: 37
Vendor ID: Purism, part ID: Librem 14
Using Internal DMI decoder.
DMI string chassis-type: "Laptop"
Laptop detected via DMI.
DMI string system-manufacturer: "Purism"
DMI string system-product-name: "Librem 14"
DMI string system-version: "1.0"
DMI string baseboard-manufacturer: "Purism"
DMI string baseboard-product-name: "Librem 14"
DMI string baseboard-version: "1.0"
W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect.
Active config mode, unknown reg 0x20 ID: 85.
Found ITE EC, ID 0x8528, Rev 0x0a on port 0x2e.
WARNING: No chipset found. Flash detection will most likely fail.
Super I/O ID 0x8528 is not on the list of flash-capable controllers.
No board enable found matching coreboot IDs vendor="Purism", model="Librem 14".
========================================================================
You seem to be running flashrom on an unknown laptop. Some
internal buses have been disabled for safety reasons.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See the manpage and https://flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
========================================================================
Unhandled programmer parameters: ich_spi_mode=hwseq
Aborting.
Error: Programmer initialization failed.
Also, I tried to setup boot order using the script, got the same error. Any ideas what I’m doing wrong?
@juro is this running PureOS? The script appears to be using the built-in flaashrom 1.2, which does not support the Librem 14’s platform (Cometlake). It should recognize this and download/use an updated version of flashrom. If that’s not happening, then there’s a bug in the flashrom version logic in the script that I need to fix
edit: took a look and found the issue. Re-download/re-run the script and you should be good to go now
I have coreboot/Heads on my L14 now. I’ve tried to install Guix, but it seems it doesn’t work well with Heads and I can’t boot after the installation. I installed Guix on a different SSD and keep the original SSD with PureOS just in case. So I’m trying to switch back from coreboot/Heads to coreboot/seaBIOS (precompiled images). I’m using the original SSD with PureOS and tried to sudo bash ./coreboot_util.sh which gives me:
flashrom v1.2-116-gc64486b on Linux 5.10.0-6-amd64 (x86_64)
flashrom was built with libpci 3.7.0, GCC 10.2.1 20210110, little endian
Command line (7 args): ./tools/flashrom/flashrom -p internal:ich_spi_mode=hwseq -w ./firmware/coreboot-librem_14-4.13-Purism-2.rom -V -o ./flashrom-20210523-105823.log
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
Found candidate at: 00000500-00000528
Found coreboot table at 0x00000500.
Error accessing high tables, 0x100000 bytes at 0x0000000099b75000
/dev/mem mmap failed: Operation not permitted
Failed getting access to coreboot high tables.
Using Internal DMI decoder.
Error accessing DMI Table, 0x1000 bytes at 0x0000000099b40000
If running PureBoot firmware, the script will prompt you to copy the update to USB and to update via the Heads menu option.
The script doesn’t prompt me to copy the update to USB. I guess the firmware was built correctly and just needs to be flashed from Heads?
Edit2: After adding iomem=relaxed to grub (howto do it) and flashing it again, it worked, so I’m back to coreboot/seaBIOS (however, I thought I would flash it from PureBoot using USB stick).
let me see why that’s not working properly, the script shouldn’t prompt you to flash at all if you’re currently running Pureboot, because you’re supposed to flash from Pureboot itself
edit: seems we relaxed things and the script will allow you to flash from Pureboot to coreboot from within the script, but we should probably check that flashrom isn’t going to fail due to kernel memory access restrictions
