libreboot
/
lbwww
1
0
Fork 0
Code Packages Projects Releases Activity

Merge pull request 'Fixes from initial pass over news/10.md' (#98) from nic3-14159/lbwww:news-10-fixes into master 

Reviewed-on: https://codeberg.org/libreboot/lbwww/pulls/98
master
Leah Rowe 2023-12-18 01:57:03 +00:00
parent 8afcf59684 8f21d0625a
commit 40f5af0a45
1 changed files with 42 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
site/news/10.md
View File

@ -2,7 +2,7 @@
% Leah Rowe
% 12 December 2023
I'm very proud of the work done in Libreboot, both my myself and by others
I'm very proud of the work done in Libreboot, both by myself and by others
who I work with. Many people make Libreboot possible, be it direct contributors
to the project, or the countless individuals and companies that work on all
the upstream projects used in Libreboot, projects like coreboot. I'm *very*
@ -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
@ -134,7 +134,7 @@ compiled ROM images, with source code, but there was no automated build system.
The [build system](../docs/maintain/) evolved over time.
The first releases of Libreboot supported only the ThinkPad X60. Later, T60
supported and MacBook 2,1 support were added. This first year of the project
support and MacBook 2,1 support were added. This first year of the project
was spent on building solid infrastructure, specifically documentation and an
automated build system. The design of Libreboot revolves around scripts that
automatically download, patch, configure and then compile various codebases,
@ -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.
@ -466,7 +466,7 @@ Libreboot 20160818, 20160902 and 20160907.
Initial outcomes
-------------
Libreboot's popularity reached great heights duting this time, greatly expanding
Libreboot's popularity reached great heights during this time, greatly expanding
and attracting many new developers. Joining GNU accelerated this further,
though it came with certain drawbacks.
@ -653,7 +653,7 @@ which is something I also considered at the time, but that would have required
maintaining a full coreboot repository, merging and overseeing a lot more
patches from upstream, and diverging heavily. The way Libreboot's deblobbing
worked was that it just deleted the blobs, and (by way of configuration) avoided
all boards except those that could bo booted entirely blob-free in the flash.
all boards except those that could be booted entirely blob-free in the flash.
This method required far less maintenance - the original blob-free policy of
Libreboot has been continued, as of 2023, in a new project I maintain
called [Canoeboot](https://canoeboot.org/) - I'll have more to say about this,
@ -709,7 +709,7 @@ the event here:
<https://www.reddit.com/r/linux/comments/639ob1/libreboot_no_longer_opposes_the_gnu_project_or/>
Also of note: Alyssa contributed to Libreboot a custom-written static site
generetor, converting its static HTML into Markdown files for documentation
generator, converting its static HTML into Markdown files for documentation
on the website, then generating pages with Pandoc. This static site generator
is included in the original Libreboot git repository, and it later became the
basis for my own [Untitled Static Site Generator](https://untitled.vimuser.org/)
@ -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
@ -783,10 +783,10 @@ I keep that repository there for archival, but it is no longer developed. I
took over the project again in 2021, and scrapped the rewrite. More on this
later in the article!
Andrew Robbins and Sebastien Gryzwna
Andrew Robbins and Sebastian Grzywna
------------------------------------
Sebastien had joined the project during early 2016, advising about hardware
Sebastian had joined the project during early 2016, advising about hardware
and he made quite a few useful code contributions at first. For example, he
added support for 16MB IFD configurations in ich9gen.
@ -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.
@ -835,12 +835,12 @@ to it, hoping they'd prove me wrong.
When I stepped down, the project had adapted a formalised "democratic"
governance policy, implementing a horizontal hierarchy form of collective
management. In practise, the former BDFL leadership under me was replaced
by basically the same thing, only it was two people; Andrew and Sebastien
by basically the same thing, only it was two people; Andrew and Sebastian
called all the shots. They would regularly turn away code contributions, and
Sebastien in particular was often extremely rude to users on the IRC channel,
Sebastian in particular was often extremely rude to users on the IRC channel,
acting in a very elitist manner.
Another general problem that Sebestian's leadership had was, that everything
Another general problem that Sebastian's leadership had was, that everything
was always *later*. You want X new feature added? Wait until after next release.
When's the next release? Soon. That account of events is quite reductive, but
it more or less sums everything up perfectly. The 2017-2021 leadership under
@ -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
@ -950,7 +950,7 @@ to take it over myself at some point; but it was too complex.
I would later take over the Libreboot project. This is what I will cover,
in the next sections. Paul stopped working on Libreboot after around
late 2017, leaving the work solely in the hands of Andrew and Sebastien.
late 2017, leaving the work solely in the hands of Andrew and Sebastian.
late 2020: osboot
================
@ -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
@ -1039,7 +1039,7 @@ project again in late December 2020. I was rapidly working on adding all the
Libreboot boards to osboot, and I would have just very quickly updated the
deblob scripts; I acted on this desire too soon, running under the gun.
I actually did remove Sebastien and Andrew's access to the Libreboot
I actually did remove Sebastian and Andrew's access to the Libreboot
infrastructure, for a few hours, before re-instating them - I wasn't ready for
a Libreboot takeover yet. I needed more time to polish everything. Doing a
tiny release for 1 customer, on 1 machine (the X230) was all well and good, but
@ -1048,7 +1048,7 @@ I decided that I had time to polish it more.
March 2021 Libreboot takeover
-----------------------------
I wanted to get rid of Sebastien and Andrew for some time, at that point. Too
I wanted to get rid of Sebastian and Andrew for some time, at that point. Too
many years had gone by, without any releases in Libreboot, and the Paper build
system was only growing more complex; it was completely unworkable, and their
time was up. They failed. An unwritten rule in the new constitution of 2017
@ -1072,7 +1072,7 @@ project; I actually did make some temporary releases of osboot (tarballs, with
ROM images and source code) in December 2020, but deleted them, because they
weren't intended for general use. I was only testing everything.
Sebastien had a lot of knowledge about hardware, but did almost no coding
Sebastian had a lot of knowledge about hardware, but did almost no coding
himself; he left that all to Andrew. And Andrew hadn't done any substantial
work in over 6 months at that time. And the work that was done, was still far
from complete. I anticipated that there would be years left before the Paper
@ -1145,7 +1145,7 @@ I had started in osboot, but at that time still complying with the GNU Free
System Distribution Guidelines, like 2016 Libreboot did.
I did not use any of the work in the *Paper* re-write. I used precisely zero
lines of code from Sebastien and Andrew's work. I did it all myself. My decision
lines of code from Sebastian and Andrew's work. I did it all myself. My decision
to take over the project had been vindicated. I did it for the users. People
had been complaining for years about the lack of a release. The Libreboot
project was dead. A joke to everyone, and it was no longer my fault; it was
@ -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?