Leah Rowe
parent
cc843552df
commit
ee575a619b
|
|
@ -131,12 +131,24 @@ according to the selected GNU+Linux distro.
|
|||
|
||||
For example:
|
||||
|
||||
./build dependencies debian
|
||||
./mk dependencies ubuntu
|
||||
|
||||
or
|
||||
|
||||
./mk dependencies debian
|
||||
|
||||
or
|
||||
|
||||
./mk dependencies fedora38
|
||||
|
||||
or
|
||||
|
||||
./mk dependencies arch
|
||||
|
||||
NOTE: In case of Ubuntu 20.04 LTS or derived distros for that specific release,
|
||||
use the dedicated configuration file (the Trisquel 11 config symlinks to this):
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
Technically, any GNU+Linux distribution can be used to build canoeboot.
|
||||
However, you will have to write your own script for installing build
|
||||
|
|
@ -146,32 +158,32 @@ Next, build ROM images
|
|||
----------------------
|
||||
|
||||
Canoeboot MaKe (cbmk) 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
|
||||
|
|
@ -184,7 +196,7 @@ Want to modify Canoeboot?
|
|||
Check the [cbmk 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
|
||||
Canoeboot build system (cbmk) works!
|
||||
|
|
|
|||
|
|
@ -17,6 +17,48 @@ images (containing payloads) in `bin/`. This design is more efficient, and
|
|||
permits many configurations without needless duplication of work. More info
|
||||
is available in the [cbmk maintenance manual](../maintain/)**
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Система побудови libreboot, називається `lbmk`, скорочення від `LibreBoot MaKe`, і цей
|
||||
документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
|
||||
libreboot з доступного джерельного коду.
|
||||
Ця версія, якщо розміщена наживо на libreboot.org, передбачає, що ви використовуєте
|
||||
сховище git `lbmk`, яке
|
||||
ви можете завантажити, використовуючи інструкції на [сторінці огляду коду](../../git.uk.md).
|
||||
|
||||
Якщо ви використовуєте архів випуску libreboot, будь ласка, зверніться до
|
||||
документації, включеної до *того* випуску. Випуски libreboot розраховані тільки,
|
||||
як *знімки*, не для розробки. Для належної розробки ви маєте завжди
|
||||
працювати безпосередньо в сховищі git libreboot.
|
||||
|
||||
Наступний документ описує те, як працює `lbmk`, і як ви можете робити зміни
|
||||
до нього: [керівництво обслуговування libreboot](../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 XBMK_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.
|
||||
The setting is decided on a board-by-board basis, taking its various quirks
|
||||
and idiosynrasies into account.
|
||||
>>>>>>> a2164297 (snip)
|
||||
|
||||
Multi-threaded builds
|
||||
=====================
|
||||
|
||||
|
|
@ -42,20 +84,10 @@ of them may be useful, e.g. `XBMK_THREADS` (sets the number of build threads).
|
|||
Introduction
|
||||
============
|
||||
|
||||
Система побудови canoeboot, називається `cbmk`, скорочення від `CanoeBoot MaKe`, і цей
|
||||
документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
|
||||
canoeboot з доступного джерельного коду.
|
||||
Ця версія, якщо розміщена наживо на canoeboot.org, передбачає, що ви використовуєте
|
||||
сховище git `cbmk`, яке
|
||||
ви можете завантажити, використовуючи інструкції на [сторінці огляду коду](../../git.uk.md).
|
||||
|
||||
Якщо ви використовуєте архів випуску canoeboot, будь ласка, зверніться до
|
||||
документації, включеної до *того* випуску. Випуски canoeboot розраховані тільки,
|
||||
як *знімки*, не для розробки. Для належної розробки ви маєте завжди
|
||||
працювати безпосередньо в сховищі git canoeboot.
|
||||
|
||||
Наступний документ описує те, як працює `cbmk`, і як ви можете робити зміни
|
||||
до нього: [керівництво обслуговування canoeboot](../maintain/)
|
||||
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. `XBMK_THREADS` (sets the number of build threads).
|
||||
|
||||
Git
|
||||
===
|
||||
|
|
@ -100,15 +132,15 @@ time or date can cause connections to be dropped during negotiation.
|
|||
canoeboot включає сценарій, який автоматично встановлює 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.
|
||||
|
||||
|
|
@ -123,23 +155,23 @@ Canoeboot Make (cbmk) автоматично виконує всі необхі
|
|||
В якості результату, ви тепер можете (після встановлення правильних залежностей побудови) виконати
|
||||
лише одну команду, з свіжого 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
|
||||
|
||||
Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
|
||||
окремі частини системи побудови власноруч, якщо виберете. Це може бути
|
||||
|
|
|
|||
|
|
@ -59,15 +59,15 @@ Install the build dependencies. For Ubuntu 20.04 and similar, you can run
|
|||
the following command in the Canoeboot build system, from the root directory
|
||||
of the Canoeboot Git repository.
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
Then, download coreboot:
|
||||
|
||||
./update trees -f coreboot
|
||||
./mk -f coreboot
|
||||
|
||||
Finally, compile the `cbutils` module:
|
||||
|
||||
./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 canoeboot recommends for reading
|
|||
from and/or writing to the boot flash. In the canoeboot 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 canoeboot'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.
|
||||
|
|
|
|||
|
|
@ -78,16 +78,12 @@ image:
|
|||
|
||||
You can build `cbfstool` in the Canoeboot 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
|
||||
Canoeboot. 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
|
||||
|
|
@ -154,11 +150,9 @@ GRUB using the Canoeboot build system. Run the following commands (assuming
|
|||
you have the correct build dependencies installed) to build GRUB, from the
|
||||
Canoeboot 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
|
||||
|
||||
|
|
@ -243,26 +237,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.
|
||||
|
||||
You can still use an override grub config in CBFS, as of Canoeboot 20240612.
|
||||
|
||||
Alternative: GRUB as primary
|
||||
----------------------------
|
||||
|
||||
The *SeaBIOS first* policy is now law, in Canoeboot 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 Canoeboot, 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
|
||||
========
|
||||
|
||||
|
|
|
|||
|
|
@ -3,10 +3,7 @@ title: GRUB payload
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
TODO: this guide should be reviewed and updated. Some info might be out of
|
||||
date.
|
||||
|
||||
GNU GRUB already has excellent
|
||||
GRUB already has excellent
|
||||
documentation, but there are aspects of Canoeboot that deserve special
|
||||
treatment. Canoeboot provides the option to boot GRUB directly, running on
|
||||
bare metal (instead of using BIOS or UEFI services).
|
||||
|
|
@ -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/)
|
||||
|
||||
When you've built GRUB, using `cbmk` (Canoeboot build system), take your kepmap
|
||||
To 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 `cbmk` (canoeboot build system), take your kepmap
|
||||
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
|
||||
|
||||
cat frazerty | ./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 cbmk. When
|
||||
you build Canoeboot, a ROM image with GRUB payload and your newly created
|
||||
|
|
|
|||
|
|
@ -72,15 +72,11 @@ could build it yourself or you could also clone `cbmk.git` and [install build
|
|||
dependencies](..//build/#first-install-build-dependencies), then inside cbmk,
|
||||
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 is provided
|
||||
pre-compiled in Canoeboot 20231026 and newer releases.
|
||||
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).
|
||||
|
|
@ -459,12 +455,12 @@ install flashprog. Do this after downloading the
|
|||
[cbmk Git repository](../../git.md):
|
||||
|
||||
cd cbmk
|
||||
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
|
||||
|
|
|
|||
|
|
@ -48,15 +48,11 @@ could build it yourself or you could also clone `cbmk.git` and [install build
|
|||
dependencies](..//build/#first-install-build-dependencies), then inside cbmk,
|
||||
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`. Canoeboot provides these builds
|
||||
in releases.
|
||||
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).
|
||||
|
|
@ -312,11 +308,11 @@ Flashrom 是用来读出、擦除、重写 NOR flash 内容的软件。
|
|||
使用 Git 仓库中的 canoeboot 构建系统，你可以下载并安装 flashprog。首先下载 [cbmk Git 仓库](https://codeberg.org/canoeboot/cbmk)，然后执行：
|
||||
|
||||
cd cbmk
|
||||
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 发行版应该也能用。
|
||||
|
||||
|
|
|
|||
|
|
@ -108,37 +108,103 @@ 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 Canoeboot 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!**
|
||||
|
||||
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 cbmk) 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 cbmk 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 cbmk, and then use the `grub.elf` file from
|
||||
cbmk in your own custom coreboot ROM (that you didn't build with cbmk).
|
||||
may wish to only compile GRUB with lbmk, and then use the `grub.elf` file from
|
||||
cbmk in your own custom coreboot ROM (that you didn't build with lbmk). However,
|
||||
this use is not officially supported by the Canoeboot project; these files are
|
||||
simply used by the Canoeboot 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).
|
||||
|
|
@ -159,20 +225,20 @@ This provides source tarballs, and ROM images.
|
|||
|
||||
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.
|
||||
|
|
@ -212,7 +278,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/>
|
||||
|
|
@ -227,8 +293,24 @@ The *utilities* for GRUB are compiled here, and used from here; specifically,
|
|||
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 Canoeboot. For ARM, we ship
|
||||
U-Boot instead.
|
||||
NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
|
||||
U-Boot instead. Since Canoeboot 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/
|
||||
---------------
|
||||
|
|
@ -401,25 +483,6 @@ other example. Deletions occur when the source tree is created.
|
|||
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
|
||||
|
|
@ -448,12 +511,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)
|
||||
|
|
@ -511,7 +571,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.
|
||||
|
|
@ -589,7 +649,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
|
||||
|
|
@ -610,7 +670,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
|
||||
|
|
@ -813,7 +873,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
|
||||
|
|
@ -927,7 +987,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 cbmk.
|
||||
running `./mk u-boot` in cbmk.
|
||||
|
||||
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.
|
||||
|
|
@ -987,20 +1047,21 @@ 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
|
||||
./mk release
|
||||
./mk download
|
||||
|
||||
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.
|
||||
This script is the beating heart of Canoeboot. Break it and you break Canoeboot.
|
||||
|
||||
include/
|
||||
===============
|
||||
|
|
@ -1014,7 +1075,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
|
||||
|
|
@ -1048,20 +1109,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
|
||||
|
||||
This script can build images for x86 *and* ARM targets.
|
||||
The *ARM* targets are ChromeOS devices (chromebooks and such); Canoeboot uses
|
||||
|
|
@ -1170,17 +1231,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):
|
||||
|
||||
|
|
@ -1207,14 +1268,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 t60_intelgpu
|
||||
./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 x200_8mb x60
|
||||
./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
|
||||
|
|
@ -1224,11 +1286,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
|
||||
|
|
|
|||
Loading…
Reference in New Issue