more stragglers
a big cleanup was needed, based on recent changes Signed-off-by: Leah Rowe <leah@libreboot.org>master
Leah Rowe
parent
3f3b501c6a
commit
a918978371
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.**
|
||||
|
|
|
|||
|
|
@ -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.**
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
======================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---------------
|
||||
|
|
|
|||
|
|
@ -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
23
site/faq.md
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
--------------------------
|
||||
|
|
|
|||
|
|
@ -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*.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
Loading…
Reference in New Issue