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

burn 

Signed-off-by: Leah Rowe <leah@libreboot.org>
c20230710
Leah Rowe 2023-07-10 11:19:41 +01:00
parent 63bd43db58
commit 23bf3b4c3d
78 changed files with 239 additions and 8434 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
site/contrib.md
View File

@ -356,14 +356,6 @@ bucts before flashing the ROM again, to flash the main bootblock. Libreboot
hosts a copy of his work, because his website hosting bucts is no longer
responsive.
Riku Viitanen
-------------
Added support for HP Elite 8200 SFF desktop PC to Libreboot. You can read
about this in the hardware page:
[HP Elite 8200 SFF](docs/hardware/hp8200sff.md)
Steve Shenton
-------------

8
site/contrib.uk.md
View File

@ -355,14 +355,6 @@ coreboot під час ініціалізації відеочіпсета Intel
періодично надсилаючи патчі для тестування, доки помилку не було виправлено
в coreboot, а потім допоміг ій інтегрувати виправлення в libreboot.
Riku Viitanen
-------------
Added support for HP Elite 8200 SFF desktop PC to Libreboot. You can read
about this in the hardware page:
[HP Elite 8200 SFF](docs/hardware/hp8200sff.md)
Стів Шентон
-------------

4
site/docs/bsd/index.md
View File

@ -151,10 +151,6 @@ releases of Libreboot.
Desktop users
-------------
NOTE: This section may not be full accurate; for example, the hardware page
about HP Elite 8200 SFF talks about use of graphics cards on both corebootfb
and txtmode setups, and seems to work fine with SeaBIOS in both cases.
Desktop users on Libreboot should just install a graphics card,
and again boot with SeaBIOS in text mode; however, when you do this,
SeaBIOS will execute the VGA option ROM on the card which will provide

39
site/docs/build/index.md vendored
View File

@ -156,22 +156,6 @@ lbmk.
Therefore, if you only want to build ROM images, just do the above. Otherwise,
please continue reading!
Optional: extract binary blobs
------------------------------
Some boards, including all sandy/ivybridge boards require nonfree blobs which cannot be included in libreboot.
For boards requiring these blobs, libreboot will attempt to download the blobs itself.
If your board does not have blob sources available, then you must extract them from a backup of you vendor rom.
You must point libreboot to the backup rom and tell the build system which board you want to extract blobs for.
For example, to extract blobs for the t440p you must run:
./blobutil extract t440p_12mb /path/to/12mb_backup.rom
You can then build the rom for this board as normal:
./build boot roms t440p_12mb
Second, download all of the required software components
--------------------------------------------------------
@ -298,26 +282,3 @@ under `resources/coreboot/` in the build system.
That's it!
If all went well, ROM images should be available to you under bin/
20230625 build error (release archive)
======================================
When building ROM images from the release archives, the following error
is observed in some cases, depending on distro:
```
In file included from src/lib/version.c:4:
build/build.h:10:32: error: 'libreboot' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625
| ^~~~~~~~~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
```
This happened when a user tried to build for ThinkPad W541 on an Arch Linux
system. The fix is available here:
<https://browse.libreboot.org/lbmk.git/patch/?id=f34e07ae27e3e6e8508cdebcbd09fdf73fca302d>
Apply this patch to your local release archive, and it should fix the issue.

39
site/docs/build/index.uk.md vendored
View File

@ -156,22 +156,6 @@ lbmk.
Отже, якщо ви лише хочете побудувати образи ROM, просто зробіть наведене вище. В іншому випадку,
будь ласка, продовжіть читати!
Опціонально: видобути двійкові блоби
------------------------------
Деякі плати, включаючи всі плати sandy/ivybridge, вимагають невільні блоби, які не можуть бути включеними до libreboot.
Для плат, які вимагають ці блоби, libreboot спробує завантажити блоби власноруч.
Якщо ваша плата не має джерел блоба в наявності, тоді ви мусите видобути їх з резервної копії вашого rom постачальника.
Ви маєте вказати libreboot резервну копію rom та сказати системі побудові те, для якої плати ви хочете видобути блоби
Наприклад, щоб видобути блоби для t440p, ви маєте виконати:
./blobutil extract t440p_12mb /path/to/12mb_backup.rom
Ви потім можете побудувати rom для цієї плати нормально:
./build boot roms t440p_12mb
Друге, завантажити всі програмні компоненти, які вимагаються
--------------------------------------------------------
@ -298,26 +282,3 @@ lbmk.
Ось так!
Якщо все пройшло добре, образи ROM мають бути доступними вам під bin/
20230625 build error (release archive)
======================================
When building ROM images from the release archives, the following error
is observed in some cases, depending on distro:
```
In file included from src/lib/version.c:4:
build/build.h:10:32: error: 'libreboot' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625
| ^~~~~~~~~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
```
This happened when a user tried to build for ThinkPad W541 on an Arch Linux
system. The fix is available here:
<https://browse.libreboot.org/lbmk.git/patch/?id=f34e07ae27e3e6e8508cdebcbd09fdf73fca302d>
Apply this patch to your local release archive, and it should fix the issue.

177
site/docs/hardware/e6400.md
View File

@ -14,11 +14,10 @@ x-toc-enable: true
| **Name** | Latitude E6400 |
| **Variants** | E6400, E6400 XFR and E6400 ATG are supported |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45(Intel GPU)/PM45(Nvidia GPU) |
| **Chipset** | Intel Cantiga GM45(Intel GPU) |
| **CPU** | Intel Core 2 Duo (Penryn family). A Quad-core
mod exists, replacing the Core 2 Duo with a Core Quad |
| **Graphics** | Intel GMA 4500MHD (and NVidia Quadro NVS 160M
on some models) |
| **Graphics** | Intel GMA 4500MHD |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | 2 or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
@ -40,8 +39,7 @@ P*: Partially works with blobs
| ***Features*** | |
|---------------------------------------------------|----|
| **Internal flashing with original boot firmware** | W+ |
| **Display (if Intel GPU)** | W+ |
| **Display (if Nvidia GPU)** | W* |
| **Display (Intel GPU)** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
@ -56,16 +54,16 @@ P*: Partially works with blobs
Introduction
============
Known supported variants: E6400, E6400 XFR and E6400 ATG. This page has
been updated to include information about Nvidia GPU variants. See news post:
[Dell Latitude E6400 XFR support confirmed, plus experimental Nvidia GPU
support on E6400 variants](../../news/e6400nvidia.md).
Known supported variants: E6400, E6400 XFR and E6400 ATG.
ONLY the Intel GPU variants are supported, at present. The Nvidia ones are
not compatible, with this censored version of Libreboot.
**To install Libreboot, see: [E6400 installation
instructions](../install/e6400.md)**
ROM images for Dell Latitude E6400 are available for flashing in the Libreboot
release 20230423 onwards, or you can compile a ROM image for installation via
ROM images for Dell Latitude E6400 are available for flashing in Libreboot
releases, or you can compile a ROM image for installation via
lbmk, see: [build instructions](../build/)
There are two possible flash chip sizes for the E6400: 4MiB (32Mbit) or 2+4MiB
@ -98,6 +96,8 @@ Intel GPU: Blob-free setup (no-ME possible)
This is a GM45/PM45 platform, so completely libre initialisation in
coreboot is possible, provided by default in Libreboot.
Intel GPU variants are GM45, and Nvidia ones are PM45.
Management Engine (ME) firmware removed
-------------------------
@ -114,158 +114,3 @@ region almost entirely to 1's, with the occasional 32-bit value (likely not
executable). libreboot disables and removes it by using a modified descriptor:
see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
Issues pertaining to Nvidia GPU variants
========================================
Copper shim for GPU cooling
---------------------------
NOTE: this section does *not* apply to XFR or ATG variants of E6400, which have
a much beefier heatsink by default.
The *default* heatsink in Nvidia variants of E6400 (regular model) has thermal
paste for the CPU, and a thermal *pad* for the GPU. This pad is woefully
inadequate, but replacing it with *paste* is a bad idea, because of the gap
there would be between heatsink plate and GPU die.
A solution for this would be to use a *copper shim*, with paste on each side,
to replace the thermal pad.
This eBay seller seems to make and sell a lot of copper shims, specifically
for E6400:
<https://www.ebay.com/itm/282033838969>
If the listing ends, please [contact the Libreboot project](../../contact.md)
so that this link can be replaced or (if a replacement link is no longer
available) removed.
If you buy one of those, could you measure it? Tell Libreboot the dimensions.
Get in touch with us. It would be nice to know precise specs, but that seller
provides what you need. If you find similar listings elsewhere, please also
let us know.
The shim will greatly reduce GPU temperatures, and probably improve performance
due to less GPU throttling as a result of heat.
Nouveau(in Linux) currently broken
----------------------------------
Nouveau is the libre driver in Linux, for Nvidia graphics. Nvidia themselves
do not provide binary drivers anymore, for these GPUs. It crashes in Linux,
when you try to start Xorg (Wayland is untested).
If you're booting an Nvidia variant in Linux, boot Linux with
the `nomodeset` kernel option at boot time. This means that graphics are
rendered in software.
Development discussion, for Nvidia variants of E6400, is available here:
<https://codeberg.org/libreboot/lbmk/issues/14>
OpenBSD's Nvidia driver works perfectly
---------------------------------------
OpenBSD 7.3 was tested, on my Nvidia-model E6400, and Xorg works OK with
the `nv` driver.
<img tabindex=1 class="l" style="max-width:35%" src="https://av.libreboot.org/openbsd.jpg" /><span class="f"><img src="https://av.libreboot.org/openbsd.jpg" /></span>
See: <https://www.openbsd.org/>
OpenBSD is a complete free 4.4BSD Unix operating system focused on portability,
security and *code correctness*. It's quite useable for most day to day tasks.
You can find information in Libreboot about BSD operating systems on the
main guide:
* [BSD Operating Systems](../bsd/)
FreeBSD and newer Linux (e.g. Archlinux) untested!
--------------------------------------------------
FreeBSD has not yet been tested, as far as we know, but it should work.
[Testers needed! Please get in touch!](../maintain/testing.html)
**At the time of writing this post, FreeBSD
and newer Linux have not yet been tested** (I plan to test *Arch Linux*), but
the older Linux/Mesa version in Debian 11.6 works just fine in the Dell BIOS,
and I've confirmed that it uses the exact same Video BIOS Option ROM.
Desktop environment / window manager on OpenBSD + Performance notes
-------------------------------------------------------------------
TODO: This section could probably be moved to its own section. It's not really
relevant to Libreboot per se, but it may help a few people.
Again, Linux's nouveau driver is currently broken. I've been playing with my
E6400 (nvidia model) for a while and I've found that these things are a *must*
for performance (the machine otherwise lags, openbsd's `nv` driver isn't quite
as good as nouveau, when the nouveau one works that is):
* Use a lightweight desktop environment like LXQt, or lightweight window
manager (OpenBSD has `cwm` in base, and it's excellent)
* Install `obsdfreqd` which scales down the CPU speed during idle state; the
GPU has a poor thermal pad for cooling and so if the CPU is running hot,
that doesn't bode well for GPU temperatures either, and the GPU is likely
lagging due to heat:
How to install `obsdfreqd`:
pkg_add obsdfreqd
rcctl enable obsdfreqd
Now, before you start it, make sure `apmd` is disabled; it can be used, but
not with the `-A` flag:
rcctl stop apmd
rcctl disable apmd
Now start obsdfreqd:
rcctl start obsdfreqd
You will be well served to perform the copper shim mod, for GPU cooling.
With `obsdfreqd`, your laptop will run much cooler. This is generally a good
idea anyway, especially on laptops, to save electricity.
Of course, there are many tweaks that you can do to OpenBSD but the key is:
don't use heavy bloated software. The term *lightweight* is misleading anyway;
if the software does its job efficiently, and you're happy with it, then it is
by definition superior for your purposes. So, "lightweight" is simply a word
for "efficient" in many contexts. We should encourage the use and development
of highly efficient software that runs more smoothly on old machines. The
elitist attitude of *just buy a new computer* is quite damaging; re-use is
always better, when that is feasible and safe. The power of BSD (and Linux) is
precisely that you can tweak it to get the most use out of older hardware..
Another nice hint: higher resolution video like 1080p 60fps or above won't
play smoothly at all in a web browser. In testing at least on OpenBSD 7.3,
Firefox seems to have the best performance among all the web browsers, at least
when I used it. Anything 720p 30/60fps will work ~OK.
For YouTube, you could use yt-dlp, which is available in ports, and use mpv to
stream via yt-dlp. Or download manually with yt-dlp and play offline. See:
<https://github.com/yt-dlp/yt-dlp>
<https://mpv.io/>
Another hint: for watching youtube in the browser, Invidious works quite well.
It's a frontend that lets you view it by proxy, and there are many instances
of it online. For a list of instances, see:
<https://redirect.invidious.io/>
Unlike youtube.com, watching youtube via invidious works even with JavaScript
turned off in the browser. You can use it to also search YouTube, and then
paste the youtube.com link into yt-dlp or mpv; Invidious websites themselves
also often provide a download button for videos.
The yt-dlp software may also work on a few other websites besides YouTube.
Running with JavaScript turned *off* is generally recommended for performance,
especially on slower machines, turning it on only when you need it. Many
websites are just full of junk nowadays.

2
site/docs/hardware/ga-g41m-es2l.md
View File

@ -51,7 +51,7 @@ This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by libreboot.
As of Libreboot release 20221214, only SeaBIOS payload is provided in ROMs
In recent Libreboot releases, only SeaBIOS payload is provided in ROMs
for this board. According to user reports, they work quite well. GRUB was
always buggy on this board, so it was removed from lbmk.

85
site/docs/hardware/hp2560p.md
View File

@ -1,85 +0,0 @@
---
title: HP EliteBook 2560p
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
<div class="specs">
<center>
<img tabindex=1 alt="HP EliteBook 2560p" class="p" src="https://av.libreboot.org/hp2560p/grub.jpg" /><span class="f"><img src="https://av.libreboot.org/hp2560p/grub.jpg" /></span>
</center>
| ***Specifications*** | |
|---------------------------|-----------------------------------|
| **Manufacturer** | HP |
| **Name** | EliteBook 2560p |
| **Released** | 2011 |
| **Chipset** | Intel QM67 |
| **CPU** | Intel Sandy Bridge, socketed |
| **Graphics** | Intel HD Graphics |
| **Display** | 12.5" 1366x768 |
| **Memory** | Up to 16GB (2x8GB) |
| **Architecture** | x86_64 |
| **EC** | KBC1126, proprietary |
| **Intel ME/AMD PSP** | Present, neutered |
| **Flash chip** | SOIC-8 8MiB |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Introduction
============
Libreboot has support for this, in the Git repository and release versions
from Libreboot 20230423 onwards.
Brief board info
----------------
HP EliteBook 2560p is a 12.5" laptop you can read more about here:
<https://support.hp.com/us-en/product/hp-elitebook-2560p-notebook-pc/5071201>
Installation of Libreboot
-------------------------
You can actually just compile the Libreboot ROM for this, and flash the
entire ROM, then flash it. The *coreboot* project proper, has information
about this:
<https://doc.coreboot.org/mainboard/hp/2560p.html#programming>
Refer to the coreboot guide for flashing instructions, and you can build the
images for it in Libreboot like so:
./build boot roms hp2560p_8mb
More information about building ROM images can be found in
the [build guide](../build/).
This is a *Sandybridge* board which means that a neutered ME image is required
if you wish to flash the ME region. Libreboot's build system automatically
downloads, neuters (using `me_cleaner`) and inserts this if compiling from
source.
If you're using *Libreboot release* ROM images, the ME image has been scrubbed
and you must re-insert it. Use the information on this guide to know how
to do that:
[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You may also wish to change the *default MAC address* if you're planning to
use the onboard Intel Gigabit Ethernet. You can do this using the information
in the same guide linked above, or read the nvmutil manual:
[Modify MAC addresses with nvmutil](../install/nvmutil.md).

124
site/docs/hardware/hp2570p.md
View File

@ -1,124 +0,0 @@
---
title: HP EliteBook 2570p
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
<div class="specs">
| ***Specifications*** | |
|---------------------------|-----------------------------------|
| **Manufacturer** | HP |
| **Name** | EliteBook 2570p |
| **Released** | 2012 |
| **Chipset** | Intel QM77 |
| **CPU** | Intel Ivy Bridge, socketed |
| **Graphics** | Intel HD Graphics |
| **Display** | 12.5" 1366x768 |
| **Memory** | Up to 16GB (2x8GB) |
| **Architecture** | x86_64 |
| **EC** | KBC1126, proprietary |
| **Intel ME/AMD PSP** | Present, neutered |
| **Flash chip** | SOIC-16 16MiB |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Introduction
============
Libreboot has support for this, in the Git repository and release versions
after (but not including) 20230423.
Brief board info
----------------
HP EliteBook 2570p is a 12.5" laptop very similar to the 2560p.
The only real difference seems to be that this shipped with Ivy Bridge
processors rather than Sandy Bridge, and has an USB 3.0 port.
You can read more specifications directly from HP:
<https://support.hp.com/us-en/document/c03412731>
The following is tested and confirmed working
thanks to `Johan Ehnberg (johan@molnix.com)`:
- Native raminit with 2+2 (matched or unmatched), 2+8 or 8+8 GiB RAM
- SeaBIOS and GRUB (booted Devuan and Ubuntu) (corebootfb+txtmode)
- S3 suspend to RAM
- Backlight control
- 2.5" SATA SSD
- Optical drive slot
- Gigabit Ethernet
- Mini-PCIe Wi-Fi
- SD card reader
- Bluetooth
- Touchpad
- Headphone jack, speakers and microphone
- Webcam
- Docking station: all ports except that weird extension port tested,
hotplug and unplug work
- VGA & DisplayPort
- Fn combos, mute button
- "Launch browser" button: worked one day, not other.
Probably just not configured in OS.
These were visible on lsusb, but no further tests were performed:
- Fingerprint sensor
- Smart card reader
- WWAN (3G modem)
Untested:
- Trackpoint (not present on cheap aftermarket keyboard tested)
- ExpressCard
- eSATA & mSATA (believed to work based on coreboot comments)
Not working:
- Radio button
Installation of Libreboot
-------------------------
You can actually just compile the Libreboot ROM for this, and flash the
entire ROM. The process is the same as 2560p, except you probably have
a SOIC-16 chip instead of SOIC-8. Follow these instructions:
<https://doc.coreboot.org/mainboard/hp/2560p.html#programming>
Refer to that coreboot guide for flashing instructions, and you can
build the images for it in Libreboot like so:
./build boot roms hp2570p_16mb
More information about building ROM images can be found in
the [build guide](../build/).
This is an *Ivy Bridge* board which means that a neutered ME image is required
if you wish to flash the ME region. Libreboot's build system automatically
downloads, neuters (using `me_cleaner`) and inserts this if compiling from
source.
If you're using *Libreboot release* ROM images, the ME image has been scrubbed
and you must re-insert it. Use the information on this guide to know how
to do that:
[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You may also wish to change the *default MAC address* if you're planning to
use the onboard Intel Gigabit Ethernet. You can do this using the information
in the same guide linked above, or read the nvmutil manual:
[Modify MAC addresses with nvmutil](../install/nvmutil.md).

262
site/docs/hardware/hp8200sff.md
View File

@ -1,262 +0,0 @@
---
title: HP Elite 8200 SFF/MT and 6200 Pro Business
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
<div class="specs">
<center>
<img tabindex=1 alt="HP Compaq 8200 Elite SFF" class="p" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span> <img tabindex=1 title="From left to right: SFF and MT" class="p" src="https://av.libreboot.org/hp8200sff/sff+mt.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/sff+mt.jpg" /></span>
</center>
| ***Specifications*** | |
|---------------------------|---------------------------------------------|
| **Manufacturer** | HP |
| **Name** | Compaq 8200 Elite SFF |
| | Compaq 8200 Elite MT |
| **Released** | 2011 |
| **Chipset** | Intel Q67 |
| **CPU** | Intel Sandy/Ivy Bridge |
| **Graphics** | Intel HD Graphics or PCI-e low profile card |
| **Memory** | Up to 32GB (4x8GB) |
| **Architecture** | x86_64 |
| **Intel ME/AMD PSP** | Present, neutered |
| **Flash chip** | SOIC-8 8MiB |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|---------------------------------------------------|----|
| **Internal flashing with original boot firmware** | W* |
| **Display (Intel GPU)** | W+ |
| **Display (PCIe graphics card)** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Introduction
============
Libreboot has support for this, in the Git repository and release versions
from 20230423 onwards.
Brief board info
----------------
HP Elite 8200 SFF is a small-form-factor desktop of Intel Sandybridge platform
which you can read more about here:
<https://support.hp.com/gb-en/product/hp-compaq-8200-elite-small-form-factor-pc/5037931>
MT is an identical board with a larger chassis and more powerful power supply:
<https://support.hp.com/gb-en/product/hp-compaq-8200-elite-desktop-pc-series/5037940>
Here's the [Technical Reference Manual](https://web.archive.org/web/20160109143257/https://h10032.www1.hp.com/ctg/Manual/c02778024.pdf).
This system supports Ivy Bridge processors too. The original BIOS
won't even POST with those, but with Libreboot they work fully.
Installation of Libreboot
-------------------------
You can actually just compile the Libreboot ROM for this, and flash the
entire ROM.
Internal flashing from OEM BIOS is possible by setting a jumper
on the board. Step by step instructions for this are below.
The *coreboot* project proper has technical details on why this works if
you are interested. It also has external flashing instructions if you need
to recover from an unbootable BIOS:
<https://doc.coreboot.org/mainboard/hp/compaq_8200_sff.html>
You can build the images for it in Libreboot like so:
./build boot roms hp8200sff_8mb
More information about building ROM images can be found in
the [build guide](../build/).
If you plan on using a graphics card (other than the integrated graphics of
your CPU), choose one of the files which name contains both "seabios" and
"txtmode".
This is a *Sandybridge* board which means that a neutered ME image is required
if you wish to flash the ME region. Libreboot's build system automatically
downloads, neuters (using `me_cleaner`) and inserts this if compiling from
source.
If you're using *Libreboot release* ROM images, the ME image has been scrubbed
and you must re-insert it. Use the information on this guide to know how
to do that:
[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You may also wish to change the *default MAC address* if you're planning to
use the onboard Intel Gigabit Ethernet. You can do this using the information
in the same guide linked above, or read the nvmutil manual:
[Modify MAC addresses with nvmutil](../install/nvmutil.md).
Internal flashing from vendor BIOS
----------------------------------
The vendor BIOS imposes write-protections in the Flash Descriptor and
runtime. However, the flash descriptor can be bypassed by bridging a
jumper and the runtime protections only apply to a fixed address block.
Since neutering the Management Engine frees up a lot of space, we can
just install an intermediate Libreboot image there. This removes all
write-protections so has the same end result as external flashing:
a completely unlocked system.
Power off the computer. Remove the side panel.
Near the back USB ports find the jumper labelled **FDO**.
![Location of the FDO jumper](https://av.libreboot.org/hp8200sff/fdo.jpg)
You need to short the two pins circled. Use a
[jumper block](https://en.wikipedia.org/wiki/Jumper_(computing)) if you
have one but a screwdriver will do the job fine too. Hold the tip
between the pins until you can see the normal BIOS boot screen.
![](https://av.libreboot.org/hp8200sff/fdo\_screwdriver.jpg)
Boot into an OS supported by flashrom. On Linux, make sure you add the
kernel parameter **iomem=relaxed** which disables memory protections that
prevent BIOS flashing.
Now, run this command:
flashrom -p internal -c MX25L6406E/MX25L6408E
The output should contain the text "The Flash Descriptor Override
Pin-Strap is set". If it doesn't, start again from the beginning.
Now build the **4** MiB Libreboot image.
./build boot roms hp8200sff_4mb
More information about building ROM images can be found in
the [build guide](../build/).
Also build `ifdtool`. It will be needed soon.
cd coreboot/default/util/ifdtool
make
sudo make install
Now choose the image you want from `bin/hp8200sff_4mb`.
We'll refer to it as `libreboot4.rom`. We need to pad it to 8 MiB:
dd if=/dev/zero bs=4M count=1 >> libreboot4.rom
Flash the Libreboot image with a tweaked layout:
ifdtool libreboot4.rom -f layout
flashrom -p internal -c MX25L6406E/MX25L6408E -w libreboot4.rom -l layout -i fd -i gbe -i bios -i me
Power off the computer. Make sure to power off, rebooting is not enough!
Power on the computer.
Now we can flash the full 8 MiB image. Boot to an OS with flashrom
again. On linux, remember the **iomem=relaxed** kernel parameter.
Pick a Libreboot image of your choice from `bin/hp8200sff_8mb`
or from a release archive. We'll refer to it as `libreboot8.rom`.
flashrom -p internal -c MX25L6406E/MX25L6408E -w libreboot8.rom
Power cycle the computer again.
HP 6200 Pro Business PC
-----------------------
According to this page from the vendor, HP BIOS updates are the same on both
the 8200 SFF Elite *and* 6200 Pro Business desktop PCs; therefore, we believe
that the Libreboot config for 8200 SFF will *also* work on 6200 Pro Business
PCs. That page is here:
<https://support.hp.com/fi-fi/drivers/selfservice/swdetails/hp-compaq-8200-elite-small-form-factor-pc/5037931/swItemId/vc-229778-2>
The config for this board is courtesy of *Riku Viitanen* (`Riku_V` on Libreboot
IRC), who tested and confirmed the following functionality:
* Sandy Bridge (i5-2400) and Ivy Bridge (i5-3570S) CPUs
* 4x8 GB RAM (Sandy Bridge: 1333MHz, Ivy Bridge: 1600MHz)
* PS/2 keyboard and mouse
* USB keyboard (a bit laggy on GRUB)
* Boot from USB and DVD
* Gigabit ethernet
* VGA and DisplayPort (Intel graphics), with libgfxinit (native video init)
* Headphone output, PC speaker
* S3 suspend, wake on USB keyboard
* lm\_sensors outputs CPU core temperatures only
* Both PCIe x16 slots, external GPU works with SeaBIOS
* PCI
* SATA
* USB ports
* Serial port (RS-232)
* Wake on LAN
At the time of adding this board to Libreboot, the following is untested:
* Parallel port (internal header on the board)
* Floppy drive. The case has a spot for it, but I can't find the header (P10).
According to the initial coreboot port from 2018, the following also works:
* EHCI debug (not enabled by Libreboot configs)
* Native (libre) raminit with up to four DIMM modules (also tested by Riku and
confirmed working, with 32GB RAM installed as 4x8GB)
TPM
---
According to git logs, TPM should work, and a commit from 2018 at revision
ID `39d0e2a2cf45e28cdddd0fe0c88f94ce527ab1ef` in coreboot makes the TPM visible
to operating systems.
PSU Fan control
---------------
See coreboot commit `9bd601584350f51f112b15a7369f9aa82f1d0919` - labelled
by commit message `superio/nuvoton/npcd378: Add PSU fan control`.
Per this commit, SuperIO-based fan control is supported on HP Elite 8200 SFF.
TODO for testing the above is here:\
<https://codeberg.org/libreboot/lbmk/issues/9>
This is controlled via `nvramtool` to modify the value in sram. See:
* `psu_fan_lvl=3` <-- default setting in coreboot, and Libreboot.
Other values possible: from reading the source code, it is implied that the
number can be between 0 and 7. If the value is set higher than 7, it will
default back to 3.
Libreboot locks CMOS/NVRAM settings, but you can change the default setting in
the *ROM* by using the `-C` option in nvramtool. You can find this under the
directory `coreboot/default/util/nvramtool` when downloading coreboot inside
of lbmk by running the command:
./download coreboot default
Go in there and type `make` to build nvramtool. Simply run nvramtool without
arguments, and it will show a list of options.

129
site/docs/hardware/hp8300usdt.md
View File

@ -1,129 +0,0 @@
---
title: HP Compaq Elite 8300 USDT
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
<div class="specs">
<center>
<img tabindex=1 alt="HP Compaq Elite 8300 USDT" class="p" src="https://av.libreboot.org/hp8300usdt/hp8300usdt.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8300usdt/hp8300usdt.jpg" /></span>
</center>
| ***Specifications*** | |
|---------------------------|---------------------------------------------|
| **Manufacturer** | HP |
| **Name** | Compaq 8300 Elite USDT |
| **Released** | 2012 |
| **Chipset** | Intel Q77 |
| **CPU** | Intel Sandy/Ivy Bridge (65W max.) |
| **Graphics** | Intel HD Graphics or MXM graphics card |
| **Memory** | Up to 16GB (2x8GB) |
| **Architecture** | x86_64 |
| **Intel ME/AMD PSP** | Present, neutered |
| **Flash chip** | SOIC-16 16MiB |
# Introduction
This is a small but powerful desktop using Sandy or Ivy Bridge CPUs (of up to 65W TDP).
It has a slot for a discrete MXM graphics card, but that is currently untested.
Libreboot has support for this, in the Git repository and
release versions after (but not including) 20230423.
These features are tested and confirmed working:
* Native raminit with both DIMMs (up to 2x8GB)
* Libgfxinit textmode and framebuffer on both DisplayPorts and VGA
* SeaBIOS and GRUB payloads
* External USB2 and USB3 ports: they all work
* USB 3.0 SuperSpeed on Linux-libre (rear, 4 ports)
* Ethernet
* Mini-PCIe WLAN
* SATA: 2.5" SSD and optical drive bay
* PS/2 keyboard and mouse
* S3 suspend and resume, wake using USB keyboard
* Headphone output, line out, internal speaker
* Wake on LAN
* Rebooting
Untested (and likely don't work):
* mSATA
* eSATA
* Discrete MXM GPU
# Installation
## Internal flashing
Internal flashing is possible and very simple on this board:
First, make sure the computer is powered off. Remove the top cover.
The jumper labelled "FDO" (for Flash Descriptor Override) needs to be shorted.
That removes all write protections on this board.
We can borrow a shunt from another header on the board: PSWD. It is right
next to the SO-DIMM RAM slots. Move it to the FDO header between the quartz
crystal (small metal cylinder) and the power cable for the optical drive.
![](https://av.libreboot.org/hp8300usdt/jumper_to_fdo.jpg)
Boot into an OS of your choice (that has flashrom support). When using Linux,
you need to supply the kernel parameter `iomem=relaxed`.
The BIOS should no longer impose any write-protections.
You can now use `flashrom -p internal` freely.
Take a backup of the original BIOS:
flashrom -p internal -r oem_bios
This is an Ivy Bridge board which means that a neutered ME image
is required if you wish to flash the ME region. Libreboot's
build system automatically downloads, neuters (using me_cleaner)
and inserts this if compiling from source.
If you're using Libreboot release ROM images, the ME image has been
scrubbed and you must re-insert it.
Use the information on this guide to know how to do that:
[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You can now flash libreboot:
flashrom -p internal -w libreboot.rom
You can now move the jumper back to its original place.
By default, Libreboot applies no write-protection, so
updating it can be done without the jumper anyway.
## External flashing
Unbricking is possible by external flashing. You first need to remove
the optical disk drive and 2.5" HDD/SSD and the metal bracket that
supports them. This requires you to open one torx screw in total.
The SOIC-16 flash chip is located on the edge of the board
near the group of yellow cubes. Follow the
[general SPI flashing guide](http://localhost:8080/docs/install/spi.html).
![](https://av.libreboot.org/hp8300usdt/chip+header.jpg)
You might need to power the board by plugging it in. In that case,
do not connect the Vcc (3v3) pin of the flash chip.
Also make sure the board doesn't fully power on (that is, boot).
If you don't have a suitable clip, you can also use the ROM_RCVRY header
right next to the flash chip. By default only the footprint is present,
so you have to solder a pin header of your own. End result can be seen
and the pinout can be seen in the photo earlier. Consult the HP service
manual (page 241) on how to remove the motherboard from the chassis.
<http://web.archive.org/web/20210305234331/https://h10032.www1.hp.com/ctg/Manual/c03612798.pdf>
If you do this, you have to reapply thermal paste.
That might be a good idea anyway, considering how old these are getting

93
site/docs/hardware/hp9470m.md
View File

@ -1,93 +0,0 @@
---
title: HP EliteBook Folio 9470m
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
<div class="specs">
<center>
<img tabindex=1 alt="HP EliteBook Folio 9470m" class="p" src="https://av.libreboot.org/hp9470m/grub.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/grub.jpg" /></span>
</center>
| ***Specifications*** | |
|---------------------------|-----------------------------------|
| **Manufacturer** | HP |
| **Name** | EliteBook Folio 9470m |
| **Released** | 2012 |
| **Chipset** | Intel QM77 |
| **CPU** | Intel Ivy Bridge ULV |
| **Graphics** | Intel HD Graphics 4000 |
| **Display** | 14" 1366x768 or 1600x900 |
| **Memory** | Up to 16GB |
| **Architecture** | x86_64 |
| **EC** | KBC1126, proprietary |
| **Intel ME/AMD PSP** | Present, neutered |
| **Flash chip** | SOIC-8 16MiB |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Introduction
============
HP EliteBook Folio 9470m is a 14" ultrabook with a backlit keyboard.
Libreboot has support for this, in the Git repository and release versions
from Libreboot 20230423 onwards.
Installation of Libreboot
=========================
You must first compile the Libreboot ROM
./build boot roms hp9470m_16mb
More information about building ROM images can be found in
the [build guide](../build).
This is an *Ivybridge* board which means that a neutered ME image is required
if you wish to flash the ME region. Libreboot's build system automatically
downloads, neuters (using `me_cleaner`) and inserts this if compiling from
source.
If you're using *Libreboot release* ROM images, the ME image has been scrubbed
and you must re-insert it. Use the information on this guide to know how
to do that:
[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You may also wish to change the *default MAC address* if you're planning to
use the onboard Intel Gigabit Ethernet. You can do this using the information
in the same guide linked above, or read the nvmutil manual:
[Modify MAC addresses with nvmutil](../install/nvmutil.md).
Disassembly
-----------
Remove the battery.
![](https://av.libreboot.org/hp9470m/00_battery.jpg)
Open the two screws marked with the three-disc icons.
Slide the HDD panel out and remove it.
![](https://av.libreboot.org/hp9470m/01_panel.jpg)
The flash chip is now comfortably accessible. Now refer to the
[external programming guide](../install/spi.html) for guidance on how
to program Libreboot on it.
![](https://av.libreboot.org/hp9470m/02_flash.jpg)
Some part of the board might turn on when programming. If programming fails,
you might have to attach the laptop to a charger. Make sure the laptop
powers off before running flashrom. No LEDs should be lit.

97
site/docs/hardware/index.md
View File

@ -3,9 +3,6 @@ title: Hardware compatibility list
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
This sections relates to known hardware compatibility in libreboot.
For installation instructions, refer to [../install/](../install/).
@ -17,37 +14,23 @@ machines.
(for later machines like T500, T400, ATI GPU doesn't matter, because it also
has an Intel GPU, and libreboot uses the Intel one)
READ THIS BEFORE UPDATING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)**
NOTE: This warning does not apply to ROMs that you compiled yourself, using
lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted*
in release ROMs. The link above says how to re-add them. When building ROM images
yourself, from source, Libreboot's build system automatically handles it. See:
[Libreboot build instructions](../build/)
Supported hardware
==================
libreboot currently supports the following systems in this release:
### Servers (AMD, Intel, x86)
- [ASUS KGPE-D16 motherboard](kgpe-d16.md)
- [ASUS KFSN4-DRE motherboard](kfsn4-dre.md)
### Desktops (AMD, Intel, x86)
- [ASUS KCMA-D8 motherboard](kcma-d8.md)
- [Gigabyte GA-G41M-ES2L motherboard](ga-g41m-es2l.md)
- [Acer G43T-AM3](acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](d510mo.md)
- [Apple iMac 5,2](imac52.md)
- [HP Elite 8200 SFF/MT](hp8200sff.md) (HP 6200 Pro Business probably works too)
- [HP Elite 8300 USDT](hp8300usdt.md)
### Laptops (Intel, x86)
@ -57,85 +40,31 @@ libreboot currently supports the following systems in this release:
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](x200.md)
- Lenovo ThinkPad X230
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](r400.md)
- [Lenovo ThinkPad T400 / T400S](t400.md)
- [Lenovo ThinkPad T500](t500.md)
- [Lenovo ThinkPad T530 / W530](../install/ivy_has_common.md) (no install
docs yet)
- [Lenovo ThinkPad W500](t500.md)
- [Lenovo ThinkPad R500](r500.md)
- [Apple MacBook1,1 and MacBook2,1](macbook21.md)
- [Lenovo ThinkPad T440p](../install/t440p_external.md)
- [Lenovo Thinkpad X220](../install/ivy_has_common.md)
- [Lenovo Thinkpad X220t](../install/ivy_has_common.md)
- [Lenovo Thinkpad T420](../install/ivy_has_common.md) (no install docs yet)
- [Lenovo ThinkPad T420S](../install/ivy_has_common.md) (no install docs yet)
- [Lenovo ThinkPad T430](../install/ivy_has_common.md) (no install docs yet)
- [Lenovo Thinkpad X230](../install/x230_external.md)
- [Lenovo Thinkpad X230t](../install/x230_external.md)
- [Lenovo ThinkPad W541](../install/ivy_has_common.md) (no install docs yet)
- [HP EliteBook 2560p](hp2560p.md)
- [HP EliteBook 2570p](hp2570p.md)
- [HP EliteBook Folio 9470m](hp9470m.md)
### Laptops (ARM, with U-Boot payload)
- [ASUS Chromebook Flip C101 (gru-bob)](../install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../install/chromebooks.md)
## Removed boards
These boards were in Libreboot, but have been removed with the intention of
re-adding them at a later date. They were removed due to issues. List:
- [HP Chromebook 14 G3 (nyan-blaze)](../install/chromebooks.md)
- [Acer Chromebook 13 (CB5-311, C810) (nyan-big)](../install/chromebooks.md)
- [Hisense Chromebook C11 and more (veyron-jerry)](../install/chromebooks.md)
- [Samsung Chromebook 2 13" (peach-pi)](../install/chromebooks.md)
- [Samsung Chromebook 2 11" (peach-pit)](../install/chromebooks.md)
- [HP Chromebook 11 G1 (daisy-spring)](../install/chromebooks.md)
- [Samsung Chromebook XE303 (daisy-snow)](../install/chromebooks.md)
- [ASUS Chromebit CS10 (veyron-mickey)](../install/chromebooks.md)
- [ASUS Chromebook Flip C100PA (veyron-minnie)](../install/chromebooks.md)
- [ASUS Chromebook C201PA (veyron-speedy)](../install/c201.md)
- [ASUS KCMA-D8 motherboard](kcma-d8.md) (removed from lbmk, TODO: re-add)
- [ASUS KGPE-D16 motherboard](kgpe-d16.md) (removed from lbmk, TODO: re-add)
- [ASUS KFSN4-DRE motherboard](kfsn4-dre.md) (removed from lbmk, TODO: re-add)
- [Intel D945GCLF](d945gclf.md) (removed from lbmk, TODO: re-add support)
### NOTES about removed boards:
**WARNING: veyron speedy boards (e.g. C201) have non-functional video init as
of 19 February 2023, and no fix is yet available on that date. See:
<https://notabug.org/libreboot/lbmk/issues/136> - the last tested revision
from 2021.01 is known to work, for u-boot on this board. See:\
<https://wiki.postmarketos.org/wiki/ASUS_Chromebook_C201_(google-veyron-speedy)>
(alpernebbi on IRC is looking into this, to bisect uboot and update the latest
revisions) - for now, ROM images deleted from the Libreboot 20221214
and 20230319 releases.**
**WARNING: daisy- and peach- boards require a BL1 bootloader blob, but the
one from coreboot 3rdparty is a fake/placeholder blob. We need logic in the
Libreboot build system for properly fetching/extracting these, plus docs to
cover it. For now, assume that these are broken - ROM images are excluded,
for now, and have been deleted from the Libreboot 20221214 and 20230319
releases. - see: <https://review.coreboot.org/plugins/gitiles/blobs/+/4c0dcf96ae73ba31bf9aa689768a5ecd47bac19e>
and <https://review.coreboot.org/plugins/gitiles/blobs/+/b36cc7e08f7337f76997b25ee7344ab8824e268d>**
d945gclf: Doesn't boot at all, according to last report. D510MO is still in
lbmk but still was reported problematic; other boards should be fine (see list
above).
WARNING: Support for these boards is at a proof-of-concept stage. Refer
to [docs/uboot/](../uboot/) for more info about the U-Boot payload.
### Emulation
- [Qemu x86](../misc/emulation.md)
- [Qemu arm64](../misc/emulation.md)
## Removed boards
These boards were in Libreboot, but have been removed with the intention of
re-adding them at a later date. They were removed due to issues. List:
- [ASUS Chromebook C201PA (veyron-speedy)](../install/c201.md)
- [Intel D945GCLF](d945gclf.md) (removed from lbmk, TODO: re-add support)
TODO: More hardware is supported. See `resources/coreboot/` in lbmk. Update
the above list!

4
site/docs/hardware/kgpe-d16.md
View File

@ -6,10 +6,6 @@ x-toc-enable: true
Introduction
============
**KGPE-D16, KCMA-D8 and KFSN4-DRE ASUS mainboards were removed on 19
November 2022. You can still use older revisions of Libreboot, and older
release versions.**
This is a server board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
Powered by libreboot. The coreboot port was done by Timothy Pearson of

25
site/docs/hardware/mac_address.md
View File

@ -101,25 +101,8 @@ See [ich9utils documentation](../install/ich9utils.md)
If *all* you want to do is change the MAC address, you might try `nvmutil`
instead. See notes below:
Changing the MAC address on ivybridge/sandybridge/haswell (e.g. X230/T440p)
=========================================================
Also see [nvmutil documentation](../install/nvmutil.md)
See [nvmutil documentation](../install/nvmutil.md)
This tool was originally written for changing the MAC address on Intel
Sandybridge, Ivybridge and Haswell platforms, but it can be used on any
platform with a valid GbE region in flash, where an Intel Flash Descriptor
is used; this includes older GM45+ICH9M machines supported by Libreboot.
The `ich9utils` program is more useful in an lbmk context, because it
generates an entire Intel Flash Descriptor and GbE region from scratch;
coreboot has a similar method in its build system, using its own utility
called bincfg, but this tool is unused in lbmk.
No tool like ich9utils exists for these boards yet, but lbmk includes the IFD
and GbE files in-tree (Intel ME is handled by extracting from Lenovo updates,
which the build system automatically fetches from the internet).
You can use `nvmutil` to change the existing MAC address in a GbE region. This
sets the "hardcoded" MAC address, typically a globally assigned one set by
the vendor.
The nvmutil utility is yet another utility provided by Libreboot, for
changing your MAC address. It is a standalone utility, that operates
only on pre-assembled GbE files.

2
site/docs/install/chromebooks.md
View File

@ -6,7 +6,7 @@ x-toc-enable: true
NOTE: daisy, peach and veyron boards were temporarily removed from
lbmk. They should be re-added to Libreboot at a later date. The reasons
are written on the hardware compatibility page. For now, Libreboot only
officially supports the `nyan` and `gru` chromebooks.
officially supports the `gru` chromebooks.
This page attempts to give a brief, general overview of how to flash
custom firmware on ChromeOS devices. This guide usually refers to all of

147
site/docs/install/e6400.md
View File

@ -6,55 +6,21 @@ x-toc-enable: true
Introduction
============
Initial flashing instructions for the E6400.
**ROM images are available in the [Libreboot 20230423
release](../../news/libreboot20230423.md), and subsequent releases.**
**Variants with Nvidia GPUs are NOT supported in Libreboot 20230423
or 20230625. Please
see below for further guidance (experimental support available in `lbmk.git`).**
Initial flashing instructions for the E6400. DO NOT flash the Nvidia GPU
variant. This page pertains only to the Intel GPU variant.
This guide is for those who want libreboot on their Latitude E6400 while
they still have the original Dell BIOS present. This guide can also be
followed (adapted) if you brick your E6400, and you want to recover it.
Variants (nvidia or intel graphics)
========
Dell E6400, E6400 XFR and E6400 ATG are all believed to work. The flashing
instructions are identical, on all of them.
Blob-free initialisation (on Intel GPU variants)
=========================
This board can boot entirely blob-free in the flash. The hardware is similar
to that of ThinkPad X200, T400 etc where no-ME setup is possible.
No-microcode setup feasible
----------------------------
The
[microcode bugfixes/mitigations added for GM45](../../news/gm45microcode.md)
are also applicable to this board, for users who are interested. Read that
article for more information.
Libreboot still recommends that boot with CPU microcode updates, by default,
for all the reasons described by Libreboot's [Binary Blobs Reductions
Policy](../../news/policy.md) but this board run reasonably well without them.
A note about GPUs
-----------------
We *confirm that* the Nvidia models are PM45, and therefore will require a VGA
blob for initialisation. This is [experimentally
supported](../../news/e6400nvidia.md) in Libreboot. - **A Video BIOS Option
ROM is used, in this configuration, which is a binary blob. Libreboot's
build system automatically downloads this at build time, or it can handle that
for you in the same way if it was scrubbed from a release ROM.**
Models with Intel graphics are GM45, and fully supported in Libreboot
with native initialisation; ROM images are available since Libreboot 20230423.
with native initialisation; ROM images are available since.
**The Intel video initialisation is libre, implemented with publicly available
source code via libgfxinit, from the coreboot project.**
@ -96,110 +62,6 @@ Intel GPU: libre video initialisation available
Libreboot uses coreboot's native `libgfxinit` on this platform, for
variants with Intel graphics.
For Intel GPU variants, Libreboot 20230423 and up have full support. Simply
flash a release ROM, if you wish.
Nvidia GPU: Video BIOS Option ROM required
==========================================
**NOTE: `nouveau` (Linux video driver) is unstable when it was last tested, in
this setup. Either specify `nomodeset` kernel option, or use another
operating system such as OpenBSD. More information is written on the
[E6400 hardware page](../hardware/e6400.md), regarding OS compatibility.**
This is *unavailable* in Libreboot 20230423 and 20230625, but a future release
will contain support for these variants; for now, you must compile Libreboot
from Git.
Download the Libreboot build system, lbmk, like so:
git clone https://codeberg.org/libreboot/lbmk
When you clone the Libreboot git repository `lbmk.git`, go in there and do
this:
git checkout e6400nvidia_wip
Actual installation is the same as with regular E6400 (Intel GPU) variants.
Refer to the [E6400 flashing instructions](../docs/install/e6400.md).
The `e6400nvidia_wip` is used, because this version is still under development.
Refer to [development discussion](https://codeberg.org/libreboot/lbmk/issues/14#issuecomment-907758) for more information - [testers needed!](../maintain/testing.md)
Obtaining the VGA Option ROM (Nvidia)
-------------------------------------
Libreboot does not (and will not) directly distribute the Nvidia ROM, but this
WIP branch has logic added to `blobutil`, which automatically fetches Dell
update files and extracts the Video BIOS from it. This is inserted during
the build process, *automatically*. Everything has been figured out *for you*,
as is the purpose of Libreboot's [automated build system](../maintain/).
In Libreboot release ROMs after Libreboot 20230423, this Video BIOS ROM will
*not* be present, but you'll be able to run the same script that lbmk uses, to
manually re-download and re-add it. The Libreboot build system scrubs certain
binary blobs, in the scripts from lbmk that create release archives.
[Please read the Libreboot build guide](../build/) for more general guidance
on compiling Libreboot. You should *especially* set name/email in Git, like
so:
git config --global user.name "John Doe"
git config --global user.email "you@example.com"
Ensure that the `python` command on your system is python *3*, not 2. You
should ensure that you have the correct *build dependencies* installed; check
the script names inside `resources/scripts/build/dependencies` and pick one
that matches your Linux distro; if one isn't available, adapt accordingly.
Then run it as root. For example, on Debian (stable, testing or sid all
confirmed to work, as of 9 May 2023):
./build dependencies debian
With build dependencies installed, and Git configured, you may then run
lbmk commands to compile the ROM image.
Libreboot's `blobutil`, while in the `e6400nvidia_wip` branch, can be
executed like so:
./blobutil download e6400nvidia_4mb
*The above command is executed automatically, when Libreboot's build system
is called, to build the full E6400 ROM image like so:*
./build boot roms e6400nvidia_4mb
The `download` command (see above) pulls down Dell's BIOS update (A34 release),
and extracts the VGA ROM from that. This is then saved to `pciroms/` under
lbmk.
The `./build boot roms` command (see above) automatically inserts this PCI
ROM, and it is downloaded automatically if the PCI ROM is missing; if
downloading and/or extraction (of the Option ROM) fails, the entire build
process will fail (non-zero exit status). DO NOT flash it until you confirm
that the build went successfully. For example, try:
make -BC coreboot/default/util/cbfstool/cbfstool
cp coreboot/default/util/cbfstool/cbfstool .
Then check the E6400 ROM under `bin/`. Let's say the ROM was
named `libreboot.rom`, you would do:
./cbfstool libreboot.rom print
This would print the files that have been inserted into the ROM image (rom
stage, car, payloads etc), and it should list the PCI option ROM as the
following file, by name: `pci10de,06eb.rom`.
DO NOT flash it unless that file is present. If you've confirmed that the ROM
has compiled successfully, you can flash it.
**BEFORE** you flash it, please know that support for Nvidia variants is
a **work in progress**. Known issues exist. For more information, please
read the [E6400 info page](../hardware/e6400.md), [E6400 nvidia news
page](../../news/e6400nvidia.md) and the [development discussion via
codeberg](https://codeberg.org/libreboot/lbmk/issues/14#issuecomment-907758).
How to flash internally (no diassembly)
=======================================
@ -228,8 +90,7 @@ You can flash Libreboot directly from the vendor (Dell) BIOS, without taking
the machine apart. It can be done entirely from Linux. It will probably also
work on BSD systems, but it has only been testing on Linux thus far.
Check `util/e6400-flash-unlock` in the `lbmk.git` repository, or in release
archives for Libreboot releases from 20230423 onwards.
Check `util/e6400-flash-unlock` in the `lbmk.git` repository, or releases.
Go in there:

157
site/docs/install/index.md
View File

@ -10,28 +10,6 @@ get an error related to `/dev/mem` access, you should reboot with
`iomem=relaxed` kernel parameter before running flashrom, or use a kernel that
has `CONFIG_STRICT_DEVMEM` not enabled.
READ THIS BEFORE UPDATING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](ivy_has_common.md)**
NOTE: This warning does not apply to ROMs that you compiled yourself, using
lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted*
in release ROMs. The link above says how to re-add them. When building ROM images
yourself, from source, Libreboot's build system automatically handles it. See:
[Libreboot build instructions](../build/)
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
PRECAUTIONS
===========
@ -46,23 +24,6 @@ If you're already running libre firmware on your board, you should decide for
sure whether you wish to risk it. See changelogs on
the [release announcements via the news page](/news/) and decide for yourself.
Haswell/Ivybridge/Sandybridge machines
======================================
BLOBS MISSING IN RELEASE ROMs
-----------------------------
E.g. ThinkPad X220, X230, T440p, W541. - also desktop boards such as HP
Elite 8200 SFF.
The lbmk build system automatically fetches required blobs for these
boards, when building, and sets them up properly, e.g. `me_cleaner`
is used. The same process is also available in a script, which can
insert them into ROM images.
**If you're using release ROMs, these blobs are missing, and must be
added. See: [ivy_has_common.md](ivy_has_common.md).**
About ROM image file names
==========================
@ -198,36 +159,6 @@ Which systems are supported?
[Refer to the hardware compatibility page](../hardware/)
Sandy/Ivybridge/Haswell MAC address (e.g. X230, X220, T440p, W541, hp8200sff)
Intel GbE MAC address (IFD-based systems)
=====================================================================
You can change the MAC address in flash, on these machines. See:
[nvmutil documentation](nvmutil.md)
The MAC address is stored in a region of the boot flashed called *GbE NVM*
which is short for *gigabit ethernet non-volatile memory*. Refer to the
following article:
For GM45/ICH9M systems (e.g. ThinkPad X200/T400, Dell Latitude E6400), see:
[ich9utils documentation](ich9utils.md) (you can also use nvmutil, see link
above)
libreboot puts a default MAC address in the available ROM images, but this is
a generic MAC address and it's identical on every ROM image. Technically, you
can use it but if you encounter other libreboot users on the same ethernet
switch, using the same physical network as you, you will encounter a MAC
address conflict.
NOTE: R500 thinkpads do not have an Intel gigabit ethernet NIC, so on that
laptop you can just flash the default ROM and you do not have to worry.
There are also some Intel X4X platforms that use an ICH10 southbridge,
supported in libreboot, but these are flashed in a *descriptorless* setup,
which means that the MAC address is irrelevant (either there will be an Intel
PHY module that is now unusable, and you use an add-on card, or it doesn't use
an Intel PHY module and the onboard NIC is usable).
Install via host CPU (internal flashing)
========================================
@ -573,11 +504,6 @@ iMac5,2 isn't documented but you can find the flash chip on that board quite
easily. See the generic flashing guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
TARGET: HP Elite 8200 SFF
-------------------------
See: [HP Elite 8200 SFF hardware information](../hardware/hp8200sff.md)
TARGET: Gigabyte GA-G41M-ES2L mainboard
---------------------------------------
@ -683,86 +609,3 @@ TARGET: Lenovo ThinkPad R500 laptop
Refer to the following laptop:\
[ThinkPad R500](../hardware/r500.md)
sandybridge/ivybridge/haswell
=================
**If using release ROMs, neutered ME must be inserted. Refer to the info
below.**
HP laptops AND desktops (all of them)
-------------------------------------
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Refer to links about and the [hardware page](../hardware/) for installation
instructions on each HP mainboard.
TARGET: ThinkPad X220/T420/T420s
--------------------------------
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Similar to X230 but there's only 1 flash. Intel ME image must be inserted
if using release ROMs. See: [guide](ivy_has_common.md) (says ivy/haswell but
the insert script for ME works with sandybridge aswell).
Refer to assembly/disassembly guide for T420:
[ThinkPad T420 external flashing](t420_external.md) (T420s is very similar)
X220/X220i: disassembly/reassembly very similar to X230. Please refer to
X230 instructions, but note: X220/X220i has *one* flash chip, not two.
**If using release ROMs, neutered ME must be inserted. Refer to the above
guide.**
TARGET: Thinkpad X230/T430/T530/W530
---------------------
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
NOTE: no install docs for T430/T530/W530 yet, but check coreboot wiki.
NOTE: Internal flashing is also possible, on this machine, from vendor firmware,
but it's still recommended to use a clip and a SPI flasher. However, follow
[internal X230 flashing from Lenovo firmware](ivy_internal.md) if you wish.
Refer to the [ivybridge/haswell common guide.](ivy_has_common.md) for how to
make the rom image usable for external flashing (with a clip). **If using
release ROMs, you must insert the neutered ME. Look at the info on that page.**
Read [board documentation](/docs/install/x230_external.html) for disassembly.
TARGET: Thinkpad X230t
---------------------
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Refer to the [ivybridge/haswell common guide.](ivy_has_common.md) for how to
make the rom image usable for external flashing.
Read [board documentation](/docs/install/x230_external.html) for disassembly.
(same instructions as X230, for this purpose of external flashing, but
full disassembly will differ slightly)
**If using release ROMs, neutered ME must be inserted. Refer to the above
guide.**
TARGET: Thinkpad t440p/w541
---------------------
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Refer to the [ivybridge/haswell common guide.](ivy_has_common.md) for how to
make the rom image usable for external flashing.
Read [board documentation](/docs/install/t440p_external.html) for disassembly.
**If using release ROMs, neutered ME must be inserted. Refer to the above
guide.**

175
site/docs/install/ivy_has_common.md
View File

@ -1,175 +0,0 @@
---
title: Insert binary blobs on Sandybridge/Ivybridge/Haswell
x-toc-enable: true
...
For how to use an external programmer see the [25xx NOR flashing guide](/docs/install/spi.html)
The Intel Flash Descriptor defines that the first 5MiB of the 12MiB boot flash consists of
the Intel Flash Descriptor, GbE and Intel ME regions. The final 7MiB of that
12MiB flash is the BIOS region. However, this 12MiB of flash is physically split
into an 8MiB NOR flash and a 4MiB NOR flash; the OS sees a continuous 12MiB of
flash, with the lower part being the contents of 8MiB NOR flash and the upper
contents being the 4MiB NOR flash.
Do not worry too much about which flash chip your programmer is connected to.
Flashrom will fail if you try to flash the wrong sized image for the chip you are connected
to.
The libreboot roms released or built for haswell or ivybridge boards come as 12/16MiB roms.
The size of the rom in question refers to the total size of *both* chips.
In order to flash a full rom externally, you need to split the rom into two sections to fit the size of the two chips you wish to flash.
This guide will show examples for the Thinkpad X230, but all of the information will apply to other boards.
Ivybridge boards require *at least* the intel management engine in order to boot.
Haswell boards additionally require the mrc blob.
Neither of these blobs are redistributable, so roms for these boards must be built from source or patched with the required blobs.
If you're planning to flash a release rom to your board then you need only patch the existing rom.
Alternatively, you can attempt to build a rom from source for your board.
Internal flashing
-----------------
For ivybridge specifically (e.g. thinkpad X230, T430) on Lenovo ThinkPads,
it is possible to flash from vendor firmware to Libreboot, without using a
clip, but some disassembly is still required. This can be beneficial if you
want to save money by not buying external flashing equipment. All you need is
a pain of metal tweezers or something similar that can be used to create
a short circuit between two conductors.
See: [ivybridge internal flashing](ivy_internal.md)
Obtaining Binary Blobs
----------------------
If you have built your rom from source then all of the blobs are generally downloaded automatically.
Some boards however, do not have sources for all blobs and require manual blob extraction.
If you try to build a rom from source and lbmk fails to locate the blobs, you can extract them from an existing rom backup.
To do this, start by obtaining a full backup rom from your machine.
Once you have connected your programmer and read from both flash chips, you will have to combine the two images to a single rom.
In general, the 4mb image is the top, and the 8mb image is the bottom.
To create a readable rom file, simply concatenate the two files.
cat bottom.rom top.rom > full_backup.bin
Once you have a backup of your vendor rom, you can use lbmk to automatically extract the necessary blobs.
The blob extraction script takes a board name as the first argument and a path to a rom as the second argument.
For example, here is how you would extract the blobs from an x230 rom backup.
./blobutil extract x230_12mb full_backup.bin
Note that the above command must be run from the root of the lbmk directory.
See [building instructions](/docs/build/index.html) for more details.
Injecting Blobs into an Existing Rom
------------------------------------
Release roms cannot include certain blobs for legal reasons.
You therefore **cannot** directly flash a release rom to your board.
You must patch the release rom with the necessary blobs *and then* flash it to your board.
Lbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
You must determine the correct board name, for your board, based on the list
generated when running this command:
./build boot roms list
For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware.
Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware.
Another example: `x230_12mb` corresponds to Thinkpad X230.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple.
Run the injection script pointing to the release archive you downloaded:
./blobutil inject /path/to/libreboot-20230319-18-g9f76c92_t440pmrc_12mb.tar.xz
The script can automatically detect the board as long as you do not change the file name.
You can then find flash-ready ROMs in `/bin/release/`
Alternatively, you may patch only a single rom file.
For example:
./blobutil inject -r x230_libreboot.rom -b x230_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
**NOTE: Haswell machines come with `mrc.bin` or without, depending on the
ROM image configuration. These ROM configs have `mrc.bin`: `t440pmrc_12mb`
and `w541mrc_12mb`. These ROM configs have libre MRC: `t440p_12mb`
and `w541_12mb` - it is critical that you choose the right one, when using
the `-b` flag in the `blobutil inject` command. For example, if you
used `-b t440p_12mb` on a ROM image that actually corresponds
to `t440pmrc_12mb`, then the required `mrc.bin` file would not be added
and that ROM would not boot when flashed.**
**NOTE: In the Libreboot 20230319 src archive or git tag, the `blobutil`
insert method is broken on Haswell configs that need `mrc.bin`, because it does
not insert `mrc.bin` at the correct offset. This was fixed in revisions after
the release, and will be available in the next release after that. Read
the [Libreboot 20230319 update
announcement](../../news/libreboot20230319_update.md) for more information.**
NOTE: the MAC changer makes use of `nvmutil`, which you can read more about in
the [nvmutil documentation](nvmutil.md).
**WARNING: This is broken in Libreboot 20221214's src archive. It fails when
attempting to use cbfstool, due to a faulty check in a script. This is fixed in
recent Libreboot releases or revisions. The fix is as
follows:
Edit line 137 in `resources/scripts/blobs/inject`. The line in 20221214 says
this:
make -C cd coreboot/default/util/cbfstool || Fail 'could not build ifdtool'
Modify it to say this:
make -C coreboot/default/util/cbfstool || Fail 'could not build cbfstool'
ALSO:
*When generating a MAC address*, the same script tries to build `nvmutil`
from `/util/nvmutil`, in Libreboot 20221214. This was discovered on 10 January
2023, based on user report on IRC. Fix it like so (already fixed, in latest
Libreboot from Git):
Line 30, it says:
make -C /util/nvmutil || Fail 'failed to build nvmutil'
Change it to say:
make -C util/nvmutil || Fail 'failed to build nvmutil'
Until this is edited accordingly, the inject script will *exit* with non-zero
status, and no blobs will be injected.
This has been fixed, following the Libreboot 20221214 release, but you must
apply this fix yourself, if using *that* release.
Splitting The Rom
-----------------
You can use `dd` to easily split your rom into the two separate portions for
external flashing.
For example, here is how you would split a 12mb rom for installation:
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
You would then flash the 4MiB chip with `top.rom` and the 8MiB chip with `bottom.rom`.
For a larger rom image, the same logic would apply.
In dd `skip` means that you want the program to ignore the first n blocks, whereas
`count` means you want it to stop writing after n blocks.
Once you have your rom image split you can proceed to [flashing.](/docs/install/spi.html)

166
site/docs/install/ivy_has_common.uk.md
View File

@ -1,166 +0,0 @@
---
title: Спільне Sandybridge/Ivybridge/Haswell
x-toc-enable: true
...
Для як використовувати зовнішній програматор дивіться [керівництво прошивання 25xx NOR](/docs/install/spi.html)
Intel Flash Descriptor означує, що перші 5Мб з 12Мб завантажувальної флеш-пам'яті складається з
регіонів Intel Flash Descriptor, GbE та Intel ME. Фінальні 7Мб тої
12Мб флеш-пам'яті є регіоном BIOS. Однак, ця 12Мб флеш-пам'ять є фізично розділеною
на флеш-пам'ять 8Мб NOR та флеш-пам'ять 4Мб NOR flash; операційна система бачить продовжувані 12Mб флеш-
пам'яті, з нижчою частиною, яка є вмістом флеш-пам'яті 8Мб NOR та вищим
вмістом, що є флеш-пам'ять 4Мб NOR.
Не хвилюйтесь надто багато про те, до якого флеш-чіпа ваш програматор під'єднано.
Flashrom вийде з ладу, якщо ви спробуєте прошити образ з неправильним розміром для чіпа, до якого ви
під`єднані.
Образи libreboot, випущені або побудовані для плат haswell або ivybridge ідуть як образи 12/16Мб.
Розмір образа в питанні посилається на загальний розмір *обох* чипів.
В порядку для того, щоб прошити повний образ зовнішньо, ви маєте поділити образ на дві секції для вміщення в розмір двох чипів, які ви бажаєте прошити.
Це керівництво покаже приклади для Thinkpad X230, але вся інформація буде застосована для інших плат.
Плати Ivybridge вимагають *хоча би* intel management engine в порядку для завантаження.
Плати Haswell додатково вимагають блоб mrc.
Ні один з цих блобів не є перерозповсюджуваним, тому образи для цих плат має бути побудовано з джерельного коду або виправлені з затребуваними блобами.
Якщо ви плануєте прошити rom випуску для вашої плати, тоді ви потребуєте лише виправити існуючий rom.
Альтернативно, ви можете спробувати побудувати rom з джерельного коду для вашої плати.
Внутрішнє прошивання
-----------------
Для ivybridge конкретно (тобто, thinkpad X230, T430) на Lenovo ThinkPad,
можливо прошитись з мікропрограмного забезпечення постачальника до Libreboot, без використання
кліпси, але деякий розбір досі потрібен. Це може бути вигідно, якщо ви
хочете заощадити кошти за допомогою некупівлі обладнання для зовнішньої прошивки. Все, що вам потрібно,
це металевий пінцет або щось подібне, за допомогою якого можна створити коротке
замикання між двома провідниками.
Дивіться: [внутрішнє прошивання ivybridge](ivy_internal.md)
Отримання бінарних блобів
----------------------
Якщо ви побудували ваш rom з джерельного коду, тоді всі блоби загалом завантажено автоматично.
Деякі плати, однак, не мають джерел для всіх блобів і вимагають ручного вилучення блобів.
Якщо ви пробуєте побудувати rom з джерельного коду та lbmk виходить з ладу при розміщенні блобів, ви може вилучити їх з існуючої резервної копії rom.
Щоб зробити це, почніть з отримання повної резервної копії rom для вашої машини.
Після того, як ви підключили програматор і зчитали обидва флеш-чіпи, вам доведеться об'єднати два образи в якості одного rom.
Загалом, образ 4Мб є верхнім і образ 8Мб є нижнім.
Для створення файлу rom, придатного для читання, просто виконайте конкатенацію обох файлів.
cat bottom.rom top.rom > full_backup.bin
Створивши резервну копію rom постачальника, ви можете використати lbmk для автоматичного вилучення потрібних блобів.
Сценарій вилучення блобів приймає ім'я плати в якості першого аргумента та шлях до rom в якості другого аргумента.
Наприклад, ось те, як би ви вилучили блоби з резервної копії rom x230.
./blobutil extract x230_12mb full_backup.bin
Майте на увазі, що команда зверху має бути виконана з кореня директорії lbmk.
Дивіться [інструкції побудови](/docs/build/index.uk.html) для більших подробиць.
Введення блобів в існуючий образ
------------------------------------
Образи випусків не можуть включати конкртні блоби з юридичних причин.
Тому ви **не можете** напряму прошити образ випуску на свою плату.
Ви маєте виправити rom випуску необхідними блобами *і потім* прошити їх на свою плату.
Lbmk включає сценарій, який автоматично введе необхідні блоби в файл rom.
Сценарій може визначити плату в автоматичному режимі, якщо ви не змінили ім'я, але ви можете також встановити
ім'я плати самостійно з використанням флага `-b`.
You must determine the correct board name, for your board, based on the list
generated when running this command:
./build boot roms list
For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware.
Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware.
Another example: `x230_12mb` corresponds to Thinkpad X230.
В порядку для введення необхідних блобів в образ rom, виконайте сценарій з кореня lbmk та вкажіть на образ rom.
Наприклад:
./blobutil inject -r x230_libreboot.rom -b x230_12mb
Опціонально, ви можете використовувати цей сценарій для модифікації mac-адреси rom з флагом `-m`.
Наприклад:
./blobutil inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
**ПРИМІТКА: Машини Haswell ідуть з `mrc.bin` або без, залежно від
конфігурації образа ROM. Ці конфігураційні файли ROM мають `mrc.bin`: `t440pmrc_12mb`
та `w541mrc_12mb`. Ці конфігураційні файли ROM мають вільний MRC: `t440p_12mb`
та `w541_12mb` - критичним є те, щоб вибрати правильний, коли використовуєте
флаг `-b` в команді `blobutil inject`. Наприклад, якщо ви
використали `-b t440p_12mb` на образі ROM, який насправді відповідає
`t440pmrc_12mb`, тоді затребуваний файл `mrc.bin` не буде додано
і той ROM не завантажиться після прошивання.**
**ПРИМІТКА: В архіві src Libreboot 20230319 або git tag, метод `blobutil`
зламано на конфігураційних файлах Haswell, які вимагають `mrc.bin`, тому він
не введе `mrc.bin` на правильному офсеті. Це було виправлено в ревізіях після
випуску, і буде доступно в наступному випуску після цього. Прочитайте
[оголошення оновлення Libreboot
20230319](../../news/libreboot20230319_update.md) для більшої інформації.**
ПРИМІТКА: редактор MAC використовує `nvmutil`, про який ви можете прочитати більше в
[документації nvmutil](nvmutil.md).
**УВАГА: Це поламано в архіві src Libreboot 20221214. Він виходить з ладу при
спробі використання cbfstool, в зв'язку з проблемною перевіркою в сценарії. Це виправлено в
нещодавніх випусках Libreboot або ревізіях. Виправлення
наступне:
Відредагуйте рядок 137 в `resources/scripts/blobs/inject`. Рядок в 20221214 каже
це:
make -C cd coreboot/default/util/cbfstool || Fail 'could not build ifdtool'
Модифікуйте його казати це:
make -C coreboot/default/util/cbfstool || Fail 'could not build cbfstool'
ТАКОЖ:
*Коли створюєте MAC-адресу*, той самий сценарій намагається побудувати `nvmutil`
з `/util/nvmutil`, в Libreboot 20221214. Це було знайдено 10 січня
2023 року, засновуючий на звітах користувачів на IRC. Виправіть це подібним чином (вже виправлено, в останньому
Libreboot з Git):
Рядок 30, він каже:
make -C /util/nvmutil || Fail 'failed to build nvmutil'
Змініть його казати:
make -C util/nvmutil || Fail 'failed to build nvmutil'
До того часу, поки це не буде відредаговано відповідним чином, сценарій введення *вийде* з не-нульовим
статусом, та блоби не буде введено.
Це було виправлено, в наступних після Libreboot 20221214 випусках, але ви маєте
застосувати виправлення самостійно, якщо використовуєте *той* випуск.
Розділення Rom
-----------------
Ви можете використовувати `dd` для легкого розділення вашого rom на дві окремі порції для
зовнішнього прошивання.
Наприклад, таким чином ви би поділили rom 12Мб для встановлення:
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
Ви би потім прошили чип 4Мб з `top.rom` та чип 8Мб з `bottom.rom`.
Для більшого образа rom, та ж сама логіка була би застосована.
В dd `skip` означає, що ви бажаєте, щоб програма проігнорувала перші n блоків, де
`count` означає, що ви хочете, щоб вона зупинила запис після n блоків.
Коли ваш образ rom поділено, ви можете перейти до [прошивання.](/docs/install/spi.html)

67
site/docs/install/ivy_internal.md
View File

@ -1,67 +0,0 @@
---
title: Ivybridge internal flashing
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
External flashing still recommended
-----------------------------------
Internal flashing is quite complex, from a software and hardware
perspective, when switching from Lenovo firmware to Libreboot.
If you already have Libreboot, then you likely have the entire
flash unlocked so you can refer to generic flashing instructions.
Internal flashing from Lenovo firmware is more time consuming, but basically
costs less money, because there's less equipment that you need for it.
This method is also more risky, because one of the steps involves shorting
two pins on the HDA (audio) chip, and if you do it wrong you could short
the wrong thing by mistake; consequences could be blown fuses and/or fire,
or just a dead ThinkPad. Proceed at your own risk!
If you prefer external flashing, see: [external flashing](x230_external.md)
Internal flashing from vendor firmware (ThinkPads only)
----------------------------------------
IVYBRIDGE ONLY:
Refer to this coreboot guide:
<https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html?highlight=x230>
With this guide, you can exploit a vulnerability in Lenovo firmware, to flash
just the BIOS region without disassembling your machine.
You will have to flash just the BIOS region, on upstream coreboot. Just compile
upstream coreboot from scratch. Coreboot instructions here:
<https://doc.coreboot.org/tutorial/index.html>
You can then strap HDA\_SDO (soft descriptor override), which will disable
flash protections set in the Intel Flash Descriptor. More info about that is
available here:
<https://winraid.level1techs.com/t/guide-unlock-intel-flash-descriptor-read-write-access-permissions-for-spi-servicing/32449>
On ivybridge platforms specifically, coreboot supports what's called
the *ME Soft Temporary Disable*, which disables the ME after BringUp, similar
to `me_cleaner`. You can do this by setting `me_state=Disabled` in nvramtool.
Now boot with HDA\_SDO strapped. On the HDA (audio) chip, there is a pin that
you can short, to disable IFD-based flash protections. You simply HOLD it in
the shorted state, while booting up the machine, and if successful, you will
then have the flash unlocked. This, combined with ME Soft Temporary Disable,
and the internal flashing guide linked above (from coreboot.org), you'll get
to a state where you can simply flash all regions. You can then flash the
truncated+neutered images from Libreboot, after building the ROMs in lbmk; see
[Libreboot build instructions](../build/).
The following photo shows what to short on the ThinkPad X230. You'll have to
look for it. X230 is easy because you don't have to directly touch the pins,
instead you can use alt points that have continuity. They are marked on this
photo:
<img tabindex=1 src="https://av.libreboot.org/x230/hda_sdo.jpg" /><span class="f"><img src="https://av.libreboot.org/x230/hda_sdo.jpg" /></span>
TODO: Document other ivybridge thinkpads (just show pics)

4
site/docs/install/kgpe-d16.md
View File

@ -3,10 +3,6 @@ title: KGPE-D16 external flashing instructions
x-toc-enable: true
...
**KGPE-D16, KCMA-D8 and KFSN4-DRE ASUS mainboards were removed on 19
November 2022. You can still use older revisions of Libreboot, and older
release versions.**
These will be re-added to Libreboot at a later date, once proper testing
has been done.

35
site/docs/install/nvmutil.md
View File

@ -6,12 +6,6 @@ x-toc-enable: true
With this software, you can change the MAC address inside GbE regions
on any system that uses an Intel Flash Descriptor.
This is the reference documentation for `nvmutil`, but an automated script
using nvmutil is available for ivy/sandybridge and haswell hardware, when
inserting blobs, which you can use to change the MAC address. See:
[docs/install/ivy_has_common.md](ivy_has_common.md)
You can use the documentation below, if you wish to use `nvmutil` manually.
Continue reading...
@ -494,35 +488,6 @@ The Linux kernel's `e1000` driver will refuse to initialise
Intel gigabit NICs that don't have a valid checksum. This
is software-defined, and not enforced by the hardware.
History
=======
A historical change log
is included at [docs/install/nvmutilimport.md](nvmutilimport.md),
but this simply lists historical changes to nvmutil when it
was a separate project. Future changes to nvmutil can be found by
running `git log util/nvmutil` in `lbmk.git`. No more changes
to `nvmutilimport.md` will be applied, but future releases of
Libreboot announced in `news/` will mention any nvmutil changes.
The *older* `nvmutils` is still available, for reference. See:
* <https://notabug.org/osboot/nvmutils/>
The `nvmutil` software is a clean re-write of `nvmutils`,
which is compiled to a single binary instead of multiple
binaries. It contains many fixes and enhancements that
are absent in the *original* `nvmutils` programs. The
old `nvmutils` project has been deprecated, and
abandoned. All new development shall now be performed
on `nvmutil`.
Libreboot's version of nvmutil is located at `util/nvmutil` in
the `lbmk.git` repository. The original nvmutil project, when
it was part of osboot, is still available (for reference) here:
* <https://notabug.org/osboot/nvmutil/>
LICENSE
=======

256
site/docs/install/nvmutilimport.md
View File

@ -1,256 +0,0 @@
Detailed revision history can be found in the Git repository; for code,
look at `lbmk.git` and for documentation, look at `lbwww.git`.
Assimilation by Libreboot
=========================
With no additional changes to nvmutil, the project became part of lbmk,
which is the Libreboot build system. Please refer to Libreboot's imported
version of the nvmutil documentation: [nvmutil.md](nvmutil.md)
This code and documentation import was performed on November 17th, 2022.
Future changes to nvmutil (in `lbmk.git`) shall be included in regular
Libreboot release announcements, under `news/`, so please be sure to
check that from now on.
For historical and reference purposes, the original nvmutil repository
shall be preserved on notabug. See:
<https://notabug.org/osboot/nvmutil>
nvmutil 20221106
================
Very minor bugfix release:
* Pledge now changed to `stdio rpath` (instead of `stdio wpath`), only
when the `dump` command is used. (pledge is only used on OpenBSD
systems; an ifdef rule prevents its use on other systems)
* Documentation inaccuracies fixed (pertaining to nvmutil exit statuses)
* Documentation generally tidied up a bit
nvmutil 20221103
================
Not much has changed, as this just fixes minor bugs and behavioural
quirks seen in the previous release:
* Prototypes now fully declared, with variable names
* Fix implicit type conversion in readFromFile()
* Always exit with zero status if the file was successfully modified.
Previously, nvmutil would exit non-zero if one of the parts was invalid,
even if the other was OK (and successfully modified)
* Always exit with zero status when running dump, if at least one
part contained a valid checksum and the file is of the correct size,
fully readable. Previously, nvmutil would exit non-zero if one or both
checksums was correct, but it now only does this if both are invalid
nvmutil 20220828
================
No new features have been added. This is a code cleanup and bugfix release.
* General code cleanup (e.g. simpler argument handling)
* Do not print errno 0 (fixes error when using the libc in OpenBSD)
* Improved errno handling
* Endianness portability re-implemented
* The `dump` command no longer warns about multicast MAC addresses
(such a warning is unnecessary, and up to the user to prevent)
* The `setmac` command still prevents multicast MAC addresses being
set, but no longer specifically warns about them (the documentation
says not to use them already. No need to re-implement documentation
in code)
* Bug fix: errno now set, when an invalid file size is detected. The
previous nvmutil version would exit (no operation) when the file size
was wrong, but it would return with zero status. It now returns with
non-zero status
* The compiled binary size is still roughly the same as in the last
release; the endianness checks increase the size, but other optimizations
were made (e.g. cleaner argument handling). Tested with tcc on an x86\_64
machine, where a 0.16% binary size increase was observed.
nvmutil 20220815
================
No new features have been added. This is a code cleanup and bugfix release.
* Further 7% reduction in binary size, compared to the previous release.
This is tested with `tcc` in an x86\_64 machine. On my tests, `tcc`
produces a 10540 byte binary in the previous release; in this release
I got 9796 bytes.
* It should be noted that `nvmmac` from the older nvmutils is 9892 bytes
compiled with `tcc` on my test system; that's with the help/version
output text removed from nvmmac. *This* nvmutil release contains
so many more features and safety checks than just that lone `nvmmac`
utility, yet the `nvmutil` binary is 1% smaller in size! That's how
efficient the `nvmutil` code is, and there is probably room for further
improvement of code efficiency.
* Endianness portability code deleted; it was untested, and still is, so
now nvmutil will detect the host endianness and exit, if the host is
big endian (nearly all hosts these days are little endian, and it's
very unlikely that you will use a big endian host).
(the code will be properly tested and ported to big-endian hosts for the
next release)
* The `status` variable is no longer used; instead, `errno` is used
exclusively and extensively. Error handling is much simpler, and much
more unixy as a result.
* Error messages are more terse
* Fix build issues with clang, from the previous release
* The `dump` command no longer states whether the MAC address is local
or global; this can be easily done by yourself, and this change slightly
reduces code bloat in nvmutil. The code still warns you if the MAC address
is multicast
nvmutil 20220810
================
* 3.4% reduction in binary size (as tested with tcc on x86\_64),
due to code optimizations, *while* adding new checks and new features.
* Random MAC address generation now takes multicast/unicast and
local/global MAC addresses into account. The generator now *forces*
local MAC addresses to be generated; the only way to set a global
address is to set the corresponding nibble statically.
Multicast and all-zero MAC addresses are *no longer permitted* in code.
* The `dump` command now warns when the address is multicast, if set by
another tool or older nvmutil that way (it will also return non-zero
status upon exit). In addition, it will say whether the address is
locally or globally assigned.
* nvmutil now aborts when you try to open a directory
* Even more terse error/feedback messages than in the last release,
while still being friendly and informative
* word/setWord now done in a more efficient, endian-specific way
on x86\_64 platforms; if non-x86\_64, it falls back to the portable
functions
* The code has been simplified in general, and tidied up compared to
the previous release
* The `setmac` command can now be used without specifying a MAC address,
which will cause the same behaviour as `setmac ??:??:??:??:??:??`
nvmutil 20220808
================
Released on 8 August 2022. Changes:
* Vastly reduced binary size (21% reduction); the source line
count has reduced by roughly the same amount (slightly higher
than 21%, because of the extra stuff compilers add).
This is *with* new features and behaviours added; the code
is just that much more efficient, and I've thoroughly audited it.
* OpenBSD `pledge(2)` now used, if available at build time
(ifdef rule used, so it still compiles on Linux/FreeBSD)
* New feature: `setmac` is now able to set *random* MAC addresses.
This is done by reading from `/dev/urandom`. It is done
conditionally, per-nibble, as specified by the user. For example,
you can specify `??:??:??:??:??:??` and every nibble will be
random, or you could set some of them statically. For
example: `00:1f:16:??:4?:?2`
* The `read()` and `pwrite()` functions are now used for reading
and writing files; older nvmutil versions used fopen/fseek/ftell
and so on. The read/write functions are POSIX, and enable
more robust file handling.
* On `showmac` and `dump`, `O_RDONLY` is now set when
executing `read()`. This means that these commands can now be
used on read-only files.
* Makefile: `-Os` flag used, instead of `-O2`
* Error messages and feedback are much more user-friendly,
and useful in general, while being much more terse.
* The returned status on exit is *much* stricter. For example,
the `dump` command will always cause an `EXIT_FAILURE` status
when at least *one* part in the NVM image has a bad checksum.
When writing a new MAC address, it will *work* only on valid
parts like before, but *now* nvmutil will return with `EXIT_FAILURE`
if *one OR* both parts are bad; older nvmutil versions *always*
returned `EXIT_SUCCESS` after modifying the file.
* The `help` and `version` commands have been removed; it is
best to simply read the documentation. Programs should not
include documentation inside themselves, but documentation should
always be supplied separately, alongside that program. This
change alone accounts for roughly 1/3 (33%) of the code size
reduction; the other 2/3 of that reduction is due to increased
code efficiency in general.
Regarding code size reduction
-----------------------------
My test setup is an x86\_64 machine with `tcc` used
as the compiler; the libc doesn't really matter, if
you use dynamic linking. Command:
make CC=tcc
Observations (dynamic linking with libc files):
* 20220808: 10.67KB
* 20220802 (unmodified): 13.51KB
* 20220802 (help/version command removed): 12.56KB
SLOC (source lines of code):
* 20220808: 321 lines
* 20220802 (unmodified): 421 lines
* 20220802 (help/version command removed): 373 lines
These numbers were obtained, using the `sloccount` program
by David A. Wheeler, which you can find here:
* <https://dwheeler.com/sloccount/>
This means that the actual reduction in compiled *logic* is
about 1.89KB, or a 15% reduction, in nvmutil 20220808. By *logic*,
I mean all code excluding the help function; this distinction is
important, because the help/version commands are unavailable in
nvmutil 20220808, but they were available in nvmutil 20220802.
Extra note: I also tested compressed sizes. With `tar` piped to `xz -9e`,
I saw: about 3KB if compiled with tcc, and 5KB using gcc. Clang
produces binaries of similar size, when compared with GCC.
Since the performance of nvmutil is largely disk-bound, I really
recommend compiling it with `tcc`, not GCC or Clang because the
binary sizes are much larger with those compilers, even with
optimization flags; despite this, the Makefile in nvmutil
assumes GCC/Clang and sets `CFLAGS` to `-Os`.
nvmutil 20220802
================
Released on 2 August 2022. Changes:
* Another major code cleanup
* More reliable argument handling
* Files now loaded *after* verifying arguments
* Files no longer written unless all checks pass
(files were previously written unconditionally, even
if no changes were made, wasting disk i/o)
* Makefile now explicitly declares CFLAGS
(strictest flags possible, warnings treated as errors)
* More secure handling of strings; strnlen used instead
of strlen, strncmp used instead of strcmp, number of
characters limited
* New command added: show mac
(show what mac addresses are stored in both parts)
* More human-friendly messages and help text
* help/version commands actually listed in help output
nvmutil 20220731
================
Released on 31 July 2022. Changes:
* Major code cleanup
* Most operations now abort, if being performed
on invalid files.
* More robust error handling
* More user-friendly error messages
* The `malloc` function is no longer used
That's it. Bug fixes and safety features added. Enjoy!
nvmutil 20220728
================
Initial release. It is functionally equivalent to the
older `nvmutils`, developed for the osboot project. This
newer version is reduced to a single source file instead
of many, and builds as a single binary instead of many.

26
site/docs/install/spi.md
View File

@ -3,9 +3,6 @@ title: Read/write 25XX NOR flash via SPI protocol
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
This guide will teach you how to use various tools for externally reprogramming
a 25xx NOR flash via SPI protocol. This is the most common type of flash IC for
computers that coreboot runs on. Almost every system currently supported by
@ -451,19 +448,6 @@ they should all be the same length (VCC and GND wires can be longer).
This advice is *especially* applicable to the BBB, which is highly unreliable.
For boards with more than one flash chip you will need to read from both chips
and combine them into a single file.
Most of the time, a two chip setup includes one 8mb 'bottom' chip and one 4mb
'top' chip.
The setup just described applies to the x230, t430, t530, and t440p.
For other boards, make sure you know which chip contains the lower and upper
portions of the rom.
You can combine both flashes together with `cat` for example:
cat bottom_8mb.rom top_4mb.rom > full_12mb.rom
Note that you will need this combined rom if you intend to manually extract blobs.
Writing
-------
@ -492,16 +476,6 @@ Verifying flash... VERIFIED.
If it says "VERIFIED" or says that the chip contents are identical to the
requested image, then the chip is properly flashed.
If the board you are writing to has two chips you'll need to split the rom into
two sections.
For example, to split a rom for the x230, t430, t530, or t440p run:
dd if=libreboot_12mb.rom bs=1M of=bottom.rom count=8
dd if=libreboot_12mb.rom bs=1M of=top.rom skip=8
Flash the resulting roms to each of their respective chips according to the above instructions.
Hardware configuration
======================

3
site/docs/install/spi_generic.md
View File

@ -3,9 +3,6 @@ title: Generic SPI Flashing Guide
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
There are a plethora of single board computers with which you can flash libreboot to a SOIC chip.
Some users might be daunted by the price of a raspberry pi.
This guide is intended to help users looking to use a programmer which is not listed in the [main guide.](spi.md)

78
site/docs/install/t420_external.md
View File

@ -1,78 +0,0 @@
---
title: ThinkPad T420 external flashing
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Read the [Ivybridge/Haswell common guide](/docs/install/ivy_has_common.html) if you want more information. Please note, for Thinkpad T420, splitting the rom is not required.
The following instructions expect you to have these on hand:
+ a clone of lbmk, can be obtained from `https://codeberg.org/libreboot/lbmk`
+ necessary tools (flat-nose pliers or sleeve tool, screwdriver, small crowbar)
+ some CPU grease
+ a pack of backup screws
+ a programmer
Preparing a release Rom
-----------------------
You must patch the release rom with the necessary blobs *and then* flash it to your board.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple.
Run the injection script pointing to the release archive you downloaded:
./blobutil inject /path/to/libreboot-20230423_t420_8mb.tar.xz
The script can automatically detect the board as long as you do not change the file name.
You can then find flash-ready ROMs in `/bin/release/`
Alternatively, you may patch only a single rom file.
./blobutil inject -r t420_libreboot.rom -b t420_8mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r t420_libreboot.rom -b t420_8mb -m 00:f6:f0:40:71:fd
Disassembly
-----------
Be patient when trying to disassembly Thinkpad T420, the disassembling is relatively complicated. You need to take the main board off the magnesium structure frame, for a complete disassembly.
Since there are a lot of screws on it, you need to at least get few spare screws in case that you messed it up. And also, using each screw only once is recommended.
The disassembly guide here aimed to be simple and clear. But if you are confused, the [ThinkPad T420 Hardware Maintenance Manual](https://web.archive.org/web/20230106040715/https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/t420_t420i_hmm.pdf) is always your friend.
Start by detaching some plates, main battery, and the ultrabay. Loosen the screws (in blue border) but don't remove it, and just pull out the plates. For the battery and the ultrabay, just unlock it and detach it. If you have any expresscard, SD card attached, also remove it.\
![](https://av.libreboot.org/t420/t420_back.jpg)
Next, remove all the screws on the black cover.\
![](https://av.libreboot.org/t420/t420_back_detached.jpg)
And now, you will able to remove the keyboard. Slightly use the crowbar to push the keyboard towards the screen to remove it. Also, pay attention to the cable under it, pull it off gently.\
![](https://av.libreboot.org/t420/t420_keyboard_removal.jpg)
![](https://av.libreboot.org/t420/t420_keyboard_cabel.jpg)
Now you can pull up around the sides of the front cover (the one with keyboard removed) to release it. Pull it upwards and lift it, pull it back to remove it. There is also a touchscreen cabel under it, pull it off as well.\
![](https://av.libreboot.org/t420/t420_side_lift.jpg)
Remove the red screws first to remove the speaker and pull off the cabel. Then, remove the pink screws and remove the modem, the telephone jack and the wireless WAN card. Pull out the anthenna cabel around them (You may need to remove your wireless WAN card in the back and push the cabel to the front). And, you need to remove the green screws and the connector in the blue box (of the picture). And then, lift up the screen to remove it.\
![](https://av.libreboot.org/t420/t420_under.jpg)
Remove the blue connections and the USB port. Then, remove the red screws and connection. Gently pull up the fan to remove it. Next, remove the pink screws (the position in picture may not be accurate, watch out for all the screws there).\
![](https://av.libreboot.org/t420/t420_screen_removed.jpg)
Now you can pull the bottom cover off. Turn it back, remove all the visible screws. Use your flat-nose pliers or sleeve tool to unscrew the VGA port. And you can pull your main board off the magnesium structure frame.
You will see the eeprom on the front:\
![](https://av.libreboot.org/t420/t420_board_front.jpg)
![](https://av.libreboot.org/t420/t420_board_front_eeprom.jpg)
The flash will likely be Winbond W25Q64CV. You may double check it by looking at the silkscreen.
Now, you can proceed to [flashing](/docs/install/spi.html) this machine.

97
site/docs/install/t440p_external.md
View File

@ -1,97 +0,0 @@
---
title: ThinkPad T440p external flashing
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Read the [Ivybridge/Haswell common guide](/docs/install/ivy_has_common.html) if you want more information.
All of the following instructions assume that you've cloned lbmk and are operating from the
root of that project. To do so, run
git clone https://codeberg.org/libreboot/lbmk
cd lbmk
You can now follow the rest of the instructions.
Preparing a release Rom
-----------------------
You must patch the release rom with the necessary blobs *and then* flash it to your board.
Lbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple.
Run the injection script pointing to the release archive you downloaded:
./blobutil inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz
The script can automatically detect the board as long as you do not change the file name.
You can then find flash-ready ROMs in `/bin/release/`
Alternatively, you may patch only a single rom file.
For example (libre replacement of `mrc.bin`):
./blobutil inject -r t440p_libreboot.rom -b t440p_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r t440p_libreboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd
If you're flashing a ROM that needs blob `mrc.bin`, you would do one of these
instead, for example:
./blobutil inject -r t440p_libreboot.rom -b t440pmrc_12mb
or (inserting a different MAC address)
./blobutil inject -r t440p_libreboot.rom -b t440pmrc_12mb -m 00:f6:f0:40:71:fd
NOTE: this makes use of `nvmutil`, which you can read more about in
the [nvmutil documentation](nvmutil.md).
Splitting The Rom
-----------------
You can use `dd` to easily split your rom into the two separate portions for
external flashing.
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
Flash the top chip with top.rom, and tho bottom chip with bottom.rom.
Don't worry about knowing which chip is which on a standard setup; flashrom will let you know if the
image size is incorrect for the chip you're flashing.
Disassembly
-----------
Start by removing the back cover screws and the main battery.\
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_back.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_back_orig.jpg" /></span>
You can then remove the back cover by sliding it off.
Next you need to:
+ Unplug the cmos battery
+ Unplug and unroute the fan cable
+ Unplug and unroute the black LED cable
+ Remove all visible screws
*Note: the ultrabay screw will loosen, but not come out of the assembly*\
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_nocover.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_nocover_orig.jpg" /></span>
Now you can pull up around the sides of the bottom assembly to release it.
Pull it upwards and lift it open to the front of the machine like a clamshell.
Make sure not to break the wires connecting the assembly to the rest of the machine.\
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_open.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_open_orig.jpg" /></span>
You should now be able to see the two flash chips near the RAM.\
<img tabindex=1 src="https://av.libreboot.org/board/t440p/t440p_chipLocation.jpg" /><span class="f"><img src="https://av.libreboot.org/board/t440p/t440p_chipLocation_orig.jpg" /></span>
You can now proceed to [flashing](/docs/install/spi.html) this machine.

13
site/docs/install/x220_external.md
View File

@ -1,13 +0,0 @@
---
title: ThinkPad X220/X220T external flashing
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
Make sure to read the [Ivybridge/Haswell common guide](/docs/install/ivy_has_common.html) before attempting to flash this board.
After you have prepared a rom and split it into two section, refer to this guide for disassembly instructions.
We don't currently have disassembly instructions for this board.
See [coreboot docs](https://www.coreboot.org/Board:lenovo/x220) for how to disassemble this machine to reveal the flash chips.

79
site/docs/install/x230_external.md
View File

@ -1,79 +0,0 @@
---
title: ThinkPad X230/X230T external flashing
x-toc-enable: true
...
**[PLEASE READ THESE INSTRUCTIONS BEFORE INSTALLING](../../news/safety.md),
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)**
NOTE: Internal flashing (from vendor firmware) to Libreboot is possible, on
this board, but the steps are a bit more complex than using an external flasher.
See: [internal ivybridge flashing](ivy_internal.md)
Read the [Ivybridge/Haswell common guide](ivy_has_common.md) if you want more information.
All of the following instructions assume that you've cloned lbmk and are operating from the
root of that project. To do so, run
git clone https://codeberg.org/libreboot/lbmk
cd lbmk
You can now follow the rest of the instructions.
Preparing a release Rom
-----------------------
You must patch the release rom with the necessary blobs *and then* flash it to your board.
Lbmk includes a script that will automatically inject the necessary blobs into a rom file.
The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag.
In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image.
Run the injection script pointing to the release archive you downloaded:
./blobutil inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz
The script can automatically detect the board as long as you do not change the file name.
You can then find flash-ready ROMs in `/bin/release/`
Alternatively, you may patch only a single rom file.
For example:
./blobutil inject -r x230_libreboot.rom -b x230_12mb
Optionally, you can use this script to modify the mac address of the rom with the `-m` flag.
For example:
./blobutil inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
NOTE: this makes use of `nvmutil`, which you can read more about in
the [nvmutil documentation](nvmutil.md).
Splitting The Rom
-----------------
You can use `dd` to easily split your rom into the two separate portions for
external flashing.
dd if=libreboot.rom of=top.rom bs=1M skip=8
dd if=libreboot.rom of=bottom.rom bs=1M count=8
Flash the top chip with top.rom, and tho bottom chip with bottom.rom.
Don't worry about knowing which chip is which on a standard setup; flashrom will let you know if the
image size is incorrect for the chip you're flashing.
Disassembly
-----------
Start by removing the battery.
Remove every screw from the bottom of the machine marked with a keyboard/touchpad indicator.
Pry up the keyboard and separate it from the palmrest.
![](https://av.libreboot.org/board/x230/palmrest.jpg)
Unplug the ribbon cable from the palmrest and pry it off as well.
![](https://av.libreboot.org/board/x230/palmrest_cable.jpg)
Pull up the protective cover to reveal the two soic chips for flashing.
![](https://av.libreboot.org/board/x230/chipLocation.jpg)

2
site/docs/linux/index.md
View File

@ -39,8 +39,6 @@ the `/boot` partition is accessible.
Full encryption for basic LUKS2 is supported in libreboot.
See [the guide](encryption.md) for more detail.
[The ZFSbootmenu guide](zfsbootmenu.md) builds upon the main encryption guide but describes a setup with ZFS native encryption and ZFSbootmenu.
Rebooting system in case of freeze
===================================

111
site/docs/linux/zfsbootmenu.md
View File

@ -1,111 +0,0 @@
---
title: ZFSbootmenu with Full Disk Encryption Guide
x-toc-enable: true
...
As described in the [general encryption guide,](encryption.md) Libreboot allows for full disk encryption including the boot partition.
Just as with the general guide, this explanation will demonstrate how to create a partition with moderate encryption for GRUB as well as a root partition with strong encryption.
The major differences between the encryption method described in the general guide and this guide are:
+ `/boot` must remain on the *root* zfs encrypted partition
+ The root partition will be encrypted with ZFS native encryption rather than LUKS
+ ZFSbootmenu will be loaded at the second boot stage (after Libreboot itself) rather than directly loading the operating system kernel/initramfs
[ZFSbootmenu](https://docs.zfsbootmenu.org/en/latest/) works by placing modified versions of the operating system kernel where they can be loaded by the system's bootloader.
ZFSbootmenu provides installation guides for various major distros in their [official docs.](https://docs.zfsbootmenu.org/en/latest/)
You should follow those docs for installation, only noting the differences necessary for full disk encryption described below.
The only differences between this guide and the docs are:
+ You need not install/configure syslinux as GRUB in Libreboot will be used to load the ZFSbootmenu kernel/initramfs
+ The ZFSbootmenu kernel/initramfs will reside on a LUKS encrypted partition you will create in this guide
+ Cryptsetup must be installed and configured to mount the LUKS encrypted partition
## Creating Encrypted Partition for GRUB
The following section is mostly identical to the main encryption guide except for the naming conventions of the partition in question.
When using ZFSbootmenu, the OS kernel/initramfs will reside on the root partion in the `/boot` directory; **not** on a separate boot partition.
The partition created in this section is only used to load the ZFSbootmenu kernel/initramfs itself and is therefore referred to as the 'pre-boot environment' *(pbe)* partition.
**Step 1:**
Create a LUKS2 formatted device with the PBKDF2 algorithm.
You can play around with the iteration count.
A higher iteration is more secure but will take GRUB a **very** long time to decrypt.
The [debian encrypted boot guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) recommends a count of 500,000 which will still take GRUB a very long time (around 25 seconds) but is faster than the default 1,000,000.
Use whatever count makes you feel comfortable.
I'll use an arbitrarily low count.
You'll also want to use a different password than you intend to use for your root partition.
We don't want someone to be able to get our root key by brute-forcing our less secure boot key.
`sudo cryptsetup luksFormat /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
**Step 2:**
Format and mount the new LUKS2 device.
```
sudo cryptsetup luksOpen /dev/sda1 pbe
sudo mkfs.ext4 -L boot /dev/mapper/pbe
sudo mkdir -p /boot/pbe
sudo mount /dev/mapper/boot /boot/pbe
```
**Note:**
If you wish to change the passphrase for the boot partition in the future then you'll need to pass the same arguments to cryptsetup as when you created it.
If you don't pass any special arguments, the key will be changed to the distro's default encryption and grub won't be able to decrypt it.
The command to use is:
`cryptsetup luksChangeKey /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
## Configure ZFSbootmenu
The [official ZFSbootmenu docs](https://docs.zfsbootmenu.org/en/latest/guides/general.html) will provide the most up-to-date information.
The only differences from the official documentation relevant here are that anything related to syslinux can be ignored and the configuration must be tailored to create only a single kernel/initramfs set.
Note that you should follow the *MBR/syslinux* guide for your distro if you are using the ZFSbootmenu guides.
Here is an example configuration:
```
> vim /etc/zfsbootmenu/config.yaml
Global:
ManageImages: true
BootMountPoint: /boot/pbe
DracutConfDir: /etc/zfsbootmenu/dracut.conf.d
PreHooksDir: /etc/zfsbootmenu/generate-zbm.pre.d
PostHooksDir: /etc/zfsbootmenu/generate-zbm.post.d
InitCPIOConfig: /etc/zfsbootmenu/mkinitcpio.conf
Components:
ImageDir: /boot/pbe/zfsbootmenu
Versions: false
Enabled: true
syslinux:
Config: /boot/syslinux/syslinux.cfg
Enabled: false
EFI:
ImageDir: /boot/pbe
Versions: false
Enabled: false
Kernel:
CommandLine: ro quiet loglevel=4
```
## Final Steps
Refer to the [general guide](encryption.md) on how to set up fstab/crypttab to mount the pre-boot environment on boot.
Replace references to *boot* with *pbe* if copying commands from the guide.
For example: make sure the partition is mounted at `/boot/pbe` rather than just `/boot.`
Ensure that your OS kernel/initramfs is generated with LUKS support.
LUKS support is generally automatically enabled in the kernel upon installing *cryptsetup.*
Create a simulated grub configuration to point Libreboot's GRUB to ZFSbootmenu.
Libreboot will search for and source a grub configuration file on boot/decryption automatically.
**Do not** actually install GRUB.
Simply create a file on the partition created for GRUB at `/boot/pbe/grub/grub.cfg` which points to the ZFSbootmenu kernel/initramfs.
```
mkdir -p /boot/pbe/grub
> vim /boot/pbe/grub/grub.cfg
linux /zfsbootmenu/vmlinuz-* loglevel=4
initrd /zfsbootmenu/initramfs-*
boot
```

205
site/docs/maintain/index.md
View File

@ -3,8 +3,8 @@ title: lbmk maintenance manual
x-toc-enable: true
...
Automated pragmatism
====================
Automated build system
======================
This manual describes the nature of `lbmk` (LibreBoot MaKe), the automated
build system used to produce libreboot releases. It is provided as a reference
@ -27,25 +27,10 @@ As such, you should always refer to the *live* version of this page, on
libreboot.org, when working on the `lbmk.git` repository; the live version is
provided for development on the Git repository!
libreboot blob reduction policy
============================
The coreboot software is nominally free, but it requires additional binary
blobs on many supported systems. These *blobs* lack source code, and the
coreboot project does not control them, but they can be used to perform
specific initialization tasks.
The libreboot project *allows* binary blobs from coreboot, but there is *still* a
lot of nuance to precisely what is allowed. It is important that you understand
these nuances, when working on *libreboot*.
[Please read the blob reduction guidelines](../../news/policy.md)
What is lbmk?
==============
In the same way that that *Alpine Linux* is a *Linux distribution*, Libreboot
In the same way that that *Trisquel* is a *GNU+Linux distribution*, Libreboot
is a **coreboot distribution**. The `lbmk` build system *is* that distro,
providing the glue necessary to integrate coreboot plus anything else that's
needed, unifying everything in a completely automated and pre-configured
@ -248,44 +233,6 @@ about the project
It's basically a copy of the homepage text, relative to libreboot.org.
blobs/
======
This directory contains binary blobs, presently only GbE and IFD files which
are non-software blobs; they are binary-encoded configuration files.
The IFD files are *Intel Flash Descriptors* configuring the machine, on Intel
machines that use flash descriptors, and the GbE files are configs for Intel
gigabit ethernet. You can read more about these on
the [freedom status page](../../freedom-status.md) - the `ifdtool`
and `nvmutil` programs interact with these (nvmutil is provided by Libreboot,
and ifdtool is supplied by the upstream coreboot project).
When `blobutil` is running, it will place temporary files here, extracting
binary blobs such as Intel ME firmware, for running through `me_cleaner`.
At present, only the GbE and IFD files are included here for Libreboot
releases, but other files such as `me.bin` are stored here during the build
process (auto-downloaded and processed through `me_cleaner` on boards that
need them).
NOTE: Other blobs such as EC firmware and Intel MRC are *not* placed here, by
lbmk.
blobutil
========
This script is responsible for downloading, extracting and inserting binary
blobs that are required on specific machines for coreboot. This is done
automatically, during the build process, but `blobutil` can also be used as
a standalone program, for *release* ROM images (many of which will have certain
blobs like Intel ME *scrubbed*, where the user is expected to insert them).
You can read more about this on the page: [Inserting binary blobs
on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
KBC1126 EC firmware for HP laptops is *also* handled by blobutil.
build
=====
@ -403,54 +350,6 @@ If you were to fork libreboot, you could very easily just modify this file, so
as to rename your fork in a largely automated way. Many parts of lbmk use this
file.
resources/blobs/
================
This directory contains ME7 Update Parser, and a file defining links to vendor
update files, from which Intel ME images are extracted, to be neutered
via `me_cleaner`.
resources/blobs/me7\_update\_parser.py
======================================
This is a special fork of `me_cleaner`, specifically for parsing and neutering
Intel ME images provided by Lenovo for ThinkPad X220 and other Lenovo
ThinkPads of Intel SandyBridge platform. You can find information about this
on the original repository:
<https://github.com/Thrilleratplay/me7_update_parser>
ME7 Update Parser was originally written for *Heads*, another coreboot distro
very similar to Libreboot that provides coreboot build automation with Linux
based payload configurations. *Their* build system auto-downloads and
auto-neuters Intel ME images, during build, so that the user does not have to
manually extract such images from dumps of the original vendor firmware (in
the flash) on a given machine.
Such logic was ported to Libreboot, courtesy of `shmalebx9` as mentioned
on the [who page](../../who.md) - Caleb is a core developer in the Libreboot
project.
resources/blobs/sources
=======================
URLs and hashes for vendor files containing Intel ME images within them. Where
feasible, backup URLs are also provided. SHA1 checksums are defined, so that
lbmk can verify the integrity of downloaded files.
When building for sandybridge, ivybridge and haswell machines, Libreboot's
bulid system automatically downloads such updates from the vendor, to extract
the Intel ME image and neuter it with `me_cleaner` or `me7_update_parser.py`.
Such auto-download logic was ported from the *Heads* build system, to be used
in the *Libreboot* build system. It is the bee's knees, because it prevents
the need for manual extraction of Intel ME images from vendor dumps. It means
that you can just *build Libreboot* (from `lbmk`) and then just flash the
resulting image, without having to worry.
Of course, backing up the original firmware is still a good idea, before
installing Libreboot or any other spin of coreboot.
resources/coreboot/
===================
@ -773,60 +672,6 @@ resources/scripts/
These scripts implement the *core* logic of Libreboot's *automated build
system*, to produce coreboot ROM images with payloads.
resources/scripts/blobs/download
================================
Where certain binary blobs like Intel ME or MRC are needed on a given board,
this script is called automatically by the build system, to download the files
for insertion.
Specific binary blobs handled are:
* Intel ME images (via `me_cleaner`)
* Intel MRC (haswell boards)
* VGA option ROMs (currently just [Dell Latitude
E6400 Nvidia variants](../../news/e6400nvidia.md))
* KBC1126 EC firmware (HP laptops)
resources/scripts/blobs/extract
===============================
Where auto-download is not viable, this script can provide a somewhat automated
experience for *extracting* blobs. You will supply a *dump* of the original
vendor firmware, dumped from the flash IC on whichever target machine you wish
to flash.
Dumping the original firmware is *always* recommended, regardless of what you
want to do.
Specific binary blobs handled are:
* Intel ME images (via `me_cleaner`)
TODO, NOT YET HANDLED BY `extract` (only handled by `download` and `inject`):
* Intel MRC (haswell boards)
* KBC1126 EC firmware (HP laptops)
* VGA option ROMs (currently just [Dell Latitude
E6400 Nvidia variants](../../news/e6400nvidia.md))
The `extract` method is useful for offline installation, where such files
are required, and available.
resources/scripts/blobs/inject
==============================
Where a blob is provided, via the `extract` or `download` method, *this*
script *inserts* a blob (ME, MRC etc) into a given target image.
Specific binary blobs handled are:
* Intel ME images (via `me_cleaner`)
* Intel MRC (haswell boards)
* VGA option ROMs (currently just [Dell Latitude
E6400 Nvidia variants](../../news/e6400nvidia.md))
* KBC1126 EC firmware (HP laptops)
resources/scripts/build/
========================
@ -1154,20 +999,6 @@ on all coreboot source trees.
Command: `./build release src`
NOTE: This script *scrubs* certain binary blobs from release ROMs, such as
Intel ME or MRC firmware. The release ROMs shall then exclude these blobs
within them, requiring manual insertion by the user post-release. See:
[Insert binary blobs
on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
resources/scripts/download/bios\_utilities
==========================================
This downloads and patches `bios_utilities`.
Command: `./download bios_utilities`
resources/scripts/download/coreboot
===================================
@ -1179,11 +1010,10 @@ Command: `./download coreboot`
NOTE: This version of the script also performs the full git checkout in each
coreboot tree, like so:
git submodule update --init --checkout
git submodule update --init
The coreboot project sets up its Git repository, in such a way where most blobs
are skipped if you omit `--checkout`. Since lbmk's policy is to *include*
these in its distribution, it makes sense to use `--checkout`.
NOTE: `--checkout` is excluded, because such exclusion skips a lot
of blobs during submodule update. This saves work for the project.
resources/scripts/download/flashrom
===================================
@ -1199,14 +1029,6 @@ This downloads and patches GRUB.
Command: `./download grub`
resources/scripts/download/me\_cleaner
======================================
This downloads the `me_cleaner` program, for neutering Intel ME images. You
can read more about it here:
<https://github.com/corna/me_cleaner/wiki/>
resources/scripts/download/memtest86plus
========================================
@ -1214,21 +1036,6 @@ This downloads and patches Memtest86+.
Command: `./download memtest86plus`
resources/scripts/download/mrc
==============================
Where required, this will download Intel MRC images. This is called
automatically by lbmk, on platforms that require it (currently only
Intel Haswell, where Libreboot-covered hardware is concerned, and a
libre replacement of `mrc.bin` exists on that platform, provided as
an option in Libreboot 20230319 or newer releases).
This is a fork of *coreboot's* MRC image download script, which does
not guarantee specific versions of the file nor does it check SHA1
hashes and such. It was forked for Libreboot purpose, because the
Libreboot build system *enforces* such verification during the build
process.
resources/scripts/download/seabios
==================================

143
site/docs/maintain/porting.md
View File

@ -1,143 +0,0 @@
---
title: Porting guide for new mainboards
...
NOTE: This page is largely Intel-centric, at present. It should be revised to
cover more vendors. [Patches welcome!](../../git.md)
This guide is intended for those with very little knowledge of firmware
in general and coreboot in particular.
Most boards in coreboot can be quite easily ported to libreboot.
You don't need any knowledge of a particular programming language or
technology in general to port a board.
If you want to make more major contributions to the build system,
please read the [main maintenance page.](/docs/maintain/index.html)
You will certainly need flashing equipment if you wish to follow this guide.
See the [flashing guide](/docs/install/spi.html) to find out what you'll need.
Coreboot is replacement firmware for the firmware chips on the printed
circuit board (PCB) of the machine in question.
Libreboot is a *distribution* of Coreboot.
You may be used to referring to your machine as *machine, device, laptop*
or it's name (ex: thinkpad t420).
Because we're targeting chips on the PCB, we refer to all of the above terms
synonymously as `board.`
The rest of this article will refer to the board you wish to port to
libreboot as `board.`
If `board` is not supported in coreboot then you need to start there first.
Libreboot developers will generally not port new boards to coreboot on request.
If you're not sure whether your board is in coreboot check the [coreboot table of hardware.](https://coreboot.org/status/board-status.html)
If you have determined that `board` is supported by coreboot, but is not
supported by libreboot, then follow the rest of this guide to try to port it yourself.
If you're still unable to port the board, or anything in this guide is
unclear, then contact libreboot developers.
The best way to get in touch is via [libreboot irc.](/contact.html#irc-chatroom)
Cloning lbmk
============
Before you try to get any work done, you'll need to clone the lbmk (libreboot make)
project.
To do so, you'll need to have git installed on your machine. You can then clone
the project.
git clone https://codeberg.org/libreboot/lbmk
If you want more information on building lbmk see [the build instructions.](/docs/build/index.html)
Coreboot Config
===============
Coreboot payloads (GRUB, Seabios, etc) are built separately.
You therefore only need to focus on the coreboot config(s) for `board.`
All of these configs are stored under resources/coreboot/`board`
The easiest way to start a new configuration for a given board is to copy an existing
configuration and make the necessary modifications.
For example, if one wanted to port the t420s, then the t420 config would be an excellent
starting point.
cp -r resources/coreboot/t420_12mb/ resources/coreboot/t420s_12mb
You can then easily modify the existing coreboot configs for you board via lbmk.
./modify coreboot configs t420s_12mb
This script will provide a curses interface through which you can easily modify the
necessary variables and settings.
The most important thing to change is `Mainboard.`
You must make sure that the mainboard definition in this config matches `board.`
For example, you would want to change lenovo/t420 to lenovo/t420s.
Selecting `exit` in the curses interface will prompt you to ask if you want to save your
changes, make sure to answer yes.
Note that you will generally have to go through this process twice, since there is
a corebootfb and txtmode config for each board (the script will handle this for you).
Now you can build and test the rom for `board.`
Once you have finished this, you can try flashing the resulting rom to your board as a test.
./build boot roms t420s_12mb
If you try to flash this rom and it fails, then there are two probable reasons:
1) CBFS size or ROM size is wrong
2) The blobs are incompatible
Solutions to these problems follow in the proceeding sections.
Wrong CBFS and or ROM size
==========================
Different boards have different flash chip setups.
Generally, you have one or two flash chips with a combined size of 4-16MB.
Thankfully, flashrom will let you know the size of the flash chip you're flashing.
For example: when flashing an X230, you'll see that one chip is 8192, and the other is 4096.
The total rom size should therefore be set as 12MB.
The CBFS size depends directly on the size of the flash chip selected.
Make sure that your CBFS size is not larger than the maximum for your board.
CBFS sizes are stated as hex values, here is a table showing the correct maximums
for various rom sizes.
| ROM Size | CBFS size |
|:--------:|:---------:|
| 8MB | 0x7E0000 |
| 12MB | 0xBE0000 |
| 16MB | 0xFE0000 |
Obtaining Blobs
===============
The easiest way to see if your coreboot config is valid is to extract the required
binary blobs from a backup of your vendor rom.
You'll need a unified rom for dual chip setups; see [the ivybridge haswell guide](/docs/install/ivy_has_common.html)
for instructions on creating a unified rom image.
Extracting the blobs from a vendor rom image is automated in lbmk.
Simply run `./blobutil extract [board] [/path/to/backup.bin]`
For example:
./blobutil extract t420s_12mb t420s_backup.bin
You can then modify your coreboot configs again and set the path for the
intel firmware descriptor, intel management engine, and gigabit ethernet firmware.
Getting Help
============
Once you have tried everything above, you might find that the board still doesn't
work.
If that is the case, then you should contact libreboot developers for more help.
You can ping `shmalebx9` and/or `leah` on irc or submit an issue on git.
In either case, make sure to include a detailed description of everything you
tried, and what exactly happened when you tried to flash the rom.
If your board is not supported in libreboot, then you can assume that our
developers don't have it.
You'll therefore be expected to test roms created by libreboot developers on
your own machine.
In the meantime, you can always externally flash a backup of your vendor rom
to keep your machine working while development progresses on your board.

141
site/docs/maintain/porting.uk.md
View File

@ -1,141 +0,0 @@
---
title: Керівництво перенесення
...
Це керівнитво передбачається для тих, хто має дуже низький рівень знань про прошивку
загалом та coreboot окремо.
Більшість плат в coreboot може бути доволі легко перенесена в libreboot.
Ви не потребуєте ніяких знань окремої мови програмування або
технології загалом для перенесення плати.
Якщо ви бажаєте зробити більш суттєві внески до системи побудови,
будь ласка прочитайте [головну сторінку обслуговування.](/docs/maintain/index.html)
Ви точно будете потребувати обладнання для прошивки, якщо ви бажаєте проходити
це керівництво. Дивіться [керівництво прошивки](/docs/install/spi.html) для
винайдення того, що вам буде потрібно.
Coreboot це прошивка для заміни для чіпів прошивки на друкованих
платах (PCB) машини під питанням.
Libreboot є *дистрибутивом* Coreboot.
Ви можливо звикли посилатись до вашої машини як *машина, пристрій, ноутбук*
або його ім'я (наприклад: thinkpad t420).
Тому що наша ціль чіпи на PCB, ми посилаємося до всіх вище термінів синонімічно
як `плата.`
Залишок цієї статті буде посилатись до плати, яку ви бажаєте перенести до
libreboot як `плата.`
Якщо `плата` не підтримується в coreboot, тоді ви маєте почати там спочатку.
Розробники Libreboot зазвичайно не будуть переносити нові плати в coreboot за запитом.
Якщо ви не впевнені про те, чи ваша плата в coreboot, перевірте [таблицю апаратного забезпечення coreboot.](https://coreboot.org/status/board-status.html)
Якщо ви визначили, що `плата` підтримується coreboot, але не
підтримується libreboot, тоді проходьте залишок цього керівництво для спроби
перенести її самостійно. Як ви досі не можете перенести плату, або щось в цьому
керівництві не зрозуміло, тоді зв'яжіться з розробниками libreboot.
Найкращий шлях вийти на зв'язок через [irc libreboot.](/contact.uk.html#кімната-irc)
Клонування lbmk
============
Перед тим, як ви спробуєте зробити будь-яку роботу, вам потрібно буде клонувати проект lbmk (libreboot make).
Щоб зробити це, ви будете потребувати git, встановлений на вашій машині. Ви можете потім клонувати
проект.
git clone https://codeberg.org/libreboot/lbmk
Якщо ви хочете більше інформації про побудову lbmk, дивіться [інструкції побудови.](/docs/build/index.uk.html)
Конфігурація Coreboot
===============
Корисні навантаження Coreboot (GRUB, Seabios, і так далі) будуються окремо.
Ви таким чином тільки потребуєте фокусуватись на конфігурації(ях) coreboot для `плати.`
Всі з цих конфігурацій зберігаються під resources/coreboot/`плата`
Найпростіший шлях почати нову конфігурацію для даної плати це копіювати існуючу
конфігурацію і зробити потрібні модифікації.
Наприклад, якщо хтось хотів би перенести t420s, тоді конфігурація t420 була би відмінною
початковою точкою.
cp -r resources/coreboot/t420_12mb/ resources/coreboot/t420s_12mb
Ви можете потім легко модифікувати існуючі конфігурації coreboot для вашої плати через lbmk.
./modify coreboot configs t420s_12mb
Цей сценарій надать інтерфейс curses, через який ви можете легко модифікувати
потрібні змінні та налаштування.
Найбліьш важлива річ - це змінити `Материнську плату (Mainboard).`
Ви мусити переконатись, що визначення материнської плати в цій конфігурації відповідає `платі.`
Наприклад, ви би хотіли змінити lenovo/t420 на lenovo/t420s.
Вибір `exit` в інтерфейсі curses виведе вам пропозицію зберегти ваші
зміни, переконайтесь, щоб відповідь так (yes).
Зробіть примітку, що ви загалом мусите пройти через цей процес двічі, оскільки існує
конфігурація corebootfb та txtmode для кожної плати (сценарій впорається з цим для вас).
Тепер ви можете побудувати та випробувати rom для `плати.`
Як тільки ви завершили це, ви можете спробувати прошивку отриманого rom на вашу плату в якості випробування.
./build boot roms t420s_12mb
Якщо ви пробуєте прошити цей rom і це провалюється, тоді існує дві можливих причини:
1) Розмір CBFS або розмір ROM неправильний
2) Блоби є несумісними
Рішення до цих проблем ідуть в наступних розділах.
Неправильний розмір CBFS та/або розмір ROM
==========================
Різні плати мають різні налаштування чіпів флеш-пам'яті.
Загалом, ви маєте один або два флеш-пам'яті з сумарним розміром в 4-16Мбайт.
На щастя, flashrom дасть вам знати розмір флеш-чіпа, який ви прошиваєте.
Наприклад: коли прошиваєте X230, ви побачите, що один чіп 8192, та інший 4096.
Сумарний розмір rom тоді має бути встановлено на 12Мбайт.
Розмір CBFS залежить безпосередньо від розміру флеш-чіпа, який обрано.
Переконайтесь, що ваш розмір CBFS не більше, ніж максимум для вашої плати.
Розміри CBFS зазначено в hex значеннях, ось таблиця, яка показує правильні максимуми
для різноманітних розмірів rom.
| Розмір ROM | Розмір CBFS |
|:----------:|:-----------:|
| 8Мбайт | 0x7E0000 |
| 12Мбайт | 0xBE0000 |
| 16Мбайт | 0xFE0000 |
Отримання блобів
===============
Найпростіший шлях побачити те, чи ваша конфігурація coreboot є дійсною - це
витягнути потрібні бінарні блоби з резервної копії rom вашого постачальника.
Вам буде потрібно уніфікований rom для налаштувань з подвійнь з подвійним чіпом; дивіться [керівництво ivybridge haswell](/docs/install/ivy_has_common.uk.html)
для інструкцій про створення уніфікованого образу rom.
Витягнення блобів з образа rom постачальника автоматизовано в lbmk.
Просто виконайте `./blobutil extract [плата] [/path/to/backup.bin]`
Наприклад:
./blobutil extract t420s_12mb t420s_backup.bin
Ви можете потім модифікувати ваші конфігурації coreboot знову та встановити шлях для
intel firmware descriptor, intel management engine, та прошивки gigabit ethernet.
Отримання допомоги
============
Коли ви спробували все вищенаведене, ви могли би знайти, що ця плата досі не
працює.
Якщо це той випадок, тоді вам варто зв'язатися з розробниками libreboot для більшої допомоги.
Ви можете ping `shmalebx9` та/або `leah` на irc або відкрити проблемне питання на git.
В обох випадках, переконайтеся, що включено деталізований опис всього, що ви
спробували, і що точно сталося, коли ви спробували прошити rom.
Якщо ваша плата не підтримується в libreboot, тоді ви можете передбачати, що наші
розробники не мають її.
Тоді від вас будуть очікувати випробувати образи, створені розробниками libreboot
на вашій власній машині.
До того часу, ви можете завжди прошити зовнішньо резервну копію rom вашого
постачальника, щоб тримати вашу машину в працюючому стані, поки розробка проходить
над вашою платою.

2
site/docs/maintain/testing.md
View File

@ -84,6 +84,6 @@ note: [insert any notes if relevant]
For example, a board status comment might look like this:
board: t440p_12mb
board: x200_8mb
status: fail
note: GRUB throws error 'something_is_b0rked'

5
site/docs/uboot/index.md
View File

@ -3,11 +3,6 @@ title: U-Boot payload
x-toc-enable: true
...
Libreboot has experimental support for using U-Boot as a coreboot
payload since the [20221214](../../news/libreboot20221214.md) release.
Refer to [docs/hardware/](../hardware/) for a complete list of U-Boot
targets in Libreboot.
U-Boot integration in Libreboot is currently at a proof-of-concept
stage, with most boards completely untested and most likely not working.
ROM images for them are mostly intended for further testing and

4
site/docs/uboot/uboot-archlinux.md
View File

@ -6,8 +6,6 @@ x-toc-enable: true
Background
==========
ArchLinuxARM Latest (as of May 1st 2023) boots and can be installed successfully using libreboot 20230319 on a gru_bob chromebook.
The following process should theoretically be applicable to other U-Boot devices and GNU/Linux distributions, but the focus here is specifically on ArchLinuxARM.
Sources used for this guide include the [following guide to install ArchLinuxARM on a RockPro64,](https://jforberg.se/blog/posts/2023-02-19-rockpro64/rockpro64.html)
@ -66,7 +64,7 @@ Formatting and Partitioning Your External Media
===============================================
Now it's time partition the boot disk. During testing, a microSD card was used in the microSD card slot of the gru-bob chromebook.
The libreboot configuration (in the 20230319 release) will boot the microSD card above the onboard eMMC if both are present and bootable. This is useful because it means no knowledge or use of the u-boot console is required.
The libreboot configuration will boot the microSD card above the onboard eMMC if both are present and bootable. This is useful because it means no knowledge or use of the u-boot console is required.
Since the eMMC is 16GB of storage space, it's advisable to choose an external storage disk of less than 16GB if you intend to install onto the onboard storage, or to create a root partition of less than 15.8GB.

30
site/download.md
View File

@ -11,32 +11,10 @@ Git repositories. The page on [/docs/maintain/](docs/maintain/) describes how
Libreboot is put together, and how to maintain it. If you wish to build
Libreboot from source, [read this page](docs/build/).
READ THIS BEFORE UPDATING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)**
NOTE: This warning does not apply to ROMs that you compiled yourself, using
lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted*
in release ROMs. The link above says how to re-add them. When building ROM images
yourself, from source, Libreboot's build system automatically handles it. See:
[Libreboot build instructions](docs/build/)
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
GPG signing key
---------------
**The latest release is Libreboot 20230625, under the `stable` directory.**
**The latest *censored* release is Libreboot c20230710, under the `censored` directory.**
### NEW KEY
@ -73,7 +51,7 @@ there is a Git repository that you can download from. Go here:
HTTPS mirrors {#https}
-------------
**The latest release is Libreboot 20230625, under the `stable` directory.**
**The latest *censored* release is Libreboot c20230710, under the `censored` directory.**
These mirrors are recommended, since they use TLS (https://) encryption.
@ -166,7 +144,7 @@ crontab. This page tells you how to use crontab:
HTTP mirrors {#http}
------------
**The latest release is Libreboot 20230625, under the `stable` directory.**
**The latest *censored* release is Libreboot c20230710, under the `censored` directory.**
WARNING: these mirrors are non-HTTPS which means that they are
unencrypted. Your traffic could be subject to interference by
@ -180,7 +158,7 @@ if using HTTPS.
FTP mirrors {#ftp}
-----------
**The latest release is Libreboot 20230625, under the `stable` directory.**
**The latest *censored* release is Libreboot c20230710, under the `censored` directory.**
WARNING: FTP is also unencrypted, like HTTP. The same risks are present.

32
site/download.uk.md
View File

@ -11,38 +11,16 @@ x-toc-enable: true
Libreboot складається разом, і як підтримувати його. Якщо ви бажаєте зібрати
Libreboot із джерельного кода, [прочитайте цю сторінку](docs/build/).
READ THIS BEFORE UPDATING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)**
NOTE: This warning does not apply to ROMs that you compiled yourself, using
lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted*
in release ROMs. The link above says how to re-add them. When building ROM images
yourself, from source, Libreboot's build system automatically handles it. See:
[Libreboot build instructions](docs/build/)
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
Код підпису GPG
---------------
**Останнім випуском є Libreboot 20230625, в директорії `stable`.**
**Останнім випуском є Censored-Libreboot c20230710, в директорії `censored`.**
### НОВИЙ КЛЮЧ
Повний відбиток ключа: `98CC DDF8 E560 47F4 75C0 44BD D0C6 2464 FA8B 4856`
Вищезазначений ключ для Libreboot 20230625, та наступних випусків.
Вищезазначений ключ для Censored-Libreboot 20230710, та наступних випусків.
Завантажте ключ тут: [lbkey.asc](lbkey.asc)
@ -73,7 +51,7 @@ blobs, nothing will happen.
Дзеркала HTTPS {#https}
-------------
**Останнім випуском є Libreboot 20230625, в директорії `stable`.**
**Останнім випуском є Censored-Libreboot c20230710, в директорії `censored`.**
Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
@ -166,7 +144,7 @@ crontab. Ця сторінка розповідає вам, як викорис
Дзеркала HTTP {#http}
------------
**Останнім випуском є Libreboot 20230625, під директорією `stable`.**
**Останнім випуском є Censored-Libreboot c20230710, під директорією `censored`.**
УВАГА: ці дзеркала є не-HTTPS, що означає, що вони
незашифровані. Ваш трафік може бути об'єктом втручання
@ -180,7 +158,7 @@ crontab. Ця сторінка розповідає вам, як викорис
Дзеркала FTP {#ftp}
-----------
**Останнім випуском є Libreboot 20230625, під директорією `stable`.**
**Останнім випуском є Censored-Libreboot 20230710, під директорією `censored`.**
УВАГА: FTP є також незашифрованим, подібно HTTP. Ті ж самі ризики присутні.

58
site/faq.md
View File

@ -8,22 +8,6 @@ AKA Frequently Questioned Answers
Important issues
================
What is the status of software freedom in Libreboot?
----------------------------------------------------
An article was written for Libreboot, to be maintained over time, that
accurately describes the current status Libreboot in terms of software freedom,
describing any caveats that exist for specific hardware platforms.
Please read the article, thus:
[Software and hardware freedom status for each mainboard supported by
Libreboot](freedom-status.md)
You may also find this other section of the FAQ useful:
[What level of software freedom does Libreboot give
me?](#what-level-of-software-freedom-does-libreboot-give-me)
How to compile libreboot from source
------------------------------------
@ -46,11 +30,6 @@ learn more.
How Can I Help
--------------
You do not need to be a skilled developer in order to help the project
substantially.
If you have a board supported by Coreboot, consider [porting](/docs/maintain/porting.md)
it to Libreboot.
If you have a board supported in Libreboot then please consider becoming a
tester.
Testing involves minimal effort and really helps out the project.
@ -108,10 +87,6 @@ configuration)
My KCMA-D8 or KGPE-D16 doesn't boot with the PIKE2008 module installed
-----------------------------------------------------------------------
**KGPE-D16, KCMA-D8 and KFSN4-DRE ASUS mainboards were removed on 19
November 2022. You can still use older revisions of Libreboot, and older
release versions.**
Loading the option ROM from the PIKE2008 module on either ASUS KCMA-D8
or KGPE-D16 causes the system to hang at boot. It's possible to use
this in the payload (if you use a linux kernel payload, like linuxboot),
@ -353,11 +328,6 @@ The *above* paragraph is only talking about setups where the *full* Intel ME
firmware is used, containing networking code and especially *Active Management
Technology* (AMT).
Use of the `me_cleaner` utility is believed to minimize any security risk when
using these Intel platforms, and coreboot *does* contain fully free code for
sandybridge/ivybridge platforms. Freedom-wise, these are similar to libreboot
compatible ThinkPads, and they are quite nice machines.
More information about the Management Engine can be found on various Web
sites, including [me.bios.io](http://me.bios.io/Main_Page),
[unhuffme](http://io.netgarage.org/me/), [coreboot
@ -367,10 +337,6 @@ The book ***[Platform Embedded Security Technology
Revealed](https://www.apress.com/9781430265719)*** describes in great
detail the ME's hardware architecture and firmware application modules.
If you're stuck with the ME (non-libreboot system), you might find this
interesting:
<http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html>
### Firmware Support Package (FSP) {#fsp}
On all recent Intel systems, coreboot support has revolved around
@ -397,9 +363,6 @@ set architecture. Your CPU will already contain them, but it also supplies a
way to update the microcode at boot time, fixing bugs and greatly enhancing
the general reliability of your system.
Microcode is already discussed in great detail, on the [binary blobs
policy](news/policy.md).
This interesting video talks about how a group of people reverse engineered
the microcode on AMD processors:
@ -525,9 +488,6 @@ practically the same, though it was found with much later hardware in
AMD that you could run without microcode updates. It's unknown whether
the updates are needed on all AMD boards (depends on CPU).
The libreboot project does not consider microcode updates a problem, and it
enables them by default on all supported hardware.
### AMD is uncooperative
AMD seemed like it was on the right track in 2011 when it started
@ -558,11 +518,6 @@ security.
Hi, I have &lt;insert random system here&gt;, is it supported?
--------------------------------------------------------------------------------------------------------
If it's supported by coreboot, you can add it immediately.
Read the [porting guide](/docs/maintain/porting.html) for how to port for a new board.
If you are able to generate a working rom for your system, please read
[lbmk maintenance manual](docs/maintain/) for how to add it to libreboot.
If coreboot lacks support for your hardware, you must add support for it.
Please consult the coreboot project for guidance.
@ -766,10 +721,6 @@ This will provide information about the battery.
What other firmware exists outside of libreboot?
==================================================
You can also read information about these in the [libreboot binary blob
reduction policy](news/policy.md), where it goes into more detail about some
of them.
### External GPUs
The Video BIOS is present on most video cards. For integrated graphics,
@ -931,9 +882,6 @@ Microcode configures logic gate arrays in a microprocessor, to implement the
instruction set architecture. Special *decoders* in the microprocessor will
configure the circuitry, based on that microcode.
The [libreboot blob reduction policy](news/policy.md) goes into great detail
about microcode.
### Sound card
Sound hardware (integrated or discrete) typically has firmware on it
@ -1016,12 +964,6 @@ Unknown. Perhaps so, but it's impossible to say without further testing.
What level of software freedom does libreboot give me?
===================================================
Please read the [libreboot binary blob minimalisation policy](news/policy.md).
Please also read:
[Software and hardware freedom status for each mainboard supported by
Libreboot](software-freedom.md)
The libreboot firmware provides host hardware initialisation inside ROM files,
that can be written to NOR flash, but on many systems there exist
a lot more small computers on the mainboard running blob firmware.

50
site/faq.uk.md
View File

@ -8,22 +8,6 @@ x-toc-enable: true
Важливі питання
================
Який статус свободи програмного забезпечення в Libreboot?
----------------------------------------------------
Стаття була написана для Libreboot, для підтримки протягом часу, яка
ретельно описує поточний статус Libreboot с точки зору свободи програмного забезпечення,
пояснюючи будь-які підводні камені, які існують для конкретних платформ апаратного забезпечення.
Будь-ласка, прочитайте статтю щодо цього:
[Статус свободи програмного та апаратного забезпечення для кожної плати, яка підтримується
Libreboot](freedom-status.md)
Ви також можете знайти цю іншу секцію сторінки поширених запитань корисною:
[Який рівень свободи програмного забезпечення Libreboot дає
мені?](#який-рівень-програмної-свободи-дає-мені-libreboot)
Як скомпілювати libreboot з джерельного коду
------------------------------------
@ -94,10 +78,6 @@ Ethernet не працює на моєму X200/T400/X60/T60, коли я йог
Мій KCMA-D8 або KGPE-D16 не завантажується з встановленим модулем PIKE2008
-----------------------------------------------------------------------
**Материнські плати KGPE-D16, KCMA-D8 та KFSN4-DRE ASUS було видалено 19
листопада 2022. Ви все ще можете використовувати старіші версії Libreboot, і випуски
старіших версій.**
Завантаження Option ROM з модуля PIKE2008 на ASUS KCMA-D8
або KGPE-D16 викликає зависання системи під час завантаження. Можна використовувати
це в корисному навантаженні (якщо ви використовуєте корисне навантаження ядра linux, таке як linuxboot),
@ -339,11 +319,6 @@ Intel.**
що містить мережевий код і в особливості *Active Management
Technology* (AMT).
Вважається, що використання утиліти `me_cleaner` мінімізує будь-який ризик безпеки,
від використання цих платформ Intel, і coreboot *містить* повністю вільний код для платформ
sandybridge/ivybridge. З точки зору свободи, вони схожі до libreboot-
сумісних ThinkPad, і це досить гарні машини.
Більше інформації про Management Engine може бути знайдено на різноманітних веб-
сайтах, включаючи [me.bios.io](http://me.bios.io/Main_Page),
[unhuffme](http://io.netgarage.org/me/), [coreboot
@ -353,10 +328,6 @@ wiki](http://www.coreboot.org/Intel_Management_Engine), та
Revealed (Розкрито вбудовану технологію безпеки платформи)](https://www.apress.com/9781430265719)*** чудово описує в
значних подробицях архітектуру апаратного забезпечення ME та прикладні модулі мікропрограми.
Якщо ви застрягли на ME (система не libreboot), ви можете знайти це
цікавим:
<http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html>
### Firmware Support Package (FSP) {#fsp}
У всіх останніх системах Intel, підтримка coreboot обертається навколо
@ -383,9 +354,6 @@ Revealed (Розкрито вбудовану технологію безпек
мікрокоду під час завантаження, виправляючи помилки та значно підвищуючи
загальну надійність вашої системи.
Мікрокод уже обговорювався дуже детально, в [політиці бінарних
блобів](news/policy.md).
У цьому цікавому відео розповідається про те, як група людей
провела зворотню розробку мікрокода на процесорах AMD:
@ -511,10 +479,6 @@ Management Engine), PSP від AMD також може діяти як тира
AMD можна працювати без оновлень мікрокоду. Невідомо, чи потрібні оновлення на всіх
платах AMD (залежить від ЦП).
Проект libreboot не розцінює оновлення мікрокоду проблемою, і він
вмикає їх за замовчуванням на всьому апаратному забезпеченні,
яке підтримується.
### AMD не співпрацює
Здавалося, що AMD була на правильному шляху в 2011 році, коли вони почала
@ -545,11 +509,6 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
Привіт, у мене &lt;вставте сюди випадкову систему&gt;, чи підтримується вона?
--------------------------------------------------------------------------------------------------------
Якщо вона підтримується coreboot, ви можете додати її негайно.
Прочитайте [посібник з перенесення](/docs/maintain/porting.html) про перенесення нової плати.
Якщо ви здатні згенерувати працюючу ROM для своєї системи, будь-ласка,
прочитайте [керівництво по експлуатації lbmk](docs/maintain/) про додавання її до libreboot.
Якщо в coreboot бракує підтримки для вашого апаратного забезпечення, ви мусите додати підтримку для нього.
Будь-ласка, проконсультуйтесь з проектом coreboot для наставництва.
@ -753,10 +712,6 @@ tlp-stat -b
Яке ще мікропрограмне забезпечення існує за межами libreboot?
==================================================
Ви можете також прочитати інформацію про цих в [політиці мінімізації бінарних блобів
libreboot](news/policy.md), де вона розповідає в більших подробицях про деяких із
них.
### Зовнішні графічні карти
Відео BIOS наявний на більшості графічних карт. Для інтегрованої графіки
@ -918,9 +873,6 @@ SATA через USB, і проект Libreboot здатний завантажу
архітектури набору інструкцій. Спеціальні *декодери* в мікропроцесорі налаштують
схему на основі цього мікрокоду.
[Політика зменшення блобів libreboot](news/policy.md) докладно описує
мікрокод.
### Звукова карта
Звукове обладнання (інтегроване чи дискретне) зазвичай має вбудоване програмне забезпечення
@ -1003,8 +955,6 @@ OpenBSD. Інші системи не перевірені, але мають п
Який рівень програмної свободи дає мені libreboot?
===================================================
Будь-ласка, прочитайте [політику мінімізації бінарних блобів libreboot](news/policy.md).
Прошивка libreboot надає ініціалізацію апаратного забезпечення хоста всередині файлів ROM,
що може бути записано на флеш NOR, але на багатьох системах існує
набагато більше маленьких комп'ютерів на материнській платі, виконуючих двійкові прошивки.

1
site/footer.de.include
View File

@ -1,7 +1,6 @@
-------------------------------------------------------------------------------
* [Binäre Blob Richtlinie](/news/policy.md)
* [Diese Seite bearbeiten](/git.de.md)
* [Wer entwickelt Libreboot?](/who.de.md)
* [Lizenz](/license.md)

1
site/footer.include
View File

@ -1,7 +1,6 @@
-------------------------------------------------------------------------------
* [Binary blob policy](/news/policy.md)
* [Edit this page](/git.md)
* [Who develops Libreboot?](/who.md)
* [License](/license.md)

1
site/footer.uk.include
View File

@ -1,7 +1,6 @@
-------------------------------------------------------------------------------
* [Політика бінарних блобів](/news/policy.md)
* [Редагувати цю сторінку](/git.md)
* [Хто розробляє Libreboot?](/who.uk.md)
* [Ліцензія](/license.md)

1
site/footer.zh-cn.include
View File

@ -1,7 +1,6 @@
-------------------------------------------------------------------------------
* [二进制 blob 政策](/news/policy.md)
* [编辑本页面](/git.md)
* [谁在开发 Libreboot?](/who.md)
* [许可证](/license.md)

356
site/freedom-status.md
View File

@ -1,356 +0,0 @@
---
title: Software and hardware freedom status for each mainboard supported by Libreboot
x-toc-enable: true
...
Introduction
============
This page documents how Libreboot's [binary blob reduction
policy](news/policy.md), adopted in November 2022, is implemented in practise,
especially that line which says: *"if a blob can be avoided, it must be
avoided."*
Libreboot uses [coreboot](https://coreboot.org/) for hardware initialisation.
While coreboot is nominally [*free* or *open source*
software](https://writefreesoftware.org/), on *some* (not
all) platforms, coreboot *requires* certain
[blobs](https://en.wikipedia.org/wiki/Binary_blob)
for things like raminit. *All* boards currently supported by Libreboot can be
initialised entirely with *free*, *libre* or *open source* code from *coreboot*
itself, because Libreboot currently only focuses on such mainboards. Libreboot's
goal is to eventually support *all* mainboards from coreboot.
A more *pragmatic* [binary blobs reduction policy](news/policy.md) was adopted
by Libreboot during November 2022, as part of an ongoing campaign to support
more hardware (from coreboot) within Libreboot, so as to provide *many more*
people with coreboot which, regardless of blob status, *does* provide increased
[software freedom](https://writefreesoftware.org/) compared to fully proprietary
boot firmware which is what most
people would otherwise use; Libreboot's modern policy is thus pragmatic, further
advancing the cause of *software freedom*.
Libreboot's *previous* policy was to *ban all binary blobs*. This actively
*harmed* the Free Software movement, by reducing the number of people who can
realistically use coreboot because, to this day, nothing quite like Libreboot
yet exists. Libreboot's main purpose is to make coreboot *as easy to use as
possible* for normal, non-technical users who like the idea of coreboot but
who are otherwise not competent to configure it from scratch. Such harm
was *corrected*, in November 2022.
Coreboot architecture
---------------------
For context about certain topics, please read:
<https://doc.coreboot.org/getting_started/architecture.html>
100% libre init in coreboot
===========================
The reason this distinction matters (referring specifically to coreboot's side
of the initialisation) will become clearer, in the following sections:
A universal exemption is made in Libreboot, permitting (read: requiring, per
project policy) the inclusion of CPU microcode updates if available. You can
read more about that and the reasons *why* by reading the following article:
[CPU microcode updates
are **OK**](news/policy.md#more-detailed-insight-about-microcode)
[Releases after Libreboot 20230423 will provide separate ROMs with microcode
excluded, alongside default ones with microcode included.](news/microcode.md)
Intel platforms
===============
Descriptor vs descriptorless setup
----------------------------------
Libreboot supports several mainboards using Intel platforms. Of these, there
are essentially two class of machine (for the purposes of this article):
* Descriptorless configuration
* Descriptor-based configuration
What does *descriptor* mean? Well, traditionally, the main flash IC (containing
the boot firmware, commonly referred to as *the BIOS*) on Intel machines,
contained only *x86* executable code, responsible for initialising all of
the hardware, such as the CPU, memory controller and peripherals. This is
what we will refer to as the *descriptorless* setup; in such configurations,
the Intel ME firmware is absent by default.
In a *descriptor* configuration, the flash is divided into regions such as:
* Intel flash descriptor: always the first 4KiB of the flash. Binary-encoded
configuration data for the machine, and the regions (such as this, or
others below) is defined in here. In some ways, you might think of this as
analagous to the *Master Boot Record* on a hard drive.
* Intel GbE NVM (gigabit ethernet non-volatile memory): binary-encoded
configuration data, for the onboard Intel gigabit ethernet device, if one is
present. It contains lots of settings like MAC address, what speed the NIC
should run at, PCI IDs, *LED blinking speed* and more.
If a non-Intel NIC is used, this region of the flash will not be present.
* ME (Intel Management Engine): a *nasty* security liability in its default
state, the ME provides many features such as remote management, with full
networking, The ME is a dedicated coprocessor separate from the main CPU, and
the initialisation firmware plus operating system for it is loaded from
this dedicated region in the main boot flash. More info is available [in the
FAQ](faq.md#intelme) - where ME firmware is otherwise present, Libreboot
either removes it or (with the `me_cleaner` program) reconfigures it in such
a way where it is disabled during machine initialisation.
* Platform region: non-program data, usually just a bunch of strings put there
by the hardware vendor.
* BIOS region: this contains the main boot firmware, responsible for
initialising the CPU, memory controller and peripherals, putting the
machine into a state where it can run programs (most likely a bootloader,
then an operating system). The coreboot code (provided by Libreboot) goes in
here.
*Basically*, you can think of such "regions" as analogous to *partitions* on
a hard drive. What's important is that the flash IC is *divided* into such
regions, where each region is intended for a specific purpose.
The contents of the *descriptor* and *GbE* regions are described by Intel
datasheets, but those datasheets often contain *reserved* sections where
parts are left undocumented. Reverse engineering efforts over the years have
documented some of these blank spots.
Libreboot does *not* distribute Intel ME images
-----------------------------------------------
Libreboot does *not* distribute the Intel ME firmware in any way, whether in
the Git repository or in releases. Where it is needed, Libreboot provides
scripts that automatically fetch and install it, in a *neutered* (disabled)
state by running the `me_cleaner` program. This is completely automated.
Please read:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
The *BringUp* code of Intel ME is all that remains, in Libreboot configurations.
ME BringUp (BUP) is analogous to coreboot, providing initialisation for the
ME itself; by that same analogy, the way Libreboot configures it is similar to
running *coreboot* without a payload. The ME is initialised, to a state where
it can run code, but then it *doesn't actually run code*. It is thus *disabled*.
In other words, a *neutered* Intel ME setup is completely benign, both from a
software freedom and security perspective. It becomes a useless, unused
processor, that most people in the real world will never want to use anyway.
With this perspective, we see that Intel ME is now entirely inconsequential
to the average user.
*Released* Libreboot ROM images, provided pre-compiled, do *not* include the
ME firmware at all; they are scrubbed, by automated release scripts when they're
preparing a release. If you're building from source, the Libreboot build system
will automatically download it (from the vendor), neuter it and then insert it;
on release ROMs, the same scripts used by the build systems can (must) be run
manually, accomplishing the same result after the fact. Please read:
[docs/install/ivy_has_common.md](docs/install/ivy_has_common.md)
The ME firmware is *required* on almost all Intel platforms, or the machine
will turn *off* after 30 minutes (or it will not boot, if the ME also controls
whether the CPU comes out of reset).
More about Intel ME removal/disabling
----------------------------------
*Libreboot* provides a way to fully remove the ME firmware, while retaining
full use of the machine, on GM45 platforms with ICH9M southbridge. These are
laptops: ThinkPad X200/T400/T500/W500 and so on of that generation. See:
[docs/install/ich9utils.md](docs/install/ich9utils.md)
The `ich9utils` software is provided by Libreboot. The `ich9gen` utility was
specifically written by Leah Rowe, in 2014 and improved incrementally since.
On newer platforms as alluded to above, `me_cleaner` is used instead.
Notes about specific types of blobs
===================================
VGA option ROMs
---------------
*Native* video initialisation is supported and *enabled*, for all supported
Intel platforms that have it. The source code is provided by coreboot, under
free license.
In some cases, a laptop may have a graphics chip that is unsupported by
coreboot. In this situation, a binary blob called a *VGA Option ROM* must be
used. Libreboot has *experimental* support for Nvidia GPU models of the Dell
Latitude E6400, in an experimental branch where the build system automatically
downloads the VGA ROM for it. This is currently *not* present in releases, or
in the stable branch of `lbmk`.
In other instances, a machine may have *two* graphics devices, where one has
native (free/libre) initialisation provided by coreboot. In these situations,
it is possible to insert a VGA ROM for the other one; Libreboot currently lacks
documentation for this, but it has been tested. Example: Dual Intel/Nvidia
graphics on some ivybridge or haswell thinkpads.
For *add-on* GPUs, SeaBIOS (payload) can typically scan a VGA ROM present on
the card and execute it. This has been tested on certain desktop mainboards
that Libreboot supports, and works just fine; Libreboot does not need to handle
these blobs at all.
Libreboot's default is *always* freedom, when feasible in practise. Users who
wish to have use of these additional GPUs, on such hardware, must take stock
of the following paragraph in Libreboot policy:
*"The principles above should apply to default configurations. However,
libreboot is to be configurable, allowing the user to do whatever they like."* -
configurable, it most certainly is! See: [docs/maintain/](docs/maintain/)
Memory controller initialisation
--------------------------------
Libreboot has *fully libre* initialisation available for all Intel memory
controllers on supported platforms. This *includes* Haswell (ThinkPad T440p
and W541) as of Libreboot 20230319 or higher.
AMD platforms
=============
Libreboot currently *lacks* support for AMD platforms, but information about
them will be written when this fact changes.
ARM platforms (chromebooks)
=============
Mostly blobless, except for the requirement on `daisy` and `peach` mainboards
to include BL1 bootloader blobs. These are:
* HP Chromebook 11 G1 (daisy-spring) **(board removed from Libreboot, due to
issues (will be re-added at a later date)**
* Samsung Chromebook XE303 (daisy-snow) **(ditto)**
* Samsung Chromebook 2 13” (peach-pi) **(ditto)**
* Samsung Chromebook 2 11” (peach-pit) **(ditto)**
* nyan-* chromebooks also temporarily removed, but are blobless in Libreboot
List of blobs needed, specifically for each board
=================================================
This article has thoroughly explained, in a detailed overview, the precise
nature as to *what* binary blobs are accomodated for in Libreboot. Again,
fully libre init from coreboot is available *on all currently supported boards*.
*From coreboot* is the critical aspect of this, but Libreboot's full scope is
the main flash IC which (in some cases) contains software outside of coreboot.
Here is a list, *for each* board, of those blobs:
Intel/x86
---------
### Intel ME:
Neutered ME required on these targets: `t420_8mb`, `t420s_8mb`, `t430_12mb`,
`t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`,
`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
`x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff`, `hp2560p_8mb`,
`hp2570p_16mb`, `hp8300usdt_16mb` and `hp9470m_16mb`.
As stated, Libreboot provides this in a state where the ME is no longer a
threat to security. It initialises itself, but then does nothing, so it's
disabled. This is done using `me_cleaner`. See:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
### KBC1126 EC firmware (HP laptops):
EC firmware is inserted into main boot flash, rather than being on a separate
IC. This is *better* because libre replacements would be more easy to install in
the future, and reverse engineering is made much easier by it. Libreboot's
build system handles such firmware in `blobutil`, automatically downloading
it during the build process. Libreboot 20230423 onwards does scrub EC firmware
and provide functionality in `blobutil` insert, to insert them with `cbfstool`
at the correct offset as defined by coreboot config for each board.
### CPU microcode:
*Microcode* updates for CPU provided on *all* x86 platforms, by default. Not
technically required, but highly recommended. To remove, do:
cbfstool filename.rom remove -n cpu_microcode_blob.bin
[Releases after Libreboot 20230423 will provide separate ROMs with microcode
excluded, alongside default ones with microcode included.](news/microcode.md)
Removal of microcode updates will affect system stability in a negative way,
introducing non-standard broken behaviour and it may result in the machine
being unable to boot properly. In other cases, doing so may break features such
as S3 suspend/resume.
CPU microcode blobs included by default, on all x86 boards. While not needed
in most cases, their use is highly recommended. For reasons why, see:
[news/policy.md#more-detailed-insight-about-microcode](news/policy.md#more-detailed-insight-about-microcode)
### Intel Flash Descriptor (IFD):
Intel Flash Descriptors are provided as blobs on some boards, but these are
not *software* blobs. They are configurations provided in a binary format,
fully readable by libre software. For example:
* Libreboot's `ich9gen` program generates ICH9M flash descriptors from scratch.
* Coreboot's `ifdtool` program has extensive features for manipulating Intel
flash descriptors.
* Corebot's `bincfg` program generates any sort of binary from a `.spec` file
which can describe any binary format in a human readable format. It contains
several flash descriptors for several platforms, but Libreboot does not use
these.
Intel GbE NVM config (configuration data, binary-encoded, for gigabit NIC):
* Libreboot's `ich9gen` program *also* generates GbE NVM images specifically
for Intel NICs used in GM45 thinkpads.
* Libreboot's `nvmutil` program can manipulate GbE NVM images
ARM/chromebooks
---------------
### BL1 bootloader (peach/daisy):
BL1 bootloader needed on: `daisy_snow`, `daisy_spring` and `peach_pit`.
These boards are *currently* not present. They were removed from Libreboot,
because the build system does not yet auto-insert the BL1 blobs. The boards
are otherwise believed to work, using Alper's port of U-Boot in Libreboot.
Conclusion
==========
From the above, you can see that Libreboot really *does* implement a *binary
blobs reduction policy*, with the emphasis on *reduction* being most critical.
It can be asserted that Libreboot does in fact provide a reasonable level of
*software freedom*, on all boards.
Libreboot *could* add a lot more blobs for various platforms, to enable various
extra features, that it instead avoids adding, precisely because the *purpose*
of the Libreboot project is to promote *libre* software and *minimise* the
power that proprietary software developers have over users.
I hope this article provided food for thought.
An aside: hardware freedom
--------------------------
None of the currently supported Libreboot machines have libre *hardware*, in
the sense that ICs do not come with publicly available *verilog* files and the
like. You could not manufacture your own replacements of these machines.
Some schematics and boardview files describing the circuit boards of each
machine are available online, through various channels. You have to search for
them yourself; one day, the Right To Repair movement will hopefully bring
about universal access to such documents by the public.
Further reading
===============
This article has described code what goes in the *main boot flash*, but any
computer you buy will have *tons* of firmware elsewhere in the system. Some
insights are available in the Libreboot FAQ. See:
* [faq.md#what-level-of-software-freedom-does-libreboot-give-me](faq.md#what-level-of-software-freedom-does-libreboot-give-me)
* [faq.md#what-other-firmware-exists-outside-of-libreboot](faq.md#what-other-firmware-exists-outside-of-libreboot)
Of these, the most critical are HDD/SSD firmware and EC firmware. The problems
described in those two links apply to many different computers, including
Libreboot ones, and virtually every other computer in the world.

434
site/freedom-status.uk.md
View File

@ -1,434 +0,0 @@
---
title: Статус свободи програмного та апаратного забезпечення для кожної плати, яка підтримується Libreboot
x-toc-enable: true
...
Вступ
============
Коротка версія історії: *всі* плати, які наразі підтримуються Libreboot
можна ініціалізувати в coreboot з *вільним*, *поважаючим свободу* або *з відкритим джерелом* кодом, який
користувач може вивчати глибинно та адаптувати для своїх потреб, але існують
деякі застереження та підводні камні, які користувач повинен знати, для деяких машин.
Як багато користувачів може знати, coreboot (який Libreboot використовує для апаратної
ініціалізації) номінально *Вільне від слова Воля*, *вільне* або *з відкритим джерелом*
програмне забезпечення; хоча, coreboot намагається надати вільний код для ініціалізації кожної
машини. Розробники coreboot працюють дуже потужно для зворотньої розробки якомога більшої
кількості можливого функціоналу, для надання джерельного кода під вільною ліцензією.
Цих людей варто відзначити, оскільки Libreboot не міг би існувати без таких
зусиль з їх боку.
На *деяких* платах, які coreboot підтримує, деякі двійкові блоби вимагаються.
Це може бути для речей подібних ініціалізації кадрового буфера відео, налаштування
контролерів пам'яті і так далі. Двійковий блоб це, в цьому контексті, будь-яке програмне забезпечення,
яке тільки іде в формі виконуваного двійкового коду *з джерельним кодом недоступним*. Це
робить складнішим (але не неможливим) вивчення того, як програми працюють, і ці
блоби часто ідуть з обмеженням або на їх використання та/або розповсюдження.
Мета цього документа - чітко описати наявність (або відсутність)
двійкових блобів на кожній даній апаратній платформі або, у межах кожної платформи,
на певних варіантах материнської плати. На веб-сайті Libreboot подібна інформація була
відсутня або викладена погано, тому було вирішено написати офіційну
документацію. Причиною такої відсутності було те, що Libreboot раніше
давав підтримку *лише* для тих плат, які *не* потребують двійкових блобів
у головній флеш-схемі для завантажувального мікропрограмного забезпечення, тому така документація не була потрібна.
Більш *прагматична* політика була опублікована протягом листопада 2022 року, з поглядом
на допомогу настільки багатьом людям, наскільки можливо, у встановленні coreboot, навіть на менш-ніж-ідеальному
апаратному забезпеченні (продовжуючи також підтримувати більше дружнє до свободи апаратне забезпечення).
Libreboot досі має суворі стандарти про те, *які* точно блоби дозволені,
які ви можете прочитати в наступному документі, так:
[Політика зменшення бінарних блобів](news/policy.uk.md)
В цій статті ви вивчите всі шляхи (на практиці), якими Libreboot
реалізовує цю *політику зменшення блобів*, особливо в тому рядку в ній, який каже,
цитата, "якщо блоб можна уникнути, його необхідно уникнути".
Чому це має значення?
---------------------
*Практичною метою* проекта Libreboot є підтримка якомога більшої кількості апаратного забезпечення
підтримки coreboot, повністю протестованого з попередньо зібраними образами ROM
та легкими інструкціями прошивки, направленими на нетехнічних користувачів, щоб привнести
якомога більше користувачів в спільноту coreboot. З більшою кількістю користувачів, набагато
більше людей відкриються coreboot і це неминуче призведе до більшої кількості
людей, які розробляють coreboot, що є критичним проектом руху за вільне
програмне забезпечення. З більшою кількістю розробників, більше *користувачів* матимуть змогу досягти рівень
свободи або *суверенітету* в їх обчисленнях та, тому, цикл має продовжитись.
Ця мета існує, тому що *ідеологічною метою* Libreboot є поширення
свободи програмного забезпечення будь-якими необхідними засобами, настільки багатьом людям, наскільки можливо.
Універсальний доступ до джерельного кода, здатність вивчати та змінювати код або
перерозповсюджувати його, та виконувати його нескінченно з будь-якою метою надзвичайно важлива.
Таким свободам варто бути *за замовчуванням* для всього програмного забезпечення. Це робить coreboot
надзвичайно корисним, навіть у випадках, де двійковий блоб є необхідним для певної
функціональності. Свободі варто бути *за замовчуванням* для всього програмного забезпечення, і це є
метою *Libreboot* допомогти продемонструвати це реальністю.
*Політика* проекта Libreboot, в межах цієї мети, надання такої
підтримки апаратного забезпечення з якомога *меншою* можливою кількостю двійкових блобів, в ідеалі *відсутньою*, як
у випадку з багатьма конфігураціями, які підтримує Libreboot. Libreboot *спробує*
підтримувати будь-яку дану одиницю апаратного забезпечення, навіть у випадках, де *повна*
свобода програмного забезпечення не є можливою; наприклад, якщо coreboot вимагає блоб для
raminit на даній платі, блоб було би надано Libreboot.
*Ви можете прочитати політику зменшення/мінімалізації блобів Libreboot в більших подробицях.
Будь ласка, прочитайте документ, названий: [Політика зменшення бінарних
блобів](news/policy.uk.md).*
Архітектура Coreboot
---------------------
Хоча не *суворо* необхідно для не-розробників, Ви можете знайти корисним
набуття розуміння на високому рівні того, *як* працює coreboot, для набуття
деякого контексту про деякі із тем, які обговорено в цій статті. Дивіться:
<https://doc.coreboot.org/getting_started/architecture.html>
100% вільна ініціалізація coreboot
===========================
*Всі* плати, які наразі підтримуються Libreboot можуть мати 100%
вільну ініціалізацію *зі сторони coreboot*. В цьому контексті, це має на увазі
будь-яку ініціалізацію, яка виконується головним процесором, для підняття машини для
виконання кода.
Завантажувальна прошивка не є *єдиним* програмним забезпеченням, присутнім в будь-якій машині, та існують
деякі контексти, які потрібно зрозуміти, щоб побачити більшу картину.
Причина, чому ця різниця має значення (посилаючись конкретно на сторону
ініціалізації coreboot), стане зрозуміліше, в наступних секціях:
Універсальний захист зроблено в Libreboot, дозволяючи (читайте: вимагаючи, згідно з
політикою проекту) включення оновлень мікрокоду ЦП, якщо доступно. Ви можете
прочитати більше про це і причини *чому*, прочитавши наступну статтю:
[Оновлення мікрокоду ЦП
є **нормальним**](news/policy.uk.md#більш-детальна-інформація-про-мікрокод)
[Releases after Libreboot 20230423 will provide separate ROMs with microcode
excluded, alongside default ones with microcode included.](news/microcode.md)
Платформи Intel
===============
Дескрипторне проти бездескрипторного налаштування
----------------------------------
Libreboot підтримує декілька материнських плат, які використовують платформи Intel. Серед них існує
суттєво два класи машин (для цілей цієї статті):
* Бездескрипторне налаштування
* Дескрипторне налаштування
Що означає *дескриптор*? Гаразд, традиційно, основна флеш інтегральна мікросхема (яка містить
завантажувальну прошивку, зазвичай на яку посилаються як на *BIOS*) на машинах Intel,
містила тільки виконуваний код *x86*, який відповідає за ініціалізацію всього
апаратного забезпечення, такого як ЦП, контролер пам'яті та периферія. Це те, що
ми будемо називати *бездескрипторне* налаштування; в таких конфігураціях,
прошивка Intel ME є відсутньою за замовчуванням.
В *дескрипторному* налаштуванні, флеш поділений на регіони, такі як:
* Intel flash descriptor: завжди перші 4Кбайт флеш. Закодовані двійково
конфігураційні дані для машини, та регіони (такі як цей, або
інші нижче) оголошено тут. Деяким чином, ви можете думати про це
аналогічно до *Master Boot Record* на жорсткому диску.
* Intel GbE NVM (неволатильна пам'ять gigabit ethernet): закодовані двійково
конфігураційні дані, для пристроя Intel gigabit ethernet на платі, якщо такий
є присутнім. Вона містить багато налаштувань, таких як MAC-адреса, на якій швидкості мережева карта
має працювати, PCI ID, *швидкість мерехтіння LED* та більше.
Якщо використовується мережева карта не Intel, цей флеш-регіон не буде присутнім.
* ME (Intel Management Engine): *брудний* недолік безпеки в своєму стані
за замовчуванням, ME надає багато функцій, таких як віддалене керування, з повним
мережевим функціоналом, ME є виділеним сопроцесором, окремим від головного ЦП, та
прошивка ініціалізації плюс операційна система для нього завантажується з
цього виділеного регіона в основній завантажувальній флеш-пам'яті. Більше інформації доступно [в
частих запитаннях](faq.uk.md#intelme) - там де в іншому випадку прошивка ME є присутньою, Libreboot
або видаляє її, або (за допомогою програми `me_cleaner`) переналаштовує її таким
чином, що його вимкнено в процесі ініціалізації машини.
* Регіон платформи: непрограмні дані, зазвичай просто купа рядків розміщена тут
продавцем апаратного забезпечення.
* Регіон BIOS: цей містить основну завантажувальну прошивку, відповідальну за
ініціалізацію ЦП, контролера пам'яті та периферії, призводячи
машину в стан, де вона може виконувати програми (скоріше за все, що завантажувач,
а потім операційну систему). Код coreboot (наданий Libreboot) іде
тут.
*По суті*, ви можете думати про такі "регіони" за аналогією до *розділів* на
жорсткому диску. Що важливо так це те, що інтегральна мікросхема флеш-пам'яті *розділена* на такі
регіони, де кожний регіон призначено для конкретної мети.
На деяких новіших дескрипторних платформах Intel, існує більше регіонів, ніж
ці. В деяких випадках, *[вбудований
контролер](faq.uk.md#прошивка-ec-вбудований-контролер)* (EC) може також
бути в своєму власному регіоні на завантажувальній флеш-пам'яті; щонайменш, наразі, це не є
актуальним ні на якому апаратному забезпеченні, яке підтримує Libreboot (натомість, це зберігається
на окремій інтегральній мікросхемі).
Вміст регіонів *дескриптора* та *GbE* описано в даташітах Intel,
але ті даташіти часто містять *зарезервовані* секції, де
частини залишені незадокументованими. Зусилля зворотної розробки протягом років
задокументували деякі з цих прогалин.
Libreboot *не* розповсюджує образи Intel ME
-----------------------------------------------
ME містить багато модулів в собі, і один з цих модулів це
код BringUp. Цей код BringUp є *власною* прошивкою ініціалізації ME,
подібною coreboot. Згідно з тією самою аналогією, інші модулі
Intel ME (такі як: ядро ME) є подібними (концептуально) до
*корисного навантаження coreboot*.
Так, налаштування *нейтралізованого ME* є, на сопроцесорі intel ME, аналогічним до
виконання coreboot без корисного навантаження. В цьому стані, ME ініціалізує себе
готовим до виконання коду, але потім *насправді не виконує код*. Він таким чином не шкідливий,
обидва з точки зору безпеки- та точки зору свободи. Іншими словами, ME
є *вимкненим*.
Libreboot *не* розповсюджує прошивку Intel ME жодним чином, ні в сховищі
Git, ні в випусках. Де необхідно, Libreboot надає
сценарії, які автоматично отримують та встановлюють її, в *нейтралізованому* стані, за
допомогою виконання програми `me_cleaner`, про яку ви можете почитати тут:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
Це повністю автоматизовано. Якщо ви будуєте образи ROM з `lbmk.git`,
автоматизованої системи побудови libreboot, прошивка ME буде завантажена,
нейтралізована за допомогою `me_cleaner` та вставлена в фінальний образ ROM автоматично.
*Випущені* образи ROM, надані попередньо зібраними, упускають прошивку Intel ME. На
платформах, які вимагають її, *ті самі* сценарії, які вставляють її в процесі
побудови, можуть *також* виконувати після-побудову, перевставляючи Intel ME в завантажувальну ROM. Це в
зв'язку з проблемними питаннями ліцензіювання, оточуючими розповсюдження образів Intel ME.
Система побудови Libreboot отримує її напряму від продавця для даної
машини або набору машин (в якості приклада, Lenovo надає образи для декількох
машин ThinkPad). Це гарантує, що кожен користувач отримує точно таку саму
конфігурацію (іншою альтернативою є витаскування прошивки Intel ME з
оригінального образа продавця, в регіоні ME інтегральної схеми флеш-пам'яті).
Ви можете дізнатись про це більше на наступній сторінці:
[docs/install/ivy_has_common.uk.md](docs/install/ivy_has_common.uk.md)
Прошивка ME є *обов'язковою* на майже всіх платформах Intel, або машина
*вимкнеться* після 30 хвилин. В нейтралізованому налаштуванні, код BringUp
Intel ME вимкне той час скидання в 30 хвилин, дозволяючи вам використовувати ваш
комп'ютер нормально, навіть незважаючи на те, що ME *не* виконує нічого після цього.
Нейтралізований ME дійсно є вимкненим
------------------------------
Зважайте на це: якщо ME тільки робить свій власний BringUp, але потім не
виконує нічого, чи це дійсно щось більше ніж незначний відтік часу життя вашої
батареї? В нейтралізованому стані, Intel ME є лише неактивним комп'ютером
на вашій материнській платі, таким, що нічого не робить, який вам не потрібен і який ви
ніколи не будете використовувати. Таким чином, його можна розцінювати нешкідливим з обох перспективи свободи
програмного забезпечення та перспективи безпеки, і це є поглядом, який взято
проектом Libreboot.
Якщо триматись цих припущень, і ви погодились зі статтею Libreboot про
мікрокод, на яку наведено посилання зверху, і зважаєте *факт*, що (щонайменш, станом на
зараз) Libreboot є здатним на повністю вільну ініціалізацію в межах coreboot, тоді
ми можемо не без причини бути впевненими, що Libreboot надає гарний рівень свободи
програмного забезпечення. Так, незважаючи на те, як дехто може інакше почувати, якщо вони *не* мають
такої перспективи.
Тобто, хоча код BringUp, який залишається для Intel ME *є* пропрієтарним,
та не може бути модифікованим, в зв'язку з перевіркою криптографічного підпису
апаратним забезпечення, це є програмним забезпеченням для пристрою, який ви ніколи не захочете насправді
використовувати в реальному світі, тобто якщо він *не робить нічого* в нейтралізованому стані, тоді
його може бути проігноровано на практиці. Це залежить від вашої точки зору, і деякі
люди можуть займати більш догматичний підхід, ніж цей. Проект Libreboot
зважає нейтралізовані налаштування ME прийнятними, обидва з перспективи безпеки
та перспективи свободи програмного забезпечення.
Більше про видалення/вимкнення Intel ME
----------------------------------
*Libreboot* надає шлях повністю видалити прошивку ME, зберігаючи
повне використання машини, на платформах GM45 з південним мостом ICH9M. Це
ноутбуки: ThinkPad X200/T400/T500/W500 і так далі з того покоління. Дивіться:
[docs/install/ich9utils.md](docs/install/ich9utils.md)
На новіших платформах використовується `me_cleaner`. Ви можете прочитати про це тут:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
Option ROM VGA
============
*Нативна* ініціалізація відео підтримується та *увімкнена*, для всіх платформ
Intel, які підтримуються, що мають її. Джерельний код надано coreboot, під
вільною ліцензією.
На *деяких* машинах, подвійна графіка є можливою. Наприклад, конкретні материнські плати ThinkPad
T440p ідуть з обома графічними картками Intel та Nvidia, де ви можете
або використовувати *обидві*, або тільки Intel; для використання графічної картки Nvidia, двійковий блоб
вимагається, який Libreboot не надає (і не захоче надавати), натомість вибираючи
увімкнення тільки графічної карти *Intel* (де вільний код ініціалізації є доступним
в coreboot). В більшості материнських плат T440p, *тільки* графічна картка Intel є фізично
присутньою.
На деяких материнських платах ThinkPad T400, W500 та T500, графічні карти ATI та Intel є
присутніми, і ви можете використовувати або одну, або обидві. Ще раз, Libreboot *тільки* підтримує
графічну картку Intel, де coreboot має вільний код ініціалізації.
Це є прикладом нюансованого характеру в політиці Libreboot. Libreboot
*міг би* надавати подібні блоби, з судженням, що *необхідно*
використовувати ці додаткові процесори. Однак, на практиці, ці машини є повністю придатними
для використання лише з графікою Intel, для якої джерельний код є доступним.
За замовчуванням Libreboot є *завжди* свобода, коли можливо на практиці. Користувачі, які
бажають мати використання додаткових графічних процесорів, на такому апаратному забезпеченні, мають взяти до уваги
наступний параграф у політиці Libreboot:
*"Принципам зверху варто бути застосованими до конфігурацій за замовчування. Однак,
libreboot є налаштовуваним, дозволяючи користувачу робити все, що заманеться."* -
налаштовуваний, напевно! Дивіться: [docs/maintain/](docs/maintain/)
Ініціалізація контролера пам'яті
--------------------------------
Libreboot має *повністю вільну* ініціалізацію, доступну для всіх контролерів пам'яті Intel
на платформах, які підтримуються. Це *включає* Haswell (ThinkPad T440p
та W541), станом на Libreboot 20230319 та пізніші.
Платформи AMD
=============
Libreboot наразі *бракує* підтримки для платформ AMD, але інформація про
них буде написана, коли цей факт зміниться.
Платформи ARM (chromebook)
=============
В більшості без блобів, за вийнятком вимоги на материнських платах `daisy` та `peach`
включати блоби завантажувача BL1. Це:
* HP Chromebook 11 G1 (daisy-spring)
* Samsung Chromebook XE303 (daisy-snow)
* Samsung Chromebook 2 13” (peach-pi)
* Samsung Chromebook 2 11” (peach-pit)
Libreboot *наразі* не розміщує ці блоби взагалі, і це
вважається *помилкою*; це задокументовано на сторінці сумісності
апаратного забезпечення. Їх можна додати вручну користувачем, але документації для цього
наразі бракує на веб-сайті Libreboot.
Список необхідних блобів, конкретно для кожної плати
=================================================
Ця стаття ретельно пояснила, в деталізованому огляді, точний
характер того, *які* бінарні блоби розміщуються в Libreboot. Знову,
повністю вільна ініціалізація з coreboot є доступною *на всіх наразі підтримуваних платах*.
*З coreboot* є критичним аспектом цього, але повні межі Libreboot це
основна завантажувальна інтегральна схема, яка (в деяких випадках) містить програмне забезпечення не з coreboot.
Ось список, *для кожної* плати, цих блобів:
Intel/x86
---------
Нейтралізований ME потрібен на цих цілях: `t420_8mb`, `t420s_8mb`, `t430_12mb`,
`t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`,
`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
`x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff_8mb`, `hp2560p_8mb`
та `hp9470m_16mb`.
Як заявлено, Libreboot надає це в стані, де ME більше не є
загрозою для безпеки. Він ініціалізує себе, але потім нічого не робить, тому його
вимкнено. Це зроблено використовуючи `me_cleaner`. Дивіться:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
KBC1126 EC firmware on `hp9470m_16mb` and `hp9470m_16mb` - on HP laptops, EC
firmware is inserted into main boot flash, rather than being on a separate IC.
This is *better* because libre replacements would be more easy to install in
the future, and reverse engineering is made much easier by it. Libreboot's
build system handles such firmware in `blobutil`, automatically downloading
it during the build process - Libreboot 20230423 onwards does scrub EC firmware
and provide functionality in `blobutil` insert, to insert them with `cbfstool`
at the correct offset as defined by coreboot config for each board. - **TODO:
English paragraph that needs to be translated into Ukrainian.**
Оновлення *мікрокоду* для ЦП надано на *всіх* платформах x86, за замовчуванням. Не
вимагається технічно, але надзвичайно рекомендовано. Виконайте для видалення:
cbfstool filename.rom remove -n cpu_microcode_blob.bin
[Releases after Libreboot 20230423 will provide separate ROMs with microcode
excluded, alongside default ones with microcode included.](news/microcode.md)
Видалення оновлень мікрокоду вплине на стабільність системи негативно,
впроваджуючи нестандартну поламану поведінку і його результатом може бути
неможливість машини правильно завантажуватись. В інших випадках, видалення його може поламати такі функції,
як S3 suspend/resume.
Блоби мікрокоду ЦП включено за замовчуванням, на всіх платах x86. В той час як не потрібні
в більшості випадків, їх використання надзвичайно рекомендовано. Дивіться для причин чому:
[news/policy.uk.md#більш-детальна-інформація-про-мікрокод](news/policy.uk.md#більш-детальна-інформація-про-мікрокод)
Intel Flash Descriptor надано в якості блобів на деяких платах, але це не є
блобами *програмного забезпечення*. Це конфігурації, які надано в двійковому форматі,
повністю придатному для читання вільним програмним забезпеченням. Наприклад:
* Програма Libreboot `ich9gen` створює флеш-дескриптори ICH9M з нуля.
* Програма Coreboot `ifdtool` має обширні функції для маніпуляції Intel
flash descriptor.
* Програма Coreboot `bincfg` створює будь-який вид бінарних з файлу `.spec`,
який може описувати будь-який бінарний формат в форматі, який можна прочитати людині. Вона містить
декілька Intel flash descriptor для декількох платформ, але Libreboot не використовує
їх.
Конфігурація Intel GbE NVM (конфігураційні дані, закодовані двійково, для гігабітної мережевої картки):
* Програма Libreboot `ich9gen` *також* створює образи GbE NVM, конкретно
для мережевих карток Intel, які використані в Thinkpad GM45.
* Програма Libreboot `nvmutil` може маніпулювати образами GbE NVM
ARM/chromebook
---------------
BL1 завантажувач потрібен на: `daisy_snow`, `daisy_spring` та `peach_pit`.
Висновки
==========
З вищезазначеного, ви можете бачити, що Libreboot в дійсності *надає* *політику зменшення
бінарних блобів*, з наголошенням на *зменшенні*, що є найбільш критичним.
Libreboot *міг би* додати багато блобів для різних платформ, для увімкнення різноманітних
додаткових функцій, які натомість він уникати додавати, в точності тому, що *метою*
проекта Libreboot є поширення *вільного* програмного забезпечення та *мінімізація* сили,
яку розробники пропрієтарного програмного забезпечення мають над користувачами.
Я сподіваюсь, що ця стаття надала їжу для роздумів.
Відступ: свобода обладнання
--------------------------
Жодна з машин, які наразі підтримуються Libreboot не має вільного *апаратного забезпечення*, в тому
сенсі, що інтегральні схеми не ідуть з публічно доступними файлами *verilog* та
подібним. Ви не змогли би виготовити власну заміну цих машин.
Деякі схеми та файли бордв'ю описують друковані плати окремих
машин, які доступні онлайн, через різноманітні канали. Ви маєте знайти їх
власноруч; одного дня, рух Право на ремонт, сподіваюся, принесе
універсальний доступ до таких документів спільноті.
Для подальшого читання
===============
В цій статті описано код, який міститься в *основній завантажувальній флеш-пам'яті*, але
будь-який комп'ютер, який ви придбаєте, матиме *тони* мікропрограм в інших частинах системи. Деякі
відомості доступні на сторінці частих запитань Libreboot. Дивіться:
* [faq.uk.md#який-рівень-програмної-свободи-дає-мені-libreboot](faq.uk.md#який-рівень-програмної-свободи-дає-мені-libreboot)
* [faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot](faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot)
З них найбільш критичним є прошивка жорстких дисків/твердотілих накопичувачів та прошивка EC. Проблема описана
в цих двох посиланнях застосовується до багатьох різних комп'ютерів, включаючи
Libreboot, та практично кожний інший комп'ютер в світі.

60
site/index.de.md
View File

@ -4,7 +4,7 @@ x-toc-enable: true
...
Das *Libreboot* Projekt bietet
eine [freie](freedom-status.md) *Boot
eine [freie](https://writefreesoftware.org/) *Boot
Firmware* welche auf [bestimmten Intel/AMD x86 und ARM Geräten](docs/hardware/)
die Hardware initialisiert (z.b. Speicher-Controller, CPU, Peripherie),
und dann einen Bootloader für dein Betriebssystem startet. [Linux](docs/linux/)
@ -13,11 +13,11 @@ Firmware. Hilfe ist verfügbar
via [\#libreboot](https://web.libera.chat/#libreboot)
und [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
<img tabindex=1 class="r" src="https://av.libreboot.org/t500/0005.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0005.jpg" /></span>
**NEUESTE VERSION: Die neueste Version von Libreboot ist 20230625, veröffentlicht am
25. June 2023.
Siehe auch: [Libreboot 20230625 release announcement](news/libreboot20230625.md).**
**NEUESTE VERSION: Die neueste Version von Censored Libreboot ist c20230710, veröffentlicht am
10. July 2023.
Siehe auch: [Censored Libreboot c20230710 release announcement](news/censored-libreboot20230710.md).**
Warum solltest Du *Libreboot* verwenden?
----------------------------
@ -53,7 +53,7 @@ Dokumentation ist verfügbar.
Libreboot ist kein Coreboot Fork
-----------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.libreboot.org/dip8/adapter.jpg" /></span>
Tatsächlich versucht Libreboot so nah am regulären Coreboot zu bleiben wie möglich,
für jedes Board, aber mit vielen automatisch durch das Libreboot Build System zur
@ -78,51 +78,3 @@ Reguläre Binär Veröffentlichungen bieten diese ROM Images vor-kompiliert,
und Du kannst dies einfach installieren ohne spezielle technische
Kenntnisse oder Fertigkeiten abgesehen von der Fähigkeit einer
[vereinfachten Anleitung, geschrieben für technisch unerfahrene Benutzer](docs/install/) zu folgen.
Wie kann ich helfen
-----------
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
Der beste Weg wie Du helfen kannst, ist das *hinzufügen* neuer Mainboards in
Libreboot, indem Du eine Konfiguration zur Verfügung stellst. Alles was von
Coreboot unterstützt wird kann auch in Libreboot integriert werden, mithilfe
von ROM Images in den Veröffentlichungen. Siehe auch:
* [Bewerbe dich um Boards zu testen oder zu pflegen](docs/maintain/testing.md)
* [Anleitung um neue Mainboards hinzuzufügen](docs/maintain/porting.md)
* [Libreboot Build System Dokumentation](docs/maintain/)
Zudem ist da noch Pflege des Build Systems (siehe oben), sowie *Dokumentation*
welche wir sehr ernst nehmen. Dokumentation ist wichtig, in jedem Projekt.
*Hilfe für Benutzer* ist ebenso wichtig. Bleibe im IRC Chat, und falls Du
kompetent genug bist jemandem bei seinem Problem zu helfen (oder bereit mit
der Person gemeinsam zu lernen), dann ist dies ein wichtiger Beitrag zum
Projekt. Viele Leute fragen zudem unter dem Subreddit `r/libreboot` nach Hilfe.
Eine Liste mit Bugs gibt es
unter [Bug Tracker](https://codeberg.org/libreboot/lbmk/issues).
Sofern Du einen Bug findest oder einen Fix hast, [hier sind Anleitungen um Patches zu
schicken](git.de.md), oder Du kannst davon berichten. Diese Website ist zudem
in Markdown geschrieben und verfügbar in einem [separaten
Repository](https://codeberg.org/libreboot/lbwww) für welches Du auch Patches schicken kannst.
Sämtliche Diskussionen über Entwicklung sowie Hilfe für Nutzer findet im IRC
Kanal statt. Mehr Informationen gibt es unter [Kontakt](contact.de.md).
Übersetzungen für libreboot.org benötigt
--------------------------------------
Libreboot hat derzeit übersetzte Webseiten in ukrainisch und französisch (aber bislang
nicht für alle Seiten für keine der Sprachen)
Sofern Du mit Übersetzungen helfen möchtest, kannst Du Seiten übersetzen,
existierende Übersetzungen überarbeiten oder deine übersetzten Versionen schicken.
Für Anleitungen, siehe bitte hier:
[Wie man Übersetzungen für libreboot.org bereitstellt](news/translations.de.md)
Auch wenn jemand bereits an einer Übersetzung in einer bestimmten Sprache arbeitet,
so können wir immer mehrere Leute gebrauchen. Desto mehr desto besser!

56
site/index.fr.md
View File

@ -3,7 +3,7 @@ title: Projet Libreboot
x-toc-enable: true
...
Libreboot est un micrologiciel de démarrage [libéré](freedom-status.md)
Libreboot est un micrologiciel de démarrage [libéré](https://writefreesoftware.org/)
qui initialise le matériel (càd le contrôleur mémoire, CPU,
périphériques) sur [des ordinateurs x86/ARM spécifiques](docs/hardware/)
et lance un chargeur d'amorçage pour votre système d'exploitation. [Linux](docs/linux/) et [BSD](docs/bsd/) sont bien supportés. C'est un
@ -11,10 +11,10 @@ remplacement pour le micrologiciel UEFI/BIOS propriétaire.
Des canaux d'aide sont disponibles
dans le canal [\#libreboot](https://web.libera.chat/#libreboot) sur le serveur IRC [Libera](https://libera.chat/).
<img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
<img tabindex=1 class="r" src="https://av.libreboot.org/t500/0005.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0005.jpg" /></span>
**NOUVELLE VERSION: La dernière version est [Libreboot 20230625](news/libreboot20230625.md), sortie
le 25 Juin 2023.**
**NOUVELLE VERSION: La dernière version est [Censored Libreboot c20230710](news/censored-libreboot20230710.md), sortie
le 10 Juillet 2023.**
Pourquoi devriez-vous utiliser *Libreboot*?
-----------------------------------
@ -49,7 +49,7 @@ un [système de compilation automatisé](docs/builds/), crééant des
De quelle façon Libreboot diffère de Coreboot?
------------------------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.libreboot.org/dip8/adapter.jpg" /></span>
Contrairement à l'opinion populaire, le but principal de Libreboot n'est
pas de fournir un Coreboot déblobbé; ceci n'est simplement qu'une
@ -74,49 +74,3 @@ de connaissances techniques décente pour écrire une configuration qui marche.
Les versions de Libreboot fournissent ces images ROM pré-compilés et vous
pouvez les installez simplement, sans connaissance ou compétence particulière
à savoir, sauf [suivre des instructions simplifiés écrite pour des utilisateurs non techniques](docs/install/).
Comment aider
-----------
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
The *single* biggest way you can help it to *add* new mainboards to Libreboot,
by submitting a config. Anything coreboot supports can be integrated in
Libreboot, with ROM images provided in releases. See:
* [Apply to become a board maintainer/tester](docs/maintain/testing.md)
* [Porting guide for new mainboards](docs/maintain/porting.md)
* [Libreboot build system documentation](docs/maintain/)
After that, there is build system maintenance (see above), and *documentation*
which we take seriously. Documentation is critical, in any project.
*User support* is also critical. Stick around on IRC, and if you're competent
to help someone with their issue (or wily enough to learn with them), that is
a great service to the project. A lot of people also ask for user support
on the `r/libreboot` subreddit.
Vous pouvez allez voir les bugs listés sur le [traqueur de bugs](https://codeberg.org/libreboot/lbmk/issues).
Si vous trouvez un bug et avez un correctif, [voici les instructions pour envoyer des patchs](git.md), et vous pouvez aussi nous les signaler.
Par ailleurs, ce site est écrit en Markdown et hébergé dans un [dépôt séparé](https://codeberg.org/libreboot/lbwww) où
vous pouvez envoyer vos patchs.
La discussion sur le dévéloppement de Libreboot et le support utilisateur
se font toutes sur le canal IRC. Plus d'information est disponible sur
la [page de contact](contact.md).
Translations needed, for libreboot.org
--------------------------------------
Libreboot currently has translated Web pages in Ukrainian and French (but not
for all pages, yet, on either language).
If you want to help with translations, you can translate pages, update existing
translations and submit your translated versions. For instructions, please
read:
[How to submit translations for libreboot.org](news/translations.md)
Even if someone is already working on translations in a given language, we can
always use multiple people. The more the merrier!

59
site/index.md
View File

@ -4,7 +4,7 @@ x-toc-enable: true
...
The *Libreboot* project provides
[free, open source](freedom-status.md) (*libre*) boot
[free, open source](https://writefreesoftware.org/) (*libre*) boot
firmware based on coreboot, replacing proprietary BIOS/UEFI firmware
on [specific Intel/AMD x86 and ARM based motherboards](docs/hardware/),
including laptop and desktop computers. It initialises the hardware (e.g. memory
@ -13,11 +13,11 @@ system. [Linux](docs/linux/) and [BSD](docs/bsd/) are well-supported. Help is
available via [\#libreboot](https://web.libera.chat/#libreboot)
on [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
<img tabindex=1 class="r" src="https://av.libreboot.org/t500/0005.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0005.jpg" /></span>
**NEW RELEASE: The latest release is Libreboot 20230625, released on
25 June 2023.
See: [Libreboot 20230625 release announcement](news/libreboot20230625.md).**
**NEW RELEASE: The latest release is Censored Libreboot c20230710, released on
10 July 2023.
See: [Censored Libreboot c20230710 release announcement](news/censored-libreboot20230710.md).**
Why should you use *Libreboot*?
----------------------------
@ -51,7 +51,7 @@ more robust installation. Documentation is provided.
Libreboot is not a fork of coreboot
-----------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.libreboot.org/dip8/adapter.jpg" /></span>
In fact, Libreboot tries to stay as close to *stock* coreboot as possible,
for each board, but with many different types of configuration provided
@ -75,50 +75,3 @@ ROM images pre-compiled, and you can simply install them, with no special
knowledge or skill except the ability to
follow [simplified instructions, written for non-technical
users](docs/install/).
How to help
-----------
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
The *single* biggest way you can help is to *add* new mainboards in Libreboot,
by submitting a config. Anything coreboot supports can be integrated in
Libreboot, with ROM images provided in releases. See:
* [Apply to become a board maintainer/tester](docs/maintain/testing.md)
* [Porting guide for new mainboards](docs/maintain/porting.md)
* [Libreboot build system documentation](docs/maintain/)
After that, there is build system maintenance (see above), and *documentation*
which we take seriously. Documentation is critical, in any project.
*User support* is also critical. Stick around on IRC, and if you're competent
to help someone with their issue (or wily enough to learn with them), that is
a great service to the project. A lot of people also ask for user support
on the `r/libreboot` subreddit.
You can check bugs listed on
the [bug tracker](https://codeberg.org/libreboot/lbmk/issues).
If you spot a bug and have a fix, [here are instructions for how to send
patches](git.md), and you can also report it. Also, this entire website is
written in Markdown and hosted in a [separate
repository](https://codeberg.org/libreboot/lbwww) where you can send patches.
Any and all development discussion and user support are all done on the IRC
channel. More information is on the [contact page](contact.md).
Translations needed, for libreboot.org
--------------------------------------
Libreboot currently has translated Web pages in Ukrainian and French (but not
for all pages, yet, on either language).
If you want to help with translations, you can translate pages, update existing
translations and submit your translated versions. For instructions, please
read:
[How to submit translations for libreboot.org](news/translations.md)
Even if someone is already working on translations in a given language, we can
always use multiple people. The more the merrier!

56
site/index.uk.md
View File

@ -4,7 +4,7 @@ x-toc-enable: true
...
Проект *Libreboot* надає
[вільну](freedom-status.uk.md) *завантажувальну
[вільну](https://writefreesoftware.org/) *завантажувальну
прошивку*, яка ініціалізує апаратне забезпечення (наприклад, контролер пам'яті, ЦП,
периферію) на [конкретних цілях Intel/AMD x86 та ARM](docs/hardware/), що
потім розпочинає завантажувач для вашої операційної системи. [Linux](docs/linux/)
@ -13,10 +13,10 @@ x-toc-enable: true
через [\#libreboot](https://web.libera.chat/#libreboot)
на [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
<img tabindex=1 class="r" src="https://av.libreboot.org/t500/0005.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0005.jpg" /></span>
**НОВИЙ ВИПУСК: Останній випуск Libreboot 20230625, випущено 25 червня 2023.
Дивіться: [Оголошення про випуск Libreboot 20230625](news/libreboot20230625.md).**
**НОВИЙ ВИПУСК: Останній випуск Censored Libreboot c20230710, випущено 10 липня 2023.
Дивіться: [Оголошення про випуск Censored Libreboot c20230710](news/censored-libreboot20230710.md).**
Чому вам варто використовувати *Libreboot*?
----------------------------
@ -49,7 +49,7 @@ Coreboot помітно складний для встановлення для
Чим Libreboot відрізняється від звичайного coreboot?
---------------------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.libreboot.org/dip8/adapter.jpg" /></span>
Таким же самим чином, як *Debian* це дистрибутив Linux, Libreboot це
*дистрибутив coreboot*. Якщо ви хочете зібрати образ ROM з нуля, вам
@ -69,49 +69,3 @@ Coreboot помітно складний для встановлення для
знань або навичок, окрім можливості
слідувати [спрощеним інструкціям, написаним для нетехнічних
користувачів](docs/install/).
Як допомогти
-----------
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
*Єдиний* найбільший шлях, яким ви можете допомогти є *додавання* нових материнських плат до Libreboot,
за допомогою відправки конфігурації. Що завгодно, що підтримує coreboot може бути інтегровано в
Libreboot, з образами ROM наданими в випусках. Дивіться:
* [Подача на становлення супровідником/випробувачем плати](docs/maintain/testing.md)
* [Керівництво перенесення для нових материнських плат](docs/maintain/porting.uk.md)
* [Документація системи побудови Libreboot](docs/maintain/)
Після цього, є обслуговування системи побудови (дивіться зверху), та *документація*,
до якої ми ставимося серйозно. Документація є критичною, в будь-якому проекті.
*Користувацька ідтримка* є також критичною. Тримайтесь поряд на IRC, і якщо ви компетентні
допомогти комусь з їх проблемним питанням (або досить вправні, щоб навчитись з ними), це є
чудовою послугою для проекту. Багато людей також запитує підтримки користувачів
на subreddit `r/libreboot`.
Ви можете перевірити помилки, перелічені
в [системі відстеження помилок](https://codeberg.org/libreboot/lbmk/issues).
Якщо ви помітили помилку і маєте виправлення, [ось інструкції щодо надсилання виправлень](git.uk.md), а також ви можете повідомити про це. Також, весь цей веб-сайт
написаний Markdown та розміщений в [окремому
сховищі](https://codeberg.org/libreboot/lbwww), де ви можете надсилати виправлення.
Усі обговорення розробки та підтримка користувачів відбуваються на IRC
каналі. Більше інформації на [сторінці зворотнього зв'язку](contact.uk.md).
Переклади потрібні, для libreboot.org
--------------------------------------
Libreboot наразі має перекладеними веб-сторінки українською та французькою (але не
для всіх сторінок, ще, жодною з мов).
Якщо ви бажаєте допомогти з перекладами, ви можете перекласти сторінки, оновити
існуючи переклади та надати ваші перекладені версії. Для інструкцій, будь ласка
прочитайте:
[Як надати переклади для libreboot.org](news/translations.md)
Навіть якщо хтось вже працює над перекладами даною мовою, ми можемо
завжди використовувати багато людей. Чим більше, тим краще!

42
site/index.zh-cn.md
View File

@ -3,12 +3,12 @@ title: Libreboot 项目
x-toc-enable: true
...
*Libreboot* 项目提供了[自由](freedom-status.md)的*引导固件*，能够在[特定的 Intel/AMD x86 以及 ARM 目标机](docs/hardware/)上对硬件（如内存控制器、CPU、外设）进行初始化，进而为操作系统启动 bootloader。本项目对 [Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好，并替代了专有的 BIOS/UEFI 固件。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#libreboot](https://web.libera.chat/#libreboot) 频道。
*Libreboot* 项目提供了[自由](https://writefreesoftware.org/)的*引导固件*，能够在[特定的 Intel/AMD x86 以及 ARM 目标机](docs/hardware/)上对硬件（如内存控制器、CPU、外设）进行初始化，进而为操作系统启动 bootloader。本项目对 [Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好，并替代了专有的 BIOS/UEFI 固件。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#libreboot](https://web.libera.chat/#libreboot) 频道。
<img tabindex=1 class="r" src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /><span class="f"><img src="https://av.libreboot.org/hp9470m/9470m+2560p.jpg" /></span>
<img tabindex=1 class="r" src="https://av.libreboot.org/t500/0005.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0005.jpg" /></span>
**新版发布: 最新版本 Libreboot 20230625 已在 2023 年 6 月 25 日发布。
详见: [Libreboot 20230625 发布公告](news/libreboot20230625.md).**
**新版发布: 最新版本 Censored Libreboot c20230710 已在 2023 年 7 月 10 日发布。
详见: [Censored Libreboot c20230710 发布公告](news/censored-libreboot20230710.md).**
为什么要使用 *Libreboot*?
----------------------------
@ -24,7 +24,7 @@ Libreboot 项目使用 [coreboot](https://www.coreboot.org/) 来[初始化硬件
Libreboot 不是 coreboot 的分支
-----------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /><span class="f"><img src="https://av.libreboot.org/thinkpadcollection/thinkpadcollection1-min.jpg" /></span>
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.libreboot.org/dip8/adapter.jpg" /></span>
事实上，Libreboot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 Libreboot 构建系统也自动提供了许多不同类型的配置。
@ -33,35 +33,3 @@ Libreboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *L
如果你要构建常规的 coreboot，而不使用 Libreboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
Libreboot 的常规二进制版本，提供了这些预编译的 ROM 镜像。你可以轻松安装它们，而无需特别的知识和技能，只要能遵循[写给非技术用户的简单指南](docs/install/)。
如何帮忙
-----------
<img tabindex=1 class="l" style="max-width:15%;" src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /><span class="f"><img src="https://av.libreboot.org/hp8200sff/grub_open.jpg" /></span>
要帮忙的话，*最*最好的方式，就是通过提交配置文件，来为 Libreboot *添加*新的主板。coreboot 支持的任何东西，都能并入 Libreboot，并且带有 ROM 镜像。见：
* [申请成为主板维护者/测试者](docs/maintain/testing.md)
* [新主板移植指南](docs/maintain/porting.md)
* [Libreboot 构建系统文档](docs/maintain/)
然后，就是构建系统的维护（见下）以及重要的*文档*。文档十分重要，在任何项目都是如此。
*用户支持*也十分重要。多瞧一瞧 IRC，如果你有能力帮别人解决问题（或者愿意跟他们一起学习），那对本项目的贡献会很大。许多人也在 reddit 版块 `r/libreboot` 寻求用户支持。
你可以检查[缺陷追踪系统](https://codeberg.org/libreboot/lbmk/issues)列出的缺陷。
如果你发现了一个缺陷，并且有解决方案，[这里说明了发布补丁的方法](git.md)，你也可以提交报告。同时，本站完全使用 Markdown 编写，并托管在了一个[单独的仓库](https://codeberg.org/libreboot/lbwww)，你可以在那里发送补丁。
所有开发方面的讨论以及用户支持，都是在 IRC 频道上完成的。了解更多，可以查看[联系](contact.md)页面。
libreboot.org 需要翻译
--------------------------------------
Libreboot 目前有乌克兰语和法语的网页翻译（但两个语言都还没翻译完所有页面）。
如果你想帮忙翻译，你可以翻译网页、更新已有翻译并提交你的译本。请阅读下面的指南：
[如何提交 libreboot.org 翻译](news/translations.md)
即使已经有人在进行某个语言的翻译了，我们也总是欢迎更多人。多多益善！

13
site/news/MANIFEST
View File

@ -1,24 +1,11 @@
safety.md
libreboot20230625.md
microcode.md
audit.md
e6400nvidia.md
libreboot20230423.md
hp_elitebooks.md
e6400.md
gm45microcode.md
hp8200sff.md
libreboot20230413.md
mirrors.md
codeberg.md
kgpe-d16.md
freedom.md
libreboot20230319.md
usa-libre-part3.md
usa-libre-part2.md
fedfree.md
libreboot20221214.md
policy.md
libreboot20220710.md
usa-libre.md
translations.md

206
site/news/audit.md
View File

@ -5,7 +5,7 @@
Introduction
============
Literally about 200+ changes have been made to the Libreboot build system,
A substancial number of changes have been made to the Libreboot build system,
since the last release of Libreboot. This has been the primary focus, thus far.
In recent weeks, Libreboot's build system has gone through an intense audit and
@ -129,29 +129,6 @@ and certain redundant variables removed. Logic split into functions, and the
code is conditionally *pledged* if you compile it on OpenBSD (for OpenBSD),
see: <https://man.openbsd.org/pledge.2>
Other plans for next release
============================
I have a bunch of Dell/HP boards that I plan to add, which I would have added
already but I've focused on the audit (which is more or less complete, now).
Besides this, I also wish to:
* Re-add Tianocore UEFI payload, on boards where this is feasible, providing it
as an option alongside existing GRUB/SeaBIOS payloads
* Provide a Linux kexec payload, based on the Linux payload provided by Heads.
I was initially working on a port of the OpenBSD userland to Linux and musl
first, because I want to replace busybox, but this is taking too long so I've
shelved it and will release that at a later date. The Heads build system is
already excellent for this purpose (though they use busybox, in their linux
distro), and I intend to adapt (directly adapt) their build system to be
used in lbmk (re-implement the same logic, but in shell scripts, where Heads
currently uses a lot of Makefiles that I find messy in comparison to lbmk's
way of doing things - though their way also has its benefits)
* If time, test more ChromeOS boards (gru-* but also the nyan, peach and veyron
boards, most of which are untested. Only the gru platforms are known to work
with Libreboots u-boot payload, at present).
FULL list of changes so far since last release
==============================================
@ -163,74 +140,59 @@ are available, live:
on 13 June 2023)
```
* ac0bd172 - (HEAD -> master) remove errant file (36 minutes ago) <Leah Rowe>
* d617135d - (origin/master) Merge pull request 'lbmk: Fix regressions' (#77) from nic3-14159/lbmk:fix-lbmk into master (49 minutes ago) <Leah Rowe>
|\
| * 0fade1b6 - lbmk: Fix regressions (61 minutes ago) <Nicholas Chin>
|/
* b52a7f4f - util/spkmodem-recv: re-add full license header (2 hours ago) <Leah Rowe>
* 7ca9b987 - util/ich9gen: change default mac address (2 hours ago) <Leah Rowe>
* e75dafa4 - Merge pull request 'Add 4MB version of HP 8200 SFF' (#72) from Riku_V/lbmk:hp8200sff_4mb into master (3 days ago) <Leah Rowe>
|\
| * 0f7a5386 - Add 4MB version of HP 8200 SFF (2 weeks ago) <Riku Viitanen>
* | e6d4aeb2 - Merge pull request 'Update Git revision for bios_extract' (#74) from nic3-14159/lbmk:update_bios_extract into master (3 days ago) <Leah Rowe>
|\ \
| * | d059fefe - Update Git revision for bios_extract (3 days ago) <Nicholas Chin>
|/ /
* | dee8f44b - util/spkmodem-recv: fix regression (5 days ago) <Leah Rowe>
* | f2822db9 - util/spkmodem-recv: make ringpos a global variable (7 days ago) <Leah Rowe>
* | 334bfedf - util/spkmodem-recv: simplify sample_cnt/char reset (8 days ago) <Leah Rowe>
* | 4a6b5827 - util/spkmodem-recv: print stats in other function (8 days ago) <Leah Rowe>
* | 2652a1dd - util/spkmodem-recv: only print unhandled err on -d (8 days ago) <Leah Rowe>
* | 3fb99a01 - util/spkmodem-recv: make debug a runtime option (8 days ago) <Leah Rowe>
* | 264a31b9 - util/spkmodem-recv: always disable line buffering (8 days ago) <Leah Rowe>
* | 118bb19f - util/spkmodem-recv: simplify stdout flush logic (8 days ago) <Leah Rowe>
* | af36cc7f - util/spkmodem-recv: rename variables for clarity (8 days ago) <Leah Rowe>
* | f7fccb59 - util/spkmodem-recv: split print_char() up (8 days ago) <Leah Rowe>
* | b40a30b1 - util/spkmodem-recv: reduce indent in print_char() (8 days ago) <Leah Rowe>
* | b21c1dd5 - util/spkmodem-recv: squash a few code lines (8 days ago) <Leah Rowe>
* | 3401f287 - util/spkmodem-recv: bsd-style indent (8 days ago) <Leah Rowe>
* | 2a6ad971 - util/spkmodem-recv: order prototypes per function (8 days ago) <Leah Rowe>
* | 212ce3a8 - util/spkmodem-recv: warn on unhandled exit error (8 days ago) <Leah Rowe>
* | 9a6d2908 - util/spkmodem-recv: another minor code cleanup (8 days ago) <Leah Rowe>
* | a61ab37b - util/spkmodem-recv: always set errno on err() (8 days ago) <Leah Rowe>
* | e8889fd1 - util/spkmodem-recv: minor code cleanup (8 days ago) <Leah Rowe>
* | 3c2a287e - util/spkmodem-recv: handle sample errors correctly (8 days ago) <Leah Rowe>
* | 979db74c - util/spkmodem-recv: simplify pulse check (8 days ago) <Leah Rowe>
* | 94aa43d8 - util/nvmutil: call unveil earlier, and harden (9 days ago) <Leah Rowe>
* | db63fcff - util/nvmutil: hardening: reduce pledges earlier (9 days ago) <Leah Rowe>
* | dbd6defe - util/nvmutil: fix faulty arg check (9 days ago) <Leah Rowe>
* | 270693fc - util/nvmutil: cleanup: move logic out of main() (10 days ago) <Leah Rowe>
* | 46a9eea0 - util/nvmutil: major cleanup. simpler arg handling. (10 days ago) <Leah Rowe>
* | c9fdfce3 - util/nvmutil: simplify writeGbeFile() (11 days ago) <Leah Rowe>
* | bdccd7cb - util/nvmutil: don't call writeGbeFile if O_RDONLY (11 days ago) <Leah Rowe>
* | 99258a38 - util/nvmutil: code cleanup (pledge/unveil calls) (11 days ago) <Leah Rowe>
* | 69fa333e - util/nvmutil: harden pledge/unveil calls (OpenBSD) (12 days ago) <Leah Rowe>
* | adf3aece - util/nvmutil: fix faulty fd check (12 days ago) <Leah Rowe>
* | b49da12d - util/nvmutil: only swap/copy if checksum is valid (12 days ago) <Leah Rowe>
* | 9aa34f1e - util/nvmutil: use bsd-style indentation (12 days ago) <Leah Rowe>
* | 18f39ab6 - util/nvmutil: clean up rhex() (12 days ago) <Leah Rowe>
* | 4d91bcc2 - util/nvmutil: check correct return value on close() (12 days ago) <Leah Rowe>
* | c2c31677 - util/nvmutil: massive code cleanup (12 days ago) <Leah Rowe>
* | f0846134 - util/nvmutil: move includes to nvmutil.h (12 days ago) <Leah Rowe>
* | 2dabafe6 - util/nvmutil: move xpledge/xunveil to nvmutil.h (12 days ago) <Leah Rowe>
* | 9a3e6516 - util/nvmutil: use SPDX license headers (12 days ago) <Leah Rowe>
* | 5d6af06a - util/nvmutil: move non-functions to nvmutil.h (12 days ago) <Leah Rowe>
* | a2136933 - util/nvmutil: use even more macros (code cleanup) (12 days ago) <Leah Rowe>
* | 5a9fac2a - util/nvmutil: remove unnecessary parentheses (12 days ago) <Leah Rowe>
* | 6885200c - util/nvmutil: simplify setWord() with word() macro (12 days ago) <Leah Rowe>
* | 7ab209d5 - util/nvmutil: do xor swap in a macro (12 days ago) <Leah Rowe>
* | 293ca0fc - util/nvmutil pledge,unveil: use correct err string (12 days ago) <Leah Rowe>
* | a1df8fd1 - util/nvmutil: ensure that errno is set on err() (12 days ago) <Leah Rowe>
* | 1f548604 - util/nvmutil: minor code cleanup (12 days ago) <Leah Rowe>
* | 8f1e6d79 - util/nvmutil: simplified error handling in main (13 days ago) <Leah Rowe>
* | 78fc8935 - util/nvmutil: Use unveil, and harden pledges (13 days ago) <Leah Rowe>
* | c2cd1916 - util/nvmutil: Harden pledge promises (13 days ago) <Leah Rowe>
* | c759a7a0 - util/nvmutil: Simplify use of pledge (on OpenBSD) (13 days ago) <Leah Rowe>
* | f37bd759 - util/nvmutil: Use correct pledge promise (OpenBSD) (13 days ago) <Leah Rowe>
* | 83ecf268 - util/*: Properly detect OpenBSD for pledge() call (13 days ago) <Leah Rowe>
* | 8df2f809 - util/e6400-flash-unlock: clean up commented code (2 weeks ago) <Leah Rowe>
* 06c92d4a - blobutil: merge with main script (2 weeks ago) <Leah Rowe>
* dee8f44b - util/spkmodem-recv: fix regression (5 days ago) <Leah Rowe>
* f2822db9 - util/spkmodem-recv: make ringpos a global variable (7 days ago) <Leah Rowe>
* 334bfedf - util/spkmodem-recv: simplify sample_cnt/char reset (8 days ago) <Leah Rowe>
* 4a6b5827 - util/spkmodem-recv: print stats in other function (8 days ago) <Leah Rowe>
* 2652a1dd - util/spkmodem-recv: only print unhandled err on -d (8 days ago) <Leah Rowe>
* 3fb99a01 - util/spkmodem-recv: make debug a runtime option (8 days ago) <Leah Rowe>
* 264a31b9 - util/spkmodem-recv: always disable line buffering (8 days ago) <Leah Rowe>
* 118bb19f - util/spkmodem-recv: simplify stdout flush logic (8 days ago) <Leah Rowe>
* af36cc7f - util/spkmodem-recv: rename variables for clarity (8 days ago) <Leah Rowe>
* f7fccb59 - util/spkmodem-recv: split print_char() up (8 days ago) <Leah Rowe>
* b40a30b1 - util/spkmodem-recv: reduce indent in print_char() (8 days ago) <Leah Rowe>
* b21c1dd5 - util/spkmodem-recv: squash a few code lines (8 days ago) <Leah Rowe>
* 3401f287 - util/spkmodem-recv: bsd-style indent (8 days ago) <Leah Rowe>
* 2a6ad971 - util/spkmodem-recv: order prototypes per function (8 days ago) <Leah Rowe>
* 212ce3a8 - util/spkmodem-recv: warn on unhandled exit error (8 days ago) <Leah Rowe>
* 9a6d2908 - util/spkmodem-recv: another minor code cleanup (8 days ago) <Leah Rowe>
* a61ab37b - util/spkmodem-recv: always set errno on err() (8 days ago) <Leah Rowe>
* e8889fd1 - util/spkmodem-recv: minor code cleanup (8 days ago) <Leah Rowe>
* 3c2a287e - util/spkmodem-recv: handle sample errors correctly (8 days ago) <Leah Rowe>
* 979db74c - util/spkmodem-recv: simplify pulse check (8 days ago) <Leah Rowe>
* 94aa43d8 - util/nvmutil: call unveil earlier, and harden (9 days ago) <Leah Rowe>
* db63fcff - util/nvmutil: hardening: reduce pledges earlier (9 days ago) <Leah Rowe>
* dbd6defe - util/nvmutil: fix faulty arg check (9 days ago) <Leah Rowe>
* 270693fc - util/nvmutil: cleanup: move logic out of main() (10 days ago) <Leah Rowe>
* 46a9eea0 - util/nvmutil: major cleanup. simpler arg handling. (10 days ago) <Leah Rowe>
* c9fdfce3 - util/nvmutil: simplify writeGbeFile() (11 days ago) <Leah Rowe>
* bdccd7cb - util/nvmutil: don't call writeGbeFile if O_RDONLY (11 days ago) <Leah Rowe>
* 99258a38 - util/nvmutil: code cleanup (pledge/unveil calls) (11 days ago) <Leah Rowe>
* 69fa333e - util/nvmutil: harden pledge/unveil calls (OpenBSD) (12 days ago) <Leah Rowe>
* adf3aece - util/nvmutil: fix faulty fd check (12 days ago) <Leah Rowe>
* b49da12d - util/nvmutil: only swap/copy if checksum is valid (12 days ago) <Leah Rowe>
* 9aa34f1e - util/nvmutil: use bsd-style indentation (12 days ago) <Leah Rowe>
* 18f39ab6 - util/nvmutil: clean up rhex() (12 days ago) <Leah Rowe>
* 4d91bcc2 - util/nvmutil: check correct return value on close() (12 days ago) <Leah Rowe>
* c2c31677 - util/nvmutil: massive code cleanup (12 days ago) <Leah Rowe>
* f0846134 - util/nvmutil: move includes to nvmutil.h (12 days ago) <Leah Rowe>
* 2dabafe6 - util/nvmutil: move xpledge/xunveil to nvmutil.h (12 days ago) <Leah Rowe>
* 9a3e6516 - util/nvmutil: use SPDX license headers (12 days ago) <Leah Rowe>
* 5d6af06a - util/nvmutil: move non-functions to nvmutil.h (12 days ago) <Leah Rowe>
* a2136933 - util/nvmutil: use even more macros (code cleanup) (12 days ago) <Leah Rowe>
* 5a9fac2a - util/nvmutil: remove unnecessary parentheses (12 days ago) <Leah Rowe>
* 6885200c - util/nvmutil: simplify setWord() with word() macro (12 days ago) <Leah Rowe>
* 7ab209d5 - util/nvmutil: do xor swap in a macro (12 days ago) <Leah Rowe>
* 293ca0fc - util/nvmutil pledge,unveil: use correct err string (12 days ago) <Leah Rowe>
* a1df8fd1 - util/nvmutil: ensure that errno is set on err() (12 days ago) <Leah Rowe>
* 1f548604 - util/nvmutil: minor code cleanup (12 days ago) <Leah Rowe>
* 8f1e6d79 - util/nvmutil: simplified error handling in main (13 days ago) <Leah Rowe>
* 78fc8935 - util/nvmutil: Use unveil, and harden pledges (13 days ago) <Leah Rowe>
* c2cd1916 - util/nvmutil: Harden pledge promises (13 days ago) <Leah Rowe>
* c759a7a0 - util/nvmutil: Simplify use of pledge (on OpenBSD) (13 days ago) <Leah Rowe>
* f37bd759 - util/nvmutil: Use correct pledge promise (OpenBSD) (13 days ago) <Leah Rowe>
* 83ecf268 - util/*: Properly detect OpenBSD for pledge() call (13 days ago) <Leah Rowe>
* 8df2f809 - util/e6400-flash-unlock: clean up commented code (2 weeks ago) <Leah Rowe>
* ff954c5b - unify download/build scripts (2 weeks ago) <Leah Rowe>
* 092600d1 - unify these scripts: build, modify and update (2 weeks ago) <Leah Rowe>
* 6344b196 - build/payload/seabios: reduced indentation (2 weeks ago) <Leah Rowe>
@ -277,13 +239,10 @@ on 13 June 2023)
* fd2ca12e - gitclone: split logic out of main() (4 weeks ago) <Leah Rowe>
* 08ad9eb1 - download/coreboot: minor cleanup (4 weeks ago) <Leah Rowe>
* 8d9570b6 - gitclone: cleaner coding style (4 weeks ago) <Leah Rowe>
* 4ac0bc8d - blobutil/download: minor code cleanup (4 weeks ago) <Leah Rowe>
* 9fb489ac - modify: clean up duplicated code (4 weeks ago) <Leah Rowe>
* f7f3aef1 - modify: cleaner coding style (4 weeks ago) <Leah Rowe>
* 34df727c - build: cleaner coding style (4 weeks ago) <Leah Rowe>
* 1a062bb6 - build: reduce code to less than 80 chars per line (4 weeks ago) <Leah Rowe>
* a212a5be - blobutil: exit 1 if a called script fails (4 weeks ago) <Leah Rowe>
* e6221571 - blobutil: cleaner coding style (4 weeks ago) <Leah Rowe>
* c08e3258 - .gitcheck: exit 1 if unsupported argument given (4 weeks ago) <Leah Rowe>
* c5122557 - .gitcheck: use subshells where appropriate (4 weeks ago) <Leah Rowe>
* dd8fb524 - .gitcheck: re-add redirection to /dev/null (4 weeks ago) <Leah Rowe>
@ -358,7 +317,6 @@ on 13 June 2023)
* 8b4c1c16 - download/coreboot: consistent tab indentation (4 weeks ago) <Leah Rowe>
* 1388cccb - build/seabios: cleaner coding style (4 weeks ago) <Leah Rowe>
* ddad8f00 - build/seabios: simplify. stricter error handling (4 weeks ago) <Leah Rowe>
* b74e4078 - blobutil/download: cleaner coding style (4 weeks ago) <Leah Rowe>
* 557272fa - download/mrc: stricter error handling (4 weeks ago) <Leah Rowe>
* 7b36ffc1 - download/mrc: handle exit status within subshell (4 weeks ago) <Leah Rowe>
* 963b5247 - download/mrc: use cleaner coding style (4 weeks ago) <Leah Rowe>
@ -366,28 +324,12 @@ on 13 June 2023)
* db3c1d9c - download/grub: delete grub if gnulib cloning fails (4 weeks ago) <Leah Rowe>
* d90dfb0a - build/dependencies/*: RFC 2646 compliance (4 weeks ago) <Leah Rowe>
* 48bda9e0 - update/coreboot: top-down coding style (4 weeks ago) <Leah Rowe>
* a35f0b65 - blobutil/extract: minor code style cleanup (4 weeks ago) <Leah Rowe>
* 009bf3b6 - blobutil/extract: split up extract_blobs() (4 weeks ago) <Leah Rowe>
* fd3936cc - blobutil/extract: cleaner coding style (4 weeks ago) <Leah Rowe>
* 1f8ad1e4 - blobutil/extract: simplified main() (4 weeks ago) <Leah Rowe>
* 1ffb32b7 - blobutil/extract: top-down logic (4 weeks ago) <Leah Rowe>
* 423e2033 - blobutil/extract: RFC 2646 compliance (80 chars) (4 weeks ago) <Leah Rowe>
* 26dfda0c - blobutil/inject: print script path on error (4 weeks ago) <Leah Rowe>
* 6289eeb5 - blobutil/inject: fail if gbe.bin doesn't exist (4 weeks ago) <Leah Rowe>
* 54f8a453 - blobutil/inject: check that me.bin exists (4 weeks ago) <Leah Rowe>
* d34f3813 - blobutil/inject: check me path (4 weeks ago) <Leah Rowe>
* 5da7554a - blobutil/inject: remove errant debug message (4 weeks ago) <Leah Rowe>
* 70e337af - blobutil/inject: use x86 top-aligned mrc offset (4 weeks ago) <Leah Rowe>
* 17429788 - remove errant code lines from last commit (4 weeks ago) <Leah Rowe>
* ee0b200f - blobutil/inject: massively improved coding style (4 weeks ago) <Leah Rowe>
* 75ad8b0d - Merge pull request 'Remove warning for coreboot images build without a payload' (#65) from nic3-14159/lbmk:remove-no-payload-warning into master (4 weeks ago) <Leah Rowe>
|\
| * fdc9e444 - Remove warning for coreboot images build without a payload (4 weeks ago) <Nicholas Chin>
* | f2e31767 - modify/u-boot: cleaner coding style (4 weeks ago) <Leah Rowe>
* | 71cac866 - modify/coreboot: cleaner coding style (4 weeks ago) <Leah Rowe>
* | 174d3af7 - modify/seabios: cleaner coding style (4 weeks ago) <Leah Rowe>
* | c8dfc3cc - build/build/roms: simplify mkCoreboot() arguments (4 weeks ago) <Leah Rowe>
|/
* fdc9e444 - Remove warning for coreboot images build without a payload (4 weeks ago) <Nicholas Chin>
* f2e31767 - modify/u-boot: cleaner coding style (4 weeks ago) <Leah Rowe>
* 71cac866 - modify/coreboot: cleaner coding style (4 weeks ago) <Leah Rowe>
* 174d3af7 - modify/seabios: cleaner coding style (4 weeks ago) <Leah Rowe>
* c8dfc3cc - build/build/roms: simplify mkCoreboot() arguments (4 weeks ago) <Leah Rowe>
* d8a8a1c6 - build/boot/roms: don't use subshells frivilously (4 weeks ago) <Leah Rowe>
* 834be77c - build/boot/roms: remove errant debug line (4 weeks ago) <Leah Rowe>
* 39c14398 - build/boot/roms: simplify build_rom_images() (4 weeks ago) <Leah Rowe>
@ -407,37 +349,9 @@ on 13 June 2023)
* 67a607b8 - build/boot/roms*: RFC 2646 compliance (5 weeks ago) <Leah Rowe>
* 79939f2f - Add devicetree patch for E6400 with Nvidia GPU (5 weeks ago) <Nicholas Chin>
* 3f1ee015 - seabios: do normal config, disable oprom in vgarom (5 weeks ago) <Leah Rowe>
* 450f19bd - Merge pull request 'hp9470m: fix board name in smbios' (#57) from Riku_V/lbmk:master into master (5 weeks ago) <Leah Rowe>
|\
| * 15ad5a00 - hp9470m: fix board name in smbios (5 weeks ago) <Riku Viitanen>
|/
| * 8e378ee4 - (e6400nvidia_wip) dell/e6400nvidia: switch to "normal" config (5 weeks ago) <Leah Rowe>
| * a9f81e44 - Revert "Revert "coreboot/e6400nvidia: don't run vga rom"" (5 weeks ago) <Leah Rowe>
| * 499fa421 - seabios: do normal config, disable oprom in vgarom (5 weeks ago) <Leah Rowe>
| * 4ee5e2af - Revert "coreboot/e6400nvidia: don't run vga rom" (5 weeks ago) <Leah Rowe>
| * 2b2f5992 - coreboot/e6400nvidia: don't run vga rom (5 weeks ago) <Leah Rowe>
| * ba5a7cf9 - coreboot/e6400nvidia: debug level 8 (5 weeks ago) <Leah Rowe>
| * f8db8519 - Merge pull request 'Add devicetree patch for E6400 with Nvidia GPU' (#51) from nic3-14159/lbmk:e6400-nvidia into e6400nvidia_wip (5 weeks ago) <Leah Rowe>
| |\
| | * 9a7be395 - Add devicetree patch for E6400 with Nvidia GPU (5 weeks ago) <Nicholas Chin>
| * | 4e5fb60c - New board: Dell Latitude E6400 (Nvidia GPU model) (5 weeks ago) <Leah Rowe>
| | | * 4a6d2d2b - (wip_tianocore) wip tianocore (5 weeks ago) <Leah Rowe>
| |_|/
|/| |
* | | ee46c042 - update the makefile (5 weeks ago) <Leah Rowe>
|/ /
* | 5a197b4f - blobutil: support downloading E6400 VGA ROM (5 weeks ago) <Leah Rowe>
* | 0729d6e6 - Merge pull request 'Add patches for bios_extract' (#49) from nic3-14159/lbmk:master into master (5 weeks ago) <Leah Rowe>
|\|
| * 2e64f639 - Add patches for bios_extract (5 weeks ago) <Nicholas Chin>
|/
* ee46c042 - update the makefile (5 weeks ago) <Leah Rowe>
* f5150f26 - remove e6400_8mb and e6400_16mb (keep e6400_4mb) (5 weeks ago) <Leah Rowe>
* 6d0ff028 - Import new util: bios_extract (5 weeks ago) <Leah Rowe>
* f820e304 - add e6400_flash_unlock binary to .gitignore (5 weeks ago) <Leah Rowe>
* a52c9952 - Merge pull request 'Add fedora 38 other unifont dependencies' (#45) from MrArthegor/lbmk:master into master (6 weeks ago) <Leah Rowe>
|\
| * bc85118c - add fedora 38 unifont dependencies (6 weeks ago) <Arthegor>
|/
* f49eccee - util/e6400-flash-unlock: do void on ec_fdo_command (6 weeks ago) <Leah Rowe>
* 6588be67 - don't force console mode in grub (7 weeks ago) <Leah Rowe>
```

9
site/news/e6400.md
View File

@ -2,9 +2,8 @@
% Leah Rowe
% 19 April 2023
**UPDATE (9 May 2023): Libreboot confirmed working on variants such as
[E6400 XFR, and experiment Nvidia GPU variant support now
available](e6400nvidia.md).**
NOTE: This pertains to the Intel GPU variant. Nvidia GPU variants are
unsupported, for this class of machine.
Introduction
============
@ -24,9 +23,7 @@ and the [hardware info page](../docs/hardware/e6400.md).
---------------------
This is a *blob-free* board in the boot flash. No Intel ME firmware needed,
and [microcode can be removed if you wish](gm45microcode.md) (you should still
leave microcode there, as is default, but some people remove it by choice that
we give them - see: [Binary Blobs Reduction Policy](policy.md)).
and it boots without CPU microcode.
*But wait.* There's more. A lot more of *them*, that is.

5
site/news/e6400.uk.md
View File

@ -20,10 +20,7 @@ E6400 та [сторінці інформації про апаратне заб
------------------------------
Це є *вільною від блобів* платою в завантажувальній флеш-пам'яті. Прошивка Intel ME
не потрібна, та [мікрокод може бути видалено, якщо ви бажаєте](gm45microcode.md)
(вам варто досі залишати мікрокод там, як за замовчуванням, але деякі люди
видаляють його, з допомогою вибора, який ми даємо їм - дивіться:
[Політика Зменшення Бінарних Блобів](policy.uk.md)).
не потрібна, та [мікрокод може бути видалено, якщо ви бажаєте].
*Але почекайте.* Є більше. Набагато більше *цього*, так ось.

122
site/news/e6400nvidia.md
View File

@ -1,122 +0,0 @@
% Experimental Nvidia GPU support on Dell Latitude E6400 variants, plus E6400 XFR support now confirmed
% Leah Rowe
% 9 May 2023
<img tabindex=1 class="r" style="max-width:35%" src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /></span>
Introduction
============
[Dell Latitude E6400 *with Intel GMA 4500MHD* graphics](e6400.md) was added, and
included in Libreboot release 20230423 or newer. *Today*, [experimental
support](https://browse.libreboot.org/lbmk.git/log/?h=e6400nvidia_wip) is now
available for variants with GPU: Nvidia Quadro NVS 160M. The Dell Latitude 6400
XFR (rugged variant) was also tested today (Intel graphics) and confirmed
working in Libreboot as of release 20230423.
The *Nvidia* variants are *not* supported in Libreboot 20230423 or 20230625.
Support is available in an experimental branch of Libreboot. 6400 XFR
testing+photo provided, courtesy Mark Cornick (`mcornick` on Libreboot IRC).
Dell Latitude E6400 with Nvidia GPU
===================================
This section *also* applies to E6400 XFS and ATG models. [Testers are
needed!](../docs/maintain/testing.md).
*Some* models of Dell Latitude E6400 have Nvidia Quadro NVS 160M graphics
device, instead of Intel GMA 4500MHD. The *initial* Libreboot port of Dell
E6400 *only* supported models with Intel graphics, but experimental support
for Nvidia graphics now exists, in a WIP branch of Libreboot.
<img tabindex=1 class="l" style="max-width:25%" src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /></span>
The Libreboot documentation has been updated, to cover these models. Refer
to Dell Latitude E6400 documentation in Libreboot; specifically,
the [E6400 info page](../docs/hardware/e6400.md) and [E6400 flashing
guide](../docs/install/e6400.md).
Nicholas Chin, author of the original Dell E6400 port, has been helping me and
I've been working on this experimental branch of Libreboot under his
guidance:
* <https://browse.libreboot.org/lbmk.git/log/?h=e6400nvidia_wip>
*These* patches were already merged in Libreboot's master branch, which the
changes in the WIP branch rely upon:
* Import the `bios_extract` utilities in lbmk: <https://browse.libreboot.org/lbmk.git/commit/?id=6d0ff0286451dc43d32428a44a68d07bc13c058a>
* Bug fixes from Nicholas for `bios_extract`: <https://browse.libreboot.org/lbmk.git/commit/?id=2e64f6397556b7e6fff8a7a305a5eaa1095acfc1>
* blobutil: support downloading VGA ROM for Nvidia E6400: <https://browse.libreboot.org/lbmk.git/commit/?id=5a197b4ff160a348179a3350af266c6b87a3aa04>
Ongoing development discussion is available, on the Libreboot bug tracker. See:
* <https://codeberg.org/libreboot/lbmk/issues/14>
For more information about the *Nvidia GPU* variants, please review the
following pages (which have been updated, while publishing this news article):
* [Dell Latitude E6400 hardware information](../docs/hardware/e6400.md)
* [Dell Latitude E6400 flashing instructions](../docs/install/e6400.md)
Nouveau(in Linux) currently broken
----------------------------------
Nouveau is the libre driver in Linux, for Nvidia graphics. Nvidia themselves
do not provide binary drivers anymore, for these GPUs. It crashes in Linux,
when you try to start Xorg (Wayland is untested).
If you're booting an Nvidia variant in Linux, boot Linux with
the `nomodeset` kernel option at boot time. This means that graphics are
rendered in software.
Development discussion, for Nvidia variants of E6400, is available here:
<https://codeberg.org/libreboot/lbmk/issues/14>
OpenBSD's Nvidia driver works perfectly
---------------------------------------
OpenBSD 7.3 was tested, on my Nvidia-model E6400, and Xorg works OK with
the `nv` driver.
<img tabindex=1 class="l" style="max-width:35%" src="https://av.libreboot.org/openbsd.jpg" /><span class="f"><img src="https://av.libreboot.org/openbsd.jpg" /></span>
See: <https://www.openbsd.org/>
OpenBSD is a complete free 4.4BSD Unix operating system focused on portability,
security and *code correctness*. It's quite useable for most day to day tasks.
You can find information in Libreboot about BSD operating systems on the
main guide:
* [BSD Operating Systems](../docs/bsd/)
FreeBSD and newer Linux (e.g. Archlinux) untested!
--------------------------------------------------
[Testers needed! Please get in touch!](../docs/maintain/testing.html)
**At the time of writing this post, FreeBSD
and newer Linux have not yet been tested** (I plan to test *Arch Linux*), but
the older Linux/Mesa version in Debian 11.6 works just fine in the Dell BIOS,
and I've confirmed that it uses the exact same Video BIOS Option ROM.
Dell Latitude E6400 ATG model
-----------------------------
[Testers needed! Please get in touch!](../docs/maintain/testing.html)
We also found out about this model; it's another rugged design, assumed to
be the same board as regular E6400, but testing is needed. If it's anything to
go by, this model shares the same service manual as the regular E6400. If you
have this board, please [get in touch](../docs/maintain/testing.md)!
ATG is basically just a thicker chassis. It seems to use the same/similar
heatsink compared to E6400 XFR.
Were you expecting more?
Well, that's all for now.
Stay tuned for further development.

60
site/news/freedom.md
View File

@ -1,60 +0,0 @@
% What level of Software Freedom does Libreboot give me?
% Leah Rowe
% 20 March 2023
Quite a while ago, I [wrote a policy](policy.md) in Libreboot that defines,
precisely, the standards of what Libreboot will accept in releases as it
pertains to *[Software Freedom](https://writefreesoftware.org/)*. This policy
was written, because a *lack of
clarity* existed, so I wanted to make sure that people knew exactly what the
Libreboot project is all about, and what they can expect. It is essentially
a *manifesto*, describing the *ideology* of the Libreboot project.
Now, *ideology* is all well and good, but it must be translated into something
concrete that exists in the real world. You can't get there with thought!
Today, I published a follow-up article that defines how the policy
is *implemented* in practise. There has been some confusion among some members
of the community, about what the policy means in practise.
Refer here to the new article, thus:
[Software and hardware freedom status for each mainboard supported by
Libreboot](../freedom-status.md)
The article describes, in great detail, the current status of licensing for
various components of Libreboot. It is the *goal* of Libreboot to promote
*[software freedom](https://writefreesoftware.org/)*, helping as many people as
possible achieve a level of
sovereignty in their personal computing, reducing (or eliminating) the power
that proprietary software developers would otherwise have over them. Libreboot
makes great strides to provide *boot firmware*, based on coreboot, with as much
libre *source code* as possible. It is the goal of the Libreboot project to
help bring about a world where software freedom is the *default* for everyone.
I hope that the article clears up any confusion, and I'm open to questions if
people have any. My info is on the contact page, or you can find me as `leah`
in the `#libreboot` channel on libera IRC.
The article will be maintained over time, to reflect the status of Libreboot.
PS:
Also, a new version of Libreboot was *released* yesterday. See:
[Libreboot 20230319 release announcement](libreboot20230319.md)
It made several major fixes, and massively updated the revisions for each
part used in ROM images (containing coreboot, GRUB and SeaBIOS).
I have a bunch of mainboards that I'm working on, and I hope to make another
release available as soon as possible. My priority for the next Libreboot
release is to add as many new boards as possible from coreboot, with minimal
changes to the build system itself; another focus this time is on improvements
to the documentation. Several installation guides are missing, for example, on
specific mainboards.
Specifically, I have focus on some AMD platforms, Intel sandybridge/ivybridge,
Intel Haswell and (more) GM45 platforms. Several boards exist in coreboot that
are viable to be added, both under the *current policy* and adhering to the
current *freedom status* in how the policy is implemented.

125
site/news/gm45microcode.md
View File

@ -1,125 +0,0 @@
% GM45 no-microcode bug mitigations re-added (ThinkPad X200, T400 etc)
% Leah Rowe
% 17 April 2023
[Libreboot releases after 20230423 will provide separate ROMs with microcode
excluded, alongside default ROMs that include microcode](microcode.md).
UPDATE: This also applies to the Dell Latitute E6400 port, added on 19
April 2023 to Libreboot. See: [E6400 announcement](e6400.md)
The change described in this article is *not* present in Libreboot 20221214,
20230319 or 20230413 - **UPDATE: [Libreboot 20230423 is out, and includes
this change on all GM45 targets](libreboot20230423.md)**
If you want a no-microcode setup, either [build the
latest Libreboot from source via lbmk](../docs/build/) and remove the microcode
updates using the instructions on this page, *or* if you need pre-built ROM
images, Libreboot 20220710 had no-microcode ROMs by default and it has the
mitigation patches described by this article.
Introduction
============
Microcode updates provide stability and security fixes, using the files
provided by coreboot, which are assembled at boot time. CPUs have microcode
in them which configures the logic gates that implement an instruction set
architecture (the x86/x86\_64 architecture), and CPUs provide a *volatile*
mechanism for hot-patching it at boot time, which coreboot makes use of.
Libreboot *includes* CPU microcode updates *by default*, on all x86 hardware.
This *includes* boards that it supported prior to the new policy enacted last
year; before the policy change, Libreboot *excluded* these updates (but the
code for loading them *was retained*, so you could manually add them yourself
if you wanted to). Adding and removing them can be done by coreboot, at build
time, or you can add/remove them from the compiled ROM image by
running `cbfstool`; you can learn how to add/remove microcode updates here:
[How to add/remove microcode on coreboot images](../freedom-status.md#intelx86)
You can learn *why* they're needed, and about microcode in general, by reading
the [Binary Blobs Reduction Policy](policy.md) - it is a pragmatic policy,
enacted on 15 November 2022 with a view to supporting as *much* hardware as
possible from coreboot, reducing or eliminating binary blobs in the boot
flash and mitigating any issues that arise - for example, Libreboot makes use
of `me_cleaner` on some newer Intel platforms. You can read more about how the
policy is executed by reading the [Freedom Status](../freedom-status.md) page.
I've received some feedback about this, specifically by users of GM45-era
ThinkPads (X200, T400, T500, W500, R500, R400, X301, X200S/X200T, T400S and
R500). On *those* machines, if you [remove microcode
updates](../freedom-status.html#intelx86), it would break SpeedStep (CPU
frequency scaling) and the machine won't *reboot* properly (turning off and on
would work). Additionally, the machine would crash on lots of I/O (CPU cycles
and memory usage), due to a *Machine Check Exception* state leading to kernel
panic in your operating system; this last issue does not have a known fix,
except to update the microcode (which newer Libreboot releases do, by default).
Libreboot contained mitigations for broken SpeedStep/reboot, in older releases,
but it was decided that these mitigations would be *excluded* from the new
releases which include microcode updates by default; why mitigate a problem
that no longer exists in Libreboot?
Why indeed.
Mitigations patches restored!
-----------------------------
*I've restored these mitigations to Libreboot, as of today.*
The patch re-adding these mitigations can be seen here:
<https://browse.libreboot.org/lbmk.git/commit/?id=bd4ea9a02845b22a09b73ebb015ce134234d100b>
Why?
----
Free choice, that's why. We don't lecture anyone. We just help people.
One aspect of Libreboot policy is that Libreboot must be *configurable*. In
practise, some users want to remove microcode updates regardless of the
problems that it would cause. Even if I disagree with their reasoning, I
respect their decision and this change is designed to accomodate them.
in practise, such users had a choice before but they currently do not, in
recent Libreboot releases. This criticism was raised with me, and I've taken
it to heart. Therefore, users now have a choice; they always did, but remember:
Libreboot is aimed at non-technical users. Libreboot needs to be usable by
them. It needs to *work*. It *does* work, very well, when microcode updates
are included, as they are by default these days. This patch is about harm
reduction, to at least smooth things over for a small handful of users who
decide to remove microcode updates (as is their choice).
This change, today, fixes a practical violation of Libreboot policy by once
again restoring such practical choice to the user. It is already said how to
do so elsewhere, but I'll repeat it here in this news article for posterity:
How to add/remove microcode updates from ROM
--------------------------------------------
Extract to file on disk:
cbfstool libreboot.rom extract -n cpu_microcode_blob.bin -f cpu_microcode_blob.bin
Remove:
cbfstool libreboot.rom remove -n cpu_microcode_blob.bin
Add (if not present):
cbfstool libreboot.rom add -f cpu_microcode_blob.bin -n cpu_microcode_blob.bin -t microcode
The `cbfstool` program can be compiled from `util/cbfstool/` in the coreboot
Git repository. In all recent Libreboot releases, you can find it
under `coreboot/default/util/cbfstool/`.
Regardless, the mitigations are largely harmless and so, I've restored them.
They are now included once again, in the Libreboot git repository and they
will be available in ROM images when the next release comes out.
I'll probably re-work the mitigation patch at some point, probably before the
next release, so that the mitigations are only applied if microcode updates
are absent. This would be checked for during machine initialisation, by
modifying the current patches accordingly.
That is all.

66
site/news/hp8200sff.md
View File

@ -1,66 +0,0 @@
% HP Elite 8200 SFF support added to Libreboot (plus more desktops coming soon)
% Leah Rowe
% 15 April 2023
Introduction
============
Today, Libreboot gains its *first* desktop machine for nearly 2 years. The
last one added was Acer G43T-AM3.
You can learn more about this on the [HP Elite 8200 SFF Libreboot installation
and hardware information page](../docs/hardware/hp8200sff.md).
The patch for Libreboot was done, courtesy of Riku Viitanen, IRC nick `Riku_V`
on Libreboot IRC. It's quite a nice Intel Sandybridge platform, with all libre
initialisation on the coreboot side, and Libreboot's build system automatically
runs `me_cleaner` while building for this board.
This board is significant because it's relatively simple to flash, cheap, and
readily available on merchant sites such as eBay. Desktop support has
traditionally been much weaker in Libreboot, and this is something that
should (can, and will) change.
HP EliteBook 2560p (laptop)
------------------
Riku is also interested in adding HP EliteBook 2560p support in Libreboot.
Coreboot has support for that board. For *that* board, I committed this
patch in a branch of Libreboot, to make handling EC firmware easier for Riku:
<https://browse.libreboot.org/lbmk.git/commit/?h=blobutil_kbc1126_ec&id=b9ee4e79c33365ede01fb7d2a0d5c8f3c1a1928c>
I initially wrote the logic in that patch as part of another experimental
branch of Libreboot, adding HP Elitebook 8560w (does not boot yet).
If my EC download script works for Riku, and 2560p support confirmed working
when Riku tests it, then both of them shall by merged into Libreboot's master
branch. The EC firmware is not on a separate IC, for that machine; instead,
it must be handled during the coreboot build process, for insertion into the
main boot flash. This is actually *better*, for similar reasons as explained
in the Libreboot [blobs reduction policy](policy.md), because it makes the EC
firmware easier to replace with libre code (based on reverse engineering,
perhaps).
Dell Optiplex 7020/9020 probably soon (testing needed)
-------------------------------------
I've purchased Dell Optiplex 7020 and 9020 workstations (Haswell gen), which is
available for coreboot with this gerrit patch:
<https://review.coreboot.org/c/coreboot/+/55232/>
Libreboot will eventually support *all* coreboot targets.
Want to help add boards yourself?
---------------------------------
Libreboot has the following documentation available:
* [lbmk maintenance manual](../docs/maintain/) (build system documentation)
* [porting guide](../docs/maintain/porting.md) (largely Intel-centric, at
the time of writing this post)
Riku's work was inspired by reading these. The guides themselves are also in
need of constant maintenance and improvement, relative to the changes in
Libreboot.

66
site/news/hp8200sff.uk.md
View File

@ -1,66 +0,0 @@
% Підтримка HP Elite 8200 SFF додана до Libreboot (плюс більше десктопів скоро)
% Лія Роу
% 15 квітня 2023 року
Вступ
============
Сьогодні, Libreboot отримує його *першу* настільну машину за майже 2 роки.
Останнім доданим був Acer G43T-AM3.
Ви можете вивчити більше про це на [сторінці встановлення Libreboot та інформації
апаратного забезпечення HP Elite 8200 SFF](../docs/hardware/hp8200sff.md).
Виправлення в Libreboot було зроблено, ввічливість Ріку Війтанен, нікнейм IRC `Riku_V`
на Libreboot IRC. Це доволі добра платформа Intel Sandybridge, з усією вільною
ініціалізацією на стороні coreboot, та система побудови Libreboot автоматично
виконує `me_cleaner` під час побудови для цієї плати.
Ця плата є значущою, тому що вона відносно легка для прошивки, дешева, і
готова на торговельних сайтах, таких як eBay. Настільна підтримка була
традиційно набагато слабішою в Libreboot, і це щось, що має
(може, і буде) змінюватися.
HP EliteBook 2560p (ноутбук)
------------------
Ріку також зацікавлений в додаванні підтримки HP EliteBook 2560p в Libreboot.
Coreboot має підтримку для тієї плати. Для *тієї* плати, я зробила commit цього
виправлення в гілку Libreboot, щоб зробити керування прошивкою EC легше для Ріку:
<https://browse.libreboot.org/lbmk.git/commit/?h=blobutil_kbc1126_ec&id=b9ee4e79c33365ede01fb7d2a0d5c8f3c1a1928c>
Я спочатку написала логіку в тому виправленні, в якості частини іншої експериментальної
гілки Libreboot, додаючи HP Elitebook 8560w (ще не завантажується).
Якщо мій сценарій завантаження EC працює для Ріку, та працездатність підтримки
2560p підтверджується, коли Ріку випробує її, тоді обидва з них буде злито в
гілку master Libreboot. Прошивка EC не на окремій інтегральній мікросхемі, для цієї
машини; натомість, вона має буде керованою протягом процесу побудови coreboot, для
вставки в головну завантажувальну флеш-пам'ять. Це насправді *краще*, з подібних
причин, як пояснено в [політиці зменшення блобів](policy.uk.md) Libreboot, тому що
це робить прошивку EC легшою для заміни на вільний код (заснований на зворотній
розробці, мабуть).
Dell Optiplex 7020/9020 можливо скоро (потребує випробування)
-------------------------------------
Я купила робочі станції Dell Optiplex 7020 та 9020 (покоління Haswell), що
доступно для coreboot з цим виправленням gerrit:
<https://review.coreboot.org/c/coreboot/+/55232/>
Libreboot в певний момент буде підтримувати *всі* цілі coreboot.
Хочете допомогти додати плати самостійно?
---------------------------------
Libreboot має наступну документацію в наявності:
* [керівництво обслуговування lbmk](../docs/maintain/) (документація системи побудови)
* [керівництво перенесення](../docs/maintain/porting.uk.md) (в основному Intel-центричне, на
момент написання цієї публікації)
Роботу Ріку надихнуло читання їх. Самі керівництва також потребують
постійного обслуговування та покращення, відповідного до змін в
Libreboot.

38
site/news/hp_elitebooks.md
View File

@ -1,38 +0,0 @@
% HP EliteBook 2560p and Folio 9470m support added to Libreboot
% Riku Viitanen
% 23 April 2023
Introduction
============
![Two HP EliteBooks side by side, both running Libreboot](https://av.libreboot.org/hp9470m/9470m+2560p.jpg)
Support for [HP EliteBook Folio 9470m](../docs/hardware/hp9470m.md) and
[HP EliteBook 2560p](../docs/hardware/hp2560p.md)
has now been merged into Libreboot. These are very nice Sandy/Ivy
Bridge laptops. Libreboot's build system now builds coreboot automatically
for them, making it simple to install libre firmware on these laptops and
take control of your own devices. Check out the links above for more details,
including installation details.
Additionally, a [long-standing bug](https://browse.libreboot.org/lbmk.git/plain/resources/grub/patches/0005-at-keyboard-timeout.patch?id=6ff0284a510e8d7a8721dd769ba6a773610c2cad)
with GRUB on coreboot now has a functional workaround
which is applied automatically by Libreboot.
More to come
------------
Leah Rowe has recently been on a buying spree, so more Sandy/Ivy Bridge and
Haswell EliteBooks are making their way to Libreboot soon. Libreboot's goal
is to eventually support everything coreboot does.
Do you want to help add new boards yourself? You totally could give it a try,
it's fun! The Libreboot [developers](https://libreboot.org/contact.html)
are very welcoming too.
Check these documents out:
* [lbmk maintenance manual](../docs/maintain/) (build system documentation)
* [porting guide](../docs/maintain/porting.md) (largely Intel-centric, at
the time of writing this post)

558
site/news/libreboot20221214.md
View File

@ -1,558 +0,0 @@
% Libreboot 20221214 released!
% Leah Rowe
% 14 December 2022
The last Libreboot release, version 20220710, was released on 10 July
in 2022. *This* new release, Libreboot 20221214, is released today on December
14th, 2022. This is intended to be a *testing* release.
This is marked as a *testing* release, but most/all boards should be fairly
stable.
**PLEASE READ THIS BEFORE INSTALLING:
[Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell](safety.md)**
READ THIS BEFORE FLASHING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)**
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
Build from source
-----------------
*This* release was build-tested on Debian 11. Your mileage may vary, with
other distros.
Work done since last release
============================
For more detailed change logs, look at the Git repository. This is
a summary of changes.
New boards, x86
----------
This list *may not be complete*, but it is as follows:
* ASUS p2b\_ls/p3b\_f added, for testing with [PCBox](https://pcbox-emu.xyz) -
these ROM images achieve perfect raminit and jump to payload in the emulator,
but VGA ROM initialisation does not yet work.
* QEMU (arm64 and x86\_64) images added, for testing payloads and so on.
* lenovo/t430 (thinkpad)
* lenovo/x230 (thinkpad)
* lenovo/x230edp (e.g. nitrocaster FHD mod kit)
* lenovo/t440p (thinkpad)
* lenovo/w541 (thinkpad)
* lenovo/x220 (thinkpad) (also works with x220 tablet)
* lenovo/t420 (thinkpad)
* lenovo/x230 tablet (thinkpad)
GA-G41M-ES2L ROMs
------------
GA-G41M-ES2L ROM images are back, but your mileage may vary. Only the
SeaBIOS payload is enabled, on this board.
No lbmk changes were done for this, because the ROMs were simply excluded
in the previous release, but this board was not deleted from lbmk.
**UPDATE ON 20 December 2022: per many user reports, these ROMs work very
well. GA-G41M-ES2L support is therefore stable, for all intents and purposes.
This section of the release announcement previously alluding to issues, but
those speculations were premature, based on limited prior testing.**
New boards, ARM
----------
NOTE: These boards use u-boot payload, instead of depthcharge.
* Samsung Chromebook 2 13" (peach-pi)
* Samsung Chromebook 2 11" (peach-pit)
* HP Chromebook 11 G1 (daisy-spring)
* Samsung Chromebook XE303 (daisy-snow)
* HP Chromebook 14 G3 (nyan-blaze)
* Acer Chromebook 13 (CB5-311, C810) (nyan-big)
* ASUS Chromebit CS10 (veyron-mickey)
* ASUS Chromebook Flip C100PA (veyron-minnie)
* ASUS Chromebook C201PA (veyron-speedy)
* Hisense Chromebook C11 and more (veyron-jerry)
* ASUS Chromebook Flip C101 (gru-bob)
* Samsung Chromebook Plus (v1) (gru-kevin)
These ARM boards are all Chromebooks.
This work on the Chromebooks and u-boot integration is courtesy
of Alper Nebi Yasak (`alpernebbi` on libreboot IRC).
In these configurations, u-boot is a *payload of coreboot*.
Removed boards
--------------
ASUS KGPE-D16, KCMA-D8 and KFSN4-DRE are removed, because raminit
never worked reliably on these boards to begin with and they were
barely maintained anymore. Use an older release of Libreboot, if
you still want to use these boards.
lbmk Git changes
------------
These are takes from the git log of `lbmk.git`:
```
* c6bb4d25 (HEAD -> master, tag: 20221214, srht/master, origin/master, notabug/master) build/release/src: don't delete .gitcheck
* 0fbf3325 correct a faulty if statement in build/release/src
* ab2cfb86 util/nvmutil: only mask random unicast/local macs
* fea3e51c update the readme
* 664cdcfb fix ./build boot roms all
* 48c73186 p2b_ls/p3b_f boards: Disable memtest payload
* 31111c64 build/boot roms: add exits for failing commands
* 4eba525b p2b_ls/p3b_f boards: no payload and no vga init
* c931b40e Merge branch 'master' of qeeg/lbmk into master
|\
| * 6351a4a4 Add P2B-LS and P3B-F configs
* | 34a56281 Merge branch 'cros-postmerge-fixes' of alpernebbi/lbmk into master
|\ \
| * | f079b83d build/release/src: Include U-Boot sources in source archive
| * | 70435784 build/clean: Add helper script to clean U-Boot builds
| * | 0bd4fdbe dependencies/debian: Install dependencies for U-Boot
| * | 3d5bd034 coreboot: Add qemu_arm64_12mb board
| * | d14731be u-boot: Add qemu_arm64_12mb board
| * | b5a5801f coreboot: qemu_x86_12mb: Enable DRIVERS_UART_8250IO
| * | 737573ce u-boot: Add qemu_x86_12mb build
| * | 1c62b003 build/roms: Support using "u-boot" ELF file as U-Boot payload
| * | 6cabcec5 u-boot: Add video damage tracking patch series
| * | 38328b93 u-boot: Set default revision to v2022.10
| * | c798975d u-boot: Use a common tree
| * | 5b6bf2a8 build/roms: Don't rebuild crossgcc if it was already built
| * | bee50540 build/roms: Make coreboot crossgcc usable for payloads and modules
| * | a5863561 build/roms: Build 32-bit crossgcc for AArch64 as well
| * | 9fb4ecec build/roms: Don't build Memtest86+ when not specified by cmdline
| * | 4e3097b5 build/roms: Disable U-Boot when not in payloads specified by cmdline
| * | 584210bd download/u-boot: Change to download target before running extra.sh
| * | 2b761f2f download/u-boot: Re-add usage text for no-argument form
| * | 71cf7f9d download/u-boot: Remove support for deleting git folders
| |/
* | b495aa09 util/nvmutil: consistent parentheses on comparison
* | 17fa25e5 util/nvmutil file reads: skip reading if errno!=0
* | 27876c64 util/nvmutil: return error when fstat() is -1
|/
* 960af2d6 util/nvmutil: rhex(): fail if errno not zero
* 3d01cf28 util/nvmutil: minor code formatting cleanup
* a7ea70c7 build/release/roms: delete ME/MRC firmware in ROMs
* 0c334380 build/boot/roms: remove errant code
* 33bbb36d remove errant detail from comment
* 55869474 delete build/release/u-boot-libre
* 137b5434 remove logic for avoiding nonredistributable blobs
* 7679c8e0 coreboot/default: add --nuke flag to ifdtool
* a5e4416a util/nvmutil: remove errant line break
* c100dd1f util/nvmutil: missing paretheses on if statement
* 036d7107 util/nvmutil: don't initialise rbuf unless needed
* 851892b4 util/nvmutil: rename variable in hextonum
* 0bf3f1ed util/nvmutil: don't reallocate memory in hextonum
* e5a46b46 util/nvmutil: dont report bad size if /dev/urandom
* ededa5dd util/nvmutil: rename variables in hextonum
* e2e321fc util/nvmutil: use BUFSIZ for rmac size in hextonum
* a6d0112d util/nvtutil: fix out of bounds error
* 04ced693 update the README
* 85937f3f util/nvmutil: reset errno on cmd_swap
* ec082429 scripts: avoid relying on spaces from sha1sum output
* 7c5334ca Merge branch 'hide-mei' of XRevan86/lbmk into master
|\
| * 69eaca2c coreboot: hide MEI on neutered-ME targets
|/
* cf052220 Merge branch 'master' of Arsen/lbmk into master
|\
| * a40ba4ad t430_12mb: Add, based on x230_12mb
* | 0c5dfddd Merge branch 'x230edp' of XRevan86/lbmk into master
|\ \
| |/
|/|
| * a33e8429 coreboot: add x230edp_12mb, remove x230fhd_12mb
|/
* e8eee6dd util/nvmutil: mild refactoring
* 342e5abe util/nvmutil: improved errno handling in main
* d7465efb util/nvmutil: put hextonum in its own function
* 9e5ff5e4 util/nvmutil: move ENOTDIR check to function
* ff88cb1a util/nvmutil: further improved errno handling
* b81b51f9 util/nvmutil: remove errant code
* a94bac81 util/nvmutil: improved error handling
* 55a951a7 util/nvmutil: fix off by one bug
* 0108615f nvmutil copy/swap: actually set nvmPartModified
* 82300f4f util/nvmutil: move cmd copy to own function
* ddf3b76c util/nvmutil: move cmd swap to own function
* c2ed251c util/nvmutil: move cmd brick to own function
* eaad16ed util/nvmutil: cmd setchecksum in own function
* cea1beea util/nvmutil: split "dump" into smaller functions
* 59e4f560 Merge branch 'dev' of shmalebx9/lbmk into master
|\
| * 99652baa fix injection script
| * 175b48a4 added more checks and optimised extraction script
| * b2c71747 make gitcheck verify coreboot subdir
| * 1246c3ad add smort failures to blob download script
* | 0ae00e88 util/nvmutil: re-factor to reduce code indentation
* | 0bbd4f1f util/nvmutil: write gbe files in a function
* | b0f9f47e util/nvmutil: human-friendly exit messages, part 2
* | e35a33d5 Merge branch 'qemu' of shmalebx9/lbmk into master
|\ \
| * | da155b3d added x86 qemu board based on x230 coreboot config
* | | e1bbdadc build/roms: remove seabios_grubfirst logic
| |/
|/|
* | 7629dfb8 remove duplicate patch causing build error
|/
* ca45a60f bump grub revision to latest upstream
* c1c76a05 dependencies/arch: notice about unifont dependency
* 43196abc also fix crossgcc on cros/fhd coreboot trees
* f0631908 cros devices: use a common coreboot tree
* 24a866ba remove kfsn4-dre, kcma-d8 and kgpe-d16
* f5b4eb3f update gitignore
* 60793c55 fix gnat build issue on coreboot repositories
* 6114c349 add innoextract to federa dependency script
* 5ec5d0ea ditto others
* 551e845e ditto debian script
* f896bb84 remove stupid flags from arch dependency script
* 5a01e98d build/dependencies/*: remove python2
* 6c12afa9 util/nvmutil: more human-friendly exit messages
* 50174563 fix part 1 checksum in t440p gbe.bin
* a7b8d0cf update .gitignore
* b3b3642f assimilate nvmutil
* 8740404e make background splash screen purple
* 3f12ef85 bonerfix
* cf945dda blobs/inject: use nvmutil, not nvmutils
* 2589d367 update the README
* 7af99534 (tag: psdg) pragmatic system distribution guideline compliance
* b5c25efe Merge branch 'u-boot-chromebooks' of alpernebbi/lbmk into master
|\
| * 61ac6c3f u-boot: Add peach pi chromebook configs
| * f848eb81 coreboot: Add peach pit chromebook configs
| * e08e3da2 u-boot: Add peach pit chromebook configs
| * 8584fcc1 coreboot: Add spring chromebook configs
| * f9f5d5fc u-boot: Add spring chromebook configs
| * 2dcb7cab coreboot: Add snow chromebook configs
| * be8bebaa u-boot: Add snow chromebook configs
| * c97f8e5c coreboot: Add nyan blaze chromebook configs
| * 330f985d u-boot: Add nyan blaze chromebook configs
| * ddc695a2 coreboot: Add nyan big chromebook configs
| * 0d696ee3 u-boot: Add nyan big chromebook configs
| * 2e0f13d9 coreboot: Add veyron mickey chromebit configs
| * 330c62ae u-boot: Add veyron mickey chromebit configs
| * f84209ce coreboot: Add veyron jerry chromebook configs
| * fc7794a1 u-boot: Add veyron jerry chromebook configs
| * bbba94ed coreboot: Add veyron minnie chromebook configs
| * bc47f8cc u-boot: Add veyron minnie chromebook configs
| * 2ed1111d coreboot: Add veyron speedy chromebook configs
| * fa553566 u-boot: Add veyron speedy chromebook configs
| * 0ae23980 coreboot: Add bob chromebook configs
| * ff39bba2 u-boot: Add bob chromebook configs
| * af46cbff coreboot: Add kevin chromebook configs
| * 38655635 u-boot: Add kevin chromebook configs
| * 6d6bd5ee build/roms: Rebuild cbutils module before starting coreboot build
| * 61ede998 build/roms: Support using U-Boot as a coreboot payload
| * a69855f7 build/roms: Build 32-bit crossgcc for AArch64 as well
| * 769f18f2 build/roms: Fix building for ARMv7 and AArch64 boards
| * 9bfbdb59 scripts: Add helpers to modify and update U-Boot configs
| * 1dc05e40 build/payload: Add helper script to build U-Boot as payload
| * cf295741 download: Use shallow clones for big projects
| * ef39e05b download: Allow keeping .git dirs with NODELETE=git
| * 764a439a u-boot-libre: Add support for deblobbing U-Boot v2022.07
| * 270272eb download/u-boot: Remove .git folders as well
| * 820b8e70 download/u-boot: Support running extra commands from board dirs
| * eae6b35d download/u-boot: Support applying patches from board dirs
| * 454364cc download/u-boot: Try to update submodules as in coreboot script
| * 0aeb69b5 download/u-boot: Use GitHub mirror as fallback
| * 7b552bd2 download/u-boot: Support reading tree and revision from board.cfg
| * 8dd1a245 download/u-boot: Prepare files per board instead of per revision
| * d8da9b51 .gitignore: Ignore u-boot directory
| * 22b1db69 u-boot-libre: Set tar mtime to SOURCE_DATE_EPOCH or @0
| * 01f61263 u-boot-libre: Fix releasing blob list as deblob script
| * 89a4c2c6 u-boot-libre: remove nonfree firmware in drivers/dma/MCD_tasks.c
| * f679fbd3 u-boot-libre: Fix reproducability issue due to timezone
```
osbmk Git changes
-------------
It's important to show the osboot changes aswell. Osboot only became part of
Libreboot last month, but the "reboot" of the osboot project happened around
the start of 2022, when it was put back in sync with Libreboot at the time,
so changes from then to now will be showed. The *last* change in osboot as
shown below is the revision that got merged with lbmk:
To be more clear: on 19 December 2021, osboot got nuked and re-forked from
scratch, relative to Libreboot, so the earliest revisions in the log below
are Libreboot from that time (forked from lbmk
revision `c3a66c32750fa4a9a90ddb6383b09fdfb6ff77f5`), so this is actually
a full list of all osboot-related changes that became part of Libreboot
in the osboot/libreboot merge last month:
(some of them are identical changes to lbmk, because efforts *were* made at
the time to keep osboot/libreboot in sync, before it was decided that they
would simply merge)
```
* c8c030b (HEAD -> master, origin/master, origin/HEAD) fork lbmk 61ac6c3f0b26deadc2fb8355a8dd0d25b29baacd
* eef6b71 clean up the download script
* 1d2f9e8 Merge branch 'finetune' of shmalebx9/osbmk into master
|\
| * bd4f1b4 added fine-tuned control for building roms
* | 55e5d92 Merge branch 'gitframework' of shmalebx9/osbmk into master
|\ \
| * | a6e5c87 added internal git package management
* | | 4b424a8 Merge branch 'master' of anjan/osbmk into master
|\ \ \
| * | | 7a444dc debian dependencies: add python-is-python3
| |/ /
* | | 7728a98 lenovo/w541: new board added
* | | d05ab33 re-do x220 configs
* | | ad68c8c add lenovo/t520
* | | 7979263 add lenovo/t420s
* | | 3e20a41 build/roms: remove unnecessary bloat
* | | a18e962 build/roms: fix missing cbfstool bug
* | | 74ef993 re-do x230 fhd configs
* | | b1b481d fix build issues with x230 fhd
* | | 3472940 actually add the x230 fhd patch
* | | 3106501 script/blobs: check to download *default* coreboot
* | | 81b4ff7 Re-add X230 FHD patches
| |/
|/|
* | 83c230b add t440p config with 4mb cbfs
|/
* 31fbee4 make only the logo darker, in grub backgrounds
* 5e2da8f update build/release/src based on osbmk changes
* 00707ea say the name osboot, in the grub menu
* 56bb8a8 add bootsplash with new logo
* 675db3d Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * 2098cfa initialize git if it isn't already
| * d4690d0 updated gitignore for new dependencies and blobs
* | e43a28c Merge branch 'dev' of shmalebx9/osbmk into master
|\|
| * 5139ad4 added myself as a license holder to changes in last commit
| * 327a39e added workaround for git credentials
|/
* b079a19 patch me_cleaner to specifically use python3
* 5cc10a7 specifically call python3, in scripts
* 91b6542 fixed b0rked descriptor
* ca8d824 added myself as a license holder to various scripts
* aaeba81 removed obselete entries from blob sources
* 2a11133 hardcoded paths to redistributable blobs
* 4e2bd46 updated blobutil scripts to deal with hardcoded paths
* 4ca4801 Perform the silentoldconfig step of seabios before full make
* 1c921b5 new board: lenovo/x230t_16mb
* 335f95c add missing board.cfg for x230_16mb
* c4a705e set regions read-write on xx30/ifd.bin
* cafb408 Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * 7c7d96e Download script can tell whether to pull 16mb ifd
| * 999331d added x230_16mb
* | c437778 x230/x220: don't set CONFIG_HAVE_EM100_SUPPORT=y
* | dfeb26c fix txtmode configs: me/ifd/gbe insertion not enabled
|/
* 6390a90 nuke boards/x230_truncated_16mb for now
* 174f6c2 disable CONFIG_HAVE_EM100_SUPPORT on boards
* 8b698a4 new board: lenovo/x230t
* ac790ee update nvmutils
* 79e94d7 Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * 55d44bc added licenses just in case
|/
* 3171b91 Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * cba24e8 fix txtmode config for t440p
| * 55d6503 changed build system for new blobutil
| * 1462a3c move all blobs scripts to one directory
* | 84a9d53 update flashrom
* | cda2d70 reset nvmutils to known good revision
* | 65b62c0 exit if can't download nvmutils
* | 12c9fd2 coreboot: set me_state=Disabled on all boards
* | 7ef3b88 Merge branch 'dev' of shmalebx9/osbmk into master
|\|
| * d78c65e added t440p blobs
* | 8e7b3c3 Merge branch 'dev' of shmalebx9/osbmk into master
|\|
| * bc91ff2 fixed breaking bug in blobs downloader
|/
* 95ae701 enable CONFIG_PCIEXP_HOTPLUG on all boards that support it
* 75a9f00 Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * ae0b95a added t420
* | 8971e0d Merge branch 'dev' of shmalebx9/osbmk into master
|\|
| * b3081fc better error handling
| * e59a546 updated blob injector to give option to change mac
| * 563d0de made blob downloader save blobs under board_short no matter what
|/
* 5d5746f Merge branch 'dev' of shmalebx9/osbmk into master
|\
| * 68533c6 removed hardcoded tmp files
| * 7fc071b added blob injector for binary releases
| * 3457579 added release infrastructure
|/
* 71f6936 Merge branch 'master' of shmalebx9/osbmk into master
|\
| * 938bd04 switch x230 config back to 12mb cbfs size
| * b69d4fa Added dependencies for automatic blob extraction
| * 0829f5b added x220 support
| * 1f4e6d7 added ifd and gbe for xx20 and xx30 boards
| * b933bff Added the scripts for automatically downloading blobs
|/
* 489f2ee memtest86+: fix build error (patch from Félicien Pillot)
* 240779a lenovo/x230: fix build
* f6cffa0 Merge branch 'master' of shmalebx9/osbmk into master
|\
| * fa8e5fa switched back to the old way of downloading the mrc
| * 831d8f3 added t440p rom as an example of a rom needing the mrc
| * cf479fd added a simpler version of the old mrc download script. This one just uses the default coreboot way of extracting it using the included script, so it will always be up to date
| * 7fdfb07 added ability to detect if the board needs the mrc and download it
| * b8bd895 added mrc download script from old osbmk but changed to agnostic shebang
| * d80bcfb added x230 coreboot config as an example of a config using the blobs extracted with the extraction script
| * d40b01c add script to extract blobs from the vendor rom image for ivy bridge lenovo boards. Could possible work/be extended for other mainboards
| * c3dfcf4 re-add me_cleaner and change to agnostic shebang
* | f70c5cc lenovo/x230: set me_state=Disabled in cmos.default
* | 9b4afd1 x230_12mb: set cbfs back to 7mb. i will add special truncated configs instead
* | d39da96 rename x230_16 to x230_truncate_16mb
|/
* baf4fd4 Revert "lenovo/x230: set me_state=Disable in cmos.default"
* 4828eb0 new cfg: lenovo/x230_16mb: 16MB-128KB CBFS size for truncated ME
* 1334dd5 lenovo/x230: set config 12MB-128KB cbfs size for truncated ME
* ecb98cc lenovo/x230: set me_state=Disable in cmos.default
* 3a5d399 1MB coreboot config: don't enable grub_withseabios
* 19d2cda optimize grub modules: pre-load ones that will likely be used
* d7e5a08 build/boot/roms: fix wrong variable name
* 81330c6 coreboot/*: set grub_scan_disk to ahci on most boards
* 99f58d8 apple/macbook21: set grub_scan_disk to ahci
* 17830a4 build/boot/roms: substitute grub_scan_disk according to board.cfg
* f222519 grub.cfg: skip ata/ahci according to grub_scan_disk
* defe338 grub.cfg: clean up messages, be less verbose
* 1fa0e53 grub.cfg: add isolinux menuentry for ata* (replace broken cd/dvd menuentry)
* e33645a grub.cfg: delete option to boot from CD/DVD
* b370cd1 grub.cfg: clean up comments
* 81f3755 grub.cfg: don't use */? wildcards. they slow down the boot
* 6a315b6 grub.cfg: optimize search_isolinux
* ccc7aed remove entry in .gitignore from the last commit
* f84d09b Fix grub's slow boot
* 6ffbcee rename README to README.md
* 47155b3 lenovo/x230: re-add support from coreboot
* 82f381b do full coreboot checkout. enable microcode updates. don't delete blobs
* 6afa56e rename project back to osboot and delete grub background
* 8614ee7 assimilate lbmk c3a66c32750fa4a9a90ddb6383b09fdfb6ff77f5
```
Known issues
============
Intel ME firmware missing in ROMs that need it
----------------------------------------------
If you compile ROM images with lbmk directly, the build system
automatically fetches ME images from the internet and neuters
plus truncated them, using `me_cleaner`. This downloading is done
to avoid distributing them directly in Libreboot, and they get
scrubbed by the release build scripts.
To re-insert neutered/truncated ME into your image, look at
the [guide](../docs/install/ivy_has_common.md).
This applies to sandybridge, ivybridge and haswell Intel platforms,
e.g. X220, T420, X230, T430, T440p. On *older* Intel platforms such
as GM45+ICH9M (X200, T400, etc) the Intel ME image isn't needed and
Libreboot ships with ME-disabled configuration.
MRC image missing in Haswell ROMs
---------------------------------
Ditto ME images. To re-insert, follow
the [guide](../docs/install/ivy_has_common.md).
Internal flashing on 16MB X230 images
-------------------------------------
The X230 has two ways of upgrading the default 12MB (8MB and 4MB chips)
flash to 16MB: remove a bunch of resistors and capacitors on the board
(a guide is yet to be written for this) and both flash ICs, and replace
SPI1 with a 16MB chip e.g. Winbond W25Q128FVSIG.
The other method: replace just SPI2 which is a 4MB flash, with an 8MB
flash e.g. Winbond W25Q64FVSIG. This latter method was tested, and it
is made to boot by changing component2density in the IFD to 8MB, but
this is non-standard per Intel specifications.
It boots, but then internal flashing still only lets you flash the first
12MB, even though the bootblock is at the end of that 16MB flash and
does boot perfectly!
So, 16MB images on X230 are experimental. When these ROM images are built,
the required IFD modification is already done in Libreboot's IFD for this
setup.
S3 suspend/resume on Haswell (T440p/W541)
-----------------------------------------
Totally broken. The suspected cause is component2density setting in IFD
being wrong: ifdtool reports it as being too big for what's actually
flashed.
No fix has been found yet that doesn't brick the machine, so this bug
is still present in the Libreboot 20221214 release.
The issue is that the MRC cache is in the wrong place in memory, because
of that bug in the IFD, but when ifdtool is used to correct component2density,
it bricks, which leads to wonder: is ifdtool's knowledge of these bits on
haswell faulty?
When X230 16MB was experimented with, Haswell was also looked at, and what
seemed to be the same component density bits were set, also resulting in
a brick (it's why only 12MB images are available for haswell in libreboot).
Chromebook boards mostly untested
---------------------------------
Alper has tested the `gru_kevin` ROM images produced by lbmk, but
the other images are untested as of this day.
Planned future work
===================
In general, you should also check the issue tracker to find other notes.
There is always more work to do, to improve Libreboot.
Linux distro in flash
---------------------
STILL ON TODO SINCE LAST RELEASE.
This is another project that has been on hold for a while. The issue
has been that I need a decent userland project. I've looked at many
different userlands and recently (as of late June) decided to make
my own. I want a BusyBox-like solution, but based on code from OpenBSD,
ported to run under Linux with musl libc.
I want this distro to provide a kexec bootloader in flash, similar to Heads,
and I also want it to use apk-tools, pointing at Alpine Linux repositories
so as to allow any number of packages to be downloaded. It could also provide
lots of utils in general, to be a live *rescue system* of sorts. Linux system
in flash, that can bootstrap other systems.
Re-factor and optimize GRUB
---------------------------
STILL ON TODO SINCE LAST RELEASE.
GRUB is full of unused bloat that almost nobody uses, yet is in the current
Libreboot builds. It's been on TODO for some time, but work has not yet
begun on this project. My efforts are currently focused on the Linux distro.
What I want is a fork of GRUB, optimized to run on bare metal as a coreboot
payload, on x86 and ARM platforms.

347
site/news/libreboot20230319.md
View File

@ -1,347 +0,0 @@
% Libreboot 20230319 released!
% Leah Rowe
% 19 March 2023
**UPDATE: Bugs in this were fixed, and a bugfix release is now available.
See: [Libreboot 20230413 release announcement of 13
April 2023](libreboot20230413.md) - the `t440pmrc_12mb` and `w541mrc_12mb`
images have been re-added, in the new release.**
**PLEASE READ THIS BEFORE INSTALLING:
[Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell](safety.md)**
Introduction
============
Libreboot provides boot firmware for supported x86/ARM machines, starting a
bootloader that then loads your operating system. It replaces proprietary
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
on ARM-based chromebooks supported (U-Boot bootloader, instead of Google's
depthcharge bootloader). On x86 machines, the GRUB and SeaBIOS coreboot
payloads are officially supported, provided in varying configurations per
machine. It provides an automated build system for the configuration and
installation of coreboot ROM images, making coreboot easier to use for
non-technical people. You can find the list of supported hardware in the
Libreboot documentation.
The last Libreboot release, version 20221214, was released on 14 December
in 2022. *This* new release, Libreboot 20230319, is released today on
March 19th, 2023.
This is marked as a *testing* release. Not all ROM image configurations have
been provided pre-compiled; specifically, `daisy` and `veyron` chromebook
boards are not available pre-compiled, but the other boards are. A few new
boards have been added, in addition to several fixes and feature additions.
READ THIS BEFORE FLASHING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)**
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
Build from source
-----------------
*This* release was build-tested on Debian *Sid*, as of 18 March 2023. Your
mileage may vary, with other distros. Refer to Libreboot documentation.
Work done since last release
============================
For more detailed change logs, look at the Git repository. This is
a summary of changes.
Brief overview of changes
-----------------
I've been very busy these last couple months, so there have been less changes
in Libreboot lately. I'm expecting to have a lot more time throughout the
coming summer, which I plan to make full use of for the next Libreboot
release.
The changes can be summarised, thus:
* **LIBRE** raminit code now available, on Haswell boards (ThinkPad T440p and
ThinkPad W541). This is using patches from Angel Pons (hell on coreboot IRC),
that are currently still in review on coreboot master. The *old* configs
that use `mrc.bin` for raminit are still available aswell, so this release
contains ROMs with libre raminit *and* ROMs with blob raminit. The reasons
are explained below.
* **FIXED S3 suspend/resume on Haswell (T440p/W541)** - but only on configs
that use `mrc.bin`. The images with libre MRC still have broken S3. S3
suspend/resume is what people refer to as *sleep mode* and *wake from sleep*.
* **Force console display mode in GRUB**: This corresponds to the
setting `GRUB_TERMINAL=console` that you might find in `/etc/default/grub`
on a Linux machine. In Libreboot, switching VGA/text modes is unsupported,
it's stuck in one mode until Linux/BSD Kernel Mode Setting takes over.
With this change to GRUB, GRUB's VGA mode switching is disabled. This might
make a few Linux distro installer menus work a bit nicer.
* **New ports:** Lenovo T530 and W530 thinkpads added.
* **Bump coreboot revision**: February 2023 revision for most x86 boards,
including Haswell (T440p/W541) when `mrc.bin` is in use; Haswell (T440p/W541)
setups that don't use `mrc.bin` (and instead use Angel`s libre replacement
code), it's currently based on coreboot from mid-2022 because that's what
Angel's as yet unmerged patches are based on (relative to coreboot's
master branch)
* **Bump GRUB revision:** February 2023 revision now, on all boards.
* **Bump SeaBIOS revision:** February 2023 revision now, on all
boards.
* `grub.cfg`: 5 seconds boot delay, instead of 10 seconds.
* GM45 thinkpads: default to 256MB VRAM instead, which is more stable than
the previous setting of 352MB. Many reports from users indicated performance
issues when the 352MB config was used.
* Stricter handling of exit status in lbmk. More errors result in a hard
exit than before, preventing the build process from erroneously continuing.
* Fixed fault checks in the Libreboot build system, when checking which
coreboot utilities are needed (e.g. cbfstool, ifdtool)
* util/nvmutil: Massively re-factored the codebase, making it more efficient
and *correct*.
NOTE: T440p/W541 images with `mrc.bin` must be compiled from source. They were
removed from the release, due to a bug reported in scripts used for preparing
them post-build, when users install them. The bug was fixed in a revision
after the release. If you still have those ROM images from prior to deletion,
and want to use them, you should apply the following patch to your archive
of the release, or just use latest `lbmk` from the Git repository; see:
<https://browse.libreboot.org/lbmk.git/commit/?id=da6bf57a3f57f2625a4903cafb5cfd10ea4a1dae>
Pre-compiled ROM images will for the `t440pmrc_12mb` and `w541mrc_12mb` targets
will be available in the next release; the `t440p_12mb` and `w541_12mb` images
are still available in this release, pre-compiled.
REMARK: libre raminit on Haswell
--------------------------------
Upon testing, I've discovered that the libre code has the following problems:
* I haven't gotten S3 suspend/resume working properly on that yet.
* Broken USB device detection in GRUB.
* SeaBIOS still works, for USB devices.
Therefore, the *libre* MRC setup in this release, for T440p and W541 thinkpads,
only provides SeaBIOS payload (booting in text mode, implying use of a
bootloader that supports this, and if wanting xorg/wayland, a kernel that does
kernel mode setting, which is most BSD/Linux setups these days).
In this release, and in the build system, the following targets are defined:
* `t440p_12mb`: libre raminit code used (reverse engineered replacement
of `mrc.bin`)
* `w541_12mb`: ditto (libre raminit code)
* `t440pmrc_12mb`: blob `mrc.bin` used for raminit. GRUB and SeaBIOS payloads
both supported.
* `w541mrc_12mb`: blob `mrc.bin` used for raminit. GRUB and SeaBIOS payloads
both supported.
The libre raminit comes from this patchset:
<https://review.coreboot.org/c/coreboot/+/64198/5>
The MRC blob (and Angel's replacement code) don't just do raminit, they handle
a few other init tasks aswell, including USB host controller.
New boards, x86
----------
* Lenovo ThinkPad W530
* Lenovo ThinkPad T530
I bought these machines, which I've not added to the release but plan to
add for the next release:
* HP EliteBook 8560w (<https://review.coreboot.org/c/coreboot/+/39398>)
* Lenovo G505S (<http://dangerousprototypes.com/docs/Lenovo_G505S_hacking>)
* Dell Latitude E6400 (now merged in coreboot master. It's an ICH9M machine
but with DDR2 raminit)
^ I would have put these in today's release, but didn't have time, and wanted
to get this release done today.
Removed boards
--------------
* asus p2b\_ls/p3b\_f - they didn't boot properly in pcbox, and the real
hardware is basically useless / impossible to find
lbmk Git changes
------------
The precise list of commits in `lbmk.git` since the last release, is as
follows:
```
* 07b6bb3d - build/release: handle nvmutil (12 hours ago) <Leah Rowe>
* 653810b8 - fix bug: me not being downloaded on some boards (12 hours ago) <Leah Rowe>
* 2bb63d85 - new board: lenovo/w530 (12 hours ago) <Leah Rowe>
* 896e9065 - new board: lenovo/t530 (13 hours ago) <Leah Rowe>
* cffa5679 - haswell (lenovo t440p/w541): fix S3 suspend/resume (14 hours ago) <Leah Rowe>
* be3d7b7e - haswell: re-add mrc.bin in separate board configs (22 hours ago) <Leah Rowe>
* bdc39ffc - haswell: only use txtmod seabios configuration (25 hours ago) <Leah Rowe>
* df6b9e28 - remove t440p_12mb_cbfs4mb (retain t440_12mb) (25 hours ago) <Leah Rowe>
* 04f1fe17 - remove x220_16mb (x220 with 16MB flash) (29 hours ago) <Leah Rowe>
* 548872ce - haswell boards: use libre mrc.bin replacement (2 days ago) <Leah Rowe>
* a942bd65 - move download/gitmodule script to root directory (2 days ago) <Leah Rowe>
* 59540530 - nuke p2b_ls/p3b_f boards (2 days ago) <Leah Rowe>
* ebd9ec96 - debian/ubuntu dependencies scripts: add gettext (3 days ago) <Leah Rowe>
* f9e20b8a - util/nvmutil: optimise rhex() further (13 days ago) <Leah Rowe>
* f04855c2 - fix flashrom download error (13 days ago) <Leah Rowe>
* e2945f02 - payload/grub: force terminal_output to console (2 weeks ago) <Leah Rowe>
* 909d3b31 - grub.cfg: set default timeout to 5 seconds (2 weeks ago) <Leah Rowe>
* 544737c8 - scripts: build cbutils, not specific utils (2 weeks ago) <Leah Rowe>
* 9398ad08 - also fix data.vbt path for lenovo/w541 (2 weeks ago) <Leah Rowe>
* d2465e82 - Fix CONFIG_INTEL_GMA_VBT_FILE for the t440p_12mb config (2 weeks ago) <Konstantinos Koukopoulos>
* 0e34d199 - update debian dependencies (for sid) (2 weeks ago) <Leah Rowe>
* a5aa5bca - ICH9M: default to 256MB VRAM, not 352MB (2 weeks ago) <Leah Rowe>
* 6421af5d - bump seabios revision (4 weeks ago) <Leah Rowe>
* aba6307d - bump grub revision (4 weeks ago) <Leah Rowe>
* 36982ab5 - fix bad ifdtool patch from earlier commit (4 weeks ago) <Leah Rowe>
* 3857b4b6 - build/dependencies/debian: add python3 dependency (4 weeks ago) <Leah Rowe>
* dac9ea86 - build/boot/roms: fail when build cbutils fails (4 weeks ago) <Leah Rowe>
* 0d0f6cf3 - coreboot: update revision of cbtree "default" (4 weeks ago) <Leah Rowe>
* dc1fedf9 - Merge branch 'uboot-v2023.01' of alpernebbi/lbmk into master (4 weeks ago) <Leah Rowe>
|\
| * 7932d5fa - u-boot: Disable environment storage (5 weeks ago) <Alper Nebi Yasak>
| * 8d57468e - u-boot: Update to v2023.01 (5 weeks ago) <Alper Nebi Yasak>
|/
* 6b4a14ce - util/nvmutil: tidy up variable declarations (7 weeks ago) <Leah Rowe>
* 031a0b55 - util/nvmutil: setWord(): declare variables first (7 weeks ago) <Leah Rowe>
* 257eedca - util/nvmutil: reset errno if any write attempted (7 weeks ago) <Leah Rowe>
* adc76e38 - util/nvmutil: do not write non-changes to disk (7 weeks ago) <Leah Rowe>
* 3e150bf3 - util/nvmutil: cmd_swap(): write sequentually (7 weeks ago) <Leah Rowe>
* 7e3a7355 - util/nvmutil: don't use malloc() (7 weeks ago) <Leah Rowe>
* a924d43b - util/nvmutil: fix clang build errors (7 weeks ago) <Leah Rowe>
* c822033b - util/nvmutil: simplify rhex() (7 weeks ago) <Leah Rowe>
* 0f485245 - util/nvmutil: use gbe[] in word() and setword() (7 weeks ago) <Leah Rowe>
* b1186968 - util/nvmutil: code cleanup (7 weeks ago) <Leah Rowe>
* 7a986497 - util/nvmutil: call pledge() earlier, in main() (7 weeks ago) <Leah Rowe>
* bb6fe263 - util/nvmutil: remove unused #define (7 weeks ago) <Leah Rowe>
* 5a5a8662 - util/nvmutil: optimised disk reads (7 weeks ago) <Leah Rowe>
* 24d56456 - util/nvmutil: optimise cmd_swap() (7 weeks ago) <Leah Rowe>
* ef84329a - util/nvmutil: optimise rhex() for speed (7 weeks ago) <Leah Rowe>
* 88a51531 - util/nvmutil: code cleanup in rhex() (7 weeks ago) <Leah Rowe>
* ac1cab28 - x230edp_12mb: Correct the path to data.vbt (7 weeks ago) <Alexei Sorokin>
* afc80b89 - util/nvmutil: update copyright years (9 weeks ago) <Leah Rowe>
* 8242dca5 - util/nvmutil: limit bytes written per command (9 weeks ago) <Leah Rowe>
* e398331b - util/nvmutil: make writeGbeFile more readable (9 weeks ago) <Leah Rowe>
* 8dea350a - util/nvmutil: only write parts that are modified (9 weeks ago) <Leah Rowe>
* d0fa08d5 - blobs/inject: fix wrong nvmutil path for make (10 weeks ago) <Leah Rowe>
* e8072934 - Merge branch 'veyron-uboot-dmreset' of alpernebbi/lbmk into master (10 weeks ago) <Leah Rowe>
|\
| * e11650c3 - u-boot: Enable DM_RESET for veyron boards (3 months ago) <Alper Nebi Yasak>
* | 6b104542 - Merge branch 'peach-uboot-usbehci' of alpernebbi/lbmk into master (10 weeks ago) <Leah Rowe>
|\ \
| |/
|/|
| * 80bf54b2 - u-boot: Enable USB_EHCI_EXYNOS on peach boards (3 months ago) <Alper Nebi Yasak>
|/
* 7f5dfebf - Do not rely on bashisms and behaviour undefined by the POSIX specification. Part 2 (3 months ago) <Ferass 'Vitali64' EL HAFIDI>
* f7870446 - Do not rely on bashisms and behaviour undefined by the POSIX specification. (3 months ago) <Ferass 'Vitali64' EL HAFIDI>
* d45b2e70 - util/nvmutil: use err() more consistently (3 months ago) <Leah Rowe>
* d726b16f - util/nvmutil: more robust pointer handling (3 months ago) <Leah Rowe>
* 448ee510 - util/nvmutil: optimise cmd_swap() further (3 months ago) <Leah Rowe>
* effcb942 - util/nvmutil: greatly optimise cmd_copy() (3 months ago) <Leah Rowe>
* 6e5828e4 - util/nvmutil: greatly optimise cmd_swap() (3 months ago) <Leah Rowe>
* 7aafc62b - scripts/blobs/inject: fix bad cbfstool build check (3 months ago) <Leah Rowe>
* 6ebd178f - util/nvmutil: simplified error handling in rhex() (3 months ago) <Leah Rowe>
* 04da953c - util/nvmutil: return errno when calling err() (3 months ago) <Leah Rowe>
* 00187811 - util/nvmutil: exit non-zero if close() fails (3 months ago) <Leah Rowe>
```
Major works planned
===================
In general, you should also check the issue tracker to find other notes.
There is always more work to do, to improve Libreboot.
Linux distro in flash
---------------------
STILL ON TODO SINCE LAST RELEASE.
This is another project that has been on hold for a while. The issue
has been that I need a decent userland project. I've looked at many
different userlands and since late June in 2022, decided to make
my own. I want a BusyBox-like solution, but based on code from OpenBSD,
ported to run under Linux with musl libc.
I want this distro to provide a kexec bootloader in flash, similar to Heads,
and I also want it to use apk-tools, pointing at Alpine Linux repositories
so as to allow any number of packages to be downloaded. It could also provide
lots of utils in general, to be a live *rescue system* of sorts. Linux system
in flash, that can bootstrap other systems.
About a week before this release, I actually started on the project for real,
after having many false starts. I've forked a project called `lobase` which
already ports OpenBSD's userland utilities *to glibc* under Linux, and it's
as of today about 5 years outdated based on OpenBSD 6.3.
I've ported these utilities directly from OpenBSD 7.2, in my local fork of
lobase, superimposing the new code on top of the old and adapting according
to musl libc (lobase is full of hacks for glibc that I don't need):
`mail`, `cat`, `ls`, `head`, `rcs`, `hexdump`, `whois` and `time`
I've been working on this in a dedicated Alpine Linux virtual machine,
currently on release 3.17 of Alpine Linux. Alpine is an ideal test distro for
such development, because it already uses musl libc and has *libressl*
available in aports.
I don't have enough to release yet, but when I have a release ready, I will
upload it to a Git repository. When the userland port is fully complete,
I shall then base off of Alpine Linux abuild+aports build system
infrastructure to provide small base images. It will be similar to the Heads
project, but built separately and not specifically targeted at Libreboot,
but in general to any coreboot setup, on supported hardware. It won't be a
general purpose distro, but I would at that point submit my userland port to
Alpine, proposing it as a replacement of their busybox package in base.
Unlike Heads, I don't plan yet to make this a direct coreboot payload.
Instead, it'll be a standalone image loaded into CBFS, and chainloaded via
the GRUB or SeaBIOS payloads, which are both capable of executing ELF binaries
from the flash.
Lobase, which my development is forked from, can be found here (archived):
<https://github.com/Duncaen/lobase>
I've been re-using lobase's build system, adapting newer code from OpenBSD.
It's a lot of work, but I'm hopeful I can have this ready before the next
Libreboot release.
Re-factor and optimize GRUB
---------------------------
STILL ON TODO SINCE LAST RELEASE.
GRUB is full of unused bloat that almost nobody uses, yet is in the current
Libreboot builds. It's been on TODO for some time, but work has not yet
begun on this project. My efforts are currently focused on the Linux distro.
What I want is a fork of GRUB, optimized to run on bare metal as a coreboot
payload, on x86 and ARM platforms.
I have an update since the last release. Paul Menzel of coreboot *has* made
GRUB modules more configurable, making it possible to reduce the size of the
payload. His patch is not yet used in Libreboot (not in this release, anyway),
but the patch in GRUB is:
```
commit 6c5ee45548fcb65d7921c9fca5867b256f9a48ad
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Thu Mar 7 12:16:06 2019 +0100
Makefile: Allow to set file systems modules for default_payload.elf
```
I'm going to play around with this when I get the time. Even with this
modification, GRUB is still full of code that Libreboot will never use.
A *GRUB Valhalla Rampage* is still in order!

211
site/news/libreboot20230413.md
View File

@ -1,211 +0,0 @@
% Libreboot 20230413 released!
% Leah Rowe
% 13 April 2023
**PLEASE READ THIS BEFORE INSTALLING:
[Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell](safety.md)**
Introduction
============
Libreboot provides boot firmware for supported x86/ARM machines, starting a
bootloader that then loads your operating system. It replaces proprietary
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
on ARM-based chromebooks supported (U-Boot bootloader, instead of Google's
depthcharge bootloader). On x86 machines, the GRUB and SeaBIOS coreboot
payloads are officially supported, provided in varying configurations per
machine. It provides an automated build system for the configuration and
installation of coreboot ROM images, making coreboot easier to use for
non-technical people. You can find the list of supported hardware in the
Libreboot documentation.
The last Libreboot release, version 20230319, was released on 19 March
in 2023. *This* new release, Libreboot 20230413, is released today on
April 13th, 2023.
This is marked as a *testing* release, though it is *basically stable*.
It is a bugfix release, relative to Libreboot 20230319. In addition to this,
massive code cleanup has been performed on parts of the build system.
The priority of this release has been build system fixes/improvements. For the
time being, no more code changes will be made unless needed, in coreboot, for
existing supported hardware; the focus is going to be on adding *more* boards
to Libreboot, to support more hardware. I've been on a spree, buying lots of
mainboards that coreboot supports, that would be interesting in Libreboot.
READ THIS BEFORE FLASHING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)**
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
Build from source
-----------------
*This* release was build-tested on Debian *Sid*, as of 13 April 2023. Your
mileage may vary, with other distros. Refer to Libreboot documentation.
KCMA-D8 and KGPE-D16 wanted!
----------------------------
[ASUS KGPE-D16 and KCMA-D8 needed for testing!](kgpe-d16.md)
These boards still haven't made it back to Libreboot, but I wish to re-add
them in a future release. If you can give/loan me a fully assembled workstation
with one (or both) of these, I would appreciate it. Please
[get in touch](../contact.md)!
Work done since last release
============================
For more detailed change logs, look at the Git repository. This is
a summary of changes.
Summary of changes:
-------------------
Zero code changes within coreboot on any boards, but the build system went
through a mild overhaul:
* Massive code cleanup of `util/nvmutil`, and improved error handling.
* Insert scripts for post-release sandybridge/ivybridge/haswell ROMs are now
much easier to use, and less error-prone.
* A few problematic boards, for which ROM images were excluded in the previous
release, have now been *removed* from the Libreboot build system. They will
be re-added in a future release, and you can find a list of them in the
detailed changelog below.
* Haswell (T440/W541): `mrc.bin` insertion is now *correct*, on the blobutil
script. In the previous release, Libreboot's build system inserted this at
the wrong location in the ROM, after downloading it; coreboot's own build
system does it correctly, and that is used when compiling, but post-release
ROM images have it inserted with equivalent logic in the Libreboot build
system, instead. - NOTE: libre raminit is also available, if you choose
the ROM images with `t440p_12mb` in the filenames, whereas `t440pmrc_12mb`
images need `mrc.bin` for raminit. More info about this is in the previous
release.
MRC W541/T440p ROM images re-added
----------------------------------
As alluded to and applied by the above text, T440p/W541 thinkpad images that
use `mrc.bin` have been re-added. Libreboot supports experimental raminit on
these boards, where the MRC file is not required, but it also provides ones
that use it, so that users can choose which one they want.
More information this is available, in the *previous*
[Libreboot 20230319 release announcement](libreboot20230319.md).
Detailed descriptions of changes
--------------------------------
Changelog:
* `blobutil/inject`: Relative to the fix below (courtesy `shmalebx9`), the
ROM image archives in releases now contain lists of SHA1 hashes, matching
what each file should be when running `blobutil/inject`
* `blobutil/inject`: It is now possible to insert MRC and neutered ME images,
where required on specific mainboards, into *all* ROM images of a given
tar archive, in addition to single ROM images. The patch for this is
courtesy of Caleb La Grange (`shmalebx9` on libreboot IRC)
* Removed daisy/peach chromebooks: The machines are believed to boot properly,
with the coreboot and u-boot code being correct, but lbmk currently does not
handle the BL1 bootloaders on these machines, and this was overlooked before;
the images for these machines have also been deleted, from previous releases.
These will be re-added in a future Libreboot release.
* Removed veyron chromebooks for now: u-boot does not work at all on those
boards (video issues), last known revision working on veyron was 2021.01 so
a git-bisect can probably done. These boards will be re-added in a future
Libreboot release.
* `util/ich9utils`: Merged it back into lbmk, rather than keeping it as a
separate repository. It is now directly part of the Libreboot build system,
once again.
* `util/nvmutil`: Major code cleanup; reduced SLOC count to 315 source lines,
whereas it was 386 code lines in the previous release. The compiled binary
sizes have been reduced by 7%, as tested with TCC on an x86\_64 host. This
code size reduction is provided, *without* reducing any functionality.
* `util/nvmutil`: Fixed faulty check for MAC address `00:00:00:00:00:00` - the
total was being reset for each word, wrongly. This has been corrected.
* `blobutil/download`: now supports extracting `me.bin` from LZMA archives, in
addition to inno archives; in practise, lbmk still currently only supports
machines where inno archives are extracted from, but experimental new ports
exist outside of `master` that will be present in future releases.
* `blobutil/download`: no longer hardcodes the `me.bin` path, when extracting
from updates during auto-download. When compiling ROM images, lbmk now does
this by bruteforce, automatically finding the correct location of the ME
image inside vendor archives; this works well on inno/lzma archives.
The script then runs `me_cleaner` as usual, inserting that into the ROM
image - this same logic is also used when inserting into release ROMs.
This is in preparation for *non-Lenovo* sandybridge, ivybridge and haswell
machines being added in future releases, e.g. Dell and HP laptops that
coreboot supports.
* `blobutil/download`: heavily re-factored the logic, switching to top-down
order of functions, split more operations into functions, generally made
the script easier to read/work on.
* `blobutil/inject`: use correct offset for insertion of `mrc.bin` (Haswell
platform, e.g. ThinkPad T440p) - as written above.
* Removed mainboard: `d945gclf` - known to be problematic at boot. I have one,
and I'm going to test it for re-entry in a future release.
* Added missing dependency in Arch Linux dependencies installation script,
patch courtesy of Andreas Hartmann.
Hardware supported in this release
==================================
All of the following are believed to *boot*, but if you have any issues,
please contact the Libreboot project. They are:
Desktops (AMD, Intel, x86)
-----------------------
- [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
- [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
- [Apple iMac 5,2](../docs/hardware/imac52.md)
### Laptops (Intel, x86)
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
- Lenovo ThinkPad X230
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](../docs/hardware/r400.md)
- [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
- [Lenovo ThinkPad T500](../docs/hardware/t500.md)
- [Lenovo ThinkPad T530 / W530](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad W500](../docs/hardware/t500.md)
- [Lenovo ThinkPad R500](../docs/hardware/r500.md)
- [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
- [Lenovo ThinkPad T440p](../docs/install/t440p_external.md)
- [Lenovo Thinkpad X220](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X220t](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad T420](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T420S](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T430](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X230](../docs/install/x230_external.md)
- [Lenovo Thinkpad X230t](../docs/install/x230_external.md)
- [Lenovo ThinkPad W541](../docs/install/ivy_has_common.md)
### Laptops (ARM, with U-Boot payload)
- [HP Chromebook 14 G3 (nyan-blaze)](../docs/install/chromebooks.md)
- [Acer Chromebook 13 (CB5-311, C810) (nyan-big)](../docs/install/chromebooks.md)
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
Downloads
=========
You can find this release on the downloads page. At the time of this
announcement, some of the rsync mirrors may not have it yet, so please check
another one if your favourite one doesn't have it.

202
site/news/libreboot20230423.md
View File

@ -1,202 +0,0 @@
% Libreboot 20230423 released!
% Leah Rowe
% 23 April 2023
**PLEASE READ THIS BEFORE INSTALLING:
[Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell](safety.md)**
Introduction
============
Libreboot provides boot firmware for supported x86/ARM machines, starting a
bootloader that then loads your operating system. It replaces proprietary
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
on ARM-based chromebooks supported (U-Boot bootloader, instead of Google's
depthcharge bootloader). On x86 machines, the GRUB and SeaBIOS coreboot
payloads are officially supported, provided in varying configurations per
machine. It provides an automated build system for the configuration and
installation of coreboot ROM images, making coreboot easier to use for
non-technical people. You can find the list of supported hardware in the
Libreboot documentation.
The last Libreboot release, version 20230413, was released on 13 April
in 2023. *This* new release, Libreboot 20230423, is released today on
April 23rd, 2023.
This is marked as a *testing* release, though it is *basically stable*.
We've been going at it like crazy, on a big spree adding more mainboards from
coreboot. Some fixes to the build system were also made, since the last release
only *10 days ago*.
The *priority* for Libreboot is to add as many new boards as possible, from now
to the next stable release (ETA Q3 2023), with many testing releases in
between. Release early, release often. Rigorious testing ensues.
READ THIS BEFORE FLASHING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)**
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
Build from source
-----------------
*This* release was build-tested on Debian *Sid*, as of 23 April 2023. Your
mileage may vary, with other distros. Refer to Libreboot documentation.
KCMA-D8 and KGPE-D16 wanted!
----------------------------
[ASUS KGPE-D16 and KCMA-D8 needed for testing!](kgpe-d16.md)
These boards still haven't made it back to Libreboot, but I wish to re-add
them in a future release. If you can give/loan me a fully assembled workstation
with one (or both) of these, I would appreciate it. Please
[get in touch](../contact.md)!
Work done since last release
============================
This is in the last *10 days*, since the previous release was 10 days ago!
Ergo, this is a very conservative changelog. It seems Libreboot has been
releasing almost fortnightly, as of late; perhaps this could continue from
now on.
New mainboards now supported:
-----------------------------
* **Dell Latitude E6400 (laptop)** (GM45, blob-free, flashable entirely in
software, no disassembly required!) - courtesy Nicholas Chin, `nic3-14159` on
Libreboot IRC.
* HP Compaq 8200 Elite SFF (desktop), courtesy Riku Viitanen (`Riku_V` on
Libreboot IRC) - *Sandybridge* hardware generation, really nice machine,
cheap, easy to flash, supports 32GB RAM, multiple HDDs etc.
* HP EliteBook Folio 9470m (laptop), courtesy Riku Viitanen (IvyBridge gen)
* HP EliteBook 2560p (laptop), courtesy Riku Viitanen (*seriously* cool guy) -
Sandybridge hardware gen
Build system changes:
---------------------
* **GM45 no-microcode bug mitigations re-added: revert to old SMRR handling
and disable PECI (for e.g. X200/T400 users who want to [remove microcode
updates](gm45microcode.md), using `cbfstool`) - fixes broken reboot/speedstep
CPU scaling in such configuration.** - Patch:
<https://browse.libreboot.org/lbmk.git/commit/?id=bd4ea9a02845b22a09b73ebb015ce134234d100b>
(patch by Leah Rowe) - this also affects Dell Latitude E6400, and it can be
used there on that board. We recommend *keeping* microcode updates, but these
mitigations were re-added to satisfy users of older releases that excluded
them, who want to still have the option to feasibly run without them.
[This is ill advised, due to bugs that the microcode updates
fix](gm45microcode.md)
* `blobutil/inject`: Fixed bad variable expansion pattern. Patch courtesy
Leah Rowe.
* GRUB patch: fix hanging on HP EliteBooks, by implementing a 200ms timeout
for PS/2 keyboard initialisation. Patch courtesy of Riku Viitanen, and it
fixes this issue which has existed in coreboot *for years*:
<https://browse.libreboot.org/lbmk.git/plain/resources/grub/patches/0005-at-keyboard-timeout.patch?id=20192c08488104f5cacc1f3842ae8e0ee74c44ef>
* `build/release/roms`: HP KBC1126 EC firmware scrubbed from release ROMs, for
re-insertion later via `./blobutil download` and `./blobutil inject` like
with ME images via `me_cleaner` - for HP laptops. Patch courtesy Leah Rowe.
* `build/dependencies/parabola`: New script for installing build dependencies
in Parabola GNU+Linux, courtesy of Riku Viitanen (`Riku_V` on Libreboot IRC)
* `util/nvmutil`: sorted includes alphabetically; `sys/` first (puffy!) -
courtesy Leah Rowe.
* `util/e6400-flash-unlock`: New utility for Dell Latitude E6400 added, written
by Nicholas Chin (`nic3-14159` on Libreboot IRC). It sends EC commands to
pull a GPIO connected to `GPIO33`/`HDA_DOCK_EN` in the chipset to a low logic
state, disabling IFD-based flash protections. Additionally, it bypasses the
SMM BIOS lock protection by disabling SMIs, and since Dell's own BIOS offers
no other protections, the machine can be flashed *entirely with software on
the host CPU*, from Dell BIOS to Libreboot! See:
<https://browse.libreboot.org/lbmk.git/tree/util/e6400-flash-unlock>
* GRUB payload: `grub.cfg` menu timeout now 30s, not 5s (courtesy Leah Rowe)
* `blobutil/download`: support downloading KBC1126-based EC firmware for HP
laptops. (patch by Leah Rowe)
* `blobutil/download`: Support extracting `me.bin` from full archives, when
running `./blobutil download` - this is done, using the `-M` option
in `me_cleaner` (some vendors put whole ROM images with IFD, GBE, ME and BIOS
regions in them, inside their BIOS update archives - we only need to get ME
from them, to run through `me_cleaner`) in `me_cleaner`. Ninja'd into lbmk by
Leah Rowe.
Hardware supported in this release
==================================
All of the following are believed to *boot*, but if you have any issues,
please contact the Libreboot project. They are:
Desktops (AMD, Intel, x86)
-----------------------
- [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
- [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
- [Apple iMac 5,2](../docs/hardware/imac52.md)
- [HP Elite 8200 SFF](../docs/hardware/hp8200sff.md) (HP 6200 Pro Business probably works too)
### Laptops (Intel, x86)
- **[Dell Latitute E6400](../docs/hardware/e6400.md) (easy to flash, no disassembly, similar
hardware to X200/T400)**
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
- Lenovo ThinkPad X230
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](../docs/hardware/r400.md)
- [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
- [Lenovo ThinkPad T500](../docs/hardware/t500.md)
- [Lenovo ThinkPad T530 / W530](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad W500](../docs/hardware/t500.md)
- [Lenovo ThinkPad R500](../docs/hardware/r500.md)
- [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
- [Lenovo ThinkPad T440p](../docs/install/t440p_external.md)
- [Lenovo Thinkpad X220](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X220t](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad T420](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T420S](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T430](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X230](../docs/install/x230_external.md)
- [Lenovo Thinkpad X230t](../docs/install/x230_external.md)
- [Lenovo ThinkPad W541](../docs/install/ivy_has_common.md)
- [HP EliteBook 2560p](../docs/hardware/hp2560p.md)
- [HP EliteBook Folio 9470m](../docs/hardware/hp9470m.md)
### Laptops (ARM, with U-Boot payload)
- [HP Chromebook 14 G3 (nyan-blaze)](../docs/install/chromebooks.md)
- [Acer Chromebook 13 (CB5-311, C810) (nyan-big)](../docs/install/chromebooks.md)
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
More boards soon!
=================
I've purchased about ~10 HP mainboards, all of the viable sandybridge,
ivybridge and haswell ones from coreboot. I'm going to add them all.
I also have Dell Optiplex 7020 and 9020; these are on coreboot gerrit and
will also be added, in the next Libreboot release (Haswell gen).
I'm going to re-work a lot of the merged Haswell boards, so that they can
also make use of Angel's experimental libre MRC raminit and such, currently
available on ThinkPad T440p and W541 as an option in Libreboot (including in
this release!)
Downloads
=========
You can find this release on the downloads page. At the time of this
announcement, some of the rsync mirrors may not have it yet, so please check
another one if your favourite one doesn't have it.

357
site/news/libreboot20230625.md
View File

@ -1,357 +0,0 @@
% Libreboot 20230625 released!
% Leah Rowe
% 25 June 2023
**PLEASE READ THIS BEFORE INSTALLING:
[Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell](safety.md)**
Introduction
============
Libreboot provides boot firmware for supported x86/ARM machines, starting a
bootloader that then loads your operating system. It replaces proprietary
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
on [ARM-based chromebooks](../docs/install/chromebooks.html) supported
(U-Boot bootloader, instead of Google's depthcharge bootloader). On x86
machines, the GRUB and SeaBIOS coreboot
payloads are officially supported, provided in varying configurations per
machine. It provides an [automated build system](../docs/maintain/) for the
[configuration](../docs/build/) and [installation](../docs/install/) of coreboot
ROM images, making coreboot easier to use for non-technical people. You can find
the [list of supported hardware](../docs/hardware/) in Libreboot documentation.
Libreboot's main benefit is *higher boot speed*,
[better](../docs/linux/encryption.md)
[security](../docs/linux/grub_hardening.md) and more
customisation options compared to most proprietary firmware. As a
[libre](policy.md) software project, the code can be audited, and coreboot does
regularly audit code. The other main benefit is [*freedom* to study, adapt and
share the code](https://writefreesoftware.org/), a freedom denied by most boot
firmware, but not Libreboot! Booting Linux/BSD is also [well](../docs/linux/)
[supported](../docs/bsd/).
*This* new release, Libreboot 20230625, released today 25 June 2023, is
a new *stable* release of Libreboot. The previous stable release was
Libreboot 20220710, released on 10 July 2022.
READ THIS BEFORE FLASHING LIBREBOOT, OR YOU MIGHT BRICK YOUR MACHINE
====================================================================
**On newer Intel platforms that require Intel ME and/or MRC firmware, such as
ThinkPad X230 or T440p, and/or HP laptops that require KBC1126 EC firmware,
the release ROMs of Libreboot are MISSING certain files, that you must insert
yourself. FAILURE to adhere to this warning may result in you bricking your
machine (rendering it unbootable), if you were to flash the release ROMs without
modifying them in any way. For more information, please read:**
**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)**
This isn't required on *all* Libreboot-supported boards, but if in doubt, follow
these instructions anyway. If you run `blobutil` on a board that doesn't need
blobs, nothing will happen.
A note about the changelog
--------------------------
The changes listed here are relative to Libreboot *20230423*, *not* 20220710.
Therefore, to get a full list of changes since 20220710 (the previous stable
release, where releases in-between then and now were *testing*), you should read
the [20221214](libreboot20221214.md), [20230319](libreboot20230319.md),
[20230413](libreboot20230413.md) and [20230423](libreboot20230423.md)
announcements before reading the *20230625* change log, in order to get
a complete picture.
Build from source
-----------------
*This* release was build-tested on Debian *Sid*, as of 25 June 2023. Your
mileage may vary, with other distros. Refer to Libreboot documentation.
Work done since last release
============================
New mainboards now supported:
-----------------------------
These boards were added to Libreboot:
* Laptop: HP EliteBook 2570p (courtesy Riku Viitanen and Johan Ehnberg
`johan@molnix.com`)
* Desktop: HP 8300 USDT (courtesy Riku Viitanen, who *also* ported this
to coreboot)
* Desktop: Gigabyte GA-G41M-ES2L was *re-added*, having been previously
deleted from Libreboot.
The focus has been on stability, auditing the build system and fixing bugs,
thus hardware support is not greatly improved since the last release. Moving
forward, the next Libreboot release will be a *testing* release and *will*
focus on hardware support in addition to payloads (linux boot, UEFI etc).
No-microcode ROMs available
---------------------------
Since Libreboot 20221214 and up, CPU microcode is
included by default on all applicable x86 mainboards. However,
Libreboot provided (and still provides) documentation for how
to manually remove it.
Such removal is still possible, but *this* release now provides
two sets of ROM images for each x86 mainboard: one set of ROMs
will *contain* CPU microcode, and another set *excludes* them.
For more context, see [Binary Blob Reduction Policy](policy.md)
and [Freedom Status](../freedom-status.md).
An earlier article was written about this, [here](microcode.md)
Massive build system audit
--------------------------
The full change log below will list all build system changes,
but may not provide the overall picture, so to be clear: the
Libreboot build system has undergone an intense audit since the
last release. Over half of it has been re-written, or heavily
re-factored. The logic is much cleaner now (better coding style,
based on the OpenBSD coding style) and many bugs are fixed.
An earlier article was written about this, [here](audit.md)
Full list of build system changes
--------------------
Certain build system changes will not be listed here in detail, if they
pertain to general code style cleanup/re-factoring, as already alluded to
in the section above. However, specific *bug fixes* will be listed here,
some of which are *also* referenced in the article linked above.
Newest changes first, oldest changes last:
* Coreboot utilities: build them and place them under `cbutils/` from the main
lbmk directory. Use these binaries during build (ROM images, for example).
this makes handling of coreboot more robust, where we can now
run `make distclean` without worrying about utilities. This also fixes the
bug where utilities were being needlessly re-compiled, slowing down the build
of multiple ROM images.
* Boot logo size reduced to ~3KB, down from ~12KB. Courtesy Riku Viitanen. This
was done, without loss of image quality.
* `cros`: Disable coreboot-related BL31 features. This fixes poweroff on gru
chromebooks. Patch courtesy of Alper Nebi Yasak.
* `u-boot`: Increase EFI variable buffer size. This fixes an error where
Debian's signed shim allocates too many EFI variables to fit in the space
provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
* Re-added Gigabyte GA-G41M-ES2L mainboard. It actually does boot, but we have
always known that raminit is quite experimental on this board. You just have
to cycle through RAM until you find modules that work.
* `nyan` chromebooks: Removed for now (not yet stable) - this release only
contains `gru` chromebooks, where ARM-based chromebooks are concerned.
* `blobutil/download`: Exit with zero status (success) immediately, when
no board configs exist for a specified target. This fixes
the `./build boot roms all` command, when the relevant script encounters
certain targets defined under `resources/coreboot`, where previously the
command would fail due to implicit references to such files.
* Main `lbmk` script: Exit non-zero if a called script fails, explicitly. The
script previously relied on `-e` which isn't always completely reliable.
The new handling also explicitly prints `lbmk error` on stdout, to let the
operator know that an error did in fact occur.
* Board target `t440p_12mb` renamed to `t440plibremrc_12mb`
* `build/boot/roms`: No-microcode ROM images provided, alongside the default
ROMs that include microcode by default. This change is also alluded to in
the sections above.
* `blobutil/download`: Cache downloads based on checksum, to avoid needlessly
re-downloading files per mainboard. This is useful when compiling multiple
ROM images, for multiple mainboards. Patch courtesy Riku Viitanen.
* Dell Latitude E6400 (board): Fix SD cards (SD cards now work fine). Patch
courtesy Nicholas Chin.
* `util/nvmutil`: Vastly more efficient code (part of the audit, referenced in
above).
* `util/nvmutil`: [unveil](https://man.openbsd.org/unveil.2) now used, in
addition to pledge when compiled on OpenBSD.
* `util/nvmutil`: Hardened pledge calls, when compiled on OpenBSD.
* utils: Properly detect OpenBSD, to test whether pledge should be used.
* board `hp8200sff`: Add 4MB ROM configs, for internal flashing, patch courtesy
of Riku Viitanen.
* Unified *all* scripts in the main directory of lbmk (build system). All core
logic is now a *single* script, removing needless code repetition.
* `download/coreboot` fix: Do not needlessly re-download a given coreboot
tree, if it was already downloaded.
* Removed help text in certain scripts (unnecessary, can just read docs)
* `build/release/roms`: Fix error handling inside subshells.
* `build/release/src`: Fix error handling, previously not handled inside
subshells.
* `build/ich9utils`: Fix error handling (subshells)
* `build/descriptors`: Fixed error handling (certain errors weren't handled)
* `build/grub`: Actually handle errors. Logic was handled in subshells, where
greater care is required for error handling. Exit with non-zero status upon
any error.
* `gitclone`: Only delete the old project directory *if* the new download has
succeeded, to avoid, for example, complete purging of files when your internet
is down. In such cases, it's better that the script simply fails and no action
is taken. This fix implements such caution.
* `blobutil` fix: Actually exit with non-zero status (fail) when a called script
fails. This previously wasn't done at all.
* `.gitcheck` (script): Another bug fix, actually *do* clean coreboot git
credentials, when temporary ones were set, per coreboot tree. This previously
was not handled at all. (this script removes the need to manually set git
name/email, by setting a temporary one which makes the coreboot build system
happy when building ROM images)
* `.gitcheck` (script): Actually *run* gitcheck-clean. It wasn't being executed
at all, which screwed up the user's git credentials in some cases (after
running lbmk, you would sometimes commit a patch and find that your name is
now *lbmkplaceholder*).
* `util/spkmodem_recv`: Also: DEBUG define no longer used. It is now an argument
namely `-d`, which can be passed to the program. The code for debug is now
present in any build. Usage: `spkmodem-recv -d`
* New util: `util/spkmodem_recv` - imported from coreboot, which in turn forked
it originally from GNU GRUB. This is a receiving client for *spkmodem*, a type
of serial console provided via pulses over PC speaker. Libreboot's version
greatly improves the error handling, and it has been re-factored for OpenBSD
coding style, to replace the (very horrible) GNU coding style.
It is also [pledged](https://man.openbsd.org/pledge.2) in
Libreboot's version. For reference,
[here](https://git.savannah.gnu.org/cgit/grub.git/plain/util/spkmodem-recv.c?id=822b726b33b8dc07dd01b257a2dfcc7b07d12e2f)
is the GNU version, and
[here](https://raw.githubusercontent.com/coreboot/coreboot/8febc91b3041a1d027bf0d36d30ccb119496524f/util/spkmodem_recv/spkmodem-recv.c) is coreboot's version of it. And now to blow your mind,
[here](https://browse.libreboot.org/lbmk.git/tree/util/spkmodem_recv/spkmodem-recv.c?id=b508245451b71b3443fa3202f3863a6de731e9c8)
is the Libreboot version present in release 20230625. A very much GNU program,
but you wouldn't know it by looking! This fork was mostly done for fun, very
much a *because we can* affair. BONUS: BSD-style error handling (`err.h`)
* download/coreboot: Run `extra.sh` directly from the directory for the given
coreboot tree, if the script exists. No board in Libreboot has ever included
an `extra.sh` script, but it can be used to extend the default functionality
of lbmk where lots of custom logic is needed for a given board. For example,
if you needed to apply lots of patches from gerrit in a specific order, in a
way that could not be generalised for other mainboards where it's really
only applicable to that mainboard, you might use `extra.sh`. This was briefly
used in the erstwhile osboot project, on a few boards.
* download/coreboot: Use the `gitclone` script for actually cloning coreboot,
while still using the main script for handling trees/revisions and such.
(this is one of the scripts that got re-written during the audit, mentioned
in the previous section above)
* build/payload/seabios: *Much* stricter error handling, exit with non-zero
status (fail) on more error conditions, should they occur.
* download/mrc (script): *Much* stricter error handling, exit with non-zero
status (fail) on more error conditions, should they occur.
* gitclone (script): Check whether a given patch exists before applying. Works
around a quirk in most shells where `*` will error out if no files exist.
* download/grub (script): If downloading `gnulib` fails, scrap the *grub*
download aswell, and exit with non-zero status (fail). This is done because
gnulib is a dependency of GRUB.
* blobutil/inject (script): When inserting `gbe.bin`, check that the file
actually exists, and exit with non-zero status (fail) otherwise.
* blobutil/inject (script): When inserting `me.bin`, check that the given
path is defined and exit with non-zero status (fail) otherwise.
* blobutil/inject (script): Use x86 top-aligned MRC offset, when
inserting `mrc.bin` on Haswell ROM images (ThinkPad T440p/W541). Previously,
lbmk would insert them based on the offset as per ROM image file size, but
it is possible (and more reliable) to have cbfstool calculate that position
within the file based on where the ROM image would be loaded into memory.
The result is identical in practise (same checksum for the file), but this is
more robust for a future scenario where, for example, Libreboot might provide
different sized images. For example, if the flash were upgraded to 16MB rather
than 12MB on a T440p (Libreboot still only provides 12MB images for T440p).
* Coreboot build system: patch it to no longer warn about lack of payload
when building (patch courtesy of Nicholas Chin). Libreboot's build system is
designed to build ROM images without a payload, and then compile/add payloads
itself, as opposed to using the *coreboot* build system for payloads.
* Don't patch the build system for python2 anymore. Prefer python3, and use
it exclusively. No more python2 code was needed anymore, in lbmk's
dependencies.
* build/boot/roms (script): Fix faulty variable expansion for list of keymaps.
This fixes keymap handling when generating GRUB payloads for each keymap.
* The entire build system: massive code cleanup as alluded to above.
* Coreboot: Patched the coreboot device tree on Dell Latitude E6400, so that
the Nvidia GPU can be initialised properly (patch courtesy Nicholas Chin) -
only Intel GPU variants of E6400 are officially supported in this release.
* SeaBIOS payload: Provide `normal` config for setups where no VGA ROM init
from CBFS is provided, either in SeaBIOS or GRUB(via coreboot). This would
be used, for example, on desktops that lack onboard graphics, where it is
expected that a graphics card would be used.
* Fixed the Makefile to match current commands available in lbmk (use of
the Makefile is still optional, and direct use of lbmk is still recommended)
* Patched util `bios_extract` to work nicely with Dell E6400 update files,
patch courtesy of Nicholas Chin.
* New util: `bios_extract` (used to VGA ROM from Dell updates, for Nvidia GPU
model of Dell Latitude E6400, though this release only officially supports
the Intel GPU variant)
* Fixed unifont package info in Fedora 38 dependencies script
* util/e6400-flash-unlock: Minor code cleanup
* Don't force console mode in GRUB (reverses experimental change made in
the 20230423 release)
Hardware supported in this release
==================================
All of the following are believed to *boot*, but if you have any issues,
please contact the Libreboot project. They are:
Desktops (AMD, Intel, x86)
-----------------------
- [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
- [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
- [Apple iMac 5,2](../docs/hardware/imac52.md)
- [HP Elite 8200 SFF/MT](../docs/hardware/hp8200sff.md) (HP 6200 Pro Business probably works too)
- [HP Elite 8300 USDT](../docs/hardware/hp8300usdt.md)
### Laptops (Intel, x86)
- **[Dell Latitude E6400](../docs/hardware/e6400.md) (easy to flash, no disassembly, similar
hardware to X200/T400)**
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](../docs/hardware/r400.md)
- [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
- [Lenovo ThinkPad T500](../docs/hardware/t500.md)
- [Lenovo ThinkPad T530 / W530](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad W500](../docs/hardware/t500.md)
- [Lenovo ThinkPad R500](../docs/hardware/r500.md)
- [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
- [Lenovo ThinkPad T440p](../docs/install/t440p_external.md)
- [Lenovo Thinkpad X220](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X220t](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad T420](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T420S](../docs/install/ivy_has_common.md)
- [Lenovo ThinkPad T430](../docs/install/ivy_has_common.md)
- [Lenovo Thinkpad X230](../docs/install/x230_external.md)
- [Lenovo Thinkpad X230t](../docs/install/x230_external.md)
- [Lenovo ThinkPad W541](../docs/install/ivy_has_common.md)
- [HP EliteBook 2560p](../docs/hardware/hp2560p.md)
- [HP EliteBook 2570p](../docs/hardware/hp2570p.md)
- [HP EliteBook Folio 9470m](../docs/hardware/hp9470m.md)
### Laptops (ARM, with U-Boot payload)
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
Downloads
=========
You can find this release on the downloads page. At the time of this
announcement, some of the rsync mirrors may not have it yet, so please check
another one if your favourite one doesn't have it.
Post-release errata
===================
When building ROM images from the release archives, the following error
is observed in some cases, depending on distro:
```
In file included from src/lib/version.c:4:
build/build.h:10:32: error: 'libreboot' undeclared here (not in a function)
10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625
| ^~~~~~~~~
src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION'
35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION;
| ^~~~~~~~~~~~~~~~~~~~~~
```
This happened when a user tried to build for ThinkPad W541 on an Arch Linux
system. The fix is available here:
<https://browse.libreboot.org/lbmk.git/patch/?id=f34e07ae27e3e6e8508cdebcbd09fdf73fca302d>
Apply this patch to your local release archive, and it should fix the issue.

180
site/news/microcode.md
View File

@ -1,180 +0,0 @@
% No-microcode ROMs available in next Libreboot release (new stable release soon!)
% Leah Rowe
% 20 June 2023
**UPDATE: [Libreboot 20230625 was released](libreboot20230625.md)
on 25 June 2023, and it contains the change described in the text below.**
**The original article text from 20 June 2023 is as follows:**
As I write this, I'm quite close to providing a new stable release of Libreboot.
The final push to get it out the door is underway, with round-the-clock build
testing and general polishing.
Introduction
============
Firstly, what is microcode? In this context, CPU microcode is what configures
logic gates in the CPU to implement an instruction set. You can learn more
about microcode on the [FAQ](../faq.md#microcode) and
[here](policy.md#more-detailed-insight-about-microcode).
In the next Libreboot releases, ROM images that *exclude* CPU microcode updates
will once again be available. Libreboot's [Binary Blob Reduction
Policy](policy.md) dictates that each mainboard must be provided with as few
binary blobs as possible, ideally none. *At present*, *all* x86 and ARM
mainboards supported in Libreboot (in `lbmk.git` and in releases) can boot
with entirely [free software](https://writefreesoftware.org/),
requiring *zero* blobs of any kind from *coreboot*.
The nuance of how Libreboot *implements* this policy is described in
the [Freedom Status](../freedom-status.md) page. Although coreboot (which
Libreboot uses for hardware initialisation) *is* a
[free software](https://writefreesoftware.org/) project,
certain binary blobs are needed on some platforms, for things like raminit
(memory controller initialisation). Libreboot tries to reduce or eliminate
these, or mitigate their existence (for example, `me_cleaner` is used on newer
Intel platforms).
One exception made in that policy is that CPU microcode updates *must* be
provided by default, on all x86 mainboards. The ARM platforms do not use
microcode at all. This is a correct policy, because these updates fix critical
security and stability issues in the silicon; more information about that
can be found [here](policy.md#more-detailed-insight-about-microcode). Since
the CPU already has older microcode burned into mask ROM, it makes logical
sense to install these updates to get the latest bug fixes.
In a previous news post,
titled [GM45 no-microcode bug mitigations re-added](gm45microcode.md), I
announced that Libreboot had re-added certain mitigations, working around bugs
caused when microcode is removed on certain Intel GM45 platforms (e.g. X200 or
T400 ThinkPads).
Why?
----
Freedom of choice, that's why. Libreboot's policy explicitly
[states](policy.md#configuration), in the context of *adding* binary blobs:
*It’s natural that the user may want to create a setup that is less libre than
the default one in libreboot. This is perfectly acceptable; freedom is superior,
and should be encouraged, but the user’s freedom to choose should also be
respected, and accomodated.*
Well, this change simply applies that *principle* in reverse. Roughly speaking:
It's natural that some people may wish to cause random kernel panics, raminit
failures, thermal safety issues, random data corruption in memory, and other
similar issues commonly caused by lack of microcode updates. Such folly should
be discouraged, but the user's *freedom to choose* should also be respected,
and accomodated.
It is the official view of the Libreboot project that microcode updates do not
even qualify as *software*. The burned-in microcode *is* software, but the
updates only provide hotpatching, essentially turning on or off certain
features. The CPU already has older, buggier microcode burned into mask ROM,
so the choice is to either update it, or encounter more bugs. Regardless,
this is a point of contention for some people.
How?
----
The change was implemented by [this
patch](https://browse.libreboot.org/lbmk.git/commit/?id=f338697b96757977d2a14da00a91236595704fed)
on 19 June 2023, in the Libreboot build system.
In `board.cfg` for each mainboard defined (in Libreboot's build system, lbmk),
the following entries are available:
* `microcode_required="n" or "y"` (it's "n" on ALL boards)
* `blobs_required="n" or "y"`("n" on MOST boards)
If `blobs_required="n"`, the given ROM image `filename.rom`
becomes `filename_noblobs.bin` for all versions of it. In this
context, *noblobs* means *zero* blobs in the entire boot flash when the
final ROM image is flashed to it, regardless of whether coreboot is
blob-free, irrespective of microcode updates. ROM images
containing `noblobs` in the filename *may* still contain microcode
updates, distinguishing *microcode* as a special kind of blob distinct
from all others.
With or without `_noblobs` in the name:
If `microcode_required="n"`, the given ROM image `filename.rom`
is either:
* If no microcode blob exists within it already, such as on ARM
mainboards, the ROM is simply copied to: `filename_nomicrocode.rom`
* If the ROM contains microcode (default on most x86 boards, except Qemu
or in rare cases where none are advised), `filename.rom` is retained and
is copied to `filename_nomicrocode.rom`, and the CPU microcode update blob
shall be removed from `filename_nomicrocode.rom`.
What this means is that ROMs *with* OR *without* microcode will be present,
where applicable, on ROM images for each given mainboard. This will be the case
by default, for ROM images provided in the next release of Libreboot and all
releases that follow.
Example:
* `seabios_e6400_4mb_libgfxinit_txtmode_noblobs.rom`
* `seabios_e6400_4mb_libgfxinit_txtmode_noblobs_nomicrocode.rom`
It is *strongly* recommended, by the Libreboot project, that you
do *not* use the `_nomicrocode` ROMs on x86 mainboards. These updates
are *required* to implement stable x86 ISA, otherwise your CPU will behave
in strange, unpredictable ways, which could cause severe bugs in software
that cause *real* issues. Issues such as data loss.
More context
------------
A small but vocal minority of users are unhappy with the presence of these
microcode files, so it has been decided that the Libreboot project will once
again accomodate such users. This change has been implemented in the most
unintrusive way possible, to keep the build system logic clean, contrary to the
bloat that existed in many older Libreboot releases.
In previous releases of Libreboot, no-microcode was the default (microcode
updates were excluded entirely, from all releases). This policy was changed
during November 2022, as part of an ongoing campaign to support more hardware
(from coreboot) within Libreboot, so as to provide many more people with
coreboot which, regardless of blob status on each platform, *does* provide
increased software freedom compared to fully proprietary boot firmware, which
is what people would otherwise use; thus, Libreboot's modern policy is
pragmatic, advancing further the cause of *software freedom*.
By contrast, Libreboot's previous policy was to *ban all binary blobs*, which
meant that many mainboards from coreboot were excluded. This resulted in less
people achieving a level of software freedom, because to this day, nothing
quite like Libreboot exists with the scope and ambition that it has. Libreboot
makes coreboot as easy to use as possible for normal, non-technical people who
like the idea of coreboot, but are not competent to configure it from scratch.
Accordingly, the old Libreboot policy, prior to November 2022, *harmed* the
Free Software movement. Such harm was *corrected* in November 2022 and, going
forward, it is the intention of the Libreboot project to eventually have
build targets *for every mainboard that coreboot supports!*
ARM platforms
-------------
On ARM platforms, microcode is not used at all, so the `nomicrocode`
ROM images there are named simply according to what is already
the case.
Removing microcode also possible on older releases
==================================================
Libreboot releases *before* 20221214 excluded microcode by default, and did
not provide ROMs *with* microcode.
Libreboot 20221214, 20230319, 20230413 and 20230423 *include* microcode by
default, and do not provide no-microcode ROM images; however, removal is quite
simple:
cbfstool libreboot.rom remove -n cpu_microcode_blob.bin
Flash the resulting image. Again, expect *bugs*.
That is all.

540
site/news/policy.de.md
View File

@ -1,540 +0,0 @@
% Binäre Blob Reduktions Richtlinie
% Leah Rowe
% 4 January 2022 (updated 15 November 2022)
Einleitung
============
Dieser Artikel beschreibt die *Prinzipien* die das Libreboot Projekt definieren.
Für Informationen darüber *wie diese Prinzipien in der Praxis angewendet
werden*, bitte lies diesen Artikel stattdessen: [Software and hardware
freedom status for each mainboard supported by Libreboot](../freedom-status.md)
Libreboot's Richtlinie ist für jeden Benutzer so viel Software Freiheit
zu bieten wie möglich, auf jeglichem Bit von unterstützter Hardware, und
*so viel Hardware von Coreboot zu unterstützen wie möglich*; was dies
bedeutet ist, dass Du die Möglichkeit haben solltest, jeglichen Quelltext,
jegliche Dokumentation oder jegliche andere Ressource die Libreboot zu dem machen
was es ist, zu lesen, zu modifizieren und zu *teilen*. Einfach geasgt, Du
solltest *Kontrolle* haben über deine eigene Computernutzung.
Das *Ziel* von Libreboot ist es genau dies zu ermöglichen, und möglichst
vielen Benutzern zu helfen, mittels Automation der Konfiguration, Kompilierung
und Installation von *coreboot* für *technisch-unerfahrene* Benutzer, und
dies weiter zu vereinfachen für den durchschnittlichen Benutzer indem
benutzerfreundliche Anleitungen für alles zur Verfügung gestellt werden.
Grundsätzlich, Libreboot ist eine *coreboot Distribution*, ähnlich wie
*Alpine Linux* eine Linux Distribution ist!
Der Zweck diese Dokuments ist, zu skizzieren wie dies erzielt wird, und
wie das Projekt auf dieser Basis operiert. *Dieses* Dokument ist hauptsächlich
über die Ideologie und ist daher (größtenteils) nicht-technisch; für
technische Informationen schau in die [Libreboot build system
documentation](../docs/maintain/).
Derzeitiger Projektrahmen
=====================
Das Libreboot Projekt ist besorgt um das was in den Haupt Boot Flash IC geht,
aber es gibt andere Firmware Teile welche in Betracht gezogen werden sollten,
wie erläutert im [libreboot FAQ](../faq.md#what-other-firmware-exists-outside-of-libreboot).
Die kritischsten hiervon sind:
* Embedded controller firmware
* HDD/SSD firmware
* Intel Management Engine / AMD PSP firmware
Was ist ein binärer Blob?
----------------------
Ein binärer Blob, in diesem Zusammenhang, ist jegliches Ausführbares für
welches kein Quelltext existiert, welchen Du nicht in einer angemessenen
Form lesen und modifizieren darfst. Per Definition sind all diese Blobs
*proprietärer* Natur und sollten vermieden werden.
Bestimmte binäre Blobs sind ebenso problematisch, auf den meisten Coreboot
Systemen, aber sie unterscheiden sich von Maschine zu Maschine. Lies mehr
unter FAQ, oder auf dieser Seite wie wir mit diesen binären Blobs im
Libreboot Projekt umgehen.
Für Informationen über die Intel Management Engine und AMD PSP, schau unter
FAQ.
Blob *reduction* policy
=======================
Default configurations
----------------------
Coreboot, upon which Libreboot is based, is mostly libre software but does
require binary blobs on some platforms. A most common example might be raminit
(memory controller initialisation) or video framebuffer initialisation. The
coreboot firmware uses binary blobs for some of these tasks, on some mainboards,
but some mainboards from coreboot can be initialised with 100% libre source
code, which you can inspect, and compile for your use.
Libreboot deals with this situation in a *strict* and *principled* way. The
nature of this is what you're about to read.
The libreboot project has the following policy:
* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM
initialization otherwise does a better job but coreboot has *libre* init code
for a given graphics device, that code should be used in libreboot, when
building a ROM image. Similarly, if *memory controller initialization* is
possible with a binary blob *or* libre code in coreboot, the *libre* code
should be used in ROMs built by the Libreboot build system, and the *blob*
for raminit should not be used; however, if no libre init code is available
for said raminit, it is permitted and Libreboot build system will use the
*blob*.
* Some nuance is to be observed: on some laptop or desktop configurations, it's
common that there will be *two* graphics devices (for example, an nvidia and
an intel chip, using nvidia optimus technology, on a laptop). It may be that
one of them has libre init code in coreboot, but the other one does not. It's
perfectly acceptable, and desirable, for libreboot to support both devices,
and accomodate the required binary blob on the one that lacks native
initialization.
* An exception is made for CPU microcode updates: they are permitted, and in
fact *required* as per libreboot policy. These updates fix CPU bugs, including
security bugs, and since the CPU already has non-libre microcode burned into
ROM anyway, the only choice is either *x86* or *broken x86*. Thus, libreboot
will only allow coreboot mainboard configurations where microcode updates
are *enabled*, if available for the CPU on that mainboard.
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
* Intel Management Engine: in the libreboot documentation, words *must* be written
to tell people how to *neuter* the ME, if possible on a given board.
The `me_cleaner` program is very useful, and provides a much more secure ME
configuration.
* Binary blobs should *never* be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with binary
blobs for init tasks on many boards. These must *all* be included in libreboot
releases, even if unused. That way, even if the Libreboot build system does
not yet integrate support for a given board, someone who downloads libreboot
can still make changes to their local version of the build system, if they
wish, to provide a configuration for their hardware.
Generally speaking, common sense is applied. For example, an exception to the
minimalization might be if *blob* raminit and *libre* raminit are available, but
the *libre* one is so broken so as to be unusable. In that situation, the blob
one should be used instead, because otherwise the user might switch back to an
otherwise fully proprietary system, instead of using coreboot (via libreboot).
*Some* freedom is *better than none*.
Libreboot's pragmatic policies will inevitably result in more people becoming
coreboot developers in the future, by acting as that crucial *bridge* between
*it* and non-technical people who just need a bit of help to get started.
Configuration
-------------
The principles above should apply to *default* configurations. However, libreboot
is to be *configurable*, allowing the user to do whatever they like.
It's natural that the user may want to create a setup that is *less* libre than
the default one in libreboot. This is perfectly acceptable; freedom is superior,
and should be encouraged, but the user's *freedom to choose* should also be
respected, and accomodated.
In other words, do not lecture the user. Just try to help them with their
problem! The goal of the libreboot project is simply to make coreboot more
accessible for otherwise non-technical users.
FREEDOM CATALOG
===============
A *[freedom status](../freedom-status.md)* page should also be made available,
educating people about the status of binary blobs on each machine supported by
the Libreboot build system. Please read:
[Software and hardware freedom status for each mainboard supported by
Libreboot](../freedom-status.md).
It is desirable to see a world where all hardware and software is libre, under
the same ideology as the Libreboot project. Hardware!?
Yes, hardware. RISC-V is a great example of a modern attempt at libre hardware,
often called *Open Source Hardware*.
It is a an ISA for the manufacture of a microprocessor. Many real-world
implementations of it already exist, that can be used, and there will only be
more.
Such *hardware* is still in its infancy. We should start a project that will
catalog the status of various efforts, including at the hardware level (even
the silicon level). Movements like OSHW and Right To Repair are extremely
important, including to our own movement which otherwise will
typically think less about hardware freedoms (even though it really, really
should!)
One day, we will live in a world where anyone can get their own chips made,
including CPUs but also every other type of IC. Efforts to make homemade
chip fabrication a reality are now in their infancy, but such efforts do
exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
* <https://www.youtube.com/channel/UC7E8-0Ou69hwScPW1_fQApA>
* <http://sam.zeloof.xyz/>
* <https://libresilicon.com/>
(Sam literally makes CPUs in his garage)
Problems with RYF criteria
==========================
Libreboot previously complied with FSF RYF criteria, but it now adheres to a
much more pragmatic policy aimed at providing more freedom to more people, in a
more pragmatic way. You can read those guidelines by following this URL:
* FSF Respects Your Freedom (RYF) guidelines:
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
Put simply, the RYF guidelines pertain to commercial products, with the
stipulation that they must not contain proprietary software, or known privacy
issues like backdoors.
The total exclusion of all proprietary software is currently not feasible. For
example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
exception, to mitigate this fact:
* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
*This should be
rejected on ideological grounds*. The rest of libreboot's policy and overall
ideology expressed, in this article, will be based largely on that rejection.
The definition of *product software* is completely arbitrary; software is
software, and software should always be *libre*. Instead of making such
exceptions, more hardware should be encouraged, with help given to provide as
much freedom as possible, while providing education to users about any pitfalls
they may encounter, and encourage freedom at all levels. When an organisation
like the FSF makes such bold exceptions as above, it sends the wrong message,
by telling people essentially to sweep these other problems under the rug, just
because they involve software that happens to run on a "secondary processor".
If the software is possible to update by the user, then it should be libre,
regardless of whether the manufacturer *intended* for it to be upgraded or not.
Where it really *isn't* possible to update such software, proprietary or not,
advice should be given to that effect. Education is important, and the FSF's
criteria actively discourages such education; it creates a false hope that
everything is great and wonderful, just because the software on one arbitrary
level is all perfect.
This view of the FSF's, as expressed in the quoted paragraph, assumes that
there is primarily *one* main processor controlling your system. On many
modern computers, this is *no longer true*.
Libre *software* does not exist in a vacuum, but we had less freedom in the
past, especially when it came to hardware, so *software* was our primary focus.
The ability to study, adapt, share and use/re-use software freely is important,
but there is a lot of nuance when it comes to *boot firmware*, nuance which is
largely non-existent outside of firmware development, or kernel development.
Most typical application/system software is high level and portable, but boot
firmware has to be written for each specific machine, and due to the way
hardware works, there are many trade-offs made, including by the FSF when
defining what standards should apply *in practise*.
The fact that almost nobody talks about the EC firmware is *because* of the
Respects Your Freedom certification. In reality, the EC firmware is crucial
to user freedom, and ought to be free, but it is completely disregarded by
the FSF as *part of the hardware*. This is wrong, and the FSF should actively
encourage people to free it, on every laptop!
Other firmware currently outside the reach of the libreboot project are covered
in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
Again, completely disregarded and shrugged off by the FSF.
The libreboot project will not hide or overlook these issues, because they are
indeed critical, but again, currently outside the scope of what the Libreboot
build system does. At the moment, the Libreboot build system concerns itself
just with coreboot (and payloads), but this ought to change in the future.
Examples of FSF *sweeping blobs under the rug*
----------------------------------------------
Over the years, there have been numerous cases where the FSF actively fails to
provide incentive for levels of software freedom, such as:
* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
broadcom NIC inside it which requires firmware, and that firmware was non-free.
The FSF were willing to ignore it, and certify the TALOS II product under RYF,
but Timothy Pearson of Raptor Engineering had it freed anyway, without being
told to. Hugo Landau reverse engineered the specification and Evan Lojewski
wrote libre firmware. See:
See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
which contains the Intel ME; the bootrom is still there, as is the ME
coprocessor, but the ME is put into a disabled state via the Intel Flash
Descriptor, and the ME firmware in flash is removed. However, the ME is an
entire coprocessor which, with libre firmware, could be used for a great many
things. In the Libreboot and coreboot projects, there has always been interest
in this but the FSF disregards it entirely. The X200 product they certified
came with Libreboot pre-installed.
* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
descriptors and GbE NVM images from scratch. This is necessary to configure
the machine, but these are binary blobs otherwise; the FSF would have been
quite content to certify the hardware anyway since these were non-software
blobs in a format fully documented by Intel (they are just binary configuration
files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
more easily modify the descriptor/gbe regions for your firmware image. See:
<https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
GPU, it's possible to configure the machine so that either GPU is used. If the
ATI GPU is to be used, a firmware blob is needed for initialization, though the
driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
hardware, so long as Libreboot does not enable the ATI GPU or tell people how
to enable it. The *Intel* GPU on that machine has libre initialization code by
the coreboot project, and a fully libre driver in both Linux and BSD kernels.
In the configuration provided by Libreboot, the ATI GPU is completely disabled
and powered down.
* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
firmware, which is user-flashable (*and intended for update by the
manufacturer*). The FSF chose to ignore the EC firmware, under
their *secondary processor* exemption. See:
<http://libreboot.org/faq.html#ec-embedded-controller-firmware>
In all of the above cases, the FSF could have been stricter, and bolder, by
insisting that these *additional* problems for freedom were solved. They did
not. There are many other examples of this, but the purpose of this article is
not to list all of them (otherwise, a book could be written on the subject).
Problems with FSDG
------------------
<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
The FSF maintains another set of criteria, dubbed Free System Distribution
Guidelines (GNU FSDG)]
The FSDG criteria is separate from RYF, but has similar problems. FSDG is
what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
all proprietary software, including device firmware. This may seem noble, but
it's extremely problematic in the context of firmware. Food for thought:
* Excluding firmware blobs in the linux kernel is *bad*. Proprietary firmware
is *also bad*. Including them is a wiser choice, if strong education is also
provided about *why they are bad* (less freedom). If you expose them to
the user, and tell them about it, there is greater incentive (by simple
reminder of their existence) to reverse engineer and replace them.
* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
for hardware *with those same firmware blobs* if the firmware is embedded
into a ROM/flash chip on the device, or embedded in some processor. If the
firmware is on separate ROM/flash, it could still be replaced by the user via
reverse engineering, but then you would probably have to do some soldering
(replace the chip on the card/device). *If the firmware is loaded by the
OS kernel, then the firmware is exposed to the user and it can be more
easily replaced. FSF criteria in this regard encourages hardware designers
to hide the firmware instead, making actual (software) freedom less likely!*
Besides this, FSDG seems OK. Any libre operating system should ideally not
have proprietary *drivers* or *applications*.
Hardware manufacturers like to shove everything into firmware because their
product is often poorly designed, so they later want to provide workarounds in
firmware to fix issues. In many cases, a device will already have firmware on it
but require an update supplied to it by your OS kernel.
The most common example of proprietary firmware in Linux is for wifi devices.
This is an interesting use-case scenario, with source code, because it could be
used for owner-controlled *software defined radio*.
The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
by default, and they include extra firmware if needed, which they have in a
separate repository containing it. If you only want firmware, it is
trivial to get installer images with it included, or add that to your installed
system. They tell you how to do it, which means that they are helping people
to get *some* freedom *rather than none*. This is an inherently pragmatic
way to do things, and it's now how Libreboot does it.
More context regarding Debian is available in this blog post:
<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
author, a prominent Debian developer, makes excellent points about device
firmware similar to the (Libreboot) article that you're reading now. It's
worth a read! As of October 2022, Debian has voted to include device firmware
by *default*, in following Debian releases. It used to be that Debian excluded
such firmware, but allowed you to add it.
OpenBSD is very much the same, but they're clever about it: during the initial
boot, after installation, it tells you exactly what firmware is needed and
updates that for you. It's handled in a very transparent way, by
their `fw_update` program which you can read about here:
<https://man.openbsd.org/fw_update>
*Banning* linux-firmware specifically is a threat to freedom in the long term,
because new users of GNU+Linux might be discouraged from using the OS if their
hardware doesn't work. You might say: just buy new hardware! This is often not
possible for users, and the user might not have the skill to reverse engineer
it either.
More detailed insight about microcode
=====================================
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
To be clear: it is preferable that microcode be libre. The microcode on Intel
and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
purpose of this section is to spread *facts*.
The libreboot build system now enables microcode updates *by default.*
Not including CPU microcode updates is an absolute disaster for system
stability and security.
Making matters worse, that very same text quoted from the FSF RYF criteria in
fact specifically mentions microcode. Quoted again for posterity:
*"However, there is one exception for secondary embedded processors. The
exception applies to software delivered inside auxiliary and low-level
processors and FPGAs, within which software installation is not intended after
the user obtains the product. This can include, for instance, microcode inside
a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
The software in such secondary processors does not count as product software."*
Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
itself. It is simultaneously not giving the OK for microcode *updates* supplied
by either coreboot or the Linux kernel; according to the FSF, these are an
attack on your freedom, but the older, buggier microcode burned into ROM is OK.
The CPU already has microcode burned into mask ROM. The microcode configures
logic gates in the CPU, to implement an instruction set, via special *decoders*
which are fixed-function; it is not possible, for example, to implement a RISCV
ISA on an otherwise x86 processor. It is only possible for the microcode to
implement x86, or *broken* x86, and the default microcode is almost always
*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
these processors.
The FSF believes
that these x86 microcode updates (on Intel/AMD) allow you to completely create
a new CPU that is fundamentally different than x86. This is not true. It is also
not true that *all* instructions in x86 ISA are implemented with microcode. In
some cases, hardcoded circuitry is used! The microcode updates are more like
tiny one liner patches here and there in a git repository, by way of analogy.
To once again get in the head-space of the FSF: these updates cannot do the CPU
equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
more!
Not including these updates will result in an unstable/undefined state. Intel
themselves define which bugs affect which CPUs, and they define workarounds, or
provide fixes in microcode. Based on this, software such as the Linux kernel
can work around those bugs/quirks. Also, upstream versions of the Linux kernel
can update the microcode at boot time (however, it is recommend still to do it
from coreboot, for more stable memory controller initialization or “raminit”).
Similar can be said about AMD CPUs.
Here are some examples of where lack of microcode updates affected *Libreboot*,
forcing Libreboot to work around changes made upstream in coreboot, changes
that were *good* and made coreboot behave in a more standards-compliant manner
as per Intel specifications. Libreboot had to *break* coreboot to retain
certain other functionalities, on some GM45/ICH9M thinkpads:
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
These patches revert *bug fixes* in coreboot, fixes that happen to break other
functionality but only when microcode updates are excluded. The most
technically correct solution is to *not* apply the above patches, and instead
supply microcode updates!
Pick your poison. Not adding the updates is *irresponsible*, and ultimately
futile, because you still end up with proprietary microcode, but you just get
an older, buggier version instead!
This shift in project policy does not affect your freedom at all, because you
still otherwise have older, buggier microcode anyway. However, it does improve
system reliability by including the updates!
Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
had to endure. Simply put, the Libreboot project aims to give users as much
freedom as is possible for their hardware; this was always the case, but this
mentality is now applied to [a lot] more hardware.
Other considerations
====================
Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
the silicon level would however be amazing, and efforts already exist; for
example, look at the RISCV ISA (in practise, actual fabrication is still
proprietary and not under your control, but RISCV is a completely libre CPU
design that companies can use, instead of having to use proprietary ARM/x86 and
so on). Similarly, Right To Repair (ability to repair your own device, which
implies free access to schematics and diagrams) is critical, for the same
reason that Libre Software (Right To Hack) is critical!
OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
Freedom criteria), the criteria which Libreboot previously complied with.
RYF also makes several concessions that are ultimately damaging, such as
the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
software. There was a time when the FSF didn't consider BIOS software a freedom
issue, just because it was burned onto a mask ROM instead of *flashed*; those
FSF policies ignore the fact that, with adequate soldering skills, it is trivial
to replace stand-alone mask ROM ICs with compatible flash memory.
Conclusion
==========
RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
complied with, the result *does* give many freedoms to the user, but RYF
completely disregards many things that are now possible, including freedoms at
the hardware level (the RYF criteria only covers *software*). Those guidelines
are written with assumptions that were still true in the 1990s, but the world
has since evolved. The libreboot project rejects those policies in their
entirety, and instead takes a pragmatic approach.
The conclusion that should be drawn from all of this is as follows:
*Following* FSF criteria does not damage anything, but that criteria is very
conservative. Its exemptions should be *disregarded* and entirely ignored.
RYF is no longer fit for purpose, and should be rewritten to create
a *more strict* set of guidelines, without all the loopholes or exemptions.
As has always been the case, Libreboot tries to always go above and beyond, but
the Libreboot project does not see RYF as a *gold standard*. There are levels
of freedom possible now that the RYF guidelines do not cover at all, and in
some cases even actively discourage/dis-incentivize because it makes compromises
based on assumptions that are no longer true.
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
It sets a victory flag and says *mission accomplished*, despite the fact
that the work is *far* from complete!
If followed *with exemptions unchallenged*, RYF may in some cases encourage
companies to *sweep under the rug* any freedom issues that exist, where it
concerns proprietary firmware not running on the host CPU (such as the
Embedded Controller firmware).
I propose that new guidelines be written, to replace RYF. These new guidelines
will do away with all exemptions/loopholes, and demand that *all* software be
libre on the machine, or as much as possible. Instead of only promoting products
that meet some arbitrary standard, simply catalog all systems on a grand
*database* of sorts (like h-node.org, but better), which will define exactly
what *hardware* **and** software issues exist on each device. Include Right to
Repair and OSHW (including things like RISCV) in the most "ideal"
standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
and others are working on nowadays.
This new set of criteria should not attempt to hide or ignore *anything*. It
should encourage people to push the envelope and innovate, so that we can have
much *more* freedom than is currently possible. Necessity is the mother of all
invention, and freedom is an important goal in every aspect of life, not just
computing.
Don't call it "Respects Your Freedom" or something similar. Instead, call it
something like: the freedom catalog. And actually focus on hardware, not just
software!
Other resources
===============
Ariadne Conill's RYF blog post
------------------------------
Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
article about RYF, with similar points made when compared to *this* article.
However, Ariadne goes into detail on several other examples of problems with
the FSF RYF criteria; for example, it talks about the *Novena* product by
Bunnie.
It's worth a read! Link:
<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

546
site/news/policy.md
View File

@ -1,546 +0,0 @@
% Binary blob reduction policy
% Leah Rowe
% 4 January 2022 (updated 15 November 2022)
Introduction
============
This article describes the *principles* that govern the Libreboot project. For
information about *how those principles are applied in practise*, please read
this article instead: [Software and hardware freedom status for each mainboard
supported by Libreboot](../freedom-status.md)
Libreboot's policy is to provide as much
[software freedom](https://writefreesoftware.org/) as possible to each
user, on each and every bit of hardware supported, and to *support as much
hardware from coreboot as is feasible*; what this means is that you should
have the potential to study, modify and *share* all source code, documentation
or other such resources that make Libreboot what it is. Put simply, you should
have *control* of your own computing.
The *goal* of Libreboot is
to do exactly this, and help as many people as possible by automating the
configuration, compilation and installation of *coreboot* for *non-technical*
users, easing it further for the average user by providing user-friendly
instructions for everything. Essentially, Libreboot is a *coreboot
distribution*, in much the same way *Alpine Linux* is a Linux distribution!
The purpose of this document it to outline how that is brought about, and how
the project operates along this basis. *This* document is largely about the
ideology and it is therefore (mostly) non-technical; for technical information,
you can refer to the [Libreboot build system documentation](../docs/maintain/).
Current project scope
=====================
The libreboot project is concerned with what goes in the main boot flash IC, but
there are other pieces of firmware to take into consideration, as covered
in the [libreboot FAQ](../faq.md#what-other-firmware-exists-outside-of-libreboot).
Most critical of these are:
* Embedded controller firmware
* HDD/SSD firmware
* Intel Management Engine / AMD PSP firmware
What is a binary blob?
----------------------
A binary blob, in this context, is any executable for which no source code
exists, that you cannot study and modify in a reasonable manner. By definition,
all such blobs are *proprietary* in nature, and should be avoided if possible.
Specific binary blobs are also problematic, on most coreboot systems, but they
differ per machine. Read more on the FAQ, and on this page, for how we deal
with binary blobs in the Libreboot project.
For information about Intel Management Engine and AMD PSP, refer to the FAQ.
Blob *reduction* policy
=======================
Default configurations
----------------------
Coreboot, upon which Libreboot is based, is mostly libre software but does
require binary blobs on some platforms. A most common example might be raminit
(memory controller initialisation) or video framebuffer initialisation. The
coreboot firmware uses binary blobs for some of these tasks, on some mainboards,
but some mainboards from coreboot can be initialised with 100% libre source
code, which you can inspect, and compile for your use.
Libreboot deals with this situation in a *strict* and *principled* way. The
nature of this is what you're about to read.
The libreboot project has the following policy:
* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM
initialization otherwise does a better job but coreboot has *libre* init code
for a given graphics device, that code should be used in libreboot, when
building a ROM image. Similarly, if *memory controller initialization* is
possible with a binary blob *or* libre code in coreboot, the *libre* code
should be used in ROMs built by the Libreboot build system, and the *blob*
for raminit should not be used; however, if no libre init code is available
for said raminit, it is permitted and Libreboot build system will use the
*blob*.
* Some nuance is to be observed: on some laptop or desktop configurations, it's
common that there will be *two* graphics devices (for example, an nvidia and
an intel chip, using nvidia optimus technology, on a laptop). It may be that
one of them has libre init code in coreboot, but the other one does not. It's
perfectly acceptable, and desirable, for libreboot to support both devices,
and accomodate the required binary blob on the one that lacks native
initialization.
* An exception is made for CPU microcode updates: they are permitted, and in
fact *required* as per libreboot policy. These updates fix CPU bugs, including
security bugs, and since the CPU already has non-libre microcode burned into
ROM anyway, the only choice is either *x86* or *broken x86*. Thus, libreboot
will only allow coreboot mainboard configurations where microcode updates
are *enabled*, if available for the CPU on that mainboard.
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
* Intel Management Engine: in the libreboot documentation, words *must* be written
to tell people how to *neuter* the ME, if possible on a given board.
The `me_cleaner` program is very useful, and provides a much more secure ME
configuration.
* Binary blobs should *never* be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with binary
blobs for init tasks on many boards. These must *all* be included in libreboot
releases, even if unused. That way, even if the Libreboot build system does
not yet integrate support for a given board, someone who downloads libreboot
can still make changes to their local version of the build system, if they
wish, to provide a configuration for their hardware.
Generally speaking, common sense is applied. For example, an exception to the
minimalization might be if *blob* raminit and *libre* raminit are available, but
the *libre* one is so broken so as to be unusable. In that situation, the blob
one should be used instead, because otherwise the user might switch back to an
otherwise fully proprietary system, instead of using coreboot (via libreboot).
*Some* freedom is *better than none*.
Libreboot's pragmatic policies will inevitably result in more people becoming
coreboot developers in the future, by acting as that crucial *bridge* between
*it* and non-technical people who just need a bit of help to get started.
Configuration
-------------
The principles above should apply to *default* configurations. However, libreboot
is to be *configurable*, allowing the user to do whatever they like.
It's natural that the user may want to create a setup that is *less* libre than
the default one in libreboot. This is perfectly acceptable;
[freedom](https://writefreesoftware.org/) is superior,
and should be encouraged, but the user's *freedom to choose* should also be
respected, and accomodated.
In other words, do not lecture the user. Just try to help them with their
problem! The goal of the libreboot project is simply to make coreboot more
accessible for otherwise non-technical users.
FREEDOM CATALOG
===============
A *[freedom status](../freedom-status.md)* page should also be made available,
educating people about the status of binary blobs on each machine supported by
the Libreboot build system. Please read:
[Software and hardware freedom status for each mainboard supported by
Libreboot](../freedom-status.md).
It is desirable to see a world where all hardware and software is libre, under
the same ideology as the Libreboot project. Hardware!?
Yes, hardware. RISC-V is a great example of a modern attempt at libre hardware,
often called *Open Source Hardware*.
It is a an ISA for the manufacture of a microprocessor. Many real-world
implementations of it already exist, that can be used, and there will only be
more.
Such *hardware* is still in its infancy. We should start a project that will
catalog the status of various efforts, including at the hardware level (even
the silicon level). Movements like OSHW and Right To Repair are extremely
important, including to our own movement which otherwise will
typically think less about hardware freedoms (even though it really, really
should!)
One day, we will live in a world where anyone can get their own chips made,
including CPUs but also every other type of IC. Efforts to make homemade
chip fabrication a reality are now in their infancy, but such efforts do
exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
* <https://www.youtube.com/channel/UC7E8-0Ou69hwScPW1_fQApA>
* <http://sam.zeloof.xyz/>
* <https://libresilicon.com/>
(Sam literally makes CPUs in his garage)
Problems with RYF criteria
==========================
Libreboot previously complied with FSF RYF criteria, but it now adheres to a
much more pragmatic policy aimed at providing more freedom to more people, in a
more pragmatic way. You can read those guidelines by following this URL:
* FSF Respects Your Freedom (RYF) guidelines:
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
Put simply, the RYF guidelines pertain to commercial products, with the
stipulation that they must not contain proprietary software, or known privacy
issues like backdoors.
The total exclusion of all proprietary software is currently not feasible. For
example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
exception, to mitigate this fact:
* "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
*This should be
rejected on ideological grounds*. The rest of libreboot's policy and overall
ideology expressed, in this article, will be based largely on that rejection.
The definition of *product software* is completely arbitrary; software is
software, and software should always be *libre*. Instead of making such
exceptions, more hardware should be encouraged, with help given to provide as
much freedom as possible, while providing education to users about any pitfalls
they may encounter, and encourage freedom at all levels. When an organisation
like the FSF makes such bold exceptions as above, it sends the wrong message,
by telling people essentially to sweep these other problems under the rug, just
because they involve software that happens to run on a "secondary processor".
If the software is possible to update by the user, then it should be libre,
regardless of whether the manufacturer *intended* for it to be upgraded or not.
Where it really *isn't* possible to update such software, proprietary or not,
advice should be given to that effect. Education is important, and the FSF's
criteria actively discourages such education; it creates a false hope that
everything is great and wonderful, just because the software on one arbitrary
level is all perfect.
This view of the FSF's, as expressed in the quoted paragraph, assumes that
there is primarily *one* main processor controlling your system. On many
modern computers, this is *no longer true*.
Libre *software* does not exist in a vacuum, but we had less freedom in the
past, especially when it came to hardware, so *software* was our primary focus.
The ability to study, adapt, share and use/re-use software freely is important,
but there is a lot of nuance when it comes to *boot firmware*, nuance which is
largely non-existent outside of firmware development, or kernel development.
Most typical application/system software is high level and portable, but boot
firmware has to be written for each specific machine, and due to the way
hardware works, there are many trade-offs made, including by the FSF when
defining what standards should apply *in practise*.
The fact that almost nobody talks about the EC firmware is *because* of the
Respects Your Freedom certification. In reality, the EC firmware is crucial
to user freedom, and ought to be free, but it is completely disregarded by
the FSF as *part of the hardware*. This is wrong, and the FSF should actively
encourage people to free it, on every laptop!
Other firmware currently outside the reach of the libreboot project are covered
in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
Again, completely disregarded and shrugged off by the FSF.
The libreboot project will not hide or overlook these issues, because they are
indeed critical, but again, currently outside the scope of what the Libreboot
build system does. At the moment, the Libreboot build system concerns itself
just with coreboot (and payloads), but this ought to change in the future.
Examples of FSF *sweeping blobs under the rug*
----------------------------------------------
Over the years, there have been numerous cases where the FSF actively fails to
provide incentive for levels of software freedom, such as:
* TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
broadcom NIC inside it which requires firmware, and that firmware was non-free.
The FSF were willing to ignore it, and certify the TALOS II product under RYF,
but Timothy Pearson of Raptor Engineering had it freed anyway, without being
told to. Hugo Landau reverse engineered the specification and Evan Lojewski
wrote libre firmware. See:
See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
* FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
which contains the Intel ME; the bootrom is still there, as is the ME
coprocessor, but the ME is put into a disabled state via the Intel Flash
Descriptor, and the ME firmware in flash is removed. However, the ME is an
entire coprocessor which, with libre firmware, could be used for a great many
things. In the Libreboot and coreboot projects, there has always been interest
in this but the FSF disregards it entirely. The X200 product they certified
came with Libreboot pre-installed.
* Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
descriptors and GbE NVM images from scratch. This is necessary to configure
the machine, but these are binary blobs otherwise; the FSF would have been
quite content to certify the hardware anyway since these were non-software
blobs in a format fully documented by Intel (they are just binary configuration
files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
more easily modify the descriptor/gbe regions for your firmware image. See:
<https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
* FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
GPU, it's possible to configure the machine so that either GPU is used. If the
ATI GPU is to be used, a firmware blob is needed for initialization, though the
driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
hardware, so long as Libreboot does not enable the ATI GPU or tell people how
to enable it. The *Intel* GPU on that machine has libre initialization code by
the coreboot project, and a fully libre driver in both Linux and BSD kernels.
In the configuration provided by Libreboot, the ATI GPU is completely disabled
and powered down.
* All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
firmware, which is user-flashable (*and intended for update by the
manufacturer*). The FSF chose to ignore the EC firmware, under
their *secondary processor* exemption. See:
<http://libreboot.org/faq.html#ec-embedded-controller-firmware>
In all of the above cases, the FSF could have been stricter, and bolder, by
insisting that these *additional* problems for freedom were solved. They did
not. There are many other examples of this, but the purpose of this article is
not to list all of them (otherwise, a book could be written on the subject).
Problems with FSDG
------------------
<img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
The FSF maintains another set of criteria, dubbed Free System Distribution
Guidelines (GNU FSDG)]. They recommend a special version of the Linux kernel,
dubbed *linux-libre*, which removes all firmware blobs from upstream. These
firmware blobs are required for certain hardware to work correctly.
The FSDG criteria is separate from RYF, but has similar problems. FSDG is
what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
all proprietary software, including device firmware. This may seem noble, but
it's extremely problematic in the context of firmware.
*Banning* linux-firmware specifically is a threat to freedom in the long term,
because new users of GNU+Linux might be discouraged from using the OS if their
hardware doesn't work. You might say: just buy new hardware! This is often not
possible for users, and the user might not have the skill to reverse engineer
it either. **Banning such firmware constitutes
*[censorship](https://en.wikipedia.org/wiki/Book_burning)*, in the name of
freedom, but all it does is reduce freedom of choice; somebody else has already
made that decision for you, *against* you.** You should not use linux-libre at
all. Some wisdom:
* Excluding firmware blobs in the linux kernel is *bad*. Proprietary firmware
is *also bad*. Including them is a wiser choice, if strong education is also
provided about *why they are bad* (less freedom). If you expose them to
the user, and tell them about it, there is greater incentive (by simple
reminder of their existence) to reverse engineer and replace them.
* Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
for hardware *with those same firmware blobs* if the firmware is embedded
into a ROM/flash chip on the device, or embedded in some processor. If the
firmware is on separate ROM/flash, it could still be replaced by the user via
reverse engineering, but then you would probably have to do some soldering
(replace the chip on the card/device). *If the firmware is loaded by the
OS kernel, then the firmware is exposed to the user and it can be more
easily replaced. FSF criteria in this regard encourages hardware designers
to hide the firmware instead, making actual (software) freedom less likely!*
Besides this, FSDG seems OK. Any libre operating system should ideally not
have proprietary *drivers* or *applications*. Libreboot *previously* adhered
to FSDG, but now takes a more pragmatic approach when it comes to things like
CPU microcode or *EC firmware*.
Hardware manufacturers like to shove everything into firmware because their
product is often poorly designed, so they later want to provide workarounds in
firmware to fix issues. In many cases, a device will already have firmware on it
but require an update supplied to it by your OS kernel.
The most common example of proprietary firmware in Linux is for wifi devices.
This is an interesting use-case scenario, with source code, because it could be
used for owner-controlled *software defined radio*.
The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
by default, and they include extra firmware if needed, which they have in a
separate repository containing it. If you only want firmware, it is
trivial to get installer images with it included, or add that to your installed
system. They tell you how to do it, which means that they are helping people
to get *some* freedom *rather than none*. This is an inherently pragmatic
way to do things, and it's now how Libreboot does it.
More context regarding Debian is available in this blog post:
<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
author, a prominent Debian developer, makes excellent points about device
firmware similar to the (Libreboot) article that you're reading now. It's
worth a read! As of October 2022, Debian has voted to include device firmware
by *default*, in following Debian releases. It used to be that Debian excluded
such firmware, but allowed you to add it.
OpenBSD is very much the same, but they're clever about it: during the initial
boot, after installation, it tells you exactly what firmware is needed and
updates that for you. It's handled in a very transparent way, by
their `fw_update` program which you can read about here:
<https://man.openbsd.org/fw_update>
OpenBSD is great.
More detailed insight about microcode
=====================================
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
To be clear: it is preferable that microcode be libre. The microcode on Intel
and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
purpose of this section is to spread *facts*.
The libreboot build system now enables microcode updates *by default.*
Not including CPU microcode updates is an absolute disaster for system
stability and security.
Making matters worse, that very same text quoted from the FSF RYF criteria in
fact specifically mentions microcode. Quoted again for posterity:
*"However, there is one exception for secondary embedded processors. The
exception applies to software delivered inside auxiliary and low-level
processors and FPGAs, within which software installation is not intended after
the user obtains the product. This can include, for instance, microcode inside
a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
The software in such secondary processors does not count as product software."*
Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
itself. It is simultaneously not giving the OK for microcode *updates* supplied
by either coreboot or the Linux kernel; according to the FSF, these are an
attack on your freedom, but the older, buggier microcode burned into ROM is OK.
The CPU already has microcode burned into mask ROM. The microcode configures
logic gates in the CPU, to implement an instruction set, via special *decoders*
which are fixed-function; it is not possible, for example, to implement a RISCV
ISA on an otherwise x86 processor. It is only possible for the microcode to
implement x86, or *broken* x86, and the default microcode is almost always
*broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
these processors.
The FSF believes
that these x86 microcode updates (on Intel/AMD) allow you to completely create
a new CPU that is fundamentally different than x86. This is not true. It is also
not true that *all* instructions in x86 ISA are implemented with microcode. In
some cases, hardcoded circuitry is used! The microcode updates are more like
tiny one liner patches here and there in a git repository, by way of analogy.
To once again get in the head-space of the FSF: these updates cannot do the CPU
equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
more!
Not including these updates will result in an unstable/undefined state. Intel
themselves define which bugs affect which CPUs, and they define workarounds, or
provide fixes in microcode. Based on this, software such as the Linux kernel
can work around those bugs/quirks. Also, upstream versions of the Linux kernel
can update the microcode at boot time (however, it is recommend still to do it
from coreboot, for more stable memory controller initialization or “raminit”).
Similar can be said about AMD CPUs.
Here are some examples of where lack of microcode updates affected *Libreboot*,
forcing Libreboot to work around changes made upstream in coreboot, changes
that were *good* and made coreboot behave in a more standards-compliant manner
as per Intel specifications. Libreboot had to *break* coreboot to retain
certain other functionalities, on some GM45/ICH9M thinkpads:
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
These patches revert *bug fixes* in coreboot, fixes that happen to break other
functionality but only when microcode updates are excluded. The most
technically correct solution is to *not* apply the above patches, and instead
supply microcode updates!
Pick your poison. Not adding the updates is *irresponsible*, and ultimately
futile, because you still end up with proprietary microcode, but you just get
an older, buggier version instead!
This shift in project policy does not affect your freedom at all, because you
still otherwise have older, buggier microcode anyway. However, it does improve
system reliability by including the updates!
Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
had to endure. Simply put, the Libreboot project aims to give users as much
freedom as is possible for their hardware; this was always the case, but this
mentality is now applied to [a lot] more hardware.
Other considerations
====================
Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
the silicon level would however be amazing, and efforts already exist; for
example, look at the RISCV ISA (in practise, actual fabrication is still
proprietary and not under your control, but RISCV is a completely libre CPU
design that companies can use, instead of having to use proprietary ARM/x86 and
so on). Similarly, Right To Repair (ability to repair your own device, which
implies free access to schematics and diagrams) is critical, for the same
reason that Libre Software (Right To Hack) is critical!
OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
Freedom criteria), the criteria which Libreboot previously complied with.
RYF also makes several concessions that are ultimately damaging, such as
the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
software. There was a time when the FSF didn't consider BIOS software a freedom
issue, just because it was burned onto a mask ROM instead of *flashed*; those
FSF policies ignore the fact that, with adequate soldering skills, it is trivial
to replace stand-alone mask ROM ICs with compatible flash memory.
Conclusion
==========
RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
complied with, the result *does* give many freedoms to the user, but RYF
completely disregards many things that are now possible, including freedoms at
the hardware level (the RYF criteria only covers *software*). Those guidelines
are written with assumptions that were still true in the 1990s, but the world
has since evolved. The libreboot project rejects those policies in their
entirety, and instead takes a pragmatic approach.
The conclusion that should be drawn from all of this is as follows:
*Following* FSF criteria does not damage anything, but that criteria is very
conservative. Its exemptions should be *disregarded* and entirely ignored.
RYF is no longer fit for purpose, and should be rewritten to create
a *more strict* set of guidelines, without all the loopholes or exemptions.
As has always been the case, Libreboot tries to always go above and beyond, but
the Libreboot project does not see RYF as a *gold standard*. There are levels
of freedom possible now that the RYF guidelines do not cover at all, and in
some cases even actively discourage/dis-incentivize because it makes compromises
based on assumptions that are no longer true.
Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
It sets a victory flag and says *mission accomplished*, despite the fact
that the work is *far* from complete!
If followed *with exemptions unchallenged*, RYF may in some cases encourage
companies to *sweep under the rug* any freedom issues that exist, where it
concerns proprietary firmware not running on the host CPU (such as the
Embedded Controller firmware).
I propose that new guidelines be written, to replace RYF. These new guidelines
will do away with all exemptions/loopholes, and demand that *all* software be
libre on the machine, or as much as possible. Instead of only promoting products
that meet some arbitrary standard, simply catalog all systems on a grand
*database* of sorts (like h-node.org, but better), which will define exactly
what *hardware* **and** software issues exist on each device. Include Right to
Repair and OSHW (including things like RISCV) in the most "ideal"
standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
and others are working on nowadays.
This new set of criteria should not attempt to hide or ignore *anything*. It
should encourage people to push the envelope and innovate, so that we can have
much *more* freedom than is currently possible. Necessity is the mother of all
invention, and freedom is an important goal in every aspect of life, not just
computing.
Don't call it "Respects Your Freedom" or something similar. Instead, call it
something like: the freedom catalog. And actually focus on hardware, not just
software!
Other resources
===============
Ariadne Conill's RYF blog post
------------------------------
Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
article about RYF, with similar points made when compared to *this* article.
However, Ariadne goes into detail on several other examples of problems with
the FSF RYF criteria; for example, it talks about the *Novena* product by
Bunnie.
It's worth a read! Link:
<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

532
site/news/policy.uk.md
View File

@ -1,532 +0,0 @@
% Політика зменшення бінарних блобів
% Лія Роу
% 4 січня 2022 року (оновлено 15 листопада 2022 року)
Вступ
============
У цій статті описано *принципи*, які керують проектом Libreboot. Щоб отримати
інформацію про те, *як ці принципи застосовуються на практиці*, прочитайте
натомість цю статтю: [Статус свободи програмного та апаратного забезпечення для
кожної материнської плати, що підтримується Libreboot](../freedom-status.uk.md)
Політика Libreboot полягає в тому, щоб надати настільки, наскільки можливо, свободи
кожному користувачу, на кожному підтримуваному апаратному забезпеченні та *підтримувати
стільки апаратного забезпечення з coreboot, наскільки це можливо*; це означає, що ви повинні
мати можливість вивчати, змінювати та *ділитися* всім джерельним кодом, документацією
чи іншими подібними ресурсами, які роблять Libreboot таким, яким він є. Простіше кажучи, ви повинні
мати *контроль* над своїми власними обчисленнями.
*Мета* Libreboot полягає в тому, щоб
зробити саме це та допомогти якомога більшій кількості людей, автоматизувавши
конфігурацію, компіляцію та встановлення *coreboot* для *нетехнічних*
користувачів, ще більше спростивши це для звичайного користувача, надаючи користувачам
дружні інструкції для всього. По суті, Libreboot - це *дистрибутив
coreboot*, приблизно так само, як *Alpine Linux* є дистрибутивом Linux!
Метою цього документа є окреслення того, як це досягається, і як
проект працює на цій основі. *Цей* документ здебільшого стосується
ідеології, тому він (переважно) нетехнічний; для отримання технічної інформації
ви можете звернутися до [документації системи збірки Libreboot](../docs/maintain/).
Поточний обсяг проекту
=====================
Проект libreboot стосується того, що входить до основної мікросхеми завантажувальної флеш-пам'яті,
але є й інші компоненти мікропрограми, які слід взяти до уваги, про що йдеться
в [поширених запитаннях щодо libreboot](../faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot).
Найбільш критичні з них це:
* Прошивка вбудованого контролера (EC)
* Прошивка жорстких дисків/твердотілих накопичувачів
* Прошивка Intel Management Engine / AMD PSP
Що таке двійковий блоб?
----------------------
Двійковий блоб у цьому контексті - це будь-який виконуваний файл, для якого не існує вихідного коду,
який ви не можете досліджувати та змінювати розумним чином. За визначенням,
усі такі блоби є *пропрієтарними* за своєю природою, і їх слід уникати, якщо це можливо.
Конкретні двійкові блоби також є проблематичними в більшості систем coreboot, але вони
відрізняються для кожної машини. Дізнайтесь більше в розділі поширених запитань і на цій сторінці про те,
як ми працюємо з двійковими блобами в проекті Libreboot.
Для інформації про Intel Management Engine та AMD PSP зверніться до поширених запитань.
Політика *зменшення* блобів
=======================
Конфігурації за замовчуванням
----------------------
Coreboot, на якому Libreboot базується, є здебільшого вільним програмним забезпеченням, але
на деяких платформах вимагає двійкових блобів. Найпоширенішим прикладом може бути raminit
(ініціалізація контролера пам'яті) або ініціалізація кадрового буфера відео. Прошивка
coreboot використовує двійкові блоби для деяких з цих завдань, на деяких материнських платах,
але деякі материнські плати з coreboot можна ініціалізувати з 100% вільним джерельним
кодом, який ви можете перевірити та скомпілювати для свого використання.
Libreboot вирішує цю ситуацію *суворо* та *принципово*. Природа
цього - це те, що ви збираєтесь прочитати.
Проект libreboot має наступну політику:
* Якщо блоб *можна* уникнути, його слід уникати. Наприклад, якщо ініціалізація VGA ROM
в іншому випадку працює краще, але coreboot має *вільний* код ініціалізації
для певного графічного пристрою, цей код слід використовувати в libreboot під
час створення образу ROM. Подібним чином, якщо *ініціалізація контролера пам'яті* можлива
за допомогою бінарного блобу *або* вільного коду в coreboot, *вільний* код
слід використовувати в ROM, створених системою збірки Libreboot, а *блоб*
для raminit не слід використовувати; однак, якщо вільний код ініціалізації недоступний
для зазначеного raminit, це дозволено, і система збірки Libreboot використовуватиме
*блоб*.
* Необхідно звернути увагу на деякі нюанси: у деяких конфігураціях ноутбуків або настільних комп'ютерів
зазвичай буде *два* графічних пристрої (наприклад, чіп nvidia та
чіп intel, використовуючи технологію nvidia optimus technology, на ноутбуці). Можливо,
один із них має вільний код ініціалізації в coreboot, а інший - ні. Абсолютно
прийнятно і бажано, щоб libreboot підтримував обидва пристрої та
розміщував необхідний двійковий блоб на тому, якому бракує власної
ініціалізації.
* Виняток зроблено для оновлень мікрокоду ЦП: вони дозволені та фактично
*обов'язкові* відповідно до політики libreboot. Ці оновлення виправляють помилки ЦП, у тому
числі помилки безпеки, і оскільки ЦП уже має невільний мікрокод, записаний в
ROM в будь-якому випадку, єдиний вибір - *x86* або *зламаний x86*. Таким чином, libreboot
дозволить лише конфігурації материнської плати coreboot, де
*ввімкнено* оновлення мікрокоду, якщо доступно для ЦП на цій системній платі.
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
* Intel Management Engine: у документації libreboot *повинні* бути написані
слова, щоб розповісти людям, як *нейтралізувати* ME, якщо це можливо на даній дошці.
Програма `me_cleaner` є дуже корисною та забезпечує набагато безпечнішу конфігурацію
ME.
* Бінарні блоби *ніколи* не слід видаляти, навіть якщо вони не використовуються.
У проекті coreboot доступний набір субмодулів `3rdparty` з бінарними блобами
для завдань ініціалізації на багатьох платах. *Усі* вони повинні бути включені до випусків
libreboot, навіть якщо вони не використовуються. Таким чином, навіть якщо система збірки Libreboot
ще не підтримує певну плату, хтось, хто завантажує libreboot, все одно
може внести зміни у свою локальну версію системи збірки, якщо
забажає, щоб надати конфігурацію свого апаратного забезпечення.
Загалом, застосовано здоровий глузд. Наприклад, винятком
із мінімізації може бути те, що *блоб* raminit та *вільний* raminit доступні, але
*вільний* так зламано, що його не можна використовувати. У такій ситуації натомість
слід використовувати той, що з блобом, тому що в іншому випадку користувач може повернутися до
повністю пропрієтарної системи замість використання coreboot (через libreboot).
*Деякі* свободи *краще, ніж жодних*.
Нова прагматична політика Libreboot також може призвести до того, що в майбутньому більше людей стануть
розробниками coreboot, виступаючи в якості важливого *містка* між
*ним* і нетехнічними людьми, яким просто потрібна допомога, щоб розпочати роботу.
Налаштування
-------------
Наведені вище принципи мають застосовуватися до конфігурацій *за замовчуванням*. Однак libreboot
має бути *конфігурованим*, дозволяючи користувачеві робити все, що заманеться.
Цілком природно, що користувач може захотіти створити *менш* вільний параметр, ніж
стандартний у libreboot. Це цілком прийнятно; свобода вище,
і її слід заохочувати, але *свободу вибору* користувача
також слід поважати та пристосовуватись до неї.
Іншими словами, не читайте лекції користувачеві. Просто спробуйте допомогти їм у
їхній проблемі! Метою проекту libreboot є просто зробити coreboot більш
доступним для нетехнічних користувачів.
КАТАЛОГ СВОБОДИ
===============
Також має бути доступна сторінка *[статусу блобів](../freedom-status.uk.md)*,
яка інформуватиме людей про статус бінарних блобів на кожній машині, що
підтримується системою збірки Libreboot. Дивіться:
[Статус свободи програмного та апаратного забезпечення для кожної плати, яка
підтримується Libreboot](../freedom-status.uk.md)
Бажано бачити світ, де все апаратне та програмне забезпечення є вільним, під
тією ж ідеологією, що й проект Libreboot. Обладнання!?
Так, обладнання. RISC-V є чудовим прикладом сучасної спроби вільного апаратного забезпечення, яке
часто називають *Апаратним забезпеченням з відкритим кодом*.
Це ISA для виробництва мікропроцесора. Уже існує багато реальних
реалізацій, які можна використовувати, і їх буде лише
більше.
Таке *апаратне забезпечення* ще знаходиться в зародковому стані. Ми повинні почати проект, який
буде каталогізувати статус різних зусиль, у тому числі на апаратному рівні (навіть на
рівні кремнію). Такі рухи, як OSHW і Право на ремонт (Right To Repair), є надзвичайно
важливими, включно з нашим власним рухом, який інакше зазвичай менше думатиме про свободу апаратного
забезпечення (хоча йому справді, справді
варто!)
Одного дня ми житимемо у світі, де будь-хто зможе виготовити власні чіпи,
включаючи процесори, а також будь-які інші типи мікросхем. Зусилля зробити домашнє виробництво
чіпів реальністю зараз знаходяться в зародковому стані, але такі зусилля існують,
наприклад, робота, виконана Семом Зелофом і проектом Libre Silicon:
* <https://www.youtube.com/channel/UC7E8-0Ou69hwScPW1_fQApA>
* <http://sam.zeloof.xyz/>
* <https://libresilicon.com/>
(Сем буквально виробляє процесори в своєму гаражі)
Проблеми з критеріями RYF
==========================
Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
* Рекомендації FSF Поважає Вашу Свободу (RYF):
<https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
як-от лазівки.
Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
пропрієтарне мікропрограмне забезпечення SDR у чіпсетах WiFi, мікропрограмне забезпечення пристроїв AHCI, таких як
жорсткі диски або твердотілі накопичувачі тощо. В інструкціях FSF RYF зазначено наступний виняток, щоб пом'якшити цей факт:
* "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і низькорівневих процесорах та FPGA, у яких встановлення програмного забезпечення не передбачається після того, як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA. Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."
*та має бути відхилено
з ідеологічних міркувань*. Решта політики libreboot і загальна
ідеологія, виражена в цій статті, базуватиметься в основному на цьому неприйнятті.
Визначення *програмного забезпечення продукту* абсолютно довільне; програмне забезпечення
є програмне забезпечення, а програмне забезпечення завжди має бути *вільним*. Замість того, щоб робити такі
винятки, слід заохочувати більше апаратного забезпечення, допомогаючи надавати якомога
більше свободи, одночасно надаючи користувачам інформацію про будь-які підводні
камені, з якими вони можуть зіткнутися, і заохочувати свободу на всіх рівнях. Коли така організація,
як FSF, робить такі сміливі винятки, як вище, вона надсилає неправильне повідомлення,
кажучи людям, по суті, заховати ці інші проблеми лише тому, що вони стосуються програмного забезпечення,
яке працює на "вторинному процесорі".
Якщо користувач може оновити програмне забезпечення, воно має бути вільним,
незалежно від того, *передбачав* виробник оновлення чи ні.
Там де справді *не* можливо оновити таке програмне забезпечення, пропрієтарне чи ні,
слід надати поради щодо цього. Освіта важлива, і критерії FSF
активно перешкоджають такій освіті; це створює помилкову надію, що
все добре і чудово, лише тому, що програмне забезпечення на одному довільному
рівні ідеальне.
Цей погляд FSF, виражений у цитованому абзаці, припускає,
що системою керує переважно *один* головний процесор. На багатьох
сучасних комп'ютерах це *більше не відповідає дійсності*.
Вільне *програмне забезпечення* не існує у вакуумі, але ми мали менше свободи в
минулому, особливо коли справа стосувалася апаратного забезпечення, тому *ПЗ* було нашим основним фокусом.
Здатність вільно вивчати, адаптувати, обмінюватися та використовувати/повторно використовувати ПЗ є важливою,
але є багато нюансів, коли справа доходить до *завантажувального мікропрограмного забезпечення*, нюансів, які
здебільшого не існують поза розробкою мікропрограмного забезпечення чи поза розробкою ядра.
Більшість типового прикладного/системного програмного забезпечення є високорівневим і портативним, але
завантажувальна мікропрограма має бути написана для кожної конкретної машини, і через те, як
апаратне забезпечення працює, існує багато компромісів, зокрема FSF, коли
визначає які стандарти слід застосовувати *на практиці*.
Той факт, що майже ніхто не говорить про прошивку EC, *пов'язаний* із
сертифікацією Поважає Вашу Свободу (Respects Your Freedom). Насправді мікропрограмне забезпечення EC має вирішальне
значення для свободи користувачів і повинно бути вільним, але FSF повністю ігнорує його як
*частину апаратного забезпечення*. Це неправильно, і FSF має активно
заохочувати людей визволяти його на кожному ноутбуці!
Інше мікропрограмне забезпечення, яке наразі не доступне для проекту libreboot, описано на
сторінці поширених питань libreboot. Наприклад, прошивка жорстких дисків/твердотілих накопичувачів описана в розділі поширених запитань.
Знову ж таки, повністю проігноровано та знизано плечима FSF.
Проект libreboot не буде приховувати або пропускати ці проблеми, тому що вони
справді є критичними, але, знову ж таки, наразі виходять за межі того, що робить система збірки Libreboot
На даний момент, система збірки Libreboot займається лише
coreboot (і корисними навантаженнями), але в майбутньому це має змінитися.
Приклади *замітання блобів під килим* FSF
----------------------------------------------
Протягом багатьох років було багато випадків, коли FSF активно не
заохочував рівень свободи програмного забезпечення, наприклад:
* Робоча станція TALOS II "OpenPOWER" від Raptor Engineering USA. Вона містить
мережеву плату Broadcom в собі, яка потребує прошивки, і ця прошивка була невільною.
FSF були готові проігнорувати це та сертифікувати продукт TALOS II відповідно до RYF,
але Тімоті Пірсон із Raptor Engineering все одно звільнив її, хоча йому навіть
про це не було сказано. Гуго Ландау розробив специфікацію, а Еван Лоєвскі
написав вільну прошивку. Дивіться:
<https://www.devever.net/~hl/ortega> та <https://github.com/meklort/bcm5719-fw>
* FSF свого часу схвалив ThinkPad X200, який продавав [Minifree Ltd](https://minifree.org),
який містить Intel ME; bootrom все ще там, як і співпроцесор ME,
але ME переведено в вимкнений стан через Intel Flash
Descriptor, а мікропрограму ME у флеш-пам'яті видалено. Однак ME - це цілий
співпроцесор, який з вільною прошивкою можна було би використовувати для багатьох
речей. У проектах Libreboot та coreboot завжди був інтерес до цього,
але FSF повністю ігнорує це. Продукт X200, який вони сертифікували,
постачався з попередньо встановленим Libreboot.
* У Libreboot є утиліта, написана мною, Лією Роу, яка створює флеш-дескриптори ICH9M і образи
GbE NVM з нуля. Це необхідно для налаштування
машини, але інакше це двійкові блоб-файли; FSF був би цілком
задоволений сертифікацією апаратного забезпечення в будь-якому випадку, оскільки це були непрограмні
блоби у форматі, повністю задокументованому Intel (це лише двійкові конфігураційні
файли), але я все одно пішла вперед і написала ich9gen. За допомогою ich9gen ви можете
легше змінювати регіони дескриптора/gbe для вашого образу мікропрограмного забезпечення. Дивіться:
<https://libreboot.org/docs/install/ich9utils.html> - libreboot також має це
* FSF свого часу схвалив ThinkPad T400 з Libreboot, який продавав Minifree. Ця
машина доступна в двох версіях: з графічним процесором ATI+Intel або лише Intel. Якщо ATI
GPU, можна налаштувати машину так, щоб використовувався будь-який GPU. Якщо буде використовуватися
графічний процесор ATI, для ініціалізації потрібен блоб мікропрограми, хоча драйвер для нього
повністю вільний. *FSF* проігнорувала цей факт і схвалила апаратне забезпечення,
доки Libreboot не вмикає графічний процесор ATI і не повідомляє людям, як його
увімкнути. Графічний процесор *Intel* на цій машині має вільний код ініціалізації
від проекту coreboot і повністю вільний драйвер в обох ядрах Linux та BSD.
У конфігурації, наданій Libreboot, ATI GPU повністю вимкнено
та виключено.
* Усі ноутбуки ThinkPad, сумісні з Libreboot, містять невільне мікропрограмне забезпечення вбудованого контролера,
яке можна прошивати користувачем (*і призначене для оновлення
виробником*). FSF вирішила ігнорувати прошивку EC, відповідно до
свого винятку *вторинного процесора*. Дивіться:
<http://libreboot.org/faq.uk.html#прошивка-ec-вбудований-контролер>
У всіх вищезазначених випадках FSF міг бути суворішим і сміливішим, наполягаючи
на тому, що ці *додаткові* проблеми свободи були вирішені. Вони цього не
зробили. Є багато інших прикладів цього, але мета цієї статті
не перелічити їх усі (інакше на цю тему можна були б написати книгу).
Проблеми з FSDG
------------------
<img tabindex=1 src="https://av.libreboot.org/firmware.uk.png" /><span class="f"><img src="https://av.libreboot.org/firmware.uk.png" /></span>
FSF підтримує ще один набір критеріїв, які називаються Правилами вільного
розповсюдження системи (GNU FSDG)]
Критерії FSDG відрізняються від RYF, але мають подібні проблеми. FSDG - це
те, чому відповідають схвалені FSF дистрибутиви GNU+Linux. По суті, він забороняє
все пропрієтарне програмне забезпечення, включаючи мікропрограму пристрою. Це може здатися благородним, але
вкрай проблематично в контексті прошивки. Їжа для роздумів:
* Виключення мікропрограмним блобів із ядра linux - це *погано*. Пропрієтарна прошивка
є *також поганою*. Включення їх є мудрішим вибором, якщо також забезпечується сильна освіта
про те, *чому вони погані* (менше свободи). Якщо ви відкриєте їх для
користувача та повідомите йому про це, з'явиться більше стимулів (через просте
нагадування про їх існування) провести зворотне проектування та замінити їх.
* Прошивка *в ядрі вашої ОС* *хороша*. FSF одночасно дає дозвіл на
апаратне забезпечення *з тими самими блобами прошивки*, якщо прошивка вбудована в
ROM/флеш-пам'ять на пристрої або вбудована в якийсь процесор. Якщо
вбудоване програмне забезпечення знаходиться на окремому ROM/флеш-пам'яті, його все одно можна замінити
користувачем за допомогою зворотного проектування, але тоді вам, ймовірно, доведеться провести деяку пайку
(замінити чіп на картці/пристрої). *Якщо мікропрограма завантажується ядром
ОС, тоді вона відкрита для користувача, і її можна легше замінити.
Критерії FSF у цьому відношенні заохочують розробників апаратного забезпечення
приховувати вбудоване програмне забезпечення, що робить фактичну (програмну) свободу менш імовірною!*
Окрім цього, FSDG здається нормальним. Будь-яка вільна операційна система має в ідеалі не містити
пропрієтарних *драйверів* або *застосунків*.
Виробники обладнання полюбляють заштовхувать все в мікропрограмне забезпечення, оскільки їх
продукт часто має поганий дизайн, тому вони пізніше хочуть надати вирішення в
прошивці для налагодження проблемних питань. В багатьох випадках, пристрій вже матиме прошивку в собі,
але вимагає оновлення, надане йому вашим ядром ОС.
Найбільш поширений приклад пропрієтарної прошивки в Linux для пристроїв wifi.
Це цікавий сценарій використання, з джерельним кодом, тому що його може бути
використано для контрольованого власником *software defined radio*.
Шлях *Debian* є ідеальним. Дистрибутив Debian GNU+Linux повністю вільний
за замовчуванням, і вони включають додаткову прошивку за необхідності, яку вони мають в
окремому репозиторії, що містить її. Якщо ви хочете тільки прошивку, тривіально
взяти образи встановлювача з нею доданою, або додати її до вашої встановленої
системи. Вони розповідають вам, як зробити це, що означає, що вони допомогають людям
отримати *деяку* свободу, *замість ніякої*. Це невід'ємно прагматичний
спосіб робити справи, і це те, як це робить Libreboot.
Більше контексту, стосовно Debian, доступно в публікації цього блога:
<https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - в ньому, автор,
відомий розробник Debian, робить чудовий акцент про прошивку
пристроїв, подібну до статті (Libreboot), яку ви зараз читаєте. Її
варто прочитати! Станом на жовтень 2022 року, Debian проголосував за включення прошивки пристроїв
за *замовчуванням*, в наступних випусках Debian. Раніше Debian виключав таке
мікропрограмне забезпечення, але дозволяв вам його додавати.
OpenBSD майже така сама, але вони розумні в цьому: під час початкового
завантаження, після інсталяції, він повідомляє вам, яке мікропрограмне забезпечення потрібно,
і оновляє його для вас. Це дуже прозоро обробляється їхньою
програмою `fw_update`, про яку ви можете прочитати тут:
<https://man.openbsd.org/fw_update>
*Заборона* прошивки linux конкретно є загрозою свободі в довгостроковій перспективі,
тому що нові користувачі GNU+Linux можуть бути відбиті від використання ОС, якщо їх
апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
для користувачів, і користувач також може не мати навичок для
зворотного проектування.
Більш детальна інформація про мікрокод
=====================================
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
та AMD *є* пропрієтарним. Факти і почуття рідко збігаються; метою цього
розділу є поширення *фактів*.
Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
та безпеки системи.
Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
насправді конкретно згадує мікрокод. Знову процитую для нащадків:
*"Однак є один виняток для вторинних вбудованих процесорів. Виняток
стосується програмного забезпечення, що постачається всередині допоміжних і низкорівневих
процесорів та FPGA, у яких інсталяція програмного забезпечення не передбачається після того,
як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA.
Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
Тут обговорюється мікрокод, який записується в *mask ROM* на самому
ЦП. Одночасно він не дає ОК для *оновлень* мікрокоду, які надаються
coreboot або ядром Linux; згідно з FSF, це напад на
вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери*,
які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
на процесорі x86. Для мікрокода можливо тільки
реалізувати x86, або *зламаний* x86, і мікрокод за замовчуваням майже завжди є
*зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
процесорів.
FSF вважає,
що ці оновлення мікрокоду x86 (для Intel/AMD) дозволяють повністю створити новий
ЦП, який принципово відрізняється від x86. Це не правда. Також неправда,
що *всі* інструкції в наборі інструкцій x86 реалізовано за допомогою мікрокоду. У
деяких випадках використовується жорстко закодована схема! Оновлення мікрокоду більше нагадують
крихітні одиничні патчі тут і там у сховищі git, за аналогією.
Щоб знову потрапити у головний простір FSF: ці оновлення не можуть зробити ЦП
еквівалентом рефакторингу всієї кодової бази. Це *гарячі виправлення*, нічого
більше!
Невиключення цих оновлень призведе до нестабільного/невизначеного стану. Intel
сама визначає, які помилки впливають на які ЦП, і вони визначають обхідні шляхи або надають
виправлення в мікрокоді. Виходячи з цього, таке програмне забезпечення, як ядро Linux
може обійти ці помилки/примхи. Крім того, апстрім версії ядра Linux
можуть оновити мікрокод під час завантаження (однак все одно рекомендується робити це
з coreboot для більш стабільної ініціалізації контролера пам'яті або “raminit”).
Подібне можна сказати і про ЦП AMD.
Ось кілька прикладів того, як відсутність оновлень мікрокоду вплинула на *Libreboot*,
змусивши Libreboot обійти зміни, внесені в апстрім coreboot, зміни,
які були *хорошими* і зробили coreboot більш сумісним зі стандартами відповідно до
специфікацій Intel. Libreboot довелося *поламати* coreboot, щоб зберегти деякі
інші функції на деяких Thinkpad GM45/ICH9M:
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
Ці патчі повертають *виправлення помилок* у coreboot, виправлення, які порушують
інші функції, але лише якщо оновлення мікрокоду виключено. Найбільш
правильним з технічної точки зору рішенням є *не* застосування наведених вище патчів, а натомість
оновлення мікрокоду!
Виберіть свою отруту. Недодавання оновлень є *безвідповідальним* і, зрештою,
марним, оскільки ви все одно отримуєте пропрієтарний мікрокод, ви просто отримуєте
старішу, з більшими помилками, версію натомість!
Ця зміна в політиці проекту зовсім не впливає на вашу свободу,
тому що в іншому випадку ви все одно маєте старіший мікрокод із більшими помилками. Однак він покращує
надійність системи, включаючи оновлення!
Така прагматична політика *перевершує* *догму*, яку колись
доводилося терпіти користувачам Libreboot. Простіше кажучи, проект Libreboot має на меті надати користувачам
якомога більше свободи для їх апаратного забезпечення; так було завжди,
але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
Інші міркування
====================
Також Libreboot не покриває суворо: OSHW і Право на ремонт (Right To Repair). Однак свобода
на рівні кремнію була б дивовижною, і зусилля вже є; наприклад, подивіться на RISCV ISA (на
практиці фактичне виготовлення все ще є пропрієтарним і не під вашим контролем, але RISCV є повністю вільним
дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
передбачає вільний доступ до схем і діаграм) є критично важливим з тієї ж причини, що
критично важливо вільне програмне забезпечення (Право на хакерство)!
OSHW і Право на ремонт взагалі не охоплюються RYF (критерії FSF Поважає Вашу
Свободу), критеріями, яких Libreboot дотримувався раніше..
RYF також робить кілька поступок, які зрештою завдають шкоди, наприклад,
політика *програмне забезпечення як схема*, яка, чесно кажучи, є безглуздою. ROM все ще
програмне забезпечення. Був час, коли FSF не вважав програмне забезпечення BIOS проблемою
свободи, лише тому, що воно записане на mask ROM, а не *прошито*; ця
політика FSF ігнорує той факт, що, маючи відповідні навички паяння, легко замінити
автономні мікросхеми mask ROM на сумісну флеш-пам'ять.
Висновки
==========
RYF сам по собі не є *неправильним*, просто має недоліки. Певним чином це правильно, і
якщо його дотримуватися, результат *надає* багато свобод користувачеві, але RYF
повністю ігнорує багато речей, які зараз можливі, включаючи свободи на
апаратному рівні (критерії RYF охоплюють лише *програмне забезпечення*). Ці вказівки
написані з припущеннями, які все ще були вірними в 1990-х роках, але відтоді
світ змінився. Проект libreboot повністю відкидає цю політику та натомість
використовує прагматичний підхід.
Висновок, який слід зробити з усього цього, такий:
*Дотримання* критеріїв FSF нічого не шкодить, але ці критерії є дуже
консервативними. Його винятки слід *ігнорувати* та повністю ігнорувати. RYF
більше не відповідає меті, і його слід переписати, щоб створити *більш суворий*
набір інструкцій без усіх лазівок чи винятків.
Як завжди було, Libreboot намагається завжди виходити за межі, але
проект Libreboot не розглядає RYF як *золотий стандарт*. Зараз є
можливі рівні свободи, які вказівки RYF взагалі не охоплюють, а
в деяких випадках навіть активно не заохочують/перешкоджають, оскільки це робить компроміси
на основі припущень, які більше не відповідають дійсності.
Сумна правда: RYF активно заохочує *менше* свободи, не будучи достатньо сміливим.
Він встановлює прапор перемоги та говорить *місію виконано*, незважаючи на те, що
робота *далека* від завершення!
Якщо дотримуватись *з незаперечними винятками*, RYF може в деяких випадках заохочувати
компанії *приховувати* будь-які проблеми зі свободою, які існуюють,
коли це стосується пропрієтарного мікропрограмного забезпечення, яке не працює на центральному процесорі хоста (наприклад, мікропрограмне забезпечення
вбудованого контролера).
Я пропоную написати нові рекомендації, щоб замінити RYF. Ці нові правила
ліквідують усі винятки/лазівки та вимагають, щоб *все* програмне забезпечення
було вільним на машині або якомога більше. Замість того, щоб лише рекламувати продукти,
які відповідають певним стандартам, просто каталогізуйте всі системи у великій
*базі даних* свого роду (наприклад, h-node.org, але краще), яка точно визначатиме, які
*апаратні* **і** програмні проблеми існують на кожному пристрої. Включіть Право
на ремонт і OSHW (включно з такими речами, як RISCV) до найбільш "ідеальної"
стандартної машини; золотим стандартом є вільний *кремній*, як те, над чим
Сем Зелоф та інші працюють зараз.
Цей новий набір критеріїв не повинен намагатися приховати або проігнорувати *щось*. Це
має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
винаходів, а свобода є важливою метою в кожному аспекті життя, не лише в
обчисленні.
Не називайте це "Поважає вашу свободу" чи щось подібне. Натомість назвіть це
приблизно так: каталог свободи. І насправді зосередьтеся на апаратному забезпеченні, а не
лише на програмному забезпеченні!
Інші ресурси
===============
Повідомлення в блозі RYF Аріадни Конілл
------------------------------
Аріадна Конілл, голова групи безпеки *Alpine Linux*, опублікувала дуже серйозну
статтю про RYF, у якій висловлено схожі моменти в порівнянні з *цією* статтею.
Однак Аріадна докладно розглядає кілька інших прикладів проблем із
критеріями FSF RYF; наприклад, йдеться про продукт *Novena* від
Bunnie.
Варто прочитати! Посилання:
<https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>

137
site/news/safety.md
View File

@ -1,137 +0,0 @@
% Safety issues updating Libreboot on Sandybridge/Ivybridge/Haswell
% Leah Rowe
% 7 July 2023
Introduction
============
As I write this post, [Libreboot 20230625](libreboot20230625.md) recently came
out. There's technically nothing unsafe about the release itself, but certain
users have been bricking their machines, on the following mainboards:
* Sandybridge platforms (e.g. ThinkPad X220, T420)
* Ivybridge platforms (e.g. ThinkPad X230, T430)
* Haswell platforms (e.g. ThinkPad T440p, W541)
Why?
----
On these platforms, the following binary blobs are required:
* Intel ME firmware: all Sandy/Ivy/Haswell boards. Libreboot's build system
runs `me_cleaner` to neuter the Intel ME, so that it's disabled after BringUp.
* Intel MRC firmware: Haswell platforms (W541, T440p) - a libre MRC replacement
is available, but experimental, and the blob version is still recommended.
* KBC1126 EC firmware: HP laptops (all sandy/ivy/haswell)
When you [build Libreboot from source](../docs/build/), Libreboot's automated
build system (lbmk) automatically downloads these blobs directly from the
hardware vendor, and inserts them into the ROM during build time.
However, these blobs are not redistributable, so Libreboot's build system (lbmk)
automatically scrubs (deletes) these blobs, from each ROM image, prior to
archiving the ROM images for release.
What this means is exactly as implied:
If you simply flash the release ROMs as-is, *without* modification, you will
be flashing them *without* these required blobs. This is exactly what some
people have been doing.
Instructions are given here, for how to insert these blobs on release ROMs:
[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)
The linked guide makes use of `blobutil`, lbmk's single centralised utility that
handles *all* firmwares, automatically for each given mainboard. It can
automatically download and insert all of the following:
* Intel ME firmware
* Intel MRC firmware
* KBC1126 EC firmware
* VGA ROM for Nvidia GPU, on Nvidia variant of Dell Latitude E6400 (which is
still, as of this post, not in lbmk's master branch, but available in a
different branch of lbmk, though the logic for downloading the VGA ROM and
inserting it *is* included in lbmk master)
More information is available in the guide.
What can be done to reduce the risk?
------------------------------------
Like I said, there's technically nothing wrong with recent Libreboot releases.
The main problem is that Libreboot *documentation* did not prominently warn
about this issue. Such warnings *were* available on Libreboot, but were not
prominently displayed. Such warnings are now littered all throughout the
Libreboot documentation, even mentioned in bold lettering at the top of the
downloads page, so there's no way a user can miss it.
Other mitigations considered
-----------------------------
See: <https://codeberg.org/libreboot/lbmk/issues/92>
In this issue page, I outline ways to further reduce the risk. On the platforms
affected by this, the flash is divided into the following regions:
* IFD region
* GbE region
* ME region
* BIOS region
The IFD region configures the machine, and specifies read/write capability for
host CPU when flashing all regions, including IFD.
GbE contains NIC configuration, including MAC address, for intel gigabit NIC.
ME region is Intel ME firmware.
BIOS region is coreboot.
Per the issue page, I intend to implement the following regime in future
Libreboot releases, on the affected machines:
* If BIOS region blob-free (no MRC/EC firmware needed): set IFD, GbE and BIOS
regions read-write by default, but lock the ME region.
* If BIOS region requires blobs inserted: set IFD and GbE regions read-write
by default, but lock the ME and BIOS regions.
In this configuration, internal flashing would still be possible, so that you
do not have to disassemble the machine, but *two* flashes would be needed:
* Firstly, re-flash IFD that unlocks ME/BIOS regions
* Then ensure that the ROMs are properly prepared, and re-flash the entire
ROM with IFD once again re-flashed to set ME and/or BIOS region read-only.
Under this configuration, we would still have the reality where some people
don't read documentation, but if they don't read documentation, they will
then just run flashrom on ROM images as-is, and it won't work. This will cause
one of three possible scenarios:
* They don't bother updating, and therefore avoid bricking their machine
* They complain on IRC/reddit, and we point them to instructions for how to
deal with it - then they update their machine, and likely don't brick it
anymore.
* They read the documentation from the start.
Under this regime, some users may still brick their machines. For example,
they might read the instructions for how to unlock regions, and then still
flash a ROM image without running `blobutil` on it - there is nothing we
can really do to prevent this, short of simply locking *all* regions, including
the IFD region (if we did that, then users would need to externally re-flash
their machine when updating).
Libreboot's policy is to make updates as easy as possible, but these extra
precautions are required on the newer Intel platforms.
When this is implemented in Libreboot, this page will be updated, and info
about it will be added to the installation/update instructions. I'm also
considering whether to apply this change *retroactively* on older release ROMs,
for all of these releases: 20221214, 20230319, 20230413, 20230423 and 20230625.
That's all for now. Please take care when updating or installing Libreboot.
Libreboot is generally well-tested and with good release engineering, but you
must ALWAYS read the documentation. This is true of any software, but it is
*especially* true of Libreboot. Please take care not to brick your machine.
Thanks!

2
site/news/usa-libre-part2.md
View File

@ -9,7 +9,7 @@ This article makes use of the term *libre software*, which has the same meaning
as more popular terms such as *open source software*
or *[free software](https://writefreesoftware.org/)*
or *free and open source software*. More information can be found about
it [here](https://en.wikipedia.org/wiki/Open_source) - to the Libreboot
it [here](https://writefreesoftware.org/) - to the Libreboot
project, this is important because it talks about your *freedom* to study,
adapt, share and re-use software as you see fit, alongside the rest of
humanity in a collective development effort, as opposed to the alternative

25
site/template.de.include
View File

@ -69,7 +69,6 @@ $endif$
<ul>
<li><a href="/index.de.html">Home</a></li>
<li><a href="/faq.html">FAQ</a></li>
<li><strong><a href="/freedom-status.html">Freiheits Status</a></strong></li>
<li><strong><a href="/download.html">Download</a></strong></li>
<li><a href="/docs/install/">Installation</a></li>
<li><a href="/docs/">Dokumentation</a></li>
@ -99,6 +98,30 @@ $body$
$for(include-after)$
$include-after$
$endfor$
<span class="fcc" style="background:#fcc;color:#000;text-shadow:none;position:fixed;bottom:0;left:0;right:0; font-size:0.8em;">
<style type="text/css">
.fcc *{color:#000;}
.fcc a{color:#007;}
.fcc:hover > a{background:none;}
.page{padding-bottom:50em;}
</style>
<p>
This website is a representation of the state <a href="https://libreboot.org/">Libreboot</a> would be in today if it still
followed the old <a href="https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html">binary blob extermination policy</a>.
Libreboot switched to a <a href="https://libreboot.org/news/policy.html">binary blob reduction policy</a>
so as to provide software freedom to more people, on more hardware. The version you're
looking at now has reduced hardware support, and proves a point: that <a href="https://libreboot.org/news/policy.html#problems-with-fsdg">GNU FSDG</a>
and <a href="https://libreboot.org/news/policy.html#problems-with-ryf-criteria">FSF RYF</a> policy is a form a censorship. An
<a href="news/censored-libreboot20230710.html">actual release</a> is available, based
on <a href="https://libreboot.org/news/libreboot20230625.html">Libreboot 20230625</a>.
</p>
<p>
Censorship? <a href="/censorship.html">Look here</a> for a list of pages that
were deleted, or had information deleted, to make this. It also explains how
the software itself was modified, in the release. This *censored* version will be
updated every time there's a regular Libreboot release.
</p>
</span>
$if(toc)$
</div>
$endif$

25
site/template.include
View File

@ -69,7 +69,6 @@ $endif$
<ul>
<li><a href="/">Home</a></li>
<li><a href="/faq.html">FAQ</a></li>
<li><strong><a href="/freedom-status.html">Freedom status</a></strong></li>
<li><strong><a href="/download.html">Download</a></strong></li>
<li><a href="/docs/install/">Install</a></li>
<li><a href="/docs/">Docs</a></li>
@ -99,6 +98,30 @@ $body$
$for(include-after)$
$include-after$
$endfor$
<span class="fcc" style="background:#fcc;color:#000;text-shadow:none;position:fixed;bottom:0;left:0;right:0; font-size:0.8em;">
<style type="text/css">
.fcc *{color:#000;}
.fcc a{color:#007;}
.fcc:hover > a{background:none;}
.page{padding-bottom:50em;}
</style>
<p>
This website is a representation of the state <a href="https://libreboot.org/">Libreboot</a> would be in today if it still
followed the old <a href="https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html">binary blob extermination policy</a>.
Libreboot switched to a <a href="https://libreboot.org/news/policy.html">binary blob reduction policy</a>
so as to provide software freedom to more people, on more hardware. The version you're
looking at now has reduced hardware support, and proves a point: that <a href="https://libreboot.org/news/policy.html#problems-with-fsdg">GNU FSDG</a>
and <a href="https://libreboot.org/news/policy.html#problems-with-ryf-criteria">FSF RYF</a> policy is a form a censorship. An
<a href="news/censored-libreboot20230710.html">actual release</a> is available, based
on <a href="https://libreboot.org/news/libreboot20230625.html">Libreboot 20230625</a>.
</p>
<p>
Censorship? <a href="/censorship.html">Look here</a> for a list of pages that
were deleted, or had information deleted, to make this. It also explains how
the software itself was modified, in the release. This *censored* version will be
updated every time there's a regular Libreboot release.
</p>
</span>
$if(toc)$
</div>
$endif$

25
site/template.uk.include
View File

@ -69,7 +69,6 @@ $endif$
<ul>
<li><a href="/index.uk.html">Домашня</a></li>
<li><a href="/faq.html">FAQ</a></li>
<li><strong><a href="/freedom-status.html">Статус свободи</a></strong></li>
<li><strong><a href="/download.uk.html">Завантаження</a></strong></li>
<li><a href="/docs/install/">Встановлення</a></li>
<li><a href="/docs/index.uk.html">Документація</a></li>
@ -99,6 +98,30 @@ $body$
$for(include-after)$
$include-after$
$endfor$
<span class="fcc" style="background:#fcc;color:#000;text-shadow:none;position:fixed;bottom:0;left:0;right:0; font-size:0.8em;">
<style type="text/css">
.fcc *{color:#000;}
.fcc a{color:#007;}
.fcc:hover > a{background:none;}
.page{padding-bottom:50em;}
</style>
<p>
This website is a representation of the state <a href="https://libreboot.org/">Libreboot</a> would be in today if it still
followed the old <a href="https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html">binary blob extermination policy</a>.
Libreboot switched to a <a href="https://libreboot.org/news/policy.html">binary blob reduction policy</a>
so as to provide software freedom to more people, on more hardware. The version you're
looking at now has reduced hardware support, and proves a point: that <a href="https://libreboot.org/news/policy.html#problems-with-fsdg">GNU FSDG</a>
and <a href="https://libreboot.org/news/policy.html#problems-with-ryf-criteria">FSF RYF</a> policy is a form a censorship. An
<a href="news/censored-libreboot20230710.html">actual release</a> is available, based
on <a href="https://libreboot.org/news/libreboot20230625.html">Libreboot 20230625</a>.
</p>
<p>
Censorship? <a href="/censorship.html">Look here</a> for a list of pages that
were deleted, or had information deleted, to make this. It also explains how
the software itself was modified, in the release. This *censored* version will be
updated every time there's a regular Libreboot release.
</p>
</span>
$if(toc)$
</div>
$endif$

25
site/template.zh-cn.include
View File

@ -69,7 +69,6 @@ $endif$
<ul>
<li><a href="/">主页</a></li>
<li><a href="/faq.html">常见问题</a></li>
<li><strong><a href="/freedom-status.html">自由度现状</a></strong></li>
<li><strong><a href="/download.html">下载</a></strong></li>
<li><a href="/docs/install/">安装</a></li>
<li><a href="/docs/">文档</a></li>
@ -99,6 +98,30 @@ $body$
$for(include-after)$
$include-after$
$endfor$
<span class="fcc" style="background:#fcc;color:#000;text-shadow:none;position:fixed;bottom:0;left:0;right:0; font-size:0.8em;">
<style type="text/css">
.fcc *{color:#000;}
.fcc a{color:#007;}
.fcc:hover > a{background:none;}
.page{padding-bottom:50em;}
</style>
<p>
This website is a representation of the state <a href="https://libreboot.org/">Libreboot</a> would be in today if it still
followed the old <a href="https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html">binary blob extermination policy</a>.
Libreboot switched to a <a href="https://libreboot.org/news/policy.html">binary blob reduction policy</a>
so as to provide software freedom to more people, on more hardware. The version you're
looking at now has reduced hardware support, and proves a point: that <a href="https://libreboot.org/news/policy.html#problems-with-fsdg">GNU FSDG</a>
and <a href="https://libreboot.org/news/policy.html#problems-with-ryf-criteria">FSF RYF</a> policy is a form a censorship. An
<a href="news/censored-libreboot20230710.html">actual release</a> is available, based
on <a href="https://libreboot.org/news/libreboot20230625.html">Libreboot 20230625</a>.
</p>
<p>
Censorship? <a href="/censorship.html">Look here</a> for a list of pages that
were deleted, or had information deleted, to make this. It also explains how
the software itself was modified, in the release. This *censored* version will be
updated every time there's a regular Libreboot release.
</p>
</span>
$if(toc)$
</div>
$endif$