update docs/maintain/ based on lbmk changes
Signed-off-by: Leah Rowe <info@minifree.org>master
Leah Rowe
parent
b716e3fedd
commit
dc7d5cef90
|
|
@ -25,6 +25,14 @@ 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/)
|
||||
|
||||
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).
|
||||
|
||||
Sources
|
||||
=======
|
||||
|
||||
|
|
|
|||
|
|
@ -35,6 +35,14 @@ libreboot з доступного джерельного коду.
|
|||
Наступний документ описує те, як працює `lbmk`, і як ви можете робити зміни
|
||||
до нього: [керівництво обслуговування libreboot](../maintain/)
|
||||
|
||||
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).
|
||||
|
||||
Git
|
||||
===
|
||||
|
||||
|
|
|
|||
|
|
@ -85,6 +85,43 @@ the [freedom status page](../../freedom-status.md).
|
|||
Before *configuration* info, you will first be shown a brief overview of every
|
||||
project that Libreboot imports, such as coreboot.
|
||||
|
||||
Environmental variables
|
||||
=======================
|
||||
|
||||
LBMK\_THREADS
|
||||
-------------
|
||||
|
||||
For example:
|
||||
|
||||
export LBMK_THREADS=2
|
||||
|
||||
This would build on two threads, when running lbmk. It defaults to 1.
|
||||
|
||||
Previous revisions of lbmk used `nproc` by default, but this was set to 1
|
||||
instead, because nproc is not available on every operating system.
|
||||
|
||||
LBMK\_STATUS
|
||||
------------
|
||||
|
||||
By default, the user is asked to confirm when building for a given mainboard,
|
||||
if that mainboard is not marked *stable* in `target.cfg`. To disable such
|
||||
dialogs, do this:
|
||||
|
||||
export LBMK_STATUS=n
|
||||
|
||||
LBMK\_RELEASE
|
||||
-------------
|
||||
|
||||
If set to `y`, it signals to `script/build/roms` that a release is being built,
|
||||
and it will honour `release="n"` in target.cfg files. You could also set this
|
||||
yourself, when doing regular builds, if you wanted to test how `./build roms`
|
||||
behaves running it in release mode. Do this if you want to:
|
||||
|
||||
export LBMK_RELEASE=y
|
||||
|
||||
This has a similar effect compared to `LBMK_STATUS="y"` but you probably don't
|
||||
need to use this option yourself.
|
||||
|
||||
Projects/files downloaded/generated by lbmk
|
||||
===========================================
|
||||
|
||||
|
|
@ -530,9 +567,8 @@ This file can contain several configuration lines, each being a string, such
|
|||
as:
|
||||
|
||||
* `tree="default"` (example entry)
|
||||
* `romtype="normal"` (example entry)
|
||||
* `rev="ad983eeec76ecdb2aff4fb47baeee95ade012225"` (example entry)
|
||||
* `arch="x86_64"` (example entry)
|
||||
* `xarch="i386-elf"` (example entry)
|
||||
* `payload_grub="y"` (example entry)
|
||||
* `payload_grub_withseabios="y"` (example entry)
|
||||
* `payload_seabios="y"` (example entry)
|
||||
|
|
@ -542,26 +578,21 @@ as:
|
|||
* `payload_seabios_grubonly="y"` (example entry)
|
||||
* `grub_scan_disk="ata"`
|
||||
* `uboot_config=default` (specify which U-Boot tree to use)
|
||||
* `vendorfiles="n"`
|
||||
* `microcode_required="y"`
|
||||
* `release="n"` (example entry)
|
||||
* `status=stable`
|
||||
|
||||
The `tree` value refers to `config/coreboot/TREE`; in other words, a given
|
||||
target could specify a name other than its own as the tree; it would then
|
||||
re-use code from that tree, rather than providing its own.
|
||||
|
||||
The `romtype` entry is used during the building of ROM images, to define
|
||||
special steps; for example, d8d16sas` would tell lbmk that a fake PIKE2008
|
||||
ROM must be inserted into CBFS (prevents hanging on SeaBIOS).
|
||||
|
||||
The `rev` entry defines which coreboot revision to use, from the
|
||||
coreboot Git repository. *At present, lbmk only supports use of the official
|
||||
repository from the upstream coreboot project*.
|
||||
|
||||
The `arch` entry specifies which CPU architecture is to be used: currently
|
||||
recognized entries are `x86_32`, `x86_64`, `ARMv7` and `AArch64`. *Setting it
|
||||
to a non-native arch means that necessary crossgcc-arch will be compiled and be
|
||||
available when building roms, but not necessarily built or discovered when
|
||||
individual scripts are called manually.*
|
||||
The `xarch` entry specifies which CPU architecture is to be used: currently
|
||||
recognized entries are `i386-elf`, `arm-eabi` and `aarch64-elf`. This is the
|
||||
target architecture for building GCC/toolchain from coreboot crossgcc,
|
||||
hence `xarch`.
|
||||
|
||||
The `payload_grub` entry specifies whether or not GRUB is to be included in
|
||||
ROM images.
|
||||
|
|
@ -600,12 +631,25 @@ 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 `vendorfiles` entry doesn't affect anything in code, except that
|
||||
the `noblobs` string will be appended to ROM image file names, on releases;
|
||||
ditto `nomicrocode` but in that case, the behaviour is: if no microcode to
|
||||
begin with, only `nomicrocode` images will be named, otherwise ROM images with
|
||||
and without microcode updates will be provided in releases (CPU microcode
|
||||
updates).
|
||||
The `release` variable can be set to n, which makes the `script/update/release`
|
||||
script 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.
|
||||
|
||||
The `status` variable can be set to whatever you want, but anything other
|
||||
than `stable` will make `script/build/roms` ask for y/n confirmation if
|
||||
not building images using `script/update/release`.
|
||||
|
||||
Recommended strings for `status` could be: `stable`, `unstable`, `broken`
|
||||
or `untested`. Alternatively, you might state `wip`. You can set whatever
|
||||
string you want here.
|
||||
|
||||
### config/coreboot/BOARDNAME/warn.txt
|
||||
|
||||
Additionally: the `warn.txt` file can be included alongside target.cfg, to
|
||||
provide warning of any potential issues or quirks. For example, raminit may
|
||||
only be reliable with certain modules. This is printed on the user's terminal
|
||||
when building that target.
|
||||
|
||||
### config/coreboot/BOARDNAME/config/
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue