snip

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

site/docs/build/index.md

@@ -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`
+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
@@ -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!

site/docs/build/index.uk.md

@@ -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`, і цей
+Please read about environmental variables in [the build
-документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
+instructions](../maintain/), before running lbmk. You should set
-canoeboot з доступного джерельного коду.
+your variables accordingly, though you do not technically need to; some
-Ця версія, якщо розміщена наживо на canoeboot.org, передбачає, що ви використовуєте
+of them may be useful, e.g. `XBMK_THREADS` (sets the number of build threads).
-сховище git `cbmk`, яке
-ви можете завантажити, використовуючи інструкції на [сторінці огляду коду](../../git.uk.md).
-
-Якщо ви використовуєте архів випуску canoeboot, будь ласка, зверніться до
-документації, включеної до *того* випуску. Випуски canoeboot розраховані тільки,
-як *знімки*, не для розробки. Для належної розробки ви маєте завжди
-працювати безпосередньо в сховищі git canoeboot.
-
-Наступний документ описує те, як працює `cbmk`, і як ви можете робити зміни
-до нього: [керівництво обслуговування canoeboot](../maintain/)
 
 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
 
 Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
 окремі частини системи побудови власноруч, якщо виберете. Це може бути

site/docs/gnulinux/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 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.

site/docs/gnulinux/grub_hardening.md

@@ -78,16 +78,12 @@ image:
 
 You can build `cbfstool` in the Canoeboot 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
 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 `src/grub/default/`:
-
-The following executable will then be available under the `src/grub/` directory:
 
 	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
 ========
 

site/docs/grub/index.md

@@ -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
+GRUB already has excellent
-date.
-
-GNU 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

site/docs/install/spi.md

@@ -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
+	./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 is provided
+at `bin/serprog_rp2040/serprog_pico.uf2`
-pre-compiled in Canoeboot 20231026 and newer releases.
+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

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

@@ -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
+	./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`. Canoeboot provides these builds
+at `bin/serprog_rp2040/serprog_pico.uf2`
-in releases.
+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 发行版应该也能用。
 

site/docs/maintain/index.md

@@ -108,37 +108,103 @@ 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 Canoeboot 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!**
 
 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/coreboot` as one example
-under `elf/grub` and `elf/seabios` respectively - `elf/u-boot` is another
-example.
 
-Binaries under `elf/` are compiled first, which cbmk 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 cbmk, and then use the `grub.elf` file from
+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 cbmk).
+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
+NOTE: This is *only* provided for x86 machines, in Libreboot. For ARM, we ship
-U-Boot instead.
+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
+	./mk -b coreboot
-	./update trees
+	./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
+	./mk -d coreboot default
-	./update trees -d coreboot cros
+	./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
+	./mk -b coreboot
-	./update trees -b coreboot x200_8mb t60_intelgpu
+	./mk -b coreboot x200_8mb
-	./update trees -x coreboot default
+	./mk -b coreboot x200_8mb x60
-	./update trees -u seabios
+	./mk -x coreboot default
-	./update trees -m u-boot gru_bob
+	./mk -u seabios
-	./update trees -f coreboot
+	./mk -m u-boot gru_bob
-	./update trees -d coreboot default
+	./mk -f coreboot
-	./update trees -d 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