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

update 

Signed-off-by: Leah Rowe <info@minifree.org>
master
Leah Rowe 2024-05-28 00:07:53 +01:00
parent 1930325800
commit ec4e4007fa
2 changed files with 16 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -25,37 +25,20 @@ libreboot from the available source code.
The following document describes how `lbmk` works, and how you can make changes
to it: [libreboot maintenance manual](../maintain/)
Release status
==============
Information about status will be reported during builds; if a board is
marked as stable, the build proceeds without further input. If the board is
marked anything other, a warning appears asking if you wish to proceed; to
disable these warnings, do this before building (not recommended):
export LBMK_STATUS=n
In Libreboot, we specify: `stable`, `unstable`, `broken` or `untested`.
The "unstable" marking means that the board boots mostly/entirely reliably
annd should be safe to use, but may have a few issues, but nothing which would,
for example, cause safety issues e.g. thermal, data reliability etc.
The `broken` setting means that a given board will likely brick if flashed.
The `untested` setting means untested.
Release status is always set with regards to the current lbmk revision, on
the theory that the current revision is being used to generate a full release.
Multi-threaded builds
=====================
Libreboot's build system defaults to a single build thread, but you can change
it by doing e.g.
export LBMK_THREADS=4
export XBMK_THREADS=4
This would make lbmk run on 4 threads.
More specifically: when compiling source trees via `script/trees`, `-jTHREADS`
is passed, where THREADS is the number of threads. This is also set when running
xz commands for compression, using the `-t` option.
Environmental variables
=======================

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

@ -31,12 +31,17 @@ with `seabios_` at the start of the file name, and `grubfirst` at the end;
these place a bootorder file in CBFS, so that SeaBIOS loads GRUB first, but
you can still press ESC to bring up the SeaBIOS boot select menu.
The error above, in the linked bug report, occurs on `grub_free()`
or `grub_realloc()` and could be caused by anything in GRUB; the user tested
on memtest86plus and got no errors, and SeaBIOS works; BIOS GRUB (from a distro)
also works, where GRUB doesn't need as many drivers; we suspect this may be
a use-after-free in a GRUB driver, or otherwise something writing to heap memory
wrongly. The bug is not yet known, only the symptom (the fatal error message).
*This warning applies to Libreboot 20240504 and other recent releases.*
**We have since fully mitigated this bug**; SeaBIOS is now the primary payload on
all boards, with GRUB still available in the boot select menu, and we have
identified that it was caused by the xHCI driver which has since been removed
for the affected machines(machines which don't have xHCI anyway, but they
touch code that does run on the given machines). The xHCI support works fine
on some newer machines and will be re-added there by making GRUB multi-tree,
so that different boards can use different versions of GRUB. This will be done,
and present in the next Libreboot release after 20240504, in addition to fixing
the actual bug itself. **For now, there are no problems!**
Libreboot releases after 20240504 will *only* (on x86) contain ROM images where
SeaBIOS is the first payload, without disabling the SeaBIOS menu (no `grubonly`). You'll still be able to use GRUB, either by pressing ESC for the boot