mirror of
https://codeberg.org/canoeboot/cbwww.git
synced 2025-05-01 12:55:14 +01:00
say GNU/Linux instead of Linux
because GNU+Linux isn't POSIX enough Signed-off-by: Leah Rowe <leah@libreboot.org>
This commit is contained in:
Leah Rowe
parent
0ccecdf730
commit
8bc7f76f59
65 changed files with 272 additions and 272 deletions
site
about.mdfaq.mdfaq.uk.mdfavicon.icoindex.de.mdindex.fr.mdindex.it.mdindex.mdindex.md.descriptionindex.uk.mdindex.zh-cn.md
docs
bsd
build
grub
index.mdindex.uk.mdindex.zh-cn.mdinstall
acer_g43t-am3.mdchromebooks.mddell_thermal.mddevmem.mddevmem.md.descriptionga-g41m-es2l.mdindex.mdkcma-d8.mdkgpe-d16.mdlatitude.mdmacbook21.mdnvmutil.mdr400.mdspi.mdspi.zh-cn.mdspi_generic.mdt400.mdt500.mdx200.mdx200.uk.md
linux
grub_boot_installer.mdgrub_boot_installer.md.descriptiongrub_cbfs.md.descriptiongrub_hardening.mdindex.mdindex.md.description
maintain
misc
uboot
news
audit1.mdaudit2.mdcanoeboot20231026.mdcanoeboot20231101.mdcanoeboot20231103.mdcanoeboot20231107.mdcanoeboot20240504.mdcanoeboot20240510.mdcanoeboot20240612.mdcanoeboot20241102.mdcanoeboot20241207.mdcanoeboot20250107.mdcanoeboot20250107rev1.mdpolicy.md
other.md|
|
@ -21,7 +21,7 @@ features](docs/linux/grub_hardening.md).
|
|||
Users take this automation for granted today, but Libreboot was the first such
|
||||
project to implement this. It, like Canoeboot, is
|
||||
a *[coreboot distro](docs/maintain/)* in the
|
||||
same way that *Debian* is a Linux distro. Similar projects now exist, today,
|
||||
same way that *Debian* is a GNU/Linux distro. Similar projects now exist, today,
|
||||
inspired by Libreboot's example. Coreboot is notoriously difficult to configure and install
|
||||
for most non-technical users, but Libreboot and Canoeboot make it easier.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ What is BSD?
|
|||
------------
|
||||
|
||||
In our context, we are referring to those descendents of 4.4BSD-Lite starting
|
||||
in the early 1990s. On balance, they are about equal to Linux in many ways,
|
||||
in the early 1990s. On balance, they are about equal to GNU/Linux in many ways,
|
||||
and some would argue that they are *better* (higher code quality). It can be
|
||||
said that the BSDs are the closest we have to *true* open source Unix systems,
|
||||
since they ultimately descend from that code lineage. For example, the
|
||||
|
|
@ -37,7 +37,7 @@ Chief among them are:
|
|||
|
||||
Many other BSD systems exist, that are largely derived from these.
|
||||
|
||||
Why use BSD (instead of Linux)?
|
||||
Why use BSD (instead of GNU/Linux)?
|
||||
-------------------------------
|
||||
|
||||
BSD operating systems are in wide use today, powering much of the world's
|
||||
|
|
@ -46,41 +46,41 @@ workstation systems. Some of them have unique features that you can't find
|
|||
anywhere else (e.g. FreeBSD jails, OpenBSD's numerous security enhancements,
|
||||
NetBSD's rump kernel design and clean code quality).
|
||||
|
||||
BSD systems are superficially similar to Linux systems, but they are very
|
||||
BSD systems are superficially similar to GNU/Linux systems, but they are very
|
||||
different under the hood (different kernel designs, different userspace
|
||||
implementations, and so on). However, almost all of the Linux userspace programs
|
||||
implementations, and so on). However, almost all of the GNU/Linux userspace programs
|
||||
that you enjoy using are probably available in the various BSD *ports trees*,
|
||||
or they can be compiled with little to no modification. This is because, despite
|
||||
the actual differences under the hood, the BSDs and various Linux distros all
|
||||
the actual differences under the hood, the BSDs and various GNU/Linux distros all
|
||||
adhere to the same basic standards (e.g. Single Unix Specification).
|
||||
|
||||
If you want to enjoy using a high quality operating system, with many unique
|
||||
features, BSD systems can be quite fun to use, and quite challenging. They tend
|
||||
to have a much more conservative take on implementations, compared to Linux
|
||||
to have a much more conservative take on implementations, compared to GNU/Linux
|
||||
distros, instead opting for technical correctness and minimalism; this is a
|
||||
good thing, because lots of Linux distros these days are extremely bloated.
|
||||
Using a BSD system feels like Linux did in the year 2005, just with much better
|
||||
good thing, because lots of GNU/Linux distros these days are extremely bloated.
|
||||
Using a BSD system feels like GNU/Linux did in the year 2005, just with much better
|
||||
hardware support, and that's a *good thing*; the reason why is that BSD systems
|
||||
simply have fewer users, and a higher concentration of *technical* users, and
|
||||
this *shows* when you use it. Linux is *much* more mass market and has to cater
|
||||
to all sorts of people, and these days Linux distros have to *Just Work*.
|
||||
this *shows* when you use it. GNU/Linux is *much* more mass market and has to cater
|
||||
to all sorts of people, and these days GNU/Linux distros have to *Just Work*.
|
||||
|
||||
You can look at the documentation of each BSD system and try each one out, to
|
||||
see which one is right for you. Be warned, BSD systems *are* typically harder
|
||||
to use than Linux systems. Even the most seasoned Linux user will often have a
|
||||
to use than GNU/Linux systems. Even the most seasoned GNU/Linux user will often have a
|
||||
hard time with any BSD, if it's their first time using a BSD system. This is
|
||||
mitigated by excellent documentation, which is one of the things that the BSDs
|
||||
excel at, but you are expected to *read* the documentation; many Linux distros
|
||||
excel at, but you are expected to *read* the documentation; many GNU/Linux distros
|
||||
try to hold your hand ("it Just Works"), but the BSDs generally don't do that.
|
||||
|
||||
If you're already a power user on Linux, and comfortable with the more hands-on
|
||||
distros like Arch Linux or Gentoo Linux, you'll have a much easier time
|
||||
If you're already a power user on GNU/Linux, and comfortable with the more hands-on
|
||||
distros like Arch GNU/Linux or Gentoo GNU/Linux, you'll have a much easier time
|
||||
learning a BSD. FreeBSD for example comes completely barebones by default, and
|
||||
you add packages to it, configuring it to your liking, much like Arch Linux; if
|
||||
you add packages to it, configuring it to your liking, much like Arch GNU/Linux; if
|
||||
you're wily enough, you might also use the CURRENT tree and install all packages
|
||||
by building them from *ports* (akin to how Gentoo Linux is used).
|
||||
by building them from *ports* (akin to how Gentoo GNU/Linux is used).
|
||||
|
||||
BSD systems also have much more relaxed licensing than Linux systems, by and
|
||||
BSD systems also have much more relaxed licensing than GNU/Linux systems, by and
|
||||
large; most of the software in the base system, on any BSD project, will use
|
||||
a permissive license instead of copyleft. They can be regarded as Free Software,
|
||||
but it's a very different ideology than, say, GNU. Some might argue that this
|
||||
|
|
@ -89,14 +89,14 @@ among different versions of the GPL. A BSD-style license permits *anyone* to
|
|||
use the code, *without* requiring modified versions to ship source code, so it
|
||||
can be said that the BSD license model contains [far fewer
|
||||
restrictions](https://docs.freebsd.org/en/articles/bsdl-gpl/). One might say
|
||||
that the BSD systems are *more free* than GNU/Linux systems.
|
||||
that the BSD systems are *more free* than GNU/GNU/Linux systems.
|
||||
|
||||
Basically, your choice to use BSD will likely be based on a combination of
|
||||
technical and/or ideological preferences. But don't say we didn't warn you.
|
||||
BSD is hard. On the flip side of that coin, BSD is *easy*, because it forces
|
||||
you to really learn how your system works; when you become proficient with
|
||||
BSD, you'll learn everything else much easier, and you may find yourself doing
|
||||
things more efficiently *in Linux* as well!
|
||||
things more efficiently *in GNU/Linux* as well!
|
||||
|
||||
That's enough BSD fanaticism. Please read the following sections, *before*
|
||||
you embark on your BSD Canoeboot journey:
|
||||
|
|
@ -120,8 +120,8 @@ On x86 platforms, Canoeboot provides the choice of GRUB and/or
|
|||
SeaBIOS payload. GRUB can technically boot BSD kernels, but the code is
|
||||
poorly maintained and unreliable for this use-case scenario; on BIOS systems,
|
||||
GRUB can chainload BSD bootloaders, but on bare metal (as coreboot payload),
|
||||
GRUB can only chainload other coreboot payloads or boot Linux/BSD kernels
|
||||
directly (but direct booting is only really reliable for Linux, in GRUB).
|
||||
GRUB can only chainload other coreboot payloads or boot GNU/Linux/BSD kernels
|
||||
directly (but direct booting is only really reliable for GNU/Linux, in GRUB).
|
||||
|
||||
It is recommended that you boot in text mode, with SeaBIOS. You can literally
|
||||
just follow the official installation guides for your BSD system, whether it
|
||||
|
|
@ -198,7 +198,7 @@ boot in text mode, you can't set VESA modes from BSD. However, you're in luck:
|
|||
At least OpenBSD and FreeBSD (possibly others) all have excellent KMS
|
||||
support nowadays; short for `Kernel Mode Setting`. This avoids the inefficiency
|
||||
of BIOS/UEFI methods, by having the kernel set modes directly. It is based on
|
||||
KMS drivers that the BSD projects ported over from the Linux kernel. With this,
|
||||
KMS drivers that the BSD projects ported over from the GNU/Linux kernel. With this,
|
||||
you can use X11/Wayland in FreeBSD (and just X11 in OpenBSD, for now).
|
||||
|
||||
For example: on FreeBSD, you can install `graphics/drm-kmod` as a package
|
||||
|
|
@ -224,7 +224,7 @@ ALWAYS READ THE MANUAL
|
|||
----------------------
|
||||
|
||||
All of the BSDs have *excellent* documentation; it's one of the defining
|
||||
characteristics, versus typical Linux distros.
|
||||
characteristics, versus typical GNU/Linux distros.
|
||||
|
||||
Aside from this quirk in coreboot, regarding *BIOS* video modes, the BSDs
|
||||
otherwise work in exactly the same way as you would expect, and you can
|
||||
|
|
@ -271,7 +271,7 @@ The reason to use KMS is because it's more efficient. The INT10H service can
|
|||
only be called in Real Mode or Virtual 8086 mode; v8086 is unavailable in
|
||||
long mode (x86\_64) and switching into Real Mode just to set VGA modes is
|
||||
extremely expensive computationally speaking. This is why modern kernels
|
||||
(Linux and BSD kernels) do mode setting themselves.
|
||||
(GNU/Linux and BSD kernels) do mode setting themselves.
|
||||
|
||||
You can learn more about INT10H text/VGA modes here:
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ ALWAYS READ THE MANUAL
|
|||
----------------------
|
||||
|
||||
All of the BSDs have *excellent* documentation; it's one of the defining
|
||||
characteristics, versus typical Linux distros. This is precisely *because*
|
||||
characteristics, versus typical GNU/Linux distros. This is precisely *because*
|
||||
the BSDs develop everything in-house, so the various components of a BSD
|
||||
system are much more heavily integrated, and this means that they can provide
|
||||
much more reliable documentation; reliable from both the user's perspective
|
||||
|
|
|
|||
|
|
@ -26,8 +26,8 @@ Kernel Mode Setting
|
|||
SeaBIOS. GRUB технічно може завантажувати ядра BSD, але код погано
|
||||
підтримується і є ненадійним для цього сценарію використання; на системах BIOS,
|
||||
GRUB може завантажити ланцюгом завантажувачі BSD, але bare metal (в якості корисного навантаження coreboot),
|
||||
GRUB може тільки завантажити ланцюгом інші корисні навантаження coreboot або завантажити ядра Linux/BSD
|
||||
безпосередньо (але безпосереднє завантаження тільки реально надійне для Linux, в GRUB).
|
||||
GRUB може тільки завантажити ланцюгом інші корисні навантаження coreboot або завантажити ядра GNU/Linux/BSD
|
||||
безпосередньо (але безпосереднє завантаження тільки реально надійне для GNU/Linux, в GRUB).
|
||||
|
||||
Це рекомендовано, щоб ви завантажувались в текстовому режимі, з SeaBIOS. Ви можете буквально
|
||||
просто слідкувати офіційним керівництвам встановлення для вашої системи BSD, чи це буде
|
||||
|
|
@ -91,7 +91,7 @@ mode з SeaVGABIOS, ви не отримаєте дисплей в завант
|
|||
Щонайменш OpenBSD та FreeBSD (можливо інші) всі мають чудову підтримку KMS
|
||||
в ці дні; коротко для `Kernel Mode Setting`. Це уникає неефективності
|
||||
методів BIOS/UEFI, маючи ядро, що встановлює режими безпосередньо. Воно засновано на
|
||||
драйверах KMS, що проекти BSD портували з ядра Linux. З цим,
|
||||
драйверах KMS, що проекти BSD портували з ядра GNU/Linux. З цим,
|
||||
ви можете використовувати X11/Wayland в FreeBSD (і просто X11 в OpenBSD, тепер).
|
||||
|
||||
Наприклад: в FreeBSD, ви можете встановити `graphics/drm-kmod` в якості пакунка
|
||||
|
|
@ -117,7 +117,7 @@ Xorg:
|
|||
----------------------
|
||||
|
||||
Всі BSD мають *чудову* документацію; це одна з визначних
|
||||
характеристик, проти типових дистрибутивів Linux.
|
||||
характеристик, проти типових дистрибутивів GNU/Linux.
|
||||
|
||||
Осторонь від цієї примхи в coreboot, що стосується *BIOS* video mode, BSD
|
||||
в іншому випадку працюють в точності таким чином, як ви би передбачали, і ви можете
|
||||
|
|
@ -168,7 +168,7 @@ VGA ROM зазвичай буде реалізовувати повні INT10H m
|
|||
бути викликано в Real Mode або Virtual 8086 mode; v8086 є недоступним в
|
||||
long mode (x86\_64) та перемикання в Real Mode лише для встановлення VGA mode є
|
||||
надзвичайно дорого, говорячи з точки зору обчислень. Це те, чому сучасні ядра
|
||||
(Linux та BSD) роблять mode setting самостійно.
|
||||
(GNU/Linux та BSD) роблять mode setting самостійно.
|
||||
|
||||
Ви можете вивчити більше про режими INT10H text/VGA тут:
|
||||
|
||||
|
|
|
|||
8
site/docs/build/index.md
vendored
8
site/docs/build/index.md
vendored
|
|
@ -19,7 +19,7 @@ to it: [canoeboot maintenance manual](../maintain/)
|
|||
|
||||
Do not run the build system on a eCryptfs file system, because it has
|
||||
very short file name limits and Canoeboot's build system deals with very
|
||||
long file names. We commonly get reports from this by Linux Mint users
|
||||
long file names. We commonly get reports from this by GNU/Linux Mint users
|
||||
who encrypt their home directory with eCryptfs; regular LUKS encryption will
|
||||
do nicely.
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ time or date can cause connections to be dropped during negotiation.
|
|||
Check `config/dependencies/` for list of supported distros.
|
||||
|
||||
Canoeboot includes a script that automatically installs build dependencies
|
||||
according to the selected Linux distro.
|
||||
according to the selected GNU/Linux distro.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ use the dedicated configuration file:
|
|||
|
||||
./mk dependencies ubuntu2004
|
||||
|
||||
Technically, any Linux distribution can be used to build canoeboot.
|
||||
Technically, any GNU/Linux distribution can be used to build canoeboot.
|
||||
However, you will have to write your own script for installing build
|
||||
dependencies.
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ specifically building the PSX BIOS, you need a MIPS cross compiler.
|
|||
|
||||
Arch-based systems have a mipsel cross compiler available from AUR, and most
|
||||
Debian-based systems have a mipsel cross compiler in apt; for these, the normal
|
||||
dependencies installation command will provide them. We know Void Linux and
|
||||
dependencies installation command will provide them. We know Void GNU/Linux and
|
||||
Fedora don't have a MIPS compiler, for instance.
|
||||
|
||||
If your distro doesn't have the MIPS compiler available,
|
||||
|
|
|
|||
6
site/docs/build/index.uk.md
vendored
6
site/docs/build/index.uk.md
vendored
|
|
@ -29,7 +29,7 @@ canoeboot з доступного джерельного коду.
|
|||
|
||||
Do not run the build system on a eCryptfs file system, because it has
|
||||
very short file name limits and Canoeboot's build system deals with very
|
||||
long file names. We commonly get reports from this by Linux Mint users
|
||||
long file names. We commonly get reports from this by GNU/Linux Mint users
|
||||
who encrypt their home directory with eCryptfs; regular LUKS encryption will
|
||||
do nicely.
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ canoeboot включає сценарій, який автоматично вс
|
|||
|
||||
Check: `config/dependencies/` for list of supported distros.
|
||||
|
||||
Технічно, будь-який дистрибутив Linux може бути використано для побудови canoeboot.
|
||||
Технічно, будь-який дистрибутив GNU/Linux може бути використано для побудови canoeboot.
|
||||
Однак, вам потрібно буде написано свій власний сценарій для встановлення залежностей
|
||||
побудови.
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ specifically building the PSX BIOS, you need a MIPS cross compiler.
|
|||
|
||||
Arch-based systems have a mipsel cross compiler available from AUR, and most
|
||||
Debian-based systems have a mipsel cross compiler in apt; for these, the normal
|
||||
dependencies installation command will provide them. We know Void Linux and
|
||||
dependencies installation command will provide them. We know Void GNU/Linux and
|
||||
Fedora don't have a MIPS compiler, for instance.
|
||||
|
||||
If your distro doesn't have the MIPS compiler available,
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ documentation, but there are aspects of Canoeboot that deserve special
|
|||
treatment. Canoeboot provides the option to boot GRUB directly, running on
|
||||
bare metal (instead of using BIOS or UEFI services).
|
||||
|
||||
Boot Linux from GRUB
|
||||
Boot GNU/Linux from GRUB
|
||||
--------------------
|
||||
|
||||
[The Linux section](../linux/) also has Canoeboot-specific guides for
|
||||
dealing with Linux distributions when using GRUB directly, in this
|
||||
[The GNU/Linux section](../linux/) also has Canoeboot-specific guides for
|
||||
dealing with GNU/Linux distributions when using GRUB directly, in this
|
||||
setup. [A similar section exists for BSD operating systems](../bsd/)
|
||||
|
||||
GRUB keyboard layouts
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Installing operating systems
|
|||
----------------------------
|
||||
|
||||
- [Install BSD operating systems on Canoeboot](bsd/)
|
||||
- [Install Linux on a Canoeboot system](linux/)
|
||||
- [Install GNU/Linux on a Canoeboot system](linux/)
|
||||
|
||||
Information for developers
|
||||
--------------------------
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Help is available on [Canoeboot IRC](../contact.md) and other channels.
|
|||
-----------------------------------------------------
|
||||
|
||||
- [Як встановити BSD на x86 хостову систему](bsd/)
|
||||
- [Керівництва Linux](linux/)
|
||||
- [Керівництва GNU/Linux](linux/)
|
||||
|
||||
Інформація для розробників
|
||||
--------------------------
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Help is available on [Canoeboot IRC](../contact.md) and other channels.
|
|||
----------------
|
||||
|
||||
- [如何在 x86 机器上安装 BSD](bsd/)
|
||||
- [Linux 指南](linux/)
|
||||
- [GNU/Linux 指南](linux/)
|
||||
|
||||
开发者信息
|
||||
----------
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ x-toc-enable: true
|
|||
...
|
||||
|
||||
This is similar to Gigabyte GA-G41M-ES2L but uses an Intel NIC rather than
|
||||
Realtek. Some problems with Linux on this NIC, on this board, with Canoeboot,
|
||||
Realtek. Some problems with GNU/Linux on this NIC, on this board, with Canoeboot,
|
||||
were observed; see (NOTE: Libreboot issue tracker, not Canoeboot):
|
||||
|
||||
<https://notabug.org/libreboot/lbmk/issues/125>
|
||||
|
|
@ -14,7 +14,7 @@ That page (on notabug) has some notes about workarounds. It links to this:
|
|||
<https://superuser.com/questions/1104537/how-to-repair-the-checksum-of-the-non-volatile-memory-nvm-of-intel-ethernet-co/1106641#1106641>
|
||||
|
||||
This page has some guidance on how to either correct the checksum (in GbE
|
||||
config) or skip checksum validation in Linux, to get the onboard NIC working.
|
||||
config) or skip checksum validation in GNU/Linux, to get the onboard NIC working.
|
||||
Although it's talking about different hardware, the steps should be the same.
|
||||
|
||||
TODO: factory BIOS on this board works fine with the onboard NIC. study what
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Chromebook laptops. Canoeboot replaces proprietary BIOS/UEFI firmware, though
|
|||
it should be noted that Google already ships coreboot and their own payload
|
||||
called Depthcharge, which is all free software; the difference with Canoeboot
|
||||
is that it replaces Depthcharge with *U-Boot* (as a coreboot payload), which
|
||||
provides a lightweight UEFI boot implementation that can boot regular Linux and
|
||||
provides a lightweight UEFI boot implementation that can boot regular GNU/Linux and
|
||||
BSD systems more easily than Depthcharge.
|
||||
|
||||
NOTE: daisy, peach and veyron boards were temporarily removed from
|
||||
|
|
@ -85,7 +85,7 @@ to flash firmware internally. To back up stock firmware you can run:
|
|||
Keep the resulting `depthcharge.rom` file safe and properly backed up on
|
||||
another device.
|
||||
|
||||
If you can already boot a conventional Linux distro on your Chromebook,
|
||||
If you can already boot a conventional GNU/Linux distro on your Chromebook,
|
||||
you may be able to use `flashrom -p linux_mtd` on that system instead.
|
||||
|
||||
Check external flashability
|
||||
|
|
@ -170,7 +170,7 @@ To flash the entire ROM image internally, run within ChromeOS:
|
|||
sudo flashrom -p host -w canoeboot.rom
|
||||
sudo flashrom -p host -v canoeboot.rom
|
||||
|
||||
If you can already boot a conventional Linux distro on your Chromebook,
|
||||
If you can already boot a conventional GNU/Linux distro on your Chromebook,
|
||||
you may be able to use `flashrom -p linux_mtd` on that system instead.
|
||||
|
||||
Install an operating system (experimental research)
|
||||
|
|
@ -186,7 +186,7 @@ three general methods for installing that vary depending on the distribution:
|
|||
|
||||
### Successful installations:
|
||||
|
||||
* [ArchLinuxARM on RK3399-based Chromebooks](../uboot/uboot-archlinux.md).
|
||||
* [ArchGNU/LinuxARM on RK3399-based Chromebooks](../uboot/uboot-archlinux.md).
|
||||
* [Debian Bookworm on Samsung Chromebook Plus XE513C24](../uboot/uboot-debian-bookworm.md).
|
||||
* [Debian on Asus Chromebook C201](https://wiki.debian.org/InstallingDebianOn/Asus/C201).
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Also: the `intel_pstate` driver can be used to artifically cap CPU speed. See:
|
|||
<https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html>
|
||||
|
||||
When you use this machine, it is recommended that you cap the CPU speed once
|
||||
you've booted into Linux. Set it to something like 50% at first. Then run a
|
||||
you've booted into GNU/Linux. Set it to something like 50% at first. Then run a
|
||||
stress test, for example:
|
||||
|
||||
stress -c x
|
||||
|
|
@ -32,7 +32,7 @@ stress test, for example:
|
|||
Where `x` is the number of CPU cores, e.g. 2. Monitor the temperatures using
|
||||
something like `xsensors`, making sure the CPU doesn't exceed 80c temperature.
|
||||
|
||||
You can also monitor CPU speeds in Linux like so:
|
||||
You can also monitor CPU speeds in GNU/Linux like so:
|
||||
|
||||
watch -n .2 grep MHz /proc/cpuinfo
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Disabling /dev/mem protections on Linux and BSD
|
||||
title: Disabling /dev/mem protections on GNU/Linux and BSD
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ to operate the internal flasher, at least on x86 machines.
|
|||
|
||||
See: <https://lwn.net/Articles/804143/>
|
||||
|
||||
Yeah, just enable `CONFIG_X86_IOPL_IOPERM` in your Linux kernel. This is
|
||||
Yeah, just enable `CONFIG_X86_IOPL_IOPERM` in your GNU/Linux kernel. This is
|
||||
a *build-time* option, so you must re-compile your kernel, or find a build that
|
||||
has this option enabled (IOPL emulation). Many default kernel configurations
|
||||
now disable this option.
|
||||
|
|
@ -76,5 +76,5 @@ must run flashprog as root, at least to use the internal flasher (using external
|
|||
USB flashing dongles doesn't normally require root).
|
||||
|
||||
NOTE: BSD kernels seem to still enable IOPL by default. However, many modern
|
||||
Linux setups disable it by default these days, so it may be in teh future
|
||||
GNU/Linux setups disable it by default these days, so it may be in teh future
|
||||
that most users will start needing to compile their own kernels. (go BSD!)
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Canoeboot installation relies heavily on port IO and access to lower memory, which is usually restricted. Learn how to enable access on Linux and BSD.
|
||||
Canoeboot installation relies heavily on port IO and access to lower memory, which is usually restricted. Learn how to enable access on GNU/Linux and BSD.
|
||||
|
|
|
|||
|
|
@ -63,9 +63,9 @@ for quite a nifty desktop. Powered by Canoeboot.
|
|||
IDE on the board is untested, but it might be possible to use a SATA HDD
|
||||
using an IDE SATA adapter. The SATA ports do work, but it's IDE emulation. The
|
||||
emulation is slow in DMA mode sia SeaBIOS, so SeaBIOS is configured to use PIO
|
||||
mode on this board. This SeaBIOS configuration does not affect the Linux kernel.
|
||||
mode on this board. This SeaBIOS configuration does not affect the GNU/Linux kernel.
|
||||
|
||||
You need to set a custom MAC address in Linux for the NIC to work.
|
||||
You need to set a custom MAC address in GNU/Linux for the NIC to work.
|
||||
In /etc/network/interfaces on debian-based systems like Debian or
|
||||
Devuan, this would be in the entry for your NIC:\
|
||||
hwaddress ether macaddressgoeshere
|
||||
|
|
@ -147,7 +147,7 @@ Here is an image of the flash chip:\
|
|||
|
||||
|
||||
Internal flashing is possible. Boot with the proprietary BIOS and
|
||||
Linux. There are 2 flash chips (one is backup).
|
||||
GNU/Linux. There are 2 flash chips (one is backup).
|
||||
|
||||
Flash the first chip:
|
||||
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ this modification to the ROM image, before flashing it.
|
|||
This is referred to informally as *Secure canoeBoot*.
|
||||
|
||||
Full flash lockdown is possible, with cryptographic verification of your
|
||||
Linux kernel and other files, using special features in the GRUB payload.
|
||||
GNU/Linux kernel and other files, using special features in the GRUB payload.
|
||||
|
||||
There are also some Intel X4X platforms that use an ICH10 southbridge,
|
||||
supported in Canoeboot, but these are flashed in a *descriptorless* setup,
|
||||
|
|
@ -414,7 +414,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 motherboard. Internal flashing means that you boot Linux or
|
||||
pertaining to your motherboard. Internal flashing means that you boot GNU/Linux or
|
||||
BSD on the target machine, and run `flashprog` there, flashing the machine
|
||||
directly.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Flashing instructions can be found at
|
|||
[../install/](../install/) - note that external
|
||||
flashing is required (e.g. RPi), if the proprietary (ASUS) firmware is
|
||||
currently installed. If you already have Canoeboot or coreboot, by default
|
||||
it is possible to re-flash using software running in Linux on the kcma-d8,
|
||||
it is possible to re-flash using software running in GNU/Linux on the kcma-d8,
|
||||
without using external hardware.
|
||||
|
||||
If you currently have the ASUS firmware, please ignore the above link and
|
||||
|
|
@ -126,8 +126,8 @@ Flash chips {#flashchips}
|
|||
2MiB flash chips are included by default, on these boards. It's on a
|
||||
P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes:
|
||||
4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a
|
||||
compressed linux+initramfs image (BusyBox+Linux system) into CBFS and
|
||||
boot that, loading it into memory (and nowadays there is LinuxBoot, for which
|
||||
compressed linux+initramfs image (BusyBox+GNU/Linux system) into CBFS and
|
||||
boot that, loading it into memory (and nowadays there is GNU/LinuxBoot, for which
|
||||
we would recommend a 16MiB boot flash)
|
||||
|
||||
*DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip
|
||||
|
|
@ -145,7 +145,7 @@ 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 motherboard. Nvidia GTX 780 cards
|
||||
are what Canoeboot recommends; it has excellent support in Nouveau (free Linux
|
||||
are what Canoeboot recommends; it has excellent support in Nouveau (free GNU/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
|
||||
because the Nouveau driver can't increase the GPU clock (it doesn't know how,
|
||||
|
|
@ -178,7 +178,7 @@ considerations:
|
|||
NOTE: SeaBIOS can load PCI-E option ROMs, and by default it will do so in
|
||||
Canoeboot, so you could use it. However, you could *also* simply
|
||||
install 16MiB NOR flash with linuxboot payload in it, and use linuxboot
|
||||
which has the Linux kernel, which can use SAS drives without needing that
|
||||
which has the GNU/Linux kernel, which can use SAS drives without needing that
|
||||
option ROM; then it can kexec another linux kernel, which in turn also can
|
||||
can use those drives. Or just put a standard linux kernel and initramfs
|
||||
in cbfs and chainload that from GRUB, with the right parameters.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Flashing instructions can be found at
|
|||
[../install/\#flashprog](../install/#flashprog) - note that external
|
||||
flashing is required, if the proprietary (ASUS) firmware is
|
||||
currently installed. If you already have Canoeboot, by default it is
|
||||
possible to re-flash using software running in Linux on the
|
||||
possible to re-flash using software running in GNU/Linux on the
|
||||
KGPE-D16, without using external hardware.
|
||||
|
||||
CPU compatibility
|
||||
|
|
@ -66,7 +66,7 @@ Flash chips {#flashchips}
|
|||
2MiB flash chips are included by default, on these boards. It's on a
|
||||
P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes:
|
||||
4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a
|
||||
compressed linux+initramfs image (BusyBox+Linux system) into CBFS and
|
||||
compressed linux+initramfs image (BusyBox+GNU/Linux system) into CBFS and
|
||||
boot that, loading it into memory.
|
||||
|
||||
Canoeboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ the full list of supported Dell Latitude models on the [Canoeboot hardware
|
|||
compatibility](./#which-systems-are-supported-by-canoeboot) page.
|
||||
|
||||
All of the Dell Latitude models can be flashed internally, which means that
|
||||
you do not need to disassemble them. You can do it from Linux or BSD, using
|
||||
you do not need to disassemble them. You can do it from GNU/Linux or BSD, using
|
||||
the instructions on this page.
|
||||
|
||||
Disable security before flashing
|
||||
|
|
@ -65,12 +65,12 @@ require binary blobs which are not allowed in Canoeboot.
|
|||
Internal flashing
|
||||
-----------------
|
||||
|
||||
You can simply boot Linux or BSD, on the Dell Latitude you wish to flash,
|
||||
You can simply boot GNU/Linux or BSD, on the Dell Latitude you wish to flash,
|
||||
and run `flashprog` from there, for Canoeboot installation. Certain other steps
|
||||
are also required, documented in the steps below:
|
||||
|
||||
You can flash Canoeboot directly from the vendor (Dell) BIOS, without taking
|
||||
the machine apart. It can be done entirely from Linux or BSD.
|
||||
the machine apart. It can be done entirely from GNU/Linux or BSD.
|
||||
|
||||
**NOTE (15 October 2023): The util is now called `dell-flash-unlock`, but it
|
||||
was previously called `e6400-flash-unlock`. Links have been updated.**
|
||||
|
|
|
|||
|
|
@ -137,10 +137,10 @@ motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replac
|
|||
Refer to the following guide:\
|
||||
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
|
||||
|
||||
OSes using Linux on Apple EFI firmware
|
||||
OSes using GNU/Linux on Apple EFI firmware
|
||||
--------------------------------------
|
||||
|
||||
You have 2 choices for booting up OSes using Linux as their kernel
|
||||
You have 2 choices for booting up OSes using GNU/Linux as their kernel
|
||||
on the MacBook:
|
||||
|
||||
* Boot via USB ;
|
||||
|
|
@ -300,7 +300,7 @@ to the file /etc/vconsole.conf and then restart the computer.
|
|||
|
||||
### Make touchpad more responsive
|
||||
|
||||
Linux kernels of version 3.15 or lower might make the touchpad
|
||||
GNU/Linux kernels of version 3.15 or lower might make the touchpad
|
||||
extremely sluggish. A user reported that they could get better
|
||||
response from the touchpad with the following in their `xorg.conf`:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ x-toc-enable: true
|
|||
|
||||
With this software, you can change the MAC address inside GbE regions
|
||||
on any system that uses an Intel Flash Descriptor. This software works well
|
||||
on most/all of the major Linux or BSD operating systems.
|
||||
on most/all of the major GNU/Linux or BSD operating systems.
|
||||
|
||||
You can use the documentation below, if you wish to use `nvmutil` manually.
|
||||
Continue reading...
|
||||
|
|
@ -109,7 +109,7 @@ does not modify or manipulate these in any way.
|
|||
The final word in the NVM section is the *checksum*; all words
|
||||
must add up, truncated, to the value `0xBABA`. The hardware
|
||||
itself does not calculate or validate this, and will in
|
||||
fact work nicely, but software such as Linux will check
|
||||
fact work nicely, but software such as GNU/Linux will check
|
||||
that this is correct. If the checksum is invalid, your
|
||||
kernel will refuse to make use of the NIC.
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ cbmk repository. A makefile is included there, for you to build an
|
|||
executable.
|
||||
|
||||
The nvmutil programs will work just fine, on any modern BSD Unix operating
|
||||
system, or unix-like system such as Linux.
|
||||
system, or unix-like system such as GNU/Linux.
|
||||
|
||||
You must be sure to have toolchains installed, for
|
||||
building; a normal libc, C compiler and linker should be enough.
|
||||
|
|
@ -545,7 +545,7 @@ used. Also, the `setmac` command will only operate on
|
|||
parts that already have a valid checksum, so you could
|
||||
run `brick` before running `setmac` (or run it afterwards).
|
||||
|
||||
The Linux kernel's `e1000` driver will refuse to initialise
|
||||
The GNU/Linux kernel's `e1000` driver will refuse to initialise
|
||||
Intel gigabit NICs that don't have a valid checksum. This
|
||||
is software-defined, and not enforced by the hardware.
|
||||
|
||||
|
|
@ -553,7 +553,7 @@ TODO
|
|||
----
|
||||
|
||||
* Support higher block sizes e.g. 8KB blocks for GbE part sections
|
||||
* Adapt this into a manpage (useful for Linux package repositories / BSD ports)
|
||||
* Adapt this into a manpage (useful for GNU/Linux package repositories / BSD ports)
|
||||
* Send nvmutil upstream to coreboot, for inclusion under `util/`
|
||||
* In addition to the manpage, when sending to coreboot, also adapt this page
|
||||
for inclusion into doc.coreboot.org
|
||||
|
|
|
|||
|
|
@ -324,4 +324,4 @@ You should see something like this:
|
|||
|
||||
 
|
||||
|
||||
Now [install Linux](../linux/).
|
||||
Now [install GNU/Linux](../linux/).
|
||||
|
|
|
|||
|
|
@ -15,10 +15,10 @@ This guide is predominantly about *installing Canoeboot* (flashing it) onto
|
|||
your motherboard's main system flash. You can also adapt this guide for dumping,
|
||||
erasing and verifying firmware images; this guide shows you how to use
|
||||
the [flashprog](https://flashprog.org/) software with various external
|
||||
25XX NOR flash programmers. This guide is written for *Linux* users, but BSD
|
||||
25XX NOR flash programmers. This guide is written for *GNU/Linux* users, but BSD
|
||||
operating systems are also compatible with flashprog; Windows might be feasible,
|
||||
ditto Apple's MacOS, as flashprog can also run on those, but they are not
|
||||
officially supported by Canoeboot, and *we recommend* that you use Linux/BSD.
|
||||
officially supported by Canoeboot, and *we recommend* that you use GNU/Linux/BSD.
|
||||
|
||||
Although this documentation is written *for the Canoeboot project*, it can be
|
||||
used on any compatible 25xx NOR flash, on any number of devices, such as home
|
||||
|
|
@ -79,7 +79,7 @@ Canoeboot is running.
|
|||
|
||||
*Internal* flashing means that the host CPU on your system can re-program the
|
||||
SPI flash, using an on-board SPI programmer (which all boards have). You do this
|
||||
from Linux, with flashprog.
|
||||
from GNU/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 motherboard.
|
||||
|
|
@ -495,7 +495,7 @@ TODO: document other SPI flashers
|
|||
SSH into your Raspberry Pi. You will run `flashprog` from your Raspberry Pi.
|
||||
|
||||
You must configure `spidev` on your Raspberry Pi. This is a special driver in
|
||||
the Linux kernel; technically, the driver name is `spi-bcm2835`.
|
||||
the GNU/Linux kernel; technically, the driver name is `spi-bcm2835`.
|
||||
|
||||
This page has info:\
|
||||
<https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md>
|
||||
|
|
@ -576,7 +576,7 @@ the problem here is that it gave Microsoft free reign to define whatever
|
|||
dependencies they liked (as per apt-get rules), and every time you updated,
|
||||
you would be pinging Microsoft servers. Do you think that is strange?
|
||||
|
||||
Microsoft shouldn't have *any* access to your Linux system! This was the
|
||||
Microsoft shouldn't have *any* access to your GNU/Linux system! This was the
|
||||
commit that Raspbian added to their distro, which added this what should rightly
|
||||
be called a security vulnerability, intentionally:
|
||||
|
||||
|
|
@ -620,7 +620,7 @@ script is also applicable to newer ubuntu versions
|
|||
If the `ubuntu2004` script complains about missing dependencies, just modify
|
||||
the dependencies config to remove those dependencies. The script is located
|
||||
at `config/dependencies/ubuntu2004` and it is written for
|
||||
Ubuntu 20.04, but it should work fine in other Linux distributions that use
|
||||
Ubuntu 20.04, but it should work fine in other GNU/Linux distributions that use
|
||||
the `apt-get` package manager.
|
||||
|
||||
A `flashprog/` directory will be present, with a `flashprog` executable inside
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ canoeboot 目前记录了这些 SPI 编程器的使用方法：
|
|||
|
||||
大部分支持 canoeboot 机器，都需要在第一次刷写的时候，借助这里的教程或是类似教程，对其进行外部再刷写。不过，目前支持的所有机器，你都可以在 canoeboot 运行时，对其进行内部再刷写。
|
||||
|
||||
*内部*刷写是指，主机上的 CPU 可以使用板载 SPI 编程器（每个主板都有）对 SPI flash 进行再编程。这可以在 Linux 上使用 flashprog 做到。
|
||||
*内部*刷写是指，主机上的 CPU 可以使用板载 SPI 编程器（每个主板都有）对 SPI flash 进行再编程。这可以在 GNU/Linux 上使用 flashprog 做到。
|
||||
|
||||
你在读的*这个*教程，使用的是*外部*编程器。之所以叫*外部*，是因为用的不是主板上的*内部*编程器。
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ Note: flashprog can never write if the flash chip isn't found automatically.
|
|||
|
||||
SSH 连接到树莓派。你将在树莓派上运行 `flashprog`。
|
||||
|
||||
你必须在树莓派上配置 `spidev`。这是 Linux 内核的一个特别驱动；它严谨的名字叫做 `spi-bcm2835`。
|
||||
你必须在树莓派上配置 `spidev`。这是 GNU/Linux 内核的一个特别驱动；它严谨的名字叫做 `spi-bcm2835`。
|
||||
|
||||
这个页面有信息：\
|
||||
<https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md>
|
||||
|
|
@ -322,7 +322,7 @@ RPi 的 flashprog 可能无法检测到一些系统的 SPI flash，即使你已
|
|||
|
||||
基本上，Raspbian 项目，即现在的 Raspberry Pi OS，对其仓库进行了更新，增加了一个新的“受信任”仓库，这刚好是一个微软软件仓库。他们这么做，似乎是为了 VS Code，但问题在于，这可以让微软自由地控制他们喜欢的依赖（根据 apt-get 规则）。每当你更新，你都会对微软的服务器发送请求。不觉得这很奇怪吗？
|
||||
|
||||
微软不应该对你的 Linux 系统有*任何*访问权！这是 Raspbian 添加在他们仓库的 commit，正是它故意添加了我们应该称之为安全漏洞的仓库：
|
||||
微软不应该对你的 GNU/Linux 系统有*任何*访问权！这是 Raspbian 添加在他们仓库的 commit，正是它故意添加了我们应该称之为安全漏洞的仓库：
|
||||
|
||||
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/655cad5aee6457b94fc2336b1ff3c1104ccb4351>
|
||||
|
||||
|
|
@ -356,7 +356,7 @@ Flashprog 是用来读出、擦除、重写 NOR flash 内容的软件。
|
|||
|
||||
./mk -b flashprog
|
||||
|
||||
如果 `ubuntu2004` 报告了依赖缺失，编辑一下这个脚本，把缺失的依赖移除就行了。脚本位于 `config/dependencies/ubuntu2004`，它是写给 Ubuntu 20.04 的，但在其他使用 `apt-get` 包管理器的 Linux 发行版应该也能用。
|
||||
如果 `ubuntu2004` 报告了依赖缺失，编辑一下这个脚本，把缺失的依赖移除就行了。脚本位于 `config/dependencies/ubuntu2004`，它是写给 Ubuntu 20.04 的，但在其他使用 `apt-get` 包管理器的 GNU/Linux 发行版应该也能用。
|
||||
|
||||
接下来，会出现一个 `flashprog/` 目录，其中有一个 `flashprog` 可执行文件。如果你在运行上面的依赖命令的时候，出现了缺失包的错误，则修改 `config/dependencies/ubuntu2004`。那个脚本会在 apt-get 中下载并安装构建依赖，它是为运行 Ubuntu 的 x86-64 系统写的，但在树莓派上的 Raspbian 应该能用。
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Connecting via ethernet is generally easier than doing so with WiFi.
|
|||
Check your distro's docs if you wish to connect with WiFi only.
|
||||
To determine the IP address of your programmer, log in to your AP/Router web interface.
|
||||
If you're not sure the IP address of your AP, it is likely `192.168.1.1.`
|
||||
You can determine the correct IP address with `ip r` on a Linux system.
|
||||
You can determine the correct IP address with `ip r` on a GNU/Linux system.
|
||||
You should see your programmer somewhere on the homepage, depending on your router firmware.
|
||||
This author recommends using [https://openwrt.org/](https://openwrt.org/) for your router firmware.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ sudo ldto merge spicc spicc-spidev
|
|||
Using flashprog
|
||||
--------------
|
||||
|
||||
Some Linux distros will provide flashprog in their default repositories.
|
||||
Some GNU/Linux distros will provide flashprog in their default repositories.
|
||||
|
||||
```
|
||||
sudo apt update
|
||||
|
|
|
|||
|
|
@ -323,4 +323,4 @@ You should see something like this:
|
|||
|
||||
 
|
||||
|
||||
Now [install Linux](../linux/).
|
||||
Now [install GNU/Linux](../linux/).
|
||||
|
|
|
|||
|
|
@ -356,4 +356,4 @@ You should see something like this:
|
|||
|
||||
|
||||
|
||||
Now [install Linux](../linux/).
|
||||
Now [install GNU/Linux](../linux/).
|
||||
|
|
|
|||
|
|
@ -271,7 +271,7 @@ You should see something like this:
|
|||
|
||||
|
||||
|
||||
Now [install Linux](../linux/).
|
||||
Now [install GNU/Linux](../linux/).
|
||||
|
||||
Errata
|
||||
------
|
||||
|
|
@ -327,7 +327,7 @@ probably setting something in memory and loading the ROM, plus a payload program
|
|||
that does the flashing; Lenovo BIOS then probably sees that and runs that, instead
|
||||
of setting PRx and going for normal boot. It is theoretically possible that we
|
||||
could discover how this works, by debugging the Lenovo BIOS update utility (in
|
||||
Windows), and then replicate what it is doing, with some tool for Linux,
|
||||
Windows), and then replicate what it is doing, with some tool for GNU/Linux,
|
||||
then load a flashprog binary into memory and the ROM to flash (for the BIOS
|
||||
region). You would do this with GPIO33 grounded, and the payload program would
|
||||
actually flash the entire chip, with just a normal libreboot image.
|
||||
|
|
|
|||
|
|
@ -258,7 +258,7 @@ Tablet (для цих систем потрібно повністю видал
|
|||
|
||||
|
||||
|
||||
Тепер [встановлюйте Linux](../linux/).
|
||||
Тепер [встановлюйте GNU/Linux](../linux/).
|
||||
|
||||
### Користувачі X200S та X200 Tablet: трюк GPIO33 не спрацює.
|
||||
|
||||
|
|
@ -305,7 +305,7 @@ internal -w rom.rom:
|
|||
яка виконує перепрошивання; тоді Lenovo BIOS, ймовірно, бачить це та запускає це замість
|
||||
встановлення PRx і переходу до нормального завантаження. Теоретично можливо, що ми
|
||||
зможемо дізнатися, як це працює, налагодивши утиліту оновлення BIOS Lenovo (у
|
||||
Windows), а потім відтворивши її дії за допомогою якогось інструменту для Linux,
|
||||
Windows), а потім відтворивши її дії за допомогою якогось інструменту для GNU/Linux,
|
||||
а потім завантаживши двійковий файл flashprog в пам'ять та ROM для прошивки (для BIOS
|
||||
регіона). Ви б зробили це з заземленням GPIO33, і програма корисного навантаження
|
||||
фактично прошиє весь чіп, лише звичайним образом libreboot.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Boot Linux distro installers on Canoeboot
|
||||
title: Boot GNU/Linux distro installers on Canoeboot
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
|
|
@ -11,18 +11,18 @@ If you're using SeaBIOS, it's quite intuitive and works similarly to other BIOS
|
|||
software; refer to the documentation on <https://seabios.org/SeaBIOS>.
|
||||
|
||||
This guide explains how to prepare a bootable USB for Canoeboot systems that
|
||||
can be used to install several Linux distributions. For this guide, you
|
||||
can be used to install several GNU/Linux distributions. For this guide, you
|
||||
will only need a USB flash drive and the `dd` utility (it's installed into all
|
||||
Linux distributions, by default).
|
||||
GNU/Linux distributions, by default).
|
||||
|
||||
These instructions are intended to be generic, applicable to just about any
|
||||
Linux distribution.
|
||||
GNU/Linux distribution.
|
||||
|
||||
Prepare the USB Drive in Linux
|
||||
Prepare the USB Drive in GNU/Linux
|
||||
------------------------------
|
||||
|
||||
If you downloaded your ISO while on an existing Linux system, here is how
|
||||
to create the bootable Linux USB drive:
|
||||
If you downloaded your ISO while on an existing GNU/Linux system, here is how
|
||||
to create the bootable GNU/Linux USB drive:
|
||||
|
||||
Connect the USB drive. Check `lsblk`, to confirm its device name
|
||||
(e.g., **/dev/sdX**):
|
||||
|
|
@ -35,7 +35,7 @@ it's not mounted:
|
|||
sudo umount /dev/sdb
|
||||
|
||||
Overwrite the drive, writing your distro ISO to it with `dd`. For example, if
|
||||
we are installing *Foobarbaz* Linux, and it's located in our Downloads
|
||||
we are installing *Foobarbaz* GNU/Linux, and it's located in our Downloads
|
||||
folder, this is the command we would run:
|
||||
|
||||
sudo dd if=~/Downloads/foobarbaz.iso of=/dev/sdb bs=8M; sync
|
||||
|
|
@ -49,21 +49,21 @@ Prepare the USB drive in NetBSD
|
|||
[This page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
|
||||
on the NetBSD website shows how to create a NetBSD bootable USB drive, from
|
||||
within NetBSD itself. You should the `dd` method documented there. This will
|
||||
work with any Linux ISO image.
|
||||
work with any GNU/Linux ISO image.
|
||||
|
||||
Prepare the USB drive in FreeBSD
|
||||
--------------------------------
|
||||
|
||||
[This page](https://www.freebsd.org/doc/handbook/bsdinstall-pre.html) on the
|
||||
FreeBSD website shows how to create a bootable USB drive for installing
|
||||
FreeBSD. Use the `dd` method documented. This will work with any Linux ISO
|
||||
FreeBSD. Use the `dd` method documented. This will work with any GNU/Linux ISO
|
||||
image.
|
||||
|
||||
Prepare the USB drive in OpenBSD
|
||||
--------------------------------
|
||||
|
||||
If you downloaded your ISO on a LibertyBSD or OpenBSD system, here is how to
|
||||
create the bootable Linux USB drive:
|
||||
create the bootable GNU/Linux USB drive:
|
||||
|
||||
Connect the USB drive. Run `lsblk` to determine which drive it is:
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ Booting ISOLINUX Images (Manual Method)
|
|||
---------------------------------------
|
||||
|
||||
These are generic instructions. They may or may not be correct for your
|
||||
distribution. You must adapt them appropriately, for whatever Linux
|
||||
distribution. You must adapt them appropriately, for whatever GNU/Linux
|
||||
distribution it is that you are trying to install.
|
||||
|
||||
If the `ISOLINUX parser` or `Search for GRUB configuration` options won't work,
|
||||
|
|
@ -173,9 +173,9 @@ Troubleshooting
|
|||
|
||||
Most of these issues occur when using Canoeboot with coreboot's `text-mode`
|
||||
with libgfxinit for video initialization. This mode is useful for text mode
|
||||
payloads, like `MemTest86+`, which expect `text-mode`, but for Linux
|
||||
payloads, like `MemTest86+`, which expect `text-mode`, but for GNU/Linux
|
||||
distributions it can be problematic when they are trying to switch to a
|
||||
framebuffer, because no mode switching support is present (Linux/BSD kernels
|
||||
framebuffer, because no mode switching support is present (GNU/Linux/BSD kernels
|
||||
do Kernel Mode Setting, so they are able to initialize a frame buffer in bare
|
||||
metal regardless of whatever coreboot is doing).
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Learn how to boot Linux distro installers on your Canoeboot system.
|
||||
Learn how to boot GNU/Linux distro installers on your Canoeboot system.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
The GNU boot loader GRUB can read from coreboot's file system, and boot Linux/BSD systems from the flash. Learn how to configure this behaviour.
|
||||
The GNU boot loader GRUB can read from coreboot's file system, and boot GNU/Linux/BSD systems from the flash. Learn how to configure this behaviour.
|
||||
|
|
|
|||
|
|
@ -46,21 +46,21 @@ Full disk encryption
|
|||
[Encrypted /boot with LUKS2 on argon2 key derivation is now
|
||||
possible](https://libreboot.org/news/argon2.md) - the work is based on that done by
|
||||
Patrick Steinhardt, importing PHC's Argon2 implementation. This was later added
|
||||
to GRUB 2.06 on the Arch Linux AUR by Ax333l, and Nicholas Johnson later rebased
|
||||
to GRUB 2.06 on the Arch GNU/Linux AUR by Ax333l, and Nicholas Johnson later rebased
|
||||
it for GRUB 2.12 to use in Libreboot's GRUB payload, which was then adapted
|
||||
for the Canoeboot GRUB payload.
|
||||
|
||||
This is covered in
|
||||
the [main Linux guide](./#encrypted-boot-via-luks2-with-argon2), in the
|
||||
the [main GNU/Linux guide](./#encrypted-boot-via-luks2-with-argon2), in the
|
||||
section pertaining to LUKS2/argon2.
|
||||
|
||||
You are strongly advised to create an encrypted Linux installation, before
|
||||
You are strongly advised to create an encrypted GNU/Linux installation, before
|
||||
setting up GRUB as shown in the guide below. Adapt it for whichever distro
|
||||
you're installing (documenting every distro on the Canoeboot documentation
|
||||
would be a futile exercise and will not be attempted).
|
||||
|
||||
You are advised to do this *first*, because steps below depend on certain
|
||||
configuration changes to be made on your installed Linux distro.
|
||||
configuration changes to be made on your installed GNU/Linux distro.
|
||||
|
||||
**Dependencies (do this first)**
|
||||
--------------------------------
|
||||
|
|
@ -144,7 +144,7 @@ the `dell-flash-unlock` utility does, so you can consider IFD locking there
|
|||
to be basically useless.
|
||||
|
||||
In addition to the above, you may also consider `/dev/mem` protection.
|
||||
Enable `CONFIG_STRICT_DEVMEM` in your Linux kernel, or set `securelevel` above
|
||||
Enable `CONFIG_STRICT_DEVMEM` in your GNU/Linux kernel, or set `securelevel` above
|
||||
zero on your BSD setup (but BSD cannot be booted with GRUB very easily so
|
||||
it's a moot point).
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ checking can be disabled through the GRUB console with this command:
|
|||
set check_signatures=no
|
||||
|
||||
The above GRUB shell command is required when you want to live USB media,
|
||||
or other Linux setups that don't yet have signatures on files e.g. linux.
|
||||
or other GNU/Linux setups that don't yet have signatures on files e.g. linux.
|
||||
|
||||
We will assume that you're using the `default` GRUB tree; the GRUB CBFS guide
|
||||
linked above tells you how to determine which GRUB tree to use.
|
||||
|
|
@ -345,14 +345,14 @@ and the system is now unbootable, that's OK because you can use an
|
|||
external flasher; please
|
||||
read [external flashing instructions](../install/spi.md)
|
||||
|
||||
Linux kernel hardening
|
||||
GNU/Linux kernel hardening
|
||||
----------------------
|
||||
|
||||
You may also wish to compile your own kernel, because distro kernels will always
|
||||
have code in the same place, so attackers are more easily able to know exactly
|
||||
where to attack your kernel (ROP-based attacks).
|
||||
|
||||
The Whonix/KickSecure Linux projects have guidance about Linux kernel
|
||||
The Whonix/KickSecure GNU/Linux projects have guidance about GNU/Linux kernel
|
||||
hardening:
|
||||
|
||||
* <https://www.kicksecure.com/wiki/System_Hardening_Checklist>
|
||||
|
|
@ -360,10 +360,10 @@ hardening:
|
|||
* <https://www.kicksecure.com/wiki/Operating_System_Hardening>
|
||||
|
||||
There's info there about userspace too, but start with kernel first. Canoeboot
|
||||
is a boot firmware project, so Linux kernel hardening is beyond the scope of
|
||||
is a boot firmware project, so GNU/Linux kernel hardening is beyond the scope of
|
||||
the Canoeboot project documentation, **for now**.
|
||||
|
||||
(for now, because Canoeboot may in fact provide a Linux distro in the flash
|
||||
(for now, because Canoeboot may in fact provide a GNU/Linux distro in the flash
|
||||
at some point, and this page will definitely be updated when that happens)
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Boot GNU and Linux on a Canoeboot system
|
||||
title: Boot GNU and GNU/Linux on a Canoeboot system
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
|
|
@ -11,10 +11,10 @@ If you're using SeaBIOS, the boot process will work similarly to traditional
|
|||
BIOS systems; refer to the SeaBIOS documentation
|
||||
on <https://seabios.org/SeaBIOS>
|
||||
|
||||
Linux is generally assumed, especially for Canoeboot development, but Canoeboot
|
||||
GNU/Linux is generally assumed, especially for Canoeboot development, but Canoeboot
|
||||
also works quite nicely with [BSD systems](../bsd/).
|
||||
|
||||
### Booting Linux from GRUB payload
|
||||
### Booting GNU/Linux from GRUB payload
|
||||
|
||||
NOTE: This guide pertains to x86 hosts, and does not cover supported CrOS/ARM
|
||||
chromebooks. For ARM targets, you should refer
|
||||
|
|
@ -48,7 +48,7 @@ This is a boon for security, because it's harder
|
|||
to tamper with, and you could potentially write-protect plus maybe provide
|
||||
a [password](grub_hardening.md) in GRUB at boot time.
|
||||
|
||||
The easiest way to use it is like this: in Linux, set up your partitions like
|
||||
The easiest way to use it is like this: in GNU/Linux, set up your partitions like
|
||||
you would, but use LVM volume groups, with group name `grubcrypt` and either:
|
||||
|
||||
* `/` as volume name `rootvol` and `/boot` as volume name `bootvol`
|
||||
|
|
@ -68,7 +68,7 @@ Or on a specific device, e.g.
|
|||
|
||||
cryptomount (ahci0,1)
|
||||
|
||||
This is similar to `cryptsetup luksOpen` in Linux.
|
||||
This is similar to `cryptsetup luksOpen` in GNU/Linux.
|
||||
|
||||
Canoeboot GRUB merges the PHC argon2 implementation, so it has full support
|
||||
for LUKS2 installations in addition to LUKS1. Canoeboot 20231026 and higher
|
||||
|
|
@ -76,7 +76,7 @@ has argon2 support, but older releases only supported PBKDF2 which would make
|
|||
LUKS2 dysfunctional unless you swapped it to use PBKDF2 (not argon2) and/or
|
||||
downgraded to LUKS1.
|
||||
|
||||
With modern Canoeboot, you can just use LUKS2 as-is, on most/all Linux distros.
|
||||
With modern Canoeboot, you can just use LUKS2 as-is, on most/all GNU/Linux distros.
|
||||
At the time of the Canoeboot 20231026 release, the GRUB upstream (on gnu.org)
|
||||
did not have these argon2 patches in its source tree, but Canoeboot merges and
|
||||
maintains them out of tree.
|
||||
|
|
@ -91,7 +91,7 @@ Garret contains information about that:
|
|||
|
||||
Canoeboot's GRUB Argon2id implementation was created by Patrick Steinhardt,
|
||||
who adapted PHC's Argon2 implementation for use in GRUB; Ax33l later added it
|
||||
to Arch Linux AUR for GRUB 2.06, and Nicholas Johnson rebased *that* for
|
||||
to Arch GNU/Linux AUR for GRUB 2.06, and Nicholas Johnson rebased *that* for
|
||||
GRUB 2.12 so that Canoeboot could use it; Canoeboot later inherited it.
|
||||
|
||||
NOTE: You should also read the instructions about about `GRUB_TERMINAL`.
|
||||
|
|
@ -130,7 +130,7 @@ executed from Canoeboot's SeaBIOS payload.
|
|||
Rebooting system in case of freeze
|
||||
----------------------------------
|
||||
|
||||
Linux kernel has a feature to do actions to the system any time, even
|
||||
GNU/Linux kernel has a feature to do actions to the system any time, even
|
||||
with it freezes, this is called a
|
||||
[Magic SysRq keys](https://en.wikipedia.org/wiki/Reisub). You can do these
|
||||
actions with Alt + Sysrq + Command. These are the actions:
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Learn how to install Linux distributions on your Canoeboot system.
|
||||
Learn how to install GNU/Linux distributions on your Canoeboot system.
|
||||
|
|
|
|||
|
|
@ -37,9 +37,9 @@ Canoeboot's build system (called *cbmk*).
|
|||
|
||||
The homepage of Canoeboot says that Canoeboot is a *coreboot distro*, providing
|
||||
the necessary integration of coreboot, payloads and utilities so as to provide
|
||||
releases, much like Linux distros do for your operating system, but here we are
|
||||
releases, much like GNU/Linux distros do for your operating system, but here we are
|
||||
concerned about the *boot firmware* instead. Canoeboot is to coreboot, what
|
||||
Debian is to Linux. It provides easier, more automated configuration and
|
||||
Debian is to GNU/Linux. It provides easier, more automated configuration and
|
||||
installation.
|
||||
|
||||
The build system, cbmk, *is* that coreboot distro, at its very core. You can
|
||||
|
|
@ -89,7 +89,7 @@ This concerns system requirements when *building* Canoeboot.
|
|||
|
||||
### Operating system
|
||||
|
||||
Any sensible Linux distribution will do. Canoeboot's build system is regularly
|
||||
Any sensible GNU/Linux distribution will do. Canoeboot's build system is regularly
|
||||
testing on all the major distros. Please do report bugs if you encounter
|
||||
issues.
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ NOTE: Some patching is also done for non-glibc-based systems, such as
|
|||
Alpine, though we currently do not have an automated way to install
|
||||
build dependencies for these distros.
|
||||
|
||||
NOTE: **Linux** is assumed. BSD systems may work, for parts of the build system,
|
||||
NOTE: **GNU/Linux** is assumed. BSD systems may work, for parts of the build system,
|
||||
but BSD systems are currently not well-tested with cbmk.
|
||||
|
||||
### **Dependencies**
|
||||
|
|
@ -359,7 +359,7 @@ Please also visit: <https://www.gnu.org/software/grub/>
|
|||
The GRUB bootloader, a reference multiboot implementation with its own
|
||||
small kernel/OS and drivers (e.g. file systems, cryptography). This is the
|
||||
default recommended [coreboot payload](https://doc.coreboot.org/payloads.html)
|
||||
on x86-based Canoeboot systems. GRUB will load and execute your Linux kernel,
|
||||
on x86-based Canoeboot systems. GRUB will load and execute your GNU/Linux kernel,
|
||||
which then runs on the bare metal.
|
||||
|
||||
The *utilities* for GRUB are compiled here, and used from here; specifically,
|
||||
|
|
@ -418,7 +418,7 @@ could be used for other machines in the future.
|
|||
Please also visit: <https://www.seabios.org/SeaBIOS>
|
||||
|
||||
This is the PC BIOS implementation used by Canoeboot, on x86 machines (not all
|
||||
of them). A BIOS/UEFI implementation is not required, because Linux and BSD
|
||||
of them). A BIOS/UEFI implementation is not required, because GNU/Linux and BSD
|
||||
kernels can execute on bare metal, but it can nonetheless still be useful; in
|
||||
particular, the BSD bootloaders can be executed from SeaBIOS.
|
||||
|
||||
|
|
@ -689,7 +689,7 @@ other than `default`, which is the default if the option is missing.
|
|||
The `grub_scan_disk` option specifies can be `ahci`, `ata` or `both`, and it
|
||||
determines which types of disks are to be scanned, when the `grub.cfg` file in
|
||||
GRUB payloads tries to automatically find other `grub.cfg` files supplied by
|
||||
your Linux distro. On some machines, setting it to `ata` or `ahci`
|
||||
your GNU/Linux distro. On some machines, setting it to `ata` or `ahci`
|
||||
can improve boot speed by reducing delays; for example, trying to scan `ata0`
|
||||
on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
|
||||
machine it is advisable to set this option to `ahci` (becuse the default HDD
|
||||
|
|
@ -937,7 +937,7 @@ code.
|
|||
|
||||
This defines which modules are inserted into `grub.elf`. These modules can be
|
||||
anything from file systems, small applications/utilities, launchers (e.g.
|
||||
the `linux` command will execute a Linux kernel), you name it.
|
||||
the `linux` command will execute a GNU/Linux kernel), you name it.
|
||||
|
||||
Canoeboot defines only a very conservative set of modules here, so as to reduce
|
||||
the amount of space used in the main boot flash. (GRUB payloads are also
|
||||
|
|
|
|||
|
|
@ -299,7 +299,7 @@ In addition to not using bashisms, commands that cbmk uses must also
|
|||
be portable; where possible, third party projects should be tweaked.
|
||||
|
||||
This is actually something that is currently lacking or otherwise untested
|
||||
in Canoeboot; it's currently assumed that only Linux (specifically Linux)
|
||||
in Canoeboot; it's currently assumed that only GNU/Linux (specifically GNU/Linux)
|
||||
will work, because many of the projects that Canoeboot makes use of will use
|
||||
bashisms, or other GNUisms (e.g. GNU-specific C extensions or GNU Make specific
|
||||
behaviour in Makefiles).
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ using more power) non-stop, which will drain battery life if this is a
|
|||
laptop. If power usage is a concern, then you should not use this.
|
||||
(we're also not sure whether this workaround is appropriate)*
|
||||
|
||||
To disable c-states, do this in Linux:
|
||||
To disable c-states, do this in GNU/Linux:
|
||||
|
||||
```
|
||||
for i in /sys/devices/system/cpu/cpu/cpuidle/state/disable;
|
||||
|
|
|
|||
|
|
@ -1,24 +1,24 @@
|
|||
---
|
||||
title: Installing ArchLinuxARM on a Chromebook with Canoeboot and U-Boot
|
||||
title: Installing ArchGNU/LinuxARM on a Chromebook with Canoeboot and U-Boot
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
The following process should theoretically be applicable to other U-Boot devices and Linux distributions, but the focus here is specifically on ArchLinuxARM.
|
||||
The following process should theoretically be applicable to other U-Boot devices and GNU/Linux distributions, but the focus here is specifically on ArchGNU/LinuxARM.
|
||||
|
||||
Sources used for this guide include the [following guide to install ArchLinuxARM on a RockPro64,](https://jforberg.se/blog/posts/2023-02-19-rockpro64/rockpro64.html)
|
||||
Sources used for this guide include the [following guide to install ArchGNU/LinuxARM on a RockPro64,](https://jforberg.se/blog/posts/2023-02-19-rockpro64/rockpro64.html)
|
||||
|
||||
And the the instructions from the ArchLinuxARM wiki [here](https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa)
|
||||
And the the instructions from the ArchGNU/LinuxARM wiki [here](https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa)
|
||||
(Be aware that there will be overlap in my documentation with these guides, so some of this information will be very close to verbatim.)
|
||||
|
||||
The purpose of this guide is to instruct users on how to install an ArchLinuxARM on an external disk that will boot on a gru_bob chromebook, and optionally on the internal eMMC. Many concepts covered in this guide may be familiar to prospective and veteran Canoeboot users, with the scope being comprehensive.
|
||||
The purpose of this guide is to instruct users on how to install an ArchGNU/LinuxARM on an external disk that will boot on a gru_bob chromebook, and optionally on the internal eMMC. Many concepts covered in this guide may be familiar to prospective and veteran Canoeboot users, with the scope being comprehensive.
|
||||
|
||||
Boot Method
|
||||
-----------
|
||||
|
||||
There are (at least) three methods that can be used to boot into a Linux distribution from u-boot:
|
||||
There are (at least) three methods that can be used to boot into a GNU/Linux distribution from u-boot:
|
||||
1) EFI - common, modern boot method for amd64 architecture machines. This is not distribution-specific, so if you intend to make a portable drive that is compatible across multiple systems, you may have a use case.
|
||||
|
||||
This is an unlikely use-case, so it's a bit odd to use an EFI partition when not using a UEFI system.
|
||||
|
|
@ -45,14 +45,14 @@ prompt 0
|
|||
timeout 50
|
||||
|
||||
label arch
|
||||
menu label Arch Linux ARM
|
||||
menu label Arch GNU/Linux ARM
|
||||
linux /Image
|
||||
initrd /initramfs-linux.img
|
||||
fdt /dtbs/rockchip/rk3399-gru-bob.dtb
|
||||
append root=PARTUUID=$PARTUUID rw console=tty1 console=ttyS2,115200 earlycon rootwait LANG=en_US.UTF-8
|
||||
|
||||
label archfallback
|
||||
menu label Arch Linux ARM (FALLBACK)
|
||||
menu label Arch GNU/Linux ARM (FALLBACK)
|
||||
linux /Image
|
||||
initrd /initramfs-linux-fallback.img
|
||||
fdt /dtbs/rockchip/rk3399-gru-bob.dtb
|
||||
|
|
@ -84,7 +84,7 @@ In the fdisk tui, create two partitions on a Master Boot Record:
|
|||
- set type to fat32 (ext2 is also supported by extlinux I believe, but I used fat32)
|
||||
- create a second partition of up to 15.8GB
|
||||
|
||||
You will find the appropriate options by typing `m` when using the fdisk tui on Linux distros.
|
||||
You will find the appropriate options by typing `m` when using the fdisk tui on GNU/Linux distros.
|
||||
|
||||
Now make the filesystems:
|
||||
|
||||
|
|
@ -115,14 +115,14 @@ Now that we've got an extlinux.conf file, copy it to your /tmp directory, and we
|
|||
|
||||
```
|
||||
cd /tmp
|
||||
curl -LO http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz
|
||||
curl -LO http://os.archlinuxarm.org/os/ArchGNU/LinuxARM-aarch64-latest.tar.gz
|
||||
mkdir root
|
||||
mkdir boot
|
||||
mount /dev/sdX2 root
|
||||
|
||||
mount /dev/sdX1 boot
|
||||
tar -C boot --strip-components=2 -xvf ArchLinuxARM-aarch64-latest.tar.gz ./boot/
|
||||
tar -C root --exclude=./boot -xvf ArchLinuxARM-aarch64-latest.tar.gz
|
||||
tar -C boot --strip-components=2 -xvf ArchGNU/LinuxARM-aarch64-latest.tar.gz ./boot/
|
||||
tar -C root --exclude=./boot -xvf ArchGNU/LinuxARM-aarch64-latest.tar.gz
|
||||
mkdir boot/extlinux
|
||||
cp extlinux.conf boot/extlinux/extlinux.conf
|
||||
sync
|
||||
|
|
@ -130,13 +130,13 @@ umount boot
|
|||
umount root
|
||||
```
|
||||
|
||||
Note the use of ArchLinuxARM-aarch64-latest.tar.gz and not ArchLinuxARM-gru-latest.tar.gz
|
||||
Note the use of ArchGNU/LinuxARM-aarch64-latest.tar.gz and not ArchGNU/LinuxARM-gru-latest.tar.gz
|
||||
|
||||
The current gru build only supports a depthcharge payload and, of course, we're not using depthcharge are we?
|
||||
|
||||
With that, you should now have a (kind of) working boot disk - insert your installation media and boot.
|
||||
|
||||
Extensive testing with ArchLinuxARM-latest release, showed that booting the fallback initramfs image will work, but the main image won't.
|
||||
Extensive testing with ArchGNU/LinuxARM-latest release, showed that booting the fallback initramfs image will work, but the main image won't.
|
||||
If you create an extlinux.conf file with paths to both images - like in the template above - you can select either by number at boot.
|
||||
|
||||
Going Live - Necessary Tweaks
|
||||
|
|
@ -182,7 +182,7 @@ lsblk -o NAME,UUID,FSTYPE,SIZE
|
|||
Final Steps
|
||||
-----------
|
||||
|
||||
At this stage, you now have a fully functional ArchLinuxARM system on an external disk, and are ready to configure your system.
|
||||
At this stage, you now have a fully functional ArchGNU/LinuxARM system on an external disk, and are ready to configure your system.
|
||||
If you intend to install onto the eMMC module, you can make your changes permanent with:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ a payload on x86 machines, both 32- and 64-bit. This is using the excellent work
|
|||
done by Simon Glass and others, on making U-Boot run as a generic x86 coreboot
|
||||
payload. It has several boot methods but the most interesting (in an x86
|
||||
context) is UEFI. U-Boot provides a very sensible UEFI implementation that can
|
||||
reliably boot many Linux and BSD systems.
|
||||
reliably boot many GNU/Linux and BSD systems.
|
||||
|
||||
### Availability
|
||||
|
||||
|
|
@ -60,11 +60,11 @@ If you see error `-2` it's likely that you have tried to boot a USB drive
|
|||
automatically; sometimes you have to do it manually (see the section below
|
||||
about using the bootflow command manually, via `bootflow select`).
|
||||
|
||||
### Boot Linux/BSD installer (USB)
|
||||
### Boot GNU/Linux/BSD installer (USB)
|
||||
|
||||
Just stick your formatted USB stick in. U-Boot should detect it. Sometimes some
|
||||
USB flash drives are broken, because many of them violate specifications and
|
||||
U-Boot doesn't properly hack around that like Linux does (buggy USB mass storage
|
||||
U-Boot doesn't properly hack around that like GNU/Linux does (buggy USB mass storage
|
||||
implementation) - also, xhci suppport is still a bit unstable, on machines that
|
||||
don't have EHCI controllers (e.g. Haswell setups and beyond).
|
||||
|
||||
|
|
@ -91,14 +91,14 @@ select your device. If you see error, perhaps try:
|
|||
Tested operating systems
|
||||
------------------------
|
||||
|
||||
### Linux/BSD
|
||||
### GNU/Linux/BSD
|
||||
|
||||
Arch Linux, Debian Linux and OpenBSD have been tested.
|
||||
Arch GNU/Linux, Debian GNU/Linux and OpenBSD have been tested.
|
||||
|
||||
Some GRUB setups that use the *console* output mode end up using the U-Boot
|
||||
console driver, which is buggy in UEFI GRUB, so menus can get quite messed up
|
||||
indeed; text in the wrong place, countdown timers mangled, etc. E.g. the Arch
|
||||
Linux installer is completely broken, but you can hit enter to boot Linux which
|
||||
GNU/Linux installer is completely broken, but you can hit enter to boot GNU/Linux which
|
||||
then uses KMS and the installed system uses it (and you could install another
|
||||
bootloader in the installed system).
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ If you want real boot security, don't use UEFI. Canoeboot's GRUB payload can
|
|||
be heavily hardened, by following the [GRUB hardening](../linux/grub_hardening.md)
|
||||
guide; this means using the GRUB payload instead of U-Boot.
|
||||
|
||||
UEFI SecureBoot with a Linux UKI could achieve similar results in a security
|
||||
UEFI SecureBoot with a GNU/Linux UKI could achieve similar results in a security
|
||||
sense to Canoeboot's GRUB hardening setup, though the latter is more flexible,
|
||||
albeit not widely used by the mainstream, but it does work (I use it myself!).
|
||||
|
||||
|
|
|
|||
18
site/faq.md
18
site/faq.md
|
|
@ -71,7 +71,7 @@ Loading the option ROM from the PIKE2008 module on either ASUS KCMA-D8
|
|||
or KGPE-D16 causes the system to hang at boot. It's possible to use
|
||||
this in the payload (if you use a linux kernel payload, like linuxboot),
|
||||
or to boot (with SeaGRUB and/or SeaBIOS) from regular SATA and then use
|
||||
it in Linux. The Linux kernel is capable of using the PIKE2008
|
||||
it in GNU/Linux. The GNU/Linux kernel is capable of using the PIKE2008
|
||||
module without loading the option ROM.
|
||||
|
||||
### How to save kernel panic logs on thinkpad laptops?
|
||||
|
|
@ -580,7 +580,7 @@ boot just fine, using the bootloader (GRUB) that is in the flash chip.
|
|||
This also means that even if you remove the HDD or SSD, you'll still
|
||||
have a functioning bootloader installed which could be used to boot a
|
||||
live distribution installer from a USB flash drive. See
|
||||
[Install Linux on Canoeboot](../docs/linux/grub_boot_installer.md)
|
||||
[Install GNU/Linux on Canoeboot](../docs/linux/grub_boot_installer.md)
|
||||
|
||||
Nowadays, other payloads are also provided. If you're using the SeaBIOS payload,
|
||||
then the normal MBR bootsector is used on your HDD or SSD, like you would
|
||||
|
|
@ -678,7 +678,7 @@ is transparent to the user of the drive.
|
|||
HDDs and SSDs are quite complex, and these days contain quite complex
|
||||
hardware which is even capable of running an entire operating system (by
|
||||
this, we mean that the drive itself is capable of running its own
|
||||
embedded OS), even Linux.
|
||||
embedded OS), even GNU/Linux.
|
||||
|
||||
SSDs and HDDs are a special case, since they are persistent storage
|
||||
devices as well as computers.
|
||||
|
|
@ -766,7 +766,7 @@ Other links:
|
|||
It is recommended that you use full disk encryption, on HDDs connected
|
||||
via USB. There are several adapters available online, that allow you to
|
||||
connect SATA HDDs via USB, and Canoeboot is capable of booting from them the
|
||||
normal way. Consult the documentation for your Linux/BSD operating system, so
|
||||
normal way. Consult the documentation for your GNU/Linux/BSD operating system, so
|
||||
that you can know how to install it with *full disk encryption*.
|
||||
|
||||
The current theory (unproven) is that this will at least prevent
|
||||
|
|
@ -841,11 +841,11 @@ as these are generally much safer.
|
|||
Operating Systems
|
||||
-----------------
|
||||
|
||||
### Can I use Linux?
|
||||
### Can I use GNU/Linux?
|
||||
|
||||
Absolutely! It is well-tested in Canoeboot, and highly recommended. See
|
||||
[installing Linux](../docs/linux/grub_boot_installer.md) and
|
||||
[booting Linux](../docs/linux/grub_cbfs.md).
|
||||
[installing GNU/Linux](../docs/linux/grub_boot_installer.md) and
|
||||
[booting GNU/Linux](../docs/linux/grub_cbfs.md).
|
||||
|
||||
Any recent distribution should work, as long as it uses KMS (kernel mode
|
||||
setting) for the graphics.
|
||||
|
|
@ -854,7 +854,7 @@ setting) for the graphics.
|
|||
|
||||
On Fedora, by default the grub.cfg tries to boot linux in 16-bit mode. You
|
||||
just have to modify Fedora's GRUB configuration.
|
||||
Refer to [the Linux page](docs/linux/).
|
||||
Refer to [the GNU/Linux page](docs/linux/).
|
||||
|
||||
### Can I use BSD?
|
||||
|
||||
|
|
@ -881,7 +881,7 @@ you to third parties, used for a variety of purposes such as advertising, but
|
|||
it's quite possible that three-letter agencies may also receive your data if
|
||||
you use Windows.
|
||||
|
||||
For the sake of your freedom, you should never, ever use Windows. Use Linux or
|
||||
For the sake of your freedom, you should never, ever use Windows. Use GNU/Linux or
|
||||
BSD systems, which are well-supported. Anyway:
|
||||
|
||||
[Video of Windows 10 booting up](https://yewtu.be/watch?v=BWq6XnWKQnM)
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ x-toc-enable: true
|
|||
|
||||
Приклад виводу flashprog з обома `CONFIG_STRICT_DEVMEM` та `CONFIG_IO_STRICT_DEVMEM` ввімкненими:
|
||||
```
|
||||
flashprog v0.9.9-r1955 on Linux 4.11.9-1-ARCH (x86_64)
|
||||
flashprog v0.9.9-r1955 on GNU/Linux 4.11.9-1-ARCH (x86_64)
|
||||
flashprog is free software, get the source code at https://flashprog.org
|
||||
|
||||
Calibrating delay loop... OK.
|
||||
|
|
@ -75,7 +75,7 @@ coreboot, тому ми просто використовуємо стандар
|
|||
або KGPE-D16 викликає зависання системи під час завантаження. Можна використовувати
|
||||
це в корисному навантаженні (якщо ви використовуєте корисне навантаження ядра linux, таке як linuxboot),
|
||||
або завантажитись (з SeaGRUB та/або SeaBIOS) зі звичайного SATA, а потім використовувати
|
||||
це в Linux. Ядро Linux здатне використовувати PIKE2008
|
||||
це в GNU/Linux. Ядро GNU/Linux здатне використовувати PIKE2008
|
||||
модуль без завантаження Option ROM.
|
||||
|
||||
### Як зберегти журнали паніки ядра на ноутбуках Thinkpad?
|
||||
|
|
@ -603,7 +603,7 @@ HDD або SSD під час встановлення нового дистри
|
|||
Це означає, що навіть якщо ви виймете жорсткий диск або твердотільний накопичувач, у вас всеодно
|
||||
буде встановлено функціонуючий завантажувач, який можна використовувати для завантаження програми
|
||||
встановлення дистрибутива з флеш-пам'яті USB. Див.
|
||||
[Як інсталювати Linux у системі Canoeboot](../docs/linux/grub_boot_installer.md)
|
||||
[Як інсталювати GNU/Linux у системі Canoeboot](../docs/linux/grub_boot_installer.md)
|
||||
|
||||
В даний час також передбачені інші корисні навантаження. Якщо ви використовуєте корисне навантаження SeaBIOS,
|
||||
тоді на вашому HDD або SSD використовується звичайний завантажувальний сектор MBR, як і слід було
|
||||
|
|
@ -700,7 +700,7 @@ AHCI/SATA), який програмне забезпечення ОС може
|
|||
Жорсткі диски та твердотільні накопичувачі є досить складними, і сьогодні містять досить складне
|
||||
обладнання, яке навіть здатне запускати цілу операційну систему (під цим ми маємо
|
||||
на увазі, що сам диск здатний запускати свою власну вбудовану ОС), навіть
|
||||
Linux або BusyBox/Linux.
|
||||
GNU/Linux або BusyBox/GNU/Linux.
|
||||
|
||||
SSD та HDD є особливим випадком, оскільки вони є постійними пристроями зберігання,
|
||||
а також комп'ютерами.
|
||||
|
|
@ -782,7 +782,7 @@ USB 3.0, який ще не можна використовувати в сво
|
|||
Рекомендовано використовувати повне шифрування диска на жорстких дисках,
|
||||
підключених через USB. У мережі є кілька адаптерів, які дозволяють підключати жорсткі диски
|
||||
SATA через USB, і проект Canoeboot здатний завантажуватись з них
|
||||
звичайним чином. Проконсультуйтесь з документацією для вашої операційної системи Linux/BSD,
|
||||
звичайним чином. Проконсультуйтесь з документацією для вашої операційної системи GNU/Linux/BSD,
|
||||
щоб знати те, як встановити їх з *повнодисковим шифруванням*:
|
||||
|
||||
Поточна теорія (недоведена) полягає в тому, що це принаймні запобіжить
|
||||
|
|
@ -857,11 +857,11 @@ WWAN, підключення до мережі 3g/4g (наприклад, GSM).
|
|||
Операційні системи
|
||||
------------------
|
||||
|
||||
### Чи я можу використовувати Linux?
|
||||
### Чи я можу використовувати GNU/Linux?
|
||||
|
||||
Абсолютно! Він добре перевірений в Canoeboot, та дуже рекомендований. Подивіться
|
||||
[встановлення Linux](../docs/linux/grub_boot_installer.md) та
|
||||
[запуск Linux](../docs/linux/grub_cbfs.md).
|
||||
[встановлення GNU/Linux](../docs/linux/grub_boot_installer.md) та
|
||||
[запуск GNU/Linux](../docs/linux/grub_cbfs.md).
|
||||
|
||||
Будь-який сучасний дистрибутив має працювати, допоки він використовує KMS (kernel mode
|
||||
setting) для графіки.
|
||||
|
|
@ -870,7 +870,7 @@ setting) для графіки.
|
|||
|
||||
У Fedora типово grub.cfg намагається завантажити linux в 16-розрядному режимі.
|
||||
Вам просто потрібно змінити конфігурацію GRUB Fedora.
|
||||
Зверніться до [сторінки Linux](docs/linux/).
|
||||
Зверніться до [сторінки GNU/Linux](docs/linux/).
|
||||
|
||||
### Чи я можу використовувати BSD?
|
||||
|
||||
|
|
@ -897,7 +897,7 @@ you to third parties, used for a variety of purposes such as advertising, but
|
|||
it's quite possible that three-letter agencies may also receive your data if
|
||||
you use Windows.
|
||||
|
||||
For the sake of your freedom, you should never, ever use Windows. Use Linux or
|
||||
For the sake of your freedom, you should never, ever use Windows. Use GNU/Linux or
|
||||
BSD systems, which are well-supported. Anyway:
|
||||
|
||||
[Video of Windows 10 booting up](https://yewtu.be/watch?v=BWq6XnWKQnM)
|
||||
|
|
|
|||
BIN
site/favicon.ico
BIN
site/favicon.ico
Binary file not shown.
|
Before Width: 250px | Height: 250px | Size: 15 KiB After (image error) Size: 15 KiB |
|
|
@ -4,11 +4,11 @@ x-toc-enable: true
|
|||
...
|
||||
|
||||
Canoeboot ist ein [Coreboot-Distribution](docs/maintain/) (coreboot distro),
|
||||
so wie Debian eine Linux-Distribution ist. Das *Canoeboot* Projekt bietet
|
||||
so wie Debian eine GNU/Linux-Distribution ist. Das *Canoeboot* Projekt bietet
|
||||
eine [freie](https://writefreesoftware.org/learn) *Boot
|
||||
Firmware* welche auf [bestimmten Intel/AMD x86 und ARM Geräten](docs/install/#which-systems-are-supported-by-canoeboot)
|
||||
die Hardware initialisiert (z.b. Speicher-Controller, CPU, Peripherie),
|
||||
und dann einen Bootloader für dein Betriebssystem startet. [Linux](docs/linux/)
|
||||
und dann einen Bootloader für dein Betriebssystem startet. [GNU/Linux](docs/linux/)
|
||||
sowie [BSD](docs/bsd/) werden gut unterstützt. Es ersetzt proprietäre BIOS/UEFI
|
||||
Firmware. Hilfe ist verfügbar
|
||||
via [\#canoeboot](https://web.libera.chat/#canoeboot)
|
||||
|
|
@ -22,11 +22,11 @@ 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.
|
||||
The SeaBIOS and GRUB payloads also boot Linux/BSD systems. Which one you use
|
||||
UEFI boot implementation, which can boot many GNU/Linux distros and BSD systems.
|
||||
The SeaBIOS and GRUB payloads also boot GNU/Linux/BSD systems. Which one you use
|
||||
depends on your preferences. Canoeboot's [design](docs/maintain/) incorporates
|
||||
all of these boot methods in a single image, so you can choose which one you use
|
||||
at boot time, and more payloads (e.g. Linux kexec payload) are planned for
|
||||
at boot time, and more payloads (e.g. GNU/Linux kexec payload) are planned for
|
||||
future releases.
|
||||
|
||||
**NEUESTE VERSION: Die neueste Version von Canoeboot ist 20250107, veröffentlicht
|
||||
|
|
@ -73,7 +73,7 @@ Tatsächlich versucht Canoeboot so nah am regulären Coreboot zu bleiben wie mö
|
|||
für jedes Board, aber mit vielen automatisch durch das Canoeboot Build System zur
|
||||
Verfügung gestellten verschiedenen Konfigurationstypen.
|
||||
|
||||
Ebenso wie *Debian* eine *Linux Distribution* ist, ist Canoeboot eine
|
||||
Ebenso wie *Debian* eine *GNU/Linux Distribution* ist, ist Canoeboot eine
|
||||
*Coreboot Distribution*. Sofern Du ein ROM Image von Grund auf herstellen möchtest,
|
||||
musst Du zunächst Konfigurationen auf Experten Level durchführen,
|
||||
und zwar für Coreboot, GRUB sowie sämtliche Software die Du sonst noch verwenden
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ x-toc-enable: true
|
|||
Canoeboot est un micrologiciel de démarrage [libéré](https://writefreesoftware.org/learn)
|
||||
qui initialise le matériel (càd le contrôleur mémoire, CPU,
|
||||
périphériques) sur [des ordinateurs x86/ARM spécifiques](docs/install/#which-systems-are-supported-by-canoeboot)
|
||||
et lance un chargeur d'amorçage pour votre système d'exploitation. [Linux](docs/linux/) et [BSD](docs/bsd/) sont bien supportés. C'est un
|
||||
et lance un chargeur d'amorçage pour votre système d'exploitation. [GNU/Linux](docs/linux/) et [BSD](docs/bsd/) sont bien supportés. C'est un
|
||||
remplacement pour le micrologiciel UEFI/BIOS propriétaire.
|
||||
Des canaux d'aide sont disponibles
|
||||
dans le canal [\#canoeboot](https://web.libera.chat/#canoeboot) sur le serveur IRC [Libera](https://libera.chat/).
|
||||
|
|
@ -19,11 +19,11 @@ 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.
|
||||
The SeaBIOS and GRUB payloads also boot Linux/BSD systems. Which one you use
|
||||
UEFI boot implementation, which can boot many GNU/Linux distros and BSD systems.
|
||||
The SeaBIOS and GRUB payloads also boot GNU/Linux/BSD systems. Which one you use
|
||||
depends on your preferences. Canoeboot's [design](docs/maintain/) incorporates
|
||||
all of these boot methods in a single image, so you can choose which one you use
|
||||
at boot time, and more payloads (e.g. Linux kexec payload) are planned for
|
||||
at boot time, and more payloads (e.g. GNU/Linux kexec payload) are planned for
|
||||
future releases.
|
||||
|
||||
**NOUVELLE VERSION: La dernière version est [Canoeboot 20250107](news/canoeboot20250107.md), sortie
|
||||
|
|
@ -69,7 +69,7 @@ pas de fournir un Coreboot déblobbé; ceci n'est simplement qu'une
|
|||
des politiques de Canoeboot, une importante certes, mais qui n'est qu'un
|
||||
aspect mineur de Canoeboot.
|
||||
|
||||
De la même façon que *Debian* est une distribution Linux, Canoeboot
|
||||
De la même façon que *Debian* est une distribution GNU/Linux, Canoeboot
|
||||
est une *distribution coreboot*. Si vous voulez compilé une image ROM
|
||||
en partant des bases, vous devez alors effectuer une configuration experte
|
||||
de Coreboot, GRUB et n'importe quel autre logiciel dont vous avez besoin
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ grazie al firmware basato su coreboot, sostituendo cosi', firmware BIOS/UEFI pro
|
|||
su [alcune schede madri basate su Intel/AMD x86 o ARM](docs/install/#which-systems-are-supported-by-canoeboot),
|
||||
in computer fissi e portatili. Inizializza l'hardware (controller di
|
||||
memoria, CPU, periferiche) e avvia un bootloader per il tuo sistema operativo.
|
||||
[Linux](docs/linux/) e [BSD](docs/bsd/) sono ben supportati.
|
||||
[GNU/Linux](docs/linux/) e [BSD](docs/bsd/) sono ben supportati.
|
||||
L'aiuto e' disponibile sul canale IRC [\#canoeboot](https://web.libera.chat/#canoeboot)
|
||||
su [Libera](https://libera.chat/).
|
||||
|
||||
|
|
@ -20,11 +20,11 @@ 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.
|
||||
The SeaBIOS and GRUB payloads also boot Linux/BSD systems. Which one you use
|
||||
UEFI boot implementation, which can boot many GNU/Linux distros and BSD systems.
|
||||
The SeaBIOS and GRUB payloads also boot GNU/Linux/BSD systems. Which one you use
|
||||
depends on your preferences. Canoeboot's [design](docs/maintain/) incorporates
|
||||
all of these boot methods in a single image, so you can choose which one you use
|
||||
at boot time, and more payloads (e.g. Linux kexec payload) are planned for
|
||||
at boot time, and more payloads (e.g. GNU/Linux kexec payload) are planned for
|
||||
future releases.
|
||||
|
||||
**ULTIMO RILASCIO: L'ultimo rilascio e' Canoeboot 20250107, rilasciato il 7 January 2025.
|
||||
|
|
@ -70,7 +70,7 @@ In effetti, Canoeboot tenta di essere il piu' possibile simile alla versione *uf
|
|||
per ogni scheda, ma con diversi tipi di configurazione forniti automaticamente dal sistema di
|
||||
compilazione automatico di Canoeboot.
|
||||
|
||||
Esattamente come *Debian* e' una *distribuzione Linux*, Canoeboot e' una
|
||||
Esattamente come *Debian* e' una *distribuzione GNU/Linux*, Canoeboot e' una
|
||||
*distribuzione coreboot*. Per fare un immagine ROM da zero, hai bisogno di esperienza necessaria
|
||||
nel configurare coreboot, GRUB e qualunque altra cosa ti serve. Con *Canoeboot*,
|
||||
che puoi scaricare da Git o da un archivio di codici sorgenti, puoi far partire `make`,
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ x-toc-enable: true
|
|||
...
|
||||
|
||||
*Canoeboot* is a *[coreboot distribution](docs/maintain)* (coreboot distro),
|
||||
in the same way that Debian is a *Linux distribution*. Canoeboot provides
|
||||
in the same way that Debian is a *GNU/Linux distribution*. Canoeboot provides
|
||||
[free, open source](https://writefreesoftware.org/) (*libre*) boot
|
||||
firmware based on coreboot, replacing proprietary BIOS/UEFI firmware
|
||||
on [specific Intel/AMD x86 and ARM based motherboards](docs/install/#which-systems-are-supported-by-canoeboot),
|
||||
including laptop and desktop computers. It initialises the hardware (e.g. memory
|
||||
controller, CPU, peripherals) and starts a bootloader for your operating
|
||||
system. [Linux](docs/linux/) and [BSD](docs/bsd/) are well-supported. Help is
|
||||
system. [GNU/Linux](docs/linux/) and [BSD](docs/bsd/) are well-supported. Help is
|
||||
available via [\#canoeboot](https://web.libera.chat/#canoeboot)
|
||||
on [Libera](https://libera.chat/) IRC.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Canoeboot provides [coreboot](https://coreboot.org/) for [machine
|
|||
initialisation](https://doc.coreboot.org/getting_started/architecture.html),
|
||||
which then jumps to a [payload](https://doc.coreboot.org/payloads.html) in
|
||||
the boot flash; coreboot works with many payloads, which boot your operating
|
||||
system e.g. Linux/BSD.
|
||||
system e.g. GNU/Linux/BSD.
|
||||
|
||||
Canoeboot makes coreboot easy to use for
|
||||
non-technical users, by providing a [fully automated build
|
||||
|
|
@ -92,7 +92,7 @@ the restrictions (not to mention, security issues) imposed on you by proprietary
|
|||
BIOS vendors, then Canoeboot is one possible choice for you. Since it inherits
|
||||
coreboot, it doesn't have any known backdoors in the code, nor does it contain
|
||||
legacy cruft from the 1980s. Canoeboot provides a sleek, fast boot experience
|
||||
for Linux/BSD systems, based on coreboot which is regularly audited and improved.
|
||||
for GNU/Linux/BSD systems, based on coreboot which is regularly audited and improved.
|
||||
|
||||
Canoeboot is more reliable than proprietary firmware. Many people use proprietary
|
||||
(non-libre) boot firmware, even if they use [a libre OS](https://www.openbsd.org/).
|
||||
|
|
@ -127,7 +127,7 @@ In fact, Canoeboot tries to stay as close to *stock* coreboot as possible,
|
|||
for each board, but with many different types of configuration provided
|
||||
automatically by the Canoeboot build system.
|
||||
|
||||
In the same way that *Alpine Linux* is a *Linux distribution*, Canoeboot is
|
||||
In the same way that *Alpine GNU/Linux* is a *GNU/Linux distribution*, Canoeboot is
|
||||
a *coreboot distribution*. If you want to build a ROM image from scratch, you
|
||||
otherwise have to perform expert-level configuration of coreboot, GRUB and
|
||||
whatever other software you need, to prepare the ROM image. With *Canoeboot*,
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Canoeboot is a free/opensource BIOS/UEFI boot firmware distribution based on coreboot with GNU boot loader GRUB, SeaBIOS and U-Boot, for booting Linux/BSD.
|
||||
Canoeboot is a free/opensource BIOS/UEFI boot firmware distribution based on coreboot with GNU boot loader GRUB, SeaBIOS and U-Boot, for booting GNU/Linux/BSD.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ x-toc-enable: true
|
|||
[вільну](https://writefreesoftware.org/learn) *завантажувальну
|
||||
прошивку*, яка ініціалізує апаратне забезпечення (наприклад, контролер пам'яті, ЦП,
|
||||
периферію) на [конкретних цілях Intel/AMD x86 та ARM](docs/install/#which-systems-are-supported-by-canoeboot), що
|
||||
потім розпочинає завантажувач для вашої операційної системи. [Linux](docs/linux/)
|
||||
потім розпочинає завантажувач для вашої операційної системи. [GNU/Linux](docs/linux/)
|
||||
та [BSD](docs/bsd/) добре підтримуються. Це заміняє пропрієтарну BIOS/UEFI
|
||||
прошивку. Допомога доступна
|
||||
через [\#canoeboot](https://web.libera.chat/#canoeboot)
|
||||
|
|
@ -21,11 +21,11 @@ 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.
|
||||
The SeaBIOS and GRUB payloads also boot Linux/BSD systems. Which one you use
|
||||
UEFI boot implementation, which can boot many GNU/Linux distros and BSD systems.
|
||||
The SeaBIOS and GRUB payloads also boot GNU/Linux/BSD systems. Which one you use
|
||||
depends on your preferences. Canoeboot's [design](docs/maintain/) incorporates
|
||||
all of these boot methods in a single image, so you can choose which one you use
|
||||
at boot time, and more payloads (e.g. Linux kexec payload) are planned for
|
||||
at boot time, and more payloads (e.g. GNU/Linux kexec payload) are planned for
|
||||
future releases.
|
||||
|
||||
**НОВИЙ ВИПУСК: Останній випуск Canoeboot 20250107, випущено 7 January 2025.
|
||||
|
|
@ -64,7 +64,7 @@ Coreboot помітно складний для встановлення для
|
|||
|
||||
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.vimuser.org/uboot-canoe.png" /><span class="f"><img src="https://av.vimuser.org/uboot-canoe.png" /></span>
|
||||
|
||||
Таким же самим чином, як *Debian* це дистрибутив Linux, Canoeboot це
|
||||
Таким же самим чином, як *Debian* це дистрибутив GNU/Linux, Canoeboot це
|
||||
*дистрибутив coreboot*. Якщо ви хочете зібрати образ ROM з нуля, вам
|
||||
інакше довелось би виконати налаштування експертного рівня coreboot, GRUB та
|
||||
будь-якого іншого потрібного програмного забезпечення, для підготування образа ROM. З *Canoeboot*,
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: 自由且开源 BIOS/UEFI 固件
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
*Canoeboot* 项目基于 coreboot 提供了[自由且开源](https://writefreesoftware.org/zh-cn/learn/)的引导固件，替代了特定基于 Intel/AMD x86 及 ARM 的主板（包括笔记本和桌面计算机）上的专有 BIOS/UEFI 固件。它首先对硬件（如内存控制器、CPU、外设）进行初始化，然后为操作系统启动 bootloader。本项目对 [Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#canoeboot](https://web.libera.chat/#canoeboot) 频道。
|
||||
*Canoeboot* 项目基于 coreboot 提供了[自由且开源](https://writefreesoftware.org/zh-cn/learn/)的引导固件，替代了特定基于 Intel/AMD x86 及 ARM 的主板（包括笔记本和桌面计算机）上的专有 BIOS/UEFI 固件。它首先对硬件（如内存控制器、CPU、外设）进行初始化，然后为操作系统启动 bootloader。本项目对 [GNU/Linux](docs/linux/) 和 [BSD](docs/bsd/) 支持良好。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#canoeboot](https://web.libera.chat/#canoeboot) 频道。
|
||||
|
||||
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
|
||||
|
||||
|
|
@ -15,11 +15,11 @@ 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.
|
||||
The SeaBIOS and GRUB payloads also boot Linux/BSD systems. Which one you use
|
||||
UEFI boot implementation, which can boot many GNU/Linux distros and BSD systems.
|
||||
The SeaBIOS and GRUB payloads also boot GNU/Linux/BSD systems. Which one you use
|
||||
depends on your preferences. Canoeboot's [design](docs/maintain/) incorporates
|
||||
all of these boot methods in a single image, so you can choose which one you use
|
||||
at boot time, and more payloads (e.g. Linux kexec payload) are planned for
|
||||
at boot time, and more payloads (e.g. GNU/Linux kexec payload) are planned for
|
||||
future releases.
|
||||
|
||||
为什么要使用 *Canoeboot*?
|
||||
|
|
@ -38,7 +38,7 @@ Canoeboot 不是 coreboot 的分支
|
|||
|
||||
事实上，Canoeboot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 Canoeboot 构建系统也自动提供了许多不同类型的配置。
|
||||
|
||||
Canoeboot 是一个 *coreboot 发行版*，就好比 *Debian* 是一个 *Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Canoeboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `cbmk`（Canoeboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
|
||||
Canoeboot 是一个 *coreboot 发行版*，就好比 *Debian* 是一个 *GNU/Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Canoeboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `cbmk`（Canoeboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
|
||||
|
||||
如果你要构建常规的 coreboot，而不使用 Canoeboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
|
||||
|
||||
|
|
|
|||
|
|
@ -18,12 +18,12 @@ this by providing an automated build system to download, patch and compile
|
|||
the various upstream sources (e.g. coreboot, GRUB, SeaBIOS). Coreboot is used
|
||||
for hardware initialisation, configuring everything from your CPU, memory
|
||||
controller all way to peripherals, readying the hardware so that it can run
|
||||
software, e.g. Linux operating systems. You can essentially think of *cbmk*,
|
||||
software, e.g. GNU/Linux operating systems. You can essentially think of *cbmk*,
|
||||
which is Canoeboot's build system, as a *source-based package manager*. It is
|
||||
what the Canoeboot releases are built with. The *cbmk* build system essentially
|
||||
implements
|
||||
a *[coreboot distro](../docs/maintain/)*, the same way you might think of
|
||||
a Linux distribution.
|
||||
a GNU/Linux distribution.
|
||||
|
||||
Extensive auditing has been performed on cbmk, since the Canoeboot 20240504
|
||||
release. These audits fix bugs, reduce code bloat and generally improve the
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@ this by providing an automated build system to download, patch and compile
|
|||
the various upstream sources (e.g. coreboot, GRUB, SeaBIOS). Coreboot is used
|
||||
for hardware initialisation, configuring everything from your CPU, memory
|
||||
controller all way to peripherals, readying the hardware so that it can run
|
||||
software, e.g. Linux and BSD systems. You can essentially think of *cbmk*,
|
||||
software, e.g. GNU/Linux and BSD systems. You can essentially think of *cbmk*,
|
||||
which is Canoeboot's build system, as a *source-based package manager*. It is
|
||||
what the Canoeboot releases are built with. The *cbmk* build system essentially
|
||||
implements a *[coreboot distro](../docs/maintain/)*,
|
||||
the same way you might think of a Linux
|
||||
the same way you might think of a GNU/Linux
|
||||
distribution; it systematically downloads, resets (to specific revisions) and
|
||||
patches various upstream project sources such as coreboot, U-Boot and GRUB,
|
||||
automatically building entire coreboot images. This build system is what creates
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ customisation options compared to most proprietary firmware. As a
|
|||
audited, and coreboot does
|
||||
regularly audit code. The other main benefit is [*freedom* to study, adapt and
|
||||
share the code](https://writefreesoftware.org/), a freedom denied by most boot
|
||||
firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/linux/)
|
||||
firmware, but not Canoeboot! Booting GNU/Linux/BSD is also [well](../docs/linux/)
|
||||
[supported](../docs/bsd/).
|
||||
|
||||
Canoeboot is maintained in parallel with [Libreboot](https://libreboot.org/), and by the same developer,
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ customisation options compared to most proprietary firmware. As a
|
|||
audited, and coreboot does
|
||||
regularly audit code. The other main benefit is [*freedom* to study, adapt and
|
||||
share the code](https://writefreesoftware.org/), a freedom denied by most boot
|
||||
firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/linux/)
|
||||
firmware, but not Canoeboot! Booting GNU/Linux/BSD is also [well](../docs/linux/)
|
||||
[supported](../docs/bsd/).
|
||||
|
||||
Canoeboot is maintained in parallel with Libreboot, and by the same developer,
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ customisation options compared to most proprietary firmware. As a
|
|||
audited, and coreboot does
|
||||
regularly audit code. The other main benefit is [*freedom* to study, adapt and
|
||||
share the code](https://writefreesoftware.org/), a freedom denied by most boot
|
||||
firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/linux/)
|
||||
firmware, but not Canoeboot! Booting GNU/Linux/BSD is also [well](../docs/linux/)
|
||||
[supported](../docs/bsd/).
|
||||
|
||||
Canoeboot is maintained in parallel with [Libreboot](https://libreboot.org/), and by the same developer,
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ customisation options compared to most proprietary firmware. As a
|
|||
audited, and coreboot does regularly audit code. The other main benefit
|
||||
is [*freedom* to study, adapt and
|
||||
share the code](https://writefreesoftware.org/), a freedom denied by most boot
|
||||
firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/linux/)
|
||||
firmware, but not Canoeboot! Booting GNU/Linux/BSD is also [well](../docs/linux/)
|
||||
[supported](../docs/bsd/).
|
||||
|
||||
Work done since last release
|
||||
|
|
|
|||
|
|
@ -10,13 +10,13 @@ Free software BIOS/UEFI
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
in the same way that Debian is a Linux distribution. It provides an automated
|
||||
in the same way that Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing the same type
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing the same type
|
||||
of infrastructure, but for your boot firmware instead of your operating system.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
@ -46,9 +46,9 @@ is being added all the time!
|
|||
|
||||
These and other examples are just the start. Canoeboot provides a *superior* boot
|
||||
experience compared to proprietary BIOS/UEFI, giving you the same power and level of
|
||||
control that a fully free Linux system would afford. It's *your* computer
|
||||
control that a fully free GNU/Linux system would afford. It's *your* computer
|
||||
to boot however you wish. Canoeboot lets you get more out of the hardware. All
|
||||
your favourite Linux distros are compatible, even Qubes(on most machines).
|
||||
your favourite GNU/Linux distros are compatible, even Qubes(on most machines).
|
||||
|
||||
If you're fed up of the control that proprietary UEFI vendors have over you,
|
||||
then Canoeboot is *for you*. Although many would agree that it is a major step
|
||||
|
|
@ -392,7 +392,7 @@ are highlighted in bold:
|
|||
should increase compatibility with distros that use extlinux.
|
||||
* `grub.cfg`: Handle GRUB *and* syslinux/extlinux configs, on the USB boot menu
|
||||
option. Now it scans for both, thus increasing compatibility with many modern
|
||||
Linux distro installers. Before this change, Canoeboot's design was made with
|
||||
GNU/Linux distro installers. Before this change, Canoeboot's design was made with
|
||||
BIOS systems in mind, because we historically only supported systems that were
|
||||
BIOS-based, whereas GRUB is more common as a bootloader on UEFI-based install
|
||||
media, but in the past we mostly assumed isolinux/syslinux for that.
|
||||
|
|
@ -403,7 +403,7 @@ are highlighted in bold:
|
|||
configs are essentially the same. So now Libreboot GRUB automatically scans
|
||||
for GRUB *and* syslinux/extlinux configs by default, including on the ESP.
|
||||
This will increase compatibility with a wide variety of distros, *without*
|
||||
introducing UEFI support yet on x86, because those same Linux kernels can
|
||||
introducing UEFI support yet on x86, because those same GNU/Linux kernels can
|
||||
also run on bare metal (and this is exactly how it works, when you use GRUB
|
||||
as a payload). NOTE: This change probably doesn't benefit Canoeboot much,
|
||||
since none of the supported Canoeboot hardware implements UEFI in factory
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Free software BIOS/UEFI
|
|||
Canoeboot is a [free/libre](https://writefreesoftware.org/) BIOS/UEFI replacement
|
||||
on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
in the same way that Debian is a Linux distribution. It provides an automated
|
||||
in the same way that Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing the same type
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing the same type
|
||||
of infrastructure, but for your boot firmware instead of your operating system.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ Open source BIOS/UEFI firmware
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
in the same way that Debian is a Linux distribution. It provides an automated
|
||||
in the same way that Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing the same type
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing the same type
|
||||
of infrastructure, but for your boot firmware instead of your operating system.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ Open source BIOS/UEFI firmware
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
like how Debian is a Linux distribution. It provides an automated
|
||||
like how Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing a source-based
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing a source-based
|
||||
package manager (called cbmk) which patches sources and compiles coreboot images.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Open source BIOS/UEFI firmware
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
like how Debian is a Linux distribution. It provides an automated
|
||||
like how Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing a source-based
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing a source-based
|
||||
package manager (called cbmk) which patches sources and compiles coreboot images.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
@ -28,7 +28,7 @@ system; on ARM(chromebooks), we provide *U-Boot* (as a coreboot payload).
|
|||
|
||||
For Canoeboot 20241207, today's release, U-Boot is *also* provided as an
|
||||
optional coreboot payload on x86 machines. This provides a sensible UEFI
|
||||
implementation, useful for booting Linux and BSD systems more easily. More
|
||||
implementation, useful for booting GNU/Linux and BSD systems more easily. More
|
||||
information available on the [U-Boot x86 page](../docs/uboot/uboot-x86.md).
|
||||
|
||||
This means that you can have a UEFI boot environment, even on machines where
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Open source BIOS/UEFI firmware
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
like how Debian is a Linux distribution. It provides an automated
|
||||
like how Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing a source-based
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing a source-based
|
||||
package manager (called cbmk) which patches sources and compiles coreboot images.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ Open source BIOS/UEFI firmware
|
|||
|
||||
Canoeboot is a free/libre BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux). It is specifically
|
||||
operating system (e.g. GNU/Linux). It is specifically
|
||||
a *[coreboot distribution](../docs/maintain/)*,
|
||||
like how Debian is a Linux distribution. It provides an automated
|
||||
like how Debian is a GNU/Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing a source-based
|
||||
this works in *exactly* the same way as a GNU/Linux distro, providing a source-based
|
||||
package manager (called cbmk) which patches sources and compiles coreboot images.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
|
|||
|
|
@ -148,8 +148,8 @@ likely to encounter a kernel panic caused by a
|
|||
|
||||
Not including these updates will result in an unstable/undefined state. Intel
|
||||
themselves define which bugs affect which CPUs, and they define workarounds, or
|
||||
provide fixes in microcode. Based on this, software such as the Linux kernel
|
||||
can work around those bugs/quirks. Also, upstream versions of the Linux kernel
|
||||
provide fixes in microcode. Based on this, software such as the GNU/Linux kernel
|
||||
can work around those bugs/quirks. Also, upstream versions of the GNU/Linux kernel
|
||||
can update the microcode at boot time (however, it is recommend still to do it
|
||||
from coreboot, for more stable memory controller initialization or “raminit”).
|
||||
Similar can be said about AMD CPUs.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ What is a coreboot distro?
|
|||
--------------------------
|
||||
|
||||
Canoeboot is a *coreboot distribution* or *coreboot distro*, in the same way
|
||||
that Debian is a *Linux distro*. Its purpose is to provide free/opensource boot
|
||||
that Debian is a *GNU/Linux distro*. Its purpose is to provide free/opensource boot
|
||||
firmware, replacing proprietary BIOS/UEFI firmware, and it
|
||||
supports [many machines](docs/install/#which-systems-are-supported-by-canoeboot).
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ Website: <https://docs.dasharo.com/>
|
|||
|
||||
Git repositories: <https://github.com/dasharo>
|
||||
|
||||
Supports many machines, with a choice of EDK2(UEFI) or Heads(Linuxboot)
|
||||
Supports many machines, with a choice of EDK2(UEFI) or Heads(GNU/Linuxboot)
|
||||
payload in the flash. Some older machines may provide a SeaBIOS payload
|
||||
instead. A lot of work that goes into the upstream coreboot project came
|
||||
from the Dasharo developers.
|
||||
|
|
@ -57,13 +57,13 @@ Website: <https://osresearch.net/>
|
|||
|
||||
Git repositories: <https://github.com/linuxboot/heads>
|
||||
|
||||
Heads provides a LinuxBoot payload using U-Root, and has many advanced features
|
||||
Heads provides a GNU/LinuxBoot payload using U-Root, and has many advanced features
|
||||
such as TPM-based MeasuredBoot. With combined use of a FIDO key, you can easily
|
||||
and more reliably determine whether you boot firmware has been tampered with.
|
||||
|
||||
The Linux-based payload in flash uses kexec to boot another Linux kernel. It
|
||||
The GNU/Linux-based payload in flash uses kexec to boot another GNU/Linux kernel. It
|
||||
provides an easy to use boot menu, highly configurable and supports many
|
||||
Linux distros easily.
|
||||
GNU/Linux distros easily.
|
||||
|
||||
If you're the sort of person who needs full disk encryption and you have a
|
||||
focus on security, Heads is for you. Perfect for use with something like Qubes.
|
||||
|
|
@ -121,7 +121,7 @@ Website: <https://docs.mrchromebox.tech/>
|
|||
Git repositories: <https://github.com/MrChromebox/>
|
||||
|
||||
Provides a tailored EDK2(UEFI) payload on supported *Chromebooks*. You can use
|
||||
this to replace ChromeOS with a regular Linux distro or BSD system - even
|
||||
this to replace ChromeOS with a regular GNU/Linux distro or BSD system - even
|
||||
Windows - if you wish.
|
||||
|
||||
The benefit of using *MrChromebox* is that it provides up to date EDK2, unlike
|
||||
|
|
@ -178,7 +178,7 @@ Soller of System76 maintains this firmware, and the work is regularly
|
|||
upstreamed into the regular coreboot project.
|
||||
|
||||
System76 provides the coreboot firmware, along with EDK2 UEFI payload. It can
|
||||
boot Linux distros, BSD systems and even Windows perfectly.
|
||||
boot GNU/Linux distros, BSD systems and even Windows perfectly.
|
||||
|
||||
Is your distro unlisted?
|
||||
------------------------
|
||||
|
|
@ -288,12 +288,12 @@ SFC most notably provides services to Debian, which is a member:
|
|||
Although SPI does not currently (at this time) sponsor any coreboot or
|
||||
firmware-related projects, several of the projects that it *does* support
|
||||
are critical for Canoeboot development. For example, it also supports the
|
||||
Arch Linux project:
|
||||
Arch GNU/Linux project:
|
||||
|
||||
<https://www.spi-inc.org/projects/archlinux/>
|
||||
|
||||
Canoeboot development, especially build testing, happens largely on computers
|
||||
running Debian Linux and Arch Linux, because these cover a large number of
|
||||
running Debian GNU/Linux and Arch GNU/Linux, because these cover a large number of
|
||||
users; we also test many other distros such as Fedora or Ubuntu.
|
||||
|
||||
Organisations like SPI (and indeed SFC, OSFF) are critical to the general
|
||||
|
|
@ -317,23 +317,23 @@ Here are a few such projects:
|
|||
|
||||
fwupd is essentially a centralised repository of firmware images, that
|
||||
can be used to provide updates for your mainboard. Although not officially
|
||||
supported nor endorsed by the Canoeboot project, many Linux distros make
|
||||
supported nor endorsed by the Canoeboot project, many GNU/Linux distros make
|
||||
use of this to provide UEFI firmware updates for example.
|
||||
|
||||
Canoeboot doesn't use this, due to the many idiosyncrasies of Canoeboot on
|
||||
various motherboards; however, we may use it in a limited capacity, in the
|
||||
future.
|
||||
|
||||
### LinuxBoot
|
||||
### GNU/LinuxBoot
|
||||
|
||||
Website: <https://www.linuxboot.org/>
|
||||
|
||||
LinuxBoot can be provided as a UEFI DXE, or as a U-Boot SPL, coreboot payload
|
||||
or Slim Bootloader Stage 1B, to provide a Linux kernel at boot time, which
|
||||
kexecs into another Linux kernel.
|
||||
GNU/LinuxBoot can be provided as a UEFI DXE, or as a U-Boot SPL, coreboot payload
|
||||
or Slim Bootloader Stage 1B, to provide a GNU/Linux kernel at boot time, which
|
||||
kexecs into another GNU/Linux kernel.
|
||||
|
||||
The benefit of using *Linux* to *boot Linux* is that then the bootloader part
|
||||
of your firmware doesn't need to rewrite every driver, because Linux already
|
||||
The benefit of using *GNU/Linux* to *boot GNU/Linux* is that then the bootloader part
|
||||
of your firmware doesn't need to rewrite every driver, because GNU/Linux already
|
||||
provides excellent drivers, and it also affords you many advanced
|
||||
configuration possibility such as hardened encryption setups with things
|
||||
like Measured Boot, and it could also be used to boot over a network.
|
||||
|
|
@ -342,7 +342,7 @@ like Measured Boot, and it could also be used to boot over a network.
|
|||
|
||||
Website: <https://github.com/openbmc/docs>
|
||||
|
||||
Linux distro for management controllers (BMCs) used on servers,
|
||||
GNU/Linux distro for management controllers (BMCs) used on servers,
|
||||
rack switches and RAID appliances. This provides a remote management
|
||||
feature, most useful (for example) on colocated server hosting.
|
||||
|
||||
|
|
@ -351,7 +351,7 @@ feature, most useful (for example) on colocated server hosting.
|
|||
Website: <https://github.com/oreboot/oreboot>
|
||||
|
||||
Oreboot is a special fork of coreboot, re-written in the Rust programming
|
||||
language, focusing specifically on the *LinuxBoot* payload configuration.
|
||||
language, focusing specifically on the *GNU/LinuxBoot* payload configuration.
|
||||
|
||||
### Trusted Firmware
|
||||
|
||||
|
|
@ -374,8 +374,8 @@ in Canoeboot as a UEFI payload for *coreboot*, but U-Boot can also provide its
|
|||
own boot initialisation independently of coreboot.
|
||||
|
||||
One of the nice features of U-Boot is its *licensing* (GPLv2 for the most part)
|
||||
and similar coding style to Linux; the licensing and technical design means
|
||||
that it's much easier to port existing Linux drivers, when something needs to
|
||||
and similar coding style to GNU/Linux; the licensing and technical design means
|
||||
that it's much easier to port existing GNU/Linux drivers, when something needs to
|
||||
be done in the U-boot project.
|
||||
|
||||
-----------------------------------------
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue