diff --git a/site/about.md b/site/about.md index 8a8e083..83190e9 100644 --- a/site/about.md +++ b/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. diff --git a/site/docs/install/dell780.md b/site/docs/install/dell780.md index 33b4951..fbb8c38 100644 --- a/site/docs/install/dell780.md +++ b/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 ----------------- diff --git a/site/docs/install/index.md b/site/docs/install/index.md index 7174489..45902ba 100644 --- a/site/docs/install/index.md +++ b/site/docs/install/index.md @@ -148,7 +148,7 @@ example, they might fix power issues that could then enhance battery life. See: 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. diff --git a/site/docs/install/kcma-d8.md b/site/docs/install/kcma-d8.md index 216fb5d..0994ac0 100644 --- a/site/docs/install/kcma-d8.md +++ b/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 diff --git a/site/docs/install/kgpe-d16.md b/site/docs/install/kgpe-d16.md index fb36c65..271a1eb 100644 --- a/site/docs/install/kgpe-d16.md +++ b/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} diff --git a/site/docs/install/latitude.md b/site/docs/install/latitude.md index 3602b43..9c9af3a 100644 --- a/site/docs/install/latitude.md +++ b/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. diff --git a/site/docs/install/nvmutil.md b/site/docs/install/nvmutil.md index 2872bea..456afe4 100644 --- a/site/docs/install/nvmutil.md +++ b/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. diff --git a/site/docs/install/spi.md b/site/docs/install/spi.md index 341f718..cb9f61c 100644 --- a/site/docs/install/spi.md +++ b/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 diff --git a/site/docs/install/t60_unbrick.md b/site/docs/install/t60_unbrick.md index a873a89..3ce8d3a 100644 --- a/site/docs/install/t60_unbrick.md +++ b/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: diff --git a/site/docs/install/x60_unbrick.md b/site/docs/install/x60_unbrick.md index 94722ba..e59fb2a 100644 --- a/site/docs/install/x60_unbrick.md +++ b/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. diff --git a/site/docs/install/x60tablet_unbrick.md b/site/docs/install/x60tablet_unbrick.md index 2bc68e5..b7ae226 100644 --- a/site/docs/install/x60tablet_unbrick.md +++ b/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. diff --git a/site/docs/linux/grub_hardening.md b/site/docs/linux/grub_hardening.md index c280ae6..15f35c1 100644 --- a/site/docs/linux/grub_hardening.md +++ b/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. diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index 7cd138b..e986392 100644 --- a/site/docs/maintain/index.md +++ b/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: 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/` diff --git a/site/docs/maintain/testing.md b/site/docs/maintain/testing.md index 4a1fef7..d663906 100644 --- a/site/docs/maintain/testing.md +++ b/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 -provide testing for the same mainboard if that's what you have. The more the +NOTE: If there are already testers for a given motherboard, *you* can still +provide testing for the same motherboard if that's what you have. The more the merrier! Be Contactable diff --git a/site/faq.md b/site/faq.md index 1377dba..a9eaa29 100644 --- a/site/faq.md +++ b/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 -mainboard (on which the boot firmware is stored) can't possibly affect +motherboard and CPU parts are unaffected, since the vendor of the +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. diff --git a/site/index.de.md b/site/index.de.md index 3c5f203..d497982 100644 --- a/site/index.de.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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. diff --git a/site/index.fr.md b/site/index.fr.md index 905337a..811ed03 100644 --- a/site/index.fr.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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. diff --git a/site/index.it.md b/site/index.it.md index 8646a36..60f53e1 100644 --- a/site/index.it.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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. diff --git a/site/index.md b/site/index.md index 6b88be4..7ff2149 100644 --- a/site/index.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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/) diff --git a/site/index.uk.md b/site/index.uk.md index da0995b..2e63ec4 100644 --- a/site/index.uk.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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. diff --git a/site/index.zh-cn.md b/site/index.zh-cn.md index 6f27bb4..a25e4d8 100644 --- a/site/index.zh-cn.md +++ b/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* -on ARM64(Aarch64) mainboards. +Intel/AMD motherboards, and a [U-Boot UEFI payload](docs/uboot/) *for coreboot* +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. diff --git a/site/news/audit1.md b/site/news/audit1.md index 02977a5..fc4e3c5 100644 --- a/site/news/audit1.md +++ b/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 diff --git a/site/news/audit2.md b/site/news/audit2.md index 5d821fd..cf923ed 100644 --- a/site/news/audit2.md +++ b/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 diff --git a/site/news/canoeboot20231026.md b/site/news/canoeboot20231026.md index e0f7a50..99a9169 100644 --- a/site/news/canoeboot20231026.md +++ b/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 -support, but supports *additional* mainboards while trying to minimize any +provides 100% free boot firmware on the same motherboards that Canoeboot can +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: * * -Excluded mainboards +Excluded motherboards ------------------- The following boards are *missing* in Canoeboot 20231026, but are supported in diff --git a/site/news/canoeboot20231101.md b/site/news/canoeboot20231101.md index ddd236b..b30924f 100644 --- a/site/news/canoeboot20231101.md +++ b/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). diff --git a/site/news/canoeboot20231103.md b/site/news/canoeboot20231103.md index 1d42d2d..0d65577 100644 --- a/site/news/canoeboot20231103.md +++ b/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). diff --git a/site/news/canoeboot20231107.md b/site/news/canoeboot20231107.md index cf5ff37..86174b6 100644 --- a/site/news/canoeboot20231107.md +++ b/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). diff --git a/site/news/canoeboot20240504.md b/site/news/canoeboot20240504.md index f899dfa..c92e1cd 100644 --- a/site/news/canoeboot20240504.md +++ b/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 -support, but supports *additional* mainboards while trying to minimize any +provides 100% free boot firmware on the same motherboards that Canoeboot can +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: @@ -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. diff --git a/site/news/canoeboot20240510.md b/site/news/canoeboot20240510.md index a4802a2..1c5cc52 100644 --- a/site/news/canoeboot20240510.md +++ b/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. diff --git a/site/news/canoeboot20240612.md b/site/news/canoeboot20240612.md index 9ab5889..802766c 100644 --- a/site/news/canoeboot20240612.md +++ b/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 diff --git a/site/news/canoeboot20241102.md b/site/news/canoeboot20241102.md index 7217307..918deb8 100644 --- a/site/news/canoeboot20241102.md +++ b/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 diff --git a/site/news/canoeboot20241207.md b/site/news/canoeboot20241207.md index f4b19cc..91af71f 100644 --- a/site/news/canoeboot20241207.md +++ b/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 diff --git a/site/news/canoeboot20250107.md b/site/news/canoeboot20250107.md index 626a85b..68199a4 100644 --- a/site/news/canoeboot20250107.md +++ b/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). diff --git a/site/news/policy.md b/site/news/policy.md index 4ad5fff..d5debbf 100644 --- a/site/news/policy.md +++ b/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 diff --git a/site/other.md b/site/other.md index 6715442..59bac48 100644 --- a/site/other.md +++ b/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