File site/docs/install/dell3050.md changed (mode: 100644) (index 2581234..7bb6198) |
... |
... |
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)** |
28 |
28 |
|
|
29 |
29 |
|
|
30 |
30 |
``` |
``` |
31 |
|
W+: Works without blobs; |
|
|
31 |
|
W+: Works without vendor firmware; |
32 |
32 |
N: Doesn't work; |
N: Doesn't work; |
33 |
|
W*: Works with blobs; |
|
|
33 |
|
W*: Works with vendor firmware; |
34 |
34 |
U: Untested; |
U: Untested; |
35 |
35 |
P+: Partially works; |
P+: Partially works; |
36 |
|
P*: Partially works with blobs |
|
|
36 |
|
P*: Partially works with vendor firmware |
37 |
37 |
?: UNKNOWN AT THIS TIME |
?: UNKNOWN AT THIS TIME |
38 |
38 |
``` |
``` |
39 |
39 |
|
|
|
... |
... |
SMT is rarely of benefit in practise, but can be useful in some circumstances. |
237 |
237 |
For example, if you're compiling a large codebase from source that takes hours, |
For example, if you're compiling a large codebase from source that takes hours, |
238 |
238 |
SMT increases the building speed by about 15 percent; for example, a 3 hour |
SMT increases the building speed by about 15 percent; for example, a 3 hour |
239 |
239 |
build job might take about 2 hours and 40 minutes instead. |
build job might take about 2 hours and 40 minutes instead. |
240 |
|
|
|
241 |
|
Intel FSP copyright |
|
242 |
|
=================== |
|
243 |
|
|
|
244 |
|
Abstract |
|
245 |
|
-------- |
|
246 |
|
|
|
247 |
|
The initial Libreboot 20241206 release included Intel FSP directly inside the |
|
248 |
|
ROM images. Intel provides the FSP under a license which states (and I |
|
249 |
|
paraphrase): you must not modify it, but you can redistribute it freely, so |
|
250 |
|
long as the license notice is retained. |
|
251 |
|
|
|
252 |
|
The FSP is a concatenation of three modules: FSP-T, FSP-S and FSP-M. T basically |
|
253 |
|
does CAR, S is essentially romstage components, and M is raminit. Due to how |
|
254 |
|
coreboot works, these components must be split into single components. Coreboot |
|
255 |
|
doesn't use T by default (it implements CAR itself), but has the option to |
|
256 |
|
use it. It will use M and S, only. |
|
257 |
|
|
|
258 |
|
Technically, the process of splitting FSP into these three files counts as |
|
259 |
|
a modification. Furthermore, coreboot also rebases the M module by modifying |
|
260 |
|
certain pointers, so that it can integrate with coreboot to provide raminit. |
|
261 |
|
|
|
262 |
|
Intel *themselves* own the copyright to the tool for splitting FSP, |
|
263 |
|
at `3rdparty/fsp/Tools/SplitFspBin.py`, and it seems that they do intend for |
|
264 |
|
the FSP to be used this way. However, until now, those using the Intel FSP |
|
265 |
|
have built coreboot images from source, so the issue of modified distributions |
|
266 |
|
didn't come up. |
|
267 |
|
|
|
268 |
|
By the strictest possible interpretation of Intel's licensing, Libreboot was |
|
269 |
|
technically in violation. To mitigate this, Libreboot 20241206 *revision 8* and |
|
270 |
|
newer, will no longer include the Intel FSP inside images. Instead, the vendor |
|
271 |
|
inject script is used for inserting the FSP into release images, which is what |
|
272 |
|
we already do for several other components. |
|
273 |
|
|
|
274 |
|
`_fsp` vs `_vfsp` targets |
|
275 |
|
------------------------- |
|
276 |
|
|
|
277 |
|
The original 20241206 release images had `_fsp` in the file name. From rev8 |
|
278 |
|
onward, `_vfsp` is specified instead. |
|
279 |
|
|
|
280 |
|
Libreboot's inject script verifies checksums on files, when inserting into the |
|
281 |
|
images. Because of this, if we inject FSP after the fact, that means anyone |
|
282 |
|
using the old images will find errors when they try. |
|
283 |
|
|
|
284 |
|
To mitigate this, the build targets containing `_fsp` in the name have been |
|
285 |
|
retained, but these targets are set `release="n"` so that no ROM images are |
|
286 |
|
provided in releases. The `_vfsp` images are provided pre-compiled, instead. |
|
287 |
|
|
|
288 |
|
With this re-design, modern lbmk (from Libreboot 20241206 rev8 onward) can still |
|
289 |
|
reliably inject Intel ME into the old `_fsp` images, if you already downloaded |
|
290 |
|
those before. |
|
291 |
|
|
|
292 |
|
It is extremely unlikely that Intel would have ever cracked down on Libreboot |
|
293 |
|
for its previous mistake, since many other projects exist that include FSP |
|
294 |
|
directly in coreboot images, even commercially. However, Libreboot wishes to |
|
295 |
|
respect Intel's license, in the |
|
296 |
|
most [technically correct](https://www.youtube.com/watch?v=0ZEuWJ4muYc) way |
|
297 |
|
possible. |
|
File site/docs/install/ivy_has_common.md changed (mode: 100644) (index c7fc9de..ee877d1) |
... |
... |
recovery via [external flashing](spi.md) - regardless, you are advised to |
10 |
10 |
also read the external flashing guide just in caes, and have an external |
also read the external flashing guide just in caes, and have an external |
11 |
11 |
flasher handy in case you need it.** |
flasher handy in case you need it.** |
12 |
12 |
|
|
|
13 |
|
Even if your board doesn't need vendor firmware inserted, you can also use this |
|
14 |
|
guide to change the GbE MAC address in the flash, if your board has an Intel |
|
15 |
|
Gigabit Ethernet device (where an Intel Flash Descriptor is used). |
|
16 |
|
|
13 |
17 |
WARNING: eCryptfs file name limits |
WARNING: eCryptfs file name limits |
14 |
18 |
================================= |
================================= |
15 |
19 |
|
|
16 |
20 |
Do not run the build system on a eCryptfs file system, because it has |
Do not run the build system on a eCryptfs file system, because it has |
17 |
21 |
very short file name limits and Libreboot's build system deals with very |
very short file name limits and Libreboot's build system deals with very |
18 |
22 |
long file names. We commonly get reports from this by Linux Mint users |
long file names. We commonly get reports from this by Linux Mint users |
19 |
|
who encrypt their home directory with cryptfs; use a serious distro like |
|
20 |
|
Debian or Arch please. And use a decent file system; ZFS or perhaps LUKS |
|
21 |
|
with btrfs will do nicely. |
|
|
23 |
|
who encrypt their home directory with eCryptfs; regular LUKS encryption will |
|
24 |
|
do nicely. |
22 |
25 |
|
|
23 |
26 |
**Install build dependencies first** |
**Install build dependencies first** |
24 |
27 |
================================ |
================================ |
|
... |
... |
boards, for certain functionalities; we cover this more thoroughly in |
41 |
44 |
the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob |
the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob |
42 |
45 |
Reduction Policy](../../news/policy.md). |
Reduction Policy](../../news/policy.md). |
43 |
46 |
|
|
44 |
|
Libreboot can't directly distribute *all* of these blobs, so some of them are |
|
|
47 |
|
Libreboot can't directly distribute *all* of these files, so some of them are |
45 |
48 |
downloaded at build-time, and processed for insertion into the firmware images. |
downloaded at build-time, and processed for insertion into the firmware images. |
46 |
49 |
**On pre-compiled ROM images in releases, these files are removed, and can be |
**On pre-compiled ROM images in releases, these files are removed, and can be |
47 |
50 |
re-added using the same automation that was applied during the build process.** |
re-added using the same automation that was applied during the build process.** |
|
... |
... |
You'll note the small size of the Intel ME, e.g. 84KB on sandybridge platforms. |
238 |
241 |
This is because lbmk *automatically* neuters it, disabling it during |
This is because lbmk *automatically* neuters it, disabling it during |
239 |
242 |
early boot. This is done using `me_cleaner`, which lbmk imports. |
early boot. This is done using `me_cleaner`, which lbmk imports. |
240 |
243 |
|
|
|
244 |
|
Intel FSP copyright |
|
245 |
|
=================== |
|
246 |
|
|
|
247 |
|
If you just want to inject Intel FSP and ME into your image, ready for |
|
248 |
|
flashing, please read [the guide](ivy_has_common.md). |
|
249 |
|
|
|
250 |
|
Abstract |
|
251 |
|
-------- |
|
252 |
|
|
|
253 |
|
The initial Libreboot 20241206 release included Intel FSP directly inside the |
|
254 |
|
ROM images. Intel provides the FSP under a license which states (and I |
|
255 |
|
paraphrase): you must not modify it, but you can redistribute it freely, so |
|
256 |
|
long as the license notice is retained. |
|
257 |
|
|
|
258 |
|
The FSP is a concatenation of three modules: FSP-T, FSP-S and FSP-M. T basically |
|
259 |
|
does CAR, S is essentially romstage components, and M is raminit. Due to how |
|
260 |
|
coreboot works, these components must be split into single components. Coreboot |
|
261 |
|
doesn't use T by default (it implements CAR itself), but has the option to |
|
262 |
|
use it. It will use M and S, only. |
|
263 |
|
|
|
264 |
|
Technically, the process of splitting FSP into these three files counts as |
|
265 |
|
a modification. Furthermore, coreboot also rebases the M module by modifying |
|
266 |
|
certain pointers, so that it can integrate with coreboot to provide raminit. |
|
267 |
|
|
|
268 |
|
Intel *themselves* own the copyright to the tool for splitting FSP, |
|
269 |
|
at `3rdparty/fsp/Tools/SplitFspBin.py`, and it seems that they do intend for |
|
270 |
|
the FSP to be used this way. However, until now, those using the Intel FSP |
|
271 |
|
have built coreboot images from source, so the issue of modified distributions |
|
272 |
|
didn't come up. |
|
273 |
|
|
|
274 |
|
By the strictest possible interpretation of Intel's licensing, Libreboot was |
|
275 |
|
technically in violation. To mitigate this, Libreboot 20241206 *revision 8* and |
|
276 |
|
newer, will no longer include the Intel FSP inside images. Instead, the vendor |
|
277 |
|
inject script is used for inserting the FSP into release images, which is what |
|
278 |
|
we already do for several other components. |
|
279 |
|
|
|
280 |
|
`_fsp` vs `_vfsp` targets |
|
281 |
|
------------------------- |
|
282 |
|
|
|
283 |
|
The original 20241206 release images had `_fsp` in the file name. From rev8 |
|
284 |
|
onward, `_vfsp` is specified instead. |
|
285 |
|
|
|
286 |
|
Libreboot's inject script verifies checksums on files, when inserting into the |
|
287 |
|
images. Because of this, if we inject FSP after the fact, that means anyone |
|
288 |
|
using the old images will find errors when they try. |
|
289 |
|
|
|
290 |
|
To mitigate this, the build targets containing `_fsp` in the name have been |
|
291 |
|
retained, but these targets are set `release="n"` so that no ROM images are |
|
292 |
|
provided in releases. The `_vfsp` images are provided pre-compiled, instead. |
|
293 |
|
|
|
294 |
|
With this re-design, modern lbmk (from Libreboot 20241206 rev8 onward) can still |
|
295 |
|
reliably inject Intel ME into the old `_fsp` images, if you already downloaded |
|
296 |
|
those before. |
|
297 |
|
|
|
298 |
|
Therefore, you must be especially careful to get this right. If you're running |
|
299 |
|
the inject script into a tarball, it will generally detect the right one, but |
|
300 |
|
inserting manually into individual image files is also possible; if you do this, |
|
301 |
|
you must remember to correctly specify `t480_vfsp_16mb` or `t480s_vfsp_16mb`, |
|
302 |
|
or to specify the `_fsp` targets if you're doing this on older images. |
|
303 |
|
|
|
304 |
|
It is extremely unlikely that Intel would have ever cracked down on Libreboot |
|
305 |
|
for its previous mistake, since many other projects exist that include FSP |
|
306 |
|
directly in coreboot images, even commercially. However, Libreboot wishes to |
|
307 |
|
respect Intel's license, in the |
|
308 |
|
most [technically correct](https://www.youtube.com/watch?v=0ZEuWJ4muYc) way |
|
309 |
|
possible. |
|
310 |
|
|
241 |
311 |
Errata |
Errata |
242 |
312 |
====== |
====== |
243 |
313 |
|
|
File site/docs/install/t480.md changed (mode: 100644) (index 8cd01ba..8580165) |
... |
... |
OR YOU MIGHT BRICK YOUR MACHINE: [SAFETY PRECAUTIONS](../../news/safety.md)** |
32 |
32 |
|
|
33 |
33 |
|
|
34 |
34 |
``` |
``` |
35 |
|
W+: Works without blobs; |
|
|
35 |
|
W+: Works without vendor firmware; |
36 |
36 |
N: Doesn't work; |
N: Doesn't work; |
37 |
|
W*: Works with blobs; |
|
|
37 |
|
W*: Works with vendor firmware; |
38 |
38 |
U: Untested; |
U: Untested; |
39 |
39 |
P+: Partially works; |
P+: Partially works; |
40 |
|
P*: Partially works with blobs |
|
|
40 |
|
P*: Partially works with vendor firmware |
41 |
41 |
?: UNKNOWN AT THIS TIME |
?: UNKNOWN AT THIS TIME |
42 |
42 |
``` |
``` |
43 |
43 |
|
|
|
... |
... |
This should also be the case for the T480s. |
707 |
707 |
If you encounter this issue, check\ |
If you encounter this issue, check\ |
708 |
708 |
[this page](../../faq.md#thinkpad-acpi) |
[this page](../../faq.md#thinkpad-acpi) |
709 |
709 |
for details as to how to fix this. |
for details as to how to fix this. |
710 |
|
|
|
711 |
|
Intel FSP copyright |
|
712 |
|
=================== |
|
713 |
|
|
|
714 |
|
If you just want to inject Intel FSP and ME into your image, ready for |
|
715 |
|
flashing, please read [the guide](ivy_has_common.md). |
|
716 |
|
|
|
717 |
|
Abstract |
|
718 |
|
-------- |
|
719 |
|
|
|
720 |
|
The initial Libreboot 20241206 release included Intel FSP directly inside the |
|
721 |
|
ROM images. Intel provides the FSP under a license which states (and I |
|
722 |
|
paraphrase): you must not modify it, but you can redistribute it freely, so |
|
723 |
|
long as the license notice is retained. |
|
724 |
|
|
|
725 |
|
The FSP is a concatenation of three modules: FSP-T, FSP-S and FSP-M. T basically |
|
726 |
|
does CAR, S is essentially romstage components, and M is raminit. Due to how |
|
727 |
|
coreboot works, these components must be split into single components. Coreboot |
|
728 |
|
doesn't use T by default (it implements CAR itself), but has the option to |
|
729 |
|
use it. It will use M and S, only. |
|
730 |
|
|
|
731 |
|
Technically, the process of splitting FSP into these three files counts as |
|
732 |
|
a modification. Furthermore, coreboot also rebases the M module by modifying |
|
733 |
|
certain pointers, so that it can integrate with coreboot to provide raminit. |
|
734 |
|
|
|
735 |
|
Intel *themselves* own the copyright to the tool for splitting FSP, |
|
736 |
|
at `3rdparty/fsp/Tools/SplitFspBin.py`, and it seems that they do intend for |
|
737 |
|
the FSP to be used this way. However, until now, those using the Intel FSP |
|
738 |
|
have built coreboot images from source, so the issue of modified distributions |
|
739 |
|
didn't come up. |
|
740 |
|
|
|
741 |
|
By the strictest possible interpretation of Intel's licensing, Libreboot was |
|
742 |
|
technically in violation. To mitigate this, Libreboot 20241206 *revision 8* and |
|
743 |
|
newer, will no longer include the Intel FSP inside images. Instead, the vendor |
|
744 |
|
inject script is used for inserting the FSP into release images, which is what |
|
745 |
|
we already do for several other components. |
|
746 |
|
|
|
747 |
|
`_fsp` vs `_vfsp` targets |
|
748 |
|
------------------------- |
|
749 |
|
|
|
750 |
|
The original 20241206 release images had `_fsp` in the file name. From rev8 |
|
751 |
|
onward, `_vfsp` is specified instead. |
|
752 |
|
|
|
753 |
|
Libreboot's inject script verifies checksums on files, when inserting into the |
|
754 |
|
images. Because of this, if we inject FSP after the fact, that means anyone |
|
755 |
|
using the old images will find errors when they try. |
|
756 |
|
|
|
757 |
|
To mitigate this, the build targets containing `_fsp` in the name have been |
|
758 |
|
retained, but these targets are set `release="n"` so that no ROM images are |
|
759 |
|
provided in releases. The `_vfsp` images are provided pre-compiled, instead. |
|
760 |
|
|
|
761 |
|
With this re-design, modern lbmk (from Libreboot 20241206 rev8 onward) can still |
|
762 |
|
reliably inject Intel ME into the old `_fsp` images, if you already downloaded |
|
763 |
|
those before. |
|
764 |
|
|
|
765 |
|
Therefore, you must be especially careful to get this right. If you're running |
|
766 |
|
the inject script into a tarball, it will generally detect the right one, but |
|
767 |
|
inserting manually into individual image files is also possible; if you do this, |
|
768 |
|
you must remember to correctly specify `t480_vfsp_16mb` or `t480s_vfsp_16mb`, |
|
769 |
|
or to specify the `_fsp` targets if you're doing this on older images. |
|
770 |
|
|
|
771 |
|
It is extremely unlikely that Intel would have ever cracked down on Libreboot |
|
772 |
|
for its previous mistake, since many other projects exist that include FSP |
|
773 |
|
directly in coreboot images, even commercially. However, Libreboot wishes to |
|
774 |
|
respect Intel's license, in the |
|
775 |
|
most [technically correct](https://www.youtube.com/watch?v=0ZEuWJ4muYc) way |
|
776 |
|
possible. |
|
File site/news/libreboot20231021.md changed (mode: 100644) (index 25ee50a..d8fdb64) |
... |
... |
logs, combined: |
303 |
303 |
* Don't use the `-B` option in make commands. |
* Don't use the `-B` option in make commands. |
304 |
304 |
* Where no-microcode ROM images are provided, ensure that the ROM hashes still |
* Where no-microcode ROM images are provided, ensure that the ROM hashes still |
305 |
305 |
match when running the vendor inject script. This is only useful on the |
match when running the vendor inject script. This is only useful on the |
306 |
|
Dell Latitude E6400, which is otherwise blob-free but (in Libreboot) |
|
|
306 |
|
Dell Latitude E6400, which is otherwise 100% free software but (in Libreboot) |
307 |
307 |
comes with or without microcode updates, and with or without the Nvidia VGA |
comes with or without microcode updates, and with or without the Nvidia VGA |
308 |
308 |
ROM (handled by vendor inject/download scripts) for dGPU variants. Verification |
ROM (handled by vendor inject/download scripts) for dGPU variants. Verification |
309 |
309 |
previously failed, under certain conditions, when inserting that VGA ROM. |
previously failed, under certain conditions, when inserting that VGA ROM. |
|
... |
... |
logs, combined: |
346 |
346 |
* Don't support removal of microcode (during release time) on untested targets. |
* Don't support removal of microcode (during release time) on untested targets. |
347 |
347 |
Set `microcode_required="y"` on most boards, but leave it set to `"n"` on |
Set `microcode_required="y"` on most boards, but leave it set to `"n"` on |
348 |
348 |
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that |
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that |
349 |
|
can be blob-free, in other words. |
|
|
349 |
|
can be entirely free software in the main boot flash, in other words. |
350 |
350 |
* Improved Dell Latitude E6400 support; the same image now provides iGPU and |
* Improved Dell Latitude E6400 support; the same image now provides iGPU and |
351 |
351 |
dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into |
dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into |
352 |
352 |
the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU |
the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU |
File site/news/libreboot20240612.md changed (mode: 100644) (index ed9808c..6a5550d) |
... |
... |
Feature changes |
221 |
221 |
* Print a two-line break before confirming the location of the generated |
* Print a two-line break before confirming the location of the generated |
222 |
222 |
release archive, when running release builds. This makes it more obvious |
release archive, when running release builds. This makes it more obvious |
223 |
223 |
to the operator. |
to the operator. |
224 |
|
* **Removed the MRC (raminit blob) on Intel Haswell** (4th generation) |
|
|
224 |
|
* **Removed the MRC (vendor raminit code) on Intel Haswell** (4th generation) |
225 |
225 |
hardware, namely the ThinkPad T440p, W541, Dell OptiPlex 9020 MT |
hardware, namely the ThinkPad T440p, W541, Dell OptiPlex 9020 MT |
226 |
226 |
and Dell OptiPlex 9020 SFF; the libre raminit now works well, and S3 works. |
and Dell OptiPlex 9020 SFF; the libre raminit now works well, and S3 works. |
227 |
227 |
* Removed all status checks from script/roms (formerly script/build/roms), |
* Removed all status checks from script/roms (formerly script/build/roms), |
|
... |
... |
The changes are, from newest to earliest: |
360 |
360 |
fixing a bug that was actually triggered, and a preventative bug fix as the |
fixing a bug that was actually triggered, and a preventative bug fix as the |
361 |
361 |
original code wasn't correct either, even on AMD64 hosts (where it happened |
original code wasn't correct either, even on AMD64 hosts (where it happened |
362 |
362 |
to compile anyway). |
to compile anyway). |
363 |
|
* include/vendor.sh: Skip a given blob if the path to it is `/dev/null` - this |
|
|
363 |
|
* include/vendor.sh: Skip a given file if the path to it is `/dev/null` - this |
364 |
364 |
fixes a bug exposed by the previous change two bullet points down (fine |
fixes a bug exposed by the previous change two bullet points down (fine |
365 |
365 |
grained error control), because VGA ROMs are handled but the KGPE-D16 target |
grained error control), because VGA ROMs are handled but the KGPE-D16 target |
366 |
366 |
mitigates a crash bug when PIKE2008's option ROM is executed by SeaBIOS, by |
mitigates a crash bug when PIKE2008's option ROM is executed by SeaBIOS, by |
|
... |
... |
these changes relative to the old one: |
619 |
619 |
* 192e23b7 vbe: implement function 09h (get/set palette data) |
* 192e23b7 vbe: implement function 09h (get/set palette data) |
620 |
620 |
* 3722c21d vgasrc: round up save/restore size |
* 3722c21d vgasrc: round up save/restore size |
621 |
621 |
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info |
* 5d87ff25 vbe: Add VBE 2.0+ OemData field to struct vbe_info |
622 |
|
* 163fd9f0 fix smbios blob length overflow |
|
|
622 |
|
* 163fd9f0 fix smbios data length overflow |
623 |
623 |
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB. |
* 82faf1d5 Add LBA 64bit support for reads beyond 2TB. |
624 |
624 |
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code |
* 3f082f38 Add AHCI Power ON + ICC_ACTIVE into port setup code |
625 |
625 |
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes |
* 3ae88886 esp-scsi: terminate DMA transfer when ESP data transfer completes |
|
... |
... |
The latest changes are listed first, going all the way down to earlier changes: |
802 |
802 |
* | f6cbc501 import nuke() from cbmk cdce8ba70b |
* | f6cbc501 import nuke() from cbmk cdce8ba70b |
803 |
803 |
|/ |
|/ |
804 |
804 |
* 7fbcb7be coreboot t440p/w541: enable nvme in grub_scan_disk |
* 7fbcb7be coreboot t440p/w541: enable nvme in grub_scan_disk |
805 |
|
* 47f582d4 ./vendor download: skip if blob path is /dev/null |
|
|
805 |
|
* 47f582d4 ./vendor download: skip if file path is /dev/null |
806 |
806 |
* e7cb10d6 do not allow dashes in coreboot target names |
* e7cb10d6 do not allow dashes in coreboot target names |
807 |
807 |
* e9b9e825 ./vendor download: more fine-tuned error control |
* e9b9e825 ./vendor download: more fine-tuned error control |
808 |
808 |
* 0dd0dfaf vendor.sh: don't error on main targets |
* 0dd0dfaf vendor.sh: don't error on main targets |
|
... |
... |
The latest changes are listed first, going all the way down to earlier changes: |
919 |
919 |
* 190495d2 disable x301 for next release (for now) |
* 190495d2 disable x301 for next release (for now) |
920 |
920 |
* 03fae0cf mrc.sh: remove redundant function extract_ref() |
* 03fae0cf mrc.sh: remove redundant function extract_ref() |
921 |
921 |
* f66ceef6 print two line breaks before confirming release |
* f66ceef6 print two line breaks before confirming release |
922 |
|
* cc339741 remove haswell mrc blob (libre raminit stable now) |
|
|
922 |
|
* cc339741 remove haswell mrc file (libre raminit stable now) |
923 |
923 |
* 05fbd392 remove all status checks. only handle release. |
* 05fbd392 remove all status checks. only handle release. |
924 |
924 |
* 8ba0fd83 git.sh: remove errant comment |
* 8ba0fd83 git.sh: remove errant comment |
925 |
925 |
* d7ce26dc move script/*/* to script/ |
* d7ce26dc move script/*/* to script/ |
File site/news/policy.de.md changed (mode: 100644) (index c3b071a..1ad4405) |
... |
... |
The libreboot project has the following policy: |
107 |
107 |
to tell people how to *neuter* the ME, if possible on a given board. |
to tell people how to *neuter* the ME, if possible on a given board. |
108 |
108 |
The `me_cleaner` program is very useful, and provides a much more secure ME |
The `me_cleaner` program is very useful, and provides a much more secure ME |
109 |
109 |
configuration. |
configuration. |
110 |
|
* Vendor blobs should *never* be deleted, even if they are unused. In the |
|
|
110 |
|
* Such vendor files should *never* be deleted, even if they are unused. In the |
111 |
111 |
coreboot project, a set of `3rdparty` submodules are available, with vendor |
coreboot project, a set of `3rdparty` submodules are available, with vendor |
112 |
|
blobs for init tasks on many boards. These must *all* be included in libreboot |
|
|
112 |
|
files for init tasks on many boards. These must *all* be included in libreboot |
113 |
113 |
releases, even if unused. That way, even if the Libreboot build system does |
releases, even if unused. That way, even if the Libreboot build system does |
114 |
114 |
not yet integrate support for a given board, someone who downloads libreboot |
not yet integrate support for a given board, someone who downloads libreboot |
115 |
115 |
can still make changes to their local version of the build system, if they |
can still make changes to their local version of the build system, if they |
File site/news/policy.md changed (mode: 100644) (index 2777c0f..7db07c3) |
... |
... |
The libreboot project has the following policy: |
98 |
98 |
to tell people how to *neuter* the ME, if possible on a given board. |
to tell people how to *neuter* the ME, if possible on a given board. |
99 |
99 |
The `me_cleaner` program is very useful, and provides a much more secure ME |
The `me_cleaner` program is very useful, and provides a much more secure ME |
100 |
100 |
configuration. |
configuration. |
101 |
|
* Vendor blobs should *never* be deleted, even if they are unused. In the |
|
|
101 |
|
* Such vendor files should *never* be deleted, even if they are unused. In the |
102 |
102 |
coreboot project, a set of `3rdparty` submodules are available, with vendor |
coreboot project, a set of `3rdparty` submodules are available, with vendor |
103 |
103 |
code for init tasks on many boards. These must *all* be included in libreboot |
code for init tasks on many boards. These must *all* be included in libreboot |
104 |
104 |
releases, even if unused. That way, even if the Libreboot build system does |
releases, even if unused. That way, even if the Libreboot build system does |
|
... |
... |
examples of how this very policy is implemented in Libreboot: |
154 |
154 |
* Newer Intel platforms have Intel ME, which is a coprocessor inside the |
* Newer Intel platforms have Intel ME, which is a coprocessor inside the |
155 |
155 |
machine that handles many functions including certain power management, and |
machine that handles many functions including certain power management, and |
156 |
156 |
it can provides useful remote management features with Intel AMT for example. |
it can provides useful remote management features with Intel AMT for example. |
157 |
|
This is a giant 5MB+ blob in the flash, and the ME has full access to your |
|
|
157 |
|
This is a giant 5MB+ section in the flash, and the ME has full access to your |
158 |
158 |
RAM and other peripherals; more is documented about this in the Libreboot |
RAM and other peripherals; more is documented about this in the Libreboot |
159 |
159 |
FAQ. On older ME4-based platforms such as Intel GM45 platforms, e.g. |
FAQ. On older ME4-based platforms such as Intel GM45 platforms, e.g. |
160 |
160 |
ThinkPad X200/T400, we remove the ME firmware entirely from the flash, leaving |
ThinkPad X200/T400, we remove the ME firmware entirely from the flash, leaving |
|
... |
... |
examples of how this very policy is implemented in Libreboot: |
170 |
170 |
actually run anything. ME Cleaner is required, instead of full removal, |
actually run anything. ME Cleaner is required, instead of full removal, |
171 |
171 |
because the machines don't boot reliably without at least the BUP/ROMP |
because the machines don't boot reliably without at least the BUP/ROMP |
172 |
172 |
modules present in flash. |
modules present in flash. |
173 |
|
* On Intel Haswell platform (Intel 4th gen), a binary blob is available for |
|
|
173 |
|
* On Intel Haswell platform (Intel 4th gen), vendor firmware is available for |
174 |
174 |
memory controller initialisation, called the Intel *MRC* or System Agent. We |
memory controller initialisation, called the Intel *MRC* or System Agent. We |
175 |
175 |
previously included this in Libreboot; nowadays, we have free initialisation |
previously included this in Libreboot; nowadays, we have free initialisation |
176 |
176 |
code written by Angel Pons. The libre code, called NRI (Native RAM |
code written by Angel Pons. The libre code, called NRI (Native RAM |
File site/news/safety.md changed (mode: 100644) (index 193213d..ce6e1a9) |
2 |
2 |
% Leah Rowe |
% Leah Rowe |
3 |
3 |
% 7 July 2023 |
% 7 July 2023 |
4 |
4 |
|
|
|
5 |
|
New safety features |
|
6 |
|
=============== |
|
7 |
|
|
|
8 |
|
NOTE: This page is mostly completely obsolete, as of 3 January 2025; changes |
|
9 |
|
made in the vendor inject script for Libreboot 20241206 rev8 or higher (and |
|
10 |
|
releases newer than the 20241206 series) make the script almost completely |
|
11 |
|
safe to use, as described in the section pertaining to this on |
|
12 |
|
the [main guide](../docs/install/ivy_has_common.md). |
|
13 |
|
|
|
14 |
|
To summarise, those new safety features are as follows: |
|
15 |
|
|
|
16 |
|
* Newer release ROMs (20241206rev8 or higher, or releases newer than 20241206 |
|
17 |
|
series) have 1-byte padding on non-inject images, to trigger an error in |
|
18 |
|
flashprog due to a size mismatch versus chip size, and they have the |
|
19 |
|
words `DO_NOT_FLASH` in the image file names. (older release images don't |
|
20 |
|
have this, so watch out) |
|
21 |
|
* Injects directly into the *tarballs*, and replaces the given tarball with |
|
22 |
|
one containing the injected images. Older versions left the tarball |
|
23 |
|
untouched and outputted images to `bin/release/` (directory), whereas many |
|
24 |
|
users wrongly believed they could use the tarball; the new version therefore |
|
25 |
|
adheres accordingly to the user's natural expectation, in this regard. |
|
26 |
|
* Avoids replacing the tarball, where errors are observed, and prints much more |
|
27 |
|
pedantic error messages, to let the user know that they must *stop* and take |
|
28 |
|
note. |
|
29 |
|
|
|
30 |
|
With this in mind, the original article written below is largely obsolete, and |
|
31 |
|
the steps below (which would require extreme over-engineering) are probably not |
|
32 |
|
going to be implemented. |
|
33 |
|
|
|
34 |
|
Now, continue reading the article below, if you wish! |
|
35 |
|
|
|
36 |
|
NOTE: The sections in the article below are *still* important to read, so please |
|
37 |
|
do read it, and note that **you must |
|
38 |
|
still [insert vendor files](../docs/install/ivy_has_common.md) regardless, |
|
39 |
|
prior to Libreboot installation, if required on your board.** |
|
40 |
|
|
|
41 |
|
Article |
|
42 |
|
======= |
|
43 |
|
|
5 |
44 |
**Please also follow this guide if using Dell Latitude laptops.** |
**Please also follow this guide if using Dell Latitude laptops.** |
6 |
45 |
|
|
7 |
46 |
**If unsure, just follow this guide. If you follow this guide on a board that |
**If unsure, just follow this guide. If you follow this guide on a board that |
|
... |
... |
BIOS region is coreboot. |
113 |
152 |
Per the issue page, I intend to implement the following regime in future |
Per the issue page, I intend to implement the following regime in future |
114 |
153 |
Libreboot releases, on the affected machines: |
Libreboot releases, on the affected machines: |
115 |
154 |
|
|
116 |
|
* If BIOS region blob-free (no MRC/EC firmware needed): set IFD, GbE and BIOS |
|
117 |
|
regions read-write by default, but lock the ME region. |
|
|
155 |
|
* BIOS region doesn't need vendor files (no MRC/EC firmware needed): set IFD, |
|
156 |
|
GbE and BIOS regions read-write by default, but lock the ME region. |
118 |
157 |
* If BIOS region requires vendor files: set IFD and GbE regions read-write |
* If BIOS region requires vendor files: set IFD and GbE regions read-write |
119 |
158 |
by default, but lock the ME and BIOS regions. |
by default, but lock the ME and BIOS regions. |
120 |
159 |
|
|