s/mainboard/motherboard

Signed-off-by: Leah Rowe <leah@libreboot.org>

site/about.md

@@ -11,7 +11,7 @@ Open source BIOS/UEFI firmware
 
 Canoeboot is free/libre boot firmware based on [Libreboot](https://libreboot.org/) (which is in turn
 based on coreboot), replacing proprietary BIOS/UEFI firmware on select x86/ARM
-laptops, desktops and server mainboards. It provides an [automated build
+laptops, desktops and server motherboards. It provides an [automated build
 system](docs/maintain/)
 for [compiling coreboot ROM images](docs/build/), that are [easy to
 install](docs/install/) for non-technical
@@ -110,7 +110,7 @@ Canoeboot is maintained by the same founder, Leah Rowe, who is the founder and
 lead developer of both the Libreboot project *and* the Canoeboot project.
 Maintaining a project like Canoeboot is both challenging and fun; Canoeboot does
 not permit any binary blobs from coreboot, which means that it can only support
-a handful of mainboards from coreboot, and sometimes
+a handful of motherboards from coreboot, and sometimes
 several [mitigations](https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e)
 may be required to stabilise certain functionalities under these conditions.
 

site/docs/install/dell780.md

@@ -80,9 +80,9 @@ Alternatively, you can use release images instead of compiling from source.
 
 ### 100% FREE / OPEN SOURCE!
 
-This mainboard is entirely free software in the main boot flash. It is using
+This motherboard is entirely free software in the main boot flash. It is using
 the Intel X4X / ICH10 platform, same as on the already supported
-Gigabyte GA-G41M-ES2L mainboard.
+Gigabyte GA-G41M-ES2L motherboard.
 
 Install Canoeboot
 -----------------

site/docs/install/index.md

@@ -148,7 +148,7 @@ example, they might fix power issues that could then enhance battery life.
 See: <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
 
 Otherwise, check the Lenovo website to find the update utility for your
-mainboard.
+motherboard.
 
 ### Other
 
@@ -204,7 +204,7 @@ flash internally. If that is the case, you must [flash externally](spi.md).
 
 ### Updating an existing installation
 
-Unless otherwise stated, in sections pertaining to each mainboard below,
+Unless otherwise stated, in sections pertaining to each motherboard below,
 an existing Canoeboot installation can be updated via internal flashing,
 without any special steps; simply follow the general internal flashing
 guide, in the final section further down this page.
@@ -216,7 +216,7 @@ If you currently have the factory firmware, you probably need to flash
 externally; on *some* machines, internal flashing is possible, usually with
 special steps required that differ from updating an existing installation.
 
-The next sections will pertain to specific mainboards, where indicated,
+The next sections will pertain to specific motherboards, where indicated,
 followed by general internal flashing instructions where applicable.
 
 ### Dell Latitude laptops (vendor BIOS)
@@ -410,7 +410,7 @@ Install via host CPU (internal flashing)
 NOTE: This mainly applies to the x86 machines.
 
 Please check other sections listed above, to see if there is anything
-pertaining to your mainboard. Internal flashing means that you boot Linux or
+pertaining to your motherboard. Internal flashing means that you boot Linux or
 BSD on the target machine, and run `flashprog` there, flashing the machine
 directly.
 

site/docs/install/kcma-d8.md

@@ -116,7 +116,7 @@ Don't use it. It uses proprietary firmware and adds a backdoor (remote
 out-of-band management chip, similar to the [Intel Management
 Engine](../../faq.md#intelme). Fortunately, the firmware is
 unsigned (possible to replace) and physically separate from the
-mainboard since it's on the add-on module, which you don't have to
+motherboard since it's on the add-on module, which you don't have to
 install.
 
 Flash chips {#flashchips}
@@ -143,7 +143,7 @@ Only text-mode is known to work, but linux(kernel) can initialize the
 framebuffer display (if it has KMS - kernel mode setting).
 
 NOTE: This section relates to the onboard ASpeed GPU. You *can* use an add-on
-PCI-E GPU in one of the available slots on the mainboard. Nvidia GTX 780 cards
+PCI-E GPU in one of the available slots on the motherboard. Nvidia GTX 780 cards
 are what Canoeboot recommends; it has excellent support in Nouveau (free Linux
 kernel / mesa driver for Nvidia cards) and generally works well; however, the
 performance won't be as high in Nouveau, compared to the non-free Nvidia driver

site/docs/install/kgpe-d16.md

@@ -56,7 +56,7 @@ Don't use it. It uses proprietary firmware and adds a backdoor (remote
 out-of-band management chip, similar to the [Intel Management
 Engine](../../faq.md#intelme). Fortunately, the firmware is
 unsigned (possibly to replace) and physically separate from the
-mainboard since it's on the add-on module, which you don't have to
+motherboard since it's on the add-on module, which you don't have to
 install.
 
 Flash chips {#flashchips}

site/docs/install/latitude.md

@@ -26,7 +26,7 @@ Please also [disable /dev/mem protection](devmem.md), otherwise flashprog
 and dell-flash-unlock won't work. You can re-enable the protections after
 flashing.
 
-Please also disable SecureBoot, if you're using a UEFI-based mainboard.
+Please also disable SecureBoot, if you're using a UEFI-based motherboard.
 Note that Canoeboot does not currently implement UEFI on x86 platforms, but
 you can set up [Secure canoeBoot](../linux/grub_hardening.md) after flashing.
 

site/docs/install/nvmutil.md

@@ -70,7 +70,7 @@ handling is provided, later in this document.
 
 The `restore` option restores the original one. The command works by using a
 reference GbE image file present in Canoeboot's build system, for the given
-mainboard.
+motherboard.
 
 The Canoeboot version is designed to throw an error, if you run it on a Libreboot
 tarball.

site/docs/install/spi.md

@@ -82,7 +82,7 @@ SPI flash, using an on-board SPI programmer (which all boards have). You do this
 from Linux, with flashprog.
 
 *This* guide that you're reading now is for using an *external* programmer. It
-is called *external* because it's not the *internal* one on your mainboard.
+is called *external* because it's not the *internal* one on your motherboard.
 
 Raspberry Pi Pico
 -----------------
@@ -234,12 +234,12 @@ build up and possibly fire (and definitely damaged circuitry). On SOIC8, pin 3
 is WP and 4 is GND, so a direct 3.3v connection there is quite hazardous for
 that reason; all the more reason to use a pull-up resistor.**
 
-The mainboard that you want to flash (if using e.g. pomona clip) will probably
+The motherboard that you want to flash (if using e.g. pomona clip) will probably
 have pull-up resistors on it already for WP/HOLD, so simply cutting WP/HOLD
 on the CH341A would also be acceptable. The pull-up resistors that you
 place (in such a mod) on the CH341A are only useful if you also want to flash
 chips in the ZIF socket. If pull-up resistors exist both on e.g. the laptop
-mainboard and on the CH341A, it just means the equivalent series resistance
+motherboard and on the CH341A, it just means the equivalent series resistance
 will be of the two resistors (on each line) in parallel. If we assume that
 a laptop is likely to have a resistor size of ~3.3k for pull-ups, then a value
 of ~5.6k ohms on the CH341A side seems reasonable.
@@ -778,7 +778,7 @@ voltage range is between 2.7V and 3.6V, but 3.3V is the most ideal level).
 
 DO NOT connect more than 1 DC power source to your flash chip either!
 Mixing voltages like that can easily cause damage to your equipment, and to
-your chip/mainboard.
+your chip/motherboard.
 
 ### MISO/MOSI/CS/CLK lines
 
@@ -790,10 +790,10 @@ connected via such resistors, directly to the Southbridge chipset.
 ### ISP programming and VCC diode
 
 ISP means in-system programming. It's when you flash a chip that is already
-mounted to the mainboard of your computer that you wish to install Canoeboot
+mounted to the motherboard of your computer that you wish to install Canoeboot
 on.
 
-It may be beneficial to modify the mainboard so that the SPI flash is powered
+It may be beneficial to modify the motherboard so that the SPI flash is powered
 (on the VCC pin) through a diode, but please note: a diode will cause a voltage
 drop. The tolerated range for a chip expecting 3.3V VCC is usually around 2.7V
 to 3.6V DC, and the drop may cause the voltage to fall outside that. If you do
@@ -813,7 +813,7 @@ other components on that board, which share the same power rail. Further,
 ensure that the pull-up resistors for WP/HOLD are *only* connected to the side
 of the diode that has continuity with the VCC pin (this is important because if
 they're not, they won't be held high while doing ISP flashing, even if they're
-still held high when the mainboard is fully powered on).
+still held high when the motherboard is fully powered on).
 
 Furthermore: ensure that the SPI flash is operating at the appropriate supply
 voltage (2.7V to 3.6V for a 3.3V chip) when fully powered on, after installing
@@ -824,7 +824,7 @@ the SOIC8/WSON8 if it uses that, and replace with an IC socket (for SOIC8,
 WSON8 or DIP8, whatever you want), because then you could easily just insert
 the flash into a breadboard when flashing.
 
-TODO: Make a page on canoeboot.org, showing how to do this on all mainboards
+TODO: Make a page on canoeboot.org, showing how to do this on all motherboards
 supported by canoeboot.
 
 ### GPIO pins on BeagleBone Black (BBB)
@@ -875,7 +875,7 @@ use pull-up resistors on those (see notes below), and decoupling capacitor on
 pin 8 (VCC).
 
 NOTE: On X60/T60 thinkpads, don't connect pin 8. Instead, plug in your the PSU
-to the charging port on your mainboard, but do not power on the mainboard. This
+to the charging port on your motherboard, but do not power on the motherboard. This
 will provide a stable 3.3V voltage, with adequate current levels. On those
 laptops, this is necessary because the flash shares a common 3.3V DC rail with
 many other ICs that all draw quite a lot of current.
@@ -921,10 +921,10 @@ pin 2 (VCC).
 ### Pull-up resistors and decoupling capacitors
 
 **Do this for chips mounted to a breadboard. Ignore this section if you're
-flashing a chip that is already soldered to a mainboard.**
+flashing a chip that is already soldered to a motherboard.**
 
 This section is only relevant if you're flashing a new chip that is not yet
-mounted to a mainboard. You need pull-up resistors on the WP and HOLD pins,
+mounted to a motherboard. You need pull-up resistors on the WP and HOLD pins,
 and decoupling capacitors on the VCC pin. If the chip is already mounted to a
 board, whether soldered or in a socket, these capacitors and resistors will
 probably already exist on the board and you can just flash it without pulling
@@ -941,11 +941,11 @@ The best way is as follows:
 SOIC8/WSON8/DIP8: pin 3 and 7 must be held to a high logic state, which means
 that each pin has its own pull-up resistor to VCC (from the voltage plane that
 pin 8 connects to); anything from 1Kohm to 10Kohm will do. When you're flashing
-a chip that's already on a laptop/desktop/server mainboard, pin 3 and 7 are
+a chip that's already on a laptop/desktop/server motherboard, pin 3 and 7 are
 likely already held high, so you don't need to bother.
 
 SOIC8/WSON8/DIP8: pin 8, which is VCC, will already have decoupling capacitors on it
-if the chip is on a mainboard, but lone chip flashing means that these capacitors
+if the chip is on a motherboard, but lone chip flashing means that these capacitors
 do not exist. A capacitor passes AC but blocks DC. Due to electromagnetic
 indunctance, and RF noise from high-speed switching ICs, a DC voltage line isn't
 actually straight (when viewed on an oscilloscope), but actually has low voltage
@@ -966,11 +966,11 @@ WP/HOLD are not pin 3/7 like above, but instead pins 1 and 9, so wire your
 pull-up resistors on those. VCC on SOIC16 is pin 2, so wire your decoupling
 capacitors up on that.
 
-### SOIC8/WSON8/DIP8/SOIC16 not mounted to a mainboard
+### SOIC8/WSON8/DIP8/SOIC16 not mounted to a motherboard
 
 If your system has lower capacity SPI flash, you can upgrade. On *most* systems,
 SPI flash is memory mapped and the maximum (in practise) that you can use is a
-16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in Canoeboot have
+16MiB chip. For example, KGPE-D16 and KCMA-D8 motherboards in Canoeboot have
 2MiB flash by default, but you can easily upgrade these. Another example is the
 ThinkPad X200S, X200 Tablet and T400S, all of which have WSON8 where the best
 course of action is to replace it with a SOIC8 flash chip.
@@ -1007,7 +1007,7 @@ video, but for WSON8. Sometimes they are called DFN8 or QFN8 sockets. Get one
 that is 1.27mm pitch.
 
 If you're flashing/dumping a lone WSON8, get a WSON8/QFN8/DFN8 socket (1.27mm
-pitch) and mount it to a breadboard for flashing. If your mainboard's landing
+pitch) and mount it to a breadboard for flashing. If your motherboard's landing
 pads for the flash IC can take a SOIC8, we recommend that you use a SOIC8
 instead because a test clip is possible later on when you wish to re-flash it,
 however you may be dealing with a board where replacing existing WSON8 with
@@ -1038,7 +1038,7 @@ and good 60/40 or 63/37 leaded solder (don't use lead-free):
 ![](https://av.canoeboot.org/dip8/adapter.jpg)
 ![](https://av.canoeboot.org/dip8/sop8todip8.jpg)
 
-### SOIC8/SOIC16 soldered to a mainboard
+### SOIC8/SOIC16 soldered to a motherboard
 
 This is an example of *in-system programming* or *ISP* for short.
 
@@ -1046,16 +1046,16 @@ SOIC8:\
 Pomona 5250 is a SOIC8 test clip. There are others available, but this is the
 best one. Use that. Use the SOIC8 diagram (see above) to wire up your Raspberry
 Pi.
-Your mainboard likely already pulls WP/HOLD (pins 3 and 7) high, so don't
+Your motherboard likely already pulls WP/HOLD (pins 3 and 7) high, so don't
 connect these. VCC on SOIC8's pin 8 probably already has decoupling
-capacitors on the mainboard, so just hook that up without using a capacitor.
+capacitors on the motherboard, so just hook that up without using a capacitor.
 
 SOIC16:\
 Pomona 5252 is a SOIC16 test clip. There are others available, but this is the
 best one. Use that. Use the SOIC16 diagram (see above) to wire up your Raspberry
 Pi. WP/HOLD pins are pins 1 and 9, and likely already held high, so no pull-up
 resistors needed. You do not need a decoupling capacitor for pin 2 (VCC) either
-because the mainboard will already have one.
+because the motherboard will already have one.
 
 Here is an example of a test clip connected for SOIC16:\
 ![](https://av.canoeboot.org/rpi/0002.jpg)
@@ -1063,9 +1063,9 @@ Here is an example of a test clip connected for SOIC16:\
 And here is an example photo for SOIC8:\
 ![](https://av.canoeboot.org/x60/th_bbb_flashing.jpg)
 
-### DIP8 soldered to the mainboard
+### DIP8 soldered to the motherboard
 
-It is extremely cursed for DIP8 to be soldered directly to the mainboard. It is
+It is extremely cursed for DIP8 to be soldered directly to the motherboard. It is
 usually mounted to a socket.
 
 The pins are large enough that you can just use test hooks to wire up your chip

site/docs/install/t60_unbrick.md

@@ -95,10 +95,10 @@ Refer to the external flashing guide:
 [Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
 
 NOTE: Do not use the 3.3v rail from your SPI programmer. Leave that disconnected.
-For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
+For 3.3v, plug your charger into the motherboard (but do not power on the motherboard)
 when the clip is connected. Before removing the clip, disconnect the charger.
 This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
-X60 shares a common 3.3V rail with many other components on the mainboard,
+X60 shares a common 3.3V rail with many other components on the motherboard,
 which all draw a lot of current, more than your flasher can provide.
 
 Example command:

site/docs/install/x60_unbrick.md

@@ -79,10 +79,10 @@ Refer to the following guide:\
 [Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
 
 NOTE: Do not use the 3.3v rail from your raspberry pi. Leave that disconnected.
-For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
+For 3.3v, plug your charger into the motherboard (but do not power on the motherboard)
 when the clip is connected. Before removing the clip, disconnect the charger.
 This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
-X60 shares a common 3.3V rail with many other components on the mainboard,
+X60 shares a common 3.3V rail with many other components on the motherboard,
 which all draw a lot of current, more than your programmer can provide.
 
 When you're finished flashing, remove the programmer and put it away somewhere.

site/docs/install/x60tablet_unbrick.md

@@ -59,10 +59,10 @@ Refer to the external flashing guide:
 [Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
 
 NOTE: Do not use the 3.3v rail from your SPI programmer. Leave that disconnected.
-For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
+For 3.3v, plug your charger into the motherboard (but do not power on the motherboard)
 when the clip is connected. Before removing the clip, disconnect the charger.
 This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
-X60 Tablet shares a common 3.3V rail with many other components on the mainboard,
+X60 Tablet shares a common 3.3V rail with many other components on the motherboard,
 which all draw a lot of current, more than most flashers can provide.
 
 Reverse the steps to re-assemble your system, after you've flashed the chip.

site/docs/linux/grub_hardening.md

@@ -126,7 +126,7 @@ The simplest way is to just do this:
 
 If you did the step before, to compile `cbfstool`, you can find ifdtool in
 the `elf/` directory, e.g. `elf/ifdtool/default/ifdtool`. Use the ifdtool
-version matching the coreboot tree for your mainboard.
+version matching the coreboot tree for your motherboard.
 
 Note that this only works for Intel-based systems that use an Intel Flash
 Descriptor, which is actually most Intel systems that Canoeboot supports.

site/docs/maintain/index.md

@@ -118,7 +118,7 @@ entire release archives, e.g. quad-core Haswell CPU or better.
 NOTE: x86 boards require an *x86_64* host CPU with appropriate host toolchains
 and libraries. We don't yet cross-compile x86 payloads.
 
-NOTE2: ARM64 mainboards *are* cross compiled, so you can build for AArch64
+NOTE2: ARM64 motherboards *are* cross compiled, so you can build for AArch64
 machines quite easily, from x86 or ARM64 machines.
 
 NOTE3: *32-bit* x86 (i686) machines can be used to compile Canoeboot, but
@@ -315,14 +315,14 @@ Third-party source trees are downloaded into this directory, by cbmk.
 Please also visit: <https://coreboot.org/>
 
 Coreboot is the main boot firmware, providing hardware initialisation. Canoeboot
-makes extensive use of coreboot, on supported mainboards.
+makes extensive use of coreboot, on supported motherboards.
 
 Coreboot trees go here. Canoeboot's build system does not simply use one tree,
 or multiple branches in the same tree; entirely separate directories are
 created, for each revision of coreboot used, each able to have its own patches.
-These can then be re-use appropriately, per mainboard. For example:
+These can then be re-use appropriately, per motherboard. For example:
 
-* `src/coreboot/default` is used by most mainboards.
+* `src/coreboot/default` is used by most motherboards.
 * `src/coreboot/cros` is used by cros devices.
 
 This may be less efficient on disk usage, but it simplifies the logic greatly.
@@ -1001,7 +1001,7 @@ which SeaBIOS revision (from Git) is to be used, when compiling SeaBIOS images.
 
 ### config/u-boot/
 
-This directory contains configuration, patches and so on, for each mainboard
+This directory contains configuration, patches and so on, for each motherboard
 that can use U-Boot as a payload in the `cbmk` build system. U-Boot doesn't yet
 have reliable generic configurations that can work across all coreboot boards
 (per-architecture), so these are used to build it per-board.
@@ -1014,7 +1014,7 @@ a location under `elf/u-boot/`.
 
 #### config/u-boot/TREENAME/
 
-Each `TREENAME` directory defines configuration for a corresponding mainboard.
+Each `TREENAME` directory defines configuration for a corresponding motherboard.
 It doesn't actually have to be for a board; it can also be used to just define
 a U-Boot revision, with patches and so on. To enable use as a payload in ROM
 images, this must have the same name as its `config/coreboot/TREENAME/`

site/docs/maintain/testing.md

@@ -30,8 +30,8 @@ maintainer or multiple maintainers; more is better.
 Please read the following sections to understand the specifics of
 maintaining a board.
 
-NOTE: If there are already testers for a given mainboard, *you* can still
+NOTE: If there are already testers for a given motherboard, *you* can still
-provide testing for the same mainboard if that's what you have. The more the
+provide testing for the same motherboard if that's what you have. The more the
 merrier!
 
 Be Contactable

site/faq.md

@@ -26,7 +26,7 @@ Refer to the [cbmk maintenance manual](docs/maintain/).
 
 ### Do not use CH341A!
 
-This SPI flasher will damage your chip, and the mainboard that it is connected
+This SPI flasher will damage your chip, and the motherboard that it is connected
 to.
 
 Read the notes about CH341A on [docs/install/spi.md](docs/install/spi.md) to
@@ -239,8 +239,8 @@ the CPU, and prevent the CPU from executing boot firmware that isn't
 signed with their private key. This means that ***coreboot and Canoeboot
 are impossible to port*** to such PCs, without the OEM's private
 signing key. Note that systems assembled from separately purchased
-mainboard and CPU parts are unaffected, since the vendor of the
+motherboard and CPU parts are unaffected, since the vendor of the
-mainboard (on which the boot firmware is stored) can't possibly affect
+motherboard (on which the boot firmware is stored) can't possibly affect
 the public key stored on the CPU.
 
 ME firmware versions 4.0 and later (Intel 4 Series and later chipsets)
@@ -532,7 +532,7 @@ re-flash it.
 ### How do I pad a ROM before flashing?
 
 It is advisable to simply use a larger ROM image. This section was written
-mostly for ASUS KCMA-D8 and KGPE-D16 mainboards, where previously we only
+mostly for ASUS KCMA-D8 and KGPE-D16 motherboards, where previously we only
 provided 2MiB ROM images in Canoeboot, but we now provide 16MiB ROM images.
 Other sizes are not provided because in practise, someone upgrading one of
 these chips will just use a 16MiB one. Larger sizes are available, but 16MiB
@@ -910,7 +910,7 @@ What level of software freedom does Canoeboot give me?
 
 Canoeboot firmware provides host hardware initialisation inside ROM files,
 that can be written to NOR flash, but on many systems there exist
-a lot more small computers on the mainboard running blob firmware.
+a lot more small computers on the motherboard running blob firmware.
 Some of them are not practicable to replace due to being located on Mask ROM.
 Most laptops have EC (Embedded Controller) firmware, for example.
 

site/index.de.md

@@ -21,8 +21,8 @@ am 7 January 2025.
 Siehe auch: [Canoeboot 20250107 release announcement](news/canoeboot20250107.md).**
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation, which can boot many Linux distros and BSD systems.

site/index.fr.md

@@ -17,8 +17,8 @@ dans le canal [\#canoeboot](https://web.libera.chat/#canoeboot) sur le serveur I
 le 7 January 2025.**
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation, which can boot many Linux distros and BSD systems.

site/index.it.md

@@ -19,8 +19,8 @@ su [Libera](https://libera.chat/).
 Vedi: [Canoeboot 20250107 annuncio di rilascio](news/canoeboot20250107.md).**
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation, which can boot many Linux distros and BSD systems.

site/index.md

@@ -53,8 +53,8 @@ the boot flash; coreboot works with many payloads, which boot your operating
 system e.g. Linux/BSD.
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation. Canoeboot's [design](docs/maintain/) incorporates all
@@ -172,14 +172,14 @@ to Canoeboot and your changes will (if conducive to Libreboot development) also
 be cherry-picked into Libreboot; the usual development workflow is the other
 way around, as described above.
 
-The *single* biggest way you can help is to *add* new mainboards in Libreboot,
+The *single* biggest way you can help is to *add* new motherboards in Libreboot,
 by submitting a config. Anything coreboot supports can be integrated in
 Libreboot, with ROM images provided in releases. If the board
 is [suitable](news/policy.md) for Canoeboot, it will then also be merged
 in Canoeboot. See:
 
 * [Apply to become a Libreboot board maintainer/tester](https://libreboot.org/docs/maintain/testing.html)
-* [Libreboot porting guide for new mainboards](https://libreboot.org/docs/maintain/porting.html)
+* [Libreboot porting guide for new motherboards](https://libreboot.org/docs/maintain/porting.html)
 * [Libreboot build system documentation](https://libreboot.org/docs/maintain/)
 * [Canoeboot build system documentation](docs/maintain/)
 

site/index.uk.md

@@ -19,8 +19,8 @@ x-toc-enable: true
 Дивіться: [Оголошення про випуск Canoeboot 20250107](news/canoeboot20250107.md).**
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation, which can boot many Linux distros and BSD systems.

site/index.zh-cn.md

@@ -11,8 +11,8 @@ Canoeboot 是 [Libreboot](https://libreboot.org/) 的分支。
 **新版发布: 最新版本 Canoeboot 20250107 已在 2025 年 1 月 7 日发布。详见: [Canoeboot 20250107 发布公告](news/canoeboot20250107.md).**
 
 Canoeboot provides [GRUB](docs/linux/) and SeaBIOS payloads on x86/x86\_64
-Intel/AMD mainboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
+Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot*
-on ARM64(Aarch64) mainboards.
+on ARM64(Aarch64) motherboards.
 An [x86/x86\_64 U-Boot UEFI payload](docs/uboot/uboot-x86.md) is also available
 on some boards. The x86, x86\_64 and arm64 U-Boot payloads provide a lightweight
 UEFI boot implementation, which can boot many Linux distros and BSD systems.

site/news/audit1.md

@@ -120,10 +120,10 @@ Changes are in order per category, from newest to oldest:
 * **GRUB is now a multi-tree project.** Each given coreboot target can
   specify which GRUB tree it wants to use, each containing its own revision
   and patches, with its own GRUB configuration file. This can be used later on
-  to provide specific optimisations on each given mainboard, but it is used
+  to provide specific optimisations on each given motherboard, but it is used
   at present to exclude xHCI patches on boards that don't need it; please also
   read the bugfix section (of this audit report) pertaining to this same topic,
-  for more context. Before this change was implemented, all mainboards used
+  for more context. Before this change was implemented, all motherboards used
   the exact same GRUB revision, with the same patches and the same config.
 * grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
   up the boot time in most tests, because most setups use `grub/`,
@@ -149,7 +149,7 @@ Changes are in order per category, from newest to oldest:
 * script/roms: Allow to override `grub_scan_disk` via `-s`, for
   example: `./build roms -s nvme t1650_12mb`
 * **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
-  device type).** It is possible now to configure each mainboard with this
+  device type).** It is possible now to configure each motherboard with this
   variable, so that certain types of devices are scanned in a precise order;
   for example, scan NVMe SSDs first.
 * **include/git.sh: Allow manual override of `git submodule` handling**, instead
@@ -164,7 +164,7 @@ Changes are in order per category, from newest to oldest:
   later changed so as to be the ONLY method for downloading submodules, skipping
   the actual git-submodule-update command entirely, on all projects.*
 * **Native NVMe driver added to the GRUB payload**, allowing users to boot from
-  NVMe SSDs where present on a given mainboard. The patch is courtesy of
+  NVMe SSDs where present on a given motherboard. The patch is courtesy of
   Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
   code to run properly within GRUB's own kernel. NVMe SSDs are now fully
   bootable on all machines that can have them, offering vastly superior
@@ -308,7 +308,7 @@ The changes are, from newest to earliest:
   issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
   using the new *multi-tree* GRUB handling, which is mentioned above in
   in the section (of this audit report) pertaining to *feature changes*, whereby
-  each mainboard can have its own GRUB revisions and patches, with its own
+  each motherboard can have its own GRUB revisions and patches, with its own
   GRUB configuration file (that could be uniquely optimised for it).
   We do not need xHCI patches on any Canoeboot machines, but the patches are
   free software regardless, and it's important to keep Canoeboot in sync with
@@ -335,12 +335,12 @@ The changes are, from newest to earliest:
   supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
   making it try to run the GRUB payload first, while still allowing you to
   interrupt by pressing ESC to bring up an alternative boot select menu. This
-  is now the *default*, on all x86 mainboards. This is a mitigation against
+  is now the *default*, on all x86 motherboards. This is a mitigation against
   future instability in GRUB because, if such issues happen again, it will not
   cause a brick since you can just use SeaBIOS instead, and skip booting to
   the GRUB payload (on the affected machines, BIOS GRUB still worked, which
   your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
-  into a multi-tree project, with certain mainboards using a version that
+  into a multi-tree project, with certain motherboards using a version that
   has the xHCI patches, if required, because the machines that actually need
   xHCI support were not affected by the bug referenced in issue 216.*
 * Main build script: Check SUID before checking Git name/email, otherwise the

site/news/audit2.md

@@ -63,7 +63,7 @@ will be new payloads and boards, in addition to testing newer upstream revisions
 of projects such as coreboot, on every machine supported by Canoeboot. A release
 is planned for early August 2024.
 
-A *lot* of work on new ports is planned. There are a number of new mainboards
+A *lot* of work on new ports is planned. There are a number of new motherboards
 that will be available, in the next Canoeboot release.
 
 Summarised list of changes
@@ -99,7 +99,7 @@ The changes are as follows:
   enabling `CONFIG_PAYLOAD_NONE` exclusively. However, advanced users may
   wish to use something else such as Tianocore, which Canoeboot may/will not
   provide (with Tianocore it's **will not**). Simply set `build_depend=""`
-  in the `target.cfg` file for a given mainboard, and then enable a payload
+  in the `target.cfg` file for a given motherboard, and then enable a payload
   under coreboot's menuconfig interface, or by direct modification of
   the defconfig file. When `CONFIG_PAYLOAD_NONE` is not set, cbmk will skip
   adding a payload, because it's a given that then coreboot's own build system
@@ -199,12 +199,12 @@ The changes are as follows:
   single-tree projects, defined *by argument*, but it was quite error prone
   and there's no clean way to otherwise do it. We don't use the script this
   way, anywhere in cbmk, and users are advised the same.
-* **`script/roms`: *Only* Support SeaBIOS and Sea*GRUB*, on x86 mainboards**.
+* **`script/roms`: *Only* Support SeaBIOS and Sea*GRUB*, on x86 motherboards**.
   SeaGRUB is a configuration whereby SeaBIOS starts first, but immediately tries
   to load GRUB from the flash. This complements the other change, listed below.
   We will no longer provide configurations where GRUB is the primary payload,
   precisely to mitigate the same issue as described below (cbmk issue 216).
-  If *GRUB* is enabled, on a given mainboard, SeaBIOS-only setups are not
+  If *GRUB* is enabled, on a given motherboard, SeaBIOS-only setups are not
   provided; only SeaGRUB is provided. You can press ESC in the SeaGRUB menu,
   to access other boot methods besides *GRUB from flash*, so you can use it
   in the same way; additionally, you can remove the `bootorder` file from CBFS
@@ -267,7 +267,7 @@ The changes are as follows:
   This mkhelper config also integrates `include/rom.sh`, containing these
   functions. This replicates the functionality originally provided
   by `script/roms`.
-* coreboot: Set `build_depend` on `target.cfg` files for specific mainboards.
+* coreboot: Set `build_depend` on `target.cfg` files for specific motherboards.
   This is used to manually specify which GRUB and SeaBIOS trees should be
   compiled, required when compiling for a specific target, for the next
   stage where a payload is added to the coreboot image, because cbmk does

site/news/canoeboot20231026.md

@@ -3,7 +3,7 @@
 % 26 October 2023
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -51,8 +51,8 @@ Canoeboot [removes all binary blobs](policy.md) from coreboot, unlike
 Libreboot which has a more pragmatic
 [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 Libreboot
-provides 100% free boot firmware on the same mainboards that Canoeboot can
+provides 100% free boot firmware on the same motherboards that Canoeboot can
-support, but supports *additional* mainboards while trying to minimize any
+support, but supports *additional* motherboards while trying to minimize any
 binary blobs all the same. Because of this difference, *Canoeboot* only
 supports a very limited subset of hardware from coreboot that is known to boot
 without binary blobs. Many other boards in coreboot require binary blobs for
@@ -239,7 +239,7 @@ mostly the results of the two audits (mentioned above):
 * SECURITY: Use sha512sum (not sha1sum) when verifying certain downloads. This
   reduces the chance for collisions, during checksum verification.
 * Set GRUB timout to 5s by default, but allow override and set to 10s or 15s
-  on some mainboards.
+  on some motherboards.
 * Support both curl and wget, where files are downloaded outside of Git; defer
   to Wget when Curl fails, and try each program three times before failing. This
   results in more resilient downloading, on wobbly internet connections.
@@ -425,7 +425,7 @@ mostly the results of the two audits (mentioned above):
 * A lot of scripts have been removed entirely, and their logic not replaced;
   in many cases, Canoeboot's build system contained logic that had gone unused
   for many years.
-* More reliable configs now used on desktop mainboards: SeaBIOS-only for start,
+* More reliable configs now used on desktop motherboards: SeaBIOS-only for start,
   but GRUB still available where feasible (in the SeaBIOS menu). This makes it
   more fool proof for a user who might use integrated graphics and then switch
   to a graphics card; the very same images will work.
@@ -501,7 +501,7 @@ scripts of the build system; considerably smaller than older revisions,
 accounting for an approximate *50% reduction* in the amount of code.
 
 That ~1250 sloc in Canoeboot is *with* all the extra features such as serprog
-integration and U-Boot support (on actual mainboards, that you can flash it
+integration and U-Boot support (on actual motherboards, that you can flash it
 with). The build system in Canoeboot 20231026 is *[extremely
 efficient](../docs/maintain/)*.
 
@@ -522,7 +522,7 @@ after the Libreboot 20231021 release came out:
 * <https://browse.libreboot.org/lbmk.git/commit/?id=df031d422a1c0b76edbea1cdee98796ad3d1392f>
 * <https://browse.libreboot.org/lbmk.git/commit/?id=5f6ba01d414e2d98d7db049347b8c5c5d125ba61>
 
-Excluded mainboards
+Excluded motherboards
 -------------------
 
 The following boards are *missing* in Canoeboot 20231026, but are supported in

site/news/canoeboot20231101.md

@@ -3,7 +3,7 @@
 % 1 November 2023
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 

site/news/canoeboot20231103.md

@@ -3,7 +3,7 @@
 % 3 November 2023
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 

site/news/canoeboot20231107.md

@@ -3,7 +3,7 @@
 % 7 November 2023
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 

site/news/canoeboot20240504.md

@@ -3,7 +3,7 @@
 % 4 May 2024
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -127,8 +127,8 @@ Canoeboot [removes all binary blobs](policy.md) from coreboot, unlike
 Libreboot which has a more pragmatic
 [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 Libreboot
-provides 100% free boot firmware on the same mainboards that Canoeboot can
+provides 100% free boot firmware on the same motherboards that Canoeboot can
-support, but supports *additional* mainboards while trying to minimize any
+support, but supports *additional* motherboards while trying to minimize any
 binary blobs all the same. Because of this difference, *Canoeboot* only
 supports a very limited subset of hardware from coreboot that is known to boot
 without binary blobs. Many other boards in coreboot require binary blobs for
@@ -254,7 +254,7 @@ are highlighted in bold:
 * Simpler, safer error handling in the build system
 * **util/autoport:** New utility, imported from coreboot's version but with extra
   patches merged for Haswell platforms. This can be used in future, tied heavily
-  to Canoeboot's own coreboot trees, to more easily add new mainboards.
+  to Canoeboot's own coreboot trees, to more easily add new motherboards.
 * **util/dell-flash-unlock: NetBSD support added**, courtesy of the developer
   who goes by the name *Linear Cannon*. Here is that person's website as of
   today: <https://linear.network/>
@@ -502,7 +502,7 @@ is that the offending patch that caused the bug has been *removed*; namely,
 xHCI GRUB patches, which are now only provided on Haswell and Broadwell
 hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
 GRUB tree with xHCI support is provided, but not currently used on any
-mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
+motherboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
 
 The next release will exclude xHCI support on machines that don't need it, which
 is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
@@ -514,7 +514,7 @@ It is now the default behaviour, in the next release, that certain images
 contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
 still press ESC to access the SeaBIOS boot menu if you want to directly boot
 an OS from that. This, and the other change mentioned above, will guarantee
-stability. GRUB is *no longer* the primary payload, on any mainboard.
+stability. GRUB is *no longer* the primary payload, on any motherboard.
 
 However, it was later decided to put this release in the `testing`
 directory instead; it was initially designated as a stable release.

site/news/canoeboot20240510.md

@@ -3,7 +3,7 @@
 % 10 May 2024
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -175,7 +175,7 @@ is that the offending patch that caused the bug has been *removed*; namely,
 xHCI GRUB patches, which are now only provided on Haswell and Broadwell
 hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
 GRUB tree with xHCI support is provided, but not currently used on any
-mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
+motherboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
 
 The next release will exclude xHCI support on machines that don't need it, which
 is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
@@ -187,7 +187,7 @@ It is now the default behaviour, in the next release, that certain images
 contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
 still press ESC to access the SeaBIOS boot menu if you want to directly boot
 an OS from that. This, and the other change mentioned above, will guarantee
-stability. GRUB is *no longer* the primary payload, on any mainboard.
+stability. GRUB is *no longer* the primary payload, on any motherboard.
 
 However, it was later decided to put this release in the `testing`
 directory instead; it was initially designated as a stable release.

site/news/canoeboot20240612.md

@@ -3,7 +3,7 @@
 % 12 June 2024
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -146,10 +146,10 @@ Changes are in order per category, from newest to oldest:
 * **GRUB is now a multi-tree project.** Each given coreboot target can
   specify which GRUB tree it wants to use, each containing its own revision
   and patches, with its own GRUB configuration file. This can be used later on
-  to provide specific optimisations on each given mainboard, but it is used
+  to provide specific optimisations on each given motherboard, but it is used
   at present to exclude xHCI patches on boards that don't need it; please also
   read the bugfix section (of this audit report) pertaining to this same topic,
-  for more context. Before this change was implemented, all mainboards used
+  for more context. Before this change was implemented, all motherboards used
   the exact same GRUB revision, with the same patches and the same config.
 * grub.cfg: scan `grub2/` last, on each given device/partition; this speeds
   up the boot time in most tests, because most setups use `grub/`,
@@ -175,7 +175,7 @@ Changes are in order per category, from newest to oldest:
 * script/roms: Allow to override `grub_scan_disk` via `-s`, for
   example: `./build roms -s nvme t1650_12mb`
 * **grub.cfg: Use `grub_scan_disk` to set boot order (rather, boot order by
-  device type).** It is possible now to configure each mainboard with this
+  device type).** It is possible now to configure each motherboard with this
   variable, so that certain types of devices are scanned in a precise order;
   for example, scan NVMe SSDs first.
 * **include/git.sh: Allow manual override of `git submodule` handling**, instead
@@ -190,7 +190,7 @@ Changes are in order per category, from newest to oldest:
   later changed so as to be the ONLY method for downloading submodules, skipping
   the actual git-submodule-update command entirely, on all projects.*
 * **Native NVMe driver added to the GRUB payload**, allowing users to boot from
-  NVMe SSDs where present on a given mainboard. The patch is courtesy of
+  NVMe SSDs where present on a given motherboard. The patch is courtesy of
   Mate Kukri, who ported SeaBIOS's own NVMe driver, converting all of the
   code to run properly within GRUB's own kernel. NVMe SSDs are now fully
   bootable on all machines that can have them, offering vastly superior
@@ -334,7 +334,7 @@ The changes are, from newest to earliest:
   issue 216](https://codeberg.org/libreboot/lbmk/issues/216). This is done, by
   using the new *multi-tree* GRUB handling, which is mentioned above in
   in the section (of this audit report) pertaining to *feature changes*, whereby
-  each mainboard can have its own GRUB revisions and patches, with its own
+  each motherboard can have its own GRUB revisions and patches, with its own
   GRUB configuration file (that could be uniquely optimised for it).
   We do not need xHCI patches on any Canoeboot machines, but the patches are
   free software regardless, and it's important to keep Canoeboot in sync with
@@ -361,12 +361,12 @@ The changes are, from newest to earliest:
   supported a configuration whereby SeaBIOS reads a `bootorder` file in CBFS,
   making it try to run the GRUB payload first, while still allowing you to
   interrupt by pressing ESC to bring up an alternative boot select menu. This
-  is now the *default*, on all x86 mainboards. This is a mitigation against
+  is now the *default*, on all x86 motherboards. This is a mitigation against
   future instability in GRUB because, if such issues happen again, it will not
   cause a brick since you can just use SeaBIOS instead, and skip booting to
   the GRUB payload (on the affected machines, BIOS GRUB still worked, which
   your distro provides and SeaBIOS executes it). *NOTE: GRUB was later made
-  into a multi-tree project, with certain mainboards using a version that
+  into a multi-tree project, with certain motherboards using a version that
   has the xHCI patches, if required, because the machines that actually need
   xHCI support were not affected by the bug referenced in issue 216.*
 * Main build script: Check SUID before checking Git name/email, otherwise the

site/news/canoeboot20241102.md

@@ -3,7 +3,7 @@
 % 2 November 2024
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -74,7 +74,7 @@ The changes are as follows:
 * Imported other of Riku's utilities: `mxmdump`, `int`.
 * Imported Riku Viitanen's fork of `gpio-scripts`, where the fork is designed
   to parse inteltool log output. This is useful for configuring the GPIOs
-  when adding a new mainboard to coreboot.
+  when adding a new motherboard to coreboot.
 * Relative to audit2: `lib.sh`: New `mk()` function can be used as shorthand
   within lbmk scripts, to build multiple projects, but does not build individual
   trees/targets within multi-tree projects. This is used to simplify certain
@@ -107,7 +107,7 @@ The changes are as follows:
   enabling `CONFIG_PAYLOAD_NONE` exclusively. However, advanced users may
   wish to use something else such as Tianocore, which Canoeboot may/will not
   provide (with Tianocore it's **will not**). Simply set `build_depend=""`
-  in the `target.cfg` file for a given mainboard, and then enable a payload
+  in the `target.cfg` file for a given motherboard, and then enable a payload
   under coreboot's menuconfig interface, or by direct modification of
   the defconfig file. When `CONFIG_PAYLOAD_NONE` is not set, cbmk will skip
   adding a payload, because it's a given that then coreboot's own build system
@@ -207,12 +207,12 @@ The changes are as follows:
   single-tree projects, defined *by argument*, but it was quite error prone
   and there's no clean way to otherwise do it. We don't use the script this
   way, anywhere in cbmk, and users are advised the same.
-* **`script/roms`: *Only* Support SeaBIOS and Sea*GRUB*, on x86 mainboards**.
+* **`script/roms`: *Only* Support SeaBIOS and Sea*GRUB*, on x86 motherboards**.
   SeaGRUB is a configuration whereby SeaBIOS starts first, but immediately tries
   to load GRUB from the flash. This complements the other change, listed below.
   We will no longer provide configurations where GRUB is the primary payload,
   precisely to mitigate the same issue as described below (cbmk issue 216).
-  If *GRUB* is enabled, on a given mainboard, SeaBIOS-only setups are not
+  If *GRUB* is enabled, on a given motherboard, SeaBIOS-only setups are not
   provided; only SeaGRUB is provided. You can press ESC in the SeaGRUB menu,
   to access other boot methods besides *GRUB from flash*, so you can use it
   in the same way; additionally, you can remove the `bootorder` file from CBFS
@@ -288,7 +288,7 @@ The changes are as follows:
   This mkhelper config also integrates `include/rom.sh`, containing these
   functions. This replicates the functionality originally provided
   by `script/roms`.
-* coreboot: Set `build_depend` on `target.cfg` files for specific mainboards.
+* coreboot: Set `build_depend` on `target.cfg` files for specific motherboards.
   This is used to manually specify which GRUB and SeaBIOS trees should be
   compiled, required when compiling for a specific target, for the next
   stage where a payload is added to the coreboot image, because cbmk does

site/news/canoeboot20241207.md

@@ -3,7 +3,7 @@
 % 7 December 2024
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 
@@ -133,7 +133,7 @@ This git log covers all changes in this audit, relative to Canoeboot 20241102.
 * 112b761926 enable the serial console on thinkpad t60 
 * 8ba8cf3e60 Only boot 32-bit u-boot from grub, 64 from seabios 
 * 6ff2a65a7c make the u-boot grub menuentry more useful 
-* 0a90386ddb Re-enable U-Boot x86 on real mainboards 
+* 0a90386ddb Re-enable U-Boot x86 on real motherboards 
 * f3d68fade3 u-boot x86 serial/ns16550: disable UART as needed 
 * 8333930599 Disable U-Boot x86 except on Qemu 
 * d6cf658624 fix U-Boot hotkey mention in grub.cfg 

site/news/canoeboot20250107.md

@@ -3,7 +3,7 @@
 % 7 January 2025
 
 Canoeboot is a *special fork* of [Libreboot](https://libreboot.org/), providing
-a de-blobbed configuration on *fewer mainboards*; Libreboot supports more
+a de-blobbed configuration on *fewer motherboards*; Libreboot supports more
 hardware, and much newer hardware. More information can be found on Canoeboot's
 [about](../about.html) page and by reading Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
 

site/news/policy.md

@@ -32,7 +32,7 @@ Free as in freedom!
 Canoeboot intentionally *de-blobs* coreboot, which is to say that it does not
 include binary blobs. The coreboot software otherwise requires binary blobs on
 some of the systems that it has support for. Canoeboot's version of coreboot is
-entirely *free*, on its consequently reduced set of supported mainboards.
+entirely *free*, on its consequently reduced set of supported motherboards.
 
 It was decided that a formal policy should be written, because there is quite
 a bit of nuance that would otherwise not be covered. Canoeboot's policies in

site/other.md

@@ -49,7 +49,7 @@ Several coreboot ports (e.g. MSI Z690-A PRO) were implemented directly by
 the Dasharo project, and later upstreamed into the regular coreboot project.
 
 Dasharo has a special emphasis on commercial application, providing tailored
-coreboot images for each supported mainboard, with an emphasis on stability.
+coreboot images for each supported motherboard, with an emphasis on stability.
 
 ### Heads