Sounds like a quite strange versioning scheme to me…
According to the script it’s spidey sense told it that my Librem was a 13v3 - I confirmed that by picking the default option. When I used the script the second time it’s spidey sense told it that my Librem was a 13v2, this time I didn’t confirm that, I picked option 4 (Librem 13 v3).
I don’t know the background of that versioning decision but since the product name is used for example in udev rules it may be a good idea to be consistent with that, even if there’s no real difference.
I notice that links is hardcoded in official script. It means that i need to redownload script to get new updates. How to check coreboot updates more easily that redownloading script?
Maybe it would help you to generate an account on https://source.puri.sm/ . When you’re succefully logged in to your account you can go to the repository of coreboot and select the little bell at the top of the projects detail page to watch the project.
Maybe you also need to change Global notification level in your settings settings to Watch. (I’m not that much of a Gitlab geek to know for sure…)
You’ll get notfiied to the email address you registered with if anything on this project changes.
it simply provides a digital record of the device serial, in case it’s needed for support purposes, and in case the sticker on the bottom of the unit is removed/worn. There are additional stickers inside the unit, but this allows for retrieval (via dmidecode) without having to open the unit.
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.
