diff --git a/site/news/10.md b/site/news/10.md index 295cdbe..73bef06 100644 --- a/site/news/10.md +++ b/site/news/10.md @@ -103,7 +103,7 @@ mission today is exactly the same as it was then: to provide free boot firmware that normal people can easily use. Something that normal users don't have to think about, that *Just Works*, with regular updates. Clean, simple and professional, with clear documentation. Coreboot documentation today is -much better, but it was very poor quality in 2013 (mediawiki site with lots +much better, but it was very poor quality in 2013 (MediaWiki site with lots of errant pages, poorly organised). It came with a twist: Libreboot initially complied with the FSF's own RYF @@ -119,7 +119,7 @@ project, coreboot does require binary blobs on some boards. More on this later! Since the project was nameless until February 2014, early promotion of my work was talking only about my company and about the FSF endorsement of it; Minifree used to be called Gluglug, hosted at `gluglug.org.uk` (you can check it -in the wayback machine. The shop itself was on `shop.gluglug.org.uk`). For +in the Wayback Machine. The shop itself was on `shop.gluglug.org.uk`). For example, [this video](https://www.youtube.com/watch?v=08HKcH2GguE&t=1565s) talked about the ThinkPad X60 running Libreboot 20131212, but I only retroactively named that to Libreboot in February 2014, so that video is @@ -153,7 +153,7 @@ files behave similarly to BASH scripts, with similar syntax and overall logic flow/style. It is an extremely configurable bootloader. GRUB revolves around the shell, which is basically an extension of the Bash -shell, adapted for use in a multiboot context. GRUB is the reference multiboot +shell, adapted for use in a Multiboot context. GRUB is the reference Multiboot implementation, which boots Linux. Libreboot provides GRUB so that it can directly boot Linux kernels. GRUB has many advanced features, such as GPG and LUKS support, and it has support for virtually all of the major file systems in @@ -179,7 +179,7 @@ Libreboot's initial no-binary-blob policy meant that SeaBIOS could not be used. SeaBIOS then was the most popular payload, and the default one in coreboot, at least on x86. Although SeaBIOS is free software, it did not have a free video BIOS back then. Coreboot's native video initialisation was developed at around -that time, for intel video chipsets, providing a basic framebuffer, but no +that time, for Intel video chipsets, providing a basic framebuffer, but no video BIOS services, so operating systems like Windows could not boot (and they still cannot, on most Libreboot setups). @@ -189,7 +189,7 @@ on top of the coreboot framebuffer, but this capability did not exist in 2013 when Libreboot started. So, SeaBIOS could not be used in Libreboot then. Libreboot provided just the coreboot framebuffer, then loaded GRUB, which then loaded Linux; Linux itself could interact with the coreboot framebuffer, -and the intel video driver (`i915`) sets modes directly, so it doesn't need +and the Intel video driver (`i915`) sets modes directly, so it doesn't need BIOS INT10H or UEFI GOP services for video-related functions. In Linux, your video drivers just write to a framebuffer directly in memory. No abstractions. This feature, called KMS (Kernel Mode Setting) was later ported to the BSDs, @@ -348,7 +348,7 @@ like `me_cleaner` (which strips out code from the ME, usually leaving only the bringup code intact) existed. On the GM45 machines, [Intel ME](https://en.wikipedia.org/wiki/Intel_Management_Engine) is usually disabled on most vendors, but Lenovo provided it because their -machines came with Intel gigabit ethernet, which requires an Intel Flash +machines came with Intel Gigabit Ethernet, which requires an Intel Flash Descriptor and Gigabit Ethernet config in the flash; Intel's standard setup here is to then provide the Intel ME, in two separate versions: a 1.5MB version without [AMT](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology), @@ -358,25 +358,25 @@ The X200 was always possible to use without Intel ME, because the ME only handled AMT and [TPM](https://en.wikipedia.org/wiki/Trusted_Platform_Module) on that platform, which are not required for boot, but the only known way at that time was to flash a *descriptorless* setup, which -meant that you would lose use of the Intel gigabit ethernet. This didn't seem +meant that you would lose use of the Intel Gigabit Ethernet. This didn't seem all that useful for Libreboot users, who expect everything to just work. Steve reverse engineered the Intel Flash Descriptor, finding disable bits in it that put the Intel ME into a permanent reset loop. In this configuration, the ME bootrom does not load any firmware from the flash. The full ME firmware otherwise goes in the main boot flash, alongside the BIOS software (e.g. -coreboot). In Libreboot, the intel ME firmware is excluded on GM45 hardware. +coreboot). In Libreboot, the Intel ME firmware is excluded on GM45 hardware. I worked with Steve between October 2014 to mid-January 2015. Steve provided -instructions for disabling the intel ME in the ICH9M flash descriptor, and +instructions for disabling the Intel ME in the ICH9M flash descriptor, and wrote a proof of concept utility that would take a *factory* ROM image dump, for instance X200 LenovoBIOS dump, and create a file containing just -the descriptor and gigabit ethernet config, but without the intel ME. That +the descriptor and Gigabit Ethernet config, but without the Intel ME. That utility was called *ich9deblob*. Under Steve's guidance, I wrote a utility that would *generate* an ICH9M descriptor from scratch. I then studied the datasheets for Intel's gigabit NIC, -writing a tool to generate the ethernet config from scratch. I had a new program +writing a tool to generate the Ethernet config from scratch. I had a new program written by around mid-January 2015, and I called it *ich9gen*. You can read about ich9gen and ich9deblob on the [ich9utils](../docs/install/ich9utils.md) page. The ich9gen utility was @@ -394,7 +394,7 @@ support was first added to Libreboot. Testing was later done on these other machines. In particular, Timothy Pearson (of Raptor Engineering) added support for switchable graphics, enabling video initialisation on versions of these boards that have both Intel and AMD graphics. Without such support, no video -init was available unless you used a board that only had the intel GPU. A +init was available unless you used a board that only had the Intel GPU. A hardware mux is present on the ones with AMD graphics, enabling you to still use just the Intel one, or switch to the AMD one. @@ -447,7 +447,7 @@ team lead by Mike Gerwitz. Libreboot's build system and documentation used a very peculiar design, which did not fit well into GNU's design policies. GNU had several technical -requirements for projects, such as use of TexInfo files for documentation, to +requirements for projects, such as use of Texinfo files for documentation, to be generated into HTML by a static site generator. At that time, Libreboot's website was written in static HTML, manually. It did not use a static site generator of any kind. @@ -717,7 +717,7 @@ which libreboot.org now uses. Alyssa acted as a sort of spokesperson during this period, acting in my place and I briefly gave her sysadmin privileges for the Libreboot hosting infrastructure, during that year (2017), because she was helping me improve my infrastructure - for example, she taught me how to -use nginx, where I'd previously used lighttpd as Libreboot's web server. +use Nginx, where I'd previously used lighttpd as Libreboot's web server. And that is the greatest irony of all. One of my main concerns about Libreboot's GNU membership was that I would lose control of the project, but I soon stepped @@ -741,7 +741,7 @@ GNU standards? I attempted to answer this, by actually doing it. I commissioned work, on the Libreboot mailing list (which existed at the time, and was hosted by GNU), to convert the website's static HTML files. Work was underway for converting the -entire documentation to TexInfo files, GNU's preferred format for documents. +entire documentation to Texinfo files, GNU's preferred format for documents. This was later scrapped, when I decided to accept Alyssa's work instead; she converted the website to use Markdown instead, with a custom static site generator. @@ -757,8 +757,8 @@ the [contrib page](../contrib.md). Paul's build system, the so-called *Paper build system*, was provided by him as a proof of concept. It initially only supported CrOS-based devices, for example -the ASUS Chromebook C201, integrating coreboot, depthcharge and various -chromeos utils that were needed. +the ASUS Chromebook C201, integrating coreboot, Depthcharge and various +ChromeOS utils that were needed. The goal of the build system re-write was to make Libreboot much more flexible and generally more configurable. Libreboot's build system *worked* very well at @@ -815,7 +815,7 @@ mentally and financially for gender reassignment surgery scheduled for late August 2018; then I spent a year recovering from that. And lots of other things. A lot of events, most/all of which won't be covered in detail here, were going on in my life, such that I never had the time nor mental energy to get involved -in Libreboot. And then the covid pandemic threw me off for a further year. I +in Libreboot. And then the COVID pandemic threw me off for a further year. I was planning a takeover of Libreboot in early 2020, but ended up doing it in 2021 instead. I had discussed the possibility publicly, several times during 2020, but nobody took me seriously at the time. @@ -894,7 +894,7 @@ utils (most of the C sloccount is ich9utils). If you actually look at the Paper system, almost all of it is covering utilities that don't need to be included in the project, many of them -chromeos-related; modern Libreboot (using my design, the lbmk build system), +ChromeOS-related; modern Libreboot (using my design, the lbmk build system), uses U-Boot, courtesy of work done by Alper Nebi Yasak (more on this later). I compile U-Boot with the *same* generic script that I maintain, which is less than 300 sloc in size, and compiles SeaBIOS, coreboot and U-Boot, without @@ -967,7 +967,7 @@ policy, since osboot later merged with Libreboot, in November of 2022, but it's the same policy that osboot used. I was commissioned by a Minifree customer to provide a ThinkPad X230. I already -knew then that the X230 (an ivybridge platform) could boot entirely blob-free +knew then that the X230 (an Ivy Bridge platform) could boot entirely blob-free in coreboot, except for the neutered Intel ME (using `me_cleaner`) and microcode updates. To my mind, it seemed acceptable in terms of software freedom. A solid, all-round very useful machine. @@ -990,7 +990,7 @@ and efficient. Thus, osboot was born. It initially began with Tianocore integrated in it, using MrChromebox's branch for coreboot. MrChromebox is a coreboot distro that -provides Tianocore as a payload, on many chromebooks, so I leaned on his +provides Tianocore as a payload, on many Chromebooks, so I leaned on his expertise to provide experimental Tianocore support, in my Libreboot 20160907 fork. I completely gutted about half of the build system in that Libreboot release, when forking it, because most of it no longer worked for modern @@ -1183,12 +1183,12 @@ it didn't hurt anything because Intel ME was always a problem. I didn't know ME neutering was possible, until I found out about `me_cleaner` - I would never provide anyone with a setup that uses a non-neutered ME, because of the networking and backdoors provided in such setups. The `me_cleaner` project removes such -backdoors from the intel ME, resulting in a clean image that only contains the +backdoors from the Intel ME, resulting in a clean image that only contains the init firmware in the ME. In this configuration, the ME initialises itself but doesn't actually run anything, so it just sits there permanently in the init stage. Things like AMT no longer work, when you run `me_cleaner`. -To put it simply: at least on the intel side, `me_cleaner` changed everything +To put it simply: at least on the Intel side, `me_cleaner` changed everything and opened up a lot more machines for me. But to do that, I had to abandon Libreboot policy. Hence, osboot was born. Libreboot policy was a liability to the free software movement, because it limited the amount of free software that @@ -1288,7 +1288,7 @@ down. That almost never happens, as the FSF tends to be extremely dogmatic, too drunk on their own prestige; set in their ways. They initially hosted their project on the official sourcehut instance run by -Drew Devault. I simply asked Drew to terminate their hosting. He complied. He +Drew DeVault. I simply asked Drew to terminate their hosting. He complied. He gave them two weeks to rename their project, or be deleted, and they did not rename. Their website was hosted on sourcehut at the time, so their website went offline for a day; on that same day, I announced the [Libreboot @@ -1379,11 +1379,11 @@ code is now used by Libreboot, to provide serprog firmware on many STM32- and RP2040-based microcontroller boards; we use them as SPI flashers, but you can use them for many other purposes. They're quite handy little machines. The serprog firmware integration was done by Riku Viitanen, who also added many -HP Elitebook machines to Libreboot during 2023. +HP EliteBook machines to Libreboot during 2023. Thanks to the work done by Nicholas Chin, several Dell Latitude laptops are now supported in Libreboot, which can be flashed without disassembly. We support -GM45 and Ivybridge models, and we're adding many more (we have identified +GM45 and Ivy Bridge models, and we're adding many more (we have identified about 20 of them). You can actually just read the Libreboot release announcements from 2023, if @@ -1417,7 +1417,7 @@ FSDG is the policy that GNU Boot uses, that Libreboot previously used, before it adopted the modern [Binary Blob Reduction Policy](policy.md) - GNU Boot started, specifically because it opposed the new policy in Libreboot. -Well, GNU Boot seemed to be going nowhere fast. I monitor their git activity +Well, GNU Boot seemed to be going nowhere fast. I monitor their Git activity daily, and their development pace is much slower than mine; slower than mine, even when I'm going slow. I thought to myself: what if a *competently* engineered solution existed, like GNU Boot but not?