snip

Signed-off-by: Leah Rowe <info@minifree.org>

site/docs/build/index.md

@@ -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`
+example, `./mk -b coreboot` will automatically build the required payloads
-if the required GRUB payload (under `elf/grub/`) does not exist.
+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!

site/docs/build/index.uk.md

@@ -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
 
 Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
 окремі частини системи побудови власноруч, якщо виберете. Це може бути

site/docs/grub/index.md

@@ -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

site/docs/hardware/dell9020.md

@@ -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.

site/docs/hardware/hp2170p.md

@@ -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
 ============

site/docs/hardware/hp2560p.md

@@ -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/).

site/docs/hardware/hp2570p.md

@@ -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/).

site/docs/hardware/hp8200sff.md

@@ -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/).

site/docs/hardware/hp820g2.md

@@ -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.

site/docs/hardware/hp8460p.md

@@ -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
 ============

site/docs/hardware/hp8470p.md

@@ -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
 ============

site/docs/hardware/hp8560w.md

@@ -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
 ============

site/docs/hardware/hp9470m.md

@@ -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).

site/docs/hardware/t1650.md

@@ -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
 ============

site/docs/install/ivy_has_common.md

@@ -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:

site/docs/install/ivy_has_common.uk.md

@@ -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.
 

site/docs/install/spi.md

@@ -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
+	./mk -b pico-serprog
-
-or for the W version:
-
-	./build serprog rp2040 pico_w
 
 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
+at `bin/serprog_rp2040/serprog_pico.uf2`
-pre-compiled in the next Libreboot release, after the 20230625 release.
+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

site/docs/install/spi.zh-cn.md

@@ -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
+	./mk -b pico-serprog
-
-or for the W version:
-
-	./build serprog rp2040 pico_w
 
 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
+at `bin/serprog_rp2040/serprog_pico.uf2`
-pre-compiled in the next Libreboot release, after the 20230625 release.
+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 发行版应该也能用。
 

site/docs/linux/grub_cbfs.md

@@ -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.

site/docs/linux/grub_hardening.md

@@ -83,16 +83,12 @@ image:
 
 You can build `cbfstool` in the libreboot build system. Run this command:
 
-	./update trees -d coreboot TREENAME
+	./mk -d coreboot TREENAME
-
-This assumes that you already downloaded coreboot:
-
-	./update trees -f coreboot
 
 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 `src/grub/default/`:
-
-The following executable will then be available under the `src/grub/` directory:
 
 	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
 ========
 

site/docs/maintain/index.md

@@ -126,17 +126,74 @@ bin/
 This directory is created when running any of the following commands, with the
 right arguments:
 
-	./build roms ARGUMENTS_HERE
+	./mk -b coreboot ARGUMENTS_HERE
-	./build roms serprog stm32
+	./mk -b stm32-vserprog
-	./build roms serprog rp2040
+	./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
+**These** are the ROM images that you should flash.
-images contained under `elf/`!
+
+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/coreboot` as one example
-under `elf/grub` and `elf/seabios` respectively - `elf/u-boot` is another
-example.
 
-Binaries under `elf/` are compiled first, which lbmk then uses to generate
+GRUB and SeaBIOS which go
-the files under `bin/`; the latter files under `bin/` are intended for
+under `elf/grub` and `elf/seabios` respectively - `elf/u-boot` is another
-installation by the user.
+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
+	./mk -b coreboot
-	./update trees
+	./mk
 
 Special commands available (not provided by files under `script/`):
 
-	./update release
+	./mk release
-	./vendor download
+	./mk download
-	./vendor inject
+	./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
+	./mk -d coreboot default
-	./update trees -d coreboot cros
+	./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
+	./mk -b coreboot
-	./update trees -b coreboot x200_8mb
+	./mk -b coreboot x200_8mb
-	./update trees -b coreboot x230_12mb x220_8mb t1650_12mb
+	./mk -b coreboot x230_12mb x220_8mb t1650_12mb
-	./update trees -x coreboot default
+	./mk -x coreboot default
-	./update trees -u seabios
+	./mk -u seabios
-	./update trees -m u-boot gru_bob
+	./mk -m u-boot gru_bob
-	./update trees -f coreboot
+	./mk -f coreboot
-	./update trees -d coreboot default
+	./mk -d coreboot default
-	./update trees -d coreboot
+	./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

site/news/10.md

@@ -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
+On this day, GNU Boot 0.1 RC3 was imminent for release, on this day, and it
-December 2023. GNU Boot 0.1 RC3 is imminent for release, on this day, and it
+was still based largely on Libreboot 20220710, with only superficial changes on
-is 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