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

more stragglers 

a big cleanup was needed, based on recent changes

Signed-off-by: Leah Rowe <leah@libreboot.org>
master
Leah Rowe 2023-10-10 21:37:16 +01:00
parent 3f3b501c6a
commit a918978371
39 changed files with 248 additions and 275 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
site/contrib.md
View File

@ -47,7 +47,7 @@ Caleb La Grange
with a narrower focus. Caleb focuses on several areas of development:
* Build system. Caleb is responsible for improving and fixing the libreboot Make build
system. Specifically: binary blob management, automation, and reproducibility.
system. Specifically: automation, and reproducibility.
* Hardware modification. Caleb has a passion for hardware alteration; soldering,
desoldering, and testing libreboot software on the resulting hardware.
* Board porting. Anything supported in Coreboot can be ported to libreboot, Caleb
@ -212,14 +212,6 @@ FSF would take me seriously, and I said yes. This is what started the early
work on Libreboot. Joshua showed me all the problems my products had, and from
that, the solution was clear:
A project needed to exist, providing a fully free version of coreboot, without
any binary blobs. At the time (and this is still true today), coreboot was not
entirely libre software and shipped with binary blobs by default. In particular,
CPU microcode updates were included by default, on all x86 machines. Working
with Joshua who reviewed my work, I created a fully free version of coreboot.
At first, it wasn't called Libreboot, and the work was purely intended for my
company (at that time called Gluglug) to be promoted by the FSF.
Joshua used his media connections at the FSF to heavily promote my work, and
on December 13th, 2013, the Libreboot project was born (but not called that).
Joshua made sure that everyone knew what I was doing!

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

@ -91,7 +91,7 @@ functionality, though this configuration has not yet been encountered.
Most people will want to use the 4MiB images.
Intel GPU: Blob-free setup (no-ME possible)
Intel GPU: 100% Free Software is possible
---------------
This is a GM45/PM45 platform, so completely libre initialisation in

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

@ -74,7 +74,7 @@ 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
[Insert vendor files 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

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

@ -113,7 +113,7 @@ 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
[Insert vendor files 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

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

@ -106,7 +106,7 @@ 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
[Insert vendor files 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

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

@ -90,7 +90,7 @@ 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
[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell
platforms](../install/ivy_has_common.md)
You can now flash libreboot:

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

@ -60,7 +60,7 @@ 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
[Insert vendor files 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

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

@ -27,7 +27,7 @@ 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)**
**[Insert vendor files 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*
@ -121,8 +121,8 @@ from 2021.01 is known to work, for u-boot on this board. See:\
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
**WARNING: daisy- and peach- boards require a BL1 bootloader firmware, but the
one from coreboot 3rdparty is a fake/placeholder file. 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

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

@ -133,7 +133,7 @@ Prepare the ROM image
Libreboot ROM image layouts are currently incompatible with the regions
that should be carried over from the stock firmware. However, the
released images should still be somewhat usable, since the Chromebooks
supported so far don't require any non-redistributable blobs to be
supported so far don't require any non-redistributable code to be
injected by the end user.
Future Libreboot versions will likely require post-processing to
@ -146,7 +146,7 @@ Flash the ROM image
===================
WARNING: Although none are supported yet, make sure not to flash ROM
images on x86 Chromebooks without injecting non-redistributable blobs
images on x86 Chromebooks without injecting non-redistributable code
first (like Intel ME firmware). This is not yet documented here.
You can flash the ROM image both internally and externally. For the

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

@ -25,10 +25,10 @@ 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)
100% Free Software possible (Intel GPU)
=========================
This board can boot entirely blob-free in the flash. The hardware is similar
This board can boot entirely *free software* in the flash. The hardware is similar
to that of ThinkPad X200, T400 etc where no-ME setup is possible.
No-microcode setup feasible
@ -47,13 +47,13 @@ A note about GPUs
-----------------
We *confirm that* the Nvidia models are PM45, and therefore will require a VGA
blob for initialisation. This is supported in Libreboot *after* the 20230625
ROM for initialisation. This is supported in Libreboot *after* the 20230625
release, if you compile from source; the `e6400_4mb` target can work on both
variants, but will need the Nvidia VGA ROM inserted to work on Nvidia models.
This insertion is handled automatically in newer lbmk revisions, during build
time, or you can [insert it on a release rom
after 20230625](ivy_has_common.md). - **A Video BIOS Option
ROM is used, in this configuration, which is a binary blob. Libreboot's
ROM is used, in this configuration. 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.**
@ -150,7 +150,7 @@ Obtaining the VGA Option ROM (Nvidia)
-------------------------------------
Libreboot does not (and will not) directly distribute the Nvidia ROM, but lbmk
has logic added to blob scripts, which automatically fetches Dell
has logic added to vendor handle scripts, 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/).
@ -158,7 +158,7 @@ as is the purpose of Libreboot's [automated build system](../maintain/).
Provided for *after* the Libreboot 20230625 release, this Video BIOS ROM will
*not* be present in releases, 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
scrubs certain vendor code, in the scripts from lbmk that create release
archives.
[Please read the Libreboot build guide](../build/) for more general guidance

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

@ -20,7 +20,7 @@ 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)**
**[Insert vendor files 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*
@ -29,8 +29,8 @@ 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need vendor files, nothing will happen.
PRECAUTIONS
===========
@ -55,12 +55,12 @@ 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
The lbmk build system automatically fetches required vendor code 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
**If you're using release ROMs, these files are missing, and must be
added. See: [ivy_has_common.md](ivy_has_common.md).**
About ROM image file names
@ -106,7 +106,7 @@ NOTE: no configs in libreboot are currently available that use this method.
With this method, coreboot is finding, loading and executing a VGA option ROM
for your graphics hardware. This would not be done on laptops, because that
implies supplying non-free binary blobs in libreboot, so this setup would only
implies needless supply of non-free software in libreboot, so this setup would only
ever be provided on desktop hardware where no GPU exists or where it is
desirable for you to use an external/add-on graphics card

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

@ -22,60 +22,59 @@ before reading the instructions below:
<https://libreboot.org/docs/build/#first-install-build-dependencies>**
Coreboot is nominally free software, but requires non-free software for certain
boards, for certain functionalities; it differs per board, and some boards do
not require blobs of any kind in the flash. We cover this more thoroughly in
boards, for certain functionalities; we cover this more thoroughly in
the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob
Reduction Policy](../../news/policy.md).
Well, not all of these blobs are freely redistributable. Coreboot does provide
binary blobs in some cases, if the vendor has allowed it. In other cases,
Well, not all of these files are freely redistributable. Coreboot does provide
vendor files in some cases, if the vendor has allowed it. In other cases,
extraction from factory firmware is required, or you can extract them from
vendor-supplied updates - Libreboot's build system does the latter.
When you [compile Libreboot ROM images from source](../build/), Libreboot will
automatically download any given blobs that are required, for any given board
automatically download any given files that are required, for any given board
target. This is done without user intervention, and only when absolutely needed
to make the machine boot properly.
The problem?
------------
Well, if the blobs cannot be freely redistributed, then we can't provide them.
Well, if the files cannot be freely redistributed, then we can't provide them.
So how do we handle *that*, in the context of Libreboot releases?
The solution
------------
The answer is very simple: these blobs are **NOT** provided, at all! However,
The answer is very simple: these files are **NOT** provided, at all! However,
the very same logic used by the build system can be run standalone, to re-insert
these binary blobs on release ROMs. The `inject` script detects what blobs are
these vendor files on release ROMs. The `inject` script detects what files are
needed for your ROM image.
The script will detect what board you're inserting on, or you can manually tell
it what board, and it will fetch them for you, inserting them, so that your
board is ready to flash - flashing it without these required blobs may result in
board is ready to flash - flashing it without these required files may result in
a brick.
Blob locations
Vendor file locations
--------------
During auto-download of blobs, they are saved to these locations within the
During auto-download of files, they are saved to these locations within the
Libreboot build system:
* ME firmware: `blobs/*/me.bin` - the `*` can be any given directory. Different ones will
* ME firmware: `vendor/*/me.bin` - the `*` can be any given directory. Different ones will
be used by given boards, but the directory name may not match the board
target name.
* SMSC SCH5545 fan control firmware (for Dell T1650): `blobs/t1650/sch5545ec.bin`
* SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin`
* SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/`
* Intel MRC firmware, used for ram/peripheral init on Haswell machines such as
thinkpad t440p/w541: `mrc/`
The above list refers to the *non-redistributable blobs*, and these are not
directly included in releases. These are what `blobutil` auto-downloads.
The above list refers to the *non-redistributable files*, and these are not
directly included in releases. These are auto-downloaded during the build.
The `me.bin` files are produced by extracting them from vendor updates and
neutering them with `me_cleaner` so that Intel ME is disabled during early boot.
Injecting Blobs into an Existing Rom
Injecting vendor files into ROM
------------------------------------
You must determine the correct board name, for your board, based on the list
@ -87,9 +86,9 @@ 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.
In order to inject the necessary files 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.
If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.
Run the injection script pointing to the release archive you downloaded:
./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440pmrc_12mb.tar.xz
@ -108,10 +107,10 @@ For example:
./update vendor inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
Check that the blobs were inserted
Check that the files were inserted
==================================
You *must* ensure that the blobs were inserted.
You *must* ensure that the files were inserted.
Some examples of how to do that in lbmk:
@ -123,7 +122,7 @@ below):
./cbutils/default/cbfstool libreboot.rom print
You should check that the blobs were inserted in cbfs, if needed; for example,
You should check that the files were inserted in cbfs, if needed; for example,
EC firmware or MRC firmware.
Next:
@ -139,7 +138,7 @@ Check the output. If it's all `0xFF` (all ones) or otherwise isn't a bunch
of code, then the Intel ME firmware wasn't inserted.
You'll note the small size of the Intel ME, e.g. 84KB on sandybridge platforms.
This is because blobutil *automatically* neuters it, disabling it during
This is because lbmk *automatically* neuters it, disabling it during
early boot. This is done using `me_cleaner`, which lbmk imports.
Errata
@ -149,7 +148,7 @@ Errata
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
the `-b` flag in the `./update vendor 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.**

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

@ -26,59 +26,59 @@ before reading the instructions below:
Coreboot is nominally free software, but requires non-free software for certain
boards, for certain functionalities; it differs per board, and some boards do
not require blobs of any kind in the flash. We cover this more thoroughly in
not require vendor code of any kind in the flash. We cover this more thoroughly in
the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob
Reduction Policy](../../news/policy.md).
Well, not all of these blobs are freely redistributable. Coreboot does provide
binary blobs in some cases, if the vendor has allowed it. In other cases,
Well, not all of these files are freely redistributable. Coreboot does provide
vendor files in some cases, if the vendor has allowed it. In other cases,
extraction from factory firmware is required, or you can extract them from
vendor-supplied updates - Libreboot's build system does the latter.
When you [compile Libreboot ROM images from source](../build/), Libreboot will
automatically download any given blobs that are required, for any given board
automatically download any given vendor files required, for any given board
target. This is done without user intervention, and only when absolutely needed
to make the machine boot properly.
The problem?
------------
Well, if the blobs cannot be freely redistributed, then we can't provide them.
Well, if the files cannot be freely redistributed, then we can't provide them.
So how do we handle *that*, in the context of Libreboot releases?
The solution
------------
The answer is very simple: these blobs are **NOT** provided, at all! However,
The answer is very simple: these files are **NOT** provided, at all! However,
the very same logic used by the build system can be run standalone, to re-insert
these binary blobs on release ROMs. The `inject` script detects what blobs are
these vendor files on release ROMs. The `inject` script detects what files are
needed for your ROM image.
The script will detect what board you're inserting on, or you can manually tell
it what board, and it will fetch them for you, inserting them, so that your
board is ready to flash - flashing it without these required blobs may result in
board is ready to flash - flashing it without these required files may result in
a brick.
Blob locations
Vendor file locations
--------------
During auto-download of blobs, they are saved to these locations within the
During auto-download of files, they are saved to these locations within the
Libreboot build system:
* ME firmware: `blobs/*/me.bin` - the `*` can be any given directory. Different ones will
* ME firmware: `vendor/*/me.bin` - the `*` can be any given directory. Different ones will
be used by given boards, but the directory name may not match the board
target name.
* SMSC SCH5545 fan control firmware (for Dell T1650): `blobs/t1650/sch5545ec.bin`
* SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin`
* SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/`
* Intel MRC firmware, used for ram/peripheral init on Haswell machines such as
thinkpad t440p/w541: `mrc/`
The above list refers to the *non-redistributable blobs*, and these are not
directly included in releases. These are what `blobutil` auto-downloads.
The above list refers to the *non-redistributable files*, and these are not
directly included in releases. These are auto-downloaded during the build.
The `me.bin` files are produced by extracting them from vendor updates and
neutering them with `me_cleaner` so that Intel ME is disabled during early boot.
Injecting Blobs into an Existing Rom
Inject vendor files into ROM
------------------------------------
You must determine the correct board name, for your board, based on the list
@ -90,9 +90,9 @@ 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.
In order to inject the necessary files 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.
If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.
Run the injection script pointing to the release archive you downloaded:
./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440pmrc_12mb.tar.xz
@ -111,10 +111,10 @@ For example:
./update vendor inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
Check that the blobs were inserted
Check that the files were inserted
==================================
You *must* ensure that the blobs were inserted.
You *must* ensure that the files were inserted.
Some examples of how to do that in lbmk:
@ -126,7 +126,7 @@ below):
./cbutils/default/cbfstool libreboot.rom print
You should check that the blobs were inserted in cbfs, if needed; for example,
You should check that the files were inserted in cbfs, if needed; for example,
EC firmware or MRC firmware.
Next:
@ -142,7 +142,7 @@ Check the output. If it's all `0xFF` (all ones) or otherwise isn't a bunch
of code, then the Intel ME firmware wasn't inserted.
You'll note the small size of the Intel ME, e.g. 84KB on sandybridge platforms.
This is because blobutil *automatically* neuters it, disabling it during
This is because lbmk *automatically* neuters it, disabling it during
early boot. This is done using `me_cleaner`, which lbmk imports.
Errata
@ -152,7 +152,7 @@ Errata
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
the `-b` flag in the `./update vendor 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.**

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

@ -8,7 +8,7 @@ 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:
inserting vendor files, which you can use to change the MAC address. See:
[docs/install/ivy_has_common.md](ivy_has_common.md)

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

@ -555,7 +555,8 @@ 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.
Note that you will need this combined rom if you intend to manually extract vendor
files, which is a method not officially supported by Libreboot's build system.
Writing
-------

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

@ -18,26 +18,26 @@ The following instructions expect you to have these on hand:
Preparing a release Rom
-----------------------
You must patch the release rom with the necessary blobs *and then* flash it to your board.
You must patch the release rom with the necessary vendor files *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.
In order to inject the necessary files 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.
If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.
Run the injection script pointing to the release archive you downloaded:
./update blobs inject /path/to/libreboot-20230423_t420_8mb.tar.xz
./update vendor 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.
./update blobs inject -r t420_libreboot.rom -b t420_8mb
./update vendor 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:
./update blobs inject -r t420_libreboot.rom -b t420_8mb -m 00:f6:f0:40:71:fd
./update vendor inject -r t420_libreboot.rom -b t420_8mb -m 00:f6:f0:40:71:fd
Disassembly
-----------

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

@ -18,17 +18,17 @@ 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.
You must patch the release rom with the necessary vendor files *and then* flash it to your board.
Lbmk includes a script that will automatically inject the necessary blobs into a rom file.
Lbmk includes a script that will automatically inject the necessary files 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.
In order to inject the necessary files 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.
If you only wish to flash a release rom then the process of injecting the necessary files is quite simple.
Run the injection script pointing to the release archive you downloaded:
./update blobs inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz
./update vendor 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/`
@ -36,21 +36,21 @@ 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`):
./update blobs inject -r t440p_libreboot.rom -b t440p_12mb
./update vendor 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:
./update blobs inject -r t440p_libreboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd
./update vendor 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
If you're flashing a ROM that needs vendor file `mrc.bin`, you would do one of these
instead, for example:
./update blobs inject -r t440p_libreboot.rom -b t440pmrc_12mb
./update vendor inject -r t440p_libreboot.rom -b t440pmrc_12mb
or (inserting a different MAC address)
./update blobs inject -r t440p_libreboot.rom -b t440pmrc_12mb -m 00:f6:f0:40:71:fd
./update vendor 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).

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

@ -22,15 +22,15 @@ 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.
You must patch the release rom with the necessary vendor files *and then* flash it to your board.
Lbmk includes a script that will automatically inject the necessary blobs into a rom file.
Lbmk includes a script that will automatically inject the necessary files into a rom image.
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.
In order to inject the necessary files 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:
./update blobs inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz
./update vendor 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/`
@ -38,12 +38,12 @@ You can then find flash-ready ROMs in `/bin/release/`
Alternatively, you may patch only a single rom file.
For example:
./update blobs inject -r x230_libreboot.rom -b x230_12mb
./update vendor 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:
./update blobs inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd
./update vendor 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).

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

@ -188,7 +188,7 @@ computer. NOTE: An attacker could still open your system and re-flash new
firmware externally. You should implement some detection mechanism, such as
epoxy applied in a *random pattern* on every screw; this slows down the attack
and means that you will know someone tampered with it because they cannot
easily re-produce the exact same blob of epoxy in the same pattern (when you
easily re-produce the exact same glob of epoxy in the same pattern (when you
apply it, swirl it around a bit for a few minutes while it cures. The purpose
is not to prevent disassembly, but to slow it down and make it detectable when
it has occured).

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

@ -72,7 +72,7 @@ the vendor on many supported systems. These programs 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
The libreboot project *allows* vendor code within 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*.
@ -110,15 +110,6 @@ The files under `bin/` are provided in regular Libreboot releases.
**These** are the ROM images that you should flash. Do *not* flash the ROM
images contained under `elf/`!
blobs/
---------------
Used by the blob handler scripts, referenced in certain coreboot configs.
Certain binary blobs such as Intel ME or SCH5545 EC firmware are downloaded
here; not all blobs are downloaded here however, as some are handled under
separate directories.
cbutils/
---------------
@ -161,10 +152,8 @@ Please also
visit: <https://doc.coreboot.org/northbridge/intel/haswell/mrc.bin.html> - the
handling of this, in Libreboot, is based largely on the information there.
This contains the Intel MRC blob, auto-downloaded during build
by `script/update/blobs/mrc`, called by the user directly or
by `script/update/blobs/download`. This provides raminit and peripheral
init on certain Haswell and Broadwell platforms.
This contains the Intel MRC firmware, auto-downloaded during build
by `script/update/vender/download`.
In some cases, libre MRC firmware is also available, and provided
by Libreboot as an alternative choice.
@ -185,7 +174,7 @@ current lbmk behaviour, and executed so as to provide Libreboot release
archives.
This provides source tarballs, and ROM images for example; however, ROM images
containing non-redistributable blobs are *scrubbed* such that those blobs must,
containing non-redistributable vendor code are *scrubbed* such that these files must,
in regular releases, be [re-added manually](../install/ivy_has_common.md) by
the user.
@ -197,7 +186,7 @@ Third-party source trees are downloaded into this directory, by lbmk.
src/bios\_extract/
---------------
Used by the blob handler scripts. The upstream that we use is here:
Used by the vendor file handler scripts. The upstream that we use is here:
<https://review.coreboot.org/bios_extract>
Specifically: the pfs extract utility from this is used on Dell vendor updates,
@ -206,7 +195,7 @@ to extract SCH5545 EC (Environment Control) firmware.
src/biosutilities/
---------------
Used by the blob handler scripts. The upstream that we use is here:
Used by the vendor file handler scripts. The upstream that we use is here:
<https://github.com/platomav/BIOSUtilities>
The `dell_inspiron_1100_unpacker.py` script is used here, to extract from Dell
@ -275,8 +264,8 @@ payload). More information available at these pages:
* <https://github.com/corna/me_cleaner/>
* Libreboot [freedom status page](../../freedom-status.md)
The *blob* scripts are what handle this, specifically the download script
located at `script/update/blobs/download`.
The *vendor file* scripts are what handle this, specifically the download script
located at `script/update/vendor/download`.
src/memtest86plus/
---------------
@ -318,7 +307,7 @@ src/uefitool/
Please also visit: <https://github.com/LongSoft/UEFITool>
This is compiled, so as to provide `UEFIExtract`. Currently used by the
blob download script at `script/update/blobs/download`, to download SCH5545 EC
vendor download script at `script/update/vendor/download`, to download SCH5545 EC
firmware (used for fan control on Dell Precision T1650).
src/pico-serprog
@ -359,6 +348,15 @@ may not have much RAM.
Where large files (or a large number of files) are handled by lbmk on a
temporary basis, this `tmp/` directory is created and then used.
vendor/
---------------
Used by the vendor file handler scripts, referenced in certain coreboot configs.
Certain vendor files such as Intel ME or SCH5545 EC firmware are downloaded
here; not all such files are downloaded here however, as some are handled under
separate directories.
util/
===============
@ -506,9 +504,9 @@ for example, be `default`. In other words, they can refer to other trees.
The coreboot downloads are based on scanning of these directories, and ROM
images are also built based on them; coreboot defconfigs are also used by
the blob scripts, for adding or removing certain binary blobs (for example,
the vendor scripts, for adding or removing certain vendor firmware (for example,
a config will define where `me.bin` is located, and if it doesn't exist, the
blob scripts will look up that file and download/process it with `me_cleaner`).
vendor scripts will look up that file and download/process it with `me_cleaner`).
### config/coreboot/BOARDNAME/patches/
@ -534,7 +532,7 @@ as:
* `payload_seabios_withgrub="y"` (example entry)
* `grub_scan_disk="ata"`
* `uboot_config=default` (specify which U-Boot tree to use)
* `blobs_required="n"`
* `vendorfiles="n"`
* `microcode_required="y"`
The `tree` value refers to `config/coreboot/TREE`; in other words, a given
@ -587,7 +585,7 @@ on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
machine it is advisable to set this option to `ahci` (becuse the default HDD
slot is AHCI).
The `blobs_required` entry doesn't affect anything in code, except that
The `vendorfiles` entry doesn't affect anything in code, except that
the `noblobs` string will be appended to ROM image file names, on releases;
ditto `nomicrocode` but in that case, the behaviour is: if no microcode to
begin with, only `nomicrocode` images will be named, otherwise ROM images with
@ -1091,9 +1089,9 @@ in the script at `script/update/vendor/download`, and it is used from there.
include/option.sh
---------------
Functions used by scripts under `script/update/blobs/`, for checking defconfig
Functions used by scripts under `script/update/vendor/`, for checking defconfig
files. These files are checked because the scripts need to know whether a given
blob is used; if it is, a path is then specified in defconfig, telling the blob
file is used; if it is, a path is then specified in defconfig, telling the vendor
script either where it is, or where it should be downloaded to.
Several other parts of lbmk also use this file. It is added to as little as
@ -1274,11 +1272,11 @@ clone, then cleans itself up and creates tarballs. If you run this script, you
should expect it to take at least 4 hours; slower on really old systems. On
really fast systems, it might take 2-3 hours.
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
NOTE: This script *scrubs* certain vendor firmware from release ROMs, such as
Intel ME or MRC firmware. The release ROMs shall then exclude these files
within them, requiring manual insertion by the user post-release. See:
[Insert binary blobs
[Insert vendor files
on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)
### script/update/project/trees
@ -1404,12 +1402,12 @@ Remember: code equals bugs, so less code equals fewer bugs.
### script/update/vendor/download
This downloads binary blobs when needed, on a given coreboot target. It does
this by scanning the defconfig files of that board, to know where the blobs
This downloads vendor code when needed, on a given coreboot target. It does
this by scanning the defconfig files of that board, to know where the files
are (or where they should be) within lbmk. Based on this, it then knows which
blobs to download.
files to download.
These blobs are then inserted at build time by the coreboot build system (as
These files are then inserted at build time by the coreboot build system (as
defined by defconfigs), or post-release by running the `inject` script.
It looks inside `config/vendor/` at the files in there, concatenating them and
@ -1420,14 +1418,14 @@ the `me_cleaner` program.
More information is available [here](../install/ivy_has_common.md).
This script is executed automatically, when you compile ROM images, if the given
mainboard requires binary blobs to be inserted. In this way, you do not need to
mainboard requires vendor code to be inserted. In this way, you do not need to
manually extract such files from your original vendor image.
### script/update/vendor/inject
This is not used during the build process, but it can be run by the user on
release ROMs (which do not contain non-redistributable blobs handled by these
blob scripts, even if they are required). This script inserts those blobs
release ROMs (which do not contain non-redistributable code handled by these
vendor scripts, even if they are required). This script inserts those files
into the coreboot ROM image; if you're building from source, using lbmk, you
do not need to run the inject script at all.

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

@ -84,7 +84,7 @@ Once you have finished this, you can try flashing the resulting rom to your boar
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
2) The vendor code (if required) is incompatible
Solutions to these problems follow in the proceeding sections.

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

@ -31,9 +31,9 @@ Despite still being distributed by some distros, boot.scr is a legacy boot metho
For more information about what actually goes into a boot.scr script, check [this page in the u-boot documentation](https://u-boot.readthedocs.io/en/latest/usage/cmd/source.html?highlight=boot.scr#fit-image)
3) extlinux.conf - a flat, bootloader-spec text file that lives in /boot/extlinux/extlinux.conf. That's all. Not a binary blob in sight!
3) extlinux.conf - a flat, bootloader-spec text file that lives in /boot/extlinux/extlinux.conf. That's all.
Since extlinux.conf is supported by multiple bootloaders, making your system more portable, is natively supported by u-boot, and requires no binary blobs or extra software, it seems to be the best choice for a chromebook.
Since extlinux.conf is supported by multiple bootloaders, making your system more portable, is natively supported by u-boot, it seems to be the best choice for a chromebook.
Creating extlinux.conf
======================

6
site/download.md
View File

@ -21,7 +21,7 @@ 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)**
**[Insert vendor files 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*
@ -30,8 +30,8 @@ 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need blobs, nothing will happen.
GPG signing key
---------------

6
site/download.uk.md
View File

@ -21,7 +21,7 @@ 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)**
**[Insert vendor files 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*
@ -30,8 +30,8 @@ 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need vendor files, nothing will happen.
Код підпису GPG
---------------

23
site/faq.md
View File

@ -194,7 +194,7 @@ Please read the [hardware compatibility list](docs/hardware/).
Freedom pitfalls with modern Intel hardware {#intel}
----------------------------------------------------
Coreboot is nominally Free Software, but requires binary blobs on most x86
Coreboot is nominally Free Software, but requires certain vendor code on some x86
targets that it supports, on both Intel and AMD.
### Intel Management Engine (ME) {#intelme}
@ -370,21 +370,16 @@ interesting:
### Firmware Support Package (FSP) {#fsp}
On all recent Intel systems, coreboot support has revolved around
integrating a blob (for each system) called the *FSP* (firmware support
integrating a vendor file (for each system) called the *FSP* (firmware support
package), which handles all of the hardware initialization, including
memory and CPU initialization. Reverse engineering and replacing this
blob is almost impossible, due to how complex it is. Even for the most
file is almost impossible, due to how complex it is. Even for the most
skilled developer, it would take years to replace. Intel distributes
this blob to firmware developers, without source.
this file to firmware developers, for free redistribution.
Since the FSP is responsible for the early hardware initialization, that
means it also handles SMM (System Management Mode). This is a special
mode that operates below the operating system level. **It's possible
that rootkits could be implemented there, which could perform a number
of attacks on the user (the list is endless). Any Intel system that has
the proprietary FSP blob cannot be trusted at all.** In fact, several
SMM rootkits have been demonstrated in the wild (use a search engine to
find them).
mode that operates below the operating system level.
### CPU microcode updates {#microcode}
@ -488,7 +483,7 @@ demonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-
and based on this work, Damien Zammit (another coreboot hacker)
[partially replaced it](https://github.com/zamaudio/smutool/) with free
firmware, but on the relevant system (ASUS F2A85-M) there were still
other blobs present (Video BIOS, and others).
other such files present (Video BIOS, and others).
### AMD AGESA firmware
@ -499,7 +494,7 @@ page is a few years out of date.
This is responsible for virtually all core hardware initialization on
modern AMD systems. In 2011, AMD started cooperating with the coreboot
project, releasing this as source code under a free license. In 2014,
they stopped releasing source code and started releasing AGESA as binary
they stopped releasing source code and started releasing AGESA as vendor
blobs instead. This makes AGESA now equivalent to [Intel FSP](#fsp).
### AMD CPU microcode updates
@ -843,7 +838,7 @@ advisable if security is a concern. USB 2.0 has plenty of bandwidth for
many HDDs (a few high-end ones can use more bandwidth than USB 2.0 is
capable of), but for SSDs it might be problematic. USB 3.0 will provide more
reasonable performance, though note that depending on the system, you may have
to deal with binary blob XHCI firmware in your kernel (if that bothers you).
to deal with binary vendor XHCI firmware in your kernel (if that bothers you).
Use of USB is also not an absolute guarantee of safety, so do beware.
The attack surface becomes much smaller, but a malicious drive could
@ -990,7 +985,7 @@ Besides software itself (embedded in ROM or not), most hardware
We do not have a single device that can be considered be "100% free",
and such absolutes are nearly impossible to reach.
Notable proprietary blobs (not a complete list):
Notable vendor code present (example) (not a complete list):
* All devices
* SATA/PATA Hard Drive/Optical Disc Drive Firmware

2
site/footer.include
View File

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

39
site/freedom-status.md
View File

@ -8,23 +8,23 @@ 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."*
especially that line which says: *"if free software can be used, it must be
used."*
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)
[vendor files](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
A more *pragmatic* [binary blob 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
people with coreboot which, regardless of freedom 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
@ -164,7 +164,7 @@ 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
Notes about specific types of vendor file
===================================
VGA option ROMs
@ -175,7 +175,7 @@ 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
coreboot. In this situation, a vendor file 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
@ -190,7 +190,7 @@ 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.
these files 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
@ -210,27 +210,28 @@ and W541) as of Libreboot 20230319 or higher.
ARM platforms (chromebooks)
=============
Mostly blobless, except for the requirement on `daisy` and `peach` mainboards
to include BL1 bootloader blobs. These are:
Mostly free software, except for the requirement on `daisy` and `peach` mainboards
to include BL1 bootloader files from the vendor. 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
* nyan-* chromebooks also temporarily removed, but are 100% free software in
Libreboot
List of blobs needed, specifically for each board
List of vendor files, 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,
nature as to *what* vendor files 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:
Here is a list, *for each* board, of those files:
Intel/x86
---------
@ -258,9 +259,9 @@ This applies to the following targets: `hp2170p_16mb`, `hp2560p_8mb`,
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
build system handles such firmware in a script, 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`
and provide functionality in a special script, to insert them with `cbfstool`
at the correct offset as defined by coreboot config for each board.
### SMSC SCH5545 Environmental Control
@ -283,7 +284,7 @@ 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
CPU microcode files 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)
@ -315,7 +316,7 @@ ARM/chromebooks
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
because the build system does not yet auto-insert the BL1 files. The boards
are otherwise believed to work, using Alper's port of U-Boot in Libreboot.
Conclusion
@ -326,7 +327,7 @@ 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
Libreboot *could* add a lot more such files for many 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.

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

@ -349,9 +349,9 @@ This applies to the following targets: `hp2170p_16mb`, `hp2560p_8mb`,
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
build system handles such firmware with scripts, 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`
and provide functionality in a special script, to insert them with `cbfstool`
at the correct offset as defined by coreboot config for each board.
### SMSC SCH5545 Environmental Control

2
site/news/censored-libreboot20230710.md
View File

@ -69,7 +69,7 @@ has been *removed* (censored), in this version, hence the name: *Censored
Libreboot*. More information available here:
<https://censored.libreboot.org/censorship.html>
You can find out about the current status of binary blobs, on the [Freedom
You can find out about the current freedom status per board, on the [Freedom
Status](../freedom-status.md) page. It describes how Libreboot policy is
implemented, in great detail.

13
site/news/e6400nvidia.md
View File

@ -47,19 +47,6 @@ 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>

6
site/news/libreboot20221214.md
View File

@ -22,11 +22,11 @@ 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)**
**[Insert vendor files 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need vendor files, nothing will happen.
Build from source
-----------------

16
site/news/libreboot20230319.md
View File

@ -43,11 +43,11 @@ 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)**
**[Insert vendor files 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need any vendor files, nothing will happen.
Build from source
-----------------
@ -75,7 +75,7 @@ The changes can be summarised, thus:
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
contains ROMs with libre raminit *and* ROMs with vendor 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
@ -139,17 +139,17 @@ 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
* `t440pmrc_12mb`: vendor `mrc.bin` used for raminit. GRUB and SeaBIOS payloads
both supported.
* `w541mrc_12mb`: blob `mrc.bin` used for raminit. GRUB and SeaBIOS payloads
* `w541mrc_12mb`: vendor `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.
The MRC vendor file (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
----------

6
site/news/libreboot20230413.md
View File

@ -43,11 +43,11 @@ 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)**
**[Insert vendor files 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need any vendor files, then nothing will happen.
Build from source
-----------------

6
site/news/libreboot20230423.md
View File

@ -42,11 +42,11 @@ 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)**
**[Insert vendor files 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need vendor files, nothing will happen.
Build from source
-----------------

6
site/news/libreboot20230625.md
View File

@ -44,11 +44,11 @@ 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)**
**[Insert vendor files 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.
these instructions anyway. If you run the vendor scripts on a board that doesn't
need vendor files, nothing will happen.
A note about the changelog
--------------------------

22
site/news/microcode.md
View File

@ -21,17 +21,17 @@ about microcode on the [FAQ](../faq.md#microcode) and
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
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*.
requiring *zero* vendor files of any kind within *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
certain vendor files 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).
@ -54,7 +54,7 @@ Why?
----
Freedom of choice, that's why. Libreboot's policy explicitly
[states](policy.md#configuration), in the context of *adding* binary blobs:
[states](policy.md#configuration), in the context of *adding* vendor files:
*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,
@ -87,15 +87,15 @@ 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)
* `vendorfiles="n" or "y"`("n" on MOST boards)
If `blobs_required="n"`, the given ROM image `filename.rom`
If `vendorfiles="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
updates, distinguishing *microcode* as a special kind of vendor file distinct
from all others.
With or without `_noblobs` in the name:
@ -103,11 +103,11 @@ 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
* If no microcode file 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
is copied to `filename_nomicrocode.rom`, and the CPU microcode update file
shall be removed from `filename_nomicrocode.rom`.
What this means is that ROMs *with* OR *without* microcode will be present,
@ -139,7 +139,7 @@ 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
coreboot which, regardless of freedom 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*.

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

@ -72,9 +72,9 @@ 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
require vendor files 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,
coreboot firmware uses certain vendor code 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.
@ -83,21 +83,21 @@ 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
* If free software *can* be used, it *should* be used. 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
possible with vendor code *or* libre code in coreboot, the *libre* code
should be used in ROMs built by the Libreboot build system, and the *vendor*
raminit code 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*.
*vendor* code.
* 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
and accomodate the required vendor code 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
@ -111,8 +111,8 @@ The libreboot project has the following policy:
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
* Vendor blobs should *never* be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with vendor
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
@ -120,8 +120,8 @@ The libreboot project has the following policy:
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
minimalization might be if *vendor* raminit and *libre* raminit are possible, but
the *libre* one is so broken so as to be unusable. In that situation, the vendor
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*.
@ -149,7 +149,7 @@ 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
educating people about the software freedom status 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).
@ -283,7 +283,7 @@ provide incentive for levels of software freedom, such as:
* 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
ATI GPU is to be used, a binary 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
@ -314,13 +314,13 @@ 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
* Excluding vendor 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
for hardware *with those same binary 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

40
site/news/policy.md
View File

@ -1,4 +1,4 @@
% Binary blob reduction policy
% Binary Blob Reduction Policy
% Leah Rowe
% 4 January 2022 (updated 15 November 2022)
@ -67,9 +67,9 @@ 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
require certain vendor code 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,
coreboot firmware uses certain vendor code 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.
@ -78,21 +78,21 @@ 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
* If free software *can* be used, it *should* be used. 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
possible with vendor code *or* libre code in coreboot, the *libre* code
should be used in ROMs built by the Libreboot build system, and the *vendor*
raminit code 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*.
*vendor* code.
* 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
and accomodate the required vendor code 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
@ -106,17 +106,17 @@ The libreboot project has the following policy:
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
* Vendor blobs should *never* be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with vendor
code 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
minimalization might be if *vendor* raminit and *libre* raminit are available, but
the *libre* one is so broken so as to be unusable. In that situation, the vendor
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*.
@ -145,7 +145,7 @@ 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
educating people about the software freedom status 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).
@ -279,7 +279,7 @@ provide incentive for levels of software freedom, such as:
* 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
ATI GPU is to be used, a binary 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
@ -304,8 +304,8 @@ Problems with FSDG
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.
dubbed *linux-libre*, which removes all vendor code from upstream. These
vendor files 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
@ -322,13 +322,13 @@ 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
* Excluding vendor 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
for hardware *with those same binary 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

22
site/news/safety.md
View File

@ -19,33 +19,33 @@ users have been bricking their machines, on the following mainboards:
Why?
----
On these platforms, the following binary blobs are required:
On these platforms, the following binary vendor files 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.
is available, but experimental, and the vendor 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
build system (lbmk) automatically downloads these files 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
However, these files are not redistributable, so Libreboot's build system (lbmk)
automatically scrubs (deletes) these files, 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
be flashing them *without* these required files. This is exactly what some
people have been doing.
Instructions are given here, for how to insert these blobs on release ROMs:
Instructions are given here, for how to insert these files on release ROMs:
[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)
[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)
The linked guide makes use of `blobutil`, lbmk's single centralised utility that
The linked guide makes use of vendor scripts, that
handles *all* firmwares, automatically for each given mainboard. It can
automatically download and insert all of the following:
@ -97,7 +97,7 @@ 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
* If BIOS region requires vendor files: 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
@ -120,7 +120,7 @@ one of three possible scenarios:
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
flash a ROM image without running vendor scripts 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).