We have released PureBoot 28 with many improvements, particularly for high resolution displays. Prior-generation devices like Librem Mini v1 and Librem 15v4 improved as well. Update now using our update instructions!
In addition, we have been working to upstream PureBoot’s functionality back into Heads. Purism works with upstream projects rather than carrying patches downstream to ensure a long support life for all of our products.
Purism is dedicated to lifetime updates for your devices that make them better, not worse.
In our last major release, PureBoot was carrying a number of downstream features. Basic mode, Restricted Boot, Mini automatic power-on, and root file hashing were among the features we had added downstream. This added up to over 2600 lines of changes outside of our release build scripts, altering 67 files. In some cases, it wasn’t clear initially whether the feature made sense for the upstream project, so we added it downstream to gain field experience. In others, PureBoot had already diverged so significantly that developing the feature upstream would have nearly been a complete reimplementation.
Following the PureBoot 27 release, Thierry Laurion, as Heads maintainer, agreed that all of these features were suitable for upstreaming, and suggested creating a PR to review everything. (Huge thanks to Thierry for supporting this effort!) The result was PR #1419, a pull request containing all of the new features from PureBoot. Only our release scripts and branding remained downstream.
We found and fixed a number of minor issues during the review process, which is an additional benefit of upstreaming our work. In some cases, we added build-time configuration to control tweaks to UI that Purism introduced. We reworked AVX2 optimizations in fbwhiptail for L1UM v2 to use AVX, which benefited many other devices supported by Heads.
With PureBoot and Heads once again in sync, our next headlining feature was implemented upstream first, benefiting all high-resolution devices supported by Heads!
PureBoot 28 now only contains 281 lines of changes outside of our release build scripts, compared to 2669 in PureBoot 27, an 89% reduction! We will send the changes from the PureBoot 28 release cycle upstream as well.
PureBoot 28 features improved high resolution support, mainly for Mini v1/v2. In prior releases, using a 4K display or TV resulted in a tiny font on the recovery console. PureBoot now increases the console font size, so the text is legible without a magnifying glass.
Graphical menus with fbwhiptail forced a 1920x1080p mode on 4K displays, which resulted in mode switching every time a menu appeared or disappeared. On many displays, this takes several seconds, and on a few it did not work at all. fbwhiptail now renders at 2x scale on 2160p, so the menu is legible, sharp, and fast. The scale factor depends on the display mode, so resolutions like 2560×1600 will display at 1.5x, and so on. This works on Mini v1 as well as v2.
Librem 15v4, which has a 3840×2160 internal panel, benefited as well. PureBoot previously forced a 1920x1080p mode on this device for both console and fbwhiptail, which was readable but a bit blurry. Since 3840×2160 now works well, the console and fbwhiptail now render at the native resolution with 2x scale.
After the release of PureBoot 27, we received a few reports of OSes failing to boot with it. The common factor in each report was a 4K display. Once we identified that, I moved my Mini v2 over to a 4K TV and finally reproduced the problem.
When booting an OS, a “memory map” from firmware tells it about memory – what addresses point to memory, what addresses point to devices, and the location of special memory that it shouldn’t touch. When booting with a 4K display, the firmware didn’t tell the OS to reserve the framebuffer. Linux would often try to use it as normal memory. Writing to the framebuffer corrupted that memory and resulted in various unpredictable crashes early in the boot process.
To test this hypothesis, I ran memtest86+ with the 4K TV attached. I had done this for PureBoot 27, but only with a 1080p display. Sure enough, memtest86+ tried to test the framebuffer like normal memory, which failed as it overwrote its own test data. The patterns were visible on the display, which is a neat visualization of memtest86+’s tests.
This was introduced by the framebuffer boot support added in PureBoot 27. This started using the framebuffer created by the Heads kernel’s i915 driver as the “firmware framebuffer” for the OS. We had already found other problems with this strategy, as Linux’s i915 driver is not designed to hand over its framebuffer to another kernel.
We now have coreboot initialize graphics using its built-in graphics initialization. That framebuffer is provided to the Heads kernel, and then to the OS kernel as well during boot. The Heads kernel now only has a framebuffer driver (efifb), it no longer needs video hardware drivers or the Direct Rendering Manager. This works correctly with all displays we tested, including 4K.
Upstream support enables Librem devices to receive the latest software and firmware, even as newer devices become available. Purism works with upstream projects for broad support of our devices and features. With PureBoot 28, PureBoot and Heads are once again closely synchronized, and we’re continuing to develop for upstream first.
(Made in USA)
|Librem Mini||In Stock|
|Librem 5||In Stock|
(Made in USA Electronics)
|Librem 11||In Stock|
|Librem 14||New Orders Shipping in October|
|Librem Server||In Stock|