canoeboot
/
cbwww
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

s/mainboard/motherboard 

Signed-off-by: Leah Rowe <leah@libreboot.org>
master
Leah Rowe 2025-01-20 10:07:55 +00:00
parent 92420c7bba
commit 72b336227e
35 changed files with 119 additions and 119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
site/about.md
View File

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

4
site/docs/install/dell780.md
View File

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

8
site/docs/install/index.md
View File

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

4
site/docs/install/kcma-d8.md
View File

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

2
site/docs/install/kgpe-d16.md
View File

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

2
site/docs/install/latitude.md
View File

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

2
site/docs/install/nvmutil.md
View File

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

44
site/docs/install/spi.md
View File

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

4
site/docs/install/t60_unbrick.md
View File

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

4
site/docs/install/x60_unbrick.md
View File

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

4
site/docs/install/x60tablet_unbrick.md
View File

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

2
site/docs/linux/grub_hardening.md
View File

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

12
site/docs/maintain/index.md
View File

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

4
site/docs/maintain/testing.md
View File

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

10
site/faq.md
View File

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

4
site/index.de.md
View File

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

4
site/index.fr.md
View File

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

4
site/index.it.md
View File

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

8
site/index.md
View File

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

4
site/index.uk.md
View File

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

4
site/index.zh-cn.md
View File

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

14
site/news/audit1.md
View File

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

10
site/news/audit2.md
View File

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

14
site/news/canoeboot20231026.md
View File

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

2
site/news/canoeboot20231101.md
View File

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

2
site/news/canoeboot20231103.md
View File

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

2
site/news/canoeboot20231107.md
View File

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

12
site/news/canoeboot20240504.md
View File

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

6
site/news/canoeboot20240510.md
View File

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

16
site/news/canoeboot20240612.md
View File

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

12
site/news/canoeboot20241102.md
View File

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

4
site/news/canoeboot20241207.md
View File

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

2
site/news/canoeboot20250107.md
View File

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

2
site/news/policy.md
View File

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

2
site/other.md
View File

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