Leah Rowe
parent
b5ca9e1686
commit
a2164297b9
|
|
@ -108,6 +108,9 @@ On Fedora, you can use the following
|
|||
|
||||
sudo dnf install python-unversioned-command
|
||||
|
||||
On most modern distros, Python 2 is no longer included and Python 3 will be
|
||||
the only one available on the `python`.
|
||||
|
||||
How to compile Libreboot
|
||||
========================
|
||||
|
||||
|
|
@ -132,24 +135,24 @@ Fedora, Arch Linux/Parabola or Void Linux.
|
|||
|
||||
Some examples (run them as root, use use e.g. `sudo`, `doas`):
|
||||
|
||||
./build dependencies ubuntu
|
||||
./mk dependencies ubuntu
|
||||
|
||||
or
|
||||
|
||||
./build dependencies debian
|
||||
./mk dependencies debian
|
||||
|
||||
or
|
||||
|
||||
./build dependencies fedora38
|
||||
./mk dependencies fedora38
|
||||
|
||||
or
|
||||
|
||||
./build dependencies arch
|
||||
./mk dependencies arch
|
||||
|
||||
NOTE: In case of Ubuntu 20.04 LTS or derived distros for that specific release,
|
||||
use the dedicated configuration file:
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
Check: `config/dependencies/` for list of supported distros.
|
||||
|
||||
|
|
@ -161,32 +164,32 @@ Next, build ROM images
|
|||
----------------------
|
||||
|
||||
Libreboot MaKe (lbmk) automatically runs all necessary commands; for
|
||||
example, `./build roms` will automatically run `./build grub`
|
||||
if the required GRUB payload (under `elf/grub/`) does not exist.
|
||||
example, `./mk -b coreboot` will automatically build the required payloads
|
||||
if not already compiled.
|
||||
|
||||
As a result, you can now (after installing the correct build dependencies) run
|
||||
just a single command, from a fresh Git clone, to build all ROM images:
|
||||
|
||||
./build roms all
|
||||
./mk -b coreboot
|
||||
|
||||
or even just build specific ROM images, e.g.:
|
||||
|
||||
./build roms x60
|
||||
./mk -b coreboot x60
|
||||
|
||||
or get a list of supported build targets:
|
||||
|
||||
./build roms list
|
||||
./mk -b coreboot list
|
||||
|
||||
Or maybe just build payloads?
|
||||
-----------------------------
|
||||
|
||||
If you wish to build payloads, you can also do that. For example:
|
||||
|
||||
./build grub
|
||||
./mk -b grub
|
||||
|
||||
./update trees -b seabios
|
||||
./mk -b seabios
|
||||
|
||||
./update trees -b u-boot
|
||||
./mk -b u-boot
|
||||
|
||||
Previous steps will be performed automatically. However, you can *still* run
|
||||
individual parts of the build system manually, if you choose. This may be
|
||||
|
|
@ -199,7 +202,7 @@ Want to modify Libreboot?
|
|||
Check the [lbmk maintenance manual](../maintain/) for guidance. You may for
|
||||
example want to modify a config, e.g.:
|
||||
|
||||
./update trees -m coreboot x200_8mb
|
||||
./mk -m coreboot x200_8mb
|
||||
|
||||
Or perhaps add a new board! The maintenance manual will teach you how the
|
||||
Libreboot build system (lbmk) works!
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ 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
|
||||
export XBMK_STATUS=n
|
||||
|
||||
In Libreboot, we specify: `stable`, `unstable`, `broken` or `untested`.
|
||||
The "unstable" marking means that the board boots mostly/entirely reliably
|
||||
|
|
@ -64,7 +64,7 @@ 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.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Environmental variables
|
|||
Please read about environmental variables in [the build
|
||||
instructions](../maintain/), before running lbmk. You should set
|
||||
your variables accordingly, though you do not technically need to; some
|
||||
of them may be useful, e.g. `LBMK_THREADS` (sets the number of build threads).
|
||||
of them may be useful, e.g. `XBMK_THREADS` (sets the number of build threads).
|
||||
|
||||
Environmental variables
|
||||
=======================
|
||||
|
|
@ -82,7 +82,7 @@ Environmental variables
|
|||
Please read about environmental variables in [the build
|
||||
instructions](../maintain/), before running lbmk. You should set
|
||||
your variables accordingly, though you do not technically need to; some
|
||||
of them may be useful, e.g. `LBMK_THREADS` (sets the number of build threads).
|
||||
of them may be useful, e.g. `XBMK_THREADS` (sets the number of build threads).
|
||||
|
||||
Git
|
||||
===
|
||||
|
|
@ -127,15 +127,15 @@ time or date can cause connections to be dropped during negotiation.
|
|||
libreboot включає сценарій, який автоматично встановлює apt-get залежності
|
||||
в Ubuntu 20.04:
|
||||
|
||||
sudo ./build dependencies ubuntu2004
|
||||
sudo ./mk dependencies ubuntu2004
|
||||
|
||||
Окремі сценарії також існують:
|
||||
|
||||
sudo ./build dependencies debian
|
||||
sudo ./mk dependencies debian
|
||||
|
||||
sudo ./build dependencies arch
|
||||
sudo ./mk dependencies arch
|
||||
|
||||
sudo ./build dependencies void
|
||||
sudo ./mk dependencies void
|
||||
|
||||
Check: `config/dependencies/` for list of supported distros.
|
||||
|
||||
|
|
@ -150,23 +150,23 @@ libreboot Make (lbmk) автоматично виконує всі необхі
|
|||
В якості результату, ви тепер можете (після встановлення правильних залежностей побудови) виконати
|
||||
лише одну команду, з свіжого Git clone, для побудови образів ROM:
|
||||
|
||||
./build roms all
|
||||
./mk -b coreboot
|
||||
|
||||
або навіть побудувати конкретні образи ROM, такі як:
|
||||
|
||||
./build roms x60
|
||||
./mk -b coreboot x60
|
||||
|
||||
or get a list of supported build targets:
|
||||
|
||||
./build roms list
|
||||
./mk -b coreboot list
|
||||
|
||||
Якщо ви бажаєте побудувати корисні навантаження, можете зробити це. Наприклад:
|
||||
|
||||
./build grub
|
||||
./mk -b grub
|
||||
|
||||
./update trees -b seabios
|
||||
./mk -b seabios
|
||||
|
||||
./update trees -b u-boot
|
||||
./mk -b u-boot
|
||||
|
||||
Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
|
||||
окремі частини системи побудови власноруч, якщо виберете. Це може бути
|
||||
|
|
|
|||
|
|
@ -3,9 +3,6 @@ title: GRUB payload
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
TODO: this guide should be reviewed and updated. Some info might be out of
|
||||
date.
|
||||
|
||||
GRUB already has excellent
|
||||
documentation, but there are aspects of libreboot that deserve special
|
||||
treatment. libreboot provides the option to boot GRUB directly, running on
|
||||
|
|
@ -33,10 +30,16 @@ files:
|
|||
When you build GRUB from source, you can use the `grub-mklayout` program to
|
||||
create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
|
||||
|
||||
Te compile GRUB, in lbmk, do this:
|
||||
|
||||
./mk -b grub default
|
||||
|
||||
Other GRUB trees are available, but the `default` one will do for now.
|
||||
|
||||
When you've built GRUB, using `lbmk` (libreboot build system), take your kepmap
|
||||
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
|
||||
|
||||
cat frazerty | ./src/grub/grub-mklayout -o frazerty.gkb
|
||||
cat frazerty | ./src/grub/default/grub-mklayout -o frazerty.gkb
|
||||
|
||||
Place the newly created `.gkb` file under `config/grub/keymap` in lbmk. When
|
||||
you build libreboot, a ROM image with GRUB payload and your newly created
|
||||
|
|
|
|||
|
|
@ -164,11 +164,11 @@ Build ROM image from source
|
|||
|
||||
For the MT variant (7020 MT and 9020 MT):
|
||||
|
||||
./build roms dell9020mt_12mb
|
||||
./mk -b coreboot dell9020mt_nri_12mb
|
||||
|
||||
For the SFF variant (7020 SFF and 9020 SFF):
|
||||
|
||||
./build roms dell9020sff_12mb
|
||||
./mk -b coreboot dell9020sff_nri_12mb
|
||||
|
||||
It is important that you choose the right one. The MT variant is the full
|
||||
MTX tower.
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Build ROM image from source
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms hp2170p_16mb
|
||||
./mk -b coreboot hp2170p_16mb
|
||||
|
||||
Installation
|
||||
============
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ about this:
|
|||
Refer to the coreboot guide for flashing instructions, and you can build the
|
||||
images for it in Libreboot like so:
|
||||
|
||||
./build roms hp2560p_8mb
|
||||
./mk -b coreboot hp2560p_8mb
|
||||
|
||||
More information about building ROM images can be found in
|
||||
the [build guide](../build/).
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ a SOIC-16 chip instead of SOIC-8. Follow these instructions:
|
|||
Refer to that coreboot guide for flashing instructions, and you can
|
||||
build the images for it in Libreboot like so:
|
||||
|
||||
./build roms hp2570p_16mb
|
||||
./mk -b coreboot hp2570p_16mb
|
||||
|
||||
More information about building ROM images can be found in
|
||||
the [build guide](../build/).
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ to recover from an unbootable BIOS:
|
|||
|
||||
You can build the images for it in Libreboot like so:
|
||||
|
||||
./build roms hp8200sff_8mb
|
||||
./mk -b coreboot hp8200sff_8mb
|
||||
|
||||
More information about building ROM images can be found in
|
||||
the [build guide](../build/).
|
||||
|
|
@ -154,7 +154,7 @@ Pin-Strap is set". If it doesn't, start again from the beginning.
|
|||
|
||||
Now build the **4** MiB Libreboot image.
|
||||
|
||||
./build roms hp8200sff_4mb
|
||||
./mk -b coreboot hp8200sff_4mb
|
||||
|
||||
More information about building ROM images can be found in
|
||||
the [build guide](../build/).
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ release after Libreboot 20231106, you *must* use the latest `lbmk.git`.
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms hp820g2_12mb
|
||||
./mk -b coreboot hp820g2_12mb
|
||||
|
||||
NOTE: The actual flash is 16MB, but you must flash only the first 12MB of it.
|
||||
The ROM images provided by Libreboot are 12MB.
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Build ROM image from source
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms hp8460pintel_8mb
|
||||
./mk -b coreboot hp8460pintel_8mb
|
||||
|
||||
Installation
|
||||
============
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Build ROM image from source
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms hp8470pintel_16mb
|
||||
./mk -b coreboot hp8470pintel_16mb
|
||||
|
||||
Installation
|
||||
============
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ Build ROM image from source
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms hp8560w_8mb
|
||||
./mk -b coreboot hp8560w_8mb
|
||||
|
||||
Installation
|
||||
============
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Installation of Libreboot
|
|||
|
||||
You must first compile the Libreboot ROM
|
||||
|
||||
./build roms hp9470m_16mb
|
||||
./mk -b coreboot hp9470m_16mb
|
||||
|
||||
More information about building ROM images can be found in
|
||||
the [build guide](../build).
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Build ROM image from source
|
|||
|
||||
The build target, when building from source, is thus:
|
||||
|
||||
./build roms t1650_12mb
|
||||
./mk -b coreboot t1650_12mb
|
||||
|
||||
Installation
|
||||
============
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ Injecting vendor files into ROM
|
|||
You must determine the correct board name, for your board, based on the list
|
||||
generated when running this command:
|
||||
|
||||
./build roms list
|
||||
./mk -b coreboot list
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -110,20 +110,20 @@ You *must* ensure that the files were inserted.
|
|||
|
||||
Some examples of how to do that in lbmk:
|
||||
|
||||
./update trees -d coreboot TREENAME
|
||||
./mk -d coreboot TREENAME
|
||||
|
||||
Now you find `cbutitls/default`, which is a directory containing `cbfstool`
|
||||
Now you find `elf/cbfstool`, which is a directory containing `cbfstool`
|
||||
and `ifdtool`. Do this on your ROM image (`libreboot.rom` in the example
|
||||
below):
|
||||
|
||||
./cbutils/default/cbfstool libreboot.rom print
|
||||
./elf/cbfstool/TREENAME/cbfstool libreboot.rom print
|
||||
|
||||
You should check that the files were inserted in cbfs, if needed; for example,
|
||||
EC firmware or MRC firmware.
|
||||
|
||||
Next:
|
||||
|
||||
./cbutils/default/ifdtool -x libreboot.rom
|
||||
./elf/ifdtool/TREENAME/ifdtool -x libreboot.rom
|
||||
|
||||
This creates several `.bin` files, one of which says `me` in it (Intel ME).
|
||||
Run hexdump on it:
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Inject vendor files into ROM
|
|||
You must determine the correct board name, for your board, based on the list
|
||||
generated when running this command:
|
||||
|
||||
./build roms list
|
||||
./mk -b coreboot list
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -95,15 +95,11 @@ could build it yourself or you could also clone `lbmk.git` and [install build
|
|||
dependencies](../build/#first-install-build-dependencies), then inside lbmk,
|
||||
do:
|
||||
|
||||
./build serprog rp2040 pico
|
||||
|
||||
or for the W version:
|
||||
|
||||
./build serprog rp2040 pico_w
|
||||
./mk -b pico-serprog
|
||||
|
||||
This will automatically build the rpi-pico firmware, and the file will be
|
||||
at `bin/serprog_rp2040/serprog_pico.uf2`. This binary will be provided
|
||||
pre-compiled in the next Libreboot release, after the 20230625 release.
|
||||
at `bin/serprog_rp2040/serprog_pico.uf2`
|
||||
and `bin/serprog_rp2040/serprog_pico_w.uf2`.
|
||||
|
||||
Disconnect the Pico and proceed to wire it to your
|
||||
[flash chip](/docs/install/spi.html#identify-which-flash-type-you-have).
|
||||
|
|
@ -482,12 +478,12 @@ install flashprog. Do this after downloading the
|
|||
[lbmk Git repository](https://codeberg.org/libreboot/lbmk):
|
||||
|
||||
cd lbmk
|
||||
sudo ./build dependencies ubuntu2004
|
||||
sudo ./mk dependencies ubuntu2004
|
||||
|
||||
NOTE: debian, arch or void can be written instead of ubuntu2004. the debian
|
||||
script is also applicable to newer ubuntu versions
|
||||
|
||||
./update trees -b flashprog
|
||||
./mk -b flashprog
|
||||
|
||||
If the `ubuntu2004` script complains about missing dependencies, just modify
|
||||
the dependencies config to remove those dependencies. The script is located
|
||||
|
|
|
|||
|
|
@ -71,15 +71,11 @@ could build it yourself or you could also clone `lbmk.git` and [install build
|
|||
dependencies](../build/#first-install-build-dependencies), then inside lbmk,
|
||||
do:
|
||||
|
||||
./build serprog rp2040 pico
|
||||
|
||||
or for the W version:
|
||||
|
||||
./build serprog rp2040 pico_w
|
||||
./mk -b pico-serprog
|
||||
|
||||
This will automatically build the rpi-pico firmware, and the file will be
|
||||
at `bin/serprog_rp2040/serprog_pico.uf2`. This binary will be provided
|
||||
pre-compiled in the next Libreboot release, after the 20230625 release.
|
||||
at `bin/serprog_rp2040/serprog_pico.uf2`
|
||||
and `bin/serprog_rp2040/serprog_pico_w.uf2`.
|
||||
|
||||
Disconnect the Pico and proceed to wire it to your
|
||||
[flash chip](/docs/install/spi.html#identify-which-flash-type-you-have).
|
||||
|
|
@ -335,11 +331,11 @@ Flashrom 是用来读出、擦除、重写 NOR flash 内容的软件。
|
|||
使用 Git 仓库中的 libreboot 构建系统，你可以下载并安装 flashprog。首先下载 [lbmk Git 仓库](https://codeberg.org/libreboot/lbmk)，然后执行：
|
||||
|
||||
cd lbmk
|
||||
sudo ./build dependencies ubuntu2004
|
||||
sudo ./mk dependencies ubuntu2004
|
||||
|
||||
注意：你可以输入 debian、arch 或 void 来替换 ubuntu。debian 脚本也可以用于新版 ubuntu。
|
||||
|
||||
./update trees -b flashprog
|
||||
./mk -b flashprog
|
||||
|
||||
如果 `ubuntu2004` 报告了依赖缺失，编辑一下这个脚本，把缺失的依赖移除就行了。脚本位于 `config/dependencies/ubuntu2004`，它是写给 Ubuntu 20.04 的，但在其他使用 `apt-get` 包管理器的 Linux 发行版应该也能用。
|
||||
|
||||
|
|
|
|||
|
|
@ -59,15 +59,15 @@ Install the build dependencies. For Ubuntu 20.04 and similar, you can run
|
|||
the following command in the libreboot build system, from the root directory
|
||||
of the libreboot Git repository.
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
Then, download coreboot:
|
||||
|
||||
./update trees -f coreboot
|
||||
./mk -f coreboot
|
||||
|
||||
Finally, compile the `cbutils` payload (and you will then have the utils):
|
||||
|
||||
./build grub
|
||||
./mk -b grub
|
||||
|
||||
Among other things, this will produce a `cbfstool` executable under any of the
|
||||
subdirectories in `src/coreboot/` under `util/cbfstool/cbfstool`.
|
||||
|
|
@ -82,9 +82,9 @@ You will also want to build `flashprog` which libreboot recommends for reading
|
|||
from and/or writing to the boot flash. In the libreboot build system, you can
|
||||
build it by running this command:
|
||||
|
||||
./update trees -b flashprog
|
||||
./mk -b flashprog
|
||||
|
||||
An executable will be available at `src/flashprog/flashprog` after you have done
|
||||
An executable will be available at `elf/flashprog/flashprog` after you have done
|
||||
this.
|
||||
|
||||
Dump the boot flash
|
||||
|
|
@ -96,7 +96,7 @@ your computer, you can use `flashprog` to acquire it.
|
|||
Simply run the following, after using libreboot's build system to compile
|
||||
flashprog:
|
||||
|
||||
sudo ./src/flashprog/flashprog -p internal -r dump.bin
|
||||
sudo ./elf/flashprog/flashprog -p internal -r dump.bin
|
||||
|
||||
If flashprog complains about multiple flash chip definitions, do what it says to
|
||||
rectify your command and run it again.
|
||||
|
|
|
|||
|
|
@ -83,16 +83,12 @@ image:
|
|||
|
||||
You can build `cbfstool` in the libreboot build system. Run this command:
|
||||
|
||||
./update trees -d coreboot TREENAME
|
||||
|
||||
This assumes that you already downloaded coreboot:
|
||||
|
||||
./update trees -f coreboot
|
||||
./mk -d coreboot TREENAME
|
||||
|
||||
This, in turn, assumes that you have installed the build dependencies for
|
||||
libreboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
The `cbfstool` executables will be under each coreboot directory, under
|
||||
each `coreboot/boardname/` directory for each board. Just pick one, presumably
|
||||
|
|
@ -159,11 +155,9 @@ GRUB using the libreboot build system. Run the following commands (assuming
|
|||
you have the correct build dependencies installed) to build GRUB, from the
|
||||
libreboot Git repository:
|
||||
|
||||
./update trees -f grub
|
||||
./mk -b grub default
|
||||
|
||||
./build grub
|
||||
|
||||
The following executable will then be available under the `src/grub/` directory:
|
||||
The following executable will then be available under `src/grub/default/`:
|
||||
|
||||
grub-mkpasswd-pbkdf2
|
||||
|
||||
|
|
@ -249,24 +243,6 @@ NOTE: Before disabling the boot menu, make sure GRUB works. Access it using
|
|||
the `bootorder` file and/or press ESC in the SeaBIOS menu. Then disable the
|
||||
SeaBIOS menu.
|
||||
|
||||
Alternative: GRUB as primary
|
||||
----------------------------
|
||||
|
||||
The *SeaBIOS first* policy is now law, in Libreboot releases. The only
|
||||
exception is the x86 QEMU target. You can do this if building from source:
|
||||
|
||||
./build roms -p grub targetname
|
||||
|
||||
Where `targetname` is e.g. `x200_8mb` (use the correct one for your board).
|
||||
|
||||
Again: make sure GRUB works. Also: don't do this if you're using a non-Intel
|
||||
graphics card because only the Intel graphics have native video initialisation
|
||||
in Libreboot, and we rely on SeaBIOS to execute the VGA ROM for others.
|
||||
|
||||
(it is assumed that you know to add the VGA ROM in CBFS if needed, if using
|
||||
a dGPU, or that you're using a graphics card on a desktop so SeaBIOS will use
|
||||
that automatically)
|
||||
|
||||
GPG keys
|
||||
========
|
||||
|
||||
|
|
|
|||
|
|
@ -126,17 +126,74 @@ bin/
|
|||
This directory is created when running any of the following commands, with the
|
||||
right arguments:
|
||||
|
||||
./build roms ARGUMENTS_HERE
|
||||
./build roms serprog stm32
|
||||
./build roms serprog rp2040
|
||||
./mk -b coreboot ARGUMENTS_HERE
|
||||
./mk -b stm32-vserprog
|
||||
./mk -b pico-serprog
|
||||
|
||||
Simply speaking, `bin/` shall contain finished ROM images or firmware, that
|
||||
can then be installed (flashed) to the target device.
|
||||
|
||||
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/`!
|
||||
**These** are the ROM images that you should flash.
|
||||
|
||||
Older versions of lbmk build coreboot images separately under `elf/`, but
|
||||
without payloads, using `elf/` as a build cache, then inserting payloads
|
||||
into copies of these images in files under `bin/`. However, modern lbmk
|
||||
now only puts coreboot images in `bin/`, with payloads included.
|
||||
|
||||
If you still have `elf/` coreboot images in your lbmk tree, please do not
|
||||
use them (and you may aswell delete them).
|
||||
|
||||
cache/
|
||||
---------------
|
||||
|
||||
Certain files are cached here automatically, by lbmk. The user need not touch
|
||||
these files.
|
||||
|
||||
cache/app
|
||||
--------------
|
||||
|
||||
When vendor updates are extracted, they go here, which is then processed to
|
||||
find individual files for use in coreboot images (e.g. KBC1126 EC firmware).
|
||||
|
||||
This directory is constantly over-written, so it's essentially another temporary
|
||||
directory used by the build system.
|
||||
|
||||
cache/file/
|
||||
--------------
|
||||
|
||||
Files that are downloaded are hashed, and the cached version of the file
|
||||
is stored there, named as the SHA512 checksum. This is used for vendor file
|
||||
downloads, and subfile downloads.
|
||||
|
||||
A *subfile* is like a Git submodule, but it's a *file* (just a humble file),
|
||||
downloaded via curl/wget. The build system does not
|
||||
run `git submodule update` commands when handling Git repositories anymore,
|
||||
instead processing submodules manually; it supports both repositories *and*
|
||||
files relative to the directory locations for those repositories, but subfiles
|
||||
are not downloaded to the *cached git repository*, only the work directory used
|
||||
for building in lbmk.
|
||||
|
||||
cache/hash
|
||||
---------------
|
||||
|
||||
When lbmk is handling any project, it sorts a list of files under `config/`
|
||||
including `config/project` (or `config/project/TREE`) and `config/data/project`.
|
||||
|
||||
SHA512 checksums are calculated from these files, in the sorted order, and
|
||||
written in that order, to a file. *That* file is then checksummed, and this
|
||||
hash is stored in `cache/hash` for that project.
|
||||
|
||||
If the currently stored hash differs from what's calculated, it means that
|
||||
the project has changed, and the source directories plus builds are deleted.
|
||||
The project source is then re-prepared and re-build.
|
||||
|
||||
cache/repo
|
||||
--------------
|
||||
|
||||
Git repositories are cached here. This avoids wasting bandwidth, when downloading
|
||||
multiple repositories. **Git submodules are also cached here!**
|
||||
|
||||
ec/
|
||||
---------------
|
||||
|
|
@ -148,21 +205,30 @@ elf/
|
|||
---------------
|
||||
|
||||
**DO NOT flash coreboot ROM images contained under `elf/`. Please use ROM images
|
||||
under `bin/` instead!**
|
||||
under `bin/` instead! - In modern lbmk, only the ones under `bin/` are ever
|
||||
created anyway.**
|
||||
|
||||
Compiled binaries (compiled by lbmk) go here, but they are not the final
|
||||
binaries; coreboot ROM images are compiled without payloads, then cached here
|
||||
under `elf/coreboot` as one example; ditto GRUB and SeaBIOS which go
|
||||
under `elf/grub` and `elf/seabios` respectively - `elf/u-boot` is another
|
||||
example.
|
||||
under `elf/coreboot` as one example
|
||||
|
||||
Binaries under `elf/` are compiled first, which lbmk then uses to generate
|
||||
the files under `bin/`; the latter files under `bin/` are intended for
|
||||
installation by the user.
|
||||
GRUB and SeaBIOS which go
|
||||
under `elf/grub` and `elf/seabios` respectively - `elf/u-boot` is another
|
||||
example. A given project can include a `build.list` file
|
||||
at `config/data/PROJECT/build.list`, which would contain a list of file paths
|
||||
relative to the *source directory*; these files would be copied, after a build
|
||||
operation, to `elf/PROJECT` for single-tree projects,
|
||||
or `elf/PROJECT/TREE` for multi-tree projects.
|
||||
|
||||
It is technically possible to re-use these files elsewhere. For example, you
|
||||
may wish to only compile GRUB with lbmk, and then use the `grub.elf` file from
|
||||
lbmk in your own custom coreboot ROM (that you didn't build with lbmk).
|
||||
lbmk in your own custom coreboot ROM (that you didn't build with lbmk). However,
|
||||
this use is not officially supported by the Libreboot project; these files are
|
||||
simply used by the Libreboot build system.
|
||||
|
||||
Some utilities are also provided compiled here, when building. For
|
||||
example: `elf/flashprog/flashprog`. This is because lbmk tries to provide
|
||||
out-of-source builds whenever feasible.
|
||||
|
||||
This is only used by the build system, but these images are *not* provided in
|
||||
releases (only the images under `bin/` are provided).
|
||||
|
|
@ -176,6 +242,9 @@ mrc/
|
|||
|
||||
Intel System Agent downloaded at build time for HP EliteBook 820 G2.
|
||||
|
||||
The *Haswell* MRC file is no longer downloaded here, because Haswell machines
|
||||
now use native raminit *exclusively*; only Broadwell uses MRC, at present.
|
||||
|
||||
pciroms/
|
||||
---------------
|
||||
|
||||
|
|
@ -198,20 +267,20 @@ the user.
|
|||
|
||||
You can create release archives by doing:
|
||||
|
||||
./update release
|
||||
./mk release
|
||||
|
||||
By default, this creates a release under `release/`, but you can change the
|
||||
directory, for example:
|
||||
|
||||
./update release -d path
|
||||
./mk release -d path
|
||||
|
||||
You can also specify that only a *source archive* be created, like so:
|
||||
|
||||
./update release -m src
|
||||
./mk release -m src
|
||||
|
||||
Or with a custom directory:
|
||||
|
||||
./update release -d path -m src
|
||||
./mk release -d path -m src
|
||||
|
||||
The build system expects there to be a *git tag*, so make sure there is one.
|
||||
This is used to create the version number for a given release.
|
||||
|
|
@ -270,7 +339,7 @@ convenience of users, and this is copied to release archives. Flashrom is the
|
|||
program that you will use to read, erase and write the flash, containing
|
||||
coreboot firmware.
|
||||
|
||||
src/grub/
|
||||
src/grub/TREE
|
||||
---------------
|
||||
|
||||
Please also visit: <https://www.gnu.org/software/grub/>
|
||||
|
|
@ -286,7 +355,23 @@ the `grub-mkstandalone` utility is executed from here to create the final
|
|||
GRUB image under `elf/grub/`.
|
||||
|
||||
NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
|
||||
U-Boot instead.
|
||||
U-Boot instead. Since Libreboot 20240612, the GRUB builds are *multi-tree*,
|
||||
much like, say, coreboot or SeaBIOS.
|
||||
|
||||
As of August 2024, the following GRUB source trees can be downloaded:
|
||||
|
||||
* `src/grub/default`
|
||||
* `src/grub/xhci`
|
||||
* `src/grub/nvme`
|
||||
|
||||
Simplify specify the tree. For example:
|
||||
|
||||
./mk -b grub xhci
|
||||
|
||||
The `xhci` tree contains patches for both NVMe SSD support, and xHCI. The `nvme`
|
||||
tree contains NVMe SSD support but not xHCI support. The `default` tree contains
|
||||
no NVMe or xHCI support. All trees otherwise have the same fixes on top of
|
||||
upstream GRUB, e.g. fix for Dell Latitude keyboard controllers.
|
||||
|
||||
src/memtest86plus/
|
||||
---------------
|
||||
|
|
@ -498,8 +583,6 @@ other example. Deletions occur when the source tree is created.
|
|||
config/vendor/
|
||||
---------------
|
||||
|
||||
### config/vendor/sources
|
||||
|
||||
URLs and hashes for vendor files containing Intel ME images within them. Where
|
||||
feasible, backup URLs are also provided. SHA512 checksums are defined, so that
|
||||
lbmk can verify the integrity of downloaded files.
|
||||
|
|
@ -517,25 +600,6 @@ E6400.
|
|||
config/coreboot
|
||||
---------------
|
||||
|
||||
### config/coreboot/build.list
|
||||
|
||||
When a given coreboot tree is compiled, for a given target, this file defines
|
||||
which files to copy from the coreboot directory, which are then copied to
|
||||
a location under `elf/coreboot`.
|
||||
|
||||
The presence of this file affects behaviour in `./update release` commands;
|
||||
specifically, PROJECT is then downloaded to `src/PROJECT/PROJECT`, and files
|
||||
under `config/PROJECT/TARGET/target.cfg` define which tree to use, which then
|
||||
looks under `config/PROJECT/TREE/target.cfg` to get the git revision; then
|
||||
the src directory `src/PROJECT/TREE` is created, copied
|
||||
from `src/PROJECT/PROJECT`.
|
||||
|
||||
For example, coreboot target `x200_8mb` refers to tree name `default` which
|
||||
would create `src/coreboot/default`.
|
||||
|
||||
If the `build.list` file is *not* included, then the git revision
|
||||
under `config/git` is used, and only `src/PROJECT` is created.
|
||||
|
||||
### config/coreboot/BOARDNAME/
|
||||
|
||||
Each target name (e.g. `x200_8mb`) has its own directory under here. Targets
|
||||
|
|
@ -567,12 +631,9 @@ as:
|
|||
* `rev="ad983eeec76ecdb2aff4fb47baeee95ade012225"` (example entry)
|
||||
* `xarch="i386-elf"` (example entry)
|
||||
* `payload_grub="y"` (example entry)
|
||||
* `payload_grub_withseabios="y"` (example entry)
|
||||
* `payload_seabios="y"` (example entry)
|
||||
* `payload_memtest="y"` (example entry)
|
||||
* `payload_uboot="y"` (example entry)
|
||||
* `payload_seabios_withgrub="y"` (example entry)
|
||||
* `payload_seabios_grubonly="y"` (example entry)
|
||||
* `grub_scan_disk="ata"`
|
||||
* `uboot_config=default` (specify which U-Boot tree to use)
|
||||
* `release="n"` (example entry)
|
||||
|
|
@ -630,7 +691,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 `release` variable can be set to n, which makes the `./update release`
|
||||
The `release` variable can be set to n, which makes the `./mk release`
|
||||
call skip that target, when creating release images. For example, a given
|
||||
board may not be stable and you don't want images for it to be included in the
|
||||
release.
|
||||
|
|
@ -708,7 +769,7 @@ VESA frame buffer (NOT to be confused with the coreboot frame buffer), or just
|
|||
normal text mode. Text mode startup is always recommended, and in that setup,
|
||||
GRUB (including coreboot GRUB, but also PC GRUB) can use VGA modes.
|
||||
|
||||
The name `libgfxinit` is simply what `./build roms` uses, but it may be
|
||||
The name `libgfxinit` is simply what `./mk -b coreboot` uses, but it may be
|
||||
that a board uses the old-school native video init code written in C. On some
|
||||
platforms, coreboot implemented a 3rd party library called `libgfxinit`, which
|
||||
is written in Ada and handles video initialization. In this setup, coreboot
|
||||
|
|
@ -729,7 +790,7 @@ config/dependencies/
|
|||
Files here are so named, and called like so: e.g. the `debian` file would be
|
||||
referenced when running:
|
||||
|
||||
./build dependencies debian
|
||||
./mk dependencies debian
|
||||
|
||||
These files define a list of packages, and the correct package manager command
|
||||
to use on a given distro. This can be used to install build dependencies, which
|
||||
|
|
@ -940,7 +1001,7 @@ These are similar in meaning to their coreboot counterparts.
|
|||
The tree` entry is actually a link, where its value is a directory name
|
||||
under `config/u-boot`. For example, `tree="default"` would refer to
|
||||
`config/u-boot/default` and the corresponding U-Boot source tree created
|
||||
(when running `./update trees u-boot`, which makes use of `target.cfg`)
|
||||
(when running `./mk u-boot`, which makes use of `target.cfg`)
|
||||
would be `u-boot/default/`. In other words: a `target.cfg` file
|
||||
in `config/u-boot/foo` might refer to `config/u-boot/bar` by
|
||||
specifying `tree="bar"`, and the created u-boot source tree would
|
||||
|
|
@ -1054,7 +1115,7 @@ You create a config, for `config/u-boot/TREENAME/configs`, by finding the
|
|||
corresponding board name in the upstream U-Boot `configs` directory, and
|
||||
running `make BOARDNAME_defconfig` and `make menuconfig` commands in the
|
||||
*U-Boot* build system. You should do this after
|
||||
running `./update trees u-boot` in lbmk.
|
||||
running `./mk u-boot` in lbmk.
|
||||
|
||||
You might want to consider basing your config on the upstream `coreboot` boards
|
||||
when possible, but such a board is not available upstream for ARM yet.
|
||||
|
|
@ -1114,27 +1175,27 @@ Take any given file under `script/` and you can do:
|
|||
|
||||
For example:
|
||||
|
||||
./build roms
|
||||
./update trees
|
||||
./mk -b coreboot
|
||||
./mk
|
||||
|
||||
Special commands available (not provided by files under `script/`):
|
||||
|
||||
./update release
|
||||
./vendor download
|
||||
./vendor inject
|
||||
./mk release
|
||||
./mk download
|
||||
./mk inject
|
||||
|
||||
The `vendor` commands are handled by the `build` script, calling functions
|
||||
inside `include/vendor.sh`, and the `./update release` logic is handled
|
||||
inside `include/vendor.sh`, and the `./mk release` logic is handled
|
||||
directly by the `build` script.
|
||||
|
||||
More information about `./vendor` commands can be found
|
||||
here: [inserting vendor files](../install/ivy_has_internal.md)
|
||||
|
||||
Information about `./update release` is written elsewhere on this page.
|
||||
Information about `./mk release` is written elsewhere on this page.
|
||||
|
||||
You can also know what build system revision you have by running:
|
||||
|
||||
./build version
|
||||
./mk version
|
||||
|
||||
This script is the beating heart of Libreboot. Break it and you break Libreboot.
|
||||
|
||||
|
|
@ -1150,7 +1211,7 @@ include/git.sh
|
|||
|
||||
These functions in here previously existed as independent scripts, but they
|
||||
were unified here, and they are used when you pass the `-f` argument
|
||||
to `script/update/trees` (e.g. `./update trees -f coreboot`).
|
||||
to `script/update/trees` (e.g. `./mk -f coreboot`).
|
||||
|
||||
These functions deal with git cloning, submodule updates, revision resets and
|
||||
the application of patch files via `git am`. *Every* git repository downloaded
|
||||
|
|
@ -1199,20 +1260,20 @@ script/roms
|
|||
|
||||
This builds coreboot ROM images.
|
||||
|
||||
Command: `./build roms targetname`
|
||||
Command: `./mk -b coreboot targetname`
|
||||
|
||||
The `targetname` argument must be specified, chosen from this output:
|
||||
|
||||
./build roms list
|
||||
./mk -b coreboot list
|
||||
|
||||
Pass several board names if you wish to build only for specific targets. For
|
||||
example:
|
||||
|
||||
./build roms x60 x200_8mb
|
||||
./mk -b coreboot x60 x200_8mb
|
||||
|
||||
To build *all* targets, specify:
|
||||
|
||||
./build roms all
|
||||
./mk -b coreboot
|
||||
|
||||
Since November 2022, this script can build images for x86 *and* ARM targets.
|
||||
The *ARM* targets are ChromeOS devices (chromebooks and such); Libreboot uses
|
||||
|
|
@ -1321,17 +1382,17 @@ the directory `src/PROJECT/TREE` will be created, reset to the specific
|
|||
revision - for multi-tree projects, all defined targets are scanned for their
|
||||
corresponding tree, and the trees are prepared as defined above.
|
||||
|
||||
Basic command: `./update trees FLAG projectname`
|
||||
Basic command: `./mk FLAG projectname`
|
||||
|
||||
Special operation: for building coreboot utilities `cbfstool` and `ifdtool` to
|
||||
go under `cbutils/`, do this:
|
||||
|
||||
./update trees -d coreboot TREENAME
|
||||
./mk -d coreboot TREENAME
|
||||
|
||||
Or define specific coreboot tree such as:
|
||||
|
||||
./update trees -d coreboot default
|
||||
./update trees -d coreboot cros
|
||||
./mk -d coreboot default
|
||||
./mk -d coreboot cros
|
||||
|
||||
FLAG values are (only *one* to be used at a time):
|
||||
|
||||
|
|
@ -1358,15 +1419,15 @@ As for *projectname", this can either be `coreboot`, `u-boot` or `seabios`.
|
|||
|
||||
Example commands:
|
||||
|
||||
./update trees -b coreboot
|
||||
./update trees -b coreboot x200_8mb
|
||||
./update trees -b coreboot x230_12mb x220_8mb t1650_12mb
|
||||
./update trees -x coreboot default
|
||||
./update trees -u seabios
|
||||
./update trees -m u-boot gru_bob
|
||||
./update trees -f coreboot
|
||||
./update trees -d coreboot default
|
||||
./update trees -d coreboot
|
||||
./mk -b coreboot
|
||||
./mk -b coreboot x200_8mb
|
||||
./mk -b coreboot x230_12mb x220_8mb t1650_12mb
|
||||
./mk -x coreboot default
|
||||
./mk -u seabios
|
||||
./mk -m u-boot gru_bob
|
||||
./mk -f coreboot
|
||||
./mk -d coreboot default
|
||||
./mk -d coreboot
|
||||
|
||||
NOTE: the `-x` and `-c` options will cause an exit with zero status, when
|
||||
the target's corresponding source tree is unavailable; a non-zero status is
|
||||
|
|
@ -1376,11 +1437,11 @@ if unavailable and *that* too will return with non-zero status under fault
|
|||
conditions.
|
||||
|
||||
NOTE: "target" can indeed be the tree name, under some circumstances. For
|
||||
example, `./update trees -m seabios default`
|
||||
example, `./mk -m seabios default`
|
||||
|
||||
After `projectname`, a target can be specified, but if no target is specified,
|
||||
then *all* targets will be operated on. For
|
||||
example, `./update trees -b coreboot` will attempt to build *all*
|
||||
example, `./mk -b coreboot` will attempt to build *all*
|
||||
coreboot ROM images.
|
||||
|
||||
NOTE: the `coreboot` projectname here shall cause the ROM images to go
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ historically been at odds with the FSF both socially, technically and
|
|||
politically. The restored version is essentially identical, but has been
|
||||
edited without altering any of the substance, and further information going
|
||||
up to the month of August 2024 has been added at the end, which was not
|
||||
available earlier on because... Libreboot not not yet invented time travel.**
|
||||
available earlier on because... Libreboot has not yet invented time travel.**
|
||||
|
||||
Anyway, article time:
|
||||
|
||||
|
|
@ -1349,12 +1349,11 @@ They did rename, to GNU Boot, but only after I forced them to do so. I forced
|
|||
them to do so, by exposing the moral bankrupcy on their part, in their initial
|
||||
effort to steal the Libreboot name.
|
||||
|
||||
The points raised in the GNU Boot article are *still valid* on today, 12
|
||||
December 2023. GNU Boot 0.1 RC3 is imminent for release, on this day, and it
|
||||
is still based largely on Libreboot 20220710, with only superficial changes on
|
||||
On this day, GNU Boot 0.1 RC3 was imminent for release, on this day, and it
|
||||
was still based largely on Libreboot 20220710, with only superficial changes on
|
||||
top of it. it still has all the old, obsolete revisions for all projects,
|
||||
including coreboot. It still has all of the same bugs, that Libreboot has since
|
||||
fixed, especially during 2023.
|
||||
fixed, especially during 2023. Libreboot is *vastly* superior, in every way.
|
||||
|
||||
Unlike with their first attempt, GNU Boot is fully hosted on the GNU Savannah
|
||||
infrastructure, as any proper GNU project should be. I *respect* the GNU Boot
|
||||
|
|
|
|||
Loading…
Reference in New Issue