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

Canoeboot 20231026 website 

Signed-off-by: Leah Rowe <leah@libreboot.org>
master 20231026
Leah Rowe 2023-10-26 01:10:41 +01:00
parent b1d84fda49
commit deaec646fe
109 changed files with 6943 additions and 3054 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
site.cfg
View File

@ -1,5 +1,5 @@
TITLE="-T nonGeNUine&nbsp;Boot"
DOMAIN="https://notgnuboot.vimuser.org/"
TITLE="-T Canoeboot"
DOMAIN="https://canoeboot.org/"
BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage
CSS="--css /global.css"
LAZY="y"

286
site/about.md Normal file
View File

@ -0,0 +1,286 @@
---
title: What is Canoeboot?
x-toc-enable: true
...
The main purpose of this article is to describe how the Canoeboot project
operates, why it exists and what it does. Who, what, why and when.
You may also be interested in: [Canoeboot vs GNU Boot](gnuboot.md)
What is Canoeboot?
===================
Canoeboot is free/opensource boot firmware based on Libreboot (which is in turn
based on coreboot), replacing proprietary BIOS/UEFI firmware on select x86/ARM
laptops, desktops and server mainboards. It provides an [automated build
system](docs/maintain/)
for [compiling coreboot ROM images](docs/build/), that are [easy to
install](docs/install/) for non-technical
users. The emphasis is placed upon ease of use, and optional [security
features](docs/gnulinux/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* in the
same way that *Debian* is a Linux distro (that uses the GNU C Library and
coreutils, among other things). 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.
Overview of operation
-------------------
More specifically, Canoeboot is a *fork* of Libreboot, maintained in parallel
as per each Libreboot release. Canoeboot adheres to the [GNU Free System
Distribution Guidelines](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html),
instead of Libreboot's more pragmatic [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html) - and such adherence (to GNU
FSDG) is the main purpose of Canoeboot. It consequently supports far less
hardware than Libreboot, providing a proof of concept showing what Libreboot
would be like if it *didn't* implement such a policy (in opposition to the GNU
one that Canoeboot implements). Libreboot previously adhered to the GNU FSDG
policy, but adopted the *Binary Blob Reduction Policy* in November 2022, in an
effort to increase the number of mainboards that can be supported from coreboot.
Thus, Canoeboot is a representation of the *old* Libreboot project. Coreboot
is nominally free software, but requires binary blobs for certain initialisation
on certain boards; only very few mainboards can boot without them. You can read
about how *Libreboot* handles this (in contrast to Canoeboot which bans all
binary blobs), by reading the Libreboot Freedom Status page:
<https://libreboot.org/freedom-status.html>
Canoeboot was created because there are still a few people who want this sort
of thing, but there weren't any modern, or otherwise high quality
implementations. Thus, I decided to revive the old Libreboot project myself,
forking from my very own project (Libreboot) and calling the new fork Canoeboot.
*I forked my own project.*
Who?
------
Canoeboot is maintained by the same founder, Leah Rowe, who is the founder and
lead developer of both the Libreboot project *and* the Canoeboot project.
Maintaining a project like Canoeboot is both challenging and fun; Canoeboot does
not permit any binary blobs from coreboot, which means that it can only support
a handful of mainboards from coreboot, and sometimes
several [mitigations](https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e)
may be required to stabilise certain functionalities under these conditions.
The project called *[GNU Boot](https://libreboot.org/news/gnuboot.html)* launched
during June 2023, in opposition to Libreboot's new policy as of November 2022;
however, GNU Boot's base Libreboot revision was from around the time of the
Libreboot 20220710 release, so their base was roughly 1 year out of date
compared to Libreboot. Canoeboot was created to directly compete with GNU Boot,
which is lead by different people.
GNU Boot *originally* started as a hostile fork attempt; the FSF tried to steal
the name Libreboot by setting up a Libreboot project at another TLD (instead of
libreboot.org) and claiming to be the real thing, despite the fact that the
real Libreboot project was actively developed, and doing releases. [This
video](https://media.libreplanet.org/u/libreplanet/m/taking-control-over-the-means-of-production-free-software-boot/)
at LibrePlanet 2023, on 19 March 2023, announced the FSF's *Libreboot* project,
which was the *hostile* fork; this was anticipated, so the *real* Libreboot at
libreboot.org made a new release that same day, having prepared for it several
weeks beforehand. This resulted in the *[Libreboot 20230319
release](https://libreboot.org/news/libreboot20230319.html)*, and
started an aggressive counter-coup out-competing them. It succeeded, and the FSF
lost; they renamed their project to GNU Boot, starting from June 2023.
Canoeboot was originally designated as *GNU Boot* unofficially, launching in
the month of July 2023 as a proof of concept based
upon [Libreboot 20230625](https://libreboot.org/news/libreboot20230625.html) to
help the [real GNU Boot](https://libreboot.org/news/gnuboot.html) get up to date
versus Libreboot. GNU Boot's June 2023 revision was nearly 1 year behind on
Libreboot. The unofficial GNU Boot was renamed and re-branded to nonGeNUine Boot
on [21 July 2023](../news/nongenuineboot20230717.html#update-21-july-2023) when
the real GNU Boot sent a legal threat to the Libreboot project (citing trademark
infringement) - an innocent mistake, based on a misunderstanding. The purpose
of the original *unofficial* project was merely to provide a base for the real
GNU Boot project to just use however they wish, but they took it the wrong way.
The logic then was: if there is *going* to be another FSDG distro, continuing
on from the *old* Libreboot policy (based on GNU FSDG), it should at least be
high quality, and released to a high standard, so the unofficial project was
made to show them precisely how the Libreboot project is run, so as to provide
them with inspiration.
GNU FSDG policy is [heavily
misguided](https://libreboot.org/news/policy.html#problems-with-fsdg). Canoeboot
is vastly inferior to Libreboot, but it can at least be developed to a high
standard (within the FSF and GNU dogma); as of 26 October 2023, GNU Boot's build
system and revisions were still largely based on Libreboot 20220710, with very
few meaningful changes; Canoeboot was released on that day (26 Oct 2023), based
on Libreboot 20231021 which is *13 months newer* than Libreboot 20220710; the
[nonGeNUine Boot 20230717 change log](news/nongenuineboot20230717.md) was in
reference to Libreboot 20220710, and the [Canoeboot 20231026 change
log](news/canoeboot20231026.md) is in reference to nonGeNUine Boot 20230717 -
if you combine both change logs, you then more or less have a list of all the
things *Canoeboot 20231026* can do that *GNU Boot* 0.1 RC didn't. It's a lot!
On this day, 26 October 2023, Canoeboot also supported *more boards* than GNU
Boot, namely: Dell Latitude E6400, gru\_bob chromebooks and gru\_kevin
chromebooks. The chromebooks are using ARM-based RK3399 SoCs with a heavily
modified version of U-Boot, developed for Libreboot. GNU Boot still didn't
have bootable U-Boot configurations on that day!
nonGeNUine Boot was renamed to Canoeboot, with the [Canoeboot 20231026
release](../news/canoeboot20231026.md) in October 2023, based
upon [Libreboot 20231021](https://libreboot.org/news/libreboot20231021.html).
Why does Canoeboot exist?
----
On the day of the first Canoeboot release, GNU Boot 0.1 RC was out but not much
different to the state it was in during July 2023, and they had not accepted the
help of the original nonGeNUine Boot project; their 0.1 RC release was essentially
Libreboot 20220710, but with a few build fixes on newer distros, some of which
were created by the unofficial GNU Boot first (e.g. fix KGPE-D16 build errors).
It was decided then that Canoeboot would be created, as an official project in
direct competition with GNU Boot, for fun - the GNU Boot project started in June
2023, in opposition to Libreboot's change of policy. Canoeboot started, with
the desire to provide FSDG-compliant releases based on Libreboot, exactly in
line with GNU Boot policy (adhering to GNU FSDG), while being superior to it.
Libreboot is on the forefront, bringing coreboot to ordinary people, and Canoeboot
follows the same pattern, providing high quality releases in parallel to it.
Canoeboot exists purely *for fun*, to see what is technically possible under GNU
policy. It is a fun technical challenge, nothing more. Every effort is made to
ensure perfect compliance with GNU FSDG criteria. Fun fun!
Libreboot's Binary Blob Reduction Policy is superior, because it allows
more people to use coreboot, thus increasing software freedom overall for more
people, but there is no harm in Canoeboot so long as it does not stifle Libreboot
development; so Canoeboot is only updated after each Libreboot release,
cherry-picking what can be included under Canoeboot policy and done in an
extremely efficient manner.
Release schedule
--------------
The Canoeboot schedule is: whenever a Libreboot release is ready, produce a
new Canoeboot release based on it, when there are enough changes to warrant a
new release.
How releases are engineered
-----------------
It's actually very simple. Here is the method by which Canoeboot releases are
created:
* Take an archive of Libreboot's git repositories (build system, website and
images), at the version that the current Canoeboot release is based on.
* Take the *new* Libreboot release, that is the target for Canoeboot-ising.
* Diff the two revisions in bulk (as-is), by re-initialising Git history in
the old Libreboot revision; then copy `.git/` to the directory containing the
new revision.
* In the directory containing the new revision, commit all of the changes.
* In the directory containing the new revision, run this
command: `git format-patch -n1`
* The resulting `.patch` file will then show all of the changes.
The resulting patch file is then opened up in *Vim*.
In the Canoeboot repository, these changes are then copied over. This is done
by scrolling through the patch file, deciding which changes are worthy. The
policy is to include *all* changes, except those that are not suitable under
FSDG.
*Then* the following is done, for coreboot and u-boot trees *per tree*:
* Take the old revision of a given tree (e.g. `coreboot/default`), and diff it
with the entire source tree on the same tree (e.g. `coreboot/default`) but
on the new revision; then from the diff, get the list of all files that have
been *added* and all of the files that have been *modified* (ignore files that
have been deleted; also keep track of files that have renamed). This can be
done very automatically with Git.
* Based on that, a list of files for scanning is now available. Next,
the `deblob-check` script is executed within that source tree, using that
list as input. For example: `./deblob-check $(cat /path/to/list) > sus.list`
* The resulting `sus.list` file contains all results, and this new list of files
can then be checked. This is checked *manually*, but usually doesn't take very
long (it's never more than a couple hundred files, and it's easy to see within
like 5 seconds whether it's a blob: 500 seconds if it's 100 files).
* Any false positives are ignored, while actual blobs are then added to
the correct file, e.g. `config/coreboot/default/blobs.list`.
* Next, documentation is scanned. The same process is used (track new files,
moved files and changed files), but there is no automation for this. Every
changed/moved/added file must be checked manually. This is to check for any
documentation that recommends or endorses any proprietary code. Whole files
can be deleted in this way; a normal diff can be provided to clean up other
files, under e.g. `config/coreboot/default/patches/` if necessary.
* There may also be cases where a given bit of code is *not a blob*, but still
proprietary, e.g. source code provided with restrictions on usage,
modification or distribution.
Libreboot often contains hundreds of changes per release, so it would be quite
inefficient to cherry-pick individual patches. Therefore, all development is
done in Libreboot exclusively, and Canoeboot is the by-product of that
development, updating every now and then.
The above steps are a general guide, but specific tweaks may also be required
in the build system, for a new release; minor edge cases here and there, that
are different for every release, but they are usually very minor.
The `deblob-check` script is from linux-libre, a GNU fork of Linux that is
de-blobbed, but the same script works on any source tree, except it will flag
all of the false positives on non-Linux source trees; it scans heuristically
for binary blobs.
This is how Canoeboot can provide releases so quickly, based upon each release
of Libreboot. Extensive testing is performed on ROM images compiled under the
Libreboot build system, so the Canoeboot images are also easy to verify, since
a Canoeboot release will always be closely based on a Libreboot release.
This is actually the benefit of Canoeboot, over all other FSDG-derived coreboot
distros, because the other projects do not have as good infrastructure or the
level of resources *or* technical knowledge that Libreboot has. Libreboot
provides high quality releases which are then filtered by order of the protocol
described above, to provide Canoeboot releases.
osboot project
--------------
Prior to 16 November 2022, another project existed called the *osboot project*,
which was also created by Leah. Osboot started as a fork of Libreboot, starting
in early December 2020, with the exact policies and goals of Libreboot as of 16
November 2022. On 16 November 2022, osboot was *shut down* and all code
differences merged back into *Libreboot*, thus creating the osboot/libreboot
merger of 16 November 2022. The osboot project was thus the blueprint for
modern Libreboot.
Prior to the merger, during those almost-2-years, osboot and Libreboot were kept
in sync, but it was much harder; Libreboot was the main project, but under the
old policy, whereas osboot was *adding* new boards and new logic to the build
system. Then later, osboot became main; however, Libreboot was still the
bigger project. At the time *osboot* started, Libreboot had not seen any
releases in five years; osboot forked the old Libreboot build system from 2016
because of a failed re-write of it since 2017; osboot was used in early 2021
to *revive* the Libreboot project, scrapping the re-write and modernising the
classic design that later became [lbmk](https://libreboot.org/docs/maintain/)
(the Canoeboot version is [cbmk](docs/maintain/) and the osboot version was
called *osbmk*).
Removing code is easier than adding it each time, when syncing one project
based on another, but doing it this way was impossible then, so osboot and
Libreboot were maintained in parallel on a *per-patch* basis; the same logic
would be implemented per-patch between the two projects, but this started
becoming much harder to manage over time.
So if osboot was to become the de facto main project, I decided that it should
be osboot that has the most recognition. Therefore, I merged osboot into
Libreboot. I *originally* intended to then maintain an `fsdg` branch within
Libreboot, which would have been equivalent to today's Canoeboot in terms of
policy. However, this too would have become impractical.
So the situation before was: FSDG-only Libreboot, and no osboot. Then it was
Osboot and Libreboot. Then libreboot-only again, but under the Binary Blob
Reduction Policy. Now, today, it is libreboot under the Binary Blob Reduction
Policy and Canoeboot under Libreboot's old Binary Blob *Extermination* Policy
adhering to GNU FSDG. You can read the actual old Libreboot policy (the FSDG
one) in this link:
<https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html>
Conclusion
==========
tl;dr - it's basically [this](https://xkcd.com/419/).

66
site/contact.de.md
View File

@ -3,4 +3,68 @@ title: Kontakt
x-toc-enable: true
...
Nein.
User support
============
IRC oder Reddit werden bevorzugt, sofern Du eine Support Anfrage hast (IRC empfohlen).
Für Informationen bzgl. IRC and Reddit siehe unten.
Entwicklungs Diskussion
======================
Eine Mailing Liste ist für die Zukunft in Planung. Bis dahin, siehe unter
[der Git Seite](git.md) für Informationen wie Du dich an der Entwicklung beteiligen kannst.
Hier finden sich ebenso Anleitungen zum Senden von Patches (via Pull-Requests).
IRC Chatraum
============
IRC ist hauptsächlich der Weg um Kontakt Canoeboot Projekt aufzunehmen. `#canoeboot` auf Libera
IRC.
Webchat:
<https://web.libera.chat/#canoeboot>
Libera ist eines der grössten IRC Netzwerke, welches für Libre Software Projekte verwendet wird.
Mehr Infos gibt es hier: <https://libera.chat/>
Wenn Du dich mit deinem bevorzugten IRC Klienten verbinden möchtest (z.B. weechat or irssi),
anbei die Verbindungsdetails:
* Server: `irc.libera.chat`
* Channel: `#canoeboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
Wir empfehlen, dass Du Port `6697` mit aktivierter TLS Verschlüsselung verwendest.
Es wird empfohlen SASL für die Authentifizierung zu verwenden. Diese Seiten auf der Libera
Website erläutern wie dies funktioniert:
* WeeChat SASL Anleitung: <https://libera.chat/guides/weechat>
* Irssi SASL Anleitung: <https://libera.chat/guides/irssi>
* HexChat SASL Anleitung: <https://libera.chat/guides/hexchat>
Grundsätzlich solltest Du die Dokumentation der von Dir verwendeten IRC Software konsultieren.
Soziale Medien
============
Canoeboot existiert offiziell an vielen Orten.
Mastodon
--------
Gründerin und Haupt-Entwicklerin, Leah Rowe, ist auf Mastodon:
* <https://mas.to/@libreleah>
Leah kann zudem unter dieser eMail kontaktiert werden:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Hauptsächlich verwendet als Support Kanal und für Veröffentlichung von Neuigkeiten:
<https://www.reddit.com/r/canoeboot/>

68
site/contact.md
View File

@ -3,4 +3,70 @@ title: Contact
x-toc-enable: true
...
No.
**TODO: mailing lists, mastodon server and peertube account.**
User support
============
IRC or Reddit are recommended, if you wish to ask for support (IRC recommended).
See below for information about IRC and Reddit.
Development discussion
======================
Mailing lists are planned for the future. For now, see notes
on [the Git page](git.md) for information about how to assist with development.
Instructions are also on that page for sending patches (via pull requests).
IRC chatroom
============
IRC is the main way to contact the Canoeboot project. `#canoeboot` on Libera
IRC.
Webchat:
<https://web.libera.chat/#canoeboot>
Libera is one of the largest IRC networks, used for Libre Software projects.
Find more about them here: <https://libera.chat/>
If you wish to connect using your preferred client (such as weechat or irssi),
the connection info is as follows:
* Server: `irc.libera.chat`
* Channel: `#canoeboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
We recommend that you use port `6697` with TLS encryption enabled.
It is recommend that you use SASL for authentication. These pages on the Libera
website tells you how:
* WeeChat SASL guide: <https://libera.chat/guides/weechat>
* Irssi SASL guide: <https://libera.chat/guides/irssi>
* HexChat SASL guide: <https://libera.chat/guides/hexchat>
In general, you should check the documentation provided by your IRC software.
Social media
============
Canoeboot exists officially on many places.
Mastodon
--------
The founder and lead developer, Leah Rowe, is on Mastodon:
* <https://mas.to/@libreleah>
Leah can also be contacted by this email address:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Mostly used as a support channel, and also for news announcements:
<https://www.reddit.com/r/canoeboot/>

68
site/contact.uk.md
View File

@ -3,4 +3,70 @@ title: Зв'язок
x-toc-enable: true
...
немає
**TODO: списки розсилки, сервер mastodon та обліковий запис peertube.**
Підтримка користувачів
============
IRC або Reddit рекомендовані, якщо ви бажаєте попросити про допомогу (найкраще IRC).
Дивіться інформацію нижче щодо IRC та Reddit.
Обговорення розробки
======================
Списки розсилки плануються на майбутнє. Зараз, подивіться нотатки
на [сторінці Git](git.md) для інформації щодо допомоги з розробкою.
На цій сторінці також знаходяться інструкції по відправці патчів (через pull request'и).
Кімната IRC
============
IRC це головний спосіб зв'язку з проектом Canoeboot. `#canoeboot` на Libera
IRC.
Веб-версія:
<https://web.libera.chat/#canoeboot>
Libera є однією з найбільших мереж IRC, використовуємих для проектів вільного програмного
забезпечення. Знайти про них більше можна тут: <https://libera.chat/>
Якщо ви бажаєте під'єднатися за допомогою вашого улюбленного клієнта (такого як weechat або irssi),
інформація для під'єднання наступна:
* Сервер: `irc.libera.chat`
* Канал: `#canoeboot`
* Порт (TLS): `6697`
* Порт (не TLS): `6667`
Ми радимо вам використовувати порт `6697` з увімкненим TLS шифруванням.
Рекомендовано використовувати SASL для аутентифікації. Ці сторінки на веб-сайті Libera
пояснять вам як:
* Керівництво WeeChat SASL: <https://libera.chat/guides/weechat>
* Керівництво Irssi SASL: <https://libera.chat/guides/irssi>
* Керівництво HexChat SASL: <https://libera.chat/guides/hexchat>
Взагалі, вам варто перевірити документацію, яка передбачена вашою програмою IRC.
Соціальні мережі
============
Canoeboot офіційно існує в багатьох місцях.
Mastodon
--------------------
Засновник та головний розробник, Лія Роу, є в Mastodon:
* <https://mas.to/@libreleah>
Також можливо зв'язатися з Лією за ії електронною адресою:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Найбільше використовується як канал підтримки, та також для оголошення новин:
<https://www.reddit.com/r/canoeboot/>

28
site/docs/bsd/index.md
View File

@ -8,8 +8,8 @@ Guide last updated on 16 November 2022.
NOTE: This guide pertains to x86 hosts, and does not cover supported CrOS/ARM
chromebooks. For ARM targets, you should refer to u-boot documentation.
nonGeNUine Boot is capable of booting many BSD systems. This section mostly documents
the peculiarities of nonGeNUine Boot as it pertains to BSD; you can otherwise refer to
Canoeboot is capable of booting many BSD systems. This section mostly documents
the peculiarities of Canoeboot as it pertains to BSD; you can otherwise refer to
the official documentation for whatever BSD system you would like to use.
Kernel Mode Setting
@ -22,7 +22,7 @@ you read this article.
Boot BSD, using SeaBIOS
=======================
On x86 platforms, nonGeNUine Boot provides the choice of GRUB and/or
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),
@ -42,7 +42,7 @@ OpenBSD and corebootfb
It's still recommended to use SeaBIOS in text mode, but OpenBSD specifically
can work with SeaBIOS booting in a coreboot framebuffer, with SeaVGABIOS. In
nonGeNUine Boot ROM images, this would be SeaBIOS images with `corebootfb` in the
Canoeboot ROM images, this would be SeaBIOS images with `corebootfb` in the
file name.
Make sure to select MBR-style partitioning on the installer, and it will
@ -55,12 +55,12 @@ FreeBSD and corebootfb
----------------------
Assumed broken, so please ensure that you boot with SeaBIOS payload in text
mode (gbmk ROM images with `txtmode` in the file name, not `corebootfb`).
mode (cbmk ROM images with `txtmode` in the file name, not `corebootfb`).
Warnings for X11 users
----------------------
One important peculiarity of most nonGeNUine Boot systems is: VGA mode
One important peculiarity of most Canoeboot systems is: VGA mode
support exists, if booting with corebootfb (coreboot's own framebuffer) and
the SeaVGABIOS option ROM used in the SeaBIOS payload; however, the ability
to switch modes is not present, which means you can't switch to text mode
@ -79,7 +79,7 @@ on most systems, but not on most coreboot systems with native video
initialisation used, due to the quirks already described. If you see any
documentation (in BSD land) pertaining to VESA modes, ignore it entirely;
unless you're using the proprietary VGA ROM for your device, it won't work,
and nonGeNUine Boot doesn't distribute these (instead, coreboot's own video
and Canoeboot doesn't distribute these (instead, coreboot's own video
initialisation is used where possible, or a headless SeaBIOS payload setup
is provided, where you would either run it headless or install a graphics
card).
@ -131,27 +131,27 @@ If you're flashing a ROM for a machine where `seabios_withgrub`
and `seabios_grubfirst` ROMs are available, choose `seabios_withgrub`.
DO NOT USE ROM IMAGES WITH `seabios_grubfirst` IN THE FILE NAME! These were
present in older nonGeNUine Boot releases, and supported in previous revisions
present in older Canoeboot releases, and supported in previous revisions
of the build system, but they did not work for the intended purpose. More
info is written on the [nonGeNUine Boot installation guide](../install/). ROM
info is written on the [Canoeboot installation guide](../install/). ROM
images with `seabios_grubfirst` in the filename will NOT be included in
future nonGeNUine Boot releases.
future Canoeboot releases.
Dubious mention: Tianocore
--------------------------
Tianocore is extremely bloated, and unauditable, so it is not included
in nonGeNUine Boot firmware, but it is the reference UEFI implementation by
in Canoeboot firmware, but it is the reference UEFI implementation by
Intel and contributors. It can boot most BSD systems very well.
More robust ways to provide UEFI services in nonGeNUine Boot are to be investigated.
More robust ways to provide UEFI services in Canoeboot are to be investigated.
Tianocore integration will not be provided officially, in any current or future
releases of nonGeNUine Boot.
releases of Canoeboot.
Desktop users
-------------
Desktop users on nonGeNUine Boot should just install a graphics card,
Desktop users on Canoeboot should just install a graphics card,
and again boot with SeaBIOS in text mode; however, when you do this,
SeaBIOS will execute the VGA option ROM on the card which will provide
early video initialisation instead of coreboot's initialisation, and that

175
site/docs/bsd/index.uk.md Normal file
View File

@ -0,0 +1,175 @@
---
title: Операційні системи BSD
x-toc-enable: true
...
Керівництво було востаннє оновлено 16 листопада 2022 року.
ПРИМІТКА: Це керівництво стосується хостів x86, і не покриває підтримувані CrOS/ARM
chromebook. Для цілей ARM, вам варто звернутись до документації u-boot.
Canoeboot є спроможним завантажити багато систем BSD. Ця секція в основному задокументовує
особливості Canoeboot, які стосуються BSD; ви можете в іншому випадку звернутись до
офіційної документації для будь-якої системи BSD, яку хочете використовувати.
Kernel Mode Setting
===================
Ваша система BSD *мусить* підтримувати Kernel Mode Setting для вашого графічного
пристрою (більшість з них підтримує в ці дні). Причини стануть очевидними, як
ви прочитаєте цю статтю.
Завантажуйте BSD, використовуючи SeaBIOS
=======================
На платформах x86, Canoeboot надає вибір корисного навантаження GRUB та/або
SeaBIOS. GRUB технічно може завантажувати ядра BSD, але код погано
підтримується і є ненадійним для цього сценарію використання; на системах BIOS,
GRUB може завантажити ланцюгом завантажувачі BSD, але bare metal (в якості корисного навантаження coreboot),
GRUB може тільки завантажити ланцюгом інші корисні навантаження coreboot або завантажити ядра Linux/BSD
безпосередньо (але безпосереднє завантаження тільки реально надійне для Linux, в GRUB).
Це рекомендовано, щоб ви завантажувались в текстовому режимі, з SeaBIOS. Ви можете буквально
просто слідкувати офіційним керівництвам встановлення для вашої системи BSD, чи це буде
FreeBSD, OpenBSD або інші.
Якщо ви не плануєте встановлювати Xorg/Wayland, тоді це все, що вам дійсно треба
робити. Наприклад, ви могли би хотіти виконувати сервер headless, у випадку чого ви
мабуть не заперечуєте виконувати текстовий режим весь час.
OpenBSD та corebootfb
----------------------
Досі рекомендовано використовувати SeaBIOS в текстовому режимі, але OpenBSD конкретно
може працювати з завантаженням SeaBIOS в coreboot framebuffer, з SeaVGABIOS. В
Canoeboot образах ROM, це були би образи SeaBIOS з `corebootfb` в
імені файла.
Переконайтесь, щоб вибрати розмітку в стилі MBR у встановлювачі, і він буде
Просто Працювати.
Якщо ви використовуєте корисне навантаження GRUB, але SeaBIOS є доступним в меню завантаження,
ви можете просто вибрати SeaBIOS в сказаному меню, і OpenBSD буде працювати чудово.
FreeBSD та corebootfb
----------------------
Припущений поламаним, тому будь ласка переконайтесь, що ви завантажуєтесь з корисним навантаженням SeaBIOS в текстовому
режимі (lbmk образи ROM з `txtmode` в імені файлу, не `corebootfb`).
Попередження для користувачів X11
----------------------
Одна важлива особливість більшості систем Canoeboot: Підтримка VGA mode
існує, якщо завантажуєтесь з corebootfb (власний framebuffer coreboot) і
option ROM SeaVGABIOS використано в корисному навантаженні SeaBIOS; хоча, можливість
змінювати режими не є присутньою, що означає, що ви не можете перемикнутись на текстовий режим
так само.
Coreboot може розпочатись в framebuffer (corebootfb) або INT10H текстовому режимі, і він залишається
в будь-якому встановленому режимі, допоки KMS використано для зміни режиму. Має
бути відмічено, що coreboot framebuffer це не є VGA mode, але натомість
coreboot реалізує мінімальні драйвери для апаратного забезпечення, яке він підтримує, надаючи
framebuffer безпосередньо в пам'яті, яке програмне забезпечення (таке як GRUB) може просто
використовувати.
Завантажувачі BSD на x86, в BIOS системах, типово очікують запуск текстового
режиму. Це зазвичай можливо встановити консоль на вищі VGA mode,
на більшості систем, але не на більшості систем coreboot з використаною нативною
ініціалізацією відео, в зв'язку з примхами, що вже описано. Якщо ви бачити будь-яку
документацію (на землі BSD), що стосується VESA mode, ігноруйте її повністю;
допоки ви не використовуєте пропрієтарний VGA ROM для вашого пристрою, це не буде працювати,
і Canoeboot не поширює це (натомість, власна ініціалізація відео coreboot
використана там, де можливо, або налаштування headless корисного навантаження SeaBIOS
надано, де ви би або виконували його headless, або встановили графічну
карту).
Тепер, це би інакше значило: відсутність X11/Wayland. Якщо ви запускаєтесь в corebootfb
mode з SeaVGABIOS, ви не отримаєте дисплей в завантажувачах BSD, і якщо ви завантажуєтесь
в текстовому режимі, ви не можете встановити VESA mode з BSD. Тим не менш, ви в удачі:
Щонайменш OpenBSD та FreeBSD (можливо інші) всі мають чудову підтримку KMS
в ці дні; коротко для `Kernel Mode Setting`. Це уникає неефективності
методів BIOS/UEFI, маючи ядро, що встановлює режими безпосередньо. Воно засновано на
драйверах KMS, що проекти BSD портували з ядра Linux. З цим,
ви можете використовувати X11/Wayland в FreeBSD (і просто X11 в OpenBSD, тепер).
Наприклад: в FreeBSD, ви можете встановити `graphics/drm-kmod` в якості пакунка
або з портів, і (для графічних карток Intel) зробіть це:
sysrc kld_list+="i915kms"
Це створює наступний запис в `/etc/rc.conf`:
kld_list="i915kms"
В FreeBSD також рекомендовано, щоб ви перемикнулись на KMS в консолі/TTY;
додайте це до `/boot/loader.conf`, щоб ви могли досі використовувати консоль після завершення
Xorg:
kern.vty=vt
Вам не варто сподіватись на вищезазначену інструкцію (для FreeBSD), тому що точний
крок може змінитись, і це не йде в повні подробиці так само. Зверніться до
документації, наданої вашою системою, щоб знати те, як налаштовується KMS.
ЗАВЖДИ ЧИТАЙТЕ КЕРІВНИЦТВО
----------------------
Всі BSD мають *чудову* документацію; це одна з визначних
характеристик, проти типових дистрибутивів Linux.
Осторонь від цієї примхи в coreboot, що стосується *BIOS* video mode, BSD
в іншому випадку працюють в точності таким чином, як ви би передбачали, і ви можете
прослідувати їх офіційній документації без значної метушні.
Ніяких конкретних або деталізованих керівництв не буде надано тут, оскільки SeaBIOS
справедливо пояснюючий сам за себе; ви можете в іншому випадку посилатись до документації
SeaBIOS.
Якщо ви прошиваєте ROM для машини, де `seabios_withgrub`
та `seabios_grubfirst` ROM є доступними, виберіть `seabios_withgrub`.
НЕ ВИКОРИСТОВУЙТЕ ОБРАЗИ ROM З `seabios_grubfirst` В ІМЕНІ ФАЙЛА! Ці були
присутніми в старіших випусках Canoeboot, і підтримувались в минулих ревізіях
системи побудови, але вони не працювали для передбаченої мети. Більше
інформації написано в [керівництві встановлення Canoeboot](../install/). ROM
образи з `seabios_grubfirst` в імені файла НЕ буде включено в
наступні випуски Canoeboot.
Сумнівна згадка: Tianocore
--------------------------
Tianocore є надзвичайно роздутим, та непридатним для аудіту, тому його не включено
в прошивку Canoeboot, але це реалізація посилання UEFI від
Intel та вкладників. Він можете завантажувати більшість систем BSD дуже добре.
Більш міцним шляхам для надання послуг UEFI в Canoeboot бути дослідженими.
Інтеграція Tianocore не буде надана офіційно, в жодному з поточних або майбутніх
випусків Canoeboot.
Настільні користувачі
-------------
ПРИМІТКА: Ця секція не може бути повністю точною; наприклад, сторінка апаратного забезпечення
про HP Elite 8200 SFF розповідає про використання графічних карток на обох налаштуваннях corebootfb
та txtmode, і здається працюючою добре з SeaBIOS в обох випадках.
Настільні користувачі на Canoeboot мають просто встановити графічну картку,
та знову завантажитись з SeaBIOS в текстовому режимі; тим не менш, коли ви робите це,
SeaBIOS виконає option ROM VGA на карточці, яка надасть
ранню ініціалізацію відео, замість ініціалізації coreboot, і цей
VGA ROM зазвичай буде реалізовувати повні INT10H mode, включаючи можливість
встановлювати режими в BIOS (використовуючи переривання), у випадку чого ви не
маєте хвилюватись про Kernel Mode Setting, але вам варто досі використовувати KMS
в будь-якому випадку.
Причиною використовувати KMS є те, що він більш ефективний. Сервіс INT10H може тільки
бути викликано в Real Mode або Virtual 8086 mode; v8086 є недоступним в
long mode (x86\_64) та перемикання в Real Mode лише для встановлення VGA mode є
надзвичайно дорого, говорячи з точки зору обчислень. Це те, чому сучасні ядра
(Linux та BSD) роблять mode setting самостійно.
Ви можете вивчити більше про режими INT10H text/VGA тут:
<https://en.wikipedia.org/wiki/INT_10H>

316
site/docs/build/index.md vendored
View File

@ -3,25 +3,58 @@ title: Build from source
x-toc-enable: true
...
nonGeNUine Boot's build system is named `gbmk`, short for **G**nu**B**oot**M**a**K**e, and this
WARNING: Flash from bin/, NOT elf/
==================================
**WARNING: When you build a ROM image from the Canoeboot build system, please
ensure that you flash the appropriate ROM image from `bin/`, NOT `elf/`.
The `elf/` coreboot ROMs do not contain payloads. Canoeboot's build system
builds no-payload ROMs under `elf/`, and payloads separately under `elf/`. Then
it copies from `elf/` and inserts payloads from `elf/`, and puts the final ROM
images (containing payloads) in `bin/`. This design is more efficient, and
permits many configurations without needless duplication of work. More info
is available in the [cbmk maintenance manual](../maintain/)**
Introduction
============
Canoeboot's build system is named `cbmk`, short for `CanoeBoot MaKe`, and this
document describes how to use it. With this guide, you can know how to compile
nonGeNUine Boot from the available source code.
This version, if hosted live on the website, assumes that you are using
the `gbmk` git repository, which
canoeboot from the available source code.
The following document describes how `cbmk` works, and how you can make changes
to it: [canoeboot maintenance manual](../maintain/)
Sources
=======
This version, if hosted live on canoeboot.org, assumes that you are using
the `cbmk` git repository, which
you can download using the instructions on [the code review page](../../git.md).
If you're using a release archive of nonGeNUine Boot, please refer to the
documentation included with *that* release. nonGeNUine Boot releases are only intended
as *snapshots*, not for development. For proper development, you should always
be working directly in the nonGeNUine Boot git repository.
A note about documentation (and this page)
------------------------------------------
The following document describes how `gbmk` works, and how you can make changes
to it: [gbmk maintenance manual](../maintain/)
Including Canoeboot 20231025 and newer, *all* releases have `cbwww.git` (the
website) and `cbwww-img.git` (images for the website) archived in the *src* tar
archive for that release; Canoeboot documentation is written in Markdown (pandoc
variant). You can find markdown files and images under `src/www/`
and `src/img/`, respectively.
If you're working with *release* documentation, you don't get the full HTML
files (such as the one you're viewing now, if you're reading *this* page in a
web browser), so either read the Markdown files directly, or compile them to
HTML using the [Untitled Static Site Generator](https://untitled.vimuser.org/)
(which is what the Canoeboot project uses to generate HTML from those files).
NOTE: `av.canoeboot.org` is hardcoded as the domain name where images are
pointed to, in `cbwww.git`, so you will need to replace these references in
your local version, unless you're happy to just continue using those.
Git
===
nonGeNUine Boot's build system uses Git, extensively. You should perform the steps
Canoeboot's build system uses Git, extensively. You should perform the steps
below, *even if you're using a release archive*.
Before you use the build system, please know: the build system itself uses
@ -41,247 +74,102 @@ You may also want to follow more of the steps here:
Python
======
Python2 is unused by gbmk or anything that it pulls down as modules. You
should ensure that the `python` command runs python 3, on your system.
You should ensure that the `python` command runs python 3, on your system.
Python2 is unused by cbmk or anything that it pulls down as modules.
Make
========
If building on Debian/Ubuntu based systems, you can achieve that via:
**G**nu**B**oot**M**a**K**e (gbmk) includes a file called `Makefile`. You can still use
the `gbmk` build system directly, or you can use Make. The `Makefile`
simply runs `gbmk` commands. However, using `gbmk` directly will offer you
much more flexibility; for example, the Makefile currently cannot build single
ROM images (it just builds all of them, for all boards).
sudo apt install python-is-python3
You must ensure that all build dependencies are installed. If you're running
Trisquel 11, you can run this:
On Fedora, you can use the following
sudo make install-dependencies-ubuntu
sudo dnf install python-unversioned-command
One exists specifically for Debian (may also work for trisquel):
How to compile Canoeboot
========================
sudo make install-dependencies-debian
Another exists for Arch (may also work for parabola):
sudo make install-dependencies-arch
Now, simply build the coreboot images like so:
make
This single command will build ROM images for *every* board integrated in
nonGeNUine Boot. If you only wish to build a limited set, you can use `gbmk` directly:
./build boot roms x200_8mb
You can specify more than one argument:
./build boot roms x200_8mb x60
ROM images appear under the newly created `bin/` directory in the build system.
For other commands, simply read the `Makefile` in your favourite text editor.
The `Makefile` is simple, because it merely runs `gbmk` commands, so it's very
easy to know what commands are available by simply reading it.
Standard `clean` command available (cleans all modules except `crossgcc`):
make clean
To clean your `crossgcc` builds:
make crossgcc-clean
To build release archives:
make release
Build without using Make
============================
The `Makefile` is included just for *compatibility*, so that someone who
instictively types `make` will get a result.
Actual development/testing is always done using `gbmk` directly, and this
Actual development/testing is always done using cbmk directly, and this
includes when building from source. Here are some instructions to get you
started:
First, install build dependencies
---------------------------------
nonGeNUine Boot includes a script that automatically installs apt-get dependencies
in Ubuntu 20.04:
Canoeboot includes a script that automatically installs build dependencies
according to the selected linux distro.
The currently supported distros are: Debian/Ubuntu/Linux Mint/Pop!\_OS,
Fedora, Arch Linux/Parabola or Void Linux.
sudo ./build dependencies ubuntu2004
Some examples (run them as root, use use e.g. `sudo`, `doas`):
Separate scripts also exist:
./build dependencies ubuntu
sudo ./build dependencies debian
or
sudo ./build dependencies arch
./build dependencies debian
sudo ./build dependencies void
or
Technically, any GNU+Linux distribution can be used to build nonGeNUine Boot.
./build dependencies fedora38
or
./build dependencies arch
NOTE: In case of Ubuntu 20.04 LTS or derived distros for that specific release,
use the dedicated configuration file:
./build dependencies ubuntu2004
Check: `config/dependencies/` for list of supported distros.
Technically, any Linux distribution can be used to build canoeboot.
However, you will have to write your own script for installing build
dependencies.
**G**nu**B**oot**M**a**K**e (gbmk)
-------------------
Next, build ROM images
----------------------
**G**nu**B**oot**M**a**K**e (gbmk) automatically runs all necessary commands; for
example, `./build payload grub` will automatically run `./build module grub`
if the required utilities for GRUB are not built, to produce payloads.
Canoeboot MaKe (cbmk) automatically runs all necessary commands; for
example, `./build roms` will automatically run `./build grub`
if the required GRUB payload (under `elf/grub/`) does not exist.
As a result, you can now (after installing the correct build dependencies) run
just a single command, from a fresh Git clone, to build the ROM images:
just a single command, from a fresh Git clone, to build all ROM images:
./build boot roms
./build roms all
or even just build specific ROM images, e.g.:
./build boot roms x60
./build roms x60
or get a list of supported build targets:
./build roms list
Or maybe just build payloads?
-----------------------------
If you wish to build payloads, you can also do that. For example:
./build payload grub
./build grub
./build payload seabios
./update trees -b seabios
./build payload u-boot qemu_x86_12mb
./update trees -b u-boot
Previous steps will be performed automatically. However, you can *still* run
individual parts of the build system manually, if you choose. This may be
beneficial when you're making changes, and you wish to test a specific part of
gbmk.
cbmk.
Therefore, if you only want to build ROM images, just do the above. Otherwise,
please continue reading!
Want to modify Canoeboot?
-------------------------
Second, download all of the required software components
--------------------------------------------------------
Check the [cbmk maintenance manual](../maintain/) for guidance. You may for
example want to modify a config, e.g.:
If you didn't simply run `./build boot roms` (with or without extra
arguments), you can still perform the rest of the build process manually. Read
on! You can read about all available scripts in `gbmk` by reading
the [gbmk maintenance manual](../maintain/); gbmk is designed to be modular
which means that each script *can* be used on its own (if that's not true, for
any script, it's a bug that should be fixed).
./update trees -m coreboot x200_8mb
It's as simple as that:
./download all
The above command downloads all modules defined in the nonGeNUine Boot build system.
However, you can download modules individually.
This command shows you the list of available modules:
./download list
Example of downloading an individual module:
./download coreboot
./download seabios
./download grub
./download flashrom
./download u-boot
Third, build all of the modules:
--------------------------------
Building a module means that it needs to have already been downloaded.
Currently, the build system does not automatically do pre-requisite steps
such as this, so you must verify this yourself.
Again, very simple:
./build module all
This builds every module defined in the nonGeNUine Boot build system, but you can
build modules individually.
The following command lists available modules:
./build module list
Example of building specific modules:
./build module grub
./build module seabios
./build module flashrom
Commands are available to *clean* a module, which basically runs make-clean.
You can list these commands:
./build clean list
Clean all modules like so:
./build clean all
Example of cleaning specific modules:
./build clean grub
./build clean cbutils
Fourth, build all of the payloads:
---------------------------------
Very straight forward:
./build payload all
You can list available payloads like so:
./build payload list
Example of building specific payloads:
./build payload grub
./build payload seabios
Each board has its own U-Boot build configuration in `gbmk` under
`resources/u-boot`. To build U-Boot payloads, you need to specify the
target board and maybe a cross compiler for its CPU architecture. These
are handled automatically when building ROM images, but for example:
./build payload u-boot qemu_x86_12mb # on x86 hosts
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
The build-payload command is is a prerequsite for building ROM images.
Fifth, build the ROMs!
----------------------
Run this command:
./build boot roms
Each board has its own configuration in `gbmk` under `resources/coreboot/`
which specifies which payloads are supported.
By default, all ROM images are built, for all boards. If you wish to build just
a specific board, you can specify the board name based on the directory name
for it under `resources/coreboot/`. For example:
./build boot roms x60
Board names, like above, are the same as the directory names for each board,
under `resources/coreboot/` in the build system.
That's it!
If all went well, ROM images should be available to you under bin/
Or perhaps add a new board! The maintenance manual will teach you how the
Canoeboot build system (cbmk) works!

258
site/docs/build/index.uk.md vendored
View File

@ -3,25 +3,42 @@ title: Побудова з джерельного коду
x-toc-enable: true
...
Система побудови nonGeNUine Boot, називається `gbmk`, скорочення від **G**nu**B**oot**M**a**K**e, і цей
WARNING: Flash from bin/, NOT elf/
==================================
TODO: translate this section into ukrainian language
**WARNING: When you build a ROM image from the Canoeboot build system, please
ensure that you flash the appropriate ROM image from `bin/`, NOT `elf/`.
The `elf/` coreboot ROMs do not contain payloads. Canoeboot's build system
builds no-payload ROMs under `elf/`, and payloads separately under `elf/`. Then
it copies from `elf/` and inserts payloads from `elf/`, and puts the final ROM
images (containing payloads) in `bin/`. This design is more efficient, and
permits many configurations without needless duplication of work. More info
is available in the [cbmk maintenance manual](../maintain/)**
Introduction
============
Система побудови canoeboot, називається `cbmk`, скорочення від `CanoeBoot MaKe`, і цей
документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
nonGeNUine Boot з доступного джерельного коду.
Ця версія, якщо розміщена наживо на nonGeNUine Boot, передбачає, що ви використовуєте
сховище git `gbmk`, яке
canoeboot з доступного джерельного коду.
Ця версія, якщо розміщена наживо на canoeboot.org, передбачає, що ви використовуєте
сховище git `cbmk`, яке
ви можете завантажити, використовуючи інструкції на [сторінці огляду коду](../../git.uk.md).
Якщо ви використовуєте архів випуску nonGeNUine Boot, будь ласка, зверніться до
документації, включеної до *того* випуску. Випуски nonGeNUine Boot розраховані тільки,
Якщо ви використовуєте архів випуску canoeboot, будь ласка, зверніться до
документації, включеної до *того* випуску. Випуски canoeboot розраховані тільки,
як *знімки*, не для розробки. Для належної розробки ви маєте завжди
працювати безпосередньо в сховищі git nonGeNUine Boot.
працювати безпосередньо в сховищі git canoeboot.
Наступний документ описує те, як працює `gbmk`, і як ви можете робити зміни
до нього: [керівництво обслуговування nonGeNUine Boot](../maintain/)
Наступний документ описує те, як працює `cbmk`, і як ви можете робити зміни
до нього: [керівництво обслуговування canoeboot](../maintain/)
Git
===
Система побудови nonGeNUine Boot використовує Git, обширно. Ви маєте виконати кроки
Система побудови Canoeboot використовує Git, обширно. Ви маєте виконати кроки
знизу, *навіть, якщо ви використовуєте архів випуску*.
Перед тим, як вам використовувати систему побудови, будь ласка, знайте: система побудови, сама по собі,
@ -41,76 +58,17 @@ Git
Python
======
Python2 не використовується gbmk або будь-чим, що завантажується в якості модулів. Ви
Python2 не використовується cbmk або будь-чим, що завантажується в якості модулів. Ви
маєте переконатись, що команда `python` виконує python 3 на вашій системі.
Make
========
**G**nu**B**oot**M**a**K**e включає файл, який названо `Makefile`. Ви досі можете
використовувати систему побудови `gbmk` безпосередньо, або ви можете використовувати Make. `Makefile`
просто виконує команди `gbmk`. Однак, використання `gbmk` безпосередньо запропонує вам
набагато більше гнучкості; наприклад, Makefile наразі не може побудувати один
образ ROM (він лише будує всі з них, для всіх плат).
Ви мусите переконатись, що всі залежності побудови встановлено. Якщо ви використовуєте
Trisquel або подібний дистрибутив (Debian), можете виконати це:
sudo make install-dependencies-ubuntu
Існує конкретно для Debian/Trisquel:
sudo make install-dependencies-debian
Інша існує для Arch/Parabola:
sudo make install-dependencies-arch
Тепер, просто побудуйте образи coreboot подібним чином:
make
Ця єдина команда побудує образи ROM для *кожної* плати, інтегрованої до
nonGeNUine Boot. Якщо ви тільки хочете побудувати обмежену вибірку, можете використовувати `gbmk` безпосередньо:
./build boot roms x200_8mb
Ви можете вказати більше одного аргумента:
./build boot roms x200_8mb x60
Образи ROM з'явяться під щойно створеною директорією `bin/` в системі побудови.
Для інших команд просто прочитайте `Makefile` в своєму улюбленому текстовому редакторі.
`Makefile` є простим, тому що він виконує виключно команди `gbmk`, таким чином дуже
просто знати те, які команди є в доступності, просто читаючи його.
Стандартна команда `clean` доступна (чистить всі модулі, окрім `crossgcc`):
make clean
Щоб почистити ваші побудови `crossgcc`:
make crossgcc-clean
Для побудови архівів випуску:
make release
Побудова без використання Make
Побудова з джерельного коду
============================
`Makefile` включено лише для *сумісності*, щоб якщо хтось
інстиктивно пише `make`, то було отримано результат.
Фактична розробка/тестування завжди виконується безпосередньо за допомогою `gbmk`, і це також
Фактична розробка/тестування завжди виконується безпосередньо за допомогою `cbmk`, і це також
стосується збирання з джерельного коду. Ось кілька інструкцій, щоб
почати:
Спочатку встановіть залежності побудови
---------------------------------
nonGeNUine Boot включає сценарій, який автоматично встановлює apt-get залежності
canoeboot включає сценарій, який автоматично встановлює apt-get залежності
в Ubuntu 20.04:
sudo ./build dependencies ubuntu2004
@ -123,162 +81,38 @@ nonGeNUine Boot включає сценарій, який автоматично
sudo ./build dependencies void
Технічно, будь-який дистрибутив GNU+Linux може бути використано для побудови nonGeNUine Boot.
Check: `config/dependencies/` for list of supported distros.
Технічно, будь-який дистрибутив Linux може бути використано для побудови canoeboot.
Однак, вам потрібно буде написано свій власний сценарій для встановлення залежностей
побудови.
**G**nu**B**oot**M**a**K**e (gbmk) автоматично виконує всі необхідні команди; наприклад,
`./build payload grub` автоматично виконає `./build module grub`,
Canoeboot Make (cbmk) автоматично виконує всі необхідні команди; наприклад,
`./build roms` автоматично виконає `./build grub`,
якщо затребувані утиліти для GRUB не збудовано, для виготовлення корисних навантажень.
В якості результату, ви тепер можете (після встановлення правильних залежностей побудови) виконати
лише одну команду, з свіжого Git clone, для побудови образів ROM:
./build boot roms
./build roms all
або навіть побудувати конкретні образи ROM, такі як:
./build boot roms x60
./build roms x60
or get a list of supported build targets:
./build roms list
Якщо ви бажаєте побудувати корисні навантаження, можете зробити це. Наприклад:
./build payload grub
./build grub
./build payload seabios
./update trees -b seabios
./build payload u-boot qemu_x86_12mb
./update trees -b u-boot
Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
окремі частини системи побудови власноруч, якщо виберете. Це може бути
вигідно, коли ви робите зміни, та бажаєте протестувати конкретну частину
gbmk.
Отже, якщо ви лише хочете побудувати образи ROM, просто зробіть наведене вище. В іншому випадку,
будь ласка, продовжіть читати!
Друге, завантажити всі програмні компоненти, які вимагаються
--------------------------------------------------------
Якщо ви не виконали просто `./build boot roms` (з або без надлишкових
аргументів), ви все одно можете виконати залишок процесу побудови власноруч. Читайте
далі! Ви можете прочитати про всі доступні сценарії в `gbmk`, читаючи
[керівництво обслуговування nonGeNUine Boot](../maintain/); gbmk розроблено бути модулярним,
що означає те, що кожен сценарій *може* бути використано самостійно (якщо це не є правдою, для
будь-якого сценарія, це є помилкою, яка має бути виправлена).
Це настільки просто, як це:
./download all
Вищезазначена команда завантажує всі модулі, які означено в системі побудови nonGeNUine Boot.
Однак, ви можете завантажити модулі індивідуально.
Ця команда показує вам список доступних модулів:
./download list
Приклад завантаження індивідуального модуля:
./download coreboot
./download seabios
./download grub
./download flashrom
./download u-boot
Третє, побудова кожного з модулів:
--------------------------------
Побудова модуля означає, що він має вже бути завантаженим.
В цей момент, система побудови не виконує автоматично кроки передумови,
такі як цей, тому ви мусите перевірити це власноруч.
Знову, дуже просто:
./build module all
Це будує кожен модуль, означений в системі побудови nonGeNUine Boot, але ви можете
будувати модулі індивідуально.
Наступна команда перелічує доступні модулі:
./build module list
Приклад побудови конкретних модулів:
./build module grub
./build module seabios
./build module flashrom
Команди доступні для *очищення* модуля, які, по суті, виконують make-clean.
Ви можете перелічити ці команди:
./build clean list
Видаліть всі модулі таким чином:
./build clean all
Приклад видалення конкретних модулів:
./build clean grub
./build clean cbutils
Четверте, побудуйте всі корисні навантаження:
---------------------------------
Дуже просто:
./build payload all
Ви можете перелічити доступні корисні навантаження таким чином:
./build payload list
Приклад побудови конкретних корисних навантажень:
./build payload grub
./build payload seabios
Кожна плата має свою власну конфігурацію побудови U-Boot в `gbmk` під
`resources/u-boot`. Для побудови корисних навантажень U-Boot, вам потрібно вказати
цільову плату і мабуть крос-компілятор для її архітектури ЦП. Вони
керуються автоматично під час побудови образів ROM, але для прикладу:
./build payload u-boot qemu_x86_12mb # на хостах x86
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
Команда build-payload є попередньою умовою для побудови образів ROM.
П'яте, побудуйте ROM!
----------------------
Виконайте цю команду:
./build boot roms
Кожна плата має свою власну конфігурацію в `gbmk` під `resources/coreboot/`,
яка вказує, які корисні навантаження підтримуються.
За замовчуванням, всі образи ROM будуються, для всіх плат. Якщо ви бажаєте побудувати лише
конкретну плату, ви можете вказати назву плати, засновану на імені директорії
для неї під `resources/coreboot/`. Наприклад:
./build boot roms x60
Імена плат, як вище, такі самі, як імена директорій для кожної плати,
під `resources/coreboot/` в системі побудови.
Ось так!
Якщо все пройшло добре, образи ROM мають бути доступними вам під bin/
cbmk.

2
site/docs/gnulinux/encryption.md
View File

@ -1,4 +1,4 @@
# Fully Encrypted Boot and Root Partitions with nonGeNUine Boot
# Fully Encrypted Boot and Root Partitions with Canoeboot
The following guide will explain how to create:

29
site/docs/gnulinux/grub_boot_installer.md
View File

@ -9,7 +9,7 @@ This guide assumes that you are using the GRUB bootloader directly.
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 nonGeNUine Boot systems that
This guide explains how to prepare a bootable USB for Canoeboot systems that
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
GNU+Linux distributions, by default).
@ -40,6 +40,13 @@ folder, this is the command we would run:
That's it! You should now be able to boot the installer from your USB drive
(the instructions for doing so will be given later).
## GRUB2 config on external media
Pick the menu option: *Search for GRUB2 configuration on external media*
If the distro installer image has a `grub.cfg` file inside, this menuentry is
scripted to find it. This works well for many distros.
## 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
@ -86,21 +93,9 @@ from [the Debian homepage](https://www.debian.org/), or the Devuan ISO from
Secondly, create a bootable USB drive using the commands in
[#prepare-the-usb-drive-in-linux](#prepare-the-usb-drive-in-linux).
Thirdly, boot the USB and enter these commands in the GRUB terminal
(for 64-bit Intel or AMD):
set root='usb0'
linux /install.amd/vmlinuz
initrd /install.amd/initrd.gz
boot
If you are on a 32-bit system (e.g. some Thinkpad X60's) then you will need to
use these commands (this is also true for 32-bit running on 64-bit machines):
set root='usb0'
linux /install.386/vmlinuz
initrd /install.386/initrd.gz
boot
You can select the option, in the Canoeboot GRUB menu, to load GRUB config
from external media, and that should work just fine. Alternatively, pick one
of the ISOLINUX-related menu options.
## Booting ISOLINUX Images (Automatic Method)
Boot it in GRUB using the `Parse ISOLINUX config (USB)` option. A new menu
@ -158,7 +153,7 @@ to distro. If you did all of that correctly, then it should now be booting your
USB drive in the way that you specified.
## Troubleshooting
Most of these issues occur when using nonGeNUine Boot with coreboot's `text-mode`
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 GNU+Linux
distributions it can be problematic when they are trying to switch to a

100
site/docs/gnulinux/grub_cbfs.md
View File

@ -12,10 +12,10 @@ on *bare metal* as a native coreboot payload and does *not* use BIOS or UEFI
services (but it *can* load and execute SeaBIOS, in addition to any other
coreboot payload, by chainloading it).
In most circumstances, this guide will not benefit you. nonGeNUine Boot's default
In most circumstances, this guide will not benefit you. Canoeboot's default
GRUB configuration file contains scripting logic within it that intelligently
searches for GRUB partitions installed onto a partition on your SSD, HDD or
USB drive installed on your computer. If such a file is found, nonGeNUine Boot's
USB drive installed on your computer. If such a file is found, Canoeboot's
default GRUB configuration is configured to switch automatically to that
configuration. While not perfect, the logic *does* work with most
configurations.
@ -30,70 +30,70 @@ a known state.
Compile flashrom and cbfstool
=============================
nonGeNUine Boot does not currently distribute utilities pre-compiled. It only
Canoeboot does not currently distribute utilities pre-compiled. It only
provides ROM images pre-compiled, where feasible. Therefore, you have to build
the utilities from source.
As for the ROM, there are mainly three methods for obtaining a nonGeNUine Boot ROM
As for the ROM, there are mainly three methods for obtaining a Canoeboot ROM
image:
1. Dump the contents of the the main *boot flash* on your system, which already
has nonGeNUine Boot installed (with GRUB as the default payload). Extract the
has Canoeboot installed (with GRUB as the default payload). Extract the
GRUB configuration from *that* ROM image.
2. Extract it from a nonGeNUine Boot ROM image supplied by the nonGeNUine Boot project, on
the nonGeNUine Boot website or mirrors of the nonGeNUine Boot website.
3. Build the ROM yourself, using the nonGeNUine Boot build system. Instructions for
2. Extract it from a Canoeboot ROM image supplied by the Canoeboot project, on
the Canoeboot website or mirrors of the Canoeboot website.
3. Build the ROM yourself, using the Canoeboot build system. Instructions for
how to do this are covered in the following article:
[How to build nonGeNUine Boot from source](../build/)
[How to build Canoeboot from source](../build/)
In either case, you will use the `cbfstool` supplied in the nonGeNUine Boot build
In either case, you will use the `cbfstool` supplied in the Canoeboot build
system.
This can be found under `coreboot/*/util/cbfstool/` as source code,
where `*` can be any coreboot source code directory for a given mainboard.
The directory named `default` should suffice.
Install the build dependencies. For Ubuntu 20.04 and similar, you can run
the following command in the nonGeNUine Boot build system, from the root directory
of the nonGeNUine Boot Git repository.
the following command in the Canoeboot build system, from the root directory
of the Canoeboot Git repository.
./build dependencies ubuntu2004
Then, download coreboot:
./download coreboot
./update trees -f coreboot
Finally, compile the `cbutils` module:
./build module cbutils
./build grub
Among other things, this will produce a `cbfstool` executable under any of the
subdirectories in `coreboot/` under `util/cbfstool/cbfstool
subdirectories in `src/coreboot/` under `util/cbfstool/cbfstool
For example: `coreboot/default/util/cbfstool/cbfstool`
For example: `src/coreboot/default/util/cbfstool/cbfstool`
The `cbfstool` utility is what you shall use. It is used to manipulate CBFS
(coreboot file system) which is a file system contained within the coreboot
ROM image; as a *coreboot distribution*, nonGeNUine Boot inherits this technology.
ROM image; as a *coreboot distribution*, Canoeboot inherits this technology.
You will also want to build `flashrom` which nonGeNUine Boot recommends for reading
from and/or writing to the boot flash. In the nonGeNUine Boot build system, you can
You will also want to build `flashrom` which Canoeboot recommends for reading
from and/or writing to the boot flash. In the Canoeboot build system, you can
build it by running this command:
./build module flashrom
./update trees -b flashrom
An executable will be available at `flashrom/flashrom` after you have done
An executable will be available at `src/flashrom/flashrom` after you have done
this.
Dump the boot flash
===================
If you wish to modify your *existing* nonGeNUine Boot ROM, which was installed on
If you wish to modify your *existing* Canoeboot ROM, which was installed on
your computer, you can use `flashrom` to acquire it.
Simply run the following, after using nonGeNUine Boot's build system to compile
Simply run the following, after using Canoeboot's build system to compile
flashrom:
sudo ./flashrom/flashrom -p internal -r dump.bin
sudo ./src/flashrom/flashrom -p internal -r dump.bin
If flashrom complains about multiple flash chip definitions, do what it says to
rectify your command and run it again.
@ -117,38 +117,44 @@ machine powered down) and read the contents of the boot flash.
Extract grub.cfg
================
nonGeNUine Boot images that use the GRUB bootloader will have *two* configuration
files in CBFS:
Canoeboot 20231026 or newer
-----------------------------------
* `grub.cfg`
* `grubtest.cfg`
Releases or or after Canoeboot 20231026 contain `grub.cfg` inside GRUB memdisk,
inaccessible directly from CBFS, but the memdisk is inside `grub.elf` which
gets put inside CBFS.
We recommend that you modify `grubtest.cfg` first, and boot. Select the boot
menu option for loading `grubtest.cfg` and verify that your new config works
correctly. If it doesn't, keep modifying `grubtest.cfg` until it does work.
When that it done, copy the changes over to `grub.cfg
An override is possible, on new Canoeboot revisions. If `grub.cfg` is present
in CBFS, Canoeboot's GRUB will use *that* and not the memdisk one; it will not
auto-switch to `grubtest.cfg`, but the test config will be available in the
menu to switch to, if present. This contrasts older behaviour in
Libreboot 20230625.
You can use the following commands to modify the contents of CBFS, where
GRUB's configuration file is concerned (dump.bin is the ROM that you dumped,
or it could refer to the nonGeNUine Boot ROM image that you compiled or otherwise
acquired).
You can find `grub.cfg` under lbmk (for this purpose, it's best to use the
lbmk one, not the release one - unless you're using a release image).
Find it at path (in current lbmk): `config/grub/config/grub.cfg`.
Show the contents of CBFS, in your ROM:
So, you can *add* `grubtest.cfg` as normal, test that, and
then *add* `grub.cfg` once you're happy, and it will override the default.
cbfstool dump.bin print
In Libreboot 20230625 and older, GRUB memdisk always loaded the config from
CBFS, which you would have to replace; this meant it was possible to brick
your GRUB installation if you accidentally flashed without `grub.cfg`. In
Canoeboot 20231026 and higher, such error is impossible; this behaviour is
also present in Libreboot 20231021, upon which Canoeboot 20231026 is based.
Extract `grub.cfg` (substitude with `grubtest.cfg` as desired):
cbfstool dump.bin extract -n grub.cfg -f grub.cfg
You will now have a file named `grub.cfg`.
Make your desired modifications. You should then delete the old `grub.cfg`
from your ROM image.
This new behaviour is therefore much safer, under user error. However, it's
still possible to flash a bad `grub.cfg` by misconfiguring it, which is why
you should add `grubtest.cfg` first; when present, it will be available in
the default menu, for testing, but the GRUB memdisk config will always be used
first if no `grub.cfg` (as opposed to `grubtest.cfg`) exists in CBFS.
Insert new grub.cfg
===================
You can find the default config under `config/grub/config/grub.cfg` in the
Canoeboot build system,
Remove the old `grub.cfg` (substitute with `grubtest.cfg` as desired):
cbfstool dump.bin remove -n grub.cfg
@ -160,7 +166,7 @@ Add your modified `grub.cfg` (substitute with `grubtest.cfg` as desired):
Flash the modified ROM image
============================
Your modified `dump.bin` or other modified nonGeNUine Boot ROM can then be re-flashed
Your modified `dump.bin` or other modified Canoeboot ROM can then be re-flashed
using:
sudo ./flashrom -p internal -w dump.bin

59
site/docs/gnulinux/grub_hardening.md
View File

@ -5,21 +5,21 @@ x-toc-enable: true
This article only applies to those people who use the GRUB bootloader as
their default payload (options besides GRUB are also available in
nonGeNUine Boot). Whenever this article refers to GRUB, or configuration files
Canoeboot). Whenever this article refers to GRUB, or configuration files
used in GRUB, it is referring exclusively to those files hosted in CBFS
(coreboot file system) in the nonGeNUine Boot ROM image. In this configuration,
(coreboot file system) in the Canoeboot ROM image. In this configuration,
GRUB is running on *bare metal* as a coreboot payload (instead of relying on
BIOS or UEFI services, like it does on *most* x86 based configurations).
This guide deals with various ways in which you can harden your GRUB
configuration, for security purposes. These steps are optional, but *strongly*
recommended by the nonGeNUine Boot project.
recommended by the Canoeboot project.
GRUB provides *many* advanced security features, which most people don't
know about but are fully documented on the nonGeNUine Boot website. Read on!
know about but are fully documented on the Canoeboot website. Read on!
This article doesn't cover how to dump your ROM, or flash a new one. Please
read other sections in the nonGeNUine Boot documentation if you don't know how to do
read other sections in the Canoeboot documentation if you don't know how to do
that. As such, this is an *expert only* guide. There is a great possibility for
bricking your system if you follow this guide incorrectly, or otherwise don't
know what you're doing.
@ -31,8 +31,8 @@ GRUB contains code, based on [GPG](https://gnupg.org/), that can verify
PGP signatures on *any* type of file, on any storage medium supported by
GRUB (it supports basically everything, including CBFS which is short
for coreboot file system and it is what we will focus on in this article).
We will be using this functionality to verify the signature of a GNU+Linux kernel,
at boot time. In conjunction with reproducible builds (both nonGeNUine Boot and your
We will be using this functionality to verify the signature of a Linux kernel,
at boot time. In conjunction with reproducible builds (both Canoeboot and your
GNU+Linux kernel), this can greatly improve system security; Debian is an excellent
example of a project striving towards this goal; see:
<https://wiki.debian.org/ReproducibleBuilds>
@ -49,9 +49,9 @@ repository). More information about reproducible builds can be found here:
<https://reproducible-builds.org/>
Reproducibility is a key goal of the nonGeNUine Boot project, though it has not yet
Reproducibility is a key goal of the Canoeboot project, though it has not yet
achieved that goal. However, it is an important part of any secure system. We
suggest that, when securing your nonGeNUine Boot system as instructed by this guide,
suggest that, when securing your Canoeboot system as instructed by this guide,
you should also use a reproducible GNU+Linux distribution (because checking GPG
signatures on a non-reproducible binary, such as a GNU+Linux kernel, is meaningless
if that binary can be compromised as a result of literally not being able to
@ -63,7 +63,7 @@ they gave you. Based on these facts, we can observe that checking GPG
signatures will improve your *operational* security, but only in specific
circumstances under *controlled conditions*.
This tutorial assumes you have a nonGeNUine Boot image (ROM) that you wish to modify,
This tutorial assumes you have a Canoeboot image (ROM) that you wish to modify,
which from now on we will refer to simply as *`my.rom`*. It should go without
saying that this ROM uses the GRUB bootloader as payload. This page shows
how to modify grubtest.cfg, which means that signing and password protection
@ -72,31 +72,28 @@ incorrect configuration will be impossible. After you are satisfied with the
new setup, you should transfer the new settings to grub.cfg to make your
machine truly secure.
First, extract the old grubtest.cfg and remove it from the nonGeNUine Boot
First, extract the old grubtest.cfg and remove it from the Canoeboot
image:
cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
cbfstool my.rom remove -n grubtest.cfg
You can build `cbfstool` in the nonGeNUine Boot build system. Run this command:
You can build `cbfstool` in the Canoeboot build system. Run this command:
./build module cbutils
./update trees -b coreboot utils
This assumes that you already downloaded coreboot:
./download coreboot
./update trees -f coreboot
This, in turn, assumes that you have installed the build dependencies for
nonGeNUine Boot. On Ubuntu 20.04 and other apt-get distros, you can do this:
Canoeboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
./build dependencies ubuntu2004
NOTE: This script also works with *Trisquel 11*, which is based on
Ubuntu 20.04.
The `cbfstool` executables will be under each coreboot directory, under
each `coreboot/boardname/` directory for each board. Just pick one, presumably
from the coreboot directory for your board. nonGeNUine Boot creates multiple coreboot
from the coreboot directory for your board. Canoeboot creates multiple coreboot
archives for different board revisions, on different boards.
References:
@ -155,15 +152,15 @@ done using the `grub-mkpasswd-pbkdf2` utility. You can get it by
installing GRUB version 2. Generate a key by giving it a password:
NOTE: This utility is included under the `grub/` directory, when you build
GRUB using the nonGeNUine Boot build system. Run the following commands (assuming
GRUB using the Canoeboot build system. Run the following commands (assuming
you have the correct build dependencies installed) to build GRUB, from the
nonGeNUine Boot Git repository:
Canoeboot Git repository:
./download grub
./update trees -f grub
./build module grub
./build grub
The following executable will then be available under the `grub/` directory:
The following executable will then be available under the `src/grub/` directory:
grub-mkpasswd-pbkdf2
@ -188,7 +185,7 @@ computer. NOTE: An attacker could still open your system and re-flash new
firmware externally. You should implement some detection mechanism, such as
epoxy applied in a *random pattern* on every screw; this slows down the attack
and means that you will know someone tampered with it because they cannot
easily re-produce the exact same blob of epoxy in the same pattern (when you
easily re-produce the exact same glob of epoxy in the same pattern (when you
apply it, swirl it around a bit for a few minutes while it cures. The purpose
is not to prevent disassembly, but to slow it down and make it detectable when
it has occured).
@ -201,7 +198,7 @@ function try\_user\_config:
function try_user_config {
set root="${1}"
for dir in boot grub grub2 boot/grub boot/grub2; do
for name in '' autoboot_ nongenuineboot_ coreboot_; do
for name in '' autoboot_ canoeboot_ coreboot_; do
if [ -f /"${dir}"/"${name}"grub.cfg ]; then
#unset superusers
configfile /"${dir}"/"${name}"grub.cfg
@ -213,9 +210,9 @@ function try_user_config {
The `unset superusers` command disables password authentication, which will
allow the attacker to boot an arbitrary operating system, regardless of
signature checking. The default nonGeNUine Boot configuration is tweaked for *easy of
signature checking. The default Canoeboot configuration is tweaked for *easy of
use* by end users, and it is *not* done with security in mind (though security
is preferred). Thus, nonGeNUine Boot is less restrictive by default. What you are
is preferred). Thus, Canoeboot is less restrictive by default. What you are
doing, per this article, is making your system *more secure* but at the expense
of user-friendliness.
@ -247,13 +244,13 @@ Now that we have a key, we can sign some files with it. We must sign:
but, afterwards, `grubtest.cfg` is not signed and it will not load.
Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `nongenuineboot_grub.cfg`. We will sign them by running the following
on-disk `canoeboot_grub.cfg`. We will sign them by running the following
commands:
```
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign nongenuineboot_grub.cfg
gpg --homedir keys --detach-sign canoeboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
```
@ -266,7 +263,7 @@ trust (cbfsdisk)/boot.key
set check_signatures=enforce
```
What remains now is to include the modifications into the nonGeNUine Boot image
What remains now is to include the modifications into the Canoeboot image
(ROM):
```

98
site/docs/gnulinux/index.md
View File

@ -11,7 +11,7 @@ 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>
GNU+Linux is generally assumed, especially for nonGeNUine Boot development, but nonGeNUine Boot
GNU+Linux is generally assumed, especially for Canoeboot development, but Canoeboot
also works quite nicely with [BSD systems](../bsd/).
Useful links
@ -19,10 +19,96 @@ Useful links
Refer to the following pages:
* [How to Prepare and Boot a USB Installer in nonGeNUine Boot Systems](grub_boot_installer.md)
* [Modifying the GRUB Configuration in nonGeNUine Boot Systems](grub_cbfs.md)
* [How to Prepare and Boot a USB Installer in Canoeboot Systems](grub_boot_installer.md)
* [Modifying the GRUB Configuration in Canoeboot Systems](grub_cbfs.md)
* [How to Harden Your GRUB Configuration, for Security](grub_hardening.md)
NOTE ABOUT VGA MODES and GRUB
=============================
Canoeboot does not support switching VGA modes, when coreboot's libgfxinit is
used on Intel GPUs. Many distros will install GRUB, which Canoeboot then finds
and executes, if running SeaBIOS payload; if using GRUB, just the distro's
grub.cfg file is loaded instead, by Canoeboot's own GRUB in flash.
Canoeboot GRUB boots in text mode or uses the coreboot framebuffer. Anyway,
set `GRUB_TERMINAL=console` in GRUB and you should be fine. This avoids GRUB,
the one provided by your distro, switching video modes.
In Debian for example (steps largely the same on other distros):
Edit `/etc/default/grub` as root, and uncomment or add the line:
GRUB_TERMINAL=console
Then still as root, do these commands:
export PATH="$PATH:/sbin"
update-grub
Now your distro's GRUB menu should work, when your distro's GRUB bootloader is
executed from Canoeboot's SeaBIOS payload.
Encrypted /boot via LUKS2 with argon2
=======================================
Full encryption for basic LUKS2 (with PBKDF or argon2 key derivation) is
supported in Canoeboot. Legacy LUKS1 is also supported. On *most* other
systems, `/boot` must be unencrypted, but Canoeboot supports use of the
GRUB bootloader as a coreboot payload, directly in the boot flash.
GRUB has code in it that can be used to unlock LUKS1 and LUKS2 dm-crypt,
using the `cryptomount` command. With this, you can boot with *true* full
disk encryption, by encrypting `/boot`.
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
you would, but use LVM volume groups, with group name `grubcrypt` and either:
* `/` as volume name `rootvol` and `/boot` as volume name `bootvol`
* `/` as volume name `rootvol` and `/boot` exists within it (no `bootvol`)
If your distro then installs GRUB, and provides a `grub.cfg` file
under `/boot/grub` (within the distro, on your SSD/HDD file system), it should
work. Canoeboot's GRUB will automatically give you a passphrase prompt, where
you type your passphrase and it unlocks the volume. Then it will find your
LVMs and it'll boot from that.
Otherwise, to manually unlock it, you drop to the GRUB shell with C and do:
cryptomount -a
Or on a specific device, e.g.
cryptomount (ahci0,1)
This is similar to `cryptsetup luksOpen` in Linux.
Canoeboot GRUB merges the PHC argon2 implementation, so it has full support
for LUKS2 installations in addition to LUKS1. Canoeboot 20231021 and higher
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.
At the time of the Canoeboot 20231021 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.
argon2id
--------
You should *specifically* use argon2id. Please ensure this, because some
older LUKS2 setups defaulted to the weaker *argon2i*. This post by Matthew
Garret contains information about that:
<https://mjg59.dreamwidth.org/66429.html>
NOTE: You should also read the instructions about about `GRUB_TERMINAL`.
Encrypted (LUKS/dm-crypt) installations
=======================================
@ -31,12 +117,12 @@ encryption, at least if you want to use GNU+Linux, because then it'll have
perfect LUKS support.
GRUB otherwise has good filesystem support, so if you have a valid `grub.cfg`
in `/boot/grub` on your installed system, nonGeNUine Boot's GRUB configuration has
in `/boot/grub` on your installed system, Canoeboot's GRUB configuration has
logic in it that will try to automatically use whatever you have installed,
by switching to it. In this way, most installations Just Work, so long as
the `/boot` partition is accessible.
Full encryption for basic LUKS2 is supported in nonGeNUine Boot.
Full encryption for basic LUKS2 is supported in Canoeboot.
See [the guide](encryption.md) for more detail.
Rebooting system in case of freeze
@ -66,7 +152,7 @@ This may also apply to CentOS or Redhat. Chroot guide can be found on
linux16 issue
-------------
nonGeNUine Boot's default GRUB config sources fedora's grub config
Canoeboot's default GRUB config sources fedora's grub config
`grub.cfg` (in `/boot/grub2/grub.cfg`), fedora by default makes use of the
`linux16` command, where it should be saying `linux`

20
site/docs/grub/index.md
View File

@ -7,11 +7,11 @@ TODO: this guide should be reviewed and updated. Some info might be out of
date.
GNU GRUB already has excellent
documentation, but there are aspects of nonGeNUine Boot that deserve special
treatment. nonGeNUine Boot provides the option to boot GRUB directly, running on
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).
[The GNU+Linux section](../gnulinux/) also has nongenuineboot-specific guides for
[The GNU+Linux section](../gnulinux/) 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/)
@ -23,7 +23,7 @@ It is possible to use *any* keymap in GRUB.
Custom keyboard layout
----------------------
Keymaps are stored in `resources/grub/keymap/`
Keymaps are stored in `config/grub/keymap/`
You can use the `ckbcomp` program to generate a keymap, based on Xorg keymap
files:
@ -33,20 +33,20 @@ files:
When you build GRUB from source, you can use the `grub-mklayout` program to
create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
When you've built GRUB, using `gbmk` (nonGeNUine Boot build system), take your kepmap
When you've built GRUB, using `cbmk` (Canoeboot build system), take your kepmap
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
cat frazerty | ./grub/grub-mklayout -o frazerty.gkb
Place the newly created `.gkb` file under `resources/grub/keymap` in gbmk. When
you build nonGeNUine Boot, a ROM image with GRUB payload and your newly created
Place the newly created `.gkb` file under `config/grub/keymap` in cbmk. When
you build Canoeboot, a ROM image with GRUB payload and your newly created
keymap will be available under the `bin/` directory.
[Learn how to build nonGeNUine Boot ROM images](../build/)
[Learn how to build Canoeboot ROM images](../build/)
Many keymaps exist in the nonGeNUine Boot build system, but sometimes you must
Many keymaps exist in the Canoeboot build system, but sometimes you must
manually tweak the file created by `ckbcomp`, adjusting the scan codes in that
file, before converting to a GRUB keymap file. Therefore, it would be unwise to
automatically add all keymaps in GRUB.
If you've added a keymap to gbmk, and it works,
If you've added a keymap to cbmk, and it works,
[please submit a patch!](../../git.md)

4
site/docs/hardware/acer_g43t-am3.md
View File

@ -4,8 +4,8 @@ x-toc-enable: true
...
This is similar to Gigabyte GA-G41M-ES2L but uses an Intel NIC rather than
Realtek. Some problems with GNU+Linux on this NIC, on this board, with nonGeNUine Boot,
were observed; see (NOTE: Libreboot issue tracker, not nonGeNUine Boot):
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>

2
site/docs/hardware/d510mo.md
View File

@ -48,7 +48,7 @@ P*: Partially works with blobs
</div>
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by nonGeNUine Boot.
for quite a nifty desktop. Powered by Canoeboot.
NOTE: D410PT is another name and it's the same board. Flash the exact same
ROM and it should work.

32
site/docs/hardware/d945gclf.md
View File

@ -9,7 +9,7 @@ this mainboard.**
<div class="specs">
<center>
<img tabindex=1 alt="D945GCLF" class="p" src="https://avgnu.vimuser.org/d945gclf/d945gclf.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/d945gclf/d945gclf.jpg" /></span>
<img tabindex=1 alt="D945GCLF" class="p" src="https://av.canoeboot.org/d945gclf/d945gclf.jpg" /><span class="f"><img src="https://av.canoeboot.org/d945gclf/d945gclf.jpg" /></span>
</center>
| ***Specifications*** | |
@ -62,7 +62,7 @@ Introduction
This board is a mini-itx desktop board for 2008. It uses an atom 230,
which is a singe core CPU but it is hyperthreaded so it appears to have
2 thread to the OS. The flash chip is very small, 512KiB, so grub2 does
not fit, which is why nonGeNUine Boot has to use seabios on this target. Full
not fit, which is why Canoeboot has to use seabios on this target. Full
disk encryption like on other supported targets will not be possible, so
plan accordingly.
@ -85,19 +85,19 @@ Remarks about vendor bios:
- Without a coreboot firmware this board is completely useless, since the
vendor bios is very bad. It cannot boot from any HDD whether it is
connected to the SATA port or USB. With nonGeNUine Boot, it works just
connected to the SATA port or USB. With Canoeboot, it works just
fine.
- The vendor bios write protects the flash so it requires external
flashing to install nonGeNUine Boot on this device. Once nonGeNUine Boot is
flashing to install Canoeboot on this device. Once Canoeboot is
flashed there is no problem to update the firmware internally
Here is an image of the board:\
![](https://avgnu.vimuser.org/d945gclf/d945gclf.jpg)\
![](https://av.canoeboot.org/d945gclf/d945gclf.jpg)\
Here is an image of the D945GCLF2 board:\
![](https://avgnu.vimuser.org/d945gclf/20160923_141521.jpg){width="80%" height="80%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141521.jpg){width="80%" height="80%"}\
And SPI SOIC8 flash chip\
![](https://avgnu.vimuser.org/d945gclf/20160923_141550.jpg){width="50%" height="50%"}
![](https://av.canoeboot.org/d945gclf/20160923_141550.jpg){width="50%" height="50%"}
How to replace thermal paste and fan
------------------------------------
@ -105,24 +105,24 @@ How to replace thermal paste and fan
This board comes with very crappy disposable loud fan, that one has no
bearings, which can not be repaired or oiled properly, do not waste your
time trying to fix it, just buy one chinese same size fan\
![](https://avgnu.vimuser.org/d945gclf/20160923_141620.jpg){width="50%" height="50%"}
![](https://avgnu.vimuser.org/d945gclf/20160923_141614.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141620.jpg){width="50%" height="50%"}
![](https://av.canoeboot.org/d945gclf/20160923_141614.jpg){width="50%" height="50%"}\
Make sure that new one has same wiring\
![](https://avgnu.vimuser.org/d945gclf/20160923_142618.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_142618.jpg){width="50%" height="50%"}\
This is a new one, with bearing and maintenable\
![](https://avgnu.vimuser.org/d945gclf/20160923_141738.jpg){width="50%" height="50%"}
![](https://avgnu.vimuser.org/d945gclf/20160923_141814.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141738.jpg){width="50%" height="50%"}
![](https://av.canoeboot.org/d945gclf/20160923_141814.jpg){width="50%" height="50%"}\
Now remove the both coolers rotating them a bit, slowly, then clean both
silicons and both coolers (removing cmos battery first is recommended)\
![](https://avgnu.vimuser.org/d945gclf/20160923_141601.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141601.jpg){width="50%" height="50%"}\
Put a little bit of non conductive thermal paste on both silicons (only
cpu silicon iis shown on that image)\
![](https://avgnu.vimuser.org/d945gclf/20160923_142031.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_142031.jpg){width="50%" height="50%"}\
Before assembling new fan, some need new longer screws, make sure having
these (on the left is original one, too short for new fan)\
![](https://avgnu.vimuser.org/d945gclf/20160923_141659.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141659.jpg){width="50%" height="50%"}\
After that, assemble your new fan into CPU cooler\
![](https://avgnu.vimuser.org/d945gclf/20160923_141635.jpg){width="50%" height="50%"}\
![](https://av.canoeboot.org/d945gclf/20160923_141635.jpg){width="50%" height="50%"}\
Finally assemle both coolers on both chips, do not forget put in the CPU
fan connector back, and you are done.

46
site/docs/hardware/e6400.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
<div class="specs">
<center>
<img tabindex=1 alt="Dell Latitude E6400" class="p" src="https://avgnu.vimuser.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/e6400/e6400-seabios.jpg" /></span> <img tabindex=1 alt="Dell Latitude E6400 XFR" class="p" style="max-width:24em" src="https://avgnu.vimuser.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/e6400/e6400xfr-seabios.jpg" /></span>
<img tabindex=1 alt="Dell Latitude E6400" class="p" src="https://av.canoeboot.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://av.canoeboot.org/e6400/e6400-seabios.jpg" /></span> <img tabindex=1 alt="Dell Latitude E6400 XFR" class="p" style="max-width:24em" src="https://av.canoeboot.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://av.canoeboot.org/e6400/e6400xfr-seabios.jpg" /></span>
</center>
| ***Specifications*** | |
@ -14,10 +14,10 @@ x-toc-enable: true
| **Name** | Latitude E6400 |
| **Variants** | E6400, E6400 XFR and E6400 ATG are supported |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45(Intel GPU) |
| **CPU** | Intel Core 2 Duo (Penryn family). A Quad-core
mod exists, replacing the Core 2 Duo with a Core Quad |
| **Graphics** | Intel GMA 4500MHD |
| **Chipset** | Intel Cantiga GM45(Intel GPU)/PM45(Nvidia GPU) |
| **CPU** | Intel Core 2 Duo (Penryn family). |
| **Graphics** | Intel GMA 4500MHD (and NVidia Quadro NVS 160M
on some models) |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | 2 or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
@ -39,7 +39,7 @@ P*: Partially works with blobs
| ***Features*** | |
|---------------------------------------------------|----|
| **Internal flashing with original boot firmware** | W+ |
| **Display (Intel GPU)** | W+ |
| **Display (if Intel GPU)** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
@ -47,27 +47,27 @@ P*: Partially works with blobs
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **GRUB** | FAIL |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
| **SeaBIOS with GRUB** | FAIL |
</div>
Introduction
============
Known supported variants: E6400, E6400 XFR and E6400 ATG.
Known supported variants: E6400, E6400 XFR and E6400 ATG. Only the *Intel*
graphics models are supported; the ones with Nvidia graphics are not compatible
with Canoeboot.
ONLY the Intel GPU variants are supported, at present. The Nvidia ones are
not compatible, with this version of nonGeNUine Boot.
**To install nonGeNUine Boot, see: [E6400 installation
**To install Canoeboot, see: [E6400 installation
instructions](../install/e6400.md)**
ROM images for Dell Latitude E6400 are available for flashing in nonGeNUine Boot
releases, or you can compile a ROM image for installation via
gbmk, see: [build instructions](../build/)
ROM images for Dell Latitude E6400 are available for flashing in the Canoeboot
release 20230423 onwards, or you can compile a ROM image for installation via
cbmk, see: [build instructions](../build/)
There are two possible flash chip sizes for the E6400: 4MiB (32Mbit) or 2+4MiB
(16Mbit+32MBit). nonGeNUine Boot presently supports the 4MiB version, and provides
(16Mbit+32MBit). Canoeboot presently supports the 4MiB version, and provides
8MiB images for those who upgrade their flash to 8MiB or 16MiB. There appears
to be several possible mainboard PCBs for the E6400, which we believe mostly
affects the GPU configuration and the number of available SPI flash footprints:
@ -90,27 +90,25 @@ functionality, though this configuration has not yet been encountered.
Most people will want to use the 4MiB images.
Intel GPU: Blob-free setup (no-ME possible)
Intel GPU: 100% Free Software is possible
---------------
This is a GM45/PM45 platform, so completely libre initialisation in
coreboot is possible, provided by default in nonGeNUine Boot.
Intel GPU variants are GM45, and Nvidia ones are PM45.
coreboot is possible, provided by default in Canoeboot.
Management Engine (ME) firmware removed
-------------------------
This port in nonGeNUine Boot makes use of `ich9gen` from ich9utils, which
This port in Canoeboot made use of `ich9gen` from ich9utils, which
you can read about in the [ich9utils manual](../install/ich9utils.md) - this
creates a no-ME setup. The Intel Management Engine firmware (ME) is completely
removed, and the ME disabled, just like on ThinkPad X200, T400 and so on.
*The E6400 laptops may come with the ME (and sometimes AMT in addition) before
flashing nonGeNUine Boot. Dell also sold configurations with the ME completely
flashing canoeboot. Dell also sold configurations with the ME completely
disabled, identifiable by a yellow sticker reading "3 ME Disabled" inside the
bottom panel. This config sets the MeDisable bit in the IFD and sets the ME
region almost entirely to 1's, with the occasional 32-bit value (likely not
executable). nonGeNUine Boot disables and removes it by using a modified descriptor:
executable). Canoeboot disables and removes it by using a modified descriptor:
see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)

18
site/docs/hardware/ga-g41m-es2l.md
View File

@ -49,11 +49,11 @@ P*: Partially works with blobs
</div>
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by nonGeNUine Boot.
for quite a nifty desktop. Powered by Canoeboot.
In recent nonGeNUine Boot releases, only SeaBIOS payload is provided in ROMs
In recent Canoeboot releases, only SeaBIOS payload is provided in ROMs
for this board. According to user reports, they work quite well. GRUB was
always buggy on this board, so it was removed from gbmk.
always buggy on this board, so it was removed from cbmk.
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
@ -67,22 +67,22 @@ hwaddress ether macaddressgoeshere
Alternatively:
cbfstool nongenuineboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
cbfstool canoeboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
Modify the MAC address in the file `rt8168-macaddress` and then:
cbfstool nongenuineboot.rom remove -n rt8168-macaddress
cbfstool nongenuineboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
cbfstool canoeboot.rom remove -n rt8168-macaddress
cbfstool canoeboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
Now you have a different MAC address hardcoded. In the above example, the ROM
image is named `nongenuineboot.rom` for your board. You can find cbfstool
image is named `canoeboot.rom` for your board. You can find cbfstool
under `coreboot/default/util/cbfstool/` after running the following command
in the build system:
./build module cbutils
You can learn more about using the build system, gbmk, here:\
[nonGeNUine Boot build instructions](../build/)
You can learn more about using the build system, cbmk, here:\
[Canoeboot build instructions](../build/)
Flashing instructions can be found at
[../install/](../install/)

2
site/docs/hardware/imac52.md
View File

@ -47,7 +47,7 @@ P*: Partially works with blobs
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Information to be written soon, but this board is merged in nonGeNUine Boot.
Information to be written soon, but this board is merged in Canoeboot.
This board is very similar to the [MacBook2,1](./macbook21.md).

20
site/docs/hardware/index.md
View File

@ -3,7 +3,7 @@ title: Hardware compatibility list
x-toc-enable: true
...
This sections relates to known hardware compatibility in nonGeNUine Boot.
This sections relates to known hardware compatibility in Canoeboot.
For installation instructions, refer to [../install/](../install/).
@ -12,12 +12,12 @@ because coreboot lacks native video initialization for the ATI GPUs on these
machines.
(for later machines like T500, T400, ATI GPU doesn't matter, because it also
has an Intel GPU, and nonGeNUine Boot uses the Intel one)
has an Intel GPU, and Canoeboot uses the Intel one)
Supported hardware
==================
nonGeNUine Boot currently supports the following systems:
Canoeboot currently supports the following systems:
### Servers (AMD, Intel, x86)
@ -58,15 +58,7 @@ nonGeNUine Boot currently supports the following systems:
- [Qemu x86](../misc/emulation.md)
- [Qemu arm64](../misc/emulation.md)
## Removed boards
These boards were in nonGeNUine Boot, but have been removed with the intention of
re-adding them at a later date. They were removed due to issues. List:
- [ASUS Chromebook C201PA (veyron-speedy)](../install/c201.md)
- [Intel D945GCLF](d945gclf.md) (removed from gbmk, TODO: re-add support)
TODO: More hardware is supported. See `resources/coreboot/` in gbmk. Update
TODO: More hardware is supported. See `config/coreboot/` in cbmk. Update
the above list!
'Supported' means that the build scripts know how to build ROM images
@ -79,7 +71,7 @@ EC update on i945 (X60, T60) and GM45 (X200, X301, T400, T500, R400, W500, R500)
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
nonGeNUine Boot, so we don't actually provide that, but if you still have
Canoeboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -87,7 +79,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running nonGeNUine Boot is unknown. nonGeNUine Boot
update the EC firmware while running Canoeboot is unknown. Canoeboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery

90
site/docs/hardware/index.zh-cn.md Normal file
View File

@ -0,0 +1,90 @@
---
title: 兼容硬件列表
x-toc-enable: true
...
这一部分说明了 canoeboot 已知兼容的硬件。
安装指南，请参看 [../install/](../install/)。
注意：对 T60/R60 thinkpad 而言，请确认它拥有的是 Intel GPU 而非 ATI GUI，因为 coreboot 对这些机器缺少 ATI GPU 的原生图像初始化。
（对 T500、T400 等后续机器而言，有 ATI GPU 也没问题，因为它也有 Intel GPU，而 canoeboot 会用 Intel 的）
已支持的硬件
==================
该版本的 canoeboot 目前支持以下机器：
### 服务器（AMD，x86）
- [ASUS KFSN4-DRE 主板](kfsn4-dre.md)
- [ASUS KGPE-D16 主板](kgpe-d16.md)
### Desktops (AMD, Intel, x86)
- [Acer G43T-AM3](acer_g43t-am3.md)
- [Apple iMac 5,2](imac52.md)
- [ASUS KCMA-D8 主板](kcma-d8.md)
- [Gigabyte GA-G41M-ES2L 主板](ga-g41m-es2l.md)
- [Intel D510MO 及 D410PT 主板](d510mo.md)
### 笔记本（Intel，x86）
- [Apple MacBook1,1 及 MacBook2,1](macbook21.md)
- [Dell Latitude E6400, E6400 XFR 及 E6400 ATG，皆支持 Nvidia 或 Intel GPU](e6400.md) **（刷入简单，无需拆解，硬件类似 X200/T400）**
- [Lenovo ThinkPad R400](r400.md)
- [Lenovo ThinkPad R500](r500.md)
- [Lenovo ThinkPad T400 / T400S](t400.md)
- [Lenovo ThinkPad T500](t500.md)
- Lenovo ThinkPad T60（Intel GPU 款）
- [Lenovo ThinkPad W500](t500.md)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](x200.md)
- Lenovo ThinkPad X301
- Lenovo ThinkPad X60 / X60S / X60 Tablet
### 笔记本（ARM，配 U-Boot payload）
- [ASUS Chromebook Flip C101 (gru-bob)](../install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../install/chromebooks.md)
### 模拟
- [Qemu x86](../misc/emulation.md)
- [Qemu arm64](../misc/emulation.md)
计划：支持更多硬件。见 cbmk 中的 `config/coreboot/`。更新上面的列表！
所谓“支持”，即指构建脚本知道如何构建这些机器的 ROM 镜像，并且机器经过测试（确认能够工作）。也可能会有例外；换言之，这是“官方”支持的机器列表。
在 i945（X60、T60）及 GM45（X200、X301、T400、T500、R400、W500、R500）上更新 EC
==============================================================
建议更新到最新 EC 固件版本。[EC 固件](../../faq.md#ec-embedded-controller-firmware) 与 canoeboot 是独立的，所以我们实际上并不会提供这些固件，但如果你仍还有 Lenovo BIOS，那你可以直接运行 Lenovo BIOS 更新工具，它会同时更新 BIOS 和 EC 版本。见：
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
注意：只有在运行 Lenovo BIOS 的时候，你才能这样做。如何在运行 canoeboot 的时候更新 EC 固件尚不清楚。canoeboot 只会替换 BIOS 固件，而不会替换 EC。
更新的 EC 固件有一些好处，例如电池管理更加好。
如何得知你的 EC 版本（i945/GM45）
------------------------------------------------
在 Linux，你可以试试这条命令：
grep 'at EC' /proc/asound/cards
输出样例：
ThinkPad Console Audio Control at EC reg 0x30, fw 7WHT19WW-3.6
7WHT19WW 另一种形式的版本号，使用搜索引擎来找出正常的版本号——这个例子中的 x200 tablet，版本号是 1.06。
或者，如果能用 `dmidecode`，则（以 `root`）运行以下命令，来得知目前刷入的 BIOS 版本：
dmidecode -s bios-version
运行最新 BIOS 的 T400 上，它的输出结果为 `7UET94WW (3.24 )`。

24
site/docs/hardware/kcma-d8.md
View File

@ -16,9 +16,9 @@ CPU cores).
This is a desktop board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
nonGeNUine Boot also supports it. The coreboot port was done by Timothy Pearson of
Canoeboot also supports it. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them, merged into *Libreboot* many
years ago (and inherited by nonGeNUine Boot).
years ago (and inherited by Canoeboot).
Note that not all boards are compatible. See [board status](#boardstatus)
below to determine compatibility with your board.
@ -26,7 +26,7 @@ below to determine compatibility with your board.
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 nonGeNUine Boot or coreboot, by default
currently installed. If you already have Canoeboot or coreboot, by default
it is possible to re-flash using software running in GNU+Linux on the kcma-d8,
without using external hardware.
@ -42,11 +42,11 @@ chip and re-flash it using external hardware.
It has a 25XX NOR flash (SPI protocol) in a P-DIP 8 socket, which looks like
this:
![](https://avgnu.vimuser.org/dip8/dip8.jpg)
![](https://av.canoeboot.org/dip8/dip8.jpg)
The default chip is a 2MiB one, but we recommend upgrading it to a 16MiB chip.
NOTE: If you're already running nonGeNUine Boot, you probably don't
NOTE: If you're already running Canoeboot, you probably don't
need to re-flash externally. Refer instead to the generic instructions on
this page: [../install/](../install/)
@ -56,9 +56,9 @@ Refer to the following guide:\
PCI option ROMs
===============
Unlike Libreboot 20160907, nonGeNUine Boot in newer releases now supports finding and
Unlike Libreboot 20160907, Canoeboot in newer releases now supports finding and
loading PCI option ROMs automatically, both in GRUB and SeaBIOS on this machine.
This was inherited by nonGeNUine Boot, when the Libreboot project was forked.
This was inherited by Canoeboot, when the Libreboot project was forked.
So for example, if you wish to use an add-on graphics card, you can! It's no
problem, and should work just fine.
@ -88,7 +88,7 @@ There are two ways to identify a supported KCMA-D8 board:
Supported boards begin with a serial number of **B9S2xxxxxxxx** or above where
the first character refers to the year of manufacture (A = 2010, B = 2011, etc.)
and the following character the month in hexadecimal (1...9, A, B, C). Thus, any
board produced September 2011 *or later* are compatible with nonGeNUine Boot. Boards
board produced September 2011 *or later* are compatible with Canoeboot. Boards
originally shipped with BIOS version **2001** or higher are also compatible.
For help locating these identifying markers, see [ASUS documentation for determining Opteron 4200 series compatibility](https://web.archive.org/web/20200710022605/https://dlcdnets.asus.com/pub/ASUS/mb/SocketC%281027%29/KCMA-D8/Manual&QVL/How_to_identify_MB_supporting_Opteron_4200_CPU.pdf)
@ -138,7 +138,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 mainboard. Nvidia GTX 780 cards
are what nonGeNUine Boot recommends; it has excellent support in Nouveau (free GNU+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,
@ -166,7 +166,7 @@ considerations:
and as such a workaround using SGABIOS is necessary. You can find
instructions on how to do this on the
[Notabug issue tracker](http://web.archive.org/web/20210416011941/https://notabug.org/libreboot/libreboot/issues/736)
TODO: test whether this is still the case in nonGeNUine Boot, which uses a newer
TODO: test whether this is still the case in Canoeboot, which uses a newer
version of coreboot nowadays)
- SAS (via PIKE 2008 module) requires non-free option ROM (and
SeaBIOS) to boot from it (theoretically possible to replace, but you
@ -174,7 +174,7 @@ considerations:
can be on a SAS drive. The linux kernel can use those SAS drives
(via PIKE module) without an option ROM).
NOTE: SeaBIOS can load PCI-E option ROMs, and by default it will do so in
nonGeNUine Boot, so you could use it. However, you could *also* simply
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 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
@ -184,7 +184,7 @@ considerations:
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the nonGeNUine Boot
replacement is theoretically possible. For now, the Canoeboot
project recommends not installing that module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In

4
site/docs/hardware/kfsn4-dre.md
View File

@ -49,7 +49,7 @@ P*: Partially works with blobs
</div>
This is a server board using AMD hardware (Fam10h). It can also be used
for building a high-powered workstation. Powered by nonGeNUine Boot.
for building a high-powered workstation. Powered by Canoeboot.
Flashing instructions can be found at
[../install/\#flashrom](../install/)
@ -113,7 +113,7 @@ the same as the non-iKVM ones.
The SAS versions have a 4-port SAS controller and a four 7-pin SAS connectors
instead of the PCI-E 8x slot which is present in all the other board configurations.
Note: the SAS functionality is **not supported** by nonGeNUine Boot.
Note: the SAS functionality is **not supported** by Canoeboot.
The IST versions with PCB revision 1.05G are the ones who are believed to
support the six core Opteron Istanbul processors (2400 and 8400 series).

16
site/docs/hardware/kgpe-d16.md
View File

@ -8,9 +8,9 @@ Introduction
This is a server board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
Powered by nonGeNUine Boot. The coreboot port was done by Timothy Pearson of
Powered by Canoeboot. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them (and sponsoring the
work), merged into Libreboot (and inherited by nonGeNUine Boot).
work), merged into Libreboot (and inherited by Canoeboot).
*Memory initialization is still problematic, for some modules. We
recommend avoiding Kingston modules.*
@ -19,7 +19,7 @@ recommend avoiding Kingston modules.*
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom) - note that external
flashing is required, if the proprietary (ASUS) firmware is
currently installed. If you already have nonGeNUine Boot, by default it is
currently installed. If you already have Canoeboot, by default it is
possible to re-flash using software running in GNU+Linux on the
KGPE-D16, without using external hardware.
@ -59,7 +59,7 @@ P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes:
compressed linux+initramfs image (BusyBox+GNU+Linux system) into CBFS and
boot that, loading it into memory.
nonGeNUine Boot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
Canoeboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
flash chip is 2MiB).
*DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip
@ -92,7 +92,7 @@ Current issues {#issues}
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the nonGeNUine Boot
replacement is theoretically possible. For now, the Canoeboot
project recommends not installing the module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In
@ -114,9 +114,9 @@ The information here is adapted, from the ASUS website.
recommended - old. View errata datasheet here:
<http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf>)
- AMD Opteron 6200 series (Fam15h, with full IOMMU support in
nonGeNUine Boot.
Canoeboot.
- AMD Opteron 6300 series (Fam15h, with full IOMMU support in
nonGeNUine Boot.
Canoeboot.
- 6.4 GT/s per link (triple link)
### Core logic
@ -124,7 +124,7 @@ The information here is adapted, from the ASUS website.
- AMD SR5690
- AMD SP5100
### Memory compatibility (with nonGeNUine Boot)
### Memory compatibility (with Canoeboot)
- *Total Slots:* 16 (4-channel per CPU, 8 DIMM per CPU), ECC
- *Capacity:* Maximum up to 256GB RDIMM (Tested max 128GB)

14
site/docs/hardware/mac_address.md
View File

@ -14,20 +14,20 @@ The R500 is an exception to this as it does not use the built-in e1000.
On all these laptops, the
[MAC address](https://en.wikipedia.org/wiki/MAC_address)
for the built-in gigabit ethernet controller is stored inside the flash chip,
along with nonGeNUine Boot and other configuration data. Therefore, installing
nonGeNUine Boot will overwrite it.
along with Canoeboot and other configuration data. Therefore, installing
Canoeboot will overwrite it.
Thus, for these laptops, prebuilt nonGeNUine Boot already contains a generic
Thus, for these laptops, prebuilt Canoeboot already contains a generic
MAC address in the configuration section. This address is `00:f5:f0:40:71:fe
in builds before 2018-01-16 and `00:4c:69:62:72:65` (see the ascii character
set) afterwards.
Unless you change it, your computer will boot and use it. This can lead
to network problems if you have more than one nonGeNUine Boot computer on
to network problems if you have more than one Canoeboot computer on
the same layer2 network (e.g. on the same network switch). The switch
(postman) will simply not know who to deliver to as the MAC (house) addresses
will be the same.
To prevent these address clashes, you can either modify prebuilt nonGeNUine Boot
To prevent these address clashes, you can either modify prebuilt Canoeboot
to use an address of your own choosing or you can change the address in your
operating system's boot scripts.
@ -58,7 +58,7 @@ The existing MAC address may be obtained by the following methods:
2. Otherwise you can read the white label that is often found on the
motherboard under the memory sticks:
![](https://avgnu.vimuser.org/t400/macaddress1.jpg)
![](https://av.canoeboot.org/t400/macaddress1.jpg)
3. The MAC address is usually listed on the laptop chassis as well. This one
will be incorrect if the motherboard was changed and the stickers were not
@ -103,6 +103,6 @@ instead. See notes below:
Also see [nvmutil documentation](../install/nvmutil.md)
The nvmutil utility is yet another utility provided by nonGeNUine Boot, for
The nvmutil utility is yet another utility provided by Canoeboot, for
changing your MAC address. It is a standalone utility, that operates
only on pre-assembled GbE files.

24
site/docs/hardware/macbook21.md
View File

@ -93,8 +93,8 @@ For the MacBook2,1:
working)*
It's believed that all MacBook2,1 and MacBook1,1 models work fine with
nonGeNUine Boot. If there's a model not in the list or not confirmed working
here and you happen to have that model and that model works with nonGeNUine Boot
Canoeboot. If there's a model not in the list or not confirmed working
here and you happen to have that model and that model works with Canoeboot
then don't forget to [send a patch](../../git.md), confirming that it
actually works!
@ -113,14 +113,14 @@ External flashing
MacBook1,1 requires external flashing, if running the default Apple firmware.
MacBook2,1 can be flashed internally, regardless.
If running nonGeNUine Boot you can already internally re-flash.
If running Canoeboot you can already internally re-flash.
[This page shows disassembly
guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo)
Locate the flash. It'll be a SOIC8, which looks like this:
![](https://avgnu.vimuser.org/chip/soic8.jpg)
![](https://av.canoeboot.org/chip/soic8.jpg)
The chip is located under the motherboard. [How to remove the
motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529).
@ -158,7 +158,7 @@ layer was made specifically for booting Microsoft Windows as part of
BootCamp, a tool which allowed dual-booting Windows and OS X) ;
* Install it like you normally would (If there's an OS X installation then
it's highly recommended to save all your data and wipe it. nonGeNUine Boot isn't
it's highly recommended to save all your data and wipe it. Canoeboot isn't
able and will never be able to boot OS X) ;
* While rebooting, hold Alt/Control once again, and select the hard disk
@ -167,7 +167,7 @@ should boot up properly automatically.
*If you installed your OS alongside OS X then you won't be able to boot
to it using GRUB, despite the fact that it does sometimes show up. You
also won't be able to boot it up when using nonGeNUine Boot.*
also won't be able to boot it up when using Canoeboot.*
Boot via USB
------------
@ -191,20 +191,20 @@ should pop up, requesting you to choose which device to boot from ;
* Select the USB icon ;
* Install it like you normally would (If there's an OS X installation then
it's highly recommended to save all your data and wipe it. nonGeNUine Boot isn't
it's highly recommended to save all your data and wipe it. Canoeboot isn't
able and will never be able to boot OS X) ;
* Reboot. It should boot up to your newly-installed system if you wiped OS X,
else, hold Alt/Control and select the correct boot device ;
* Flash nonGeNUine Boot. DO NOT REBOOT AGAIN BEFORE FLASHING. Sometimes the
* Flash Canoeboot. DO NOT REBOOT AGAIN BEFORE FLASHING. Sometimes the
firmware can get confused, because Apple never intended to boot other
EFI OSes other than OS X, as such there's a chance that your MacBook can
become [soft-bricked](https://apple.stackexchange.com/questions/408104/late-2006-macbook-doesnt-turn-on-fan-spinning-but-no-chime/409754).
If that is the case then dissassemble it and remove
the CMOS/PRAM battery, wait a few minutes, and put it back in.
*If you want to install nonGeNUine Boot with the SeaBIOS payload then be sure
*If you want to install Canoeboot with the SeaBIOS payload then be sure
to reconfigure GRUB2 correctly, else your system won't boot.*
Coreboot wiki page
@ -229,12 +229,12 @@ remove it.*
Make it overheat less
---------------------
NOTE: in nonGeNUine Boot, this section is less relevant, because C3
NOTE: in Canoeboot, this section is less relevant, because C3
states are now; the issue pertained to much older releases of Libreboot,
upon which nonGeNUine Boot is based. However, this section may still be useful,
upon which Canoeboot is based. However, this section may still be useful,
so it will be retained.
The MacBook2,1 overheats a lot with nonGeNUine Boot, we still don't know why but a simple workaround is to install macfanctld.
The MacBook2,1 overheats a lot with Canoeboot, we still don't know why but a simple workaround is to install macfanctld.
Macfanctld is available on the default repos of many distributions.

8
site/docs/hardware/r400.md
View File

@ -56,7 +56,7 @@ Dell Latitude E6400
**If you haven't bought an R400 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -72,7 +72,7 @@ There are two possible flash chip sizes for the R400: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The R400 laptops come with the ME (and sometimes AMT in addition)
before flashing nonGeNUine Boot. nonGeNUine Boot disables and removes it by using a
before flashing Canoeboot. Canoeboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -84,7 +84,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
nonGeNUine Boot, so we don't actually provide that, but if you still have
Canoeboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -92,7 +92,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running nonGeNUine Boot is unknown. nonGeNUine Boot
update the EC firmware while running Canoeboot is unknown. Canoeboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

6
site/docs/hardware/r500.md
View File

@ -55,7 +55,7 @@ Dell Latitude E6400
**If you haven't bought an R500 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -69,8 +69,8 @@ The chip is 4MiB NOR flash (SPI protocol) is SOIC8 form factory.
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
Unlike other GM45+ICH9M thinkpads in nonGeNUine Boot, the R500 doesn't have an Intel
PHY (for Gigabit Ethernet). However, nonGeNUine Boot still includes an Intel flash
Unlike other GM45+ICH9M thinkpads in Canoeboot, the R500 doesn't have an Intel
PHY (for Gigabit Ethernet). However, Canoeboot still includes an Intel flash
descriptor, but with just the descriptor and BIOS region. The `ich9gen` program
supports this fully.

10
site/docs/hardware/t400.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad T400" class="p" src="https://avgnu.vimuser.org/t400/boot1.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t400/boot1.jpg" /></span>
<img tabindex=1 alt="ThinkPad T400" class="p" src="https://av.canoeboot.org/t400/boot1.jpg" /><span class="f"><img src="https://av.canoeboot.org/t400/boot1.jpg" /></span>
</center>
| ***Specifications*** | |
@ -55,7 +55,7 @@ Dell Latitude E6400
**If you haven't bought an T400 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -71,7 +71,7 @@ There are two possible flash chip sizes for the T400: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T400 laptops come with the ME (and sometimes AMT in addition)
before flashing nonGeNUine Boot. nonGeNUine Boot disables and removes it by using a
before flashing Canoeboot. Canoeboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -83,7 +83,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
nonGeNUine Boot, so we don't actually provide that, but if you still have
Canoeboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -91,7 +91,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running nonGeNUine Boot is unknown. nonGeNUine Boot
update the EC firmware while running Canoeboot is unknown. Canoeboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

10
site/docs/hardware/t500.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad T500" class="p" src="https://avgnu.vimuser.org/t500/0062.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0062.jpg" /></span>
<img tabindex=1 alt="ThinkPad T500" class="p" src="https://av.canoeboot.org/t500/0062.jpg" /><span class="f"><img src="https://av.canoeboot.org/t500/0062.jpg" /></span>
</center>
| ***Specifications*** | |
@ -55,7 +55,7 @@ Dell Latitude E6400
**If you haven't bought an T500 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -73,7 +73,7 @@ There are two possible flash chip sizes for the T500: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T500 laptops come with the ME (and sometimes AMT in addition)
before flashing nonGeNUine Boot. nonGeNUine Boot disables and removes it by using a
before flashing Canoeboot. Canoeboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -85,7 +85,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
nonGeNUine Boot, so we don't actually provide that, but if you still have
Canoeboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -93,7 +93,7 @@ will update both the BIOS and EC version. See:
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running nonGeNUine Boot is unknown. nonGeNUine Boot
update the EC firmware while running Canoeboot is unknown. Canoeboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery

12
site/docs/hardware/x200.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://avgnu.vimuser.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/x200/disassembly/0019.jpg" /></span>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://av.canoeboot.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://av.canoeboot.org/x200/disassembly/0019.jpg" /></span>
</center>
| ***Specifications*** | |
@ -53,7 +53,7 @@ Dell Latitude E6400
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -63,7 +63,7 @@ It is believed that all X200 laptops are compatible. X200S and X200
Tablet will also work, [depending on the configuration](#x200s).
It may be possible to put an X200 motherboard in an X201 chassis, though this
is currently untested by the nonGeNUine Boot project. The same may also apply between
is currently untested by the Canoeboot project. The same may also apply between
X200S and X201S; again, this is untested. *It's most likely true.*
There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or
@ -71,7 +71,7 @@ There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The X200 laptops come with the ME (and sometimes AMT in addition)
before flashing nonGeNUine Boot. nonGeNUine Boot disables and removes it by using a
before flashing Canoeboot. Canoeboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
@ -83,7 +83,7 @@ EC update {#ecupdate}
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
nonGeNUine Boot, so we don't actually provide that, but if you still have
Canoeboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
@ -93,7 +93,7 @@ will update both the BIOS and EC version. See:
- [X200t BIOS Update](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-tablet-laptops/thinkpad-x200-tablet/downloads/ds018814)
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running nonGeNUine Boot is unknown. nonGeNUine Boot
update the EC firmware while running Canoeboot is unknown. Canoeboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery

10
site/docs/hardware/x200.uk.md
View File

@ -5,7 +5,7 @@ x-toc-enable: true
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://avgnu.vimuser.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/x200/disassembly/0019.jpg" /></span>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://av.canoeboot.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://av.canoeboot.org/x200/disassembly/0019.jpg" /></span>
</center>
| ***Характеристики*** | |
@ -56,7 +56,7 @@ P*: Частково працює з бінарними компонентами
Tablet також працюватимуть, [залежно від конфігурації](#x200s).
Можливо, можна розмістити материнську плату X200 у шасі X201, хоча це
наразі не перевірено проектом nonGeNUine Boot. Те ж саме може стосуватися
наразі не перевірено проектом Canoeboot. Те ж саме може стосуватися
X200S та X201S; знову ж таки, це неперевірено. *Швидше за все, це правда.*
Є два можливих розміра флеш-чіпа для X200: 4MБ (32 Мбіт) або
@ -64,7 +64,7 @@ X200S та X201S; знову ж таки, це неперевірено. *Шви
упором для рук: 4МБ це SOIC-8, 8МБ це SOIC-16.
*Ноутбуки X200 постачаються з ME (та іноді AMT додатково)
перед перепрошивкою nonGeNUine Boot. nonGeNUine Boot вимикає та видаляє його за допомогою
перед перепрошивкою Canoeboot. Canoeboot вимикає та видаляє його за допомогою
модифікованого дескриптора: дивіться [../install/ich9utils.md](../install/ich9utils.md)*
(містить примітки та інструкції)
@ -76,7 +76,7 @@ X200S та X201S; знову ж таки, це неперевірено. *Шви
Рекомендується оновити мікропрограму EC до останньої версії.
[Прошивка EC](../../faq.md#ec-embedded-controller-firmware) є окремою від
nonGeNUine Boot, тому ми її фактично не надаємо, але якщо у вас все ще є
Canoeboot, тому ми її фактично не надаємо, але якщо у вас все ще є
Lenovo BIOS, ви можете просто запустити утиліту оновлення BIOS Lenovo, яка
оновить як BIOS, так і версію EC. Дивіться:
@ -86,7 +86,7 @@ Lenovo BIOS, ви можете просто запустити утиліту о
- [Оновлення BIOS X200t](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-tablet-laptops/thinkpad-x200-tablet/downloads/ds018814)
ПРИМІТКА: це можна зробити, лише якщо ви використовуєте Lenovo BIOS. Як
оновити мікропрограму EC, користуючись nonGeNUine Boot, невідомо. nonGeNUine Boot
оновити мікропрограму EC, користуючись Canoeboot, невідомо. Canoeboot
тільки замінює прошивку BIOS, не EC.
Оновлена мікропрограма EC має декілька переваг, напр. краще поводження

26
site/docs/index.md
View File

@ -2,32 +2,31 @@
title: Documentation
...
Always check the nonGeNUine Boot website for the latest updates to
nonGeNUine Boot. News, including release announcements, can be found in
Always check the Canoeboot website for the latest updates to
Canoeboot. News, including release announcements, can be found in
the [main news section](../news/).
**nonGeNUine Boot was originally designated as GNU Boot unofficially, but
re-branded to nonGeNUine Boot on [21
July 2023](../news/nongenuineboot20230717.html#update-21-july-2023)**
[Answers to Frequently Asked Questions about Canoeboot](../faq.md).
[Answers to Frequently Asked Questions about nonGeNUine Boot](../faq.md).
What is Canoeboot? An article is available for that; please read the
article titled [What is Canoeboot?](../about.md).
Installing nonGeNUine Boot
Installing Canoeboot
====================
- [What systems can I use nonGeNUine Boot on?](hardware/)
- [How to install nonGeNUine Boot](install/)
- [What systems can I use Canoeboot on?](hardware/)
- [How to install Canoeboot](install/)
Documentation related to operating systems
============================
- [How to install BSD on an x86 host system](bsd/)
- [GNU+Linux Guides](gnulinux/)
- [How to install BSD operating systems](bsd/)
- [How to install GNU+Linux](gnulinux/) (and other Linux-based systems)
Information for developers
==========================
- [How to compile the nonGeNUine Boot source code](build/)
- [How to compile the Canoeboot source code](build/)
- [Build system developer documentation](maintain/)
- [GRUB payload](grub/)
- [U-Boot payload](uboot/)
@ -38,3 +37,6 @@ Other information
- [Miscellaneous](misc/)
- [List of codenames](misc/codenames.md)
If you're using *release archives*, this documentation and accompanying images
are under `src/www/` and `src/img/` respectively, in the source release archive.
This fact is true for Canoeboot 20231026 and newer.

20
site/docs/index.uk.md
View File

@ -2,17 +2,20 @@
title: Документація
...
Завжди перевіряйте nonGeNUine Boot для останніх оновлень
nonGeNUine Boot. Новини, включаючи оголошення про випуски, може бути знайдено
Завжди перевіряйте Canoeboot для останніх оновлень
Canoeboot. Новини, включаючи оголошення про випуски, може бути знайдено
в [основній секції новин](../news/).
[Відповіді на поширені запитання про nonGeNUine Boot](../faq.md).
[Відповіді на поширені запитання про Canoeboot](../faq.md).
Встановлення nonGeNUine Boot
What is Canoeboot? An article is available for that; please read the
article titled [What is Canoeboot?](../about.md).
Встановлення Canoeboot
=====================
- [На яких системах я можу встановлювати nonGeNUine Boot?](hardware/)
- [Як встановити nonGeNUine Boot](install/)
- [На яких системах я можу встановлювати Canoeboot?](hardware/)
- [Як встановити Canoeboot](install/)
Документація, яка має відношення до операційних систем
============================
@ -23,7 +26,7 @@ nonGeNUine Boot. Новини, включаючи оголошення про в
Інформація для розробників
==========================
- [Як зібрати джерельний код nonGeNUine Boot](build/)
- [Як зібрати джерельний код Canoeboot](build/)
- [Документація розробника системи побудови](maintain/)
- [Корисне навантаження GRUB](grub/)
- [Корисне навантаження U-Boot](uboot/)
@ -34,3 +37,6 @@ nonGeNUine Boot. Новини, включаючи оголошення про в
- [Різне](misc/)
- [Список кодових назв](misc/codenames.md)
If you're using *release archives*, this documentation and accompanying images
are under `src/www/` and `src/img/` respectively, in the source release archive.
This fact is true for Canoeboot 20231026 and newer.

40
site/docs/index.zh-cn.md Normal file
View File

@ -0,0 +1,40 @@
---
title: 文档
...
canoeboot 的最新更新，可以在 [canoeboot.org](https://canoeboot.org) 上找到。新闻，包括新版发布公告，可以在[新闻主页](../news/)中找到。
[canoeboot 常见问题解答](../faq.md).
What is Canoeboot? An article is available for that; please read the
article titled [What is Canoeboot?](../about.md).
安装 canoeboot
====================
- [哪些机器上可以使用 canoeboot？](hardware/)
- [如何安装 canoeboot](install/)
操作系统相关文档
============================
- [如何在 x86 机器上安装 BSD](bsd/)
- [Linux 指南](gnulinux/)
开发者信息
==========================
- [如何编译 canoeboot 源代码](build/)
- [构建系统开发者文档](maintain/)
- [GRUB payload](grub/)
- [U-Boot payload](uboot/)
其它信息
=================
- [杂项](misc/)
- [代号列表](misc/codenames.md)
If you're using *release archives*, this documentation and accompanying images
are under `src/www/` and `src/img/` respectively, in the source release archive.
This fact is true for Canoeboot 20231026 and newer.

34
site/docs/install/c201.md
View File

@ -6,13 +6,8 @@ x-toc-enable: true
WARNING: This board is known to have non-functioning video init at the time
of writing, 19 February 2023. It is as yet unsolved.
**NOTE: This information is inherited from Libreboot, and should probably
be removed. It refers to older Libreboot releases, which supported this
hardware in the configuration described, but nonGeNUine Boot has never supported
this machine.**
See: <https://notabug.org/libreboot/lbmk/issues/136> (NOTE: Libreboot issue page,
not nonGeNUine Boot)
not Canoeboot)
Introduction
===========
@ -28,15 +23,28 @@ A special fork of flashrom, maintained by Google, is required for flashing.
More information about this is present in the generic [chromebook flashing
instructions](chromebooks.md).
Depthcharge payload (obsolete)
------------------------------
This board was also supported in Libreboot 20160907, with the Depthcharge
payload. Support was dropped in later releases, and then re-added in the
December 2022 release but with *u-boot* payload (not *depthcharge*).
Refer to older versions of this page, in `lbwww.git`, if you wish to see
instructions pertaining to Depthcharge:
* <https://notabug.org/libreboot/lbwww/src/4be2eed23e11b1071cd500a329abf654ab25f942/site/docs/install/c201.md>
* <https://notabug.org/libreboot/lbwww/src/4be2eed23e11b1071cd500a329abf654ab25f942/site/docs/hardware/c201.md>
U-boot payload
==============
U-Boot was ported to coreboot CrOS devices, courtesy of Alper Nebi
Yasak on behalf of the Libreboot project, upon which nonGeNUine Boot is based.
Yasak on behalf of the Libreboot project, upon which Canoeboot is based.
Read the section pertaining to U-boot payload:
[u-boot payload documentation for nonGeNUine Boot](../uboot/)
[u-boot payload documentation for Canoeboot](../uboot/)
Internal flashing
=================
@ -46,7 +54,7 @@ If you're flashing good firmware, and the machine boots properly, you can
do it in software, from the host CPU.
In the past, C201 was the only CrOS device so this page contained information
about internal flashing. nonGeNUine Boot now supports many more CrOS devices, so
about internal flashing. Canoeboot now supports many more CrOS devices, so
the information has moved.
See: [chromebook flashing instructions](chromebooks.md)
@ -67,9 +75,9 @@ below. The write protect screw is located next to the SPI flash chip, circled
in red in the picture below. It has to be removed. Refer to the following
photos:
[![Screws](https://avgnu.vimuser.org/c201/screws.jpg)](https://avgnu.vimuser.org/c201/screws.jpg)
[![Screws](https://av.canoeboot.org/c201/screws.jpg)](https://av.canoeboot.org/c201/screws.jpg)
[![WP screw](https://avgnu.vimuser.org/c201/wp-screw.jpg)](https://avgnu.vimuser.org/c201/wp-screw.jpg)
[![WP screw](https://av.canoeboot.org/c201/wp-screw.jpg)](https://av.canoeboot.org/c201/wp-screw.jpg)
The write protect screw can be put back in place later, when the device
is known to be in a working state.
@ -81,10 +89,10 @@ If the machine is no longer booting, due to bad firmware, you can unbrick
it externally. Refer to [external flash instructions](spi.md).
[![SPI flash
layout](https://avgnu.vimuser.org/c201/spi-flash-layout.jpg)](https://avgnu.vimuser.org/c201/spi-flash-layout.jpg)
layout](https://av.canoeboot.org/c201/spi-flash-layout.jpg)](https://av.canoeboot.org/c201/spi-flash-layout.jpg)
[![Battery
connector](https://avgnu.vimuser.org/c201/battery-connector.jpg)](https://avgnu.vimuser.org/c201/battery-connector.jpg)
connector](https://av.canoeboot.org/c201/battery-connector.jpg)](https://av.canoeboot.org/c201/battery-connector.jpg)
You do not need to correct the `WP#` pin because it is held high via pull-up
resistor to 3.3v, when the write-protect screw is loosened (when tightened,

20
site/docs/install/chromebooks.md
View File

@ -42,7 +42,7 @@ Identify your device
====================
It's more common to refer to ChromeOS boards by their codenames, and
many compatible devices can share a single codename. nonGeNUine Boot ROM
many compatible devices can share a single codename. Canoeboot ROM
images also use these, you should only use the one corresponding to your
device's. There are a number of ways to find it, some are:
@ -85,7 +85,7 @@ extra careful about that.
On newer Chromebooks, there is a root-of-trust chip providing a
[Closed Case Debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md)
mechanism that lets you flash externally using a special USB debugging
cable. However, most boards that nonGeNUine Boot supports do not have this.
cable. However, most boards that Canoeboot supports do not have this.
Disable write protection
========================
@ -97,7 +97,7 @@ owner. How to do so depends on the board, refer to the
for more info. You will usually need to do this only once for the
board's lifetime, unless you manually enable it again.
On most boards that nonGeNUine Boot supports, write-protection is enforced by
On most boards that Canoeboot supports, write-protection is enforced by
a physical screw. When screwed in, it forms an electrical connection
that asserts the WP pin on the flash chip. The screw can be identified
by the fact that it bridges electrical contacts, but finding and
@ -120,18 +120,18 @@ The *--wp* arguments are only available on the
[ChromiumOS fork of flashrom](https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom).
If you are using another OS or an external flasher, you may need to
compile and use that flashrom fork to disable write-protection. There is
no `gbmk` support yet for automatically building it.
no `cbmk` support yet for automatically building it.
Prepare the ROM image
=====================
nonGeNUine Boot ROM image layouts are currently incompatible with the regions
Canoeboot ROM image layouts are currently incompatible with the regions
that should be carried over from the stock firmware. However, the
released images should still be somewhat usable, since the Chromebooks
supported so far don't require any non-redistributable blobs to be
injected by the end user.
Future nonGeNUine Boot versions will likely require post-processing to
Future Canoeboot versions will likely require post-processing to
preserve irreplaceable data in the firmware image. For now, make sure to
keep backups of the original firmware.
@ -151,8 +151,8 @@ documentation if your board supports it.
To flash the entire ROM image internally, run within ChromeOS:
sudo flashrom -p host -w nongenuineboot.rom
sudo flashrom -p host -v nongenuineboot.rom
sudo flashrom -p host -w canoeboot.rom
sudo flashrom -p host -v canoeboot.rom
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.
@ -171,12 +171,10 @@ three general methods for installing that vary depending on the distribution:
Successful installations:
-------------------------
* [ArchGNU+LinuxARM on RK3399-based Chromebooks](../uboot/uboot-archlinux.md). (TODO: test Parabola)
* [ArchLinuxARM 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).
**TODO: Test Debian instructions with Trisquel.**
Unsuccessful installations:
---------------------------

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

@ -2,7 +2,7 @@
title: D510MO flashing tutorial
...
This guide is for those who want nonGeNUine Boot on their Intel D510MO
This guide is for those who want Canoeboot on their Intel D510MO
motherboard while they still have the original BIOS present.
NOTE: D410PT is another designation and it's the same board. Flash the same ROM.

6
site/docs/install/d945gclf.md
View File

@ -2,11 +2,11 @@
title: Intel D945GCLF flashing tutorial
...
NOTE: On newer nonGeNUine Boot revisions, boot issues were reported so this board
NOTE: On newer Canoeboot revisions, boot issues were reported so this board
was temporarily removed. It will be re-added at a later date, after testing
has been done.
This guide is for those who want nonGeNUine Boot on their Intel D945GCLF
This guide is for those who want Canoeboot on their Intel D945GCLF
motherboard while they still have the original BIOS present.
D945GCLF2D also reported working by a user.
@ -20,4 +20,4 @@ Flashing instructions {#clip}
Refer to [spi.md](spi.md) for how to re-flash externally.
Here is an image of the flash chip:\
![](https://avgnu.vimuser.org/d945gclf/d945gclf_spi.jpg)
![](https://av.canoeboot.org/d945gclf/d945gclf_spi.jpg)

49
site/docs/install/e6400.md
View File

@ -9,7 +9,7 @@ Introduction
Initial flashing instructions for the E6400. DO NOT flash the Nvidia GPU
variant. This page pertains only to the Intel GPU variant.
This guide is for those who want nonGeNUine Boot on their Latitude E6400 while
This guide is for those who want Canoeboot on their Latitude E6400 while
they still have the original Dell BIOS present. This guide can also be
followed (adapted) if you brick your E6400, and you want to recover it.
@ -19,7 +19,7 @@ to that of ThinkPad X200, T400 etc where no-ME setup is possible.
A note about GPUs
-----------------
Models with Intel graphics are GM45, and fully supported in nonGeNUine Boot
Models with Intel graphics are GM45, and fully supported in Canoeboot
with native initialisation; ROM images are available since.
**The Intel video initialisation is libre, implemented with publicly available
source code via libgfxinit, from the coreboot project.**
@ -38,7 +38,7 @@ MAC address {#macaddress}
===========
The MAC address is part of the ROM image that you're flashing. You can change
it at any time, before or after you've flashed nonGeNUine Boot; you can also change
it at any time, before or after you've flashed Canoeboot; you can also change
it in the *Dell* BIOS, if you really want to. This is for the onboard gigabit
ethernet device.
@ -59,7 +59,7 @@ etc). You can *also* run ich9gen, if you wish:
Intel GPU: libre video initialisation available
===============================================
nonGeNUine Boot uses coreboot's native `libgfxinit` on this platform, for
Canoeboot uses coreboot's native `libgfxinit` on this platform, for
variants with Intel graphics.
How to flash internally (no diassembly)
@ -68,16 +68,19 @@ How to flash internally (no diassembly)
Warning for BSD users
---------------------
+**NOTE: The util is now called `dell-flash-unlock`, but it
+was previously called `e6400-flash-unlock`. Links have been updated.**
BSD *boots* and works properly on these machines, but take note:
Nicholas's [e6400-flash-unlock](https://browse.libreboot.org/lbmk.git/plain/util/e6400-flash-unlock/e6400_flash_unlock.c)
utility has not yet been ported to BSD systems. The `flashrom` software is
available on BSD systems. nonGeNUine Boot's build system has not yet been ported to
the BSDs.
Nicholas's [dell-flash-unlock](https://browse.libreboot.org/lbmk.git/plain/util/dell-flash-unlock/dell_flash_unlock.c)
utility has been ported to OpenBSD, but *other* BSDs are assumed unsupported for
now. The `flashrom` software is available on BSD systems. Canoeboot's build
system has *itself* not yet been ported to the BSDs, but you can use the
flash unlock utility.
BSD users could run GNU+Linux from USB to run `flashrom` and `e6400-flash-unlock`.
Virtualisation is available in BSDs, where it should be feasible to run the
nonGeNUine Boot build system, in GNU+Linux, under virtualisation.
NOTE: BSD is mentioned above, but the only BSD tested for `dell-flash-unlock`
is OpenBSD, as of 15 October 2023.
Flashing from GNU+Linux
-------------------
@ -86,22 +89,26 @@ MAKE SURE you boot with this GNU+Linux kernel parameter: `iomem=relaxed` - this
disables memory protections, permitting `/dev/mem` access needed by flashrom.
The flash is memory mapped and flashrom accesses it via `/dev/mem`.
You can flash nonGeNUine Boot directly from the vendor (Dell) BIOS, without taking
You can flash Canoeboot directly from the vendor (Dell) BIOS, without taking
the machine apart. It can be done entirely from GNU+Linux. It will probably also
work on BSD systems, but it has only been testing on GNU+Linux thus far.
Check `util/e6400-flash-unlock` in the `gbmk.git` repository, or releases.
**NOTE: The util is now called `dell-flash-unlock`, but it
was previously called `e6400-flash-unlock`. Links have been updated.**
Check `util/dell-flash-unlock` in the `cbmk.git` repository, or in release
archives for Canoeboot releases from 20231026 onward.
Go in there:
cd util/e6400-flash-unlock
cd util/dell-flash-unlock
make
With this program, you can unlock the flash in such a way where everything
is writeable. Information about how to use it is in the `README.md` file which
is included in that program's directory, or you can read it online here:
<https://browse.libreboot.org/lbmk.git/plain/util/e6400-flash-unlock/README.md>
<https://browse.libreboot.org/lbmk.git/plain/util/dell-flash-unlock/README.md>
Literally just run that program, and do what it says. You run it once, and shut
down, and when you do, the system brings itself back up automatically. Then
@ -116,30 +123,30 @@ Protected Range registers.
When you flash it, you can use this command:
flashrom -p internal -w nongenuineboot.rom
flashrom -p internal -w canoeboot.rom
Where `nongenuineboot.rom` is your E6400 ROM. *Make sure* it's the right one.
Where `canoeboot.rom` is your E6400 ROM. *Make sure* it's the right one.
If flashrom complains about multiple flash chips detected, just pick one of
them (doesn't matter which one). On *most* Dell machines, the most correct
would probably be this option in flashrom: `-c MX25L3205D/MX25L3208D`.
So:
flashrom -p internal -w nongenuineboot.rom -c MX25L3205D/MX25L3208D
flashrom -p internal -w canoeboot.rom -c MX25L3205D/MX25L3208D
When you see flashrom say `VERIFIED` at the end, that means the flash was
successful. If you don't see that, or you're unsure, please [contact the
nonGeNUine Boot project via IRC](../../contact.md).
Canoeboot project via IRC](../../contact.md).
BACK UP THE FACTORY BIOS
========================
The `-w` option flashes `nongenuineboot.rom`. You may consider *backing up* the
The `-w` option flashes `canoeboot.rom`. You may consider *backing up* the
original Dell BIOS first, using the -r option:
flashrom -p internal -r backup.rom -c MX25L3205D/MX25L3208D
Do this while in a flashable state, after the 2nd run of `e6400-flash-unlock`.
Do this while in a flashable state, after the 2nd run of `dell-flash-unlock`.
Make sure the `backup.rom` file gets backed up to an external storage media,
not the E6400 itself.

10
site/docs/install/ga-g41m-es2l.md
View File

@ -3,7 +3,7 @@ title: GA-G41M-ES2L flashing tutorial
x-toc-enable: true
...
This guide is for those who want nonGeNUine Boot on their Intel GA-G41M-ES2L
This guide is for those who want Canoeboot on their Intel GA-G41M-ES2L
motherboard while they still have the original BIOS present.
MAC ADDRESS
@ -45,22 +45,22 @@ NOTE: You should use a resistor in series, between 1K to 10K ohms, for the 3.3v
connection to the CS pin. This is to protect from over-current.
Here is an image of the flash chip:\
![](https://avgnu.vimuser.org/ga-g41m-es2l/ga-g41m-es2l.jpg)
![](https://av.canoeboot.org/ga-g41m-es2l/ga-g41m-es2l.jpg)
Internal flashing is possible. Boot with the proprietary BIOS and
GNU+Linux. There are 2 flash chips (one is backup).
Flash the first chip:
./flashrom -p internal:dualbiosindex=0 -w nongenuineboot.rom
./flashrom -p internal:dualbiosindex=0 -w canoeboot.rom
Flash the second chip:
./flashrom -p internal:dualbiosindex=1 -w nongenuineboot.rom
./flashrom -p internal:dualbiosindex=1 -w canoeboot.rom
NOTE: you can still boot the system with just the main flash chip
connected, after desoldering the backup chip. This has been tested while
nonGeNUine Boot was already installed onto the main chip.
Canoeboot was already installed onto the main chip.
NOTE: If you don't flash both chips, the recovery program from the default
factory BIOS will kick in and your board will be soft bricked. Make sure that

106
site/docs/install/ich9utils.md
View File

@ -3,23 +3,39 @@ title: ich9utils
x-toc-enable: true
...
If all you want to do is change the MAC address, you might use `nvmutil`
instead. See: [nvmutil documentation](../install/nvmutil.md).
**THIS PAGE IS OBSOLETE. Releases from Canoeboot 20231026 onward do not have
ich9utils; instead, ICH9M descriptors and gbe nvm configurations are provided
pre-assembled. Coreboot's bincfg can regenerate them if you wish, and/or you
can modify the ifd file with coreboot's ifdtool. You can use nvmutil to modify
the GbE NVM MAC address**
Both this and nvmutil were *inherited* from Libreboot, upon which nonGeNUine Boot
is based.
**If all you want to do is change the MAC address, you might use `nvmutil`
instead. See: [nvmutil documentation](../install/nvmutil.md).**
The documentation below is *still valid*, if you actually want to use ich9utils.
You can find it in older Libreboot releases, up to Libreboot 20230625. The only
modification that ich9gen permitted was to change the MAC address, and ifdtool
can set read-only mode via `--unlock` argument on a ROM, so ich9utils was a
moving (read: not moving) part that basically did the same thing as providing
static images.
The initial plan was to rewrite ich9utils in a cleaner coding style, like that
used in nvmutil, but then it was decided instead that ich9utils would be
scrapped.
Anyway, ich9utils documentation:
Introduction
============
The `ich9utils` utility from nonGeNUine Boot is used to manipulate Intel Flash
The `ich9utils` utility from Canoeboot is used to manipulate Intel Flash
Descriptors for ICH9M on laptops such as ThinkPad X200 or T400. Specifically,
the `ich9gen` utility can generate 12KiB descriptor+GbE files for inserting
into the start of a ROM, where everything after that is the BIOS region. These
are special descriptors with the Intel ME region disabled, and Intel ME itself
fully disabled.
ich9utils is handled by the `gbmk` (non**G**eNUine**B**oot**M**a**K**e) build system, and the code
ich9utils is handled by the `cbmk` (**C**anoe**B**oot **M**a**K**e) build system, and the code
itself is hosted in that same repository. You can check the Git repositories
linked on [../../git.md](../../git.md) if you wish to download and use it.
@ -27,7 +43,7 @@ It is very *uncommon*, on GM45/ICH9M systems, to have an Intel Flash Descriptor
and GbE but *without* an Intel ME. On *most* of these systems (without GNU
Boot or coreboot), there is either descriptor+GbE+ME+BIOS or just BIOS,
where on systems with just the BIOS region an Intel GbE NIC is not present.
In nonGeNUine Boot, we provide descriptor+GbE images with Intel ME
In Canoeboot, we provide descriptor+GbE images with Intel ME
disabled and not present in the ROM; this enables the Intel GbE NIC to be used,
while not having an Intel ME present. A consequence of this is that the
malicious features of ME (such as AMT) are not present, however the Intel ME
@ -60,22 +76,12 @@ Another project: <http://io.netgarage.org/me/>
ich9utils
=========
You can find `ich9utils` on the [Git page](../../git.md) or you can download
`gbmk` from the same page and run the following command in there:
You can find `ich9utils` on the [Libreboot Git page](https://libreboot.org/git.html) or you can download
`lbmk` from the same page at an under revision (around Libreboot 20230625 or
so), and find it under `util/ich9utils/`.
./build module ich9utils
You may also find it in the source code tar archives, on releases.
In `gbmk`, you can use the following command to generate descriptors:
./build descriptors ich9m
The nonGeNUine Boot build system will use the descriptors under `descriptors/ich9m`
when building ROM images for these machines.
Alternatively, you can just clone `ich9utils` directly and run `make` in the
directory, and run the `ich9gen` program directly.
Go in there and type `make` to get the binaries: `ich9deblob`, `ich9gen`
and `ich9show`.
ICH9 show utility {#ich9show}
================
@ -94,6 +100,11 @@ to use a custom macaddress, you can supply an argument like so:
ich9gen --macaddress 00:1f:16:80:80:80
**WARNING: ich9gen's `--macaddress` functionality does NOT check for all-zero
MAC addresses, nor does it prevents multicast addresses. A valid MAC address
is non-zero, and unicast. This is why you should use `nvmutil` because it does
this check.**
The above MAC address is just an example. It is recommended that you use the
MAC address officially assigned to your NIC.
@ -106,11 +117,14 @@ Three new files will be created:
- `ich9fdgbe_16m.bin`: this is for GM45 laptops with the 16MB flash
chip.
**NOTE: You can also use the `--lock` and `--unlock` arguments in ifdtool, to
accomplish the same result of locking or unlocking a descriptor.**
These files contain the descriptor+GbE region and are suitable for systems
that have an Intel GbE NIC present. The flash regions (as defined by the
Intel Flash Descriptor) are set *read-write* which means that you can also
re-flash using `flashrom -p internal` in your operating system running on
that machine. This is the default setup used when nonGeNUine Boot's build system
that machine. This is the default setup used when Canoeboot's build system
compiles ROM images.
Alternative versions of these files are also created, which have `ro` in the
@ -123,27 +137,27 @@ The region setup created by these descriptors is as follows:
* First 4KiB of flash is: Intel Flash Descriptor
* Next 8KiB after Descriptor: Intel GbE region
* Rest of the flash, after GbE: BIOS region (BIOS region will have nonGeNUine Boot)
* Rest of the flash, after GbE: BIOS region (BIOS region will have Canoeboot)
The GbE region contains configuration data for your Intel GbE NIC. You can
find information about this in Intel datasheets, and it is very well described
in the `ich9utils` source code.
Assuming that your nonGeNUine Boot image is named **nongenuineboot.rom**, copy the
file to where **nongenuineboot.rom** is located and then insert the
Assuming that your Canoeboot image is named **canoeboot.rom**, copy the
file to where **canoeboot.rom** is located and then insert the
descriptor+gbe file into the ROM image.
For 16MiB flash chips:
dd if=ich9fdgbe_16m.bin of=nongenuineboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_16m.bin of=canoeboot.rom bs=12k count=1 conv=notrunc
For 8MiB flash chips:
dd if=ich9fdgbe_8m.bin of=nongenuineboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_8m.bin of=canoeboot.rom bs=12k count=1 conv=notrunc
For 4MiB flash chips:
dd if=ich9fdgbe_4m.bin of=nongenuineboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_4m.bin of=canoeboot.rom bs=12k count=1 conv=notrunc
If you wish to have read-only flash (write protected flash), substitute the
above examples with descriptor+GbE images that have `ro` in the filename. RO
@ -160,13 +174,13 @@ will just supply a descriptor-less setup. Those GbE-less descriptor images
created by `ich9gen` are only 4KiB in size, and should *never be used* except
for fun, like, basically shits and/or giggles.
For shits and giggles, R500 ROM images in nonGeNUine Boot use these no-GbE descriptor
For shits and giggles, R500 ROM images in Canoeboot use these no-GbE descriptor
images generated by ich9gen. However, a descriptorless setup would also work
just fine. ThinkPad R500 doesn't have an Intel PHY in it, and it instead uses
a Broadcom NIC for ethernet. In descriptorless mode, ICH9M works very similarly
to older ICH7 chipsets.
Your nongenuineboot.rom image is now ready to be flashed on the system. Refer
Your canoeboot.rom image is now ready to be flashed on the system. Refer
back to [../install/\#flashrom](../install/#flashrom) for how to flash
it.
@ -182,7 +196,7 @@ Read on for more information. Use the `ro` files mentioned below, and your
flash will be read-only in software (you can still externally re-flash and read
the contents of flash).
For ease of use, nonGeNUine Boot provides ROMs that are read-write by default. In
For ease of use, Canoeboot provides ROMs that are read-write by default. In
practise, you can boot a GNU+Linux kernel with access to lower memory disabled
which will make software re-flashing impossible (unless you reboot with such
memory protections disabled, e.g. `iomem=relaxed` kernel parameter).
@ -229,16 +243,16 @@ appear, if no GbE region was detected inside the ROM image. This is
usually the case, when a discrete NIC is used (eg Broadcom) instead of
Intel. Only the Intel NICs need a GbE region in the flash chip.
Assuming that your nonGeNUine Boot image is named **nongenuineboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **nongenuineboot.rom** is located
Assuming that your Canoeboot image is named **canoeboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **canoeboot.rom** is located
and then run:
dd if=deblobbed_descriptor.bin of=nongenuineboot.rom bs=12k count=1 conv=notrunc
dd if=deblobbed_descriptor.bin of=canoeboot.rom bs=12k count=1 conv=notrunc
Alternatively, if you got a the **deblobbed\_4kdescriptor.bin** file (no
GbE defined), do this:
dd if=deblobbed_4kdescriptor.bin of=nongenuineboot.rom bs=4k count=1 conv=notrunc
dd if=deblobbed_4kdescriptor.bin of=canoeboot.rom bs=4k count=1 conv=notrunc
(it's very unlikely that you would ever see this. Descriptor without GbE is
very rare, probably non-existant, but theoretically possible and this functionality
@ -261,7 +275,7 @@ build `ich9gen` executable will be able to re-create the very same 12KiB
file from scratch, based on the C structs, this time **without** the
need for a` factory.rom` dump!
You should now have a **nongenuineboot.rom** image containing the correct 4K
You should now have a **canoeboot.rom** image containing the correct 4K
descriptor and 8K gbe regions, which will then be safe to flash. Refer
back to [index.md/\#gm45](index.md/#gm45) for how to flash
it.
@ -291,7 +305,7 @@ Keep the original factory.rom stored safely somewhere):
Use-case: a factory.rom image modified in this way would theoretically
have no flash protections whatsoever, making it easy to quickly switch
between factory/nongenuineboot in software, without ever having to
between factory/canoeboot in software, without ever having to
disassemble and re-flash externally unless you brick the device.
The sections below are adapted from (mostly) IRC logs related to early
@ -313,7 +327,7 @@ Early notes {#early_notes}
of disabling the descriptor.
- **and the location of GPIO33 on the x200s: (was an external link.
Putting it here instead)**
[https://avgnu.vimuser.org/x200/gpio33_location.jpg](https://avgnu.vimuser.org/x200/gpio33_location.jpg) -
[https://av.canoeboot.org/x200/gpio33_location.jpg](https://av.canoeboot.org/x200/gpio33_location.jpg) -
it's above the number 7 on TP37 (which is above the big intel chip
at the bottom)
- The ME datasheet may not be for the mobile chipsets but it doesn't
@ -439,7 +453,7 @@ way through the 8K area, and the rest is all 0xFF. This is all
documented in the datasheet.
The GBe region starts at 0x20A000 bytes from the \*end\* of a factory
image and is 0x2000 bytes long. In nonGeNUine Boot (deblobbed) the descriptor
image and is 0x2000 bytes long. In Canoeboot (deblobbed) the descriptor
is set to put gbe directly after the initial 4K flash descriptor. So the
first 4K of the ROM is the descriptor, and then the next 8K is the gbe
region.
@ -460,7 +474,7 @@ not making this stuff up...
regions on the X200 factory.rom dumps. The checksums of the backup
regions match BABA, however. We think `0xBABA` is the only correct checksum,
because those other, similar checksums were only ever found in the "backup"
GbE regions on factory ROM dumps. In nonGeNUine Boot, we simply use `0xBABA` and
GbE regions on factory ROM dumps. In Canoeboot, we simply use `0xBABA` and
ensure that both 4KiB regions in GbE NVM have that checksum.
By default, the X200 (as shipped by Lenovo) actually has an invalid main
@ -481,7 +495,7 @@ Flash descriptor region {#flash_descriptor_region}
<http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf>
from page 850 onwards. This explains everything that is in the flash
descriptor, which can be used to understand what nonGeNUine Boot is doing
descriptor, which can be used to understand what Canoeboot is doing
about modifying it.
How to deblob *manually*:
@ -505,7 +519,7 @@ There's an interesting parameter called 'ME Alternate disable', which
allows the ME to only handle hardware errata in the southbridge, but
disables any other functionality. This is similar to the 'ignition' in
the 5 series and higher but using the standard firmware instead of a
small 128K version. Useless for nonGeNUine Boot, though.
small 128K version. Useless for Canoeboot, though.
To deblob GM45, you chop out the platform and ME regions and correct the
addresses in flReg1-4. Then you set meDisable to 1 in ICHSTRAP0 and
@ -524,7 +538,7 @@ How to patch the descriptor from the factory.rom dump
- Then it can be dd'd into the first 12K part of a coreboot image.
- the GBe region always starts 0x20A000 bytes from the end of the ROM
This means that nonGeNUine Boot's descriptor region will simply define the
This means that Canoeboot's descriptor region will simply define the
following regions:
- descriptor (4K)
@ -542,8 +556,8 @@ If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F.
platform data partition in boot flash (factory.rom / lenovo bios) {#platform_data_region}
-----------------------------------------------------------------
Basically useless for nonGeNUine Boot, since it appears to be a blob. Removing
it didn't cause any issues in nonGeNUine Boot. We think it's just random data that
Basically useless for Canoeboot, since it appears to be a blob. Removing
it didn't cause any issues in Canoeboot. We think it's just random data that
the manufacturer can put there, to use in their firmware. Intel datasheets seem
to suggest that the platform region serves no specific function except to
provide a region in flash for the hardware manufacturer to use, for whatever

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

@ -3,7 +3,7 @@ title: Installation instructions
x-toc-enable: true
...
This section relates to installing nonGeNUine Boot on supported targets.
This section relates to installing Canoeboot on supported targets.
NOTE: if running `flashrom -p internal` for software based flashing, and you
get an error related to `/dev/mem` access, you should reboot with
@ -13,11 +13,11 @@ has `CONFIG_STRICT_DEVMEM` not enabled.
PRECAUTIONS
===========
nonGeNUine Boot flashing can be risky business. Please ensure that you have external
Canoeboot flashing can be risky business. Please ensure that you have external
flashing equipment, in case anything goes wrong. The general rule of thumb with
firmware is this: if it's non-free, replace it, but if you're already running
free firmware and it works nicely for you, you do not need to update it.
However, you might want to tweak it or try out newer releases of nonGeNUine Boot if
However, you might want to tweak it or try out newer releases of Canoeboot if
they have bug fixes for your board, and/or new security fixes.
If you're already running libre firmware on your board, you should decide for
@ -31,7 +31,7 @@ Init types and display mode
---------------------------
NOTE: regardless of init type, on desktops, an external/add-on GPU can always
be used. On laptop hardware in nonGeNUine Boot, libgfxinit will always be used. On
be used. On laptop hardware in Canoeboot, libgfxinit will always be used. On
desktop/server hardware, if available, libgfxinit will also always be used by
default (but in that setup, SeaBIOS can be used if you want to use an add-on
graphics card, e.g. on KCMA-D8, KGPE-D16, GA-G41M-ES2L)
@ -63,11 +63,11 @@ int10h text mode is used on startup.
### vgarom
NOTE: no configs in nonGeNUine Boot are currently available that use this method.
NOTE: no configs in Canoeboot are currently available that use this method.
With this method, coreboot is finding, loading and executing a VGA option ROM
for your graphics hardware. This would not be done on laptops, because that
implies supplying non-free binary blobs in nonGeNUine Boot, so this setup would only
implies supplying non-free binary blobs in Canoeboot, so this setup would only
ever be provided on desktop hardware where no GPU exists or where it is
desirable for you to use an external/add-on graphics card
@ -91,7 +91,7 @@ In this setup, coreboot is neither implementing libgfxinit / native graphics
initialization nor is it finding/loading/executing VGA option ROMs. In this
setup, SeaBIOS would most likely be used for that.
The `normal` setup is supported in the nonGeNUine Boot build system, but not
The `normal` setup is supported in the Canoeboot build system, but not
currently used. It is there for desktop hardware that will be added in the
future, where those desktop boards do not have an onboard GPU and therefore an
add-on GPU is always used..
@ -144,7 +144,7 @@ carefully.
Run flashrom on host CPU
------------------------
You can simply take any ROM image from the nonGeNUine Boot project, and flash it.
You can simply take any ROM image from the Canoeboot project, and flash it.
Boot a GNU+Linux distribution on the target device, and install flashrom.
In some cases, this is not possible or there are other considerations. Please
@ -169,7 +169,7 @@ ensure that you get the same checksums. Check each dump using `sha1sum`
How to erase and rewrite the chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w nongenuineboot.rom
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w canoeboot.rom
If you are re-flashing a GM45+ICH9M laptop (e.g. ThinkPad X200/X200S/X200T,
T400, T500, R400, W500 etc - but not R500), you should run the ich9gen utility
@ -201,7 +201,7 @@ the sections below:
#### DELL Latitute E6400 laptop (easy to flash, similar to X200/T400)
See: [Dell Latitute E6400 nonGeNUine Boot Installation Guide](e6400.md)
See: [Dell Latitute E6400 Canoeboot Installation Guide](e6400.md)
#### ThinkPad X200/T400/T500/W500/R400/R500 vendor BIOS
@ -222,7 +222,7 @@ Intel NIC.
[You must flash it externally](spi.md)
D410PT is more or less the same board as D510MO, but we would like more info
about this board. If you have a D410PT mainboard, please contact the nonGeNUine Boot
about this board. If you have a D410PT mainboard, please contact the Canoeboot
project via IRC and ping `leah` before you flash it. When you do so, please
reference this paragraph on this web page.
@ -235,7 +235,7 @@ and you must flash both chips. Refer to the guide:\
#### Macbook1,1 running non-free Apple EFI firmware
This laptop requires external flashing. Remove the mainboard and refer to
the [external flashing guide](spi.md); if nonGeNUine Boot is already running, you
the [external flashing guide](spi.md); if Canoeboot is already running, you
can flash internally.
MacBook2,1 can be flashed internally.
@ -267,7 +267,7 @@ example of the push pin as a proof of concept:
NOTE: If BIOS password auth is enabled, you can clear it by shorting pins on
an EEPROM and then resetting the password in Lenovo BIOS, prior to flashing
nonGeNUine Boot. For T60, see:
Canoeboot. For T60, see:
<https://ounapuu.ee/posts/2022/10/13/recovering-password-locked-thinkpad-t60/>
(TODO: link something here for X60)
@ -292,7 +292,7 @@ Download and build flashrom, using the instructions
on [the Git page](../../git.md), and download the `bucts` software using the
notes on that very same page.
You can replace Lenovo BIOS with nonGeNUine Boot, using flashrom running on the host
You can replace Lenovo BIOS with Canoeboot, using flashrom running on the host
CPU. However, there are some considerations.
Firstly, make sure that the yellow CMOS battery is installed, and functioning
@ -315,10 +315,10 @@ can set the machine to boot using that lower 64KiB bootblock, which is
read-write. You do this by setting the BUC.TS register to 1, using the `bucts`
program referenced below.
The nonGeNUine Boot ROM images already have the upper 64KiB bootblock copied to the lower
The Canoeboot ROM images already have the upper 64KiB bootblock copied to the lower
one, so you don't have to worry about copying it yourself.
If you build flashrom using the nonGeNUine Boot build system, there will be three
If you build flashrom using the Canoeboot build system, there will be three
binaries:
* `flashrom`
@ -395,7 +395,7 @@ Assuming that everything went well:
Flash the ROM for a second time. For this second flashing attempt, the upper
64KiB bootblock is now read-write. Use the *unpatched* flashrom binary:
sudo ./flashrom -p internal -w nongenuineboot.rom
sudo ./flashrom -p internal -w canoeboot.rom
To reset bucts, do this:
@ -406,10 +406,10 @@ flashed. It is flashed if flashrom said VERIFIED when running the above
command.
If it said VERIFIED, shut down. If it didn't say VERIFIED, make sure bucts is
still set to 1, and consult the nonGeNUine Boot project on IRC for advice, and avoid
still set to 1, and consult the Canoeboot project on IRC for advice, and avoid
shutting down your system until you get help.
If all went well, nonGeNUine Boot should now be booting and you should be able to
If all went well, Canoeboot should now be booting and you should be able to
boot into your operating system.
If you messed up, there are external flashing instructions. See main navigation
@ -436,7 +436,7 @@ Refer to the following article:\
DELL Latitude E6400 laptop (easy to flash, similar to X200/T400)
-------------------------
See: [Dell Latitute E6400 nonGeNUine Boot Installation Instructions](e6400.md)
See: [Dell Latitute E6400 Canoeboot Installation Instructions](e6400.md)
ASUS KFSN4-DRE
--------------
@ -455,7 +455,7 @@ TARGET: Apple Macbook2,1, Macbook1,1 and iMac5,2 (i945 platform)
----------------------------------------------------------------
iMac5,2 is essentially the same board as Macbook2,1, and it is compatible with
nonGeNUine Boot.
Canoeboot.
Refer to the following article:\
[Macbook2,1 and MacBook1,1 installation guide](../hardware/macbook21.md)

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

@ -3,12 +3,12 @@ title: KGPE-D16 external flashing instructions
x-toc-enable: true
...
These will be re-added to nonGeNUine Boot at a later date, once proper testing
These will be re-added to Canoeboot at a later date, once proper testing
has been done.
Initial flashing instructions for KGPE-D16.
This guide is for those who want nonGeNUine Boot on their ASUS KGPE-D16
This guide is for those who want Canoeboot on their ASUS KGPE-D16
motherboard, while they still have the proprietary ASUS BIOS present.
This guide can also be followed (adapted) if you brick you board, to
know how to recover.
@ -27,6 +27,6 @@ External programmer
Refer to [spi.md](spi.md) for a guide on how to re-flash externally.
The flash chip is in a PDIP 8 socket (SPI flash chip) on the
motherboard, which you take out and then re-flash with nonGeNUine Boot, using
motherboard, which you take out and then re-flash with Canoeboot, using
the programmer. *DO NOT* remove the chip with your hands. Use a chip
extractor tool.

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

@ -4,7 +4,8 @@ x-toc-enable: true
...
This software was inherited from Libreboot, when we forked it to create
nonGeNUine Boot.
Censored Libreboot 20230710 and nonGeNUine Boot 20230717, which then became
the Canoeboot 20231026 release; subsequent releases will be called Canoeboot.
With this software, you can change the MAC address inside GbE regions
on any system that uses an Intel Flash Descriptor.
@ -15,8 +16,8 @@ Continue reading...
Introduction
============
This is the manual for `nvmutil`, included in the nonGeNUine Boot,
build system (gbmk) under `util/nvmutil/`. This program lets you modify
This is the manual for `nvmutil`, included in the Canoeboot,
build system (cbmk) under `util/nvmutil/`. This program lets you modify
the MAC address, correct/verify/invalidate checksums,
swap/copy and dump regions on Intel PHY NVM images,
which are small binary configuration files that go
@ -26,7 +27,7 @@ This software is largely targeted at coreboot users,
but it can be used on most modern Intel systems, or
most systems from about 2008/2009 onwards.
NOTE: nonGeNUine Boot X200/X200T/X200S/T400/T400S/T500/W500/R400
NOTE: Canoeboot X200/X200T/X200S/T400/T400S/T500/W500/R400
users should know that this software does *not*
replace `ich9gen`, because that program generates entire
ICH9M IFD+GbE regions, in addition to letting you set the
@ -45,8 +46,8 @@ using `nvmutil`.
How to download newer versions
==============================
Simply pull down the latest changes in `gbmk.git`. The `nvmutil`
software is part of our nonGeNUine Boot build system, which we called `gbmk`,
Simply pull down the latest changes in `cbmk.git`. The `nvmutil`
software is part of our Canoeboot build system, which we called `cbmk`,
short for non**G**eNUine**B**oot**M**a**K**e.
More info about git:
@ -136,7 +137,7 @@ them together:
cat spi1.rom spi2.rom > rom.bin
If your GbE region is locked (per IFD settings), you can dump
and flash it using external flashing equipment. The nonGeNUine Boot
and flash it using external flashing equipment. The Canoeboot
project has a handy guide for this; it can be used for reading
from and writing to the chip. See: [spi.md](spi.md)
@ -237,7 +238,7 @@ How to compile source code
==========================
The nvmutil source code is located under `util/nvmutil/` in the
gbmk repository. A makefile is included there, for you to build an
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

82
site/docs/install/r400_external.md
View File

@ -5,18 +5,18 @@ x-toc-enable: true
**If you haven't bought an R400 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Initial flashing instructions for R400.
This guide is for those who want nonGeNUine Boot on their ThinkPad R400 while
This guide is for those who want Canoeboot on their ThinkPad R400 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your R400, to know how to recover.
Before following this section, please make sure to setup your nonGeNUine Boot
Before following this section, please make sure to setup your Canoeboot
ROM properly first. Although ROM images are provided pre-built in
nonGeNUine Boot, there are some modifications that you need to make to the one
Canoeboot, there are some modifications that you need to make to the one
you chose before flashing. (instructions referenced later in this guide)
Serial port {#serial_port}
@ -31,7 +31,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:R400) has a list of
CPUs for this system. The Core 2 Duo P8400 and P8600 are believed to
work in nonGeNUine Boot. The Core 2 Duo T9600 was confirmed to work, so the
work in Canoeboot. The Core 2 Duo T9600 was confirmed to work, so the
T9400 probably also works. *The Core 2 Duo T5870/5670 and Celeron M
575/585 are untested!*
@ -49,7 +49,7 @@ Intel GPU; this is referred to as "Dual Graphics" (previously
you can specify that the system will use one or the other (but not
both).
nonGeNUine Boot is known to work on systems with only the Intel GPU, using
Canoeboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -80,84 +80,84 @@ Disassembly
-----------
Remove all screws:\
![](https://avgnu.vimuser.org/r400/0000.jpg)\
![](https://av.canoeboot.org/r400/0000.jpg)\
Remove the HDD and optical drive:\
![](https://avgnu.vimuser.org/r400/0001.jpg)\
![](https://av.canoeboot.org/r400/0001.jpg)\
Remove the hinge screws:\
![](https://avgnu.vimuser.org/r400/0002.jpg) ![](https://avgnu.vimuser.org/r400/0003.jpg)
![](https://av.canoeboot.org/r400/0002.jpg) ![](https://av.canoeboot.org/r400/0003.jpg)
Remove the palm rest and keyboard:\
![](https://avgnu.vimuser.org/r400/0004.jpg) ![](https://avgnu.vimuser.org/r400/0005.jpg)
![](https://av.canoeboot.org/r400/0004.jpg) ![](https://av.canoeboot.org/r400/0005.jpg)
Remove these screws, and then remove the bezel:\
![](https://avgnu.vimuser.org/r400/0006.jpg) ![](https://avgnu.vimuser.org/r400/0007.jpg)
![](https://av.canoeboot.org/r400/0006.jpg) ![](https://av.canoeboot.org/r400/0007.jpg)
Remove the speaker screws, but don't remove the speakers yet (just set
them loose):\
![](https://avgnu.vimuser.org/r400/0008.jpg) ![](https://avgnu.vimuser.org/r400/0009.jpg)
![](https://avgnu.vimuser.org/r400/0010.jpg)
![](https://av.canoeboot.org/r400/0008.jpg) ![](https://av.canoeboot.org/r400/0009.jpg)
![](https://av.canoeboot.org/r400/0010.jpg)
Remove these screws, and then remove the metal plate:\
![](https://avgnu.vimuser.org/r400/0011.jpg) ![](https://avgnu.vimuser.org/r400/0012.jpg)
![](https://avgnu.vimuser.org/r400/0013.jpg)
![](https://av.canoeboot.org/r400/0011.jpg) ![](https://av.canoeboot.org/r400/0012.jpg)
![](https://av.canoeboot.org/r400/0013.jpg)
Remove the antennas from the wifi card, and then start unrouting them:\
![](https://avgnu.vimuser.org/r400/0014.jpg) ![](https://avgnu.vimuser.org/r400/0015.jpg)
![](https://avgnu.vimuser.org/r400/0016.jpg) ![](https://avgnu.vimuser.org/r400/0017.jpg)
![](https://avgnu.vimuser.org/r400/0018.jpg) ![](https://avgnu.vimuser.org/r400/0019.jpg)
![](https://av.canoeboot.org/r400/0014.jpg) ![](https://av.canoeboot.org/r400/0015.jpg)
![](https://av.canoeboot.org/r400/0016.jpg) ![](https://av.canoeboot.org/r400/0017.jpg)
![](https://av.canoeboot.org/r400/0018.jpg) ![](https://av.canoeboot.org/r400/0019.jpg)
Disconnect the LCD cable from the motherboard:\
![](https://avgnu.vimuser.org/r400/0020.jpg) ![](https://avgnu.vimuser.org/r400/0021.jpg)
![](https://avgnu.vimuser.org/r400/0022.jpg) ![](https://avgnu.vimuser.org/r400/0023.jpg)
![](https://av.canoeboot.org/r400/0020.jpg) ![](https://av.canoeboot.org/r400/0021.jpg)
![](https://av.canoeboot.org/r400/0022.jpg) ![](https://av.canoeboot.org/r400/0023.jpg)
Remove the hinge screws, and then remove the LCD panel:\
![](https://avgnu.vimuser.org/r400/0024.jpg) ![](https://avgnu.vimuser.org/r400/0025.jpg)
![](https://avgnu.vimuser.org/r400/0026.jpg) ![](https://avgnu.vimuser.org/r400/0027.jpg)
![](https://av.canoeboot.org/r400/0024.jpg) ![](https://av.canoeboot.org/r400/0025.jpg)
![](https://av.canoeboot.org/r400/0026.jpg) ![](https://av.canoeboot.org/r400/0027.jpg)
Remove this:\
![](https://avgnu.vimuser.org/r400/0028.jpg) ![](https://avgnu.vimuser.org/r400/0029.jpg)
![](https://av.canoeboot.org/r400/0028.jpg) ![](https://av.canoeboot.org/r400/0029.jpg)
Remove this long cable (there are 3 connections):\
![](https://avgnu.vimuser.org/r400/0030.jpg) ![](https://avgnu.vimuser.org/r400/0031.jpg)
![](https://avgnu.vimuser.org/r400/0032.jpg) ![](https://avgnu.vimuser.org/r400/0033.jpg)
![](https://av.canoeboot.org/r400/0030.jpg) ![](https://av.canoeboot.org/r400/0031.jpg)
![](https://av.canoeboot.org/r400/0032.jpg) ![](https://av.canoeboot.org/r400/0033.jpg)
Disconnect the speaker cable, and remove the speakers:\
![](https://avgnu.vimuser.org/r400/0034.jpg)
![](https://av.canoeboot.org/r400/0034.jpg)
Remove the heatsink screws, remove the fan and then remove the
heatsink/fan:\
![](https://avgnu.vimuser.org/r400/0035.jpg) ![](https://avgnu.vimuser.org/r400/0036.jpg)
![](https://avgnu.vimuser.org/r400/0037.jpg) ![](https://avgnu.vimuser.org/r400/0038.jpg)
![](https://av.canoeboot.org/r400/0035.jpg) ![](https://av.canoeboot.org/r400/0036.jpg)
![](https://av.canoeboot.org/r400/0037.jpg) ![](https://av.canoeboot.org/r400/0038.jpg)
Remove the NVRAM battery:\
![](https://avgnu.vimuser.org/r400/0039.jpg) ![](https://avgnu.vimuser.org/r400/0040.jpg)
![](https://av.canoeboot.org/r400/0039.jpg) ![](https://av.canoeboot.org/r400/0040.jpg)
Remove this screw:\
![](https://avgnu.vimuser.org/r400/0041.jpg) ![](https://avgnu.vimuser.org/r400/0042.jpg)
![](https://av.canoeboot.org/r400/0041.jpg) ![](https://av.canoeboot.org/r400/0042.jpg)
Disconnect the AC jack:\
![](https://avgnu.vimuser.org/r400/0043.jpg) ![](https://avgnu.vimuser.org/r400/0044.jpg)
![](https://av.canoeboot.org/r400/0043.jpg) ![](https://av.canoeboot.org/r400/0044.jpg)
Remove this screw and then remove what is under it:\
![](https://avgnu.vimuser.org/r400/0045.jpg)
![](https://av.canoeboot.org/r400/0045.jpg)
Remove this:\
![](https://avgnu.vimuser.org/r400/0046.jpg)
![](https://av.canoeboot.org/r400/0046.jpg)
Lift the motherboard (which is still inside the cage) from the side on
the right, removing it completely:\
![](https://avgnu.vimuser.org/r400/0047.jpg) ![](https://avgnu.vimuser.org/r400/0048.jpg)
![](https://av.canoeboot.org/r400/0047.jpg) ![](https://av.canoeboot.org/r400/0048.jpg)
Remove all screws, marking each hole so that you know where to re-insert
them. You should place the screws in a layout corresponding to the order
that they were in before removal: ![](https://avgnu.vimuser.org/r400/0049.jpg)
![](https://avgnu.vimuser.org/r400/0050.jpg)
that they were in before removal: ![](https://av.canoeboot.org/r400/0049.jpg)
![](https://av.canoeboot.org/r400/0050.jpg)
Remove the motherboard from the cage, and the SPI flash chip will be
next to the memory slots:\
![](https://avgnu.vimuser.org/r400/0051.jpg) ![](https://avgnu.vimuser.org/r400/0052.jpg)
![](https://av.canoeboot.org/r400/0051.jpg) ![](https://av.canoeboot.org/r400/0052.jpg)
Now, you should be ready to install nonGeNUine Boot.
Now, you should be ready to install Canoeboot.
Read [this article](spi.md) to learn how you may flash the chip, which is near
to the RAM.
@ -173,7 +173,7 @@ When re-installing the heatsink, you must first clean off all old paste
with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much
better than the default paste used on these systems.
![](https://avgnu.vimuser.org/t400/paste.jpg)
![](https://av.canoeboot.org/t400/paste.jpg)
NOTE: the photo above is for illustration purposes only, and does not
show how to properly apply the thermal paste. Other guides online detail
@ -198,13 +198,13 @@ be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://avgnu.vimuser.org/t400/memory.jpg)
![](https://av.canoeboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://avgnu.vimuser.org/t400/boot0.jpg) ![](https://avgnu.vimuser.org/t400/boot1.jpg)
![](https://av.canoeboot.org/t400/boot0.jpg) ![](https://av.canoeboot.org/t400/boot1.jpg)
Now [install GNU+Linux](../gnulinux/).

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

@ -6,7 +6,7 @@ x-toc-enable: true
This guide will teach you how to use various tools for externally reprogramming
a 25xx NOR flash via SPI protocol. This is the most common type of flash IC for
computers that coreboot runs on. Almost every system currently supported by
nonGeNUine Boot uses this type of boot flash; the only exception is ASUS KFSN4-DRE,
Canoeboot uses this type of boot flash; the only exception is ASUS KFSN4-DRE,
which uses LPC flash in a PLCC32 socket, which you can simply hot-swap after
booting the vendor firmware, and then flash internally. Simple!
@ -14,21 +14,22 @@ We will be using
the [flashrom](https://flashrom.org/Flashrom) software which is written to
dump, erase and rewrite these flash chips.
nonGeNUine Boot currently documents how to use these SPI programmers:
Canoeboot currently documents how to use these SPI programmers:
* Raspberry Pi (RPi)
* Raspberry Pi (RPi) single-board computers
* BeagleBone Black (BBB)
* Libre Computer 'Le Potato'
Many other SPI programmers exist. More of them will be documented on this page,
at a date in the future. You can otherwise figure it out on your own; certain
parts of this page are still useful, even if you're using a programmer that
nonGeNUine Boot does not yet document.
Canoeboot does not yet document.
Most systems in nonGeNUine Boot have to be re-flashed externally, using instructions
Most systems in Canoeboot have to be re-flashed externally, using instructions
on this and similar guides, the first time you flash. However, on all currently
supported systems, it's possible that you can re-flash *internally* when
nonGeNUine Boot is running.
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
@ -37,10 +38,78 @@ from GNU+Linux, with flashrom.
*This* guide that you're reading now is for using an *external* programmer. It
is called *external* because it's not the *internal* one on your mainboard.
+Raspberry Pi Pico
+=================
![Left to right: Raspberry Pi Pico and Pico H](https://av.canoeboot.org/rpi_pico/two_picos.webp)
If you don't already have a programmer, get this one! It's well engineered,
safe, and costs just $5 with headers pre-soldered (Raspberry Pi Pico H).
Additionally, all the software running on it is free, down to the full
[Boot ROM](https://github.com/raspberrypi/pico-bootrom). The wireless
versions (Pico W & Pico WH) need vendor firmware to use the Wi-Fi chip,
but that is not needed for following this guide.
A Pico has proper 3.3V logic levels, unlike a ch341a. Which means it won't
destroy your board by sending 5V to it. If you have a 1.8V flash chip,
you need to add a logic level converter.
First, connect just the Pico to your computer with a micro-USB cable.
Mount it like any other USB flash drive. If it isn't detected, you might need
to press the BOOTSEL button while you plug it in (this forces it into the
bootloader mode).
You can download the serprog firmware here:\
<https://codeberg.org/libreboot/pico-serprog>\
or here:\
<https://notabug.org/libreboot/pico-serprog>
Copy the file `rpi-pico-serprog.uf2` into your Pico. To build this firmware, you
could build it yourself or you could also clone `cbmk.git` and [install build
dependencies](..//build/#first-install-build-dependencies), then inside cbmk,
do:
./build serprog rp2040 pico
or for the W version:
./build serprog rp2040 pico_w
This will automatically build the rpi-pico firmware, and the file will be
at `bin/serprog_rp2040/serprog_pico.uf2`. This binary is provided
pre-compiled in Canoeboot 20231026 and newer releases.
Disconnect the Pico and proceed to wire it to your
[flash chip](/docs/install/spi.html#identify-which-flash-type-you-have).
![Raspberry Pi Pico pinout, when using the firmware linked
above](https://av.canoeboot.org/rpi_pico/pinout_serprog.png)
![A Raspberry Pi Pico connected to a SOIC16 flash
chip](https://av.canoeboot.org/rpi_pico/soic16_x200.webp)
Headers were manually soldered on the top side, and the plastic packaging
was repurposed as an insulating base. These might be nice to have, but by no
means necessary. If your headers are on the other side, just keep in mind
that the pinouts are as seen from above.
Now run (as root) `dmesg -wH`. When you plug in the Pico, a line like this
will appear:
[453876.669019] cdc_acm 2-1.2:1.0: ttyACMx: USB ACM device
Take note of the ttyACMx. Flashrom is now usable
(substitute ttyACMx with what you observed earlier).
flashrom -p serprog:dev=/dev/ttyACMx,spispeed=16M
spispeed=32M usually works, but since it's not much faster it's probably
not worth it. The 12Mbps USB port is limiting the actual speed here.
Do not use CH341A!
==================
NOR flashes on nonGeNUine Boot systems run on 3.3V DC or 1.8V DC, and this includes
NOR flashes on Canoeboot systems run on 3.3V DC or 1.8V DC, and this includes
data lines. CH341A has 5V logic levels on data lines, which will damage your
SPI flash and also the southbridge that it's connected to, plus anything else
that it's connected to.
@ -95,8 +164,8 @@ tell them why the CH341A is bad.
These photos show both modifications (3.3v logic and WP/HOLD pull-up
resistors) performed, on the black CH341A:\
<img tabindex=1 src="https://avgnu.vimuser.org/ch341a/0000_th.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/ch341a/0000.jpg" /></span>
<img tabindex=1 src="https://avgnu.vimuser.org/ch341a/0001_th.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/ch341a/0001.jpg" /></span>
<img tabindex=1 src="https://av.canoeboot.org/ch341a/0000_th.jpg" /><span class="f"><img src="https://av.canoeboot.org/ch341a/0000.jpg" /></span>
<img tabindex=1 src="https://av.canoeboot.org/ch341a/0001_th.jpg" /><span class="f"><img src="https://av.canoeboot.org/ch341a/0001.jpg" /></span>
The green version (not shown above) may come with 3.3v logic already wired, but
still needs to have pull-up resistors placed for WP/HOLD.
@ -113,12 +182,34 @@ accomplish your goal, which is to read from and/or write to the boot flash.
SOIC8
-----
![](https://avgnu.vimuser.org/chip/soic8.jpg)
![](https://av.canoeboot.org/chip/soic8.jpg)
| Pin | Function |
|-----|----------|
| 1 | CS |
| 2 | MISO |
| 3 | WP |
| 4 | GND |
| 5 | MOSI |
| 6 | CLK |
| 7 | HOLD |
| 8 | VCC |
SOIC16
------
![](https://avgnu.vimuser.org/chip/soic16.jpg)
![](https://av.canoeboot.org/chip/soic16.jpg)
| Pin | Function |
|-----|----------|
| 2 | VCC |
| 3 | HOLD |
| 7 | CS |
| 8 | MISO |
| 9 | WP |
| 10 | GND |
| 15 | MOSI |
| 16 | CLK |
SOIC8 and SOIC16 are the most common types, but there are others:
@ -127,21 +218,24 @@ WSON8
It will be like this on an X200S or X200 Tablet:\
![](https://avgnu.vimuser.org/x200t_flash/X200T-flashchip-location.jpg)
![](https://av.canoeboot.org/x200t_flash/X200T-flashchip-location.jpg)
Pinout is the same as SOIC8 above.
On T400S, it is in this location near the RAM:\
![](https://avgnu.vimuser.org/t400s/soic8.jpg)\
![](https://av.canoeboot.org/t400s/soic8.jpg)\
NOTE: in this photo, the chip has been replaced with SOIC8
DIP8
----
![](https://avgnu.vimuser.org/dip8/dip8.jpg)
![](https://av.canoeboot.org/dip8/dip8.jpg)
Pinout is the same as SOIC8 above.
Supply Voltage
--------------
Historically, all boards that nonGeNUine Boot supports happened to have SPI NOR chips
Historically, all boards that Canoeboot supports happened to have SPI NOR chips
which work at 3.3V DC. With the recent addition of Chromebooks whose chips are
rated for 1.8V DC, this can no longer be assumed.
@ -354,28 +448,27 @@ If you're using a BBB or RPi, you will do this while SSH'd into those.
Flashrom is the software that you will use, for dumping, erasing and rewriting
the contents of your NOR flash.
In the nonGeNUine Boot build system, from the Git repository, you can download and
In the Canoeboot build system, from the Git repository, you can download and
install flashrom. Do this after downloading the
[gbmk Git repository](../../git.md):
[cbmk Git repository](../../git.md):
cd gbmk
cd cbmk
sudo ./build dependencies ubuntu2004
NOTE: debian, arch or void can be written instead of ubuntu2004. the debian
script is also applicable to newer ubuntu versions
./download flashrom
./build module flashrom
./update trees -b flashrom
If the `ubuntu2004` script complains about missing dependencies, just modify
the script and remove those dependencies. The script is located
at `resources/scripts/build/dependencies/ubuntu2004` and it is written for
Ubuntu 20.04, but it should work fine in other GNU+Linux distributions that use
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
the `apt-get` package manager.
A `flashrom/` directory will be present, with a `flashrom` executable inside
of it. If you got an error about missing package when running the dependencies
command above, tweak `resources/scripts/build/dependencies/ubuntu2004`. That
command above, tweak `config/dependencies/ubuntu2004`. That
script downloads and installs build dependencies in apt-get and it is intended
for use on x86-64 systems running Ubuntu 20.04, but it should work in Raspbian
on the Raspberry Pi.
@ -392,10 +485,9 @@ version of this is available, with the same workaround patch, but based on
flashrom 1.3: <https://codeberg.org/Riku_V/whackrom>
If you downloaded the flashrom source code directly, you can go into the
directory and simply type `make`. In the nonGeNUine Boot build system, build
dependencies are documented in script located
at `resources/scripts/build/dependencies/` which you can install
using the `apt-get` software.
directory and simply type `make`. In the Canoeboot build system, build
dependencies are documented in configuration files located
at `config/dependencies/` which you can install.
How to use flashrom
===================
@ -455,11 +547,11 @@ Writing
Next, run this command (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/nongenuineboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/canoeboot.rom
If using BBB:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/nongenuineboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/canoeboot.rom
If using BBB, you may have to use a lower speed than 512. You may also have to
re-flash several times before it works fully.
@ -494,7 +586,7 @@ Do not *disconnect* your chip from the flasher until you've disconnected or
turned off the power source.
BE CAREFUL that you are indeed supplying the appropriate supply voltage to the
chip. SPI flashes on most of the currently supported nonGeNUine Boot hardware run on
chip. SPI flashes on most of the currently supported Canoeboot hardware run on
3.3V DC and logic at that level too. Some of them (at least Chromebooks) can
have chips that run on 1.8V DC. You should make sure to check the part number
and datasheet of the SPI flash chip for the supply voltage it requires. If your
@ -522,7 +614,7 @@ ISP programming and VCC diode
-----------------------------
ISP means in-system programming. It's when you flash a chip that is already
mounted to the mainboard of your computer that you wish to install nonGeNUine Boot
mounted to the mainboard of your computer that you wish to install Canoeboot
on.
It may be beneficial to modify the mainboard so that the SPI flash is powered
@ -556,6 +648,9 @@ the SOIC8/WSON8 if it uses that, and replace with an IC socket (for SOIC8,
WSON8 or DIP8, whatever you want), because then you could easily just insert
the flash into a breadboard when flashing.
TODO: Make a page on canoeboot.org, showing how to do this on all mainboards
supported by canoeboot.
GPIO pins on BeagleBone Black (BBB)
-----------------------------------
@ -573,7 +668,7 @@ This diagram shows the pinout for most modern Pi's and Pi derivatives.
The diagram shows the pins of an RPi on the left and the two SOIC clips
on the left.
![](https://avgnu.vimuser.org/rpi/wiring.webp)
![](https://av.canoeboot.org/rpi/wiring.webp)
GPIO pins on Raspberry Pi (RPi) 26 Pin
-------------------------------
@ -581,7 +676,7 @@ GPIO pins on Raspberry Pi (RPi) 26 Pin
Diagram of the 26 GPIO Pins of the Raspberry Pi Model B (for the Model
B+ with 40 pins, start counting from the right and leave 14 pins):
![](https://avgnu.vimuser.org/rpi/0012.png) ![](https://avgnu.vimuser.org/rpi/0013.png)
![](https://av.canoeboot.org/rpi/0012.png) ![](https://av.canoeboot.org/rpi/0013.png)
Use this as a reference for the other sections in this page, seen below:
@ -617,8 +712,8 @@ SOIC16 wiring diagram (Raspberry Pi)
------------------------------------
RPi GPIO header:\
![](https://avgnu.vimuser.org/rpi/0009.png)
![](https://avgnu.vimuser.org/rpi/0010.png)
![](https://av.canoeboot.org/rpi/0009.png)
![](https://av.canoeboot.org/rpi/0010.png)
BBB P9 header:\
<https://beagleboard.org/static/images/cape-headers.png>
@ -706,7 +801,7 @@ SOIC8/WSON8/DIP8/SOIC16 not mounted to a mainboard
If your system has lower capacity SPI flash, you can upgrade. On *most* systems,
SPI flash is memory mapped and the maximum (in practise) that you can use is a
16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in nonGeNUine Boot have
16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in Canoeboot have
2MiB flash by default, but you can easily upgrade these. Another example is the
ThinkPad X200S, X200 Tablet and T400S, all of which have WSON8 where the best
course of action is to replace it with a SOIC8 flash chip.
@ -751,13 +846,13 @@ SOIC8 is desirable; in that case, you might still want to dump the contents of
the original WSON8.
Here is a SOIC8 in a socket, mounted to a breadboard, for flashing:\
![](https://avgnu.vimuser.org/rpi/soic8_socket.jpg)
![](https://av.canoeboot.org/rpi/soic8_socket.jpg)
Here is a photo of a DIP8 IC:\
![](https://avgnu.vimuser.org/dip8/dip8.jpg)
![](https://av.canoeboot.org/dip8/dip8.jpg)
Here is a photo of a SOIC8 in 1.27mm 208mil SOP to DIP adapter:\
![](https://avgnu.vimuser.org/dip8/sop8todip8.jpg)
![](https://av.canoeboot.org/dip8/sop8todip8.jpg)
NOTE: DIP8 and WSON8-in-socket, and SOIC16-in-socket, are basically the same,
just adapt accordingly.
@ -770,9 +865,9 @@ can just put the 2.54mm pins directly in the DIP8 socket and mount the SOIC8 +
adapter onto that, and solder that. Use quality rosin flux (not acid based)
and good 60/40 or 63/37 leaded solder (don't use lead-free):
![](https://avgnu.vimuser.org/dip8/adapter_breadboard.jpg)
![](https://avgnu.vimuser.org/dip8/adapter.jpg)
![](https://avgnu.vimuser.org/dip8/sop8todip8.jpg)
![](https://av.canoeboot.org/dip8/adapter_breadboard.jpg)
![](https://av.canoeboot.org/dip8/adapter.jpg)
![](https://av.canoeboot.org/dip8/sop8todip8.jpg)
SOIC8/SOIC16 soldered to a mainboard
------------------------------------
@ -795,10 +890,10 @@ resistors needed. You do not need a decoupling capacitor for pin 2 (VCC) either
because the mainboard will already have one.
Here is an example of a test clip connected for SOIC16:\
![](https://avgnu.vimuser.org/rpi/0002.jpg)
![](https://av.canoeboot.org/rpi/0002.jpg)
And here is an example photo for SOIC8:\
![](https://avgnu.vimuser.org/x60/th_bbb_flashing.jpg)
![](https://av.canoeboot.org/x60/th_bbb_flashing.jpg)
DIP8 soldered to the mainboard
------------------------------
@ -811,7 +906,7 @@ for flashing. You might want to de-solder the chip, using a solder vacuum
(extractor) tool, and then you can install a socket in its place. You can then
insert the DIP8 IC into the socket.
In the nonGeNUine Boot project, we have never heard of a board where the DIP8 is
In the Canoeboot project, we have never heard of a board where the DIP8 is
directly soldered. It is almost always mounted in a socket.
Your DIP8 IC has the same pinout as a SOIC8 IC.
@ -827,7 +922,7 @@ can easily damage the pads that way.
WSON8 has the same pinout as SOIC8, but it's a ball mounted QFN (quad flat
pack, no leads). There are no clips for it. Sometimes referred to as QFN8
On all currently supported nonGeNUine Boot hardware, boards that have WSON8 can also
On all currently supported Canoeboot hardware, boards that have WSON8 can also
have a SOIC8 because the pads are long enough to accomodate either type of
chip.
@ -867,13 +962,13 @@ In case you're not comfortable with soldering, we have some excellent videos
linked on the [FAQ page](../../faq.md) which you can watch.
WSON8 IC:\
![](https://avgnu.vimuser.org/rpi/wson8/0001.jpg)
![](https://av.canoeboot.org/rpi/wson8/0001.jpg)
Surround a large area around the chip with layers of kapton tape, and then
aluminium foil. This will act as a heat shield, to reduce the risk of re-flowing
other solder joints (which can make them turn into cold joints, and you risk
knocking them off of the board):\
![](https://avgnu.vimuser.org/rpi/wson8/0002.jpg)\
![](https://av.canoeboot.org/rpi/wson8/0002.jpg)\
Notice that the kapton+foil does not cover the chip itself, or the solder pads.
It's important that these are exposed to the heat.
@ -891,16 +986,16 @@ move freely. While in this state, the solder is fully melted and the chip can
be lifted off with ease.
If you're doing it correctly, the chip will come off within 1 minute, like so:\
![](https://avgnu.vimuser.org/rpi/wson8/0003.jpg)
![](https://av.canoeboot.org/rpi/wson8/0003.jpg)
Add fresh solder to the pads, including the thermal pad:\
![](https://avgnu.vimuser.org/rpi/wson8/0004.jpg)
![](https://av.canoeboot.org/rpi/wson8/0004.jpg)
Now wick it out using a copper braid, dunked in rosin flux:\
![](https://avgnu.vimuser.org/rpi/wson8/0005.jpg)
![](https://av.canoeboot.org/rpi/wson8/0005.jpg)
Ensure that all of the solder is removed:\
![](https://avgnu.vimuser.org/rpi/wson8/0006.jpg)\
![](https://av.canoeboot.org/rpi/wson8/0006.jpg)\
You will notice that one of the pads doesn't have all of the solder removed.
The pad on the top-left in this photo. This is intentional, to show you a
comparison for reference. The other pads are free of solder.
@ -913,13 +1008,13 @@ SPI flasher.
Align the new SOIC8, and tack it in the corner pins. Then solder it fully. Use
lots of flux!\
![](https://avgnu.vimuser.org/rpi/wson8/0007.jpg)\
![](https://av.canoeboot.org/rpi/wson8/0007.jpg)\
A T12-D08 tip is being used in this photo, but a mini chisel, mini hoof or
knife (e.g. T12-K) tip would be ideal.
Ensure that all the joints are perfect. A good solder joint is shiny, and with
concave fillets where the solder has flowed. Observe:\
![](https://avgnu.vimuser.org/rpi/wson8/0008.jpg)
![](https://av.canoeboot.org/rpi/wson8/0008.jpg)
After you're done, use a soft bristle brush and 99.9% isopropyl alcohol to
break up the remaining flux, then soak up the flux using a cloth, while the
@ -942,7 +1037,7 @@ Photos showing a BeagleBone Black are under the normal GNU Free Documentation
license like other pages and images on this website, or you can use them under
the CC-BY-SA 4.0 license if you wish (I, Leah Rowe, own all BBB photos shown
on this page, except for the one on the beaglebone website, and that one is
merely linked here, instead of being hosted on the avgnu.vimuser.org server).
merely linked here, instead of being hosted on the av.canoeboot.org server).
This version of the page is hosted in the `gbwww` git repository, with images
for it hosted in the `gbwww-img` repository (from nonGeNUine Boot).
This version of the page is hosted in the `cbwww` git repository, with images
for it hosted in the `cbwww-img` repository (from Canoeboot).

691
site/docs/install/spi.zh-cn.md Normal file
View File

@ -0,0 +1,691 @@
---
title: 通过 SPI 协议对 25XX NOR flash 进行读/写
x-toc-enable: true
...
本指南将教你怎样使用各种工具，通过 SPI 协议对 25xx NOR flash 进行外部再编程。这是 coreboot 所支持的计算机中，最常见的 flash IC 类型。目前 canoeboot 支持的每个系统，基本都使用这种类型的引导 flash；唯一的例外就是 ASUS KFSN4-DRE，它在 PLCC32 芯片座中使用了 LPC flash，你可以在供应商固件启动后，对其进行热切换，然后再内部刷入。十分简单！
我们会用到 [flashrom](https://flashrom.org/Flashrom) 软件，这个软件可以读出、擦除及重写这些 flash 芯片。
canoeboot 目前记录了这些 SPI 编程器的使用方法：
* Raspberry Pi Pico
* 树莓派（Raspberry Pi，RPi）
* BeagleBone Black（BBB）
* Libre Computer 'Le Potato'
其他的 SPI 编程器还有许多。本页面以后会记载更多的 SPI 编程器。或者你也可以自己弄明白；尽管你用的编程器还没有被 Canoeboot 记载，但这个页面某些部分的信息仍然会很有用。
大部分支持 canoeboot 机器，都需要在第一次刷写的时候，借助这里的教程或是类似教程，对其进行外部再刷写。不过，目前支持的所有机器，你都可以在 canoeboot 运行时，对其进行内部再刷写。
*内部*刷写是指，主机上的 CPU 可以使用板载 SPI 编程器（每个主板都有）对 SPI flash 进行再编程。这可以在 Linux 上使用 flashrom 做到。
你在读的*这个*教程，使用的是*外部*编程器。之所以叫*外部*，是因为用的不是主板上的*内部*编程器。
Raspberry Pi Pico
=================
![Left to right: Raspberry Pi Pico and Pico H](https://av.canoeboot.org/rpi_pico/two_picos.webp)
If you don't already have a programmer, get this one! It's well engineered,
safe, and costs just $5 with headers pre-soldered (Raspberry Pi Pico H).
Additionally, all the software running on it is free, down to the full
[Boot ROM](https://github.com/raspberrypi/pico-bootrom). The wireless
versions (Pico W & Pico WH) need vendor firmware to use the Wi-Fi chip,
but that is not needed for following this guide.
A Pico has proper 3.3V logic levels, unlike a ch341a. Which means it won't
destroy your board by sending 5V to it. If you have a 1.8V flash chip,
you need to add a logic level converter.
First, connect just the Pico to your computer with a micro-USB cable.
Mount it like any other USB flash drive. If it isn't detected, you might need
to press the BOOTSEL button while you plug it in (this forces it into the
bootloader mode).
You can download the serprog firmware here:\
<https://codeberg.org/libreboot/pico-serprog>\
or here:\
<https://notabug.org/libreboot/pico-serprog>
Copy the file `rpi-pico-serprog.uf2` into your Pico. To build this firmware, you
could build it yourself or you could also clone `lbmk.git` and [install build
dependencies](..//build/#first-install-build-dependencies), then inside lbmk,
do:
./build serprog rp2040 pico
or for the W version:
./build serprog rp2040 pico_w
This will automatically build the rpi-pico firmware, and the file will be
at `bin/serprog_rp2040/serprog_pico.uf2`. This binary will be provided
pre-compiled in the next Canoeboot release, after the 20230625 release.
Disconnect the Pico and proceed to wire it to your
[flash chip](/docs/install/spi.html#identify-which-flash-type-you-have).
![Raspberry Pi Pico pinout, when using the firmware linked above](https://av.canoeboot.org/rpi_pico/pinout_serprog.png)
![A Raspberry Pi Pico connected to a SOIC16 flash chip](https://av.canoeboot.org/rpi_pico/soic16_x200.webp)
Headers were manually soldered on the top side, and the plastic packaging
was repurposed as an insulating base. These might be nice to have, but by no
means necessary. If your headers are on the other side, just keep in mind
that the pinouts are as seen from above.
Now run (as root) `dmesg -wH`. When you plug in the Pico, a line like this
will appear:
[453876.669019] cdc_acm 2-1.2:1.0: ttyACMx: USB ACM device
Take note of the ttyACMx. Flashrom is now usable
(substitute ttyACMx with what you observed earlier).
flashrom -p serprog:dev=/dev/ttyACMx,spispeed=16M
spispeed=32M usually works, but since it's not much faster it's probably
not worth it. The 12Mbps USB port is limiting the actual speed here.
不要使用 CH341A！
==================
canoeboot 支持的机器，NOR flash 使用的是 3.3V DC 或 1.8V DC，这也包括了数据线路。CH341A 在数据线路上有 5V 逻辑电平，这会损伤 SPI flash 和它连接的南桥，以及它连接的其它任何东西。
可惜的是，ch341a 编程器非常流行。除非你修复了这个问题，不然千万不要用它。你确实是可以修复它，让数据线路在 3.3v 工作的，只要跟着这里的步骤走：
<https://www.eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/>
现实是，大多数人都不会去修复自己的 ch341a，而是选择去冒这个险，所以本网站不会提供 ch341a 的指南。最好不要使用那个设备。
**那篇 eevblog 没谈论到的一点是：WP/HOLD 引脚（第 3 和第 7 引脚）必须通过上拉电阻保持到高电平，但在 CH341A 上，它们是直接连接到 3.3V DC 的（连接在第 8 引脚上）。建议切断与 WP 和 HOLD 引脚的连接，并使用上拉电阻连接两引脚。1k 到 10k（欧姆）的值应该都可以。**
**如果电流出现浪涌，比如你把夹子连错了导致两个引脚短路的时候，那 WP/HOLD 缺少上拉电阻就会导致 VCC 与接地端之间短路，这会产生大量积热，可能还会起火（电路损坏更是当然的了）。在 SOIC8 上，第 3 引脚是 WP，第 4 引脚是 GND，所以说直接把 3.3v 连过去十分冒险；这些都是你用上拉电阻的理由。**
（比如你用 pomona 的夹子的话）你想刷的所有主板，多半已经存在用于 WP/HOLD 的上拉电阻了，所以直接断开 CH341A 上的 WP/HOLD 也行。只有在你也想刷写 ZIP 芯片座中的芯片时，你在这个 CH341A 上放置（在这个修改版中）的上拉电阻才有用。如果比方说笔记本主板和 CH341A 都存在上拉电阻，那就意味着（各支路上的）两个并联电阻会成为等效的串联电阻。假如我们有一台笔记本，它可能有约 3.3k 大小的上拉电阻，那在 CH341A 这边加上约 5.6k 欧姆的阻值就是合理的。
或者，你也可以这样解决问题：用一个有逻辑电平转换器的适配器，并确保有匹配的 vcc 进入 flash。在这种方案下，使用逻辑电平转换器相当灵活，你可以用它设置许多电压，比如说 1.8v 或者 3.3v。
再重复一遍：
**不要买 ch341a!** 它设计出来，不适合把 ROM 刷到那些使用了 3.3v SPI 的机器（即大多数 coreboot 机器）。千万不要使用它！现在厂商还没有修复这个问题，而且估计他们也不会再修复了！
如果你看到有人在谈论 CH341A，请给他们看这个页面，告诉他们为什么 CH341A 不好。
以下是完成了这两个修改（3.3v 逻辑电平和 WP/HOLD 上拉电阻）的黑色 CH341A：\
<img tabindex=1 src="https://av.canoeboot.org/ch341a/0000_th.jpg" /><span class="f"><img src="https://av.canoeboot.org/ch341a/0000.jpg" /></span>
<img tabindex=1 src="https://av.canoeboot.org/ch341a/0001_th.jpg" /><span class="f"><img src="https://av.canoeboot.org/ch341a/0001.jpg" /></span>
绿色版本（上面未展示）可能已经连接了 3.3v 逻辑电平，但仍然需要为 WP/HOLD 增加上拉电阻。
识别你的 flash 类型
==================================
每一个 flash，都会有一个点或者标记，表明这是第 1 引脚（如 WSON8 的第 1 焊盘）。
参考下面的图片，再看看你的主板。搞清楚你的芯片类型之后，根据你了解的情况及本教程剩下的部分，来实现你的目标，即对你的引导 flash 进行读/写。
SOIC8
-----
![](https://av.canoeboot.org/chip/soic8.jpg)
SOIC16
------
![](https://av.canoeboot.org/chip/soic16.jpg)
SOIC8 和 SOIC16 是最常见的类型，但也有其他的类型：
WSON8
-----
X200S 或 X200 Tablet 上是像这样的：\
![](https://av.canoeboot.org/x200t_flash/X200T-flashchip-location.jpg)
T400S 上，是在 RAM 附近的这个位置：\
![](https://av.canoeboot.org/t400s/soic8.jpg)\
注意: 本照片中的芯片换成了 SOIC8
DIP8
----
![](https://av.canoeboot.org/dip8/dip8.jpg)
电源电压
--------------
之前，Canoeboot 支持的所有主板，刚好都有在 3.3V DC 下工作的 SPI NOR 芯片。因为最近添加了额定 1.8V DC 芯片的 Chromebook，所以就不再是这么回事了。
检查主板上芯片的元件型号，再查找一下它的数据表。找出它需要的电源电压并记下来。如果它和你外部刷写硬件的输出电压不匹配，那你只能通过适配器或者逻辑电平转换器，把它连至芯片，而绝不能直接连接。
软件配置
======================
通用/Le potato
-----------------
[通用指南](spi_generic.md)可以帮助你使用本指南未列出的 SBC（单板电脑）。不过，那份指南会使用 libre computer 'Le Potato' 作为参考板。如果你有那块板子，你应该参考 [通用指南](spi_generic.md)。
BeagleBone Black（BBB）
----------------------
SSH 连接到你的 BeagleBone Black。假定你在 BBB 上用的是 Debian 9。你将在 BBB 上运行 `flashrom`。
注意：该部分已过时，因为它是写给 BBB 上运行的 Debian 9 的。
以 root 运行以下命令，开启 spidev：
```
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
```
检查 spidev 设备现在是否存在：
ls /dev/spidev*
输出：
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1
现在 BBB 可以开始刷了。以下的 systemd 服务文件可以选择性开启，从而让它重启后依然存在。
```
[Unit]
Description=Enable SPI function on pins
[Service]
Type=oneshot
ExecStart=config-pin P9.17 spi_cs
ExecStart=config-pin P9.18 spi
ExecStart=config-pin P9.21 spi
ExecStart=config-pin P9.22 spi_sclk
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
```
现在测试 flashrom：
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
重要的一点是，要使用 `spispeed=512` 或者更低的速度，例如 256 或 128，否则 BBB 会十分不稳定。
输出示例：
```
Calibrating delay loop... OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
```
这表示正常工作了（夹子没连接任何 flash 芯片，所以出错是正常的）。
BBB 注意事项
-----------------
不建议使用 BeagleBone Black，因为拿它来进行 SPI 刷写，速度很慢而且不稳定，并且现在有更好的选择了。我们以前建议使用 BBB，因为它可以完全运行自由软件，但现在有了更佳的选择。
计划：讲解其他 SPI 刷写工具
Rasberry Pi（RPi）
-----------------
SSH 连接到树莓派。你将在树莓派上运行 `flashrom`。
你必须在树莓派上配置 `spidev`。这是 Linux 内核的一个特别驱动；它严谨的名字叫做 `spi-bcm2835`。
这个页面有信息：\
<https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md>
假定你的树莓派运行的是最新的 Raspbian。运行：
sudo raspi-config
在 Interface 部分，你可以开启 SPI。
用于 SPI 通讯的设备位于 `/dev/spidev0.0`。
RPi 驱动强度（Drive Strength）
------------------
RPi 的 flashrom 可能无法检测到一些系统的 SPI flash，即使你已经完美地连好了线并夹住了芯片。这可能是因为树莓派 GPIO 的驱动强度，它默认是 8mA。驱动强度本质上就是，在保持高电平最低电压的同时，引脚最高能输出的电流。对树莓派而言，这个电压是 3.0 V。
类似地，也要满足一个最低电压，SPI flash 芯片才会把它当成高逻辑电平。这个值一般是 SPI flash 的 0.7*VCC，对 3.3V 的芯片而言也就是 2.31V。如果驱动强度太低了，那 flash 芯片的引脚处的电压可能会低于最低电压，导致它被视为发送了低逻辑电平，而不是高逻辑电平。
在许多系统，SPI flash 的 VCC 引脚和机器中其他芯片是共享的，导致你的编程夹提供的电压会给这些芯片供电。这样的话，芯片组的一部分就会启动，并试图把 SPI 线路弄得忽高忽低，妨碍了树莓派要发送的数据。如果树莓派和芯片组要把一个引脚设置为不同的值，驱动强度更高的一边能够将电压“拉”到它想设置的电平。
幸运的是，树莓派的驱动强度能增加到 16mA。有许多工具可以设置这一项，例如 pigpio 项目的 pigs 工具。在 Raspberry Pi OS 里，可以使用以下命令安装 pigpio 并将驱动强度设置为 16mA：
安装 pigpio：
sudo apt install pigpio
启动 pigpiod 守护进程，pigs 工具会与其通讯，从而与 gpio 交互：
sudo pigpiod
将包含了 spi0 引脚的 GPIO 0 组，驱动强度设置为 16mA：
pigs pads 0 16
注意，硬件工作的驱动强度是 2mA 的倍数，pigs 会将奇数值四舍五入到下一个 2 的倍数。你可以使用以下命令查看驱动强度
pigs padg 0
警告：如果芯片组非常想把引脚的值设置为和树莓派相反，那树莓派的 GPIO 引脚就会通过比 16mA 还高的电流，这样会损坏引脚，因为它设计只能耐受 16mA。驱动强度不是电流限制。尽管如此，不管驱动强度如何，这对树莓派都有风险。芯片组和 flash 之间的电阻应该会对此进行保护，但并非所有主板都有这些电阻。
见 <https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#gpio-pads-control> 了解树莓派上的驱动强度控制。
RPi 注意事项
-----------------
基本上，Raspbian 项目，即现在的 Raspberry Pi OS，对其仓库进行了更新，增加了一个新的“受信任”仓库，这刚好是一个微软软件仓库。他们这么做，似乎是为了 VS Code，但问题在于，这可以让微软自由地控制他们喜欢的依赖（根据 apt-get 规则）。每当你更新，你都会对微软的服务器发送请求。不觉得这很奇怪吗？
微软不应该对你的 Linux 系统有*任何*访问权！这是 Raspbian 添加在他们仓库的 commit，正是它故意添加了我们应该称之为安全漏洞的仓库：
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/655cad5aee6457b94fc2336b1ff3c1104ccb4351>
在受到公众的强烈反对后，他们在以下 commit 中移除了它：
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/ed96790e6de281bc393b575c38aa8071ce39b555>
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/4d1afece91008f3787495b520ac03b53fef754c6>
RPi 的自由固件
---------------------
旧款树莓派的引导固件可以替换成完全自由的固件。对有些用户而言，这额外的一步可能很有用。参见：
<https://github.com/librerpi/>
网站：
<https://librerpi.github.io/>
安装 flashrom
----------------
如果你在使用 BBB 或者 RPi，你需要在 SSH 进去之后再这么做。
Flashrom 是用来读出、擦除、重写 NOR flash 内容的软件。
使用 Git 仓库中的 canoeboot 构建系统，你可以下载并安装 flashrom。首先下载 [lbmk Git 仓库](https://codeberg.org/libreboot/lbmk)，然后执行：
cd lbmk
sudo ./build dependencies ubuntu2004
注意：你可以输入 debian、arch 或 void 来替换 ubuntu。debian 脚本也可以用于新版 ubuntu。
./update trees -b flashrom
如果 `ubuntu2004` 报告了依赖缺失，编辑一下这个脚本，把缺失的依赖移除就行了。脚本位于 `config/dependencies/ubuntu2004`，它是写给 Ubuntu 20.04 的，但在其他使用 `apt-get` 包管理器的 Linux 发行版应该也能用。
接下来，会出现一个 `flashrom/` 目录，其中有一个 `flashrom` 可执行文件。如果你在运行上面的依赖命令的时候，出现了缺失包的错误，则修改 `config/dependencies/ubuntu2004`。那个脚本会在 apt-get 中下载并安装构建依赖，它是为运行 Ubuntu 的 x86-64 系统写的，但在树莓派上的 Raspbian 应该能用。
或者，你可以直接从上游下载 flashrom，位于：<https://flashrom.org/Flashrom>
如果你是在 ThinkPad X200 上刷写 Macronix flash 芯片，则要使用一个 flashrom 的特别修改版，下载地址在这里：<https://vimuser.org/hackrom.tar.xz> —— 其中有修改版的源代码，也有可以直接运行的二进制文件。将 `--workaround-mx` 参数传给 flashrom。这会缓解稳定性问题。
如果你直接下载了 flashrom 源代码，你可以进入目录并直接运行 `make`。在 canoeboot 构建系统中，`config/dependencies/` 处的脚本写明了构建依赖，你可以直接使用 `apt-get` 软件安装。
如何使用 flashrom
===================
请先阅读本页更下方的部分，了解特定的芯片类型及其接线方法。
读出
-------
刷入新的 ROM 镜像之前，强烈建议你将当前芯片的内容读出到一个文件。
树莓派正确接线后，运行这个命令来查看是否检测到 25xx flash：
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768
对 BBB 而言，必须使用更慢的速度及不同的设备路径：
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
在 BBB 上，绝对不要使用高于 `spispeed=512` 的速度。有时候，你可能还要低到 `spispeed=128` 的速度。BBB 对 SPI 刷写而言非常不稳定、不可靠。在读取的时候，要多次读出，并检查它们的 checksum 是否一致，然后再刷。你可能需要多次刷写芯片！
注意：在有些机器上，更高的速度会不稳定。这时，尝试一下更低的速度，例如 `spispeed=4096` 或者 `spispeed=2048`，这大多数情况下应该会工作，但明显会慢些。如果你使用的线短于 10cm，设置成 `spispeed=32768` 一般刚好就能工作了。
如果检测到了 flash 芯片，你可以现在尝试读出这个 flash 的内容，或者给它刷写新的 ROM。
在 RPi 上，这样读出：
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r dump.bin
BBB 的话，这样：
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r dump.bin
建议读出*两次*，比如弄一个 `dump2.bin`，然后检查 sha1sum：
sha1sum dump*.bin
如果 checksum 匹配了，那读得就没问题。如果不匹配，那就要检查接线了。为了最佳稳定性，线长应该要短于 10cm，并且长度都要相同（VCC 和 GND 线路可以长些）。
这条建议是*特别*给 BBB 的，这块板子十分不可靠。
有些主板有不止一个 flash 芯片，你需要从两块芯片中读取，并把它们合并成一个文件。大多数时候。两个芯片的配置包含了一块 8mb 的“下层”芯片和一块 4mb 的“上层”芯片。刚刚描述的配置适用于 x230、t430 和 t440p 的情况。对其他主板而言，请确认那块芯片包含了 rom 的下层部分和上层部分。要把两个 flash 组合起来的话，你可以用比如说 `cat`：
cat bottom_8mb.rom top_4mb.rom > full_12mb.rom
注意，如果你要手动提取 blob，那你就需要这个组合而成的 rom。
写入
-------
接下来，运行这个命令（RPi）：
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/canoeboot.rom
如果用的是 BBB：
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/canoeboot.rom
用 BBB 的时候，可能得使用低于 512 的速度。你也许还得多次重复刷写，才能完全工作。
再说一遍，为了稳定性，你可能需要使用更低的 `spispeed` 值。
当命令输出了以下内容，那就说明刷写成功了。如果没有，那就再刷一遍。
```
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
```
如果它显示“VERIFIED”了，或者芯片的内容和请求的镜像一致，那芯片就刷写成功了。
硬件配置
======================
软件配置请参考上面的教程。下面的建议会教你如何为每种 flash 芯片接线。
警告
--------
在芯片还没有正确接好线时，先不要连接电源。例如，不要连接到接通电源的测试夹。
请先断开或关闭电源，再*断开*刷写工具与芯片的连接。
注意你提供给芯片的电源电压是否真的合适。目前 canoeboot 支持的硬件，大多数的 SPI flash 都是在 3.3V DC 下工作的，逻辑电平也一样。有一部分（至少是 Chromebook）的芯片可能在 1.8V DC 下工作。你需要确认 SPI flash 芯片的元件型号及数据集，看看它需要的电源电压。如果你的外部刷写硬件无法匹配，那就使用适配器或者逻辑电平转换器来刷写。
对这些芯片做任何操作时，要检查一遍你使用的电源电压是否正确，这一点很重要。低于额定的电源电压不会造成任何损伤，但高于它的话就会把芯片烧了（大多数 3.3V 的芯片，能接受的电压介于 2.7V 和 3.6V 之间，但 3.3V 是最理想的）。
也不要给你的 flash 芯片连接超过 1 个 DC 电源！那样混合电压的话，很容易损伤你的设备及芯片/主板。
MISO/MOSI/CS/CLK 接线
----------------------
在刷写这些芯片的时候，你可能也想增加 47 欧姆的串联电阻（不是加在 VCC 或 GND 线上）。这可以提供一些过流保护。在 Intel 平台上，SPI flash 直接连接到南桥芯片组时，通常会通过这样的电阻。
ISP 编程及 VCC 二极管
-----------------------------
ISP 即系统内编程（in-system programming）。它指的是，一块芯片已经装在了你想安装 canoeboot 的电脑的主板上，而你要对这块芯片进行刷写。
为了通过二极管来驱动（VCC 引脚上的）SPI flash，而对主板进行修改，可能会有一定的好处，但要注意的是：二极管会导致电压下降。一块需要 3.3V VCC 的芯片，能够接受大约 2.7V 到 3.6V DC，但压降后可能会低于这个区间。如果你要这么做的话，还请确认 WP 和 HOLD 引脚仍然保持在高电平状态；每一个引脚都通过自己的电阻（1K 到 10K 欧姆）连接到了*相同*的通过二极管的电源。
原因很简单：大多机器的 flash 都和主板上其他部件共用同一路电源，这会分走很多电流。然后，如果你不小心提供了过高的电压或者导致了过流，那可能就会烧了其他部分；但如果有二极管保护，你只能把引导 flash 烧了（如果你焊接技术不错的话，那很容易替换）。
把二极管接上去的时候，要确认芯片上的 VCC 隔离了主板上的其他所有部件，后者会共用同一路电源。然后，确保 WP/HOLD 的上拉电阻*仅*连接到了二极管导通 VCC 引脚的那一边（这一点很重要，因为如果不这样做的话，ISP 刷写的时候 WP/HOLD 就不会保持高电平，即使主板完全开机时它们还能保持高电平）。
还有就是：安装好二极管后，确保 SPI flash 完全启动时在合适的电源电压下工作（3.6V 芯片而言是 2.7V 到 3.3V）。
如果目标主板是桌面、工作站、服务器主板（而不是笔记本），那如果主板用的是 SOIC8/WSON8，你就可以对它拆焊，（对 SOIC8、WSON8 或 DIP8 之中的任意一个）使用芯片测试座来替换，因为那样你就可以简单地把 flash 插入面包板刷写了。
计划：在 canoeboot.org 创建一个页面，讲怎么在 canoeboot 支持的所有主板这么做。
BeagleBone Black（BBB）上的 GPIO 引脚
-----------------------------------
把 pomona 夹子连接到 BBB 时，参考这张图片：<https://beagleboard.org/Support/bone101#headers> （D0 = MISO 或连接到 MISO）。
如果你要用 *P9 排针*来连接芯片刷写的话，请看那个页面的那个部分。
40 引脚树莓派（RPi）的 GPIO 引脚
--------------------------------------
下图展示了大多数现代树莓派及其衍生版的引脚分配。图中右边是 RPi 的引脚，左边是两个 SOIC 夹。
![](https://av.canoeboot.org/rpi/wiring.webp)
26 引脚树莓派（RPi）的 GPIO 引脚
-------------------------------
树莓派 B 款 26 GPIO 引脚图（对 40 引脚的 B+ 款而言，从右边开始数，剩下 14 个引脚）：
![](https://av.canoeboot.org/rpi/0012.webp) ![](https://av.canoeboot.org/rpi/0013.png)
此处的信息，也请在阅读以下其他部分时参考：
SOIC8/DIP8/WSON8 接线图
-------------------------------
参考此表：
Pin \# 25xx signal RPi(GPIO) BBB(P9 header)
------ ----------- ---------- --------------
1 CS 24 17
2 MISO 21 21
3 *未使用* *未使用* *未使用*
4 GND 25 1
5 MOSI 19 18
6 CLK 23 22
7 *未使用* *未使用* *未使用*
8 VCC 1 3
在你的 SOIC8 上，其中一个角落会有一个点，这个点是第 1 引脚。
注意：第 3 和第 7 引脚是 WP/HOLD 引脚。在面包板上刷写芯片时，请对它们使用上拉电阻（见上面的注记），并在第 8 引脚（VCC）使用去耦电容。
注意：在 X60/T60 thinkpad 上，不要连接第 8 引脚。而是将你的 PSU 接在主板供电口上，但不要启动主板。这会提供稳定的 3.3V 电压及足够的电流。在这些笔记本上，这是必要的，因为 flash 和其他许多 IC 共用一路 3.3V DC 电源，这些 IC 都会分走很多电流。
SOIC16 接线图（树莓派）
------------------------------------
RPi GPIO 排针：\
![](https://av.canoeboot.org/rpi/0009.webp)
![](https://av.canoeboot.org/rpi/0010.png)
BBB P9 排针：\
<https://beagleboard.org/static/images/cape-headers.png>
参考此表：
Pin \# 25xx signal RPi(GPIO) BBB(P9 header)
-------- -------------- ----------- --------------
1 *未使用* *未使用* *未使用*
2 VCC 1 3
3 *未使用* *未使用* *未使用*
4 *未使用* *未使用* *未使用*
5 *未使用* *未使用* *未使用*
6 *未使用* *未使用* *未使用*
7 CS\# 24 17
8 MISO 21 21
9 *未使用* *未使用* *未使用*
10 GND 25 1
11 *未使用* *未使用* *未使用*
12 *未使用* *未使用* *未使用*
13 *未使用* *未使用* *未使用*
14 *未使用* *未使用* *未使用*
15 MOSI 19 18
16 SCLK 23 22
参考本页面上方的 RPi GPIO 指南。
在你的 SOIC16 上，其中一个角落会有一个点，这个点是第 1 引脚。
注意：第 1 和第 9 引脚是 WP/HOLD 引脚。在面包板上刷写芯片时，请对它们使用上拉电阻（见上面的注记），并在第 2 引脚（VCC）使用去耦电容。
上拉电阻和去耦电容
-------------------------------------------
**如果芯片是装在面包板上的，那请遵循这里的步骤。如果你要刷写的芯片已经焊接在了主板上，那请忽略这一部分。**
如果你要刷写的新芯片还没有安装在主板上，那这一部分才有关系。你需要在 WP 和 HOLD 引脚增加上拉电阻，在 VCC 引脚增加去耦电容。如果芯片已经安装在了主板上，无论是通过焊接还是芯片座，那这些电容和电阻可能已经存在于主板上了，你可以直接刷写而无需将 WP/HOLD 拉高，也无需电容（只要连接外部电源即可）。
最佳方法如下：
* 如果是 DIP8 的话，将 DIP8 IC 插入面包板（2.54mm 的洞）
* 如果是 WSON8 的话，将 WSON8 插入 WSON8 socket，并装上面包板
* 如果是 SOIC8 的话，将 SOIC8 插入 SOIC8 socket，并装上面包板
* 使用 2.54mm 杜邦端子，将 SPI 刷写器连接到面包板，并正确接线（见下面的 SPI 刷写教程链接）
SOIC8/WSON8/DIP8：第 3 和第 7 引脚必须保持高逻辑电平状态，即每个引脚都通过上拉电阻连接到了 VCC（来自引脚 8 连接的电压层）；1K 欧到 10K 欧都可以。当你刷写的芯片已经处于笔记本/桌面/服务器主板上时，那第 3 和第 7 引脚很可能已经处于高电平，所以就不用再管这一点了。
SOIC8/WSON8/DIP8：如果芯片在主板上，那第 8 引脚，即 VCC，就已经有去耦电容在上面了。但如果单独把芯片拿出来刷，那这些电容就不存在。电容会通过 AC，但阻挡 DC。由于电磁感应及 IC 状态高速切换导致的射频噪声，DC 电压那根线（从示波器上看）其实并不是直线，而实际上还混进了一些低压 AC；在高荷载下的一根噪声特别大的线上，约 300mV 及以上的噪声是常见的。为了消除那些噪声，需要将 DC 线的电容接地，并将 VCC 那边的电容尽可能接近 IC 的 VCC 引脚。我们建议在这里使用陶瓷电容器。建议使用的电容器为：100nF 和 4.7uF 的陶瓷电容器。电解电容器还不如此，因为它的 ESR（等效串联电阻）更加高（陶瓷电容器的 ESR 非常低，十分利于去耦）。
使用去耦电容的结果就是，DC 线上的部分噪声过滤到了大地，使得 DC 信号（从示波器上看）更加干净、笔直了。
SOIC16：同上，但在面包板上使用 SOIC16 socket。在 SOIC16 上，WP/HOLD 不同于上面的第 3/7 引脚，而是第 1 和第 9 引脚，所以要把上拉电阻接到那里。SOIC16 上的 VCC 是第 2 引脚，所以要把去耦电容接到那里。
SOIC8/WSON8/DIP8/SOIC16 未安装在主板上
--------------------------------------------------
如果你的机器的 SPI flash 容量较低，那你可以升级。在*大多数*机器上，SPI flash 是经过映射的内存，而（实际上）你最大可以使用 16MiB 的芯片。例如，canoeboot 的 KGPE-D16 和 KCMA-D8 主板默认有 2MiB flash，但你可以对它们轻松升级。另一个例子是 ThinkPad X200S、X200 Tablet 和 T400S，它们都有 WSON8，而最佳的方案就是将它替换为 SOIC8 flash 芯片。
在所有这些情况中，刷写新芯片都需要使用面包板，而不是测试夹。你需要使用 2.54mm 杜邦端子连接到树莓派。对数据线路而言，要确保每根线的长度都相等，线长约 10cm（不要再长了）。
一些建议：
* DIP8：建议选择 Winbond W25Q128FVIQ。这是个直接的替代品。
* SOIC8 也是可能的：建议选择 Winbond W25Q128FVSIG。
* DIP8 也可以使用转接器及 SOIC8。使用 208-mil 1.27mm SOP8/SOIC8 转 DIP8 的适配 PCB，并在每一边使用 2.54mm 四引脚排针（方形引脚），然后你就能把它当成正常的 P-DIP8 IC 插入了。这个页面是一个很好的例子： <https://coolcomponents.co.uk/products/soic-to-dip-adapter-8-pin>
* 如果你走上面的途径的话，那我们建议使用上述的 SOP8/DIP8 转接器。它是 Sparkfun 制造的，并且到处可见。没必要专门从一个网站上买。它的元件型号是：BOB-13655。
* 如果你使用 SOP/DIP 转接器和 SOIC8 IC，那你显然需要对它进行焊接。焊接这类 IC 时建议使用 K 焊头。使用良好的助焊剂和 60/40 含铅焊锡（或者 63/37），不要使用 Rohs 的无铅蹩脚货。
如果你使用 SOIC8，将它装上 SOP 转 DIP 的转接器（208mil 1.27mm），并为它焊上 2.54mm header。你可以将 2.54mm 引脚插在面包板上，将芯片焊在适配 PCB 上，并将它安装在面包板的引脚上，从而对齐再焊接。这时 PCB 在引脚上，引脚在面包板上，将引脚往里推一点。
这是写给新 SOIC8 芯片的，但你也可以使用类似视频里的 socket，不过是给 WSON8 的。有时候它们又叫做 DFN8 或 QFN8 socket。你需要 1.27mm 间距的。
如果你是在对单独的 WSON8 进行刷入/读出，那你需要一个 WSON8/QFN8/DFN8 芯片座（1.27mm 间距）并将其安装到面包板来刷写。如果你主板上 flash IC 的着陆焊盘能上 SOIC8，那我们建议你转而使用 SOIC8，因为后续你想再刷写它时，可以使用测试夹，但你的主板已有的 WSON8 换成 SOIC8 可能更加可取；那种情况下，你可能仍要把原 WSON8 的内容读出来。
这展示的是芯片座上的 SOIC8 安装在面包板上，以供刷写：\
![](https://av.canoeboot.org/rpi/soic8_socket.jpg)
这张照片是 DIP8 IC：\
![](https://av.canoeboot.org/dip8/dip8.jpg)
这张照片是 SOIC8 在 1.27mm 208mil SOP 转 DIP 的转接器上：\
![](https://av.canoeboot.org/dip8/sop8todip8.jpg)
注意：DIP8、芯片座上的 WSON8 以及芯片座上的 SOIC16，基本上是一样的，只是用了相应的转接器。
如果你要替换 DIP8，但是在使用接在转接器上的 SOIC8，则先将它焊接在转接器上，然后将 2.54mm 排针（方形引脚）插入面包板来把它们对齐。将 SOIC8 置于 PCB 上，插入引脚，并把引脚往里推一些，然后将其焊接。或者对面包板而言，你可以直接在 2.54mm 引脚上插入 DIP8 芯片座，并在它上面装上 SOIC8 + 转接器，然后将其焊接。使用优质的松香助焊剂（非酸性）和良好的 60/40 或 63/37 含铅焊锡（不要使用无铅焊锡）：
![](https://av.canoeboot.org/dip8/adapter_breadboard.jpg)
![](https://av.canoeboot.org/dip8/adapter.jpg)
![](https://av.canoeboot.org/dip8/sop8todip8.jpg)
SOIC8/SOIC16 焊接在主板上
------------------------------------
这是*系统内编程*或 *ISP* 的一个简短例子。
SOIC8：\
Pomona 5250 是一个 SOIC8 测试夹。也有其他的可以用，但这个是最好用的。使用 SOIC8 接线图（见上）来连接你的树莓派。你的主板很可能已经将 WP/HOLD（第 3 和第 7 引脚）拉到高电平了，所以不用连接这些。SOIC8 第 8 引脚的 VCC 很可能在主板上已经有去耦电容了，所以只需要勾起来而不用使用电容。
SOIC16：\
Pomona 5252 是一个 SOIC16 测试夹。也有其他的可以用，但这个是最好用的。就用这个。使用 SOIC16 接线图（见上）来连接你的树莓派。WP/HOLD 引脚是第 1 和第 9 引脚，并且很可能已经是高电平了，所以不需要上拉电阻。同样，第 2 引脚（VCC）也不再需要去耦电容，因为主板已经有一个了。
测试夹连接到 SOIC16 的例子如下：\
![](https://av.canoeboot.org/rpi/0002.jpg)
SOIC8 例子的照片如下：\
![](https://av.canoeboot.org/x60/th_bbb_flashing.jpg)
DIP8 焊接在主板上
------------------------------
把 DIP8 直接焊接在主板上怪异至极。它通常是安装在芯片座上的。
由于引脚足够大，你可以直接用测试夹的钩子来连接芯片进行刷写。你可能需要使用焊锡真空（提取）工具，对芯片进行拆焊，然后你就可以在那里安装一个芯片座了。接着你就可以把 DIP8 IC 插入芯片座。
我们在 canoeboot 项目从来没听过有哪块板子的 DIP8 是直接焊上去的。它基本都是安装在芯片座上的。
DIP8 IC 的引脚分配和 SOIC8 IC 一样。
使用 SOIC8 替换 WSON8 IC
---------------------------
你*连是可以连* SOIC8 测试夹，但要连接效果好，需要费点功夫，而且这也十分不可靠。不要直接焊接 WSON8 的焊盘；有些人会这样做，但你不要这样做，因为你这样很容易就会损坏焊盘。
WSON8 的引脚分配和 SOIC8 一样，但它是球状 QFN（四边扁平无引脚封装）。它没有合适的夹子，有时候称为 QFN8。
目前 canoeboot 支持的所有硬件，有 WSON8 的主板也可以上 SOIC8，因为它的焊盘长到足够容纳这两者任意一种芯片。
在 T12 焊台上上使用 T12-D08 或者 T12-K 焊头，是不错的烙铁选择。KSGER 生产的焊台还不错：\
<https://yewtu.be/watch?v=w0nZCK7B-0U>
KSGER 焊台的外壳默认是没有接地的，所以你应该改装一下，让外壳接地，以防发生电气事故。这是为了你的安全。这个视频展示了操作方法：\
<https://yewtu.be/watch?v=-6IZ_sBgw8I>
使用优质的 60/40 或者 63/37 铅+锡焊锡，不要使用无铅的！无铅的不适合这类业余用途。使用优质的*松香*助焊剂。绝不要使用酸性助焊剂。Amtech 和 MG Chemicals 生产的助焊膏就很不错。把它放在分配器管中使用。其中一些助焊剂含有己二酸，其 pH 值较低，只是用作一种温和的活化剂。只要事后清洗助焊剂，应该就没问题。
确保手边有铜丝刷和湿海绵。在铜丝刷上擦拭烙铁，并在湿海绵上轻拍（从而去除氧化物），保持清洁。焊头要经常清洁。此外，清洁过后，要使用新焊锡重新镀锡焊头，以防焊头氧化！
确保你买的是 99.9% 的异丙醇。不要购买弱一些的溶液，因为它们含水，也不要用其他的化学物质，因为其他大多数都有腐蚀性。焊接之前，先用异丙醇清洁要焊接的区域，然后用布吸收湿酒精。你还可以用它清除掉你使用过的任何助焊剂。
焊点要良好，助焊剂的使用十分重要，因为它移除了氧化物，并防止焊接过程中的进一步氧化，确保焊锡能够正常流动，否则焊锡会起球，无法获得良好的焊点。
如果你焊接技术不好，我们准备了一些不错的视频，链接在 [FAQ 页面](../../faq.md)，你可以去看看。
WSON8 IC：\
![](https://av.canoeboot.org/rpi/wson8/0001.jpg)
使用几层 kapton 胶带包围芯片周围的一大块区域，然后再铺上铝箔。这样可以隔热，减少让其他焊点再流动的风险（这会把它们变成冷焊点，并且有风险把它们从主板上敲下来）：\
![](https://av.canoeboot.org/rpi/wson8/0002.jpg)\
注意，胶带+铝箔不要盖住芯片本身或焊盘。让它们接触高温是必要的。
使用拆焊台，温度设为 330-340C 左右。温度这么高的原因是，空气的导热效率不如铁高，所以必须要高一些的温度。你需要在 IC 上面涂上很多松香助焊剂。喷嘴不要离主板太近。喷嘴的直径应该略高于芯片长度。在高气流下均匀加热。
对芯片喷射热空气时，用镊子夹住芯片，但不要用力。不要用力把芯片撬开了。只要用镊里夹住芯片，轻轻地推它，直到感觉到芯片可以自由移动了。这时，焊锡已经完全融化，芯片可以轻松取出来了。
如果不出什么问题，那一分钟内，芯片就能取下来，就像这样：\
![](https://av.canoeboot.org/rpi/wson8/0003.jpg)
在焊盘上，包括导热垫上，加以新焊锡：\
![](https://av.canoeboot.org/rpi/wson8/0004.jpg)
现在，用浸在松香助焊剂中的吸锡带将其吸干：\
![](https://av.canoeboot.org/rpi/wson8/0005.jpg)
确保所有焊锡都已经清除：\
![](https://av.canoeboot.org/rpi/wson8/0006.jpg)\
你会发现，其中一个焊盘上的焊锡没有完全去除。这是有意为之的，目的是给你参考对比一下。其他焊盘已经没有焊锡了。
你*可以*直接将没刷写好的芯片焊接上去，然后使用测试夹来刷写它。或者，你也可以将 SOIC8 插入面包板上的芯片座，并先刷好再焊接。如果你想把 WSON8 的内容读出来，你可以将移除的 WSON8 放在面包版上的芯片座中，然后使用 SPI 刷写器来对其进行读出。
对齐新的 SOIC8，将其焊到角落的引脚上。然后对其完全焊接。使用大量的助焊剂！\
![](https://av.canoeboot.org/rpi/wson8/0007.jpg)\
这张图里用的是 T12-D08 焊头，但迷你凿形、迷你蹄形或刀形（如 T12-K）焊头是最理想的。
确保每一个焊点都完美了。好的焊点有光泽，并且焊锡流过的地方有凹陷的圆角。请看：\
![](https://av.canoeboot.org/rpi/wson8/0008.jpg)
弄完之后，用软毛刷和 99.9% 的异丙醇把剩余的助焊剂清理干净，然后趁酒精还是湿的，用布吸收酒精。99.9% 的异丙醇是最好用的液体，因为它挥发很快，并且不会残留腐蚀性物质。
-------------------------------------------------------------------------------
许可证
=========
本页面发布所使用的版权条款，不同于本网站上大多数其他页面。
本页面及其照片，以 [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt) 发布。请检查 Git 仓库历史，了解本文档何部分归谁所有。
部分这些资源源自于*旧的* Canoeboot git 仓库，Canoeboot 随后分离成了单独的仓库，包括 `lbmk` 仓库。
展示了 BeagleBone Black 的照片，以 GNU Free Documentation License 许可，如同本网站的其他页面和图像。如果你想的话，你也可以在 CC-BY-SA 4.0 下使用它们（我，Leah Rowe，拥有本页展示的全部 BBB 照片的所有权，除了 beaglebone 网站上的那一张以外；而那一张只是在这里链接的，而不是托管在 av.canoeboot.org 服务器的）。
本页面的该版本托管在 `lbwww` git 仓库，其图像托管在 `lbwww-img` 仓库（来自用户 canoeboot）。

6
site/docs/install/spi_generic.md
View File

@ -3,11 +3,11 @@ title: Generic SPI Flashing Guide
x-toc-enable: true
...
There are a plethora of single board computers with which you can flash nonGeNUine Boot to a SOIC chip.
There are a plethora of single board computers with which you can flash Canoeboot to a SOIC chip.
Some users might be daunted by the price of a raspberry pi.
This guide is intended to help users looking to use a programmer which is not listed in the [main guide.](spi.md)
As an example, this guide will use the [libre computer 'le potato.'](https://libre.computer/products/aml-s905x-cc/)
You should note however, that this guide is intended to demonstrate how to set up any SBC with SPI programming capabilities for flashing nonGeNUine Boot.
You should note however, that this guide is intended to demonstrate how to set up any SBC with SPI programming capabilities for flashing Canoeboot.
If you are wondering about which SBC to buy, keep these things in mind:
@ -91,7 +91,7 @@ Reading/writing from SPI works respectively as such:
```
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r /path/to/read.bin
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/nongenuineboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/canoeboot.rom
```
Note that `spispeed` varies based on the board in question.

98
site/docs/install/t400_external.md
View File

@ -8,7 +8,7 @@ Dell Latitude E6400
**If you haven't bought an T400 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
@ -16,7 +16,7 @@ Introduction
Initial flashing instructions for T400.
This guide is for those who want nonGeNUine Boot on their ThinkPad T400 while
This guide is for those who want Canoeboot on their ThinkPad T400 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your T400, to know how to recover.
@ -40,7 +40,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T400) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work with nonGeNUine Boot.
to work with Canoeboot.
T9600, T9500, T9550 and T9900 are all compatible, as reported by users.
@ -62,7 +62,7 @@ Intel GPU; this is referred to as "switchable graphics". In the *BIOS
setup* program for lenovobios, you can specify that the system will use
one or the other (but not both).
nonGeNUine Boot is known to work on systems with only the Intel GPU, using
Canoeboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -93,96 +93,96 @@ The procedure
-------------
Remove *all* screws, placing them in the order that you removed them:\
![](https://avgnu.vimuser.org/t400/0001.jpg) ![](https://avgnu.vimuser.org/t400/0002.jpg)
![](https://av.canoeboot.org/t400/0001.jpg) ![](https://av.canoeboot.org/t400/0002.jpg)
Remove those three screws then remove the rear bezel:\
![](https://avgnu.vimuser.org/t400/0003.jpg) ![](https://avgnu.vimuser.org/t400/0004.jpg)
![](https://avgnu.vimuser.org/t400/0005.jpg) ![](https://avgnu.vimuser.org/t400/0006.jpg)
![](https://av.canoeboot.org/t400/0003.jpg) ![](https://av.canoeboot.org/t400/0004.jpg)
![](https://av.canoeboot.org/t400/0005.jpg) ![](https://av.canoeboot.org/t400/0006.jpg)
Remove the speakers:\
![](https://avgnu.vimuser.org/t400/0007.jpg) ![](https://avgnu.vimuser.org/t400/0008.jpg)
![](https://avgnu.vimuser.org/t400/0009.jpg) ![](https://avgnu.vimuser.org/t400/0010.jpg)
![](https://avgnu.vimuser.org/t400/0011.jpg)
![](https://av.canoeboot.org/t400/0007.jpg) ![](https://av.canoeboot.org/t400/0008.jpg)
![](https://av.canoeboot.org/t400/0009.jpg) ![](https://av.canoeboot.org/t400/0010.jpg)
![](https://av.canoeboot.org/t400/0011.jpg)
Remove the wifi:\
![](https://avgnu.vimuser.org/t400/0012.jpg) ![](https://avgnu.vimuser.org/t400/0013.jpg)
![](https://av.canoeboot.org/t400/0012.jpg) ![](https://av.canoeboot.org/t400/0013.jpg)
Remove this cable:\
![](https://avgnu.vimuser.org/t400/0014.jpg) ![](https://avgnu.vimuser.org/t400/0015.jpg)
![](https://avgnu.vimuser.org/t400/0016.jpg) ![](https://avgnu.vimuser.org/t400/0017.jpg)
![](https://avgnu.vimuser.org/t400/0018.jpg)
![](https://av.canoeboot.org/t400/0014.jpg) ![](https://av.canoeboot.org/t400/0015.jpg)
![](https://av.canoeboot.org/t400/0016.jpg) ![](https://av.canoeboot.org/t400/0017.jpg)
![](https://av.canoeboot.org/t400/0018.jpg)
Unroute those antenna wires:\
![](https://avgnu.vimuser.org/t400/0019.jpg) ![](https://avgnu.vimuser.org/t400/0020.jpg)
![](https://avgnu.vimuser.org/t400/0021.jpg) ![](https://avgnu.vimuser.org/t400/0022.jpg)
![](https://avgnu.vimuser.org/t400/0023.jpg)
![](https://av.canoeboot.org/t400/0019.jpg) ![](https://av.canoeboot.org/t400/0020.jpg)
![](https://av.canoeboot.org/t400/0021.jpg) ![](https://av.canoeboot.org/t400/0022.jpg)
![](https://av.canoeboot.org/t400/0023.jpg)
Remove the LCD assembly:\
![](https://avgnu.vimuser.org/t400/0024.jpg) ![](https://avgnu.vimuser.org/t400/0025.jpg)
![](https://avgnu.vimuser.org/t400/0026.jpg) ![](https://avgnu.vimuser.org/t400/0027.jpg)
![](https://avgnu.vimuser.org/t400/0028.jpg) ![](https://avgnu.vimuser.org/t400/0029.jpg)
![](https://avgnu.vimuser.org/t400/0030.jpg) ![](https://avgnu.vimuser.org/t400/0031.jpg)
![](https://av.canoeboot.org/t400/0024.jpg) ![](https://av.canoeboot.org/t400/0025.jpg)
![](https://av.canoeboot.org/t400/0026.jpg) ![](https://av.canoeboot.org/t400/0027.jpg)
![](https://av.canoeboot.org/t400/0028.jpg) ![](https://av.canoeboot.org/t400/0029.jpg)
![](https://av.canoeboot.org/t400/0030.jpg) ![](https://av.canoeboot.org/t400/0031.jpg)
Disconnect the NVRAM battery:\
![](https://avgnu.vimuser.org/t400/0033.jpg)
![](https://av.canoeboot.org/t400/0033.jpg)
Disconnect the fan:\
![](https://avgnu.vimuser.org/t400/0034.jpg)
![](https://av.canoeboot.org/t400/0034.jpg)
Unscrew these:\
![](https://avgnu.vimuser.org/t400/0035.jpg) ![](https://avgnu.vimuser.org/t400/0036.jpg)
![](https://avgnu.vimuser.org/t400/0037.jpg) ![](https://avgnu.vimuser.org/t400/0038.jpg)
![](https://av.canoeboot.org/t400/0035.jpg) ![](https://av.canoeboot.org/t400/0036.jpg)
![](https://av.canoeboot.org/t400/0037.jpg) ![](https://av.canoeboot.org/t400/0038.jpg)
Unscrew the heatsink, then lift it off:\
![](https://avgnu.vimuser.org/t400/0039.jpg) ![](https://avgnu.vimuser.org/t400/0040.jpg)
![](https://av.canoeboot.org/t400/0039.jpg) ![](https://av.canoeboot.org/t400/0040.jpg)
Disconnect the power jack:\
![](https://avgnu.vimuser.org/t400/0041.jpg) ![](https://avgnu.vimuser.org/t400/0042.jpg)
![](https://av.canoeboot.org/t400/0041.jpg) ![](https://av.canoeboot.org/t400/0042.jpg)
Loosen this:\
![](https://avgnu.vimuser.org/t400/0043.jpg)
![](https://av.canoeboot.org/t400/0043.jpg)
Remove this:\
![](https://avgnu.vimuser.org/t400/0044.jpg) ![](https://avgnu.vimuser.org/t400/0045.jpg)
![](https://avgnu.vimuser.org/t400/0046.jpg) ![](https://avgnu.vimuser.org/t400/0047.jpg)
![](https://avgnu.vimuser.org/t400/0048.jpg)
![](https://av.canoeboot.org/t400/0044.jpg) ![](https://av.canoeboot.org/t400/0045.jpg)
![](https://av.canoeboot.org/t400/0046.jpg) ![](https://av.canoeboot.org/t400/0047.jpg)
![](https://av.canoeboot.org/t400/0048.jpg)
Unscrew these:\
![](https://avgnu.vimuser.org/t400/0049.jpg) ![](https://avgnu.vimuser.org/t400/0050.jpg)
![](https://av.canoeboot.org/t400/0049.jpg) ![](https://av.canoeboot.org/t400/0050.jpg)
Remove this:\
![](https://avgnu.vimuser.org/t400/0051.jpg) ![](https://avgnu.vimuser.org/t400/0052.jpg)
![](https://av.canoeboot.org/t400/0051.jpg) ![](https://av.canoeboot.org/t400/0052.jpg)
Unscrew this:\
![](https://avgnu.vimuser.org/t400/0053.jpg)
![](https://av.canoeboot.org/t400/0053.jpg)
Remove the motherboard (the cage is still attached) from the right hand
side, then lift it out:\
![](https://avgnu.vimuser.org/t400/0054.jpg) ![](https://avgnu.vimuser.org/t400/0055.jpg)
![](https://avgnu.vimuser.org/t400/0056.jpg)
![](https://av.canoeboot.org/t400/0054.jpg) ![](https://av.canoeboot.org/t400/0055.jpg)
![](https://av.canoeboot.org/t400/0056.jpg)
Remove these screws, placing the screws in the same layout and marking
each screw hole (so that you know what ones to put the screws back into
later): ![](https://avgnu.vimuser.org/t400/0057.jpg) ![](https://avgnu.vimuser.org/t400/0058.jpg)
![](https://avgnu.vimuser.org/t400/0059.jpg) ![](https://avgnu.vimuser.org/t400/0060.jpg)
![](https://avgnu.vimuser.org/t400/0061.jpg) ![](https://avgnu.vimuser.org/t400/0062.jpg)
later): ![](https://av.canoeboot.org/t400/0057.jpg) ![](https://av.canoeboot.org/t400/0058.jpg)
![](https://av.canoeboot.org/t400/0059.jpg) ![](https://av.canoeboot.org/t400/0060.jpg)
![](https://av.canoeboot.org/t400/0061.jpg) ![](https://av.canoeboot.org/t400/0062.jpg)
Separate the motherboard:\
![](https://avgnu.vimuser.org/t400/0063.jpg) ![](https://avgnu.vimuser.org/t400/0064.jpg)
![](https://av.canoeboot.org/t400/0063.jpg) ![](https://av.canoeboot.org/t400/0064.jpg)
Connect your programmer, then connect GND and 3.3V\
![](https://avgnu.vimuser.org/t400/0065.jpg) ![](https://avgnu.vimuser.org/t400/0066.jpg)
![](https://avgnu.vimuser.org/t400/0067.jpg) ![](https://avgnu.vimuser.org/t400/0069.jpg)
![](https://avgnu.vimuser.org/t400/0070.jpg) ![](https://avgnu.vimuser.org/t400/0071.jpg)
![](https://av.canoeboot.org/t400/0065.jpg) ![](https://av.canoeboot.org/t400/0066.jpg)
![](https://av.canoeboot.org/t400/0067.jpg) ![](https://av.canoeboot.org/t400/0069.jpg)
![](https://av.canoeboot.org/t400/0070.jpg) ![](https://av.canoeboot.org/t400/0071.jpg)
A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is
also fine:\
![](https://avgnu.vimuser.org/t400/0072.jpg)
![](https://av.canoeboot.org/t400/0072.jpg)
Of course, make sure to turn on your PSU:\
![](https://avgnu.vimuser.org/x200/disassembly/0013.jpg)
![](https://av.canoeboot.org/x200/disassembly/0013.jpg)
Now, you should be ready to install nonGeNUine Boot.
Now, you should be ready to install Canoeboot.
Refer to the external flashing instructions [here](spi.md), and when you're
done, re-assemble your laptop.
@ -198,7 +198,7 @@ When re-installing the heatsink, you must first clean off all old paste
with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much
better than the default paste used on these systems.
![](https://avgnu.vimuser.org/t400/paste.jpg)
![](https://av.canoeboot.org/t400/paste.jpg)
NOTE: the photo above is for illustration purposes only, and does not
show how to properly apply the thermal paste. Other guides online detail
@ -223,13 +223,13 @@ be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://avgnu.vimuser.org/t400/memory.jpg)
![](https://av.canoeboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://avgnu.vimuser.org/t400/boot0.jpg) ![](https://avgnu.vimuser.org/t400/boot1.jpg)
![](https://av.canoeboot.org/t400/boot0.jpg) ![](https://av.canoeboot.org/t400/boot1.jpg)
Now [install GNU+Linux](../gnulinux/).

98
site/docs/install/t500_external.md
View File

@ -5,12 +5,12 @@ x-toc-enable: true
**If you haven't bought a T500 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Initial flashing instructions for T500.
This guide is for those who want nonGeNUine Boot on their ThinkPad T500 while
This guide is for those who want Canoeboot on their ThinkPad T500 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your T500, to know how to recover.
@ -28,7 +28,7 @@ A note about CPUs
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T500) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work with nonGeNUine Boot. The T9600 was also tested on the T400 and
to work with Canoeboot. The T9600 was also tested on the T400 and
confirmed working.
T9550 and T9900 was tested by a user, and is compatible as reported in the IRC channel.
@ -58,7 +58,7 @@ Intel GPU; this is referred to as "switchable graphics". In the *BIOS
setup* program for lenovobios, you can specify that the system will use
one or the other (but not both).
nonGeNUine Boot is known to work on systems with only the Intel GPU, using
Canoeboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
@ -89,104 +89,104 @@ The procedure
-------------
Remove all screws:\
![](https://avgnu.vimuser.org/t500/0000.jpg)\
![](https://av.canoeboot.org/t500/0000.jpg)\
It is also advisable to, throughout the disassembly, place any screws
and/or components that you removed in the same layout or arrangement.
The follow photos demonstrate this:\
![](https://avgnu.vimuser.org/t500/0001.jpg) ![](https://avgnu.vimuser.org/t500/0002.jpg)
![](https://av.canoeboot.org/t500/0001.jpg) ![](https://av.canoeboot.org/t500/0002.jpg)
Remove the HDD/SSD and optical drive:\
![](https://avgnu.vimuser.org/t500/0003.jpg) ![](https://avgnu.vimuser.org/t500/0004.jpg)
![](https://av.canoeboot.org/t500/0003.jpg) ![](https://av.canoeboot.org/t500/0004.jpg)
Remove the palm rest:\
![](https://avgnu.vimuser.org/t500/0005.jpg) ![](https://avgnu.vimuser.org/t500/0006.jpg)
![](https://av.canoeboot.org/t500/0005.jpg) ![](https://av.canoeboot.org/t500/0006.jpg)
Remove the keyboard and rear bezel:\
![](https://avgnu.vimuser.org/t500/0007.jpg) ![](https://avgnu.vimuser.org/t500/0008.jpg)
![](https://avgnu.vimuser.org/t500/0009.jpg) ![](https://avgnu.vimuser.org/t500/0010.jpg)
![](https://avgnu.vimuser.org/t500/0011.jpg) ![](https://avgnu.vimuser.org/t500/0012.jpg)
![](https://av.canoeboot.org/t500/0007.jpg) ![](https://av.canoeboot.org/t500/0008.jpg)
![](https://av.canoeboot.org/t500/0009.jpg) ![](https://av.canoeboot.org/t500/0010.jpg)
![](https://av.canoeboot.org/t500/0011.jpg) ![](https://av.canoeboot.org/t500/0012.jpg)
If you have a WWAN/3G card and/or sim card reader, remove them
permanently. The WWAN-3G card has proprietary firmware inside; the
technology is identical to what is used in mobile phones, so it can also
track your movements:\
![](https://avgnu.vimuser.org/t500/0013.jpg) ![](https://avgnu.vimuser.org/t500/0017.jpg)
![](https://avgnu.vimuser.org/t500/0018.jpg)
![](https://av.canoeboot.org/t500/0013.jpg) ![](https://av.canoeboot.org/t500/0017.jpg)
![](https://av.canoeboot.org/t500/0018.jpg)
Remove this frame, and then remove the wifi chip:\
![](https://avgnu.vimuser.org/t500/0014.jpg) ![](https://avgnu.vimuser.org/t500/0015.jpg)
![](https://avgnu.vimuser.org/t500/0016.jpg)
![](https://av.canoeboot.org/t500/0014.jpg) ![](https://av.canoeboot.org/t500/0015.jpg)
![](https://av.canoeboot.org/t500/0016.jpg)
Remove the speakers:\
![](https://avgnu.vimuser.org/t500/0019.jpg) ![](https://avgnu.vimuser.org/t500/0020.jpg)
![](https://avgnu.vimuser.org/t500/0021.jpg) ![](https://avgnu.vimuser.org/t500/0022.jpg)
![](https://avgnu.vimuser.org/t500/0023.jpg) ![](https://avgnu.vimuser.org/t500/0024.jpg)
![](https://avgnu.vimuser.org/t500/0025.jpg)
![](https://av.canoeboot.org/t500/0019.jpg) ![](https://av.canoeboot.org/t500/0020.jpg)
![](https://av.canoeboot.org/t500/0021.jpg) ![](https://av.canoeboot.org/t500/0022.jpg)
![](https://av.canoeboot.org/t500/0023.jpg) ![](https://av.canoeboot.org/t500/0024.jpg)
![](https://av.canoeboot.org/t500/0025.jpg)
Remove the NVRAM battery (already removed in this photo):\
![](https://avgnu.vimuser.org/t500/0026.jpg)
![](https://av.canoeboot.org/t500/0026.jpg)
When you re-assemble, you will be replacing the wifi chip with another.
These two screws don't hold anything together, but they are included in
your system because the screw holes for half-height cards are a
different size, so use these if you will be installing a half-height
card:\
![](https://avgnu.vimuser.org/t500/0027.jpg)
![](https://av.canoeboot.org/t500/0027.jpg)
Unroute the antenna wires:\
![](https://avgnu.vimuser.org/t500/0028.jpg) ![](https://avgnu.vimuser.org/t500/0029.jpg)
![](https://avgnu.vimuser.org/t500/0030.jpg) ![](https://avgnu.vimuser.org/t500/0031.jpg)
![](https://av.canoeboot.org/t500/0028.jpg) ![](https://av.canoeboot.org/t500/0029.jpg)
![](https://av.canoeboot.org/t500/0030.jpg) ![](https://av.canoeboot.org/t500/0031.jpg)
Disconnect the LCD cable from the motherboard:\
![](https://avgnu.vimuser.org/t500/0032.jpg) ![](https://avgnu.vimuser.org/t500/0033.jpg)
![](https://av.canoeboot.org/t500/0032.jpg) ![](https://av.canoeboot.org/t500/0033.jpg)
Remove the LCD assembly hinge screws, and then remove the LCD assembly:\
![](https://avgnu.vimuser.org/t500/0034.jpg) ![](https://avgnu.vimuser.org/t500/0035.jpg)
![](https://avgnu.vimuser.org/t500/0036.jpg)
![](https://av.canoeboot.org/t500/0034.jpg) ![](https://av.canoeboot.org/t500/0035.jpg)
![](https://av.canoeboot.org/t500/0036.jpg)
Remove the fan and heatsink:\
![](https://avgnu.vimuser.org/t500/0037.jpg) ![](https://avgnu.vimuser.org/t500/0038.jpg)
![](https://avgnu.vimuser.org/t500/0039.jpg)
![](https://av.canoeboot.org/t500/0037.jpg) ![](https://av.canoeboot.org/t500/0038.jpg)
![](https://av.canoeboot.org/t500/0039.jpg)
Remove this screw:\
![](https://avgnu.vimuser.org/t500/0040.jpg)
![](https://av.canoeboot.org/t500/0040.jpg)
Remove these cables, keeping note of how and in what arrangement they
are connected:\
![](https://avgnu.vimuser.org/t500/0041.jpg) ![](https://avgnu.vimuser.org/t500/0042.jpg)
![](https://avgnu.vimuser.org/t500/0043.jpg) ![](https://avgnu.vimuser.org/t500/0044.jpg)
![](https://avgnu.vimuser.org/t500/0045.jpg) ![](https://avgnu.vimuser.org/t500/0046.jpg)
![](https://avgnu.vimuser.org/t500/0047.jpg) ![](https://avgnu.vimuser.org/t500/0048.jpg)
![](https://avgnu.vimuser.org/t500/0049.jpg)
![](https://av.canoeboot.org/t500/0041.jpg) ![](https://av.canoeboot.org/t500/0042.jpg)
![](https://av.canoeboot.org/t500/0043.jpg) ![](https://av.canoeboot.org/t500/0044.jpg)
![](https://av.canoeboot.org/t500/0045.jpg) ![](https://av.canoeboot.org/t500/0046.jpg)
![](https://av.canoeboot.org/t500/0047.jpg) ![](https://av.canoeboot.org/t500/0048.jpg)
![](https://av.canoeboot.org/t500/0049.jpg)
Disconnect the power jack:\
![](https://avgnu.vimuser.org/t500/0050.jpg) ![](https://avgnu.vimuser.org/t500/0051.jpg)
![](https://av.canoeboot.org/t500/0050.jpg) ![](https://av.canoeboot.org/t500/0051.jpg)
Remove the motherboard and cage from the base (the marked hole is where
those cables were routed through):\
![](https://avgnu.vimuser.org/t500/0052.jpg) ![](https://avgnu.vimuser.org/t500/0053.jpg)
![](https://av.canoeboot.org/t500/0052.jpg) ![](https://av.canoeboot.org/t500/0053.jpg)
Remove all screws, arranging them in the same layout when placing the
screws on a surface and marking each screw hole (this is to reduce the
possibility of putting them back in the wrong holes):\
![](https://avgnu.vimuser.org/t500/0054.jpg) ![](https://avgnu.vimuser.org/t500/0055.jpg)
![](https://av.canoeboot.org/t500/0054.jpg) ![](https://av.canoeboot.org/t500/0055.jpg)
Also remove this:\
![](https://avgnu.vimuser.org/t500/0056.jpg) ![](https://avgnu.vimuser.org/t500/0057.jpg)
![](https://av.canoeboot.org/t500/0056.jpg) ![](https://av.canoeboot.org/t500/0057.jpg)
Separate the motherboard from the cage:\
![](https://avgnu.vimuser.org/t500/0058.jpg) ![](https://avgnu.vimuser.org/t500/0059.jpg)
![](https://av.canoeboot.org/t500/0058.jpg) ![](https://av.canoeboot.org/t500/0059.jpg)
The flash chip is next to the memory slots. On this system, it was a
SOIC-8 (4MiB or 32Mb) flash chip:\
![](https://avgnu.vimuser.org/t500/0060.jpg)
![](https://av.canoeboot.org/t500/0060.jpg)
Connect your programmer, then connect GND and 3.3V\
![](https://avgnu.vimuser.org/t500/0061.jpg)\
![](https://avgnu.vimuser.org/t400/0067.jpg) ![](https://avgnu.vimuser.org/t400/0069.jpg)
![](https://avgnu.vimuser.org/t400/0070.jpg) ![](https://avgnu.vimuser.org/t400/0071.jpg)
![](https://av.canoeboot.org/t500/0061.jpg)\
![](https://av.canoeboot.org/t400/0067.jpg) ![](https://av.canoeboot.org/t400/0069.jpg)
![](https://av.canoeboot.org/t400/0070.jpg) ![](https://av.canoeboot.org/t400/0071.jpg)
Now flash nonGeNUine Boot.
Now flash Canoeboot.
Thermal paste (IMPORTANT)
=========================
@ -199,7 +199,7 @@ When re-installing the heatsink, you must first clean off all old paste
with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much
better than the default paste used on these systems.
![](https://avgnu.vimuser.org/t400/paste.jpg)
![](https://av.canoeboot.org/t400/paste.jpg)
NOTE: the photo above is for illustration purposes only, and does not
show how to properly apply the thermal paste. Other guides online detail
@ -217,13 +217,13 @@ Some T500 laptops might come with an Atheros chipset, but this is
802.11g only.
It is recommended that you install a new wifi chipset. This can only be
done after installing nonGeNUine Boot, because the original firmware has a
done after installing Canoeboot, because the original firmware has a
whitelist of approved chips, and it will refuse to boot if you use an
'unauthorized' wifi card.
The following photos show an Atheros AR5B95 being installed, to replace
the Intel chip that this T500 came with:\
![](https://avgnu.vimuser.org/t400/0012.jpg) ![](https://avgnu.vimuser.org/t400/ar5b95.jpg)
![](https://av.canoeboot.org/t400/0012.jpg) ![](https://av.canoeboot.org/t400/ar5b95.jpg)
WWAN
====
@ -254,13 +254,13 @@ be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://avgnu.vimuser.org/t400/memory.jpg)
![](https://av.canoeboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://avgnu.vimuser.org/t500/0062.jpg)
![](https://av.canoeboot.org/t500/0062.jpg)
Now [install GNU+Linux](../gnulinux/).

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

@ -9,7 +9,7 @@ your ThinkPad T60 from booting.
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in nonGeNUine Boot, so bricks are rare.
ROM images for this machine are well-tested in Canoeboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -17,9 +17,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had nonGeNUine Boot running and you flashed
You still have Lenovo BIOS, or you had Canoeboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and nonGeNUine Boot wasn't flashed.
Lenovo BIOS was present and Canoeboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -41,10 +41,10 @@ you re-flash a second time and set it back to 0.
In this case, unbricking is easy: reset BUC.TS to 0 by removing that
yellow cmos coin (it's a battery) and putting it back after a minute or
two:\
![](https://avgnu.vimuser.org/t60_dev/0006.JPG)
![](https://av.canoeboot.org/t60_dev/0006.JPG)
\*Those dd commands should be applied to all newly compiled T60 ROM
images (the ROM images in nonGeNUine Boot binary archives already have this
images (the ROM images in Canoeboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -72,65 +72,65 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where nonGeNUine Boot resides).
flash the SPI chip (where Canoeboot resides).
Remove those screws and remove the HDD:\
![](https://avgnu.vimuser.org/t60_dev/0001.JPG) ![](https://avgnu.vimuser.org/t60_dev/0002.JPG)
![](https://av.canoeboot.org/t60_dev/0001.JPG) ![](https://av.canoeboot.org/t60_dev/0002.JPG)
Lift off the palm rest:\
![](https://avgnu.vimuser.org/t60_dev/0003.JPG)
![](https://av.canoeboot.org/t60_dev/0003.JPG)
Lift up the keyboard, pull it back a bit, flip it over like that and
then disconnect it from the board:\
![](https://avgnu.vimuser.org/t60_dev/0004.JPG) ![](https://avgnu.vimuser.org/t60_dev/0005.JPG)
![](https://avgnu.vimuser.org/t60_dev/0006.JPG)
![](https://av.canoeboot.org/t60_dev/0004.JPG) ![](https://av.canoeboot.org/t60_dev/0005.JPG)
![](https://av.canoeboot.org/t60_dev/0006.JPG)
Gently wedge both sides loose:\
![](https://avgnu.vimuser.org/t60_dev/0007.JPG) ![](https://avgnu.vimuser.org/t60_dev/0008.JPG)
![](https://av.canoeboot.org/t60_dev/0007.JPG) ![](https://av.canoeboot.org/t60_dev/0008.JPG)
Remove that cable from the position:\
![](https://avgnu.vimuser.org/t60_dev/0009.JPG) ![](https://avgnu.vimuser.org/t60_dev/0010.JPG)
![](https://av.canoeboot.org/t60_dev/0009.JPG) ![](https://av.canoeboot.org/t60_dev/0010.JPG)
Now remove that bezel. Remove wifi, nvram battery and speaker connector
(also remove 56k modem, on the left of wifi):\
![](https://avgnu.vimuser.org/t60_dev/0011.JPG)
![](https://av.canoeboot.org/t60_dev/0011.JPG)
Remove those screws:\
![](https://avgnu.vimuser.org/t60_dev/0012.JPG)
![](https://av.canoeboot.org/t60_dev/0012.JPG)
Disconnect the power jack:\
![](https://avgnu.vimuser.org/t60_dev/0013.JPG)
![](https://av.canoeboot.org/t60_dev/0013.JPG)
Remove nvram battery:\
![](https://avgnu.vimuser.org/t60_dev/0014.JPG)
![](https://av.canoeboot.org/t60_dev/0014.JPG)
Disconnect cable (for 56k modem) and disconnect the other cable:\
![](https://avgnu.vimuser.org/t60_dev/0015.JPG) ![](https://avgnu.vimuser.org/t60_dev/0016.JPG)
![](https://av.canoeboot.org/t60_dev/0015.JPG) ![](https://av.canoeboot.org/t60_dev/0016.JPG)
Disconnect speaker cable:\
![](https://avgnu.vimuser.org/t60_dev/0017.JPG)
![](https://av.canoeboot.org/t60_dev/0017.JPG)
Disconnect the other end of the 56k modem cable:\
![](https://avgnu.vimuser.org/t60_dev/0018.JPG)
![](https://av.canoeboot.org/t60_dev/0018.JPG)
Make sure you removed it:\
![](https://avgnu.vimuser.org/t60_dev/0019.JPG)
![](https://av.canoeboot.org/t60_dev/0019.JPG)
Unscrew those:\
![](https://avgnu.vimuser.org/t60_dev/0020.JPG)
![](https://av.canoeboot.org/t60_dev/0020.JPG)
Make sure you removed those:\
![](https://avgnu.vimuser.org/t60_dev/0021.JPG)
![](https://av.canoeboot.org/t60_dev/0021.JPG)
Disconnect LCD cable from board:\
![](https://avgnu.vimuser.org/t60_dev/0022.JPG)
![](https://av.canoeboot.org/t60_dev/0022.JPG)
Remove those screws then remove the LCD assembly:\
![](https://avgnu.vimuser.org/t60_dev/0023.JPG) ![](https://avgnu.vimuser.org/t60_dev/0024.JPG)
![](https://avgnu.vimuser.org/t60_dev/0025.JPG)
![](https://av.canoeboot.org/t60_dev/0023.JPG) ![](https://av.canoeboot.org/t60_dev/0024.JPG)
![](https://av.canoeboot.org/t60_dev/0025.JPG)
Once again, make sure you removed those:\
![](https://avgnu.vimuser.org/t60_dev/0026.JPG)
![](https://av.canoeboot.org/t60_dev/0026.JPG)
Remove the shielding containing the motherboard, then flip it over.
Remove these screws, placing them on a steady surface in the same layout
@ -139,13 +139,13 @@ screw hole after removing the screw (a permanent marker pen will do),
this is so that you have a point of reference when re-assembling the
system:
![](https://avgnu.vimuser.org/t60_dev/0027.JPG) ![](https://avgnu.vimuser.org/t60_dev/0028.JPG)
![](https://avgnu.vimuser.org/t60_dev/0029.JPG) ![](https://avgnu.vimuser.org/t60_dev/0031.JPG)
![](https://avgnu.vimuser.org/t60_dev/0032.JPG) ![](https://avgnu.vimuser.org/t60_dev/0033.JPG)
![](https://av.canoeboot.org/t60_dev/0027.JPG) ![](https://av.canoeboot.org/t60_dev/0028.JPG)
![](https://av.canoeboot.org/t60_dev/0029.JPG) ![](https://av.canoeboot.org/t60_dev/0031.JPG)
![](https://av.canoeboot.org/t60_dev/0032.JPG) ![](https://av.canoeboot.org/t60_dev/0033.JPG)
This photo shows the flash chip, near the RAM, with numbers of pins written:
![](https://avgnu.vimuser.org/t60_dev/0030.JPG)
![](https://av.canoeboot.org/t60_dev/0030.JPG)
Refer to the external flashing guide:
@ -160,7 +160,7 @@ which all draw a lot of current, more than your flasher can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w nongenuineboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w canoeboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or
@ -174,48 +174,48 @@ complains about multiple flash chip definitions detected, then choose
one of them following the instructions in the output.
Put those screws back:\
![](https://avgnu.vimuser.org/t60_dev/0047.JPG)
![](https://av.canoeboot.org/t60_dev/0047.JPG)
Put it back into lower chassis:\
![](https://avgnu.vimuser.org/t60_dev/0048.JPG)
![](https://av.canoeboot.org/t60_dev/0048.JPG)
Attach LCD and insert screws (also, attach the lcd cable to the board):\
![](https://avgnu.vimuser.org/t60_dev/0049.JPG)
![](https://av.canoeboot.org/t60_dev/0049.JPG)
Insert those screws:\
![](https://avgnu.vimuser.org/t60_dev/0050.JPG)
![](https://av.canoeboot.org/t60_dev/0050.JPG)
On the CPU (and there is another chip south-east to it, sorry forgot to
take pic) clean off the old thermal paste (with the alcohol) and apply
new (Artic Silver 5 is good, others are good too) you should also clean
the heatsink the same way\
![](https://avgnu.vimuser.org/t60_dev/0051.JPG)
![](https://av.canoeboot.org/t60_dev/0051.JPG)
Attach the heatsink and install the screws (also, make sure to install
the AC jack as highlighted):\
![](https://avgnu.vimuser.org/t60_dev/0052.JPG)
![](https://av.canoeboot.org/t60_dev/0052.JPG)
Reinstall that upper bezel:\
![](https://avgnu.vimuser.org/t60_dev/0053.JPG)
![](https://av.canoeboot.org/t60_dev/0053.JPG)
Do that:\
![](https://avgnu.vimuser.org/t60_dev/0054.JPG) ![](https://avgnu.vimuser.org/t60_dev/0055.JPG)
![](https://av.canoeboot.org/t60_dev/0054.JPG) ![](https://av.canoeboot.org/t60_dev/0055.JPG)
Re-attach modem, wifi, (wwan?), and all necessary cables. Sorry, forgot
to take pics. Look at previous removal steps to see where they go back
to.
Attach keyboard and install nvram battery:\
![](https://avgnu.vimuser.org/t60_dev/0056.JPG) ![](https://avgnu.vimuser.org/t60_dev/0057.JPG)
![](https://av.canoeboot.org/t60_dev/0056.JPG) ![](https://av.canoeboot.org/t60_dev/0057.JPG)
Place keyboard and (sorry, forgot to take pics) reinstall the palmrest
and insert screws on the underside:\
![](https://avgnu.vimuser.org/t60_dev/0058.JPG)
![](https://av.canoeboot.org/t60_dev/0058.JPG)
It lives!\
![](https://avgnu.vimuser.org/t60_dev/0071.JPG) ![](https://avgnu.vimuser.org/t60_dev/0072.JPG)
![](https://avgnu.vimuser.org/t60_dev/0073.JPG)
![](https://av.canoeboot.org/t60_dev/0071.JPG) ![](https://av.canoeboot.org/t60_dev/0072.JPG)
![](https://av.canoeboot.org/t60_dev/0073.JPG)
Always stress test ('stress -c 2' and xsensors. below 90C is ok) when
replacing cpu paste/heatsink:\
![](https://avgnu.vimuser.org/t60_dev/0074.JPG)
![](https://av.canoeboot.org/t60_dev/0074.JPG)

34
site/docs/install/x200_external.md
View File

@ -5,10 +5,10 @@ x-toc-enable: true
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
This guide is for those who want nonGeNUine Boot on their ThinkPad X200 while
This guide is for those who want Canoeboot on their ThinkPad X200 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your X200, to know how to recover.
@ -18,7 +18,7 @@ underneath the palm rest. You will then connect an external SPI programmer, to
re-flash the chip externally while it is powered off with the battery removed.
NOTE: This guide only applies to the regular X200. For X200S and X200 Tablet
flashing, please read other guides available on the nonGeNUine Boot website.
flashing, please read other guides available on the Canoeboot website.
Flash chip size
===============
@ -40,27 +40,27 @@ Tablet (for those systems, you have to remove the motherboard
completely, since the flash chip is on the other side of the board).
Remove these screws:\
![](https://avgnu.vimuser.org/x200/disassembly/0003.jpg)
![](https://av.canoeboot.org/x200/disassembly/0003.jpg)
Gently push the keyboard towards the screen, then lift it off, and optionally
disconnect it from the board:\
![](https://avgnu.vimuser.org/x200/disassembly/0004.jpg)
![](https://avgnu.vimuser.org/x200/disassembly/0005.jpg)
![](https://av.canoeboot.org/x200/disassembly/0004.jpg)
![](https://av.canoeboot.org/x200/disassembly/0005.jpg)
Disconnect the cable of the fingerpring reader, and then pull up the palm rest,
lifting up the left and right side of it:\
![](https://avgnu.vimuser.org/x200/disassembly/0006.1.jpg)
![](https://avgnu.vimuser.org/x200/disassembly/0006.jpg)
![](https://av.canoeboot.org/x200/disassembly/0006.1.jpg)
![](https://av.canoeboot.org/x200/disassembly/0006.jpg)
This shows the location of the flash chip, for both SOIC-8 and SOIC-16:\
![](https://avgnu.vimuser.org/x200/x200_soic16.jpg)
![](https://avgnu.vimuser.org/x200/x200_soic8.jpg)
![](https://av.canoeboot.org/x200/x200_soic16.jpg)
![](https://av.canoeboot.org/x200/x200_soic8.jpg)
Lift back the tape that covers a part of the flash chip, and then
connect the clip:\
![](https://avgnu.vimuser.org/x200/disassembly/0008.jpg)
![](https://av.canoeboot.org/x200/disassembly/0008.jpg)
Now, you should be ready to install nonGeNUine Boot.
Now, you should be ready to install Canoeboot.
Refer to the [SPI programming instructions](spi.md).
@ -83,14 +83,14 @@ Make sure that the RAM you buy is the 2Rx8 configuration when buying 4GiB sticks
In this photo, 8GiB of RAM (2x4GiB) is installed:
![](https://avgnu.vimuser.org/x200/disassembly/0018.jpg)
![](https://av.canoeboot.org/x200/disassembly/0018.jpg)
Boot it!
--------
You should see something like this:
![](https://avgnu.vimuser.org/x200/disassembly/0019.jpg)
![](https://av.canoeboot.org/x200/disassembly/0019.jpg)
Now [install GNU+Linux](../gnulinux/).
@ -104,7 +104,7 @@ was proven correct; however, it is still useless in practise.
Look just above the 7 in TP37 (that's GPIO33):
![](https://avgnu.vimuser.org/x200/gpio33_location.jpg)
![](https://av.canoeboot.org/x200/gpio33_location.jpg)
By default we would see this in lenovobios, when trying flashrom -p
internal -w rom.rom:
@ -149,13 +149,13 @@ 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 GNU+Linux,
then load a flashrom 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 nonGeNUine Boot image.
actually flash the entire chip, with just a normal Canoeboot image.
It's possible. The above is likely the only way that the Lenovo BIOS updater
program works. So if we discover precisely how to do that, then you could
just connect some pogo pins to ground GPIO33, then boot up, run some software
(which would have to be written) that does the above.
On a related note, nonGeNUine Boot has a utility that could help with
On a related note, Canoeboot has a utility that could help with
investigating this:
[ich9utils.md#demefactory](ich9utils.md#demefactory)

34
site/docs/install/x200_external.uk.md
View File

@ -5,10 +5,10 @@ x-toc-enable: true
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to nonGeNUine Boot. It is the
it can be flashed entirely in software from Dell BIOS to Canoeboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Цей посібник призначений для тих, хто бажає nonGeNUine Boot на своєму ThinkPad X200,
Цей посібник призначений для тих, хто бажає Canoeboot на своєму ThinkPad X200,
поки у нього все ще є оригінальний Lenovo BIOS в наявності. Цього керівництва також можна
дотримуватися (адаптувати), якщо ви перетворили ваш X200 на цеглину, щоб знати, як його відновити.
@ -18,7 +18,7 @@ same hardware generation (GM45), with same CPUs, video processor, etc.**
повторно прошити мікросхему зовні, коли вона вимкнена та акумулятор висунуто.
ПРИМІТКА: Цей посібник стосується лише звичайного X200. Для перепрошивки X200S та X200 Tablet,
будь-ласка прочитайте інші посібники, доступні на nonGeNUine Boot
будь-ласка прочитайте інші посібники, доступні на Canoeboot
Розмір флеш-чіпа
===============
@ -40,27 +40,27 @@ Tablet (для цих систем потрібно повністю видал
оскільки мікросхема флеш-пам'яті знаходиться з іншого боку плати).
Викрутіть ці гвинти:\
![](https://avgnu.vimuser.org/x200/disassembly/0003.jpg)
![](https://av.canoeboot.org/x200/disassembly/0003.jpg)
Обережно притисніть клавіатуру до екрана, потім підніміть її та за бажанням
від'єднайте від плати:\
![](https://avgnu.vimuser.org/x200/disassembly/0004.jpg)
![](https://avgnu.vimuser.org/x200/disassembly/0005.jpg)
![](https://av.canoeboot.org/x200/disassembly/0004.jpg)
![](https://av.canoeboot.org/x200/disassembly/0005.jpg)
Від'єднайте кабель пристрою для зчитування відбитків пальців, а потім потягніть упор для рук,
піднявши його ліву та праву сторону:\
![](https://avgnu.vimuser.org/x200/disassembly/0006.1.jpg)
![](https://avgnu.vimuser.org/x200/disassembly/0006.jpg)
![](https://av.canoeboot.org/x200/disassembly/0006.1.jpg)
![](https://av.canoeboot.org/x200/disassembly/0006.jpg)
Тут показано розташування мікросхеми флеш-пам'яті, для обох SOIC-8 та SOIC-16:\
![](https://avgnu.vimuser.org/x200/x200_soic16.jpg)
![](https://avgnu.vimuser.org/x200/x200_soic8.jpg)
![](https://av.canoeboot.org/x200/x200_soic16.jpg)
![](https://av.canoeboot.org/x200/x200_soic8.jpg)
Підніміть стрічку, яка закриває частину флеш-пам'яті, а потім
приєднайте затискач:\
![](https://avgnu.vimuser.org/x200/disassembly/0008.jpg)
![](https://av.canoeboot.org/x200/disassembly/0008.jpg)
Тепер ви повинні бути готові до встановлення nonGeNUine Boot.
Тепер ви повинні бути готові до встановлення Canoeboot.
Зверніться до [інструкцій програмування SPI](spi.md).
@ -83,14 +83,14 @@ Tablet (для цих систем потрібно повністю видал
На цьому фото встановлено 8 ГБ оперативної пам'яті (2x4ГБ):
![](https://avgnu.vimuser.org/x200/disassembly/0018.jpg)
![](https://av.canoeboot.org/x200/disassembly/0018.jpg)
Завантажуйтесь!
--------
Ви маєте побачити щось подібне цьому:
![](https://avgnu.vimuser.org/x200/disassembly/0019.jpg)
![](https://av.canoeboot.org/x200/disassembly/0019.jpg)
Тепер [встановлюйте GNU+Linux](../gnulinux/).
@ -104,7 +104,7 @@ sgsit дізнався про контакт під назвою GPIO33, яки
Подивіться трохи вище 7 у TP37 (це GPIO33):
![](https://avgnu.vimuser.org/x200/gpio33_location.jpg)
![](https://av.canoeboot.org/x200/gpio33_location.jpg)
Це замовчуванням ми побачимо це в lenovobios, під час спроби flashrom -p
internal -w rom.rom:
@ -143,13 +143,13 @@ internal -w rom.rom:
Windows), а потім відтворивши її дії за допомогою якогось інструменту для GNU+Linux,
а потім завантаживши двійковий файл flashrom в пам'ять та ROM для прошивки (для BIOS
регіона). Ви б зробили це з заземленням GPIO33, і програма корисного навантаження
фактично прошиє весь чіп, лише звичайним образом nonGeNUine Boot.
фактично прошиє весь чіп, лише звичайним образом Canoeboot.
Це можливо. Ймовірно, це єдиний спосіб роботи програми оновлення BIOS Lenovo.
Отже, якщо ми дізнаємося, як саме це зробити, тоді ви можете просто підключити кілька
контактів pogo для заземлення GPIO33, потім завантажитися, запустити програмне забезпечення
(яке потрібно було б написати), яке виконує вищезазначене.
У зв'язку з цим у nonGeNUine Boot є утиліта, яка може допомогти
У зв'язку з цим у Canoeboot є утиліта, яка може допомогти
розслідувати це:
[ich9utils.md#demefactory](ich9utils.md#demefactory)

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

@ -6,7 +6,7 @@ x-toc-enable: true
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in nonGeNUine Boot, so bricks are rare.
ROM images for this machine are well-tested in Canoeboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -14,9 +14,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had nonGeNUine Boot running and you flashed
You still have Lenovo BIOS, or you had Canoeboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and nonGeNUine Boot wasn't flashed.
Lenovo BIOS was present and Canoeboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -38,10 +38,10 @@ you re-flash a second time and set it back to 0.
In this case, unbricking is easy: reset BUC.TS to 0 by removing that
yellow cmos coin (it's a battery) and putting it back after a minute or
two:\
![](https://avgnu.vimuser.org/x60_unbrick/0004.jpg)\
![](https://av.canoeboot.org/x60_unbrick/0004.jpg)\
\*Those dd commands should be applied to all newly compiled X60 ROM
images (the ROM images in nonGeNUine Boot binary archives already have this
images (the ROM images in Canoeboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -68,66 +68,66 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where nonGeNUine Boot resides).
flash the SPI chip (where Canoeboot resides).
Remove those screws:\
![](https://avgnu.vimuser.org/x60_unbrick/0000.jpg)
![](https://av.canoeboot.org/x60_unbrick/0000.jpg)
Push the keyboard forward (carefully):\
![](https://avgnu.vimuser.org/x60_unbrick/0001.jpg)
![](https://av.canoeboot.org/x60_unbrick/0001.jpg)
Lift the keyboard up and disconnect it from the board:\
![](https://avgnu.vimuser.org/x60_unbrick/0002.jpg)
![](https://av.canoeboot.org/x60_unbrick/0002.jpg)
Grab the right-hand side of the chassis and force it off (gently) and
pry up the rest of the chassis:\
![](https://avgnu.vimuser.org/x60_unbrick/0003.jpg)
![](https://av.canoeboot.org/x60_unbrick/0003.jpg)
You should now have this:\
![](https://avgnu.vimuser.org/x60_unbrick/0004.jpg)
![](https://av.canoeboot.org/x60_unbrick/0004.jpg)
Disconnect the wifi antenna cables, the modem cable and the speaker:\
![](https://avgnu.vimuser.org/x60_unbrick/0005.jpg)
![](https://av.canoeboot.org/x60_unbrick/0005.jpg)
Unroute the cables along their path, carefully lifting the tape that
holds them in place. Then, disconnect the modem cable (other end) and
power connection and unroute all the cables so that they dangle by the
monitor hinge on the right-hand side:\
![](https://avgnu.vimuser.org/x60_unbrick/0006.jpg)
![](https://av.canoeboot.org/x60_unbrick/0006.jpg)
Disconnect the monitor from the motherboard, and unroute the grey
antenna cable, carefully lifting the tape that holds it into place:\
![](https://avgnu.vimuser.org/x60_unbrick/0008.jpg)
![](https://av.canoeboot.org/x60_unbrick/0008.jpg)
Carefully lift the remaining tape and unroute the left antenna cable so
that it is loose:\
![](https://avgnu.vimuser.org/x60_unbrick/0009.jpg)
![](https://av.canoeboot.org/x60_unbrick/0009.jpg)
Remove the screw that is highlighted (do NOT remove the other one; it
holds part of the heatsink (other side) into place):\
![](https://avgnu.vimuser.org/x60_unbrick/0011.jpg)
![](https://av.canoeboot.org/x60_unbrick/0011.jpg)
Remove those screws:\
![](https://avgnu.vimuser.org/x60_unbrick/0012.jpg)
![](https://av.canoeboot.org/x60_unbrick/0012.jpg)
Carefully remove the plate, like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0013.jpg)
![](https://av.canoeboot.org/x60_unbrick/0013.jpg)
Remove the SATA connector:\
![](https://avgnu.vimuser.org/x60_unbrick/0014.jpg)
![](https://av.canoeboot.org/x60_unbrick/0014.jpg)
Now remove the motherboard (gently) and cast the lcd/chassis aside:\
![](https://avgnu.vimuser.org/x60_unbrick/0015.jpg)
![](https://av.canoeboot.org/x60_unbrick/0015.jpg)
Lift back that tape and hold it with something. Highlighted is the SPI
flash chip:\
![](https://avgnu.vimuser.org/x60_unbrick/0016.jpg)
![](https://av.canoeboot.org/x60_unbrick/0016.jpg)
Here is another photo, with the numbers of the pins written:\
![](https://avgnu.vimuser.org/x60_unbrick/0017.jpg)\
![](https://av.canoeboot.org/x60_unbrick/0017.jpg)\
This photo shows an SPI flasher used, with SOIC8 test clip:\
![](https://avgnu.vimuser.org/x60/th_bbb_flashing.jpg)
![](https://av.canoeboot.org/x60/th_bbb_flashing.jpg)
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
@ -141,74 +141,74 @@ which all draw a lot of current, more than your programmer can provide.
When you're finished flashing, remove the programmer and put it away somewhere.
Put back the tape and press firmly over it:\
![](https://avgnu.vimuser.org/x60_unbrick/0026.jpg)
![](https://av.canoeboot.org/x60_unbrick/0026.jpg)
Your empty chassis:\
![](https://avgnu.vimuser.org/x60_unbrick/0027.jpg)
![](https://av.canoeboot.org/x60_unbrick/0027.jpg)
Put the motherboard back in:\
![](https://avgnu.vimuser.org/x60_unbrick/0028.jpg)
![](https://av.canoeboot.org/x60_unbrick/0028.jpg)
Reconnect SATA:\
![](https://avgnu.vimuser.org/x60_unbrick/0029.jpg)
![](https://av.canoeboot.org/x60_unbrick/0029.jpg)
Put the plate back and re-insert those screws:\
![](https://avgnu.vimuser.org/x60_unbrick/0030.jpg)
![](https://av.canoeboot.org/x60_unbrick/0030.jpg)
Re-route that antenna cable around the fan and apply the tape:\
![](https://avgnu.vimuser.org/x60_unbrick/0031.jpg)
![](https://av.canoeboot.org/x60_unbrick/0031.jpg)
Route the cable here and then (not shown, due to error on my part)
reconnect the monitor cable to the motherboard and re-insert the
screws:\
![](https://avgnu.vimuser.org/x60_unbrick/0032.jpg)
![](https://av.canoeboot.org/x60_unbrick/0032.jpg)
Re-insert that screw:\
![](https://avgnu.vimuser.org/x60_unbrick/0033.jpg)
![](https://av.canoeboot.org/x60_unbrick/0033.jpg)
Route the black antenna cable like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0034.jpg)
![](https://av.canoeboot.org/x60_unbrick/0034.jpg)
Tuck it in neatly like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0035.jpg)
![](https://av.canoeboot.org/x60_unbrick/0035.jpg)
Route the modem cable like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0036.jpg)
![](https://av.canoeboot.org/x60_unbrick/0036.jpg)
Connect modem cable to board and tuck it in neatly like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0037.jpg)
![](https://av.canoeboot.org/x60_unbrick/0037.jpg)
Route the power connection and connect it to the board like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0038.jpg)
![](https://av.canoeboot.org/x60_unbrick/0038.jpg)
Route the antenna and modem cables neatly like so:\
![](https://avgnu.vimuser.org/x60_unbrick/0039.jpg)
![](https://av.canoeboot.org/x60_unbrick/0039.jpg)
Connect the wifi antenna cables. At the start of the tutorial, this
system had an Intel wifi chip. Here you see I've replaced it with an
Atheros AR5B95 (supports 802.11n and can be used without blobs):\
![](https://avgnu.vimuser.org/x60_unbrick/0040.jpg)
![](https://av.canoeboot.org/x60_unbrick/0040.jpg)
Connect the modem cable:\
![](https://avgnu.vimuser.org/x60_unbrick/0041.jpg)
![](https://av.canoeboot.org/x60_unbrick/0041.jpg)
Connect the speaker:\
![](https://avgnu.vimuser.org/x60_unbrick/0042.jpg)
![](https://av.canoeboot.org/x60_unbrick/0042.jpg)
You should now have this:\
![](https://avgnu.vimuser.org/x60_unbrick/0043.jpg)
![](https://av.canoeboot.org/x60_unbrick/0043.jpg)
Re-connect the upper chassis:\
![](https://avgnu.vimuser.org/x60_unbrick/0044.jpg)
![](https://av.canoeboot.org/x60_unbrick/0044.jpg)
Re-connect the keyboard:\
![](https://avgnu.vimuser.org/x60_unbrick/0045.jpg)
![](https://av.canoeboot.org/x60_unbrick/0045.jpg)
Re-insert the screws that you removed earlier:\
![](https://avgnu.vimuser.org/x60_unbrick/0046.jpg)
![](https://av.canoeboot.org/x60_unbrick/0046.jpg)
Power on!\
![](https://avgnu.vimuser.org/x60_unbrick/0047.jpg)
![](https://av.canoeboot.org/x60_unbrick/0047.jpg)
Operating system:\
![](https://avgnu.vimuser.org/x60_unbrick/0049.jpg)
![](https://av.canoeboot.org/x60_unbrick/0049.jpg)

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

@ -6,7 +6,7 @@ x-toc-enable: true
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 Tablet from booting.
ROM images for this machine are well-tested in nonGeNUine Boot, so bricks are rare.
ROM images for this machine are well-tested in Canoeboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
@ -14,9 +14,9 @@ one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had nonGeNUine Boot running and you flashed
You still have Lenovo BIOS, or you had Canoeboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and nonGeNUine Boot wasn't flashed.
Lenovo BIOS was present and Canoeboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
@ -38,10 +38,10 @@ you re-flash a second time and set it back to 0.
In this case, unbricking is easy: reset BUC.TS to 0 by removing that
yellow cmos coin (it's a battery) and putting it back after a minute or
two:\
![](https://avgnu.vimuser.org/x60t_unbrick/0008.JPG)\
![](https://av.canoeboot.org/x60t_unbrick/0008.JPG)\
\*Those dd commands should be applied to all newly compiled X60 ROM
images (the ROM images in nonGeNUine Boot binary archives already have this
images (the ROM images in Canoeboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
@ -68,45 +68,45 @@ will not boot at all.
"Unbricking" means flashing a known-good (working) ROM. The problem:
you can't boot the system, making this difficult. In this situation,
external hardware (see hardware requirements above) is needed which can
flash the SPI chip (where nonGeNUine Boot resides).
flash the SPI chip (where Canoeboot resides).
![](https://avgnu.vimuser.org/x60t_unbrick/0000.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0000.JPG)
Remove those screws:\
![](https://avgnu.vimuser.org/x60t_unbrick/0001.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0001.JPG)
Remove the HDD:\
![](https://avgnu.vimuser.org/x60t_unbrick/0002.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0002.JPG)
Push keyboard forward to loosen it:\
![](https://avgnu.vimuser.org/x60t_unbrick/0003.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0003.JPG)
Lift:\
![](https://avgnu.vimuser.org/x60t_unbrick/0004.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0004.JPG)
Remove those:\
![](https://avgnu.vimuser.org/x60t_unbrick/0005.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0005.JPG)
![](https://avgnu.vimuser.org/x60t_unbrick/0006.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0006.JPG)
Also remove that (marked) and unroute the antenna cables:\
![](https://avgnu.vimuser.org/x60t_unbrick/0007.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0007.JPG)
For some X60T laptops, you have to unroute those too:\
![](https://avgnu.vimuser.org/x60t_unbrick/0010.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0010.JPG)
Remove the LCD extend board screws. Also remove those screws (see blue
marks) and remove/unroute the cables and remove the metal plate:\
![](https://avgnu.vimuser.org/x60t_unbrick/0008.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0008.JPG)
Remove that screw and then remove the board:\
![](https://avgnu.vimuser.org/x60t_unbrick/0009.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0009.JPG)
This photo shows the flash location:\
![](https://avgnu.vimuser.org/x60t_unbrick/0011.JPG)
![](https://av.canoeboot.org/x60t_unbrick/0011.JPG)
This photo shows an SPI flasher used, with SOIC8 test clip:\
![](https://avgnu.vimuser.org/x60/th_bbb_flashing.jpg)
![](https://av.canoeboot.org/x60/th_bbb_flashing.jpg)
Refer to the external flashing guide:

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

File diff suppressed because it is too large Load Diff

331
site/docs/maintain/style.md Normal file
View File

@ -0,0 +1,331 @@
---
title: cbmk coding style and design
x-toc-enable: true
...
This document is extremely new, and may change rapidly.
For context, please also read the main [cbmk maintenance manual](index.md).
You should *read* the logic in cbmk yourself, to really know what is meant by
some of the concepts explained here. This article will no doubt be incomplete,
and several practises may persist in spite of it; nonetheless, this article
shall serve as a reference for cbmk development.
NO BASHISMS
===========
Canoeboot's build system, cbmk (CanoeBoot MaKe) is written entirely in POSIX
shell (sh) scripts. This is thanks to the work done by Ferass El Hafidi on
the *Libreboot* build system, lbmk (LibreBoot MaKe), upon which Canoeboot is
based.
Here is an *excellent* introduction to posix `sh` scripting:
<https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html>
and an even more excellent introduction:
<https://vermaden.wordpress.com/ghost-in-the-shell/>
(seriously, it's good. Read it!)
Design
======
Canoeboot's build system design is very simple: put as much as possible
under `config/`, and keep actual logic to a minimum.
You can read about that design in the [cbmk maintenance manual](index.md).
No Makefiles
------------
We have Makefiles in some C programs, under `util/`, and projects that we import
may use Makefiles, but cbmk itself does not contain any Makefiles. Instead, we
do everything in shell scripts.
This approach has certain drawbacks, but for the most part it ensures that the
code is more readable. It's easier to implement a cleaner coding style, which
the next sections will cover.
Coding style
============
Read <https://man.openbsd.org/style.9> and go read a few userland program source
trees in OpenBSD's main CVS tree. This is the style that inspires the cbmk
coding style; OpenBSD's style pertains to C programming, and it has been adapted
for shell scripts in the Canoeboot build system, cbmk.
You should read the OpenBSD style and go read OpenBSD utils, especially userland
programs like `cat` or `ls` in the OpenBSD `src` tree.
Canoeboot scripts, and also C programs like `nvmutil`, are heavily inspired by
this style. We insist on its use, because this style is extremely readable and
forces you to write better code.
main on top
-----------
In every cbmk script, it is our intention that there be a `main()` function.
All logic should be inside a function, and `main()` should be the function that
executes first; at the bottom of each script, insert this line:
main $@
This will execute `main()`, passing any arguments (from the user's shell) to it.
Top-down logic
--------------
*Every* function called from main should always be *below* the calling function.
Therefore, if multiple functions call a given function, that function should be
below the final one that called it. Here is an example (please also pay
attention to how the functions are formatted, e.g. where `{` and `}` go:
```
#!/usr/bin/env sh
. "include/err.sh"
main()
{
foo
bar
do_something_else
}
foo()
{
printf "I'm a function that does stuff.\n"
bar || err "foo: an error occured"
do_something_else
}
bar()
{
printf "I'm another function that does stuff.\n"
some_other_command || printf "WARNING: bar: something something" 1>&2
}
do_something_else()
{
complicated_function bla bla bla || \
err "do_something_else: something happened that wasn't nice"
}
complicated_function()
{
printf "I'm a complicated function, provided as helper"
printf " function for do_something_else()\n"
do_some_complicated_stuff || return 1
}
main $@
```
PWD is always root of cbmk
--------------------------
In any script executed by cbmk, under `script/`, the work directory is relative
to the main `cbmk` script. In other words, all scripts under `script/` also
assume this.
This is actually one of the reasons for that design, as also alluded to in
the main [cbmk maintenance manual](index.md).
main should only be a simple skeleton
-------------------------------------
The `main()` function should not implement much logic itself. Each script in
cbmk is its own program. The `main()` function should contain the overall
structure of the entire logic, with subfunctions providing actual functionality.
Subfunctions can then have their own subfunctions, declared below themselves, in
this top-down style. For example, a function that builds SeaBIOS payloads might
be below a function that builds ROM images with SeaBIOS payloads inside them,
when building coreboot ROM images.
One task, one script
====================
Not literally *one task*, but one theme, one *kind* of overall task. For
example, `script/build/roms` builds final ROM images of coreboot,
containing payloads; that same script does not also build cross compilers or
tell you the current weather forecast. This is an analog of the Unix design
philosophy which says: write one program that does one thing well, and then
another program that does another thing very well; programs communicate with
each other via the universal method, namely text.
Error handling
==============
Where feasible, a script should do:
set -e -u
If `-e` isn't feasible, perhaps try just `-u` - if neither is feasible, then
that is OK. Judge it case by case.
However, neither of these should be relied upon exclusively. When a script runs
*any* kind of command that could return with error status, that error status
must be handled.
The general rule is to call `err()`, which is provided in cbmk by
the file `include/err.sh`. This is inspired by the way `err()` is called in
BSD programs (from `err.h`, a non-standard BSD libc extension).
Where a script must perform certain cleanup before exiting, the script should
implement its own `fail()` function that performs cleanup, and then
calls `err()`. The `err()` function takes a string as argument, which will be
printed to the screen.
If `err` is being called from `main()`, just write the error message. However,
if it's being called from another function, you should write the function name.
For example:
err "function_name: this shit doesn't work. fix it."
Do not directly exit
--------------------
Please try to use `err` for all error exits.
The main `cbmk` script has its own exit function, for handling zero or non-zero
exits. Zero means success, and non-zero means error.
A script should either return zero status, or call `err()`.
An individual function may, in some cases, return 1 or 0 itself, which would
then be handled accordingly by the calling function.
How to handle errors
--------------------
There are some instances where errors should be *ignored*, in which case you
might do:
command || :
The `||` means: if `command` exits with non-zero (error) status, do this, and
then after the `||` is what to do: similarly, `&&` instead would mean: if the
command succeeded, then do this.
Never mix `&&` and `||`
If/else blocks
==============
Keep these simple, and where possible, maybe don't use them at all! For
example:
```
if [ "${var}" = "foo" ]; then
do_something
fi
```
You might instead do:
```
[ "${var}" != "foo" ] || \
do_something
```
or
```
[ "${var}" = "foo" ] && \
do something
```
Warnings
--------
In C, the `stderr` file is 2 as represented by `int fd` style. In shell scripts,
it's the same: 1 for standard output, 2 for errors/warnings. The `err` function
in cbmk writes to 2 (stderr).
If you want to output something that is a warning, or otherwise an error that
should not yield an exit, you should do something like this:
printf "function_name: this is dodgy stuff. fix it maybe?\n" 1>&2
Avoid passing arguments excessively
===================================
In functions, use of arguments passed to them can be useful, but in general,
they should be avoided; use global variables when feasible.
Do not exceed 80 characters per line
====================================
See: RFC 3676
Excessively long code lines are really annoying to read.
Use tab-based indendation
=========================
A new line should begin with tab indentation, in a function.
Multi-line commands
-------------------
Use \\ at the end, as you would, but use *four spaces* to indent on the
follow-up line. For example:
```
function_name()
{
really stupidly long command that may also return error state || \
err "function_name: you screwed up. try again."
}
```
Use printf!
===========
Don't use `echo` unless there's some compelling reason to do so.
The `printf` functionality is more standard, across various sh implementations.
env
===
Don't do:
#!/bin/sh
Do:
#!/usr/bin/env sh
This is more portable, between various Unix systems.
Be portable!
============
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 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).
Work+testing is sorely needed, in this area. It would be nice if Canoeboot
could be built on BSD systems, for example.
Do as little as possible
========================
Don't over-engineer anything. Write as simply as you can, to perform a single
task. This is basically the same as what has been written elsewhere, but it's
re-stated this way to illustrate a point:
Canoeboot's build system is designed to be as efficient as possible. It
intentionally *avoids* implementing many things that are unnecessary for the
user. The purpose of Canoeboot is to provide coreboot ROM images as efficiently
as possible, with desirable configurations that users want. Do that in as few
steps as possible, in the most streamlined way possible, while still providing
a degree of configurability - this is the mentality behind cbmk design.

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

@ -1,9 +1,9 @@
---
title: Apply to become board maintainer/tester for nonGeNUine Boot
title: Apply to become board maintainer/tester for Canoeboot
x-toc-enable: true
...
nonGeNUine Boot strives to make Coreboot accessible for as many users as possible.
Canoeboot strives to make Coreboot accessible for as many users as possible.
To accomplish this goal, we must add as many boards as possible.
As the total number of supported boards increases it becomes more and more difficult
for our main contributors to test every single release for every single supported board.
@ -18,13 +18,12 @@ All you need to do in order to become a board maintainer is:
+ Have the board you wish to maintain
Once you become a board maintainer, your real name and screen name can
be added to the public list on the nonGeNUine Boot contributors page.
be added to the public list on the Canoeboot contributors page.
You can, of course, choose to forego the public listing (we will ask for
permission, before publishing your name).
To apply for such a posting, ping `leah` or `shmalebx9` on
[irc,](../../contact.html#irc-chatroom) or email
the nonGeNUine Boot maintainers.
To apply for such a posting, email
Leah Rowe via [leah@libreboot.org](mailto:leah@libreboot.org)
Do not be afraid to apply to maintain a board with another listed
maintainer or multiple maintainers; more is better.
@ -61,9 +60,9 @@ Testing Procedure
=================
You will receive an email when roms are ready for testing.
The email will link to an open issue on our [current git hosting platform.](/git.html#gbmk-nongenuineboot-make)
The email will link to an open issue on our [current git hosting platform.](/git.html#cbmk-canoeboot-make)
Whether you receive an email from a GNU email
Whether you receive an email from a canoeboot.org email
domain or one of our developer's email you should verify (for
your own security)
that the downloaded roms are signed with the [official key.](/download.html#gpg-signing-key)
@ -79,6 +78,6 @@ note: [insert any notes if relevant]
For example, a board status comment might look like this:
board: x200_8mb
board: t440p_12mb
status: fail
note: GRUB throws error 'something_is_b0rked'

80
site/docs/maintain/testing.uk.md Normal file
View File

@ -0,0 +1,80 @@
---
title: Подати на становлення підтримувачем/випробувачем плати Canoeboot
x-toc-enable: true
...
Canoeboot намагається зробити Coreboot доступним для якомога більшої кількості користувачів.
Задля досягнення цієї мети, ми мусимо додати якомога більше плат.
В той час як загальне число підтримуваних плат підвищується, стає більш і більш складнішим
для наших основних учасників випробувати кожний випуск для кожної підтримуваної плати.
Тому ми потребуємо допомоги спільноти в випробуванні випусків перед тим, як їх розповсюджують
до користувачів.
Вам *не* потрібно бути розробником для того, щоби бути супроводжувачем плати.
Все, що вам потрібно робити для становлення підтримувачем плати це:
+ Бути доступними для зв'язку через email, коли нові бінарні файли для випробування доступні
+ Мати правильне обладнання готовим для зовнішньої прошивки вашої плати
+ Мати плату, яку ви хочете супроводжувати
Як тільки ви стали супроводжувачем плати, ваше реальне ім'я та сценічне ім'я
може бути доданим до публічного списку на сторінці учасників Canoeboot.
Ви можете, звісно, вибрати уникнути публічного вказання (ми спитаємо вас
дозволу, перед публікацією вашого імені).
контакт: Лії Роу через [leah@libreboot.org](mailto:leah@libreboot.org)
Будь ласка, почитайте наступні секції, щоб зрозуміти специфіку
підтримання плати.
ПРИМІТКА: Якщо вже є випробувачі для даної материнської плати, *ви* може досі
надати випробування для такої самої материнської плати, якщо це те, що ви маєте. Чим більше, тим
краще!
Будьте доступними для зв'язку
==============
Вам варто відслідковувати будь-яку електронну пошту, що ви вкажете в вашому поданні.
Немає конкретного часового проміжку для того, скільки має пройти часу після того, як
ви отримаєте електронний лист, до повідомлення про статус вашої плати.
Вам варто зробити найкращі зусилля для відповіді протягом декількох днів.
Якщо ви *єдиний* супроводжувач для вашої плати, тоді, будь ласка,
врахуйте, що ваш внесок є особливо значущим.
Майте обладнання для зовнішньої прошивки
================================
Образи rom, які ви випробуєте, будуть звісно невипробуваними.
Задля уникнення отримання непрацездатної машини, вам потрібно мати обладнання для зовнішньої
прошивки в наявності для відновлення вашої плати з поламаного rom.
В більшості випадків ви можете посилатися на [керівництво SPI.](../install/spi.html)
В менш частих випадках -таких як, деякі ARM chromebook- ваша плата може бути прошита іншим чином.
Посилайтесь на [документацію Coreboot](https://doc.coreboot.org/)
або спитайте в IRC, якщо не впевнені.
Процедура випробування
=================
Ви отримаєте лист електронною поштою, коли образи rom будуть готовими для випробування.
Лист електронною поштою буде посилатися на відкритий issue на нашій [поточній платформі розміщення git.](/git.html#cbmk-canoeboot-make)
Чи ви отримаєте лист електронною поштою через поштовий домен canoeboot.org,
або один з email розробників, вам варто перевірити (для
вашої власної безпеки),
що завантажені rom підписано з [офіційним ключем.](/download.html#gpg-signing-key)
Коли ваше випробування закінчено, прокоментуйте в issue, на яке наведено посилання
в вашому відправленому листі електронною поштою, таким чином:
board: `ваша плата`
status: `pass/fail`
note: [вставьте будь-які приміткі, якщо релевантно]
Наприклад, відгук про статус плати міг би виглядати подібним чином:
board: t440p_12mb
status: fail
note: GRUB throws error 'something_is_b0rked'

2
site/docs/misc/codenames.md
View File

@ -10,7 +10,7 @@ Introduction
This document lists product codenames for some hardware.
Please note that just because a certain device is listed here does NOT mean
that it is supported in nonGeNUine Boot. For supported devices refer to the
that it is supported in Canoeboot. For supported devices refer to the
installation documentation.
### A note on GPUs

26
site/docs/misc/emulation.md
View File

@ -1,21 +1,21 @@
---
title: Building nonGeNUine Boot for Emulation
title: Building Canoeboot for Emulation
x-toc-enable: true
...
Introduction
============
nonGeNUine Boot supports building for qemu as a target board.
Canoeboot supports building for qemu as a target board.
The resulting rom can then be tested using qemu.
The qemu board is mostly intended to speed up development by removing the need to flash to bare metal during initial tests.
Qemu may also be useful for end users who intend to make changes to their nonGeNUine Boot rom without having to flash and reboot their machine.
Qemu may also be useful for end users who intend to make changes to their Canoeboot rom without having to flash and reboot their machine.
Building and Testing
====================
nonGeNUine Boot can be built for qemu just like any other board.
Canoeboot can be built for qemu just like any other board.
`./build boot roms qemu_x86_12mb`
@ -36,11 +36,27 @@ qemu-system-aarch64 -bios bin/qemu_arm64_12mb/uboot_payload_qemu_arm64_12mb_libg
-M virt,secure=on,virtualization=on,acpi=on -cpu cortex-a53 -m 768M -serial stdio -vga none -display none
```
That command (above) does a serial console. Alper Nebi Yasak added this patch to Libreboot:
<https://browse.libreboot.org/lbmk.git/commit/?id=444f2899e69e9b84fd5428625aa04b00c1341804>
This enables a graphical display in qemu, like so (only works for releases on or
after Canoeboot 20231026, or Libreboot after release 20231021). Command:
```
qemu-system-aarch64 \
-machine virt,secure=on,virtualization=on \
-cpu cortex-a72 -m 1G \
-serial stdio -device VGA \
-device qemu-xhci \
-device usb-kbd -device usb-mouse \
-bios bin/qemu_arm64_12mb/*.rom
```
Use Cases
=========
While development is the primary motivation for qemu support, the board makes it easy to test minor changes to release roms.
For example one can use *cbfstool* from coreboot to edit the background image in a nonGeNUine Boot rom as follows:
For example one can use *cbfstool* from coreboot to edit the background image in a Canoeboot rom as follows:
```
cbfstool /path/to/rom remove -n background.png

45
site/docs/misc/index.md
View File

@ -4,29 +4,14 @@ x-toc-enable: true
...
TODO: this page is very old, and could do with an update. It was *old* when
we inherited it from Libreboot, which we forked to create nonGeNUine Boot; it is
we inherited it from Libreboot, which we forked to create Canoeboot; it is
even older now. It's almost a tradition now, that this page is never updated.
High Pitched Whining Noise on Idle in Debian or Devuan
======================================================================
Start powertop automatically at boot time.
Included with nonGeNUine Boot is a script called 'powertop.debian'. Run this
as root and it will setup powertop to run with --auto-tune at boot
time. Load the file in your text editor to see how it does that.
sudo ./resources/scripts/misc/powertop.debian
Might want to run with --calibrate first
If powertop doesn't work, another way (reduces battery life slightly)
is to add *processor.max\_cstate=2* to the *linux* line in grub.cfg,
using [this guide](../gnulinux/grub_cbfs.md).
High Pitched Whining Noise on Idle in Arch-based distros
==============================================================
**NOTE: VERY OLD advice (years old), it may not be relevant for modern Arch.**
The following removes most of the noise. It reduces what is a high
frequency whine (that not everyone can hear) to a slight buzz (which
most people can't hear or doesn't bother most people).
@ -36,7 +21,7 @@ is a step towards that. Also, in some instances you will need to run
'sudo powertop --auto-tune' again. This needs to be implemented
properly in coreboot itself!
On the X60 with coreboot or nonGeNUine Boot, there is a high pitched sound
On the X60 with coreboot or Canoeboot, there is a high pitched sound
when idle. So far we have use processor.max\_cstate=2 or idle=halt in
GRUB. These consume power. Stop using them!
@ -88,7 +73,7 @@ X60 Tablet it is called X6 Tablet UltraBase). For the ThinkPad T60, you
can use the "Advanced Mini Dock".
If you are using one of the ROM images with 'serial' in the name, then
you have serial port enabled in nonGeNUine Boot and you have memtest86+
you have serial port enabled in Canoeboot and you have memtest86+
included inside the ROM. Connect your null modem cable to the serial
port on the dock and connect the other end to a 2nd system using your
USB Serial adapter.
@ -103,7 +88,7 @@ Y.
There are also others like Minicom but Screen works nicely.
By doing this before booting the X60/T60, you will see console output
from nonGeNUine Boot. You will also see GRUB displaying on the serial output,
from Canoeboot. You will also see GRUB displaying on the serial output,
and you will be able to see MemTest86+ on the serial output aswell. You
can also configure your distro so that a terminal (TTY) is accessible
from the serial console.
@ -119,7 +104,7 @@ change the `linux` line to add instructions for enabling getty. See
Finetune backlight control on intel gpu's
=========================================
Sometimes the backlight control value (BLC\_PWM\_CTL) set by nonGeNUine Boot
Sometimes the backlight control value (BLC\_PWM\_CTL) set by Canoeboot
is not ideal. The result is either flicker, which could cause nausea or
epilepsy or an uneven backlight and/or coil whine coming from the
display. To fix this a different value for the gpu reg BLC\_PWM\_CTL
@ -213,31 +198,31 @@ Power Management Beeps on Thinkpads
When disconnecting or connecting the charger, a beep occurs. When the
battery goes to a critically low charge level, a beep occurs. Nvramtool
is included in nonGeNUine Boot, and can be used to enable or disable this
is included in Canoeboot, and can be used to enable or disable this
behaviour.
You need to write changes in a nonGeNUine Boot ROM image, and flash it, in order
You need to write changes in a Canoeboot ROM image, and flash it, in order
to apply them. You can either use a pre-compiled rom image, or create an image
from the current one in your computer. See here
[../gnulinux/grub_cbfs.html#get-the-rom-image](../gnulinux/grub_cbfs.html#get-the-rom-image)
for more information on how to do that.
Once you have a nonGeNUine Boot rom image, say 'nongenuineboot.rom', you can write
Once you have a Canoeboot rom image, say 'canoeboot.rom', you can write
changes on the image with the following commands.
Disable or enable beeps when removing/adding the charger:
sudo ./nvramtool -C nongenuineboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C nongenuineboot.rom -w power_management_beeps=Disable
sudo ./nvramtool -C canoeboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C canoeboot.rom -w power_management_beeps=Disable
Disable or enable beeps when battery is low:
sudo ./nvramtool -C nongenuineboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C nongenuineboot.rom -w low_battery_beep=Disable
sudo ./nvramtool -C canoeboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C canoeboot.rom -w low_battery_beep=Disable
You can check that the parameters are set in the image with :
sudo ./nvramtool -C nongenuineboot.rom -a
sudo ./nvramtool -C canoeboot.rom -a
Finally, you need to flash the rom with this new image. See here
[../gnulinux/grub_cbfs.html#with-re-flashing-the-rom](../gnulinux/grub_cbfs.html#with-re-flashing-the-rom)

19
site/docs/uboot/index.md
View File

@ -3,15 +3,20 @@ title: U-Boot payload
x-toc-enable: true
...
U-Boot integration in nonGeNUine Boot is currently at a proof-of-concept
+Libreboot has experimental support for using U-Boot as a coreboot
+payload since the [20221214](../../news/libreboot20221214.md) release.
+Refer to [docs/hardware/](../hardware/) for a complete list of U-Boot
+targets in Libreboot. Canoeboot inherits U-Boot support from Libreboot.
+
+U-Boot integration in Canoeboot is currently at a proof-of-concept
stage, with most boards completely untested and most likely not working.
ROM images for them are mostly intended for further testing and
development. If you have one of these machines and want to help fix
things, you can ping `alpernebbi` on Libera IRC, who ported these boards
to nonGeNUine Boot.
to Canoeboot.
Make sure you have the latest `gbmk` from the Git repository,
and the build dependencies are installed like so, from `gbmk/` as root:
Make sure you have the latest `cbmk` from the Git repository,
and the build dependencies are installed like so, from `cbmk/` as root:
./build dependencies debian
@ -51,7 +56,7 @@ inside the shell, which can be saved to and automatically loaded from
persistent storage configured at build-time.
WARNING: Environment variable storage has not been explicitly configured
so far and is untested in the context of nonGeNUine Boot. It may cause data
so far and is untested in the context of Canoeboot. It may cause data
loss or even brick your device by overwriting your disk's partition
table, unexpected parts of the SPI ROM image, or do something else
entirely.
@ -59,10 +64,10 @@ entirely.
Known issues
============
U-Boot integration in nonGeNUine Boot is incomplete. Here is a list of known
U-Boot integration in Canoeboot is incomplete. Here is a list of known
issues that affect all boards:
- Branding is U-Boot with their logo (nonGeNUine Boot only in version number)
- Branding is U-Boot with their logo (Canoeboot only in version number)
- Splash screen might be better instead of console messages
- Cursor/drawing bugs with video improvements patches
- Environment storage is likely dangerously broken

29
site/docs/uboot/uboot-archlinux.md
View File

@ -1,22 +1,21 @@
---
title: Installing ArchGNU+LinuxARM on a Chromebook with U-Boot installed
title: Installing ArchLinuxARM on a Chromebook with U-Boot installed
x-toc-enable: true
...
**TODO FOR nonGeNUine Boot PROJECT: Test with Parabola, which is the FSF-endorsed
version of Arch. See: <https://www.parabola.nu/>**
Background
==========
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.
ArchLinuxARM Latest (as of May 1st 2023) boots and can be installed successfully using libreboot 20230319 on a gru\_bob chromebook; ergo, Canoeboot 20231026 likely works too.
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)
The following process should theoretically be applicable to other U-Boot devices and GNU/Linux distributions, but the focus here is specifically on ArchLinuxARM.
And the the instructions from the ArchGNU+LinuxARM wiki [here](https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa)
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)
And the the instructions from the ArchLinuxARM 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 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 nonGeNUine Boot users, with the scope being comprehensive.
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.
Boot Method
===========
@ -67,7 +66,7 @@ Formatting and Partitioning Your External Media
===============================================
Now it's time partition the boot disk. During testing, a microSD card was used in the microSD card slot of the gru-bob chromebook.
The nonGeNUine Boot configuration will boot the microSD card above the onboard eMMC if both are present and bootable. This is useful because it means no knowledge or use of the u-boot console is required.
The Canoeboot configuration will boot the microSD card above the onboard eMMC if both are present and bootable. This is useful because it means no knowledge or use of the u-boot console is required.
Since the eMMC is 16GB of storage space, it's advisable to choose an external storage disk of less than 16GB if you intend to install onto the onboard storage, or to create a root partition of less than 15.8GB.
@ -112,27 +111,27 @@ Boot-Disk Creation
Now that we've got an extlinux.conf file, copy it to your /tmp directory, and we'll begin.
```
cd /tmp
curl -LO http://os.archlinuxarm.org/os/ArchGNU+LinuxARM-aarch64-latest.tar.gz
curl -LO http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz
mkdir root
mkdir boot
mount /dev/sdX2 root
mount /dev/sdX1 boot
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
tar -C boot --strip-components=2 -xvf ArchLinuxARM-aarch64-latest.tar.gz ./boot/
tar -C root --exclude=./boot -xvf ArchLinuxARM-aarch64-latest.tar.gz
mkdir boot/extlinux
cp extlinux.conf boot/extlinux/extlinux.conf
sync
umount boot
umount root
```
Note the use of ArchGNU+LinuxARM-aarch64-latest.tar.gz and not ArchGNU+LinuxARM-gru-latest.tar.gz
Note the use of ArchLinuxARM-aarch64-latest.tar.gz and not ArchLinuxARM-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 ArchGNU+LinuxARM-latest release, showed that booting the fallback initramfs image will work, but the main image won't.
Extensive testing with ArchLinuxARM-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
@ -173,7 +172,7 @@ lsblk -o NAME,UUID,FSTYPE,SIZE
Final Steps
===========
At this stage, you now have a fully functional ArchGNU+LinuxARM system on an external disk, and are ready to configure your system.
At this stage, you now have a fully functional ArchLinuxARM 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:
```
dd if=/dev/mmcblk0 of=/dev/mmcblk1 bs=4M status=progress

40
site/docs/uboot/uboot-debian-bookworm.md
View File

@ -8,16 +8,10 @@ System Configuration
Hardware: Samsung Chromebook Plus XE513C24 (gru\_kevin)
Tested on Libreboot 20230423 (nonGeNUine Boot is a fork of Libreboot)
Tested on Libreboot 20230423 (Canoeboot is a fork of Libreboot)
Operating System: Debian Bookworm RC2
Note! As of this RC2 version of Debian Bookworm, the system automatically
makes use of non-free firmware during install. If your intention is to avoid
all non-free firmware you should avoid using Debian Bookworm or search for a
downstream version of Debian Bookworm that strips out all non-free firmware.
More info in the link below.
[https://wiki.debian.org/Firmware](https://wiki.debian.org/Firmware)
Install Media Preparation
@ -40,10 +34,6 @@ with the appropriate device path on your system.
# dd if=debian-bookworm-DI-rc2-arm64-DVD-1.img of=/dev/sdcard_device bs=1M status=progress; sync
```
During the install the system automatically makes use of non-free firmware to
activate the wireless network card. For this reason you could choose the
netinst iso and download files as needed rather than using the DVD iso.
Installation
============
@ -54,7 +44,7 @@ The system automatically found an EFI image (efi/boot/bootaa64.efi), but after
loading it the "Synchronous Abort" handler activated and the chromeboot would
reboot.
Since nongenuineboot/uboot has a 2 second pause at the beginning to stop autoboot if
Since canoeboot/uboot has a 2 second pause at the beginning to stop autoboot if
desired I paused autoboot and it dropped me to the uboot command line. Look for
the grub EFI image on the micro sdcard and started that up instead. Below are
the series of uboot commands I used to understand the media and partition
@ -102,24 +92,16 @@ everything was in text mode and easy to read. The "Graphical install" worked
also, however the screen resolution was so high that all the text and buttons
were quite small on the display and harder to read.
![](https://avgnu.vimuser.org/xe513c24/debbook-grub.jpg)
![](https://av.canoeboot.org/xe513c24/debbook-grub.jpg)
At this point the installation proceeded normally.
![](https://avgnu.vimuser.org/xe513c24/debbook-lang.jpg)
![](https://avgnu.vimuser.org/xe513c24/debbook-packages.jpg)
Note that you will see a message during install asking whether you want to
search for non-free firmware. My experience was that the system would use
non-free firmware regardless what I selected in that dialogue. The system was
able to connect wirelessly to the internet and download packages and updates as
needed.
![](https://avgnu.vimuser.org/xe513c24/debbook-nonfree.jpg)
![](https://av.canoeboot.org/xe513c24/debbook-lang.jpg)
![](https://av.canoeboot.org/xe513c24/debbook-packages.jpg)
Some users have mentioned experiencing corruption of the first partition after
installing Debian Bookworm on a nonGeNUine Boot / uboot xe513c24 system. This is
possibly due to the experimental nature of the nongenuineboot / uboot system at this
installing Debian Bookworm on a Canoeboot / uboot xe513c24 system. This is
possibly due to the experimental nature of the canoeboot / uboot system at this
time.
One potential workaround is to leave some unused space at the beginning of the
@ -127,7 +109,7 @@ drive before the first partition. This can be done by manually partitioning
during install and configuring the first partition to start 100MB or so from
the start of the drive.
Also, per instructions from alpernebbi on IRC, when you arrive at the stage
Also, per instructions from alpernebbi on Libreboot IRC, when you arrive at the stage
where the grub bootloader is installed take special note to select yes to the
option to "Force installation to removable media path", and also say no to the
option to "Update NVRAM variables". If one selects yes on updating NVRAM
@ -163,15 +145,15 @@ grub though, so you may need to repeat this as a workaround for now.
Below are a couple screen shots of the installed system running from the
internal emmc.
![](https://avgnu.vimuser.org/xe513c24/debbook-desktop.jpg)
![](https://avgnu.vimuser.org/xe513c24/debbook-firefox.jpg)
![](https://av.canoeboot.org/xe513c24/debbook-desktop.jpg)
![](https://av.canoeboot.org/xe513c24/debbook-firefox.jpg)
System Functionality
====================
Things that work:
* Wireless internet and bluetooth (due to non-free firmware)
* Wireless internet and bluetooth
* Touch screen and stylus
* Touchpad
* Audio (Speakers and headphone jack)

4
site/docs/uboot/uboot-openbsd.md
View File

@ -8,7 +8,7 @@ System Configuration
Hardware: Samsung Chromebook Plus XE513C24 (gru\_kevin)
Tested on Libreboot 20230423 (nonGeNUine Boot is a fork of Libreboot)
Tested on Libreboot 20230423 (Canoeboot is a fork of Libreboot)
Operating System: OpenBSD 7.3
@ -41,4 +41,4 @@ indicating an error opening random.seed but continued to load the OpenBSD
kernel. Unfortunately the system then froze indefinitely. See screen shot
below.
![](https://avgnu.vimuser.org/xe513c24/openbsd-attempt.jpg)
![](https://av.canoeboot.org/xe513c24/openbsd-attempt.jpg)

175
site/download.md
View File

@ -3,99 +3,149 @@ title: Downloads
x-toc-enable: true
...
Introduction
============
New releases are announced in the [main news section](news/).
If you're more interested in nonGeNUine Boot development, go to the
[nonGeNUine Boot development page](../git.md), which also includes links to the
If you're more interested in canoeboot development, go to the
[canoeboot development page](../git.md), which also includes links to the
Git repositories. The page on [/docs/maintain/](docs/maintain/) describes how
nonGeNUine Boot is put together, and how to maintain it. If you wish to build
nonGeNUine Boot from source, [read this page](docs/build/).
non**G**e**NU**ine Boot 20230717 release
---------------------------------------------
The latest non-**G**e**NU**ine firmware can be found here, originally released
on 17 July 2023 as *unofficial* GNU Boot 20230717, but re-branded on [21
July 2021](news/nongenuineboot20230717.html#update-21-july-2023) to *nonGeNUine
Boot*:
**<https://av.vimuser.org/notgnuboot/20230717/>**
**Please read the [nonGeNUine Boot 20230717 release
announcement](news/nongenuineboot20230717.md)**
*This non-**G**e**NU**ine release is proposed to the GNU project, for use in
the GNU Boot releases, but it is not officially sanctioned. It was created
by Leah Rowe, leader of the [Libreboot project](https://libreboot.org), based
directly upon the [Libreboot 20230625
release](https://libreboot.org/news/libreboot20230625.html) of 25 June 2023;
the intent is to help GNU Boot reach parity with current Libreboot releases,
so that the two projects can begin to operate in sync (while GNU Boot continues
to exclude parts of Libreboot that it finds unacceptable); as of
July 16th, 2023, GNU Boot was struggling to get up to speed with Libreboot, so
it was decided that the Libreboot project itself would help GNU Boot in
whatever way it can.*
On that day, GNU Boot's code repository was still based on Libreboot from
late 2022, and its website repository was mostly based upon Libreboot from
late 2021. *This* mock nonGeNUine Boot website and release, though unofficial, *is*
validly adherent to GNU Boot policy, and *is* real. You can *use it*, today.
*nonGeNUine* Boot policy adheres to the [GNU Free System Distribution
Guidelines (GNU FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html),
whereas Libreboot adheres to the [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html), and that is the reason GNU
wanted to fork Libreboot. We in Libreboot do not agree with the GNU Boot
project, especially since Libreboot already still provides blob-free
configurations when possible, on any given mainboard, but no-blob configuration
is still the preferred configuration when possible, in Libreboot. Indeed, this
nonGeNUine Boot release adds several new mainboards that the real GNU Boot can make
use of (Dell Latitude E6400 and 2 RK3399 chromebooks).
Canoeboot is put together, and how to maintain it. If you wish to build
Canoeboot from source, [read this page](docs/build/).
GPG signing key
---------------
**The latest *official* release is TBD.**
**The latest release is Canoeboot 20231026, under the `canoeboot` directory.**
**NOTE: The signing key below is used by Libreboot, and was used to
sign the unofficial nonGeNUine Boot 20230717 release, linked above.**
### NEW KEY
Full key fingerprint: `98CC DDF8 E560 47F4 75C0 44BD D0C6 2464 FA8B 4856`
This is the same key used to sign Libreboot releases, which is also used to
sign Canoeboot releases since it's the same person maintaining both projects.
Download the key here: [lbkey.asc](lbkey.asc)
nonGeNUine Boot releases are signed using GnuPG.
Canoeboot releases are signed using GPG.
sha512sum -c sha512sum.txt
gpg --verify sha512sum.txt.sig
Git repository
--------------
==============
Links to regular release archives are listed on this page.
However, for the absolute most bleeding edge up-to-date version of nonGeNUine Boot,
However, for the absolute most bleeding edge up-to-date version of Canoeboot,
there is a Git repository that you can download from. Go here:
[How to download nonGeNUine Boot from Git](git.md)
[How to download Canoeboot from Git](git.md)
Download Canoeboot from mirrors
===============================
Canoeboot releases are hosted on the same Rsync server as Libreboot, and
mirrors pick this up; look in the `canoeboot` directory on Libreboot mirrors.
For your convenience, these are linked below (on the mirror lists).
HTTPS mirrors {#https}
-------------
**The latest *official* release is TBD.**
**The latest release is Canoeboot 20231026, under the `canoeboot` directory.**
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
These mirrors are recommended, since they use TLS (https://) encryption.
You can download Canoeboot from these mirrors:
* <https://www.mirrorservice.org/sites/libreboot.org/release/canoeboot/> (University
of Kent, UK)
* <https://mirrors.mit.edu/libreboot/canoeboot/> (MIT university, USA)
* <https://mirror.math.princeton.edu/pub/libreboot/canoeboot/> (Princeton
university, USA)
* <https://mirror.shapovalov.tech/libreboot/canoeboot/> (shapovalov.tech, Ukraine)
* <https://mirror.koddos.net/libreboot/canoeboot/> (koddos.net, Netherlands)
* <https://mirror-hk.koddos.net/libreboot/canoeboot/> (koddos.net, Hong Kong)
* <https://mirror.cyberbits.eu/libreboot/canoeboot/> (cyberbits.eu, France)
RSYNC mirrors {#rsync}
-------------
The following rsync mirrors are available publicly:
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <rsync://rsync.mirrorservice.org/libreboot.org/release/canoeboot/> (University of Kent,
UK)
* <rsync://mirror.math.princeton.edu/pub/libreboot/canoeboot/> (Princeton university, USA)
* <rsync://rsync.shapovalov.tech/libreboot/canoeboot/> (shapovalov.tech, Ukraine)
* <rsync://ftp.linux.ro/libreboot/canoeboot/> (linux.ro, Romania)
* <rsync://mirror.koddos.net/libreboot/canoeboot/> (koddos.net, Netherlands)
* <rsync://mirror-hk.koddos.net/libreboot/canoeboot/> (koddos.net, Hong Kong)
Are you running a mirror? Contact the canoeboot project, and the link will be
added to this page!
You can make your rsync mirror available via your web server, and also configure
your *own* mirror to be accessible via rsync. There are many resources online
that show you how to set up an rsync server.
How to create your own rsync mirror:
Useful for mirroring Canoeboot's entire set of release archives. You can put
an rsync command into crontab and pull the files into a directory on your
web server.
If you are going to mirror the entire set, it is recommended that you allocate
at least 25GiB. Canoeboot's rsync is currently about 12GiB, so allocating 25GiB
will afford you plenty of space for the future. At minimum, you should ensure
that at least 15-20GiB of space is available, for your Canoeboot mirror.
*It is highly recommended that you use the canoeboot.org mirror*, if you wish
to host an official mirror. Otherwise, if you simply want to create your own
local mirror, you should use one of the other mirrors, which sync from
canoeboot.org.
**NOTE: the rsync commands below will only download canoeboot. Remove
the `canoeboot/` part at the end of each path, if you also want to download
all of Libreboot; Libreboot and Canoeboot share the same Rsync server.**
Before you create the mirror, make a directory on your web server. For
example:
mkdir /var/www/html/libreboot/canoeboot/
Now you can run rsync, for instance:
rsync -avz --delete-after rsync://rsync.canoeboot.org/mirrormirror/ /var/www/html/libreboot/canoeboot/
You might put this in an hourly crontab. For example:
crontab -e
Then in crontab, add this line and save/exit (hourly crontab):
0 * * * * rsync -avz --delete-after rsync://rsync.canoeboot.org/mirrormirror/ /var/www/html/libreboot/canoeboot/
**It's extremely important to have the final forward slash (/) at the end of each path,
in the above rsync command. Otherwise, rsync will behave very strangely.**
**NOTE: `rsync.canoeboot.org` is not directly accessible by the public, except
those whose IPs are whitelisted. For bandwidth reasons, the firewall running
on canoeboot.org blocks incoming rsync requests, except by specific IPs.**
**If you wish to run an rsync mirror, sync from one of the third party mirrors
above and set up your mirror. You can then contact Leah Rowe, to have your IP
addresses whitelisted for rsync usage - if the IP addresses match DNS A/AAAA
records for your rsync host, this can be used. A script runs in an hourly
crontab on canoeboot.org, that fetches the A/AAAA records of whitelisted
rsync mirrors, automatically adding rules permitting them to get through the
firewall.**
If you wish to regularly keep your rsync mirror updated, you can add it to a
crontab. This page tells you how to use crontab:
<https://man7.org/linux/man-pages/man5/crontab.5.html>
HTTP mirrors {#http}
------------
**The latest *official* release is TBD.**
**The latest release is Canoeboot 20231026, under the `canoeboot` directory.**
WARNING: these mirrors are non-HTTPS which means that they are
unencrypted. Your traffic could be subject to interference by
@ -103,13 +153,16 @@ adversaries. Make especially sure to check the GPG signatures, assuming
that you have the right key. Of course, you should do this anyway, even
if using HTTPS.
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <http://mirror.linux.ro/libreboot/canoeboot/> (linux.ro, Romania)
* <http://mirror.helium.in-berlin.de/libreboot/canoeboot/> (in-berlin.de, Germany)
FTP mirrors {#ftp}
-----------
**The latest *official* release is TBD.**
**The latest release is Canoeboot 20231026, under the `canoeboot` directory.**
WARNING: FTP is also unencrypted, like HTTP. The same risks are present.
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <ftp://ftp.mirrorservice.org/sites/libreboot.org/release/canoeboot/> (University
of Kent, UK)
* <ftp://ftp.linux.ro/libreboot/canoeboot/> (linux.ro, Romania)

170
site/download.uk.md
View File

@ -5,92 +5,147 @@ x-toc-enable: true
Нові випуски оголошуються в [основній секції новин](news/).
Якщо ви більше зацікавлені в розробці nonGeNUine Boot, пройдіть на
[сторінку розробки nonGeNUine Boot](../git.md), яка також включає посилання на
Якщо ви більше зацікавлені в розробці canoeboot, пройдіть на
[сторінку розробки canoeboot](../git.md), яка також включає посилання на
репозиторії Git. Сторінка на [/docs/maintain/](docs/maintain/) описує те, як
nonGeNUine Boot складається разом, і як підтримувати його. Якщо ви бажаєте зібрати
nonGeNUine Boot із джерельного кода, [прочитайте цю сторінку](docs/build/).
Non-**G**e**NU**ine Boot 20230717 release
---------------------------------------------
The latest non-**G**e**NU**ine firmware can be found here, originally released
on 17 July 2023:
**<https://av.vimuser.org/notgnuboot/20230717/>**
**Please read the [nonGeNUine Boot 20230717 release
announcement](news/nongenuineboot20230717.md)**
*This non-**G**e**NU**ine release is proposed to the GNU project, for use in
the GNU Boot releases, but it is not officially sanctioned. It was created
by Leah Rowe, leader of the [Libreboot project](https://libreboot.org), based
directly upon the [Libreboot 20230625
release](https://libreboot.org/news/libreboot20230625.html) of 25 June 2023;
the intent is to help GNU Boot reach parity with current Libreboot releases,
so that the two projects can begin to operate in sync (while GNU Boot continues
to exclude parts of Libreboot that it finds unacceptable); as of
July 16th, 2023, GNU Boot was struggling to get up to speed with Libreboot, so
it was decided that the Libreboot project itself would help GNU Boot in
whatever way it can.*
On that day, GNU Boot's code repository was still based on Libreboot from
late 2022, and its website repository was mostly based upon Libreboot from
late 2021. *This* mock nonGeNUine Boot website and release, though unofficial, *is*
validly adherent to GNU Boot policy, and *is* real. You can *use it*, today.
*nonGeNUine* Boot policy adheres to the [GNU Free System Distribution
Guidelines (GNU FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html),
whereas Libreboot adheres to the [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html), and that is the reason GNU
wanted to fork Libreboot. We in Libreboot do not agree with the GNU Boot
project, especially since Libreboot already still provides blob-free
configurations when possible, on any given mainboard, but no-blob configuration
is still the preferred configuration when possible, in Libreboot. Indeed, this
nonGeNUine Boot release adds several new mainboards that the real GNU Boot can make
use of (Dell Latitude E6400 and 2 RK3399 chromebooks).
Canoeboot складається разом, і як підтримувати його. Якщо ви бажаєте зібрати
Canoeboot із джерельного кода, [прочитайте цю сторінку](docs/build/).
Код підпису GPG
---------------
**The latest *official* release is TBD.**
**Останнім випуском є Canoeboot 20231026, в директорії `canoeboot`.**
**NOTE: The signing key below is used by Libreboot, and was used to
sign the unofficial nonGeNUine Boot 20230717 release, linked above.**
### НОВИЙ КЛЮЧ
Повний відбиток ключа: `98CC DDF8 E560 47F4 75C0 44BD D0C6 2464 FA8B 4856`
This is the same key used to sign Libreboot releases, which is also used to
sign Canoeboot releases since it's the same person maintaining both projects.
Завантажте ключ тут: [lbkey.asc](lbkey.asc)
Випуски nonGeNUine Boot підписані з використанням GnuPG.
Випуски Canoeboot підписані з використанням GPG.
sha512sum -c sha512sum.txt
gpg --verify sha512sum.txt.sig
Репозиторій Git
--------------
===============
Посилання на архіви регулярних випусків зазначені на цій сторінці.
Однак, для абсолютно найновішої версії nonGeNUine Boot,
Однак, для абсолютно найновішої версії Canoeboot,
існує репозиторії Git, з якого можна завантажити. Ідіть сюди:
[Як завантажити nonGeNUine Boot через Git](git.md)
[Як завантажити Canoeboot через Git](git.md)
Download Canoeboot from mirrors
===============================
Canoeboot releases are hosted on the same Rsync server as Libreboot, and
mirrors pick this up; look in the `canoeboot` directory on Libreboot mirrors.
For your convenience, these are linked below (on the mirror lists).
Дзеркала HTTPS {#https}
-------------
**The latest *official* release is TBD.**
**Останнім випуском є Canoeboot 20231026, в директорії `canoeboot`.**
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
Дані дзеркала є рекомендованими, оскільки використовують TLS (https://) шифрування.
Ви можете завантажити Canoeboot через дані дзеркала:
* <https://www.mirrorservice.org/sites/libreboot.org/release/canoeboot/> (Кентський
університет, Великобританія)
* <https://mirrors.mit.edu/libreboot/canoeboot/> (Університет МТІ, США)
* <https://mirror.math.princeton.edu/pub/libreboot/canoeboot/> (Прінстонський
університет, США)
* <https://mirror.shapovalov.tech/libreboot/canoeboot/> (shapovalov.tech, Україна)
* <https://mirror.koddos.net/libreboot/canoeboot/> (koddos.net, Нідерланди)
* <https://mirror-hk.koddos.net/libreboot/canoeboot/> (koddos.net, Гонконг)
* <https://mirror.cyberbits.eu/libreboot/canoeboot/> (cyberbits.eu, Франція)
Дзеркала RSYNC {#rsync}
-------------
Наступні дзеркала rsync доступні публічно:
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <rsync://rsync.mirrorservice.org/libreboot.org/release/canoeboot/> (Кентський університет,
Великобританія)
* <rsync://mirror.math.princeton.edu/pub/libreboot/canoeboot/> (Прінстонський університет, США)
* <rsync://rsync.shapovalov.tech/libreboot/canoeboot/> (shapovalov.tech, Україна)
* <rsync://ftp.linux.ro/libreboot/canoeboot/> (linux.ro, Румунія)
* <rsync://mirror.koddos.net/libreboot/canoeboot/> (koddos.net, Нідерланди)
* <rsync://mirror-hk.koddos.net/libreboot/canoeboot/> (koddos.net, Гонконг)
Ви підтримуєте роботу дзеркала? Зв'яжіться з проектом canoeboot, і посилання буде
додано до цієї сторінки!
Ви можете зробити своє дзеркало rsync доступним через свій веб-сервер, а також налаштувати
ваше *власне* дзеркало бути доступним через rsync. Є багато онлайн-ресурсів,
які показують вам те, як налаштувати сервер rsync.
Як створити ваше власне дзеркало rsync:
Корисно для відзеркалювання повного набору архівів випусків Canoeboot. Ви можете розмістити
команду rsync в crontab та витягувать файли в директорію на
вашому веб-сервері.
Якщо ви збираєтесь відзеркалювати повний набір, рекомендовано, щоб вами було виділено
хоча би 25 ГБ. Rsync Canoeboot наразі приблизно 12 ГБ, таким чином виділення 25 ГБ
забезпечить вам багато місця на майбутнє. Мінімально, ви маєте переконатись, що
хоча би 15-20 ГБ простору доступно, для вашого дзеркала Canoeboot.
*Настійно рекомендується, щоб ви використовували дзеркало canoeboot.org*, якщо бажаєте
розміщувати офіційне дзеркало. В іншому випадку, якщо ви просто бажаєте створити своє власне
локальне дзеркало, вам варто використовувати одне з інших дзеркал, яке синхронізується з
canoeboot.org.
**NOTE: the rsync commands below will only download canoeboot. Remove
the `canoeboot/` part at the end of each path, if you also want to download
all of Libreboot; Libreboot and Canoeboot share the same Rsync server.**
Перед створенням дзеркала, зробіть директорію на вашому веб-сервері. Для
прикладу:
mkdir /var/www/html/libreboot/canoeboot/
Тепер ви можете виконувати rsync, для прикладу:
rsync -avz --delete-after rsync://rsync.canoeboot.org/mirrormirror/ /var/www/html/libreboot/canoeboot/
Ви могли би розмістить це в щогодинний crontab. Для прикладу:
crontab -e
Потім в crontab, додайте цей рядок і збережіться/вийдіть (щогодинний crontab):
0 * * * * rsync -avz --delete-after rsync://rsync.canoeboot.org/mirrormirror/ /var/www/html/libreboot/canoeboot/
**Це надзвичайно важливо, щоб мати в кінці косу лінію (/) в кінці кожного шляху,
в вищезазначеній команді rsync. В інакшому випадку, rsync буде поводитись дуже дивно.**
**ПОМІТКА: `rsync.canoeboot.org` не є напряму доступним для громадськості, окрім
тих, чиї IP у білому списку. Через пропускну здатність, Брандмауер, який працює
на canoeboot.org, блокує вхідні запити rsync, окрім окремих IP.**
**Якщо ви бажаєте запустити дзеркало rsync, синхронізуйте з одного з дзеркал третіх сторін
вище і встановіть своє дзеркало. Ви можете потім зв'язатись з Лією Роу, щоб мати ваші адреси
IP внесеним в білий список для використання rsync - якщо адреси IP відповідають DNS A/AAAA
записам для вашого хоста rsync, це може бути використано. Сценарій виконується в щогодинному
crontab на canoeboot.org, який отримує A/AAAA записи внесених в білий список дзеркал
rsync, автоматично додаючи правила, які дозволяють їм проходити через
брандмауер.**
Якщо ви бажаєте регулярно тримати свої дзеркала rsync оновленими, ви можете додати це до
crontab. Ця сторінка розповідає вам, як використовувати crontab:
<https://man7.org/linux/man-pages/man5/crontab.5.html>
Дзеркала HTTP {#http}
------------
**The latest *official* release is TBD.**
**Останнім випуском є Canoeboot 20231026, під директорією `canoeboot`.**
УВАГА: ці дзеркала є не-HTTPS, що означає, що вони
незашифровані. Ваш трафік може бути об'єктом втручання
@ -98,13 +153,16 @@ sign the unofficial nonGeNUine Boot 20230717 release, linked above.**
ви маєте правильний ключ. Звісно, вам варто зробити це в будь-якому випадку, навіть
при використанні HTTPS.
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <http://mirror.linux.ro/libreboot/canoeboot/> (linux.ro, Румунія)
* <http://mirror.helium.in-berlin.de/libreboot/canoeboot/> (in-berlin.de, Німеччина)
Дзеркала FTP {#ftp}
-----------
**The latest *official* release is TBD.**
**Останнім випуском є Canoeboot 20231026, під директорією `canoeboot`.**
УВАГА: FTP є також незашифрованим, подібно HTTP. Ті ж самі ризики присутні.
**NO MIRRORS YET. GNU will no doubt use its FTP infrastructure for this.**
* <ftp://ftp.mirrorservice.org/sites/libreboot.org/release/canoeboot/> (Кентський
університет, Великобританія)
* <ftp://ftp.linux.ro/libreboot/canoeboot/> (linux.ro, Румунія)

170
site/faq.md
View File

@ -8,15 +8,15 @@ AKA Frequently Questioned Answers
Important issues
================
How to compile nonGeNUine Boot from source
How to compile Canoeboot from source
------------------------------------
Refer to the [gbmk build instructions](docs/build/).
Refer to the [cbmk build instructions](docs/build/).
How does the build system work?
-------------------------------
Refer to the [gbmk maintenance manual](docs/maintain/).
Refer to the [cbmk maintenance manual](docs/maintain/).
Do not use CH341A!
------------------
@ -30,7 +30,7 @@ learn more.
How Can I Help
--------------
If you have a board supported in nonGeNUine Boot then please consider becoming a
If you have a board supported in Canoeboot then please consider becoming a
tester.
Testing involves minimal effort and really helps out the project.
See the [board maintainers documentation](/docs/maintain/testing.md)
@ -57,7 +57,7 @@ Error accessing DMI Table, 0x1000 bytes at 0x000000007fb27000
/dev/mem mmap failed: Operation not permitted
```
The backlight is darker on the left side of the screen when lowering the brightness on my ThinkPad X200/X200S/X200T, T400, T500, R400, W500, R500 and other Intel laptops
Backlight darker on the left side of the screen
---------------------------------------------------------------------------------------------------------------
We don't know how to detect the correct PWM value to use in
@ -67,11 +67,11 @@ this issue on some CCFL panels, but not LED panels.
You can work around this in your distribution, by following the notes at
[docs: backlight control](../docs/misc/#finetune-backlight-control-on-intel-gpus).
The ethernet doesn't work on my X200/T400/X60/T60 when I plug in it
-------------------------------------------------------------------
Dead ethernet port on X200/T400/X60/T60
---------------------------------------
This was observed on some systems using network-manager. This happens
both on the original BIOS and in nonGeNUine Boot. It's a quirk in the
both on the original BIOS and in Canoeboot. It's a quirk in the
hardware. On debian systems, a workaround is to restart the networking
service when you connect the ethernet cable:
@ -84,8 +84,8 @@ On systemd-based distros, you might try:
(the service name might be different for you, depending on your
configuration)
My KCMA-D8 or KGPE-D16 doesn't boot with the PIKE2008 module installed
-----------------------------------------------------------------------
KCMA-D8/KGPE-D16: doesn't boot with PIKE2008
---------------------------------------
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
@ -162,11 +162,11 @@ the target (`target$`):
Hardware compatibility
======================
What systems are compatible with nonGeNUine Boot?
What systems are compatible with Canoeboot?
-----------------------------------------------------------------------------------
Any system can easily be added, so *compatibility* merely refers to whatever
boards are integrated in the `gbmk` build system, which nonGeNUine Boot uses.
boards are integrated in the `cbmk` build system, which Canoeboot uses.
Please read the [hardware compatibility list](docs/hardware/).
@ -259,7 +259,7 @@ application introduced in Q2 2013 with ME firmware version 9.0 on 4th
Generation Intel Core i3/i5/i7 (Haswell) CPUs. It allows a PC OEM to
generate an asymmetric cryptographic keypair, install the public key in
the CPU, and prevent the CPU from executing boot firmware that isn't
signed with their private key. This means that ***coreboot and nonGeNUine Boot
signed with their private key. This means that ***coreboot and Canoeboot
are impossible to port*** to such PCs, without the OEM's private
signing key. Note that systems assembled from separately purchased
mainboard and CPU parts are unaffected, since the vendor of the
@ -297,7 +297,7 @@ privacy that can't be ignored.
Before version 6.0 (that is, on systems from 2008/2009 and earlier), the
ME can be disabled by setting a couple of values in the SPI flash
memory. The ME firmware can then be removed entirely from the flash
memory space. The nonGeNUine Boot project [does this](docs/install/ich9utils.md) on
memory space. The Canoeboot project [does this](docs/install/ich9utils.md) on
the Intel 4 Series systems that it supports, such as the [ThinkPad
X200](../docs/install/x200_external.md) and [ThinkPad
T400](../docs/install/t400_external.md). ME firmware versions 6.0 and
@ -319,7 +319,7 @@ hopelessly proprietary and "tivoized".
**In summary, the Intel Management Engine and its applications are a
backdoor with total access to and control over the rest of the PC. The
ME is a threat to freedom, security, and privacy, and the nonGeNUine Boot
ME is a threat to freedom, security, and privacy, and the Canoeboot
project strongly recommends avoiding it entirely. Since recent versions
of it can't be removed, this means avoiding all recent generations of
Intel hardware.**
@ -328,6 +328,10 @@ The *above* paragraph is only talking about setups where the *full* Intel ME
firmware is used, containing networking code and especially *Active Management
Technology* (AMT).
Use of the `me_cleaner` utility is believed to minimize any security risk when
using these Intel platforms, and coreboot *does* contain fully free code for
sandybridge/ivybridge platforms.
More information about the Management Engine can be found on various Web
sites, including [me.bios.io](http://me.bios.io/Main_Page),
[unhuffme](http://io.netgarage.org/me/), [coreboot
@ -349,12 +353,7 @@ this blob to firmware developers, without source.
Since the FSP is responsible for the early hardware initialization, that
means it also handles SMM (System Management Mode). This is a special
mode that operates below the operating system level. **It's possible
that rootkits could be implemented there, which could perform a number
of attacks on the user (the list is endless). Any Intel system that has
the proprietary FSP blob cannot be trusted at all.** In fact, several
SMM rootkits have been demonstrated in the wild (use a search engine to
find them).
mode that operates below the operating system level.
### CPU microcode updates {#microcode}
@ -368,6 +367,10 @@ the microcode on AMD processors:
<https://yewtu.be/watch?v=W3FbTMqYi4U>
Here is another video:
<https://yewtu.be/watch?v=I6dQfnb3y0I>
The git repository for that project is here:
<https://github.com/RUB-SysSec/Microcode>
@ -375,27 +378,14 @@ The git repository for that project is here:
Both the video and the repository give some further insight about CPU
microcode. The way it works on AMD will be very similar to Intel.
### Intel is uncooperative
For years, coreboot has been struggling against Intel. Intel has been
shown to be extremely uncooperative in general. Many coreboot
developers, and companies, have tried to get Intel to cooperate; namely,
releasing source code for the firmware components. Even Google, which
sells millions of *chromebooks* (coreboot preinstalled) have been unable
to persuade them.
Even when Intel does cooperate, they still don't provide source code.
They might provide limited information (datasheets) under strict
corporate NDA (non-disclosure agreement), but even that is not
guaranteed. Even ODMs and IBVs can't get source code from Intel, in
most cases (they will just integrate the blobs that Intel provides).
Newer Intel graphics chipsets also [require firmware
blobs](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1).
Freedom pitfalls to consider on AMD hardware {#amd}
----------------------------------------------------------------------------
NOTE: Nowadays there's openSIL <https://github.com/openSIL/openSIL> - it's
AMD's attempt to provide some source code again, that projects like coreboot
can use, but AMD is still problematic; the PSP for example (see below) cannot
be "neutered" (nothing like `me_cleaner`, or *psp\_cleaner*) exists yet.
AMD has more or less the same problem as Intel, when it comes to software
freedom.
@ -437,7 +427,7 @@ machine completely outside of the user's knowledge.
Much like with the Intel Boot Guard (an application of the Intel
Management Engine), AMD's PSP can also act as a tyrant by checking
signatures on any boot firmware that you flash, making replacement boot
firmware (e.g. nongenuineboot, coreboot) impossible on some boards. Early
firmware (e.g. canoeboot, coreboot) impossible on some boards. Early
anecdotal reports indicate that AMD's boot guard counterpart will be
used on most OEM hardware, disabled only on so-called "enthusiast"
CPUs.
@ -464,7 +454,7 @@ demonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_-
and based on this work, Damien Zammit (another coreboot hacker)
[partially replaced it](https://github.com/zamaudio/smutool/) with free
firmware, but on the relevant system (ASUS F2A85-M) there were still
other blobs present (Video BIOS, and others).
other such files present (Video BIOS, and others).
### AMD AGESA firmware
@ -485,32 +475,11 @@ practically the same, though it was found with much later hardware in
AMD that you could run without microcode updates. It's unknown whether
the updates are needed on all AMD boards (depends on CPU).
### AMD is uncooperative
AMD seemed like it was on the right track in 2011 when it started
cooperating with and releasing source code for several critical
components to the coreboot project. It was not to be. For so-called
economic reasons, they decided that it was not worth the time to invest
in the coreboot project anymore. Unfortunately they haven't even shared
the source code of AGESA library for a Family 15h Steamroller/Excavator
architectures (which, like the earlier fam15h Bulldozer/Piledriver, do
not have a PSP) and released it to a coreboot project only as a binary.
For a company to go from being so good, to so bad, in just 3 years,
shows that something is seriously wrong with AMD. Like Intel, they do
not deserve your money.
Given the current state of Intel hardware with the Management Engine, it
is our opinion that all performant x86 hardware newer than the AMD
Family 15h CPUs (on AMD's side) or anything post-2009 on Intel's side
is defective by design and cannot safely be used to store, transmit, or
process sensitive data. Sensitive data is any data in which a data
breach would cause significant economic harm to the entity which created
or was responsible for storing said data, so this would include banks,
credit card companies, or retailers (customer account records), in
addition to the "usual" engineering and software development firms.
This also affects whistleblowers, or anyone who needs actual privacy and
security.
The Libreboot project does not consider microcode updates a problem, and it
enables them by default on all supported hardware; Canoeboot removes them, as
per GNU Free System Distribution Guidelines, but microcode updates are not a
threat to your freedom. For reasons why, read this article:
<https://libreboot.org/news/policy.html>
Hi, I have &lt;insert random system here&gt;, is it supported?
--------------------------------------------------------------------------------------------------------
@ -521,7 +490,7 @@ Please consult the coreboot project for guidance.
General questions
=================
How do I install nonGeNUine Boot?
How do I install Canoeboot?
-------------------------------------------------------
See [installation guide](docs/install/)
@ -538,7 +507,7 @@ align the pins properly. The connection is generally more sturdy.
How do I write-protect the flash chip?
----------------------------------------------------------------------------
By default, there is no write-protection on a nonGeNUine Boot system. This is
By default, there is no write-protection on a Canoeboot system. This is
for usability reasons, because most people do not have easy access to an
external programmer for re-flashing their firmware, or they find it
inconvenient to use an external programmer.
@ -549,7 +518,7 @@ possible, using dedicated hardware). For example, on current GM45
laptops (e.g. ThinkPad X200, T400), you can write-protect (see
[ICH9 gen utility](docs/install/ich9utils.md#ich9gen)).
It's possible to write-protect on all nonGeNUine Boot systems, but the instructions
It's possible to write-protect on all Canoeboot systems, but the instructions
need to be written. The documentation is in the main git repository, so you are
welcome to submit patches adding these instructions.
@ -559,18 +528,17 @@ other methods on AMD systems.
How do I change the BIOS settings?
------------------------------------------------------------------------
Most nonGeNUine Boot setups actually use the [GRUB
Most Canoeboot setups actually use the [GRUB
payload](http://www.coreboot.org/GRUB2). More information about payloads
can be found at
[coreboot.org/Payloads](http://www.coreboot.org/Payloads). SeaBIOS is also
available. The *CMOS* config is hardcoded in nonGeNUine Boot, but you can change the
defaults via `nvramtool -C nongenuineboot.rom -w config_item=value`
available. The *CMOS* config is hardcoded in Canoeboot.
Our nonGeNUine Boot project inherits the modular payload concept from coreboot, which
Our Canoeboot project inherits the modular payload concept from coreboot, which
means that pre-OS bare-metal *BIOS setup* programs are not very
practical. Coreboot (and nonGeNUine Boot) does include a utility called
practical. Coreboot (and Canoeboot) does include a utility called
*nvramtool*, which can be used to change some settings. You can find
nvramtool under *coreboot/util/nvramtool/*, in the nonGeNUine Boot source
nvramtool under *coreboot/util/nvramtool/*, in the Canoeboot source
archives.
The *-a* option in nvramtool will list the available options, and *-w*
@ -580,7 +548,7 @@ coreboot wiki for more information.
In practise, you don't need to change any of those settings, in most
cases.
Default nonGeNUine Boot setups lock the CMOS table, to ensure consistent functionality
Default Canoeboot setups lock the CMOS table, to ensure consistent functionality
for all users. You can use:
nvramtool -C yourrom.rom -w somesetting=somevalue
@ -597,10 +565,10 @@ How do I pad a ROM before flashing?
It is advisable to simply use a larger ROM image. This section was written
mostly for ASUS KCMA-D8 and KGPE-D16 mainboards, where previously we only
provided 2MiB ROM images in nonGeNUine Boot, but we now provide 16MiB ROM images.
provided 2MiB ROM images in Canoeboot, but we now provide 16MiB ROM images.
Other sizes are not provided because in practise, someone upgrading one of
these chips will just use a 16MiB one. Larger sizes are available, but 16MiB
is the maximum that you can use on all currently supported nonGeNUine Boot systems
is the maximum that you can use on all currently supported Canoeboot systems
that use SPI flash.
Required for ROMs where the ROM image is smaller than the flash chip
@ -632,20 +600,20 @@ padded 16MiB image do the following:
With padding removed cbfstool will be able to operate on the image as usual.
Do I need to install a bootloader when installing a distribution?
Do I need a bootloader in my distro?
---------------------------------------------------------------------------------------------------
Most nonGeNUine Boot setups integrate the GRUB bootloader already, as a
Most Canoeboot setups integrate the GRUB bootloader already, as a
*[payload](http://www.coreboot.org/Payloads)*. This means that the GRUB
bootloader is actually *flashed*, as part of the boot firmware
(nonGeNUine Boot). This means that you do not have to install a boot loader on
(Canoeboot). This means that you do not have to install a boot loader on
the HDD or SSD, when installing a new distribution. You'll be able to
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 GNU+Linux on nonGeNUine Boot](../docs/gnulinux/grub_boot_installer.md)
[Install GNU+Linux on Canoeboot](../docs/gnulinux/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
@ -654,12 +622,12 @@ expect. So the above paragraphs only apply to the GRUB payload.
Do I need to re-flash when I re-install a distribution?
-------------------------------------------------------------------------------------------
Not anymore. Recent versions of nonGeNUine Boot (using the GRUB payload) will
Not anymore. Recent versions of Canoeboot (using the GRUB payload) will
automatically switch to a GRUB configuration on the HDD or SSD, if it
exists. You can also load a different GRUB configuration, from any kind
of device that is supported in GRUB (such as a USB flash drive). For
more information, see
[Modifying the GRUB configuration in nonGeNUine Boot](../docs/gnulinux/grub_cbfs.md)
[Modifying the GRUB configuration in Canoeboot](../docs/gnulinux/grub_cbfs.md)
If you're using the SeaBIOS payload, it's even easier. It works just like you
would expect. SeaBIOS implements a normal x86 BIOS interface.
@ -670,7 +638,7 @@ What does a flash chip look like?
You can find photos of various chip types on the following page:\
[External 25xx NOR flashing guide](docs/install/spi.md)
What other firmware exists outside of nonGeNUine Boot?
What other firmware exists outside of Canoeboot?
==================================================
### External GPUs
@ -684,7 +652,7 @@ in a coreboot ROM image and have coreboot executes it, if you use a
different payload, such as GRUB).
The *coreboot project* provides free initialization code, on many boards, and
nonGeNUine Boot will use this code when it is available, depending on the
Canoeboot will use this code when it is available, depending on the
configuration.
In configurations where SeaBIOS and native GPU init are used together,
@ -752,6 +720,11 @@ it through the controller. This
<http://www.intel.co.uk/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1_3.pdf>
(pages 59, 67, 94, 99).
The following is based on discussion with Peter Stuge (CareBear\\) in
the coreboot IRC channel on Friday, 18 September 2015, when
investigating whether the SATA drive itself can make use of DMA. The
following is based on the datasheets linked above:
According to those linked documents, FIS type 39h is *"DMA Activate FIS
- Device to Host"*. It mentions *"transfer of data from the host to
the device, and goes on to say: Upon receiving a DMA Activate, if the
@ -802,7 +775,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 nonGeNUine Boot is capable of booting from them the
connect SATA HDDs via USB, and Canoeboot is capable of booting from them the
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*.
@ -830,6 +803,9 @@ Microcode configures logic gate arrays in a microprocessor, to implement the
instruction set architecture. Special *decoders* in the microprocessor will
configure the circuitry, based on that microcode.
The [libreboot blob reduction policy](https://libreboot.org/news/policy.html)
goes into great detail about microcode.
### Sound card
Sound hardware (integrated or discrete) typically has firmware on it
@ -841,7 +817,7 @@ workaround.
Webcams have firmware integrated into them that process the image input
into the camera; adjusting focus, white balancing and so on. Can use USB
webcam hardware, to work around potential DMA issues; integrated webcams
(on laptops, for instance) are discouraged by the nonGeNUine Boot project, for
(on laptops, for instance) are discouraged by the Canoeboot project, for
security reasons.
### USB host controller
@ -866,7 +842,7 @@ by the GSM network, by triangulating the signal).
On some laptops, these cards use USB (internally), so won't have DMA,
but it's still a massive freedom and privacy issue. If you have an
internal WWAN chip/card, the nonGeNUine Boot project recommends that you
internal WWAN chip/card, the Canoeboot project recommends that you
disable and (ideally, if possible) physically remove the hardware. If
you absolutely must use this technology, an external USB dongle is much
better because it can be easily removed when you don't need it, thereby
@ -881,14 +857,14 @@ Operating Systems
Can I use GNU+Linux?
--------------------------------------------------
Absolutely! It is well-tested in nonGeNUine Boot, and highly recommended. See
Absolutely! It is well-tested in Canoeboot, and highly recommended. See
[installing GNU+Linux](../docs/gnulinux/grub_boot_installer.md) and
[booting GNU+Linux](../docs/gnulinux/grub_cbfs.md).
Any recent distribution should work, as long as it uses KMS (kernel mode
setting) for the graphics.
Fedora won't boot? (may also be applicable to Redhat/CentOS)
Fedora won't boot? (maybe Redhat/CentOS)
-----------------------------------------------------------
On Fedora, by default the grub.cfg tries to boot linux in 16-bit mode. You
@ -898,7 +874,7 @@ Refer to [the GNU+Linux page](docs/gnulinux/).
Can I use BSD?
----------------------------------
Absolutely! The nonGeNUine Boot firmware has good support for FreeBSD, NetBSD and
Absolutely! The Canoeboot firmware has good support for FreeBSD, NetBSD and
OpenBSD. Other systems are untested, but should work just fine.
See:
@ -909,10 +885,10 @@ Are other operating systems compatible?
Unknown. Perhaps so, but it's impossible to say without further testing.
What level of software freedom does nonGeNUine Boot give me?
What level of freedom does Canoeboot give me?
===================================================
nonGeNUine Boot firmware provides host hardware initialisation inside ROM files,
Canoeboot firmware provides host hardware initialisation inside ROM files,
that can be written to NOR flash, but on many systems there exist
a lot more small computers on the mainboard running blob firmware.
Some of them are not practicable to replace due to being located on Mask ROM.
@ -993,6 +969,10 @@ Where can I learn more about electronics
* [Sam Zeloof](https://yewtu.be/channel/UC7E8-0Ou69hwScPW1_fQApA)
(Sam literally makes CPUs in his garage, inspired by Jeri Ellsworth's
work with transistors)
* [Ben Eater](https://eater.net/) (shows how to build an 8-bit CPU from scratch,
also does things with MOS 6502)
(also shows how to make other things like graphics chips, teaches networking
concepts) - check out Ben's videos! <https://redirect.invidious.io/beneater>
* [iPad Rehab with Jessa Jones](https://yewtu.be/channel/UCPjp41qeXe1o_lp1US9TpWA)
(very precise soldering. she does repairs on mobile phones and such, also
featured in iFixit's series about getting into component repairs)

82
site/faq.uk.md
View File

@ -8,15 +8,15 @@ x-toc-enable: true
Важливі питання
================
Як скомпілювати nonGeNUine Boot з джерельного коду
Як скомпілювати Canoeboot з джерельного коду
------------------------------------
Зверніться до [інструкцій зі збірки gbmk](docs/build/).
Зверніться до [інструкцій зі збірки cbmk](docs/build/).
Як працює система збірки?
-------------------------------
Зверніться до [посібника з обслуговування gbmk](docs/maintain/).
Зверніться до [посібника з обслуговування cbmk](docs/maintain/).
Не використовуйте CH341A!
------------------
@ -48,7 +48,7 @@ Error accessing DMI Table, 0x1000 bytes at 0x000000007fb27000
/dev/mem mmap failed: Operation not permitted
```
Підсвічування в лівій частині екрана стає темнішим, якщо зменшити яскравість мого ноутбука ThinkPad X200/X200S/X200T, T400, T500, R400, W500, R500 та інших ноутбуків Intel
Підсвічування в лівій частині екрана стає темнішим
---------------------------------------------------------------------------------------------------------------
Ми не знаємо, як визначити правильне значення ШІМ для використання в
@ -62,7 +62,7 @@ Ethernet не працює на моєму X200/T400/X60/T60, коли я йог
-------------------------------------------------------------------
Це спостерігалося в деяких системах, які використовують network-manager. Таке буває
як в оригінальному BIOS, так і в nonGeNUine Boot. Це примха в
як в оригінальному BIOS, так і в Canoeboot. Це примха в
обладнанні. У системах debian обхідним шляхом є перезапуск сервіса
мережі, коли ви підключаєте кабель ethernet:
@ -75,8 +75,8 @@ Ethernet не працює на моєму X200/T400/X60/T60, коли я йог
(назва служби може відрізнятися для вас, залежно від вашої
конфігурації)
Мій KCMA-D8 або KGPE-D16 не завантажується з встановленим модулем PIKE2008
-----------------------------------------------------------------------
які слід враховувати на апаратному забезпеченні AMD
---------------------------------------------------
Завантаження Option ROM з модуля PIKE2008 на ASUS KCMA-D8
або KGPE-D16 викликає зависання системи під час завантаження. Можна використовувати
@ -153,11 +153,11 @@ Ethernet не працює на моєму X200/T400/X60/T60, коли я йог
Апаратна сумісність
======================
Які системи сумісні з nonGeNUine Boot?
Які системи сумісні з Canoeboot?
-----------------------------------------------------------------------------------
Будь-яку систему можна легко додати, тому *сумісність* посилається до будь-якої
інтегрованої до системи побудови `gbmk` плати, яку nonGeNUine Boot використовує.
інтегрованої до системи побудови `cbmk` плати, яку Canoeboot використовує.
Прочитайте [список сумісного обладнання](docs/hardware/).
@ -250,7 +250,7 @@ Platform Module (TPM), Intel Boot Guard, аудіо та відео DRM
поколінні процесорів Intel Core i3/i5/i7 (Haswell). Це дозволяє виробникам комплектного обладнання для ПК
згенерувати асиметричну криптографічну пару ключів, встановити публічний ключ
в ЦП і запобігти ЦП від запуску завантажувальної мікропрограми, яка не підписана
з їх приватним ключем. Це означає, що ***coreboot та nonGeNUine Boot
з їх приватним ключем. Це означає, що ***coreboot та Canoeboot
неможливо перенести*** на такі ПК, без приватного ключа підпису
OEM. Зверніть увагу, що системи, зібрані з придбаних окремо материнської плати
та ЦП залишаються незмінними, оскільки постачальник материнської
@ -288,7 +288,7 @@ Intel Management Engine із власною мікропрограмою маю
До версії 6.0 (тобто в системах 2008/2009 і раніше),
ME можна вимкнути, встановивши пару значень у флеш-пам'яті SPI.
Прошивку ME потім можна повністю видалити з простору флеш-
пам'яті. Проект nonGeNUine Boot [робить це](docs/install/ich9utils.md) на
пам'яті. Проект Canoeboot [робить це](docs/install/ich9utils.md) на
системах Intel серії 4, які він підтримує, наприклад [ThinkPad
X200](../docs/install/x200_external.uk.md) та [ThinkPad
T400](../docs/install/t400_external.md). Прошивка ME версії 6.0 та
@ -310,7 +310,7 @@ PCH, включає мікропрограму "ME Ignition", яка викон
**Підсумовуючи, Intel Management Engine і його програми є
лазівкою з повним доступом до та контролем над рештою ПК.
ME є загрозою свободі, безпеці та конфіденційності, і проект nonGeNUine Boot
ME є загрозою свободі, безпеці та конфіденційності, і проект Canoeboot
наполегливо рекомендує повністю уникати цього. З останніх версій
його не можна видалити, це означає уникати всіх останніх поколінь обладнання
Intel.**
@ -384,7 +384,7 @@ Revealed (Розкрито вбудовану технологію безпек
Новіші графічні чіпсети Intel [вимагають блобів
прошивки](https://01.org/linuxgraphics/intel-linux-graphics-firmwares?langredirect=1).
Проект nonGeNUine Boot *надає* деяку підтримку для новіших платформ Intel, але
Проект Canoeboot *надає* деяку підтримку для новіших платформ Intel, але
вам варто знати про ці проблемні питання, якщо ви вибираєте використовувати ці машини.
Підводні камені свободи, які слід враховувати на апаратному забезпеченні AMD {#amd}
@ -431,7 +431,7 @@ PSP теоретично має доступ до всього простору
Подібно до Intel Boot Guard (додаток Intel
Management Engine), PSP від AMD також може діяти як тиран, перевіряючи
підписи будь-якої завантажувальної мікропрограми, яку ви прошиваєте, унеможливлюючи заміну
завантажувальної мікропрограми (наприклад, nongenuineboot, coreboot) на деяких платах. Ранні
завантажувальної мікропрограми (наприклад, canoeboot, coreboot) на деяких платах. Ранні
неофіційні повідомлення свідчать про те, що аналог AMD boot guard буде використовуватися
на більшості апаратного забезпечення OEM, відключений лише на так званих процесорах
"ентузіастів".
@ -506,7 +506,7 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
Це також стосується викривачів або будь-кого, кому потрібна справжня конфіденційність та
безпека.
Привіт, у мене &lt;вставте сюди випадкову систему&gt;, чи підтримується вона?
&lt;вставте сюди випадкову систему&gt;, чи підтримується вона?
--------------------------------------------------------------------------------------------------------
Якщо в coreboot бракує підтримки для вашого апаратного забезпечення, ви мусите додати підтримку для нього.
@ -515,7 +515,7 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
Загальні питання
=================
Як встановити nonGeNUine Boot?
Як встановити Canoeboot?
-------------------------------------------------------
Подивіться [посібник з встановлення](docs/install/)
@ -532,7 +532,7 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
Як захистити флеш-чіп від запису?
----------------------------------------------------------------------------
За замовчуванням немає захисту від запису на системі nonGeNUine Boot. Це
За замовчуванням немає захисту від запису на системі Canoeboot. Це
з міркувань зручності використання, оскільки більшість людей не мають легкого доступу до зовнішнього
програматора для перепрошивання їх мікропрограми, або вони знаходять
незручним використання зовнішнього програматора.
@ -543,7 +543,7 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
(таких як, ThinkPad X200, T400) можна захистити від запису (див.
[утиліту ICH9 gen](docs/install/ich9utils.md#ich9gen)).
Захист від запису можна встановити на всіх системах nonGeNUine Boot, але інструкції
Захист від запису можна встановити на всіх системах Canoeboot, але інструкції
потрібно написати. Документація знаходиться в основному репозиторії git, тому ви можете
надсилати виправлення, додаючи ці інструкції.
@ -553,18 +553,18 @@ Family 15h (на стороні AMD) або будь-яке інше, випущ
Як змінити налаштування BIOS?
------------------------------------------------------------------------
Більшість налаштувань nonGeNUine Boot насправді використовує [корисне навантаження
Більшість налаштувань Canoeboot насправді використовує [корисне навантаження
GRUB](http://www.coreboot.org/GRUB2). Більше інформації про корисні навантаження
може бути знайдено на
[coreboot.org/Payloads](http://www.coreboot.org/Payloads). SeaBIOS також
доступний. Конфігурацію *CMOS* жорстко закодовано в nonGeNUine Boot.
доступний. Конфігурацію *CMOS* жорстко закодовано в Canoeboot.
Проект nonGeNUine Boot успадковує модульну концепцію корисного навантаження від coreboot, що
Проект Canoeboot успадковує модульну концепцію корисного навантаження від coreboot, що
означає, що програми *налаштування BIOS* не дуже
практичні. Coreboot (та nonGeNUine Boot) включає утиліту, названу
практичні. Coreboot (та Canoeboot) включає утиліту, названу
*nvramtool*, яка може бути використана для зміни деяких налаштувань. Ви можете знайти
nvramtool у *coreboot/util/nvramtool/*, в архівах джерельного коду
nonGeNUine Boot.
Canoeboot.
Параметр *-a* у nvramtool покаже список доступних параметрів, і *-w*
може бути використано для їх зміни. Зверніться до документації nvramtool на
@ -573,7 +573,7 @@ coreboot вікі для більшої інформації.
На практиці, у більшості випадків, вам не потрібно змінювати жодні з цих
налаштувань.
Налаштування nonGeNUine Boot за замовчуванням блокують таблицю CMOS, щоб забезпечити узгоджену функціональність
Налаштування Canoeboot за замовчуванням блокують таблицю CMOS, щоб забезпечити узгоджену функціональність
для всіх користувачів. Ви можете використовувати:
nvramtool -C вашаROM.rom -w деякеналаштування=деякезначення
@ -590,10 +590,10 @@ coreboot вікі для більшої інформації.
Бажано просто використовувати більший образ ROM. Цей розділ був написаний здебільшого для
материнських плат ASUS KCMA-D8 та KGPE-D16, де раніше ми надавали
тільки образи ROM розміром 2 MБ у nonGeNUine Boot, але тепер ми надаємо образи ROM розміром 16 МБ.
тільки образи ROM розміром 2 MБ у Canoeboot, але тепер ми надаємо образи ROM розміром 16 МБ.
Інші розміри не надаються, оскільки на практиці хтось, оновлюючи один із
цих чіпів, використовуватиме лише 16 МБ. Доступні більші розміри, але 16 МБ
це максимум, який ви можете використати на всіх підтримуваних системах nonGeNUine Boot, які
це максимум, який ви можете використати на всіх підтримуваних системах Canoeboot, які
використовують флеш-пам'ять SPI.
Необхідно для ROM, де образ ROM менший за флеш-чіп
@ -628,17 +628,17 @@ ROM та флеш-чіпом. Випадок вище, наприклад:
Чи потрібно встановлювати завантажувач під час встановлення дистрибутива?
---------------------------------------------------------------------------------------------------
Більшість налаштувань nonGeNUine Boot уже інтегрують завантажувач GRUB як
Більшість налаштувань Canoeboot уже інтегрують завантажувач GRUB як
*[корисне навантаження](http://www.coreboot.org/Payloads)*. Це означає, що завантажувач GRUB
фактично *прошивається* як частина завантажувальної прошивки
(nonGeNUine Boot). Це означає, що вам не потрібно встановлювати завантажувач на
(Canoeboot). Це означає, що вам не потрібно встановлювати завантажувач на
HDD або SSD під час встановлення нового дистрибутива. Ви зможете нормально завантажитися,
використовуючи завантажувач (GRUB), який знаходиться у мікросхемі флеш-пам'яті.
Це означає, що навіть якщо ви виймете жорсткий диск або твердотільний накопичувач, у вас всеодно
буде встановлено функціонуючий завантажувач, який можна використовувати для завантаження програми
встановлення дистрибутива з флеш-пам'яті USB. Див.
[Як інсталювати GNU+Linux у системі nonGeNUine Boot](../docs/gnulinux/grub_boot_installer.md)
[Як інсталювати GNU+Linux у системі Canoeboot](../docs/gnulinux/grub_boot_installer.md)
В даний час також передбачені інші корисні навантаження. Якщо ви використовуєте корисне навантаження SeaBIOS,
тоді на вашому HDD або SSD використовується звичайний завантажувальний сектор MBR, як і слід було
@ -647,12 +647,12 @@ HDD або SSD під час встановлення нового дистри
Чи потрібно мені перепрошивати, коли я перевстановлю дистрибутив?
-------------------------------------------------------------------------------------------
Більше ні. Останні версії nonGeNUine Boot (з використанням корисного навантаження GRUB)
Більше ні. Останні версії Canoeboot (з використанням корисного навантаження GRUB)
автоматично переключатимуться на конфігурацію GRUB на HDD або SSD, якщо
існує. Ви також можете завантажити іншу конфігурацію GRUB з будь-якого пристрою, який підтримується
GRUB (наприклад, флеш-накопичувач USB). Для
більшої інформації див.
[Змінення конфігурації GRUB в системах nonGeNUine Boot](../docs/gnulinux/grub_cbfs.md)
[Змінення конфігурації GRUB в системах Canoeboot](../docs/gnulinux/grub_cbfs.md)
Якщо ви використовуєте корисне навантаження SeaBIOS, це ще простіше. Це працює так, як ви
очікували. SeaBIOS реалізує звичайний інтерфейс x86 BIOS.
@ -663,7 +663,7 @@ GRUB (наприклад, флеш-накопичувач USB). Для
Ви можете знайти фотографії різних видів чипів на наступній сторінці:\
[Керівництво зовнішньої прошивки 25xx NOR](docs/install/spi.md)
Яке ще мікропрограмне забезпечення існує за межами nonGeNUine Boot?
Яке ще мікропрограмне забезпечення існує за межами Canoeboot?
==================================================
### Зовнішні графічні карти
@ -677,7 +677,7 @@ VBIOS (спеціальний вид OptionROM) зазвичай вбудова
інше корисне навантаження, таке як GRUB).
*Проект coreboot* надає вільний код ініціалізації, на багатьох платах, і
nonGeNUine Boot буде використовувати цей код, коли він наявний, в залежності від конфігурації.
Canoeboot буде використовувати цей код, коли він наявний, в залежності від конфігурації.
В конфігураціях, де SeaBIOS і власна ініціалізація GPU використовуються разом,
додається спеціальна прокладка VBIOS, яка використовує лінійний кадровий буфер coreboot.
@ -793,7 +793,7 @@ USB 3.0, який ще не можна використовувати в сво
Рекомендовано використовувати повне шифрування диска на жорстких дисках,
підключених через USB. У мережі є кілька адаптерів, які дозволяють підключати жорсткі диски
SATA через USB, і проект nonGeNUine Boot здатний завантажуватись з них
SATA через USB, і проект Canoeboot здатний завантажуватись з них
звичайним чином. Проконсультуйтесь з документацією для вашої операційної системи GNU+Linux/BSD,
щоб знати те, як встановити їх з *повнодисковим шифруванням*:
@ -833,7 +833,7 @@ SATA через USB, і проект nonGeNUine Boot здатний завант
Веб-камери мають вбудоване програмне забезпечення, яке обробляє зображення, що вводиться
в камеру; налаштування фокуса, балансу білого тощо. Можна використовувати апаратне забезпечення
веб-камери USB, щоб вирішити можливі проблеми DMA; інтегровані веб-камери
(наприклад, на ноутбуках) не рекомендовані проектом nonGeNUine Boot з
(наприклад, на ноутбуках) не рекомендовані проектом Canoeboot з
міркувань безпеки.
### Хост-контролер USB
@ -858,7 +858,7 @@ WWAN, підключення до мережі 3g/4g (наприклад, GSM).
На деяких ноутбуках ці карти використовують USB (внутрішньо), тому не матимуть DMA,
але це все одно є великою проблемою свободи та конфіденційності. Якщо у вас є
внутрішній чіп/карта WWAN, проект nonGeNUine Boot рекомендує вимкнути та
внутрішній чіп/карта WWAN, проект Canoeboot рекомендує вимкнути та
(в ідеалі, якщо можливо) фізично видалити апаратне забезпечення. Якщо вам абсолютно
необхідно використовувати цю технологію, зовнішній USB-адаптер набагато
кращий, оскільки його можна легко вийняти, коли він вам не потрібен, тим самим
@ -873,7 +873,7 @@ WWAN, підключення до мережі 3g/4g (наприклад, GSM).
Чи я можу використовувати GNU+Linux?
--------------------------------------------------
Абсолютно! Він добре перевірений в nonGeNUine Boot, та дуже рекомендований. Подивіться
Абсолютно! Він добре перевірений в Canoeboot, та дуже рекомендований. Подивіться
[встановлення GNU+Linux](../docs/gnulinux/grub_boot_installer.md) та
[запуск GNU+Linux](../docs/gnulinux/grub_cbfs.md).
@ -890,21 +890,21 @@ Fedora не завантажується? (також може бути заст
Чи я можу використовувати BSD?
----------------------------------
Абсолютно! Прошивка nonGeNUine Boot має добру підтримку для FreeBSD, NetBSD та
Абсолютно! Прошивка Canoeboot має добру підтримку для FreeBSD, NetBSD та
OpenBSD. Інші системи не перевірені, але мають працювти нормально.
Дивіться:
[docs/bsd/](docs/bsd/)
[docs/bsd/](docs/bsd/index.uk.md)
Чи підтримуються інші операційні системи?
-------------------------------------------------------------------
Невідомо. Можливо, але неможливо сказати без подальшого випробовування.
Який рівень програмної свободи дає мені nonGeNUine Boot?
Який рівень програмної свободи дає мені Canoeboot?
===================================================
Прошивка nonGeNUine Boot надає ініціалізацію апаратного забезпечення хоста всередині файлів ROM,
Прошивка Canoeboot надає ініціалізацію апаратного забезпечення хоста всередині файлів ROM,
що може бути записано на флеш NOR, але на багатьох системах існує
набагато більше маленьких комп'ютерів на материнській платі, виконуючих двійкові прошивки.
Деякі з них неможливо замінити через те, що вони розташовані на Mask ROM.

BIN
site/favicon.ico
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.5 KiB

After

Width:  |  Height:  |  Size: 7.1 KiB

BIN
site/favicon_black.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.8 KiB

BIN
site/favicon_white.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.0 KiB

3
site/footer.de.include
View File

@ -2,10 +2,9 @@
-------------------------------------------------------------------------------
* [Diese Seite bearbeiten](/git.de.md)
* [Wer entwickelt nonGeNUine Boot?](/who.md)
* [Wer entwickelt Canoeboot?](/who.md)
* [Lizenz](/license.md)
* [Vorlage](/template-license.md)
* [Logo](/logo-license.md)
* [Autoren](/contrib.md)
-------------------------------------------------------------------------------

3
site/footer.include
View File

@ -2,10 +2,9 @@
-------------------------------------------------------------------------------
* [Edit this page](/git.md)
* [Who develops nonGeNUine Boot?](/who.md)
* [Who develops Canoeboot?](/who.md)
* [License](/license.md)
* [Template](/template-license.md)
* [Logo](/logo-license.md)
* [Authors](/contrib.md)
-------------------------------------------------------------------------------

11
site/footer.it.include Normal file
View File

@ -0,0 +1,11 @@
-------------------------------------------------------------------------------
* [Modifica questa pagina](/git.de.md)
* [Chi sviluppa Canoeboot?](/who.de.md)
* [Licenza](/license.md)
* [Modelli di licenze](/template-license.md)
* [Autori](/contrib.md)
-------------------------------------------------------------------------------

3
site/footer.uk.include
View File

@ -2,10 +2,9 @@
-------------------------------------------------------------------------------
* [Редагувати цю сторінку](/git.md)
* [Хто розробляє nonGeNUine Boot?](/who.md)
* [Хто розробляє Canoeboot?](/who.md)
* [Ліцензія](/license.md)
* [Шаблон](/template-license.uk.md)
* [Логотип](/logo-license.md)
* [Автори](/contrib.md)
-------------------------------------------------------------------------------

3
site/footer.zh-cn.include
View File

@ -2,10 +2,9 @@
-------------------------------------------------------------------------------
* [编辑本页面](/git.md)
* [谁在开发 nonGeNUine Boot?](/who.md)
* [谁在开发 Canoeboot?](/who.md)
* [许可证](/license.md)
* [模板](/template-license.md)
* [图标](/logo-license.md)
* [作者](/contrib.md)
-------------------------------------------------------------------------------

262
site/git.de.md
View File

@ -3,118 +3,118 @@ title: Code review
x-toc-enable: true
...
**NOTE TO GNU Boot AUDITORS: Obviously, these repository links are unofficial
and you'll want to change them to your own ones for GNUBoot.**
NOTE FOR CONTRIBUTORS:
======================
**The repositories below are real, containing the actual code for this
nonGeNUine Boot website intended for use by GNU Boot, images and also the [nonGeNUine
Boot 20230717 release](news/nongenuineboot20230717.md). The GNU project is both free,
and encouraged, to re-use this work officially.**
The preferred development style is: work on Libreboot, and port changes from
each Libreboot release into Canoeboot, but do it all at once. Whenever a new
Libreboot release comes out, a Canoeboot release will happen either
simultaneously or a few days later, porting all suitable changes over from
the Libreboot release. More information about this is available
in the [about page](about.md).
nonGeNUine Boot Repositories
In other words: please only send patches directly to Canoeboot, if they are
patches that only Canoeboot can benefit from; use your best judgement. The
same rule applies for bug reports and testing; do Libreboot first.
Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
Please see: [Libreboot git page](https://libreboot.org/git.html)
and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
Canoeboot Repositories
===================
Informationen darüber wer an nonGeNUine Boot arbeitet und wer das Projekt betreibt
sind unter [who.md](who.md) zu finden.
Informationen darüber wer an Canoeboot arbeitet und wer das Projekt betreibt
sind unter [who.de.md](who.de.md) zu finden.
Das nonGeNUine Boot Projekt hat hauptsächlich 3 Git Repositories:
Das `canoeboot` Projekt hat hauptsächlich 3 Git Repositories:
* Build system: <https://codeberg.org/vimuser/gbmk>
* Webseite (+Anleitungen): <https://codeberg.org/vimuser/gbwww>
* Bilder (für die Webseite): <https://codeberg.org/vimuser/gbwww-img>
* Build system: <https://codeberg.org/canoeboot/cbmk>
* Webseite (+Anleitungen): <https://codeberg.org/canoeboot/cbwww>
* Bilder (für die Webseite): <https://codeberg.org/canoeboot/cbwww-img>
Weiter unten auf dieser Seite sind Mirror von `gbmk` und `gbwww` aufgelistet,
sofern die Haupt Git Repositories nicht erreichbar sein sollten.
Zudem gibt es noch diese vom nonGeNUine Boot Projekt gehosteten Programme, welche
von nonGeNUine Boot entweder empfohlen oder verwendet werden:
bucts is also there: <https://notabug.org/libreboot/bucts>
Du kannst diese Repositories herunterladen, sie nach deinen Wünschen ändern,
und dann deine Änderungen zur Verfügung stellen mithilfe der folgenden
Anleitungen.
Es wird empfohlen den nonGeNUine Boot build (alle zugehörigen Teile) in einer
GNU+Linux Umgebung herzustellen. Unter BSD Systemen ist das build system (gbmk)
beispielsweise nicht getestet.
Installiere `git` auf deinem GNU+Linux System und lade eines der Repositories
herunter.
Die Entwicklung von nonGeNUine Boot findet mithilfe der Versionskontrolle von
Die Entwicklung von Canoeboot findet mithilfe der Versionskontrolle von
Git statt. Sieh in der [offiziellen Git Dokumentation](https://git-scm.com/doc)
nach, sofern Du nicht weisst wie man Git verwendet.
Das `bucts` Repository wird auch vom nonGeNUine Boot Projekt gehostet, da das
Original Repository auf `stuge.se` nicht mehr verfügbar ist, seit wie dies
zuletzt geprüft haben. Das `bucts` Programm wurde von Peter Stuge geschrieben.
Du benötigst `bucts` sofern Du ein nonGeNUine Boot ROM intern auf ein Thinkpad X60
oder T60 flashen möchtest, welches (derzeit) noch ein nicht-freies Lenovo
BIOS verwendet. Anleitungen hierfür findest Du hier:\
[nonGeNUine Boot Installations Anleitungen](docs/install/)
Das `ich9utils` Repository wird erheblich vom `gbmk` build system verwendet.
Du kannst `ich9utils` allerdings auch separat herunterladen und verwenden.
Es erzeugt ICH9M descriptor+GbE Images für GM45 ThinkPads welche die ICH9M
Southbridge verwenden. Es könnte auch für andere Systeme funktionieren,
welche dieselbe Platform bzw. denselben Chipsatz verwenden.
Dokumentation für `ich9utils` ist hier verfügbar:\
[ich9utils Dokumentation](docs/install/ich9utils.md)
gbmk (non**G**eNUine**B**oot**M**a**K**e)
cbmk (canoeboot-make)
---------------------
Dies ist das zentrale build system in nonGeNUine Boot. Man könnte auch sagen `gbmk` *ist*
nonGeNUine Boot! Das Git repository herunterladen:
Dies ist das zentrale build system in Canoeboot. Man könnte auch sagen `cbmk` *ist*
Canoeboot! Das Git repository herunterladen:
git clone https://codeberg.org/vimuser/gbmk
git clone https://codeberg.org/canoeboot/cbmk
Der oben dargestellte `git` Befehl, wird das nonGeNUine Boot build system `gbmk`
Der oben dargestellte `git` Befehl, wird das Canoeboot build system `cbmk`
herunterladen.
Du kannst dann folgendermassen in das Verzeichnis wechseln:
cd gbmk
cd cbmk
Ändere dies nach deinen Vorstellungen oder erstelle einfach einen build.
Für Anleitungen bzgl. `gbmk` build, siehe [build Anleitungen](docs/build/).
Für Anleitungen bzgl. `cbmk` build, siehe [build Anleitungen](docs/build/).
Informationen über das build system selbst und wie es funktioniert, sind
verfügbar unter dem [gbmk maintenance guide](docs/maintain/).
verfügbar unter dem [cbmk maintenance guide](docs/maintain/).
gbwww and gbwww-img
cbwww and cbwww-img
-------------------
Die *gesamte* nonGeNUine Boot Website sowie Dokumentation befindet sich in einem
Die *gesamte* Canoeboot Website sowie Dokumentation befindet sich in einem
Git Repository.
Du kannst es folgendermassen herunterladen:
git clone https://codeberg.org/vimuser/gbwww
git clone https://codeberg.org/canoeboot/cbwww
Bilder befinden sich unter <https://avgnu.vimuser.org/> und sind verfügbar
Bilder befinden sich unter <https://av.canoeboot.org/> und sind verfügbar
in einem separaten Git Repository:
git clone https://codeberg.org/vimuser/gbwww-img
git clone https://codeberg.org/canoeboot/cbwww-img
Du kannst alles nach deinen Vorstellungen ändern. Beachte die nachfolgenden
Informationen wie Du deine Änderungen zur Verfügung stellen kannst.
Die gesamte Website ist in Markdown geschrieben, insbesondere die Pandoc Version.
Die statischen HTML Seiten werden mit [Untitled](https://untitled.vimuser.org/)
generiert. Leah Rowe, die Gründerin von nonGeNUine Boot, ist auch die Gründerin des Untitled static
generiert. Leah Rowe, die Gründerin von Canoeboot, ist auch die Gründerin des Untitled static
site generator Projekts.
Wenn Du möchtest, kannst Du einen lokalen HTTP Server einrichten und eine
lokale Version der Website herstellen. Bitte bedenke, dass alle Bilder nach
wie vor mit den Bildern auf <https://avgnu.vimuser.org/> verknüpft werden,
daher werden jegliche Bilder die Du `gbwww-img` hinzugefügt hast nicht auf
deiner lokalen `gbwww` Seite dargestellt, sofern Du die Bilder (die Du
hinzugefügt hast) mit `avgnu.vimuser.org` verknüpfst. Es ist jedoch erforderlich,
dass sich diese Bilder auf avgnu.vimuser.org befinden.
wie vor mit den Bildern auf <https://av.canoeboot.org/> verknüpft werden,
daher werden jegliche Bilder die Du `cbwww-img` hinzugefügt hast nicht auf
deiner lokalen `cbwww` Seite dargestellt, sofern Du die Bilder (die Du
hinzugefügt hast) mit `av.canoeboot.org` verknüpfst. Es ist jedoch erforderlich,
dass sich diese Bilder auf av.canoeboot.org befinden.
Sofern Du der Webseite Bilder hinzufügen möchtest, füge diese ebenso
dem `gbwww-img` Repository hinzu, indem Du diese dann jeweils mit diesem Link verknüpfst
<https://avgnu.vimuser.org/path/to/your/new/image/in/gbwww-img>.
Wenn dein Patch der nonGeNUine Boot Webseite hinzugefügt wird, werden erscheinen deine Bilder live.
dem `cbwww-img` Repository hinzu, indem Du diese dann jeweils mit diesem Link verknüpfst
<https://av.canoeboot.org/path/to/your/new/image/in/cbwww-img>.
Wenn dein Patch der Canoeboot Webseite hinzugefügt wird, werden erscheinen deine Bilder live.
If adding a photo, compress it for web distribution. Images should be about
800px wide, and usually under 100KiB in size:
First, scale your image down to approximately 800px width, using your favourite
image manipulation program. For example, with `imagemagick` you can do the
following (make sure the image isn't already smaller or equal than preferred).
convert original.jpg -resize 600000@ -quality 70% web.jpg
You should always run `jpegoptim` on jpg images before submitting them.
It strips useless metadata and *losslessly* optimises them further by cleverly
rearranging the huffman tables used in them.
jpegoptim -s --all-progressive web.jpg
If the image is a (line) drawing, vector graphics are preferable to bitmaps.
Therefore, if possible, save them as SVGs. Those are easy to modify,
and will surely make translators' work easier as well.
PNG images should be optimised with `zopfli` (this is lossless as well).
For example, this reduced the Canoeboot boot logo from around 11k to 3k:
zopflipng -ym image.png image.png
Zu Entwicklungszwecken, könntest Du deine Bilder auch lokal verknüpfen, und
anschliesend die URLs anpassen sobald Du deine Patches für die Dokumentation/Webseite schickst.
@ -122,7 +122,7 @@ anschliesend die URLs anpassen sobald Du deine Patches für die Dokumentation/We
Eine Anleitung wie Du eine lokale Version der Webseite herstellen kannst,
befinden sich auf der Untitled Webseite. Lade untitled
herunter, und erstelle in dem `untitled` Verzeichnis ein Verzeichnis mit
dem Namen `www/` dann wechsle in dieses Verzeichnis und klone das `gbwww`
dem Namen `www/` dann wechsle in dieses Verzeichnis und klone das `cbwww`
Repository dorthin. Konfiguriere deinen lokalen HTTP Server entsprechend.
Nochmal, Anleitungen hierfür findest Du auf der Untitled Webseite.
@ -135,8 +135,8 @@ Repository öffentlich aufgezeichnet. Dies betrifft ebenso den Namen sowie
die email Adresse des Mitwirkenden.
Du musst bei Git keinen Autoren Namen bzw. keine email Addresse verwenden,
mithilfe derer Du identifizierbar bist. Du kannst `nongenuineboot Contributor`
verwenden und deine email Addresse könnte als john@doe.com
mithilfe derer Du identifizierbar bist. Du kannst `canoeboot Contributor`
verwenden und deine email Addresse könnte als contributor@canoeboot.org
spezifiert werden. Es ist Dir gestattet dies zu tun, sofern Du deine Privatsphäre
wahren möchtest. Wir glauben an Privatsphäre. Sofern Du anonym bleiben möchtest
werden wir dies respektieren.
@ -159,13 +159,115 @@ bevor Du einem öffentlichen Git Repository Änderungen hinzufügst.
Lizenzen (für Mitwirkende)
--------
Make sure to freely license your work, under a free license.
Stelle sicher, dass deine Beiträge mit einer libre Lizenz frei lizensiert
sind. Canoeboot schreibt nicht mehr vor, welche Lizenzen akzeptiert werden,
und es existieren einige Lizenzen. Wir werden deinen Beitrag prüfen und
dir mitteilen sofern es ein Problem damit gibt (z.B. keine Lizenz).
*Always* declare a license on your work! Not declaring a license means that
the default, restrictive copyright laws apply, which would make your work
proprietary, subject to all of the same restrictions.
Gib *immer* eine Lizenz an für deine Arbeit! Keine Lizenz anzugeben bedeutet
das deine Arbeit unter die Standard Urheberrechte fällt, was deine Arbeit
proprietär macht und somit von denselben Einschränkungen betroffen ist.
The Free Software Foundation maintains a handy dandy list, which you can review
here:
Die MIT Lizenz ist ein guter Start, und sie ist die bevorzugte Lizenz
für sämtliche Arbeit an Canoeboot, aber wir sind nicht pingelig. Canoeboot
hat in der Vergangenheit GNU Lizenzen so wie GPL verwendet; vieles davon
besteht nach wie vor und wird auch weiterhin bestehen.
Es ist deine Arbeit; sofern deine Arbeit auf der Arbeit eines anderen basiert,
ist es aufgrund der Lizenz-Kompatibilität ggfs. naheliegend diesselbe Lizenz zu
verwenden.
<https://www.gnu.org/licenses/license-list.en.html>
[Hier](https://opensource.org/licenses) findest Du übliche Beispiele für Lizenzen.
*Wenn* deine Arbeit auf bestehender Arbeit basiert, dann ist es wichtig
(für deinen Beitrag) das die Lizenz deiner Arbeit kompatibel ist mit der
Lizenz der Arbeit auf der sie beruht. Die MIT Lizenz ist hierfür gut geeignet,
weil sie mit vielen anderen Lizenen kompatibel ist, und Freiheit zulässt
(wie zum Beispiel die Freiheit einer SubLizenz) was bei vielen anderen
Lizenzen nicht der Fall ist:
<https://opensource.org/licenses/MIT>
Patches senden
------------
Erstelle einen Account unter <https://codeberg.org/> und navigiere (während
Du eingeloggt bist) zu dem Repository das Du bearbeiten möchtest. Klicke
auf *Fork* und Du wirst ein eigenes Canoeboot Repository in deinem Account
erhalten. Erstelle einen Clone dieses Repository, füge alle gewünschten Änderungen hinzu
und führe anschliessend einen Push in dein Repository in deinem Account
auf Codeberg durch. Du kannst dies auch in einem neuen Branch erledigen,
sofern Du magst.
In deinem Codeberg Account kannst Du nun zum offiziellen Canoeboot
Repository navigieren und dort einen Pull Request erstellen. Die Art und
Weise wie dies funktioniert ist vergleichbar mit anderen populären Web basierten
Git Plattformen die heutzutage verwendet werden.
Du kannst dort deine Patches bereitstellen. Alternativ kannst Du dich in
den Canoeboot IRC Kanal einloggen und dort bekannt geben welche deiner Patches
geprüft werden sollen, sofern Du ein eigenes Git repository mit den Patches
hast.
Sobald Du einen Pull Request erstellt hast, werden die Canoeboot Maintainer
per email informiert. Sofern Du nicht schnell genug eine Antwort erhälst,
kannst Du das Projekt ebenso mithilfe des `#canoeboot` Kanals auf Libera
Chat kontaktieren.
Ein weiterer Weg Patches zu senden ist Leah Rowe direkt eine email zu senden:
[info@minifree.org](mailto:info@minifree.org) ist Leah's Projekt email Addresse.
Um den Prozess der Quelltext Überprüfung transparent zu gestalten,
wird jedoch empfohlen künftig Codeberg zu verwenden.
Git mirrors
===========
Mirrors für cbmk.git
--------------------
Das `cbmk` Repository enthält Canoeboot's automatischess build system, welches
Canoeboot Veröffentlichungen herstellt (inklusive kompilierter ROM Images).
Du kannst `git clone` für alle diese Links ausführen (die Links können auch
angeklickt werden, um Änderungen in deinem Web Browser anzusehen):
* <https://git.sr.ht/~canoeboot/cbmk>
* <https://git.disroot.org/canoeboot/cbmk>
* <https://gitea.treehouse.systems/canoeboot/cbmk>
* <https://0xacab.org/canoeboot/cbmk/>
* <https://framagit.org/canoeboot/canoeboot>
* <https://gitlab.com/canoeboot/cbmk>
* <https://notabug.org/canoeboot/cbmk>
cbwww.git Mirror
----------------
Das `cbwww` Repository enthält Markdown Dateien (Pandoc Variant), für die
Verwendung mit dem [Untitled Static Site Generator](https://untitled.vimuser.org/);
dies wird von Canoeboot verwendet um HTML Web Seiten bereitzustellen, *inklusive*
der Seite die Du gerade liest!
Du kannst `git clone` für diese Links ausführen und/oder die Links
anklicken um Änderungen in deinem Web Browser anzusehen). Siehe:
* <https://git.sr.ht/~canoeboot/cbwww>
* <https://git.disroot.org/canoeboot/cbwww>
* <https://gitea.treehouse.systems/canoeboot/cbwww>
* <https://0xacab.org/canoeboot/cbwww>
* <https://framagit.org/canoeboot/cbwww/>
* <https://gitlab.com/canoeboot/cbwww>
* <https://notabug.org/canoeboot/cbwww>
cbwww-img.git Mirror
----------------
Du kannst `git clone` für diese Links ausführen und/oder die Links
anklicken um Änderungen in deinem Web Browser anzusehen). Siehe:
* <https://git.sr.ht/~canoeboot/cbwww-img>
* <https://git.disroot.org/canoeboot/cbwww-img>
* <https://gitea.treehouse.systems/canoeboot/cbwww-img>
* <https://0xacab.org/canoeboot/cbwww-img>
* <https://framagit.org/canoeboot/cbwww-img/>
* <https://gitlab.com/canoeboot/cbwww-img>
* <https://notabug.org/canoeboot/cbwww-img>

247
site/git.md
View File

@ -3,115 +3,121 @@ title: Code review
x-toc-enable: true
...
**NOTE TO GNU Boot AUDITORS: Obviously, these repository links are unofficial
and you'll want to change them to your own ones for GNUBoot.**
NOTE FOR CONTRIBUTORS:
======================
**The repositories below are real, containing the actual code for this
nonGeNUine Boot website intended for use by GNU Boot, images and also the [nonGeNUine
Boot 20230717 release](news/nongenuineboot20230717.md). The GNU project is both free,
and encouraged, to re-use this work officially.**
The preferred development style is: work on Libreboot, and port changes from
each Libreboot release into Canoeboot, but do it all at once. Whenever a new
Libreboot release comes out, a Canoeboot release will happen either
simultaneously or a few days later, porting all suitable changes over
from the Libreboot release. More information about this is available
in the [about page](about.md).
nonGeNUine Boot repositories
In other words: please only send patches directly to Canoeboot, if they are
patches that only Canoeboot can benefit from; use your best judgement. The
same rule applies for bug reports and testing; do Libreboot first.
Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
Please see: [Libreboot git page](https://libreboot.org/git.html)
and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
Canoeboot repositories
===================
Information about who works on nonGeNUine Boot and who runs the project can be
Information about who works on canoeboot and who runs the project can be
found on [who.md](who.md)
The nonGeNUine Boot project has 3 main Git repositories:
The `canoeboot` project has 3 main Git repositories:
* Build system: <https://codeberg.org/vimuser/gbmk>
* Website (+docs): <https://codeberg.org/vimuser/gbwww>
* Images (for website): <https://codeberg.org/vimuser/gbwww-img>
* Build system: <https://codeberg.org/canoeboot/cbmk>
* Website (+docs): <https://codeberg.org/canoeboot/cbwww>
* Images (for website): <https://codeberg.org/canoeboot/cbwww-img>
If the main Git repositories are down, mirrors of `gbmk` and `gbwww` are listed
further down in this page
There are also these programs, hosted by the nonGeNUine Boot project, and nonGeNUine Boot
either recommends them or makes use of them:
bucts is also there: <https://notabug.org/libreboot/bucts>
You can download any of these repositories, make whatever changes you like, and
then submit your changes using the instructions below.
It is recommended that you build nonGeNUine Boot (all parts of it) in a GNU+Linux
distribution. For example, the build system (gbmk) is untested on BSD systems.
Install `git` in your GNU+Linux system, and download one of the repositories.
Development of nonGeNUine Boot is done using the Git version control system.
Development of canoeboot is done using the Git version control system.
Refer to the [official Git documentation](https://git-scm.com/doc) if you don't
know how to use Git.
The `bucts` repository is hosted by the nonGeNUine Boot project, because the original
repository on `stuge.se` is no longer available, last time we checked. The
`bucts` program was written by Peter Stuge. You need `bucts` if you're flashing
internally an nonGeNUine Boot ROM onto a ThinkPad X60 or T60 that is currently running
the non-free Lenovo BIOS. Instructions for that are available here:\
[nonGeNUine Boot installation guides](docs/install/)
The `ich9utils` repository is used heavily, by the `gbmk` build system. However,
you can also download `ich9utils` on its own and use it. It generates ICH9M
descriptor+GbE images for GM45 ThinkPads that use the ICH9M southbridge. It may
also work for other systems using the same platform/chipset.
Documentation for `ich9utils` is available here:\
[ich9utils documentation](docs/install/ich9utils.md)
gbmk (non**G**eNUine**B**oot**M**a**K**e)
cbmk (canoeboot-make)
---------------------
This is the core build system in nonGeNUine Boot. You could say that `gbmk` *is*
nonGeNUine Boot! Download the Git repository:
This is the core build system in canoeboot. You could say that `cbmk` *is*
canoeboot! Download the Git repository:
git clone https://codeberg.org/vimuser/gbmk
git clone https://codeberg.org/canoeboot/cbmk
The `git` command, seen above, will download the nonGeNUine Boot build system `gbmk`.
The `git` command, seen above, will download the canoeboot build system `cbmk`.
You can then go into it like so:
cd gbmk
cd cbmk
Make whatever changes you like, or simply build it. For instructions on how to
build `gbmk`, refer to the [build instructions](docs/build/).
build `cbmk`, refer to the [build instructions](docs/build/).
Information about the build system itself, and how it works, is available in
the [gbmk maintenance guide](docs/maintain/).
the [cbmk maintenance guide](docs/maintain/).
gbwww and gbwww-img
cbwww and cbwww-img
-------------------
The *entire* nonGeNUine Boot website and documentation is hosted in a Git repository.
The *entire* canoeboot website and documentation is hosted in a Git repository.
Download it like so:
git clone https://codeberg.org/vimuser/gbwww
git clone https://codeberg.org/canoeboot/cbwww
Images are hosted on <https://avgnu.vimuser.org/> and available in a separate
Images are hosted on <https://av.canoeboot.org/> and available in a separate
repository:
git clone https://codeberg.org/vimuser/gbwww-img
git clone https://codeberg.org/canoeboot/cbwww-img
Make whatever changes you like. See notes below about how to send patches.
The entire website is written in Markdown, specifically the Pandoc version.
Static HTML pages are generated with the [Untitled Static Site
Generator](https://untitled.vimuser.org/).
The entire website is written in Markdown, specifically the Pandoc version of
it. The static HTML pages are generated with [Untitled](https://untitled.vimuser.org/).
Leah Rowe, the founder of canoeboot, is also the founder of the Untitled static
site generator project.
If you like, you can set up a local HTTP server and build your own local
version of the website. Please note that images will still link to the ones
hosted on <https://avgnu.vimuser.org/>, so any images that you add to `gbwww-img`
will not show up on your local `gbwww` site if you make the image links (for
images that you add) link to `avgnu.vimuser.org`. However, it is required that such
images be hosted on avgnu.vimuser.org.
hosted on <https://av.canoeboot.org/>, so any images that you add to `cbwww-img`
will not show up on your local `cbwww` site if you make the image links (for
images that you add) link to `av.canoeboot.org`. However, it is required that such
images be hosted on av.canoeboot.org.
Therefore, if you wish to add images to the website, please also submit to the
`gbwww-img` repository, with the links to them being
<https://avgnu.vimuser.org/path/to/your/new/image/in/gbwww-img> for each one.
When it is merged on the nonGeNUine Boot website, your images will appear live.
`cbwww-img` repository, with the links to them being
<https://av.canoeboot.org/path/to/your/new/image/in/cbwww-img> for each one.
When it is merged on the canoeboot website, your images will appear live.
If adding a photo, compress it for web distribution. Images should be about
800px wide, and usually under 100KiB in size:
First, scale your image down to approximately 800px width, using your favourite
image manipulation program. For example, with `imagemagick` you can do the
following (make sure the image isn't already smaller or equal than preferred).
convert original.jpg -resize 600000@ -quality 70% web.jpg
You should always run `jpegoptim` on jpg images before submitting them.
It strips useless metadata and *losslessly* optimises them further by cleverly
rearranging the huffman tables used in them.
jpegoptim -s --all-progressive web.jpg
If the image is a (line) drawing, vector graphics are preferable to bitmaps.
Therefore, if possible, save them as SVGs. Those are easy to modify,
and will surely make translators' work easier as well.
PNG images should be optimised with `zopfli` (this is lossless as well).
For example, this reduced the Canoeboot boot logo from around 11k to 3k:
zopflipng -ym image.png image.png
For development purposes, you might make your images local links first, and
then adjust the URLs when you submit your documentation/website patches.
Instructions are on the Untitled website, for how to set up your local version
of the website. Download untitled, and inside your `untitled` directory, create
a directory named `www/` then go inside the www directory, and clone the `gbwww`
a directory named `www/` then go inside the www directory, and clone the `cbwww`
repository there. Configure your local HTTP server accordingly.
Again, instructions are available on the Untitled website for this purpose.
@ -124,8 +130,8 @@ everyone can access. This includes the name and email address of the
contributor.
In Git, for author name and email address, you do not have to use identifying
data. You can use `nongenuineboot Contributor` and your email address could be
specified as john@doe.com. You are permitted to do this, if
data. You can use `canoeboot Contributor` and your email address could be
specified as contributor@canoeboot.org. You are permitted to do this, if
you wish to maintain privacy. We believe in privacy. If you choose to remain
anonymous, we will honour this.
@ -145,16 +151,109 @@ push changes to a public Git repository.
Licenses (for contributors)
--------
Make sure to freely license your work, under a free license.
Make sure to freely license your work, under a libre license. Canoeboot no
longer sets arbitrary restrictions on what licenses are accepted, and many
licenses out there already exist. We will audit your contribution and tell
you if there are problems with it (e.g. no license).
*Always* declare a license on your work! Not declaring a license means that
the default, restrictive copyright laws apply, which would make your work
proprietary, subject to all of the same restrictions.
The Free Software Foundation maintains a handy dandy list, which you can review
here:
The MIT license is a good one to start with, and it is the preferred license
for all new works in Canoeboot, but we're not picky. Canoeboot has historically
used GNU licensing such as GPL; much of that remains, and is likely to remain.
It's your work; obviously, if you're deriving from an existing work,
it may make sense to use the same license on your contribution, for license
compatibility.
<https://www.gnu.org/licenses/license-list.en.html>
You can find common examples of licenses
[here](https://opensource.org/licenses).
As a GNU project, it is natural that you may use copyleft licenses for works
submitted to nonGeNUine Boot.
If you *are* deriving from an existing work, it's important that your license
(for your contribution) be compatible with the licensing of the work from which
yours was derived. The MIT license is good because it's widely compatible
with many other licenses, and permits many freedoms (such as the freedom to
sublicense) that other licenses do not:
<https://opensource.org/licenses/MIT>
Send patches
------------
Make an account on <https://codeberg.org/> and navigate (while logged in) to the
repository that you wish to work on. Click *Fork* and in your account,
you will have your own repository of canoeboot. Clone your repository, make
whatever changes you like to it and then push to your repository, in your
account on Codeberg. You can also do this on a new branch, if you wish.
In your Codeberg account, you can then navigate to the official canoeboot
repository and submit a Pull Request. The way it works is similar to other
popular web-based Git platforms that people use these days.
You can submit your patches there. Alternative, you can log onto the canoeboot
IRC channel and notify the channel of which patches you want reviewed, if you
have your own Git repository with the patches.
Once you have issued a Pull Request, the canoeboot maintainers will be notified
via email. If you do not receive a fast enough response from the project, then
you could also notify the project via the `#canoeboot` channel on Libera Chat.
Another way to submit patches is to email Leah Rowe directly:
[info@minifree.org](mailto:info@minifree.org) is Leah's project email address.
However, for transparency of the code review process, it's recommended that you
use Codeberg, for the time being.
Git mirrors
===========
Mirrors of cbmk.git
-------------------
The `cbmk` repository contains Canoeboot's automated build system, which
produces Canoeboot releases (including compiled ROM images).
You can run `git clone` on any of these links (the links are also clickable,
to view changes in your Web browser):
* <https://git.sr.ht/~canoeboot/cbmk>
* <https://git.disroot.org/canoeboot/cbmk>
* <https://gitea.treehouse.systems/canoeboot/cbmk>
* <https://0xacab.org/canoeboot/cbmk/>
* <https://framagit.org/canoeboot/canoeboot>
* <https://gitlab.com/canoeboot/cbmk>
* <https://notabug.org/canoeboot/cbmk>
cbwww.git mirror
----------------
The `cbwww` repository contains Markdown files (pandoc variant), for use
with the [Untitled Static Site Generator](https://untitled.vimuser.org/); this
is what Canoeboot uses to provide HTML web pages, *including* the page that
you are reading right now!
You can run `git clone` on these links, and/or click to view changes in your
Web browser. See:
* <https://git.sr.ht/~canoeboot/cbwww>
* <https://git.disroot.org/canoeboot/cbwww>
* <https://gitea.treehouse.systems/canoeboot/cbwww>
* <https://0xacab.org/canoeboot/cbwww>
* <https://framagit.org/canoeboot/cbwww/>
* <https://gitlab.com/canoeboot/cbwww>
* <https://notabug.org/canoeboot/cbwww>
cbwww-img.git mirror
----------------
You can run `git clone` on these links, and/or click to view changes in your
Web browser. See:
* <https://git.sr.ht/~canoeboot/cbwww-img>
* <https://git.disroot.org/canoeboot/cbwww-img>
* <https://gitea.treehouse.systems/canoeboot/cbwww-img>
* <https://0xacab.org/canoeboot/cbwww-img>
* <https://framagit.org/canoeboot/cbwww-img/>
* <https://gitlab.com/canoeboot/cbwww-img>
* <https://notabug.org/canoeboot/cbwww-img>

249
site/git.uk.md
View File

@ -3,116 +3,121 @@ title: Огляд коду
x-toc-enable: true
...
**NOTE TO GNU Boot AUDITORS: Obviously, these repository links are unofficial
and you'll want to change them to your own ones for GNUBoot.**
NOTE FOR CONTRIBUTORS:
======================
**The repositories below are real, containing the actual code for this
nonGeNUine Boot website intended for use by GNU Boot, images and also the [nonGeNUine
Boot 20230717 release](news/nongenuineboot20230717.md). The GNU project is both free,
and encouraged, to re-use this work officially.**
The preferred development style is: work on Libreboot, and port changes from
each Libreboot release into Canoeboot, but do it all at once. Whenever a new
Libreboot release comes out, a Canoeboot release will happen either
simultaneously or a few days later, porting all suitable changes over
from the Libreboot release. More information about this is available
in the [about page](about.md).
репозиторії nonGeNUine Boot
In other words: please only send patches directly to Canoeboot, if they are
patches that only Canoeboot can benefit from; use your best judgement. The
same rule applies for bug reports and testing; do Libreboot first.
Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
Please see: [Libreboot git page](https://libreboot.org/git.html)
and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
репозиторії Canoeboot
===================
Інформацію про те, хто працює над nonGeNUine Boot і хто керує проектом, можна
знайти на [who.md](who.md)
Інформацію про те, хто працює над canoeboot і хто керує проектом, можна
знайти на [who.uk.md](who.uk.md)
Проект nonGeNUine Boot має 3 основні сховища Git:
Проект `canoeboot` має 3 основні сховища Git:
* Система побудови: <https://codeberg.org/vimuser/gbmk>
* Веб-сайт (+документація): <https://codeberg.org/vimuser/gbwww>
* Зображення (для веб-сайта): <https://codeberg.org/vimuser/gbwww-img>
* Система побудови: <https://codeberg.org/canoeboot/cbmk>
* Веб-сайт (+документація): <https://codeberg.org/canoeboot/cbwww>
* Зображення (для веб-сайта): <https://codeberg.org/canoeboot/cbwww-img>
If the main Git repositories are down, mirrors of `gbmk` and `gbwww` are listed
further down in this page
Є також ці програми, розміщені в проекті nonGeNUine Boot, і nonGeNUine Boot
або рекомендує їх, або використовує їх:
bucts is also there: <https://notabug.org/libreboot/bucts>
Ви можете завантажити будь-яке з цих сховищ, внести будь-які зміни, і
потім надіслати свої зміни, дотримуючись інструкцій нижче.
Рекомендовано створювати nonGeNUine Boot (усі його частини) у дистрибутиві
GNU+Linux. Наприклад, система збірки (gbmk) не перевірена на системах BSD.
Встановіть `git` у вашій системі GNU+Linux, і завантажте одне із сховищ.
Розробка nonGeNUine Boot виконується за допомогою системи контролю версій Git.
Розробка canoeboot виконується за допомогою системи контролю версій Git.
Зверніться до [офіційної документації Git](https://git-scm.com/doc), якщо ви не
знаєте, як користуватися Git.
Репозиторій `bucts` розміщено в проекті nonGeNUine Boot, оскільки оригінальний
репозиторій на `stuge.se` більше не доступний, коли ми перевіряли останній раз.
Програма `bucts` була написана Пітером Стьюджем. Вам знадобляться `bucts`, якщо ви прошиваєте
внутрішньо nonGeNUine Boot ROM на ThinkPad X60 або T60, на якому зараз працює
невільний Lenovo BIOS. Інструкції щодо цього доступні тут:\
[посібники зі встановлення nonGeNUine Boot](docs/install/)
Репозиторій `ich9utils` активно використовується системою збирання `gbmk`. Однак
ви також можете завантажити `ich9utils` самостійно та використовувати його. Він генерує ICH9M
дескриптор+GbE образи для GM45 ThinkPad, які використовують південний міст ICH9M. Він
також може працювати з іншими системами, що використовують ту саму платформу/чіпсет.
Документація для `ich9utils` доступна тут:\
[документація ich9utils](docs/install/ich9utils.md)
gbmk (non**G**eNUine**B**oot**M**a**K**e)
cbmk (canoeboot-make)
---------------------
Це основна система збирання в nonGeNUine Boot. Можна сказати, що `gbmk` *це*
nonGeNUine Boot! Завантажте репозиторій Git:
Це основна система збирання в canoeboot. Можна сказати, що `cbmk` *це*
canoeboot! Завантажте репозиторій Git:
git clone https://codeberg.org/vimuser/gbmk
git clone https://codeberg.org/canoeboot/cbmk
Команда `git`, показана вище, завантажить систему збірки nonGeNUine Boot `gbmk`.
Команда `git`, показана вище, завантажить систему збірки canoeboot `cbmk`.
Потім ви можете перейти до цього так:
cd gbmk
cd cbmk
Внесіть будь-які зміни, які забажаєте, або просто побудуйте. Щоб отримати вказівки щодо
збирання `gbmk`, зверніться до [інструкцій зі збирання](docs/build/).
збирання `cbmk`, зверніться до [інструкцій зі збирання](docs/build/index.uk.md).
Інформація про саму систему збірки та про те, як вона працює, доступна в
[посібнику обслуговування gbmk](docs/maintain/).
[посібнику обслуговування cbmk](docs/maintain/).
gbwww та gbwww-img
cbwww та cbwww-img
-------------------
*Весь* веб-сайт і документація nonGeNUine Boot розміщені в репозиторії Git.
*Весь* веб-сайт і документація canoeboot розміщені в репозиторії Git.
Завантажте так:
git clone https://codeberg.org/vimuser/gbwww
git clone https://codeberg.org/canoeboot/cbwww
Зображення розміщені на <https://avgnu.vimuser.org/> і доступні в окремому
Зображення розміщені на <https://av.canoeboot.org/> і доступні в окремому
сховищі:
git clone https://codeberg.org/vimuser/gbwww-img
git clone https://codeberg.org/canoeboot/cbwww-img
Вносьте будь-які зміни, які забажаєте. Дивіться нотатки нижче про те, як надсилати виправлення.
Весь веб-сайт написаний у Markdown, зокрема його версія Pandoc.
Статичні сторінки HTML створюються за допомогою [Untitled](https://untitled.vimuser.org/).
Лія Роу, засновниця nonGeNUine Boot, також є засновницею проекту генератор статичних сайтів
Лія Роу, засновниця canoeboot, також є засновницею проекту генератор статичних сайтів
Untitled.
Якщо хочете, ви можете налаштувати локальний HTTP-сервер і створити власну локальну
версію веб-сайту. Зауважте, що зображення все одно будуть посилатися на ті, що
розміщені на <https://avgnu.vimuser.org/>, тому будь-які зображення, які ви додаєте до `gbwww-img`
не відображатимуться на вашому локальному сайті `gbwww`, якщо ви зробите, щоб посилання на зображення (для
зображень, які ви додаєте) посилались на `avgnu.vimuser.org`. Однак необхідно, щоб такі
зображення розміщувалися на avgnu.vimuser.org.
розміщені на <https://av.canoeboot.org/>, тому будь-які зображення, які ви додаєте до `cbwww-img`
не відображатимуться на вашому локальному сайті `cbwww`, якщо ви зробите, щоб посилання на зображення (для
зображень, які ви додаєте) посилались на `av.canoeboot.org`. Однак необхідно, щоб такі
зображення розміщувалися на av.canoeboot.org.
Тому, якщо ви бажаєте додати зображення на веб-сайт, надішліть їх також до
репозиторія `gbwww-img`, із посиланням на них
<https://avgnu.vimuser.org/шлях/до/вашого/нового/зображення/в/gbwww-img> для кожного з них.
Коли його буде поєднано на веб-сайті nonGeNUine Boot, ваші зображення з'являться в реальному часі.
репозиторію `cbwww-img`, із посиланням на них
<https://av.canoeboot.org/шлях/до/вашого/нового/зображення/в/cbwww-img> для кожного з них.
Коли його буде поєднано на веб-сайті canoeboot, ваші зображення з'являться в реальному часі.
Якщо додаєте світлину, стисніть її для веб розповсюдження. Світлинам варто бути приблизно
800px завширшки, і зазвичай менше 100Кбайт розміром:
По-перше, зменшіть масштаб вашого зображення до приблизно 800px завширшки, використовуючи вашу улюблену
програму маніпуляції зображенням. Наприклад, з `imagemagick` ви можете зробити
наступне (переконайтесь, що зображення не є вже меншим або еквівалентним, ніж віддано перевагу).
convert original.jpg -resize 600000@ -quality 70% web.jpg
Вам варто завжди виконувати `jpegoptim` на jpg зображеннях перед їх поданням.
Воно вирізає безкорисні метадані та оптимізує *без втрат* їх більше, розумно
переорганізовуючи таблиці Гаффмана, що використані в них.
jpegoptim -s --all-progressive web.jpg
Якщо зображення є (штриховим) малюнком, векторній графіці віддається перевага в порівнянні з бітовою картою.
Таким чином, якщо можливо, зберігайте їх як SVG. Їх легко модифікувати,
і точно зробить роботу перекладачів легше так само.
Зображенням PNG варто бути оптимізованими з `zopfli` (він так само без втрат).
Наприклад, це зменшило логотип завантаження Canoeboot з приблизно 11k до 3k:
zopflipng -ym image.png image.png
Для цілей розробки ви можете спочатку створити локальні посилання на зображення, а
потім налаштувати URL-адреси, коли надсилатимете документацію/патчі веб-сайту.
На веб-сайті Untitled є інструкції щодо налаштування локальної версії
веб-сайту. Завантажте untitled, і в своєму каталозі `untitled` створіть каталог
під назвою `www/`, потім увійдіть у каталог www і клонуйте сховище `gbwww`
під назвою `www/`, потім увійдіть у каталог www і клонуйте сховище `cbwww`
там. Налаштуйте локальний HTTP-сервер відповідним чином.
Знову ж таки, інструкції для цього доступні на веб-сайті Untitled.
@ -125,8 +130,8 @@ Untitled.
учасника.
У Git для імені автора та електронної адреси вам не потрібно використовувати
ідентифікаційні дані. Ви можете використовувати `nongenuineboot Contributor`, а свою електронну адресу можна
вказати як john@doe.com. Вам дозволено це робити, якщо
ідентифікаційні дані. Ви можете використовувати `canoeboot Contributor`, а свою електронну адресу можна
вказати як contributor@canoeboot.org. Вам дозволено це робити, якщо
ви бажаєте зберегти конфіденційність. Ми віримо в конфіденційність. Якщо ви вирішите залишитися
анонімними, ми врахуємо це.
@ -146,13 +151,109 @@ Untitled.
Ліцензії (для учасників)
--------
Make sure to freely license your work, under a free license.
Обов'язково вільно ліцензуйте свою роботу, за вільною ліцензією. Canoeboot більше не
встановлює довільні обмеження на те, які ліцензії приймаються, і багато
інших ліцензій вже існує. Ми перевіримо ваш внесок і розкажемо вам, якщо з ним
виникли проблеми (наприклад, немає ліцензії).
*Always* declare a license on your work! Not declaring a license means that
the default, restrictive copyright laws apply, which would make your work
proprietary, subject to all of the same restrictions.
*Завжди* декларуйте ліцензію на свою роботу! Недекларування ліцензії означає, що
за замовчуванням застосовуються обмежувальні закони про авторське право, які зроблять вашу роботу
захищеною власністю, підпадаючи під усі ті самі обмеження.
The Free Software Foundation maintains a handy dandy list, which you can review
here:
Ліцензія MIT є хорошою для початку, і вона є бажаною ліцензією
для всіх нових робіт у Canoeboot, але ми не вибагливі. Canoeboot історично
використовував ліцензування GNU, таке як GPL; багато з цього залишилося, і, ймовірно, залишиться.
Це ваша робота; очевидно, якщо ви використовуєте існуючу роботу,
може мати сенс використовувати ту саму ліцензію для вашого внеску, для сумісності
ліцензії.
<https://www.gnu.org/licenses/license-list.en.html>
Ви можете знайти типові приклади ліцензій
[тут](https://opensource.org/licenses).
Якщо ви *виходите* на основі існуючого твору, важливо, щоб ваша ліцензія (на ваш внесок)
була сумісна з ліцензуванням твору, з якого
ваш був отриманий. Ліцензія MIT хороша, оскільки вона широко сумісна
з багатьма іншими ліцензіями та надає багато свобод (наприклад, свободу
субліцензування), яких немає в інших ліцензіях:
<https://opensource.org/licenses/MIT>
Надсилайте виправлення
------------
Створіть обліковий запис на <https://codeberg.org/> і перейдіть (увійшовши в систему) до
репозиторію, над яким ви хочете працювати. Натисніть *Fork*, і у вашому обліковому записі,
ви матимете власне сховище canoeboot. Клонуйте свій репозиторій, внесіть у нього
будь-які зміни, а потім надішліть їх у свій репозиторій у своєму обліковому
записі на NotABug. Ви також можете зробити це на новій гілці, якщо хочете.
У своєму обліковому записі Codeberg, ви можете перейти до офіційного репозиторія canoeboot
і надіслати запит на отримання. Принцип роботи подібний до інших популярних веб-платформ
Git, якими люди користуються сьогодні.
Ви можете відправити свої патчі туди. Крім того, ви можете увійти на
IRC-канал canoeboot і повідомити канал, які виправлення ви хочете бути переглянутими, якщо у вас
є власне сховище Git з виправленнями.
Після того, як ви подасте Pull Request, розробники canoeboot отримають сповіщення
електронною поштою. Якщо ви не отримаєте достатньо швидкої відповіді від проекту, ви
також можете повідомити проект через канал `#canoeboot` на Libera Chat.
Інший спосіб подати виправлення - це напряму надіслати Лії Роу електронною поштою:
[leah@canoeboot.org](mailto:leah@canoeboot.org) - це адреса електронної пошти проекту Лії.
Однак, для прозорості процесу перевірки коду, ми рекомендуємо на даний момент
використовувати Codeberg.
Дзеркала Git
============
Дзеркала cbmk.git
----------------
Репозиторій `cbmk` містить автоматизовану систему побудови Canoeboot, що
створює випуски Canoeboot (включаючи зібрані образи ROM).
Ви можете виконати `git clone` на будь-якому з цих посилань (посилання є також доступними для натискання,
для перегляду змін в вашому веб-браузері):
* <https://git.sr.ht/~canoeboot/cbmk>
* <https://git.disroot.org/canoeboot/cbmk>
* <https://gitea.treehouse.systems/canoeboot/cbmk>
* <https://0xacab.org/canoeboot/cbmk/>
* <https://framagit.org/canoeboot/canoeboot>
* <https://gitlab.com/canoeboot/cbmk>
* <https://notabug.org/canoeboot/cbmk>
дзеркало cbwww.git
----------------
Репозиторій `cbwww` містить файли Markdown (варіант pandoc), для використання
з [генератором статичних сайтів Untitled](https://untitled.vimuser.org/); це те,
що Canoeboot використовує для надання веб-сторінок HTML, *включаючи* сторінку, яку ви
читаєте прямо зараз!
Ви можете виконати `git clone` на цих посиланнях, та/або натиснути для перегляду змін в вашому
веб-браузері. Дивіться:
* <https://git.sr.ht/~canoeboot/cbwww>
* <https://git.disroot.org/canoeboot/cbwww>
* <https://gitea.treehouse.systems/canoeboot/cbwww>
* <https://0xacab.org/canoeboot/cbwww>
* <https://framagit.org/canoeboot/cbwww/>
* <https://gitlab.com/canoeboot/cbwww>
* <https://notabug.org/canoeboot/cbwww>
дзеркало cbwww-img.git
----------------
Ви можете виконати `git clone` на цих посиланнях, та/або натиснути для перегляду змін в вашому
веб-браузері. Дивіться:
* <https://git.sr.ht/~canoeboot/cbwww-img>
* <https://git.disroot.org/canoeboot/cbwww-img>
* <https://gitea.treehouse.systems/canoeboot/cbwww-img>
* <https://0xacab.org/canoeboot/cbwww-img>
* <https://framagit.org/canoeboot/cbwww-img/>
* <https://gitlab.com/canoeboot/cbwww-img>
* <https://notabug.org/canoeboot/cbwww-img>

73
site/global.css
View File

@ -2,6 +2,9 @@
* This CSS is released under Creative Commons Zero 1.0 Universal license:
* https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
*/
h1,h2,h3,h4{font-weight:normal; font-size:2em}
.specs
{
float: right;
@ -14,13 +17,6 @@
}
@media (max-width:89em)
{
html
{
font-size: 0.95em;
}
}
@media (min-width:90em)
{
html
@ -31,20 +27,30 @@
html
{
background: #fff;
background: #fcfcfc;
color: #222;
font-family: sans-serif;
line-height: 1.4;
}
hr{display:none;}
code,pre, #TOC, a:hover
ul,code,pre, #TOC, a:hover
{
background: #eee;
background: #e2e2e2;
border-radius:0.3em;
}
#TOC{
min-width:25%;
float:left;
margin-right:1.1em;
margin-bottom:1em;
}
ul{padding-left:1em}
a
{
color: #22d;
color: #023595;
}
img,video,iframe,pre
@ -61,6 +67,8 @@ img,video,iframe,pre
text-align :center;
}
#footer{margin-top:1em}
.title>*, span.date
{
display: block;
@ -76,24 +84,6 @@ html, ul, #TOC
display: none;
}
@media (min-width:60em)
{
.title-logo{display:none}
div.title,h1.title {
background:url("/favicon.ico") no-repeat;
background-size:auto 99%;
min-height:2em
}
div.title {background-position:right}
h1.title {padding:0 4em}
#TOC
{
float: left;
margin: 1em;
min-width: 25%;
}
}
.f, .f *
{
position: fixed;
@ -152,3 +142,28 @@ span.fcc
font-size: 0.9em;
}
.fcc p {padding:0; margin: 0}
header ul, #footer ul
{
text-align:center;
margin-top:2em;
margin-bottom:2em;
}
@media (min-width:60em)
{
.title-logo{display:none}
div.title,h1.title {
background:url("/favicon.ico") no-repeat;
background-size:auto 99%;
min-height:2.5em
}
div.title {background-position:right}
h1.title {padding:0 4em; font-size:2.8em; font-weight:normal;}
#TOC
{
float: left;
margin: 1em;
min-width: 25%;
}
}

170
site/global_green.css Normal file
View File

@ -0,0 +1,170 @@
/*
* This CSS is released under Creative Commons Zero 1.0 Universal license:
* https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
*/
/* this green style was experimental, but i scrapped it before publishing
the first canoeboot website. i opted for a lighter theme instead. */
.specs
{
float: right;
}
:not(p)
{
max-width: 85em;
margin: 0 auto;
}
@media (min-width:90em)
{
html
{
font-size: 1.05em;
}
}
html
{
background: #143232;
color: #eee;
font-family: sans-serif;
line-height: 1.4;
}
hr{display:none;}
ul,code,pre, #TOC, a:hover
{
background: #102121;
border-radius:0.3em;
}
#TOC{
min-width:25%;
float:left;
margin-right:1.1em;
margin-bottom:1em;
}
ul{padding-left:1em}
a
{
color: #cfc;
}
img,video,iframe,pre
{
max-width: 100%;
overflow: auto;
}
.title>*, header ul>li, .nav ul>li,
#footer ul>li, .h:hover>*
{
display: inline;
margin: 0.7%;
text-align :center;
}
#footer{margin-top:1em}
.title>*, span.date
{
display: block;
}
html, ul, #TOC
{
padding: 1em;
}
.date, .author, .h a
{
display: none;
}
.f, .f *
{
position: fixed;
max-width: 100%;
max-height: 100%;
top: 50%;
left: 50%;
}
.f *
{
transform: translate(-50%, -50%);
}
.f
{
display: none;
top: 0;
left: 0;
width: 100%;
height: 100%;
background: rgba(0, 0, 0, 0.8);
}
*:focus + .f
{
display: block;
}
img
{
cursor: pointer;
}
.l,.r {
max-width:40%;
margin:1em;
}
.r {
float: right;
}
.l {
float: left;
}
.p {
max-width: 13em;
}
span.fcc
{
background: #fcc;
position: fixed;
bottom: 0;
left: 0;
right: 0;
font-size: 0.9em;
}
.fcc p {padding:0; margin: 0}
header ul, #footer ul
{
text-align:center;
margin-top:2em;
margin-bottom:2em;
}
@media (min-width:60em)
{
.title-logo{display:none}
div.title,h1.title {
background:url("/favicon.ico") no-repeat;
background-size:auto 99%;
min-height:3em
}
div.title {background-position:right}
h1.title {padding:0 4em; font-size:2.5em; font-weight:normal;}
#TOC
{
float: left;
margin: 1em;
min-width: 25%;
}
}

593
site/gnuboot.md Normal file
View File

@ -0,0 +1,593 @@
---
title: Canoeboot vs GNU Boot
x-toc-enable: true
...
If you want to understand the beef Canoeboot has with GNU Boot, please
read the [about page](about.md), the [Libreboot Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html) and tha [GNU Boot article
on libreboot.org](https://libreboot.org/news/gnuboot.html) - all of that energy
has fuelled the creation of this page, and in fact the entire Canoeboot project.
The purpose of Canoeboot is to be superior to GNU Boot, while complying with
all of its policies by providing ROM images and source tarballs adhering to
the GNU Free System Distribution Guidelines, [even though GNU FSDG is
deeply flawed](https://libreboot.org/news/policy.html#problems-with-fsdg); this
page describes precisely how that has been achieved, and it will be updated
over time as Canoeboot continues to develop.
tl;dr as of 26 October 2023, Canoeboot code is about 1 year ahead of GNU Boot
in terms of development, and about 2 years ahead in terms of documentation.
Read on, if you want details. GNU Boot is also known as *gnuboot*.
Canoeboot and GNU Boot are *both* forks of Libreboot, designed to comply with
the GNU Free System Distribution Guidelines. This page is maintained, to show
the differences between these two projects.
This current version of the page pertains to *Canoeboot 20231026*
versus *GNU Boot 0.1 RC*. You can find GNU Boot ("gnuboot") on the GNU Savannah
website.
GNU Boot 0.1 RC based on Libreboot 20220710
===========================================
This fact is very important; nonGeNUine Boot's 20230717 changelog is relative
to Libreboot 20220710, and Canoeboot 20231026's changelog is relative to
nonGeNUine Boot 20230717's changelog.
Therefore, this page will analyse differences in both projects, at these two
points. First, let's analyse GNU Boot, with the tag reset to `0.1-rc1`, which
corresponds to commit ID `a64d284fd798d843133c9d7274bba17bd7837174`. Since GNU
Boot also contains the Libreboot history that it forked from, it contains the
Libreboot 20220710 release tag, so we can do this:
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit 20220710..0.1-rc1
Within the GNU Boot git repository, this would yield the following response:
```
* a64d284 .gitignore: order alphabetically
* 0df4fe5 GRUB: config from HDD/SSD: Add support for gnuboot_grub.cfg
* ce13d22 GRUB: Use GNU Boot logo
* 74b678c GRUB: Say the name GNUBoot in the grub menu
* eeddd2b build/dependencies: debian: adding python-is-python3 to build seabios properly
* 58b8e09 coreboot/fam15h: don't build ada toolchain for generic platforms
* f7c0fec coreboot/fam15h: update code base, deblob, unset CONFIG_STM (see bug #64535)
* de9297f coreboot/fam15h: fix crossgcc acpica build on newer hostcc
* c38348d coreboot/fam15h: fix for gcc/gnat building
* 0d77d99 coreboot/fam15h: fixing binutils not building properly
* b773079 coreboot/default, coreboot/fam15h: use GNU mirror for acpica
* bf17993 Continue Libreboot under the GNU project
```
And that's all. The fam15h-related fixed are actually merged from
the `fsdg20230625` branch of Libreboot, made during July 2023. See:
<https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625>
The other patches are also merged (cherry-picked) from Libreboot! The above
commit log is all that GNU Boot did, for their 0.1 RC1 release.
Therefore, to know the differences between Canoeboot and GNU Boot, I will copy
all items first from the nonGeNUine Boot 20230717 change log, and then the
Canoeboot 20231026 change log, but I will skip those entries that define
features which GNU Boot already has.
On this day, GNU Boot's current commit ID (in the `main` branch)
is `54c6ae497d49c233b654c171978baa77b90ffe17` from 12 October 2023. Most of
the changes since 0.1 RC1 up to that commit are just documentation changes,
and even still, only cherry-picking minor patches here and there that were
already done in Libreboot, in some cases years ago. It's worth noting that
the GNU Boot documentation is based on Libreboot documentation from *late 2021*
or at most, very early 2022.
I don't need to compare documentation, and it would take too long. Their
documentation is *2 years out of date*, what more is there to say?
Now, feature comparisons in the build systems:
Canoeboot 20231026 features that GNU Boot lacks
===============================================
Board support
-------------
Canoeboot has *these* boards fully supported, that GNU Boot currently lacks
support for:
* [Dell Latitude E6400](docs/hardware/e6400.md)
* [ASUS Chromebook Flip C101 (gru-bob)](docs/install/chromebooks.md)
* [Samsung Chromebook Plus (v1) (gru-kevin)](docs/install/chromebooks.md)
Git revisions in Canoeboot 20231026:
------------------------------------
* Coreboot (default): commit ID `d862695f5f432b5c78dada5f16c293a4c3f9fce6`, 12 October 2023
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
* GRUB: commit ID `e58b870ff926415e23fc386af41ff81b2f588763`, 3 October 2023
* SeaBIOS: commit ID `1e1da7a963007d03a4e0e9a9e0ff17990bb1608d`, 24 August 2023
* U-Boot: commit ID `4459ed60cb1e0562bc5b40405e2b4b9bbf766d57`, 2 October 2023
Git revisions in GNU Boot 0.1 RC1:
---------------------------------
* Coreboot (default): commit ID `b2e8bd83647f664260120fdfc7d07cba694dd89e`, 17 November 2021
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 25 October 2021
* SeaBIOS: commit ID `1281e340ad1d90c0cc8e8d902bb34f1871eb48cf`, 24 September 2021
* U-Boot: **does not exist** (no ARM/U-Boot support in Libreboot 20220710)
NOTE: GNU Boot *does* support downloading, deblobbing and re-compressing
U-Boot archives, and in fact does a better job of *that* than Canoeboot in
some ways, but it does not yet actually build U-Boot, and it does not boot
U-Boot in any way, on any actual mainboards.
As you can see, Canoeboot's revisions are a lot newer.
GRUB LUKS2 support with argon2
------------------------------
Canoeboot 20231026 contains a heavily patched version of GRUB, which contains
argon2 support. This allows full decryption of LUKS2 volumes, without having
to switch to different key derivation (PBKDF2) and without needing to use
LUKS1. You can simple use the default LUKS2 setup provided by any distro, and
it will work. More information is available about GRUB cryptomount, in
the [GNU+Linux guide](docs/gnulinux/) - search on that page for LUKS2 or argon2.
GNU Boot completely *lacks* this feature, as of 26 October 2023. It can only
support LUKS2 if the key derivation is downgraded to PBKDF2 (insecure, or to
LUKS1 (also insecure).
For all intentions, the average user cannot have a fully encrypted system on
GNU Boot. They must leave `/boot` unencrypted on GNU+Linux distros.
With Canoeboot, you can have encrypted `/boot` very easily. This is a boon for
security, because it reduces the chance of someone tampering with your data
successfully, and combined with [other steps](docs/gnulinux/grub_hardening.md),
can be used to reduce the risk of evil maid attacks (by making it infeasible).
Serprog support
---------------
Canoeboot can build firmware images for RP2040 and STM32 microcontrollers,
using `pico-serprog` and `stm32-vserprog` respectively. This can be used to
set up an SPI flasher of high quality, but these parts are low-cost.
GNU Boot does not support this feature, as of 26 October 2023.
Simplified command structure
----------------------------
There are *9* shell scripts in Canoeboot 20231026, versus about 50 in GNU
Boot 0.1 RC1, because GNU Boot uses the pre-audit design; Libreboot used to
have lots of very simple scripts, but ended up with a lot of code repetition.
The new lbmk design generalises all of the logic, doing away with the very
hacky logic that existed in the old build system design.
The interface in Canoeboot's build system is much easier to use. For example,
the commands are shorter, and easier to remember. See:
[cbmk maintenance manual](docs/maintain/) tells you everything about the
Canoeboot build system.
GNU Boot doesn't even *have* a maintenance manual, in their version. Their
documentation exists in the same repository as code, but their
version of `docs/maintain/` does not actually contain any instructions,
at least as of commit ID a64d284fd798d843133c9d7274bba17bd7837174 on 17
August 2023.
Better documentation
--------------------
Canoeboot has much better documentation, but this is obvious if you've been
paying attention. As already stated: GNU Boot's documentation is horribly
out of date, even relative to the version of Libreboot that they're using!
(which itself is also horribly out of date)
Canoeboot's build system is smaller
-----------------------------------
Smaller doesn't mean worse; in fact, Canoeboot's build system is more
efficient. It's about 1250 sloc (source lines of code), when counting shell
scripts in the core of the build system. Libreboot, Canoeboot and GNU Boot
build systems all use the same design, written in shell scripts.
1250 sloc in Canoeboot, versus 2111 in gnuboot; gnuboot however lacks many
of the features and improvements that you're about to see below. The
Canoeboot build system does several times as many things, in half
the amount of code! The code is generally just more reliable, less error
prone, and easier to work with, in Canoeboot. GNU Boot uses a very old version
of the Libreboot build system design, from long before I started any massive
audits. There have been *three* Libreboot build system audits in 2023, as
of 26 October 2023.
Three audits, and Canoeboot has inherited the improvements of all of them.
GNU Boot's design is based on the pre-audit lbmk codebase.
Build system / performance improvements in Canoeboot:
* Much stricter, more robust error handling; too many changes to list here, so
check the git log. Also, errors that *are not errors* are no longer treated as
such; nonGeNUine Boot 20230717's build system was actually too strict, sometimes.
* Most logic has been unified in single scripts that perform once type of task
each, instead of multiple scripts performing the same type of talk; for
example, defconfig-based projects now handled with the same scripts, and
preparing trees for them is done the same. These unifications have been done
carefully and incrementally, with great thought so as to prevent *spaghetti*.
The code is clean, and small.
* GitHub is no longer used on main Git repository links, instead only as backup
* Backup repositories now defined, for all main repos under `config/git/`
* Single-tree projects are no longer needlessly re-downloaded when they already
have been downloaded.
* GRUB LUKS2 support now available, with argon2 key derivation; previously, only
PBKDF2 worked so most LUKS2 setups were unbootable in Canoeboot. This is fixed.
* Vastly reduced number of modules in GRUB, keeping only what is required.
* Use `--mtime` and option options in GNU Tar (if it is actually GNU Tar), when
creating Tar archives. This results in partially reproducible source archives,
and consistent hashes were seen in testing, but not between distros.
* Always re-inialitise `.git` within lbmk, for the build system itself, if
Git history was removed as in releases. This work around some build systems
like coreboot that use Git extensively, and are error-prone without it.
* More robust makefile handling in source trees; if one doesn't exist, error
out but also check other makefile name combinations, and only error out if
the command was to actually build.
* ROMs build script: support the "all" argument, even when getopt options are
used e.g. `-k`
* Disabled the pager in `grub.cfg`, because it causes trouble in some
non-interactive setups where the user sees an errant message on the screen
and has to press enter. This fixes boot interruptions in some cases, allowing
normal use of the machine. The pager was initially enabled many years ago,
to make use of cat a bit easier in the GRUB shell, but the user can just
enable the pager themselves if they really want to.
* U-Boot can now be compiled standalone, without using the ROMs build script,
because crossgcc handling is provided for U-Boot now in addition to coreboot.
* All helper scripts are now under `include/`, and main scripts in `script/`,
called by the main `build` script
* Generally purge unused variables in shell scripts
* Simplified initialisation of variables in shell scripts, using the `setvars`
function defined under `include/err.sh`
* Support patch subdirectories, when applying patches. This is done recursively,
making it possible to split up patch files into smaller sets inside sub
directories, per each source tree (or target of each source tree, where a
project is multi-tree within lbmk)
* SPDX license headers now used, almost universally, in all parts of cbmk.
* Files such as those under `config/git` are now
concatenated, traversing recursively through the target directory; files first,
then directories in order, and for each directory, follow the same pattern
until all files are concatenated. This same logic is also used for patches.
This now enables use of subdirectories, in some config/patch directories.
* General code cleanup on `util/nvmutil`
* Git histories are more thoroughly deleted, in third party source trees during
release time.
* Symlinks in release archives are no longer hard copies; the symlinks are
re-created by the release script, because it clones the current lbmk work
directory via Git (local git clone), rather than just using `cp` to copy links.
* Properly output to stderr, on printf commands in scripts where it is either
a warning prior to calling `err`, or just something that belongs on the error
output (instead of standard output).
* Don't use the `-B` option in make commands.
* SECURITY: Use sha512sum (not sha1sum) when verifying certain downloads. This
reduces the chance for collisions, during checksum verification.
* Set GRUB timout to 5s by default, but allow override and set to 10s or 15s
on some mainboards.
* Support both curl and wget, where files are downloaded outside of Git; defer
to Wget when Curl fails, and try each program three times before failing. This
results in more resilient downloading, on wobbly internet connections.
* Don't clone Git repositories into `/tmp`, because it might be a tmpfs with
little memory available; clone into `tmp/gitclone` instead, within lbmk,
and `mv` it to avoid unnecessary additional writes (`mv` is much more efficient
than `cp`, for this purpose).
* Removed unused `target.cfg` handling in vendor scripts, because they use
the concatenated config format instead (they always have).
* Coreboot builds: automatically run make-oldconfig, to mitigate use of raw
coreboot config where a revision was updated but the config was untouched.
This may still result in a confirmation dialog, and it's still recommended
that the configs be updated per revision (or switch them to defconfigs).
* Vastly simplified directory structure; `resources/scripts/` is now `script/`,
and `resources/` was renamed to `config/`; ifd and gbe files were also moved
to `config/ifd/`. Commands are now 1-argument instead of 2, for example
the `./build boot roms` command is now `./build roms`.
* memtest86plus: only build it on 64-bit hosts, for now (32-bit building is
broken on a lot of distros nowadays, and lbmk doesn't properly handle cross
compilation except on coreboot or U-Boot)
* (courtesy of Riku Viitanen) don't use cat on loops that handle lines of text.
Instead, use the `read` command that is built into `sh`, reading each line.
This is more efficient, and provides more robust handling on lines with
spaces in them.
* *ALL* projects now have submodules downloaded at build time, not just multi
tree projects such as coreboot - and a few projects under `config/git` have
had certain `depend` items removed, if a given project already defines it
under `.gitmodules` (within its repository).
* Improved cbutils handling; it's now even less likely to needlessly re-build
if it was already built.
* The release build script no longer archives what was already built, but
instead builds from scratch, creating an archive from source downloads
first before building the ROM archives. This saves time because it enables
a single build test per release, whereas at was previously necessary to test
the Git repository and then the release archive. Testing both is still desired,
but this behaviour also means that whatever is built at release time is
guaranteed to be the same as what the user would build (from archives).
* Improved handling of `target.cfg` files in multi-tree projects coreboot,
SeaBIOS and U-Boot. Unified to all such projects, under one script, and
with improved error handling.
* GRUB payload: all ROM images now contain the same ELF, with all keymaps
inserted. This speeds up the build process, and enables easier configuration
when changing the keyboard layout because less re-flashing is needed.
* Simplified IFD handling on ICH9M platforms (e.g. X200/T400 thinkpads); the
ich9gen utility wasn't needed anymore so ich9utils has been removed, and now
the IFD/GbE files are included pre-assembled (generated by ich9gen). Ich9gen
can still be used, or you can re-generate with coreboot's bincfg; the ifdtool
util can be used to edit IFD and nvmutil (part of Canoeboot) can change MAC
addresses. The ich9utils code was always redundant for the last few years,
especially since 2022 when nvmutil was first written.
* Running as root is now forbidden, for most commands; lbmk will exit with
non-zero status if you try. The `./build dependencies x` commands still work
as root (they're the only commands available as root).
* Enabled memtest86plus on more boards, where it wasn't previously enabled.
* Only enable SeaBIOS as first payload on desktops, but still enable GRUB as
second payload where GRUB is known to work (on each given host). The text
mode and coreboot framebuffer modes are provided in each case, where feasible.
* The `list` command has been mostly unified, making it easier to tell (from
lbmk) what commands are available, without having to manually poke around
under `script/`.
* The `-T0` flag is now used, universally, on xz commands. This makes `xz` run
on multiple threads, greatly speeding up the creation of large tar archives.
* Universally use `-j` in make commands, for multi-threading, but it relies
on `nproc` to get thread count, so this only works if you have `nproc` (you
probably don't, if you run BSD; BSD porting is still on TODO for Canoeboot)
* File names as arguments now universally have quotes wrapped around them, and
similar auditing has been done to all variables used as arguments everywhere
in lbmk. There were cases where multiple arguments were wrongly quoted then
treated as a single argument, and vice versa. This is now fixed.
* Re-wrote `.gitcheck`; now, a global git name/email config is always required.
The only behaviour (setting local config, and unsetting) was quite error-prone
under fault conditions, where cleanup may not have been provided, or when
execution was interrupted, resulting sometimes in accidentally committing
to `lbmk.git` as author named `lbmkplaceholder`.
* The new BSD-like coding style is now used on *all* shell scripts in lbmk. A
few scripts still used the old lbmk coding style, as of audit 2.
* Scripts no longer directly exit with non-zero status, under fault conditions;
instead, `x_` or `err` is used to provide such behaviour. This results in all
exits from lbmk being consolidated to `err`, under fault conditions. - zero
exits are also consolidated, going only through the main script, which has its
own exit function called `lbmk_exit` that provides `TMPDIR` cleanup.
* BSD-style error handling implemented, with an `err` function (and functions
that use it) inside `include/err.sh`; there is also `x_` which can be used
to run a command and exit automatically with non-zero status, useful because
it provides more verbose output than if you just relied on `set -e`, and it
still works when a script *does not* use `set -e` - however, it is not used
on all functions, because it works by executing `$@` directly, which can break
depending on arguments. Therefore, some scripts just default to `|| err` for
providing breakage in scripts.
* Memtest *6.2* now used (instead of *5.x* releases). This is essentially a
re-write, and it works on the coreboot framebuffer, whereas previous revisions
only worked on text mode setups.
* NO MAKEFILE. The Makefile in lbmk has been removed. It was never meaningfully
used because all it did was run lbmk commands, without implementing any logic
itself. A Makefile may be added again in the future, but with a view to
installing *just the build system* onto the host system, to then build ROM
images under any number of directories. Lbmk's design is strictly no-Makefile,
but it uses Makefiles provided by third party source trees when building them.
* Safer GRUB configuration file handling between GRUB memdisk and coreboot CBFS;
it is no longer possible to boot without a GRUB config, because the one in
GRUB memdisk is provided as a failsafe, overridden by *inserting* one in CBFS,
but there is no config in CBFS by default anymore.
* The build system *warns* users about `elf/` vs `bin/`, when it comes to
flashing coreboot ROM images; it tells them to use `bin/` because those
images do contain payloads, whereas the ones under `elf/` do not.
* VASTLY more efficient build process; all coreboot ROMs without payload are
now cached under `elf/`, as are payloads, then they are joined separately by
the usual ROMs build script, and these cached ROMs contain many changes in
them that were previously handled by `moverom` in the main ROM build script.
Under the new design, repetitive steps are avoided; payloads are inserted into
a copy of the cached ROMs under `TMPDIR`, *before* being copied for keymaps
and small files; this eliminates delays caused by slow compression (LZMA is
always used, when inserting payloads). After crossgcc and the payloads are
compiled, the ROM with coreboot builds in under a minute, whereas it would
have previously taken several minutes on most Canoeboot-supported hardware.
* VASTLY reduced GRUB payload size; modules that aren't needed have been removed
resulting in much smaller GRUB payloads, that also boot faster.
* ALL defconfig creation, updating and modification are handled by the same
script that *also* handles compiling, as mentioned in the bullet-point below.
* ALL main source trees are now compiled, downloaded, configured and cleaned
using the same script. The *download* (Git) logic is a separate file
under `include/` and its functions are called by the main build script, which
provides a stub for this.
* Scripts are no longer executed directly, ever, except the main script. All
scripts are otherwise executed from `script/`, inheriting the `TMPDIR`
variable set (and exported) by lbmk.
* Generally improved user feedback in scripts, especially the vendor scripts.
* Coreboot, U-Boot and SeaBIOS are now downloaded, configured and compiled using
the exact same script. Although these codebases differ wildly, their build
systems use the same design, and they are compatible from a user-interface
perspective.
* Vastly improved `/tmp` handling; a universal `TMPDIR` is set (environmental
variable) and exported to all child processes running lbmk scripts. On exit,
the main tmp directory is purged, cleaning all tmp directories under it.
* General simplification of coding style on all shell scripts.
* Fixed some variable initialisations in the coreboot ROM image build script
* Don't enable u-boot on QEMU x86 images (due to buggy builds, untested)
* Fixed coreboot-version file inserted into coreboot trees, when compiled
on Canoeboot release archives.
* Very general auditing has been done, finding and fixing bugs.
* Reduced the number of scripts significantly. There were about 50 scripts in
the nonGeNUine Boot 20230717 build system. There are closer to *20* in today's
Canoeboot 20231026 revision.
* Many scripts that were separate are now unified. For example: the scripts
handling defconfigs files on SeaBIOS, u-Boot and coreboot have now been
merged into a single script, performing the same work *better* in less code.
* Ditto many other scripts; repeated logic unified, logic generalised. The
logic for *downloading* coreboot and u-boot was unified into one script,
basing off of the coreboot one, and then expanding to also cover SeaBIOS.
Most building (e.g. handling of Makefiles) is now done in a single script.
* Far superior error handling; in many scripts, the `-e` option in `sh` was
heavily relied upon to catch errors, but now errors are handled much more
verbosely. *Many* fault conditions previously did not make lbmk *exit* at all,
let alone with non-zero status, and zero status was sometimes being returned
under some edge cases that were tested. Error handling is more robust now.
* `util/ich9utils` (containing `ich9gen`) was *removed*, thus eliminating about
3000 source lines (of C code) from lbmk. The `nvmutil` program, also provided
by and originating from the Canoeboot project, can already change GbE MAC
addresses. Coreboot's bincfg can generate ich9m descriptors, and ifdtool can
manipulate them; so the features provided by ich9utils were superfluous, since
they are available in other projects that we ship. We now ship pre-built
ifd/gbe configs on these machines, which can be modified or re-assembled
manually if you want to. This eliminates a moving part from Canoeboot, and
speeds up the build a little bit.
* ROM images (of coreboot) build *much faster*: no-payload coreboot ROMs are
cached on disk, as are payloads, where previously only the latter was cached.
These cached images have as much inserted into them as possible, to eliminate
redundant steps in the build process. The `elf` directory contains these, and
the existing `bin` directory still holds the full ROM images (containing
payloads) when compiled.
* GRUB payload: vastly reduced the size of the payload, by eliminating GRUB
modules that were not needed. About 100KB of compressed space saved in flash!
* GRUB payload: [argon2 key derivation supported](argon2.md) - this means LUKS2
decryption is now possible in GRUB. This work was performed by Nicholas
Johnson, rebasing from Axel's AUR patch for GRUB 2.06 (Canoeboot currently
uses GRUB 2.12).
* The *new* coding style is now used on many more scripts, including
the `build/boot/roms_helper` script - the new style is much cleaner,
mandating that logic be top-down, with a `main()` function defined; it's
basically inspired by the OpenBSD coding style for C programs, adapted to
shell scripts.
* All GRUB keymaps now included; a single `grub.elf` is now used on all ROM
images. The `grub.cfg` goes in GRUB memdisk now, but can be overridden by
inserting a `grub.cfg` in CBFS; many behaviours are also controlled this way,
for example to change keymaps and other behaviours. This results in *much*
faster builds, because a different GRUB payload doesn't have to be added to
each new ROM image; such takes time, due to time-expensive LZMA compression.
This, plus the optimised set of GRUB modules, also makes GRUB itself load
much faster. All of the fat has been trimmed, though still quite a lot more
than a Crumb.
* A lot of scripts have been removed entirely, and their logic not replaced;
in many cases, Canoeboot's build system contained logic that had gone unused
for many years.
* More reliable configs now used on desktop mainboards: SeaBIOS-only for start,
but GRUB still available where feasible (in the SeaBIOS menu). This makes it
more fool proof for a user who might use integrated graphics and then switch
to a graphics card; the very same images will work.
* TMPDIR environmental variable now set, and exported from main parent process
when running lbmk; child processes inherit it, and a single tmp dir is used.
This is then automatically cleaned, upon exit from lbmk; previously, lbmk did
not cleanly handle `/tmp` at all, but now it's pretty reliable.
* A [HUGE build system audit](https://libreboot.org/news/audit.html) inherited
from Libreboot, is part of the Canoeboot tree; the entire build system was
re-written in a much cleaner coding style, with much stricter error handling
and clear separation of logic. A *lot* of bugs were fixed. A *LOT* of bugs.
Build system auditing has been the *main* focus, in these past 12 months.
* `cros`: Disable coreboot-related BL31 features. This fixes poweroff on gru
chromebooks. Patch courtesy of Alper Nebi Yasak.
* `u-boot`: Increase EFI variable buffer size. This fixes an error where
Debian's signed shim allocates too many EFI variables to fit in the space
provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
* Coreboot build system: don't warn about no-payload configuration. nonGeNUine Boot
compiles ROM images *without* using coreboot's payload support, instead it
builds most payloads by itself and inserts them (via cbfstool) afterwards.
This is more flexible, allowing greater configuration; even U-Boot is
handled this way, though U-Boot at least still uses coreboot's crossgcc
toolchain collection to compile it. Patch courtesy Nicholas Chin.
* `util/spkmodem-recv`: New utility, forked from GNU's implementation, then
re-written to use OpenBSD style(9) programming style instead of the
originally used GNU programming style, and it is uses
OpenBSD `pledge()` when compiled on OpenBSD. Generally much cleaner coding
style, with better error handling than the original GNU version (it is forked
from coreboot, who forked it from GNU GRUB, with few changes made). This
is a receiving client for spkmodem, which is a method coreboot provides to
get a serial console via pulses on the PC speaker.
* download/coreboot: Run `extra.sh` directly from given coreboot tree. Unused
by any boards, but could allow expanding upon patching capabilities in lbmk
for specific mainboards, e.g. apply coreboot gerrit patches in a specific
order that is not easy to otherwise guarantee in more generalised logic of
the nonGeNUine Boot build system.
* `util/e6400-flash-unlock`: New utility, that disables flashing protections
on Dell's own BIOS firmware, for Dell Latitude E6400. This enables nonGeNUine Boot
installation *without* disassembling the machine (external flashing equipment
is *not required*). Courtesy Nicholas Chin.
* Build dependencies scripts updated for more modern distros. As of this day's
release, nonGeNUine Boot compiles perfectly in bleeding edge distros e.g. Arch
Linux, whereas the previous 20220710 required using old distros e.g.
Debian 10.
* `cbutils`: New concept, which implements: build coreboot utilities like
cbfstool and include the binaries in a directory inside lbmk, to be re-used.
Previously, they would be compiled in-place within the coreboot build system,
often re-compiled needlessly, and the checks for whether a given util are
needed were very ad-hoc: now these checks are much more robust.
Very centralised approach, per coreboot tree, rather than selectively
compiling specific coreboot utilities, and makes the build system logic in
nonGeNUine Boot much cleaner.
* GRUB config: 30s timeout by default, which is friendlier on some desktops
that have delayed keyboard input in GRUB.
* ICH9M/GM45 laptops: 256MB VRAM by default, instead of 352MB. This fixes
certain performance issues, for some people, as 352MB can be very unstable.
* U-Boot patches: for `gru_bob` and `gru_kevin` chromebooks, U-Boot is used
instead of Google's own *depthcharge* bootloader. It has been heavily
modified to avoid certain initialisation that is replaced by coreboot, in
such a way that U-Boot is mainly used as a bootloader providing UEFI for
compliant GNU+Linux distros and BSDs. Courtesy Alper Nebi Yasak.
* lbmk: The entire nonGeNUine Boot build system has, for the most part, been made
portable; a lot of scripts now work perfectly, on POSIX-only implementations
of `sh` (though, many dependencies still use GNU extensions, such as GNU
Make, so this portability is not directly useful yet, but a stepping stone.
nonGeNUine Boot eventually wants to be buildable on non-GNU, non-GNU/Linux systems,
e.g. BSD systems)
* nvmutil: Lots of improvements to code quality, features, error handling. This
utility was originally its own project, started by Leah Rowe, and later
imported into the nonGeNUine Boot build system.
* build/boot/roms: Support cross-compiling coreboot toolchains for ARM platforms,
in addition to regular x86 that was already supported. This is used for
compiling U-boot as a payload, on mainboards.
* U-boot integration: at first, it was just downloading U-Boot. Board integration
for ARM platforms (from coreboot) came later, e.g. ASUS Chromebook Flip C101
as mentioned above. The logic for this is forked largely from the handling
of coreboot, because the interface for dealing with their build systems is
largely similar, and they are largely similar projects. Courtesy Denis Carikli
and Alper Nebi Yasak.
* New utility: `nvmutil` - can randomise the MAC address on Intel GbE NICs, for
systems that use an Intel Flash Descriptor
* General build system fixes: better (and stricter) error handling
* Fixed race condition when building SeaBIOS in some setups.
* GRUB configs: only scan ATA, AHCI or both, depending on config per board.
This mitigates performance issues in GRUB on certain mainboards, when
scanning for `grub.cfg` files on the HDD/SSD.
* GRUB configs: speed optimisations by avoiding slow device enumeration in
GRUB.
Summary
=======
Now, does this mean Canoeboot is *good*? The answer is an emphatic no. It only
means that Canoeboot is far superior to GNU Boot, on a technical level.
Canoeboot is still *inferior* to Libreboot, for all of the reasons laid out in
the [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html) - the
Canoeboot project is provided, specifically, to prove the merits of that policy,
by showing what Libreboot would have been by now if it continued adhering to
GNU policy, instead of changing to its current Blob Reduction Policy.
So, in conclusion: this page is not trying to tell you why you should use
Canoeboot; rather, it's just telling you that someone worse exists.
Libreboot provides all of the same blob-free configurations as Canoeboot, when
possible on any given mainboard, and that is the preference, but the FSF/GNU
dogma states that the user must never run any proprietary software. This dogma
is wrong; a more correct approach is to say that proprietary software is bad,
because it restricts the user's freedom to study and modify the software; it
removes their power to say no when the developer wants to change the program in
a bad way, it leaves them at the mercy of that developer - the point is this:
Free software is good, and we should be promoting as much of it as possible.
This means that a hardline no-blob approach like the policy implemented by
Canoeboot (or GNU Boot for that matter), is entirely misguided, because it
will only alienate those who just want *some* free software. Most people like
the idea of software freedom but cannot go all the way yet; we should encourage
people to make the right choices, but otherwise just help them in whatever way
we can, meeting people where they're at right now.
And that is why Libreboot exists in the way that it does. Canoeboot serves as an
example of what would happen in the best-case scenario if Libreboot never changed
its policy. That best case scenario is still inferior to Libreboot. Canoeboot
is missing a ton of boards and features from Libreboot. you can see that
by reading the Canoeboot 20231026 and nonGeNUine Boot 20230717 change logs.
Actual summary
==============
[Install Libreboot](https://libreboot.org/).

59
site/index.de.md
View File

@ -1,74 +1,89 @@
---
title: nonGeNUine Boot
title: Canoeboot projekt
x-toc-enable: true
...
Das *nonGeNUine Boot* Projekt bietet
eine [freie](https://www.gnu.org/philosophy/free-sw.html) *Boot
Das *Canoeboot* Projekt bietet
eine [freie](https://writefreesoftware.org/learn) *Boot
Firmware* welche auf [bestimmten Intel/AMD x86 und ARM Geräten](docs/hardware/)
die Hardware initialisiert (z.b. Speicher-Controller, CPU, Peripherie),
und dann einen Bootloader für dein Betriebssystem startet. [GNU+Linux](docs/gnulinux/)
sowie [BSD](docs/bsd/) werden gut unterstützt. Es ersetzt proprietäre BIOS/UEFI
Firmware.
Firmware. Hilfe ist verfügbar
via [\#canoeboot](https://web.libera.chat/#canoeboot)
und [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://avgnu.vimuser.org/t500/0005.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0005.jpg" /></span>
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**NEUESTE VERSION: Die neueste Version von nonGeNUine Boot ist 20230717, veröffentlicht am
17. July 2023.
Siehe auch: [nonGeNUine Boot 20230717 release announcement](news/nongenuineboot20230717.md).**
**NEUESTE VERSION: Die neueste Version von Canoeboot ist 20231026, veröffentlicht
am 26. Oktober 2023.
Siehe auch: [Canoeboot 20231026 release announcement](news/canoeboot20231026.md).**
Warum solltest Du *nonGeNUine Boot* verwenden?
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
Warum solltest Du *Canoeboot* verwenden?
----------------------------
nonGeNUine Boot gibt dir [Freiheit](https://www.gnu.org/philosophy/free-sw.html) welche
Canoeboot gibt dir [Freiheit](https://writefreesoftware.org/learn) welche
Du mit den meisten Boot Firmwares nicht hast, und zusätzlich schnellere Boot
Geschwindigkeiten sowie [höhere Sicherheit](docs/gnulinux/grub_hardening.md).
Es ist extrem leistungsfähig und für viele Einsatzzwecke [konfigurierbar](docs/maintain/).
Du hast Rechte. Das Recht auf Privatsphäre, Gedankenfreiheit, Meinungsäußerungsfreiheit,
und Informationsfreiheit. In diesem Zusammenhang, nonGeNUine Boot gibt dir diese Rechte.
und Informationsfreiheit. In diesem Zusammenhang, Canoeboot gibt dir diese Rechte.
Deine Freiheit ist wichtig.
[Das Recht auf Reparatur](https://yewtu.be/watch?v=Npd_xDuNi9k) ist wichtig.
Viele Menschen verwenden proprietäre (non-libre)
Boot Firmware, sogar wenn Sie ein [Libre OS](https://www.gnu.org/distros/) verwenden.
Boot Firmware, sogar wenn Sie ein [Libre OS](https://www.openbsd.org/) verwenden.
Proprietäre Firmware [enthält](faq.html#intel) häufig [Hintertüren](faq.html#amd),
und kann fehlerhaft sein. Das nonGeNUine Boot Projekt wurde im July 2023 gegründet,
und kann fehlerhaft sein. Das Canoeboot Projekt wurde im Oktober 2023 gegründet,
mit dem Ziel, Coreboot Firmware auch für technisch unerfahrene Nutzer verfügbar
zu machen.
Das nonGeNUine Boot Projekt verwendet [Coreboot](https://www.coreboot.org/) für
Das Canoeboot Projekt verwendet [Coreboot](https://www.coreboot.org/) für
[die Initialiserung der Hardware](https://doc.coreboot.org/getting_started/architecture.html).
Die Coreboot Installation ist für unerfahrene Benutzer überaus schwierig; sie
übernimmt lediglich die Basis Initialisierung und springt dann zu einem separaten
[payload](https://doc.coreboot.org/payloads.html) Programm (z.B.
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), welche zusätzlich konfiguriert werden muss.
*nonGeNUine Boot löst dieses Problem*; es ist eine *Coreboot Distribution* mit
*Canoeboot löst dieses Problem*; es ist eine *Coreboot Distribution* mit
einem [automatisierten Build System](docs/build/) welches vollständige *ROM images*
für eine robustere Installation erstellt.
Dokumentation ist verfügbar.
nonGeNUine Boot ist kein Coreboot Fork
Canoeboot ist kein Coreboot Fork
-----------------------------------
<img tabindex=1 class="l" style="max-width:15%;" src="https://avgnu.vimuser.org/dip8/adapter.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/dip8/adapter.jpg" /></span>
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
Tatsächlich versucht nonGeNUine Boot so nah am regulären Coreboot zu bleiben wie möglich,
für jedes Board, aber mit vielen automatisch durch das nonGeNUine Boot Build System zur
Tatsächlich versucht Canoeboot so nah am regulären Coreboot zu bleiben wie möglich,
für jedes Board, aber mit vielen automatisch durch das Canoeboot Build System zur
Verfügung gestellten verschiedenen Konfigurationstypen.
Ebenso wie *Trisquel GNU+Linux* eine *GNU+Linux Distribution* ist, ist nonGeNUine Boot eine
Ebenso wie *Alpine Linux* eine *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
möchtest um das ROM Image vorzubereiten. Mithilfe von *nonGeNUine Boot* kannst Du
möchtest um das ROM Image vorzubereiten. Mithilfe von *Canoeboot* kannst Du
sprichwörtlich von Git oder einem anderen Quell-Archiv herunterladen, anschliessend
`make` ausführen, und es wird komplette ROM Images herstellen, ohne das Benutzer
Eingaben oder Eingreifen von Nöten sind. Die Konfiguration wurde bereits im
Vorfeld erledigt.
Sofern Du das reguläre Coreboot herstellen wollen würdest, ohne hierfür das automatisierte
nonGeNUine Boot Build System zu verwenden, würde dies deutlich mehr Eingreifen und ein
Canoeboot Build System zu verwenden, würde dies deutlich mehr Eingreifen und ein
sehr tiefgreifendes technisches Verständnis voraussetzen um eine funktionsfähige
Konfiguration herzustellen.

61
site/index.fr.md
View File

@ -1,74 +1,89 @@
---
title: nonGeNUine Boot
title: Projet Canoeboot
x-toc-enable: true
...
nonGeNUine Boot est un micrologiciel de démarrage [libéré](https://www.gnu.org/philosophy/free-sw.html)
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/hardware/)
et lance un chargeur d'amorçage pour votre système d'exploitation. [GNU+Linux](docs/gnulinux/) 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/).
<img tabindex=1 class="r" src="https://avgnu.vimuser.org/t500/0005.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0005.jpg" /></span>
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**NOUVELLE VERSION: La dernière version est [nonGeNUine Boot 20230717](news/nongenuineboot20230717.md), sortie
le 17 Juillet 2023.**
**NOUVELLE VERSION: La dernière version est [Canoeboot 20231026](news/canoeboot20231026.md), sortie
le 26 octobre 2023.**
Pourquoi devriez-vous utiliser *nonGeNUine Boot*?
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
Pourquoi devriez-vous utiliser *Canoeboot*?
-----------------------------------
nonGeNUine Boot vous donne des [libertés](https://www.gnu.org/philosophy/free-sw.html)
Canoeboot vous donne des [libertés](https://writefreesoftware.org/learn)
que nous n'auriez pas autrement avec d'autre micrologiciel de démarrage. Il est
extremement [puissant](docs/gnulinux/grub_hardening.md)
et [configurable](docs/maintain) pour plein de cas d'utilisations.
Vous avez des droits. Un droit à la vie privée, liberté de pensée, liberté d'espression et le droit de lire. Dans ce contexte là, nonGeNUine Boot vous permet d'avoir ces droits.
Vous avez des droits. Un droit à la vie privée, liberté de pensée, liberté d'espression et le droit de lire. Dans ce contexte là, Canoeboot vous permet d'avoir ces droits.
Votre liberté compte.
Le [Droit à la réparation](https://yewtu.be/watch?v=Npd_xDuNi9k) est important.
Beaucoup de personnes utilisent un micrologiciel de
démarrage propriétare (non libre), même
si ils utilisent [un système d'exploitation libre](https://www.gnu.org/distros/).
si ils utilisent [un système d'exploitation libre](https://www.openbsd.org/).
Les micrologiciels propriétaires [contiennent](faq.html#intel) souvent
des [portes dérobées](faq.html#amd) et peuvent être instable. nonGeNUine Boot
a été fondé en July 2023 avec le but de rendre le libre
des [portes dérobées](faq.html#amd) et peuvent être instable. Canoeboot
a été fondé en Octobre 2023 avec le but de rendre le libre
au niveau du micrologiciel accessible pour les utilisateurs non-techniques.
nonGeNUine Boot utilise [coreboot](https://www.coreboot.org) pour
Canoeboot utilise [coreboot](https://www.coreboot.org) pour
[l'initialisation matérielle](https://doc.coreboot.org/getting_started/architecture.html)
Coreboot est renommé comme être difficilement installable par des utilisateurs
non technique; il se charge seulement de l'initialisation basique
puis bascule sur un programme de [charge utile](https://doc.coreboot.org/payloads.html)
(par ex. [GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), qui doit lui aussi être configuré.
*nonGeNUine Boot règle ce problème*; c'est une *distribution de coreboot* avec
*Canoeboot règle ce problème*; c'est une *distribution de coreboot* avec
un [système de compilation automatisé](docs/builds/), crééant des
*images ROM* complètes pour une installation plus robuste. De la documentation est disponible.
De quelle façon nonGeNUine Boot diffère de Coreboot?
De quelle façon Canoeboot diffère de Coreboot?
------------------------------------------------
<img tabindex=1 class="l" style="max-width:15%;" src="https://avgnu.vimuser.org/dip8/adapter.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/dip8/adapter.jpg" /></span>
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
Contrairement à l'opinion populaire, le but principal de nonGeNUine Boot n'est
Contrairement à l'opinion populaire, le but principal de Canoeboot n'est
pas de fournir un Coreboot déblobbé; ceci n'est simplement qu'une
des politiques de nonGeNUine Boot, une importante certes, mais qui n'est qu'un
aspect mineur de nonGeNUine Boot.
des politiques de Canoeboot, une importante certes, mais qui n'est qu'un
aspect mineur de Canoeboot.
De la même façon que *Trisquel GNU+Linux* est une distribution GNU+Linux, nonGeNUine Boot
De la même façon que *Alpine Linux* est une distribution 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
afin de préparer la ROM. Avec *nonGeNUine Boot*,
afin de préparer la ROM. Avec *Canoeboot*,
vous pouvez télécharger la source depuis Git ou une archive, exécuter
`make` etça compilera une image ROM entières. Le système de compilation
automatisé de nonGeNUine Boot nommé `gbmk` (non**G**eNUine**B**oot**M**a**K**e), compile ces images
automatisé de Canoeboot nommé `cbmk` (Canoeboot MaKe), compile ces images
ROM automatiquement, sans besoin d'entrées utilisateur or intervention
requise. La configuration est faite à l'avance.
Si vous devriez compiler du coreboot classique sans utiliser le système
de build automatisé de nonGeNUine Boot, ça demanderait bien plus d'effort et
de build automatisé de Canoeboot, ça demanderait bien plus d'effort et
de connaissances techniques décente pour écrire une configuration qui marche.
Les versions de nonGeNUine Boot fournissent ces images ROM pré-compilés et vous
Les versions de Canoeboot fournissent ces images ROM pré-compilés et vous
pouvez les installez simplement, sans connaissance ou compétence particulière
à savoir, sauf [suivre des instructions simplifiés écrite pour des utilisateurs non techniques](docs/install/).

87
site/index.it.md Normal file
View File

@ -0,0 +1,87 @@
---
title: Progetto Canoeboot
x-toc-enable: true
...
Il progetto *Canoeboot* fornisce avvio [libero e open source](https://writefreesoftware.org/learn)
grazie al firmware basato su coreboot, sostituendo cosi', firmware BIOS/UEFI proprietario
su [alcune schede madri basate su Intel/AMD x86 o ARM](docs/hardware/),
in computer fissi e portatili. Inizializza l'hardware (controller di
memoria, CPU, periferiche) e avvia un bootloader per il tuo sistema operativo.
[GNU+Linux](docs/gnulinux/) 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/).
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**ULTIMO RILASCIO: L'ultimo rilascio e' Canoeboot 20231026, rilasciato il 26 ottobre 2023.
Vedi: [Canoeboot 20231026 annuncio di rilascio](news/canoeboot20231026.md).**
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
Per quale ragione utilizzare *Canoeboot*?
-----------------------------------------
Canoeboot ti permette [liberta'](https://writefreesoftware.org/learn) che non potresti ottenere
con altri firmware di boot, velocita' di avvio maggiori
e [migliore sicurezza](docs/gnulinux/grub_hardening.md).
E' estremamente flessibile e [configurabile](docs/maintain/) per la maggior parte dei casi.
*Noi* crediamo nella liberta' di [studiare, condividere, modificare and usare
il software](https://writefreesoftware.org/), senza restrizione alcuna,
in quanto e' uno dei fondamentali diritti umani che chiunque deve avere.
In questo contesto, *il software libero* conta. La tua liberta' conta. La formazione personale conta.
[Il diritto di riparare](https://yewtu.be/watch?v=Npd_xDuNi9k) conta.
Molte persone usano firmware di boot proprietario (non-libero), anche se usano
[un sistema operativo libero](https://www.openbsd.org/).
Firmware proprietari spesso [contengono](faq.html#intel) [vulnerabilita'](faq.html#amd),
e possono essere difettosi. Il progetto canoeboot venne fondato nel ottobre 2023, con lo scopo
prefissato di permettere che il firmware coreboot sia accessibile anche
per utenti con scarsa formazione tecnica.
Il progetto Canoeboot fa uso di [coreboot](https://www.coreboot.org/) per
[l'inizializzazione hardware](https://doc.coreboot.org/getting_started/architecture.html).
Coreboot e' notoriamente difficile da installare per utenti che hanno una scarsa formazione tecnica;
gestisce solo l'inizializzazione di base e successivamente carica un programma come
[payload](https://doc.coreboot.org/payloads.html) (ad esempio.
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), i quali possono essere configurati a piacere.
*Canoeboot risolve questo problema*; e' una *distribuzione di coreboot* con un
[sistema di compilazione automatizzato](docs/build/) che produce *immagini ROM* complete, per una
installazione piu' robusta. Viene fornito con apposita documentazione.
Canoeboot non deriva da coreboot
--------------------------------
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
In effetti, Canoeboot tenta di essere il piu' possibile simile alla versione *ufficiale* di coreboot,
per ogni scheda, ma con diversi tipi di configurazione forniti automaticamente dal sistema di
compilazione automatico di Canoeboot.
Esattamente come *Alpine Linux* e' una *distribuzione 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`,
e questo mettera' su automaticamente le immagini ROM richieste. Un sistema di compilazione automatico,
chiamato `cbmk` (Canoeboot MaKe), mettera' su quelle immagini ROM automaticamente, senza troppi
interventi da parte dell'utente. Le configurazioni di base sono gia' state previste in precedenza.
Se avresti voluto compilare coreboot normalmente senza il sistema di compilazione
automatico di Canoeboot, ti troveresti ad affrontare molte piu' difficolta senza adeguate competenze
tecniche per produrre una configurazione funzionante.
I rilasci binari di Canoeboot forniscono immagini ROM precompilate,
che puoi semplicemente installare senza troppe conoscenze tecniche o abilita'
particolari ad eccezione del seguire [semplici istruzioni scritte per chiunque](docs/install/).

84
site/index.md
View File

@ -1,83 +1,99 @@
---
title: nonGeNUine Boot
title: Canoeboot project
x-toc-enable: true
...
The *nonGeNUine Boot* ([formerly](news/nongenuineboot20230717.md#update-21-july-2023)
the unofficial *GNU Boot* or *gnuboot*) project provides 100%
[free](https://www.gnu.org/philosophy/free-sw.html) (*libre*) boot
The *Canoeboot* project provides
[free, open source](https://writefreesoftware.org/learn) (*libre*) boot
firmware based on coreboot, replacing proprietary BIOS/UEFI firmware
on [specific Intel/AMD x86 and ARM based motherboards](docs/hardware/),
including laptop and desktop computers. It initialises the hardware (e.g. memory
controller, CPU, peripherals) and starts a bootloader for your operating
system. [GNU+Linux](docs/gnulinux/) and [BSD](docs/bsd/) are well-supported.
This project is a proof of concept, intended for re-use by the [GNU
Boot](https://libreboot.org/news/gnuboot.html) (or *gnuboot*) project.
system. [GNU Linux](docs/gnulinux/) and [BSD](docs/bsd/) are well-supported. Help is
available via [\#canoeboot](https://web.libera.chat/#canoeboot)
on [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://avgnu.vimuser.org/t500/0005.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0005.jpg" /></span>
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**NEW RELEASE: The latest release is nonGeNUine Boot 20230717, released on
17 July 2023 (as *unofficial* GNU Boot, later re-branded to nonGeNUine
Boot [on 21 July 2023](news/nongenuineboot20230717.md#update-21-july-2023)) -
See: [nonGeNUine Boot 20230717 release announcement](news/nongenuineboot20230717.md).**
**NEW RELEASE: The latest release is Canoeboot 20231026, released on
26 October 2023.
See: [Canoeboot 20231026 release announcement](news/canoeboot20231026.md).**
Why should you use *nonGeNUine Boot*?
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
Why should you use *Canoeboot*?
----------------------------
nonGeNUine Boot gives you [freedoms](https://www.gnu.org/philosophy/free-sw.html) that
Canoeboot gives you [freedoms](https://writefreesoftware.org/learn) that
you otherwise can't get with most other boot firmware, plus faster boot speeds
and [better security](docs/gnulinux/grub_hardening.md). It's extremely powerful
and [configurable](docs/maintain/) for many use cases.
We *remove* binary blobs from coreboot and U-Boot, in line with the [GNU Free
System Distribution Guidelines (GNU
FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html).
and [configurable](docs/maintain/) for many use cases. Canoeboot is a *special
fork* of Libreboot, maintained in parallel to it by the same developer (Leah
Rowe); Canoeboot complies with the GNU Free System Distribution Guidelines,
whereas Libreboot adopts a more pragmatic [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html). Consequently, *Canoeboot* only
supports a very limited subset of hardware from coreboot that is known to boot
without binary blobs. Many other boards in coreboot require binary blobs for
things like memory controller initialisation. Canoeboot *removes* binary blobs
from coreboot and U-Boot, which are then provided "de-blobbed" in releases.
*We* believe the freedom to [study, share, modify and use
software](https://www.gnu.org/philosophy/free-sw.html), without any
software](https://writefreesoftware.org/), without any
restriction, is one of the fundamental human rights that everyone must have.
In this context, *software freedom* matters. Your freedom matters. Education
matters.
[Right to repair](https://yewtu.be/watch?v=Npd_xDuNi9k) matters.
Many people use proprietary (non-libre)
boot firmware, even if they use [a libre OS](https://www.gnu.org/distros/).
boot firmware, even if they use [a libre OS](https://www.openbsd.org/).
Proprietary firmware often [contains](faq.html#intel) [backdoors](faq.html#amd),
and can be buggy. The nonGeNUine Boot project was founded in July 2023, with the
and can be buggy. The Canoeboot project was founded in October 2023, with the
express purpose of making coreboot firmware accessible for non-technical users.
The nonGeNUine Boot project uses [coreboot](https://www.coreboot.org/) for [hardware
The Canoeboot project uses [coreboot](https://www.coreboot.org/) for [hardware
initialisation](https://doc.coreboot.org/getting_started/architecture.html).
Coreboot is notoriously difficult to install for most non-technical users; it
handles only basic initialization and jumps to a separate
[payload](https://doc.coreboot.org/payloads.html) program (e.g.
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), which must also be configured.
*nonGeNUine Boot solves this problem*; it is a *coreboot distribution* with
*Canoeboot solves this problem*; it is a *coreboot distribution* with
an [automated build system](docs/build/) that builds complete *ROM images*, for
more robust installation. Documentation is provided.
nonGeNUine Boot is not a fork of coreboot
Canoeboot is not a fork of coreboot
-----------------------------------
<img tabindex=1 class="l" style="max-width:15%;" src="https://avgnu.vimuser.org/dip8/adapter.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/dip8/adapter.jpg" /></span>
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
In fact, nonGeNUine Boot tries to stay as close to *stock* coreboot as possible,
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 nonGeNUine Boot build system.
automatically by the Canoeboot build system.
In the same way that *Trisquel GNU+Linux* is a *GNU+Linux distribution*, nonGeNUine Boot is
In the same way that *Alpine Linux* is a *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 *nonGeNUine Boot*,
whatever other software you need, to prepare the ROM image. With *Canoeboot*,
you can literally download from Git or a source archive, and run `make`, and it
will build entire ROM images. An automated build system, named `gbmk`
(non**G**eNUine**B**oot**M**a**K**e), builds these ROM images automatically, without any user input
will build entire ROM images. An automated build system, named `cbmk`
(CanoeBoot MaKe), builds these ROM images automatically, without any user input
or intervention required. Configuration has already been performed in advance.
If you were to build regular coreboot, without using an *automated* build system
like our one, it would require a lot more intervention and decent technical
If you were to build regular coreboot, without using Canoeboot's automated
build system, it would require a lot more intervention and decent technical
knowledge to produce a working configuration.
Regular binary releases of nonGeNUine Boot provide these
Regular binary releases of Canoeboot provide these
ROM images pre-compiled, and you can simply install them, with no special
knowledge or skill except the ability to
follow [simplified instructions, written for non-technical

59
site/index.uk.md
View File

@ -1,68 +1,83 @@
---
title: nonGeNUine Boot
title: Проект Canoeboot
x-toc-enable: true
...
Проект *nonGeNUine Boot* надає
[вільну](https://www.gnu.org/philosophy/free-sw.html) *завантажувальну
Проект *Canoeboot* надає
[вільну](https://writefreesoftware.org/learn) *завантажувальну
прошивку*, яка ініціалізує апаратне забезпечення (наприклад, контролер пам'яті, ЦП,
периферію) на [конкретних цілях Intel/AMD x86 та ARM](docs/hardware/), що
потім розпочинає завантажувач для вашої операційної системи. [GNU+Linux](docs/gnulinux/)
та [BSD](docs/bsd/) добре підтримуються. Це заміняє пропрієтарну BIOS/UEFI
прошивку.
прошивку. Допомога доступна
через [\#canoeboot](https://web.libera.chat/#canoeboot)
на [Libera](https://libera.chat/) IRC.
<img tabindex=1 class="r" src="https://avgnu.vimuser.org/t500/0005.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0005.jpg" /></span>
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**НОВИЙ ВИПУСК: Останній випуск nonGeNUine Boot 20230717, випущено 17 липня 2023.
Дивіться: [Оголошення про випуск nonGeNUine Boot 20230717](news/nongenuineboot20230717.md).**
**НОВИЙ ВИПУСК: Останній випуск Canoeboot 20231026, випущено 26 жовтень 2023.
Дивіться: [Оголошення про випуск Canoeboot 20231026](news/canoeboot20231026.md).**
Чому вам варто використовувати *nonGeNUine Boot*?
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
Чому вам варто використовувати *Canoeboot*?
----------------------------
nonGeNUine Boot надає вам [свободи](https://www.gnu.org/philosophy/free-sw.html), які в
Canoeboot надає вам [свободи](https://writefreesoftware.org/learn), які в
іншому випадку ви не можете отримати з більшістю інших завантажувальних
прошивок. Він надзвичайно [потужний](docs/gnulinux/grub_hardening.md)
та [налаштовується](docs/maintain/) для багатьох випадків використання.
У вас є права. Право на конфіденційність, свобода мислення, свобода висловлювання
та право читати. В цьому контексті, nonGeNUine Boot надає вам ці права.
та право читати. В цьому контексті, Canoeboot надає вам ці права.
Ваша свобода має значення.
[Право на ремонт](https://yewtu.be/watch?v=Npd_xDuNi9k) має значення.
Багато людей використовують пропрієтарну (невільну)
завантажувальну прошивку, навіть якщо вони використовують [вільну операційну систему](https://www.gnu.org/distros/).
завантажувальну прошивку, навіть якщо вони використовують [вільну операційну систему](https://www.openbsd.org/).
Пропрієтарна прошивка часто [містить](faq.uk.html#intel) [лазівки](faq.uk.html#amd),
та може бути глючною. Проект nonGeNUine Boot було засновано в July 2023 року, з
та може бути глючною. Проект Canoeboot було засновано в жовтень 2023 року, з
явною метою зробити прошивку coreboot доступною для нетехнічних користувачів.
Проект nonGeNUine Boot використовує [coreboot](https://www.coreboot.org/) для [ініціалізації апаратного забезпечення](https://doc.coreboot.org/getting_started/architecture.html).
Проект Canoeboot використовує [coreboot](https://www.coreboot.org/) для [ініціалізації апаратного забезпечення](https://doc.coreboot.org/getting_started/architecture.html).
Coreboot помітно складний для встановлення для більшості нетехнічних користувачів; він
виконує тільки базову ініціалізацію та перестрибує до окремої програми
[корисного навантаження](https://doc.coreboot.org/payloads.html) (наприклад,
[GRUB](https://www.gnu.org/software/grub/),
[Tianocore](https://www.tianocore.org/)), які також мають бути налаштованими.
*Програмне забезпечення nonGeNUine Boot вирішує цю проблему*; це *дистрибутив coreboot* з
*Програмне забезпечення Canoeboot вирішує цю проблему*; це *дистрибутив coreboot* з
[автоматизованою системою побудови](docs/build/index.uk.md), яка збирає завершені *образи ROM*, для
більш надійної установки. Документація надається.
Чим nonGeNUine Boot відрізняється від звичайного coreboot?
Чим Canoeboot відрізняється від звичайного coreboot?
---------------------------------------------
<img tabindex=1 class="l" style="max-width:15%;" src="https://avgnu.vimuser.org/dip8/adapter.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/dip8/adapter.jpg" /></span>
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
Таким же самим чином, як *Debian* це дистрибутив GNU+Linux, nonGeNUine Boot це
Таким же самим чином, як *Debian* це дистрибутив Linux, Canoeboot це
*дистрибутив coreboot*. Якщо ви хочете зібрати образ ROM з нуля, вам
інакше довелось би виконати налаштування експертного рівня coreboot, GRUB та
будь-якого іншого потрібного програмного забезпечення, для підготування образа ROM. З *nonGeNUine Boot*,
будь-якого іншого потрібного програмного забезпечення, для підготування образа ROM. З *Canoeboot*,
ви можете буквально завантажити з Git або архіву джерельного коду, та запустити `make`, і це
побудує всі образи ROM. Автоматизована система побудови, названа `gbmk`
(non**G**eNUine**B**oot**M**a**K**e), збирає ці образи ROM автоматично, без будь-якого вводу користувача
побудує всі образи ROM. Автоматизована система побудови, названа `cbmk`
(Canoeboot MaKe), збирає ці образи ROM автоматично, без будь-якого вводу користувача
або потрібного втручання. Налаштування вже виконано заздалегідь.
Якщо би ви збирали звичайний coreboot, не використовуючи автоматизовану систему побудови nonGeNUine Boot,
Якщо би ви збирали звичайний coreboot, не використовуючи автоматизовану систему побудови Canoeboot,
це вимагало би набагато більше втручання та гідних технічних
знань для створення робочої конфігурації.
Звичайні бінарні випуски nonGeNUine Boot надають ці
Звичайні бінарні випуски Canoeboot надають ці
образи ROM попередньо зібраними, і ви можете просто встановити їх, не маючи спеціальних
знань або навичок, окрім можливості
слідувати [спрощеним інструкціям, написаним для нетехнічних

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

@ -1,35 +1,45 @@
---
title: nonGeNUine Boot
title: Canoeboot 项目
x-toc-enable: true
...
*nonGeNUine Boot* 项目提供了[自由](https://www.gnu.org/philosophy/free-sw.html)的*引导固件*，能够在[特定的 Intel/AMD x86 以及 ARM 目标机](docs/hardware/)上对硬件（如内存控制器、CPU、外设）进行初始化，进而为操作系统启动 bootloader。本项目对 [GNU+Linux](docs/gnulinux/) 和 [BSD](docs/bsd/) 支持良好，并替代了专有的 BIOS/UEFI 固件。
*Canoeboot* 项目基于 coreboot 提供了[自由且开源](https://writefreesoftware.org/zh-cn/learn/)的引导固件，替代了特定基于 Intel/AMD x86 及 ARM 的主板（包括笔记本和桌面计算机）上的专有 BIOS/UEFI 固件。它首先对硬件（如内存控制器、CPU、外设）进行初始化，然后为操作系统启动 bootloader。本项目对 [GNU+Linux](docs/gnulinux/) 和 [BSD](docs/bsd/) 支持良好。寻求帮助，可以前往 [Libera](https://libera.chat/) IRC 上的 [\#canoeboot](https://web.libera.chat/#canoeboot) 频道。
<img tabindex=1 class="r" src="https://avgnu.vimuser.org/t500/0005.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/t500/0005.jpg" /></span>
<img tabindex=1 class="r" src="https://av.canoeboot.org/t60logo.jpg" /><span class="f"><img src="https://av.canoeboot.org/t60logo.jpg" /></span>
**新版发布: 最新版本 nonGeNUine Boot 20230717 已在 2023 年 7 月 17 日发布。
详见: [nonGeNUine Boot 20230717 发布公告](news/nongenuineboot20230717.md).**
**新版发布: 最新版本 Canoeboot 20231026 已在 2023 年 10 月 26 日发布。详见: [Canoeboot 20231026 发布公告](news/canoeboot20231026.md).**
为什么要使用 *nonGeNUine Boot*?
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
provided as a proof of concept for the [GNU Boot](https://libreboot.org/news/gnuboot.html)
or *gnuboot* project to use a more modern Libreboot base, but
they never did use it. As of 26 October 2023, GNU Boot is still based on
Libreboot 20220710 with few meaningful changes. Canoeboot 20231026 is based
on Libreboot 20231021. Look at the [Canoeboot vs GNU Boot](gnuboot.md) page for more info,
or read the [about page](about.md) for more general information.
Since the rename, Canoeboot is now an official sister project
of [Libreboot](https://libreboot.org/), and it
will be maintained meticulously, based upon each new Libreboot release whenever
feasible.
为什么要使用 *Canoeboot*?
----------------------------
nonGeNUine Boot 赋予了你[自由](https://www.gnu.org/philosophy/free-sw.html)，而这等自由，是你用其他引导固件得不到的。同时，它的启动速度更加快，[安全性也更加高](docs/gnulinux/grub_hardening.md)。在各种情况下使用，它都十分强大，具有高度[可配置性](docs/maintain/)。
Canoeboot 赋予了你[自由](https://writefreesoftware.org/learn)，而这等自由，是你用其他引导固件得不到的。同时，它的启动速度更加快，[安全性也更加高](docs/gnulinux/grub_hardening.md)。在各种情况下使用，它都十分强大，具有高度[可配置性](docs/maintain/)。
权利在你手上。你拥有隐私权、思想自由、言论自由、阅读权。这时，nonGeNUine Boot 赋予了你这些权利。你的自由是宝贵的。
[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)是宝贵的。
尽管许多人在用[自由的操作系统](https://www.gnu.org/distros/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，并且也可能出问题。2023 年 7 月，我们建立了 nonGeNUine Boot 项目，目的是让不懂技术的用户能使用 coreboot 固件。
*我们*相信，不受限制地[研究、分享、修改及使用软件](https://writefreesoftware.org/)的自由，是每个人都必须享有的基本人权的一部分。这时，*软件自由*至关重要。你的自由至关重要。教育至关重要。[修理权](https://yewtu.be/watch?v=Npd_xDuNi9k)至关重要。尽管许多人在用[自由的操作系统](https://www.openbsd.org/)，但他们用的引导固件却是专有（非自由）的。专有固件常常[包含](faq.html#intel)了[后门](faq.html#amd)，并且也可能出问题。2023 年 10 月，我们建立了 Canoeboot 项目，目的是让不懂技术的用户能使用 coreboot 固件。
nonGeNUine Boot 项目使用 [coreboot](https://www.coreboot.org/) 来[初始化硬件](https://doc.coreboot.org/getting_started/architecture.html)。对大部分不懂技术的用户来说，coreboot 是出了名地难安装；它只处理了基础的初始化，然后跳转进入单独的 [payload](https://doc.coreboot.org/payloads.html) 程序（例如 [GRUB](https://www.gnu.org/software/grub/)、[Tianocore](https://www.tianocore.org/)），而后者也需要进行配置。*nonGeNUine Boot 解决了这样的问题*；他是一个 *coreboot 发行版*，配有[自动构建系统](docs/build/)，能够构建完整的 *ROM 镜像*，从而让安装更加稳定。另有文档可参考。
Canoeboot 项目使用 [coreboot](https://www.coreboot.org/) 来[初始化硬件](https://doc.coreboot.org/getting_started/architecture.html)。对大部分不懂技术的用户来说，coreboot 是出了名地难安装；它只处理了基础的初始化，然后跳转进入单独的 [payload](https://doc.coreboot.org/payloads.html) 程序（例如 [GRUB](https://www.gnu.org/software/grub/)、[Tianocore](https://www.tianocore.org/)），而后者也需要进行配置。*Canoeboot 解决了这样的问题*；他是一个 *coreboot 发行版*，配有[自动构建系统](docs/build/)，能够构建完整的 *ROM 镜像*，从而让安装更加稳定。另有文档可参考。
nonGeNUine Boot 不是 coreboot 的分支
Canoeboot 不是 coreboot 的分支
-----------------------------------
<img tabindex=1 class="l" style="max-width:15%;" src="https://avgnu.vimuser.org/dip8/adapter.jpg" /><span class="f"><img src="https://avgnu.vimuser.org/dip8/adapter.jpg" /></span>
<img tabindex=1 class="l" style="max-width:25%;" src="https://av.canoeboot.org/dip8/adapter.jpg" /><span class="f"><img src="https://av.canoeboot.org/dip8/adapter.jpg" /></span>
事实上，nonGeNUine Boot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 nonGeNUine Boot 构建系统也自动提供了许多不同类型的配置。
事实上，Canoeboot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 Canoeboot 构建系统也自动提供了许多不同类型的配置。
nonGeNUine Boot 是一个 *coreboot 发行版*，就好比 *Trisquel GNU+Linux* 是一个 *GNU+Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *nonGeNUine Boot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `gbmk`（non**G**eNUine**B**oot**M**a**K**e），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
Canoeboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Canoeboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `cbmk`（Canoeboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
如果你要构建常规的 coreboot，而不使用 nonGeNUine Boot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
如果你要构建常规的 coreboot，而不使用 Canoeboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
nonGeNUine Boot 的常规二进制版本，提供了这些预编译的 ROM 镜像。你可以轻松安装它们，而无需特别的知识和技能，只要能遵循[写给非技术用户的简单指南](docs/install/)。
Canoeboot 的常规二进制版本，提供了这些预编译的 ROM 镜像。你可以轻松安装它们，而无需特别的知识和技能，只要能遵循[写给非技术用户的简单指南](docs/install/)。

16
site/license.md
View File

@ -3,16 +3,11 @@ title: License
x-toc-enable: true
...
Unless otherwise stated, every page and image (e.g. JPG/PNG files) on the GNU
Boot website or in the repository that it is built on, is released under the
terms of the GNU Free Documentation License, either version 1.3 or (at your
option) any newer version as published by the Free Software
Foundation, with no Invariant Sections, no Front Cover
Texts and no Back Cover
Texts.
You can download the logo files from `gbwww-img.git`. See:
[git.md](git.md)
Unless otherwise stated, every page and image (e.g. JPG/PNG files) on the
Canoeboot website or in the repository that it is built on, is released under
the terms of the GNU Free Documentation License, either version 1.3 or (at your
option) any newer version as published by the Free Software Foundation, with no
Invariant Sections, no Front Cover Texts and no Back Cover Texts.
These pages are static HTML, generated from Markdown files, which you can find
a link to at the bottom of each HTML page, for the corresponding Markdown file.
@ -493,3 +488,4 @@ permit their use in free software.
The license text ended in the previous paragraph. Now you see the generic footer
generated for every page on this website:
Please also see [logo license](logo-license.md)

12
site/logo-license.md
View File

@ -1,5 +1,13 @@
---
title: nonGeNUine Boot logo license
title: Canoeboot logo license
...
There is no logo at the moment.
You can download the logo files from `cbwww-img.git`. See:
[git.md](git.md) - licensing available there. The Canoeboot logo design is
Copyright 2023 Cuan Knaggs, provided to the Canoeboot project under license:
Creative Commons Attribution-ShareAlike 4.0 International - and the version
used by Canoeboot is a modified version of the original. The original is included
in that Git repository, `cbwww-img.git` (linked above), along with the modified
versions. A version of that is also provided in `lbmk.git` as a GRUB
background, and under `cbwww.git` as the favicon icon for the Canoeboot website
hosted at *canoeboot.org*.

1
site/news/MANIFEST
View File

@ -1 +1,2 @@
canoeboot20231026.md
nongenuineboot20230717.md

789
site/news/canoeboot20231026.md Normal file
View File

@ -0,0 +1,789 @@
% Canoeboot 20231026 released!
% Leah Rowe in Canoe Leah Mode™
% 26 October 2023
Introduction
============
*This* new release, Canoeboot 20231026, released today 26 October 2023, is
based on the [Libreboot 20231021](https://libreboot.org/news/libreboot20231021.html)
release, porting changes in it on top of
[nonGeNUine Boot 20230717](nongenuineboot20230717.md) as a base. The previous
release was nonGeNUine Boot 20230717, released on 17 July 2023; the project
named *nonGeNUine Boot* has been renamed to Canoeboot, in this release, which
is the first ever release under the name *Canoeboot*.
Canoeboot provides boot firmware for supported x86/ARM machines, starting a
bootloader that then loads your operating system. It replaces proprietary
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
on [ARM-based chromebooks](../docs/install/chromebooks.html) supported
(U-Boot bootloader, instead of Google's depthcharge bootloader). On x86
machines, the GRUB and SeaBIOS coreboot
payloads are officially supported, provided in varying configurations per
machine. It provides an [automated build system](../docs/maintain/) for the
[configuration](../docs/build/) and [installation](../docs/install/) of coreboot
ROM images, making coreboot easier to use for non-technical people. You can find
the [list of supported hardware](../docs/hardware/) in Canoeboot documentation.
Canoeboot's main benefit is *higher boot speed*,
[better](../docs/gnulinux/encryption.md)
[security](../docs/gnulinux/grub_hardening.md) and more
customisation options compared to most proprietary firmware. As a
[libre](https://writefreesoftware.org/learn) software project, the code can be
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/gnulinux/)
[supported](../docs/bsd/).
Canoeboot is maintained in parallel with Libreboot, and by the same developer,
Leah Rowe, who maintains both projects; Canoeboot implements the [GNU Free
System Distribution Guideline](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html)
as policy, whereas Libreboot implements its own [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html).
Work done since last release
============================
No new mainboards have been added in Canoeboot 20231026, versus nonGeNUine
Boot 20230717, but a slew of build system enhancements and new features have
been ported from Libreboot.
However, the *following* mainboards added in Libreboot 20231021 have *been
excluded* in this Canoeboot release, due to the GNU FSDG policy: HP
EliteBook 2170p, HP EliteBook 8470p, Dell Precision T1650 and Dell
Latitude E6430.
GRUB LUKS2 now supported (with argon2 key derivation)
---------------------------------------------------
*This* new Canoeboot release imports the [PHC argon2
implementation](https://github.com/P-H-C/phc-winner-argon2) into GRUB,
courtesy of [Axel](https://axelen.xyz/) who initially ported the code to run
under GRUB *2.06*, but this Canoeboot release uses GRUB *2.12* (an RC revision
from git, at present).
Axel's code was published to [this AUR repository](https://aur.archlinux.org/cgit/aur.git/tree/?h=grub-improved-luks2-git&id=1c7932d90f1f62d0fd5485c5eb8ad79fa4c2f50d)
which [Nicholas Johnson](https://nicholasjohnson.ch/) then rebased on top of
GRUB *2.12*, and I then imported the work into Libreboot, with Johnson's
blessing; Canoeboot has inherited this work in full.
These libreboot patches added argon2 support, and have been ported to Canoeboot
in this 20231026 release:
* <https://browse.libreboot.org/lbmk.git/commit/?id=2c0c521e2f15776fd604f8da3bc924dec95e1fd1>
* <https://browse.libreboot.org/lbmk.git/commit/?id=fd6025321c4ae35e69a75b45d21bfbfb4eb2b3a0>
* <https://browse.libreboot.org/lbmk.git/commit/?id=438bf2c9b113eab11439c9c65449e269e5b4b095>
This means that you can now boot from encrypted `/boot` partitions. I'm very
grateful to everyone who made this possible!
Simplified commands (build system)
-------------------------
Simply put, cbmk (the Canoeboot build system) is now *easier to use* than
gbmk (the nonGeNUine Boot 20230717 build system) was; there
are only *9* shell scripts in this release, versus 50 or so in the
nonGeNU 20230717 release, and the command structure has been simplified.
You can find information about *using* the build system in
the [Canoeboot build instructions](../docs/build/) and in the [cbmk
maintenance manual](../docs/maintain/).
The Libreboot 20231021 release has *12* scripts, bacause there are 3 more
scripts there for handling the downloading of vendor code; since Canoeboot
intentionally avoids doing that, those scripts are not needed in Canoeboot
and have therefore been excluded. They are: `script/vendor/download`,
`script/vendor/inject` and `include/mrc.sh`.
TWO massive audits. 50% code size reduction in lbmk.
--------------------------------------------
Libreboot's build system, lbmk, is written entirely in shell scripts. It is
an automatic build system that downloads, patches, configures and compiles
source trees such as coreboot and various payloads, to build complete ROM
images that are easier to install. More info about that is available in
the [lbmk maintenance manual](https://libreboot.org/docs/maintain/) - and you
can read the [cbmk maintenance manual](../docs/maintain/) for comparison.
The primary focus of Libreboot 20231021 cultiminated in two *audits*, namely
[Libreboot Build System Audit 2](https://libreboot.org/news/audit2.html) and
then [Librebootboot Build System Audit 3](https://libreboot.org/news/audit3.html).
The changes in those audits have been ported to this *Canoeboot* release.
Changes include things like vastly reduced code complexity (while not
sacrificing functionality), greater speed (at compiling, and boot speeds are
higher when you use the GRUB payload), many bug fixes and more.
Serprog firmware building (RP2040 and STM32)
-----------------------------------
In addition to coreboot firmware, the Canoeboot build system (lbmk) can now
build *serprog* firmware, specifically `pico-serprog` and `stm32-vserprog`, on
all devices that these projects support.
The *serprog* protocol is supported by flashrom, to provide SPI flashing. It
can be used to set up an external SPI flasher, for [flashing Canoeboot
externally](../docs/install/spi.md). This too has been ported from Libreboot.
Pre-compiled firmware images are available, for many of these devices, under
the `roms/` directory in this Canoeboot 20231026 release! Riku Viitanen is the
one who added this capability to Libreboot, which was then ported to Canoeboot.
Updated U-Boot revision (2023.10)
----------------------------
Alper Nebi Yasak submitted patches that update the U-Boot revision in
Libreboot, on `gru_bob` and `gru_kevin` chromebooks. Additionally, the `cros`
coreboot tree has merged there with the `default` tree instead (and the `default`
tree has been updated to coreboot from 12 October 2023).
Many improvements were made to these boards, which you can learn about by
reading these diffs:
* <https://browse.libreboot.org/lbmk.git/commit/?id=eb267733fabe6c773720706539ef37f1ce591f81>
* <https://browse.libreboot.org/lbmk.git/commit/?id=8b411963b7e4941cbd96ac874d0582eaa20ea998>
* <https://browse.libreboot.org/lbmk.git/commit/?id=b2d84213dae4e199b4e4fa4f70dd6e3fbf5d90c4>
* <https://browse.libreboot.org/lbmk.git/commit/?id=f459e05ecd40592d80d119d16449d40f0dfbfa78>
* <https://browse.libreboot.org/lbmk.git/commit/?id=5b4ced3329f5fd8cb1fa166c8ac424e0bb618d67>
* <https://browse.libreboot.org/lbmk.git/commit/?id=46e01c0e1dade74f5ce777bf8593fe2722318af2>
* <https://browse.libreboot.org/lbmk.git/commit/?id=7afe2f39189fa196547c3dd9f9f617cfab91d835>
* <https://browse.libreboot.org/lbmk.git/commit/?id=f7db91c848f1fbf6bea93b62dfa4313ff550eeec>
* <https://browse.libreboot.org/lbmk.git/commit/?id=f9bad4449aa97aa2eb21f2254c0ad1515119888a>
* <https://browse.libreboot.org/lbmk.git/commit/?id=fea0cec24a1f2b03cf3c8b928259222f0bcf2357>
* <https://browse.libreboot.org/lbmk.git/commit/?id=f08102a22731182e8ad2f678ab39b19508fd455a>
* <https://browse.libreboot.org/lbmk.git/commit/?id=4e7e4761918d2cb04f3bf664c8c0ea8426a0e3bc>
* <https://browse.libreboot.org/lbmk.git/commit/?id=6e65595da5301b9b8c435a9ab55e6f0d9b01a86d>
* <https://browse.libreboot.org/lbmk.git/commit/?id=4d9567a7561df6eeb0dd81f2faf522c8526163b0>
All of these patches have been ported to this Canoeboot release.
Coreboot, GRUB, U-Boot and SeaBIOS revisions
------------------------------------
In Canoeboot 20231026 (*this release*):
* Coreboot (default): commit ID `d862695f5f432b5c78dada5f16c293a4c3f9fce6`, 12 October 2023
* Coreboot (cros): MERGED WITH `coreboot/default` (see above)
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
* GRUB: commit ID `e58b870ff926415e23fc386af41ff81b2f588763`, 3 October 2023
* SeaBIOS: commit ID `1e1da7a963007d03a4e0e9a9e0ff17990bb1608d`, 24 August 2023
* U-Boot: commit ID `4459ed60cb1e0562bc5b40405e2b4b9bbf766d57`, 2 October 2023
In nonGeNUine Boot 20230717 (*previous release*):
* Coreboot (default): commit ID `e70bc423f9a2e1d13827f2703efe1f9c72549f20`, 17 February 2023
* Coreboot (cros): commit ID `8da4bfe5b573f395057fbfb5a9d99b376e25c2a4` 2 June 2022
* Coreboot (fam15h\_udimm): DID NOT EXIST
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 14 February 2023
* SeaBIOS: commit ID `ea1b7a0733906b8425d948ae94fba63c32b1d425`, 20 January 2023
* U-Boot (for coreboot/cros): commit ID `890233ca5569e5787d8407596a12b9fca80952bf`, 9 January 2023
As you can see, all revisions are quite new in this release.
Build system tweaks
===================
resources/ now config/
----------------------
The `resources/scripts/` directory is now `script/`, and what was `resources/`
now only contains configuration data plus code patches for various projects,
so it has been renamed to `config/` - I considered splitting patches
into `patch/`, but the current directory structure for patches is not a problem
so I left it alone.
Also, the IFD/GbE files have been moved here, under `config/ifd/`. These can
always be ge-generated if the user wants to, using ich9gen, or using a
combination of bincfg and ifdtool from coreboot, and nvmutil (to change the
mac address) from Canoeboot or Libreboot.
Full list of changes (detail)
--------------------
These changes have been ported from the Libreboot 20231021 release, which are
mostly the results of the two audits (mentioned above):
* Much stricter, more robust error handling; too many changes to list here, so
check the git log. Also, errors that *are not errors* are no longer treated as
such; nonGeNUine Boot 20230717's build system was actually too strict, sometimes.
* Most logic has been unified in single scripts that perform once type of task
each, instead of multiple scripts performing the same type of talk; for
example, defconfig-based projects now handled with the same scripts, and
preparing trees for them is done the same. These unifications have been done
carefully and incrementally, with great thought so as to prevent *spaghetti*.
The code is clean, and small.
* GitHub is no longer used on main Git repository links, instead only as backup
* Backup repositories now defined, for all main repos under `config/git/`
* Single-tree projects are no longer needlessly re-downloaded when they already
have been downloaded.
* GRUB LUKS2 support now available, with argon2 key derivation; previously, only
PBKDF2 worked so most LUKS2 setups were unbootable in Canoeboot. This is fixed.
* Vastly reduced number of modules in GRUB, keeping only what is required.
* Use `--mtime` and option options in GNU Tar (if it is actually GNU Tar), when
creating Tar archives. This results in partially reproducible source archives,
and consistent hashes were seen in testing, but not between distros.
* Always re-inialitise `.git` within lbmk, for the build system itself, if
Git history was removed as in releases. This work around some build systems
like coreboot that use Git extensively, and are error-prone without it.
* More robust makefile handling in source trees; if one doesn't exist, error
out but also check other makefile name combinations, and only error out if
the command was to actually build.
* ROMs build script: support the "all" argument, even when getopt options are
used e.g. `-k`
* Disabled the pager in `grub.cfg`, because it causes trouble in some
non-interactive setups where the user sees an errant message on the screen
and has to press enter. This fixes boot interruptions in some cases, allowing
normal use of the machine. The pager was initially enabled many years ago,
to make use of cat a bit easier in the GRUB shell, but the user can just
enable the pager themselves if they really want to.
* U-Boot can now be compiled standalone, without using the ROMs build script,
because crossgcc handling is provided for U-Boot now in addition to coreboot.
* All helper scripts are now under `include/`, and main scripts in `script/`,
called by the main `build` script
* Generally purge unused variables in shell scripts
* Simplified initialisation of variables in shell scripts, using the `setvars`
function defined under `include/err.sh`
* Support patch subdirectories, when applying patches. This is done recursively,
making it possible to split up patch files into smaller sets inside sub
directories, per each source tree (or target of each source tree, where a
project is multi-tree within lbmk)
* SPDX license headers now used, almost universally, in all parts of cbmk.
* Files such as those under `config/git` are now
concatenated, traversing recursively through the target directory; files first,
then directories in order, and for each directory, follow the same pattern
until all files are concatenated. This same logic is also used for patches.
This now enables use of subdirectories, in some config/patch directories.
* General code cleanup on `util/nvmutil`
* Git histories are more thoroughly deleted, in third party source trees during
release time.
* Symlinks in release archives are no longer hard copies; the symlinks are
re-created by the release script, because it clones the current lbmk work
directory via Git (local git clone), rather than just using `cp` to copy links.
* Properly output to stderr, on printf commands in scripts where it is either
a warning prior to calling `err`, or just something that belongs on the error
output (instead of standard output).
* Don't use the `-B` option in make commands.
* SECURITY: Use sha512sum (not sha1sum) when verifying certain downloads. This
reduces the chance for collisions, during checksum verification.
* Set GRUB timout to 5s by default, but allow override and set to 10s or 15s
on some mainboards.
* Support both curl and wget, where files are downloaded outside of Git; defer
to Wget when Curl fails, and try each program three times before failing. This
results in more resilient downloading, on wobbly internet connections.
* Don't clone Git repositories into `/tmp`, because it might be a tmpfs with
little memory available; clone into `tmp/gitclone` instead, within lbmk,
and `mv` it to avoid unnecessary additional writes (`mv` is much more efficient
than `cp`, for this purpose).
* Removed unused `target.cfg` handling in vendor scripts, because they use
the concatenated config format instead (they always have).
* Coreboot builds: automatically run make-oldconfig, to mitigate use of raw
coreboot config where a revision was updated but the config was untouched.
This may still result in a confirmation dialog, and it's still recommended
that the configs be updated per revision (or switch them to defconfigs).
* Vastly simplified directory structure; `resources/scripts/` is now `script/`,
and `resources/` was renamed to `config/`; ifd and gbe files were also moved
to `config/ifd/`. Commands are now 1-argument instead of 2, for example
the `./build boot roms` command is now `./build roms`.
* memtest86plus: only build it on 64-bit hosts, for now (32-bit building is
broken on a lot of distros nowadays, and lbmk doesn't properly handle cross
compilation except on coreboot or U-Boot)
* (courtesy of Riku Viitanen) don't use cat on loops that handle lines of text.
Instead, use the `read` command that is built into `sh`, reading each line.
This is more efficient, and provides more robust handling on lines with
spaces in them.
* *ALL* projects now have submodules downloaded at build time, not just multi
tree projects such as coreboot - and a few projects under `config/git` have
had certain `depend` items removed, if a given project already defines it
under `.gitmodules` (within its repository).
* Improved cbutils handling; it's now even less likely to needlessly re-build
if it was already built.
* The release build script no longer archives what was already built, but
instead builds from scratch, creating an archive from source downloads
first before building the ROM archives. This saves time because it enables
a single build test per release, whereas at was previously necessary to test
the Git repository and then the release archive. Testing both is still desired,
but this behaviour also means that whatever is built at release time is
guaranteed to be the same as what the user would build (from archives).
* Improved handling of `target.cfg` files in multi-tree projects coreboot,
SeaBIOS and U-Boot. Unified to all such projects, under one script, and
with improved error handling.
* GRUB payload: all ROM images now contain the same ELF, with all keymaps
inserted. This speeds up the build process, and enables easier configuration
when changing the keyboard layout because less re-flashing is needed.
* Simplified IFD handling on ICH9M platforms (e.g. X200/T400 thinkpads); the
ich9gen utility wasn't needed anymore so ich9utils has been removed, and now
the IFD/GbE files are included pre-assembled (generated by ich9gen). Ich9gen
can still be used, or you can re-generate with coreboot's bincfg; the ifdtool
util can be used to edit IFD and nvmutil (part of Canoeboot) can change MAC
addresses. The ich9utils code was always redundant for the last few years,
especially since 2022 when nvmutil was first written.
* Running as root is now forbidden, for most commands; lbmk will exit with
non-zero status if you try. The `./build dependencies x` commands still work
as root (they're the only commands available as root).
* Enabled memtest86plus on more boards, where it wasn't previously enabled.
* Only enable SeaBIOS as first payload on desktops, but still enable GRUB as
second payload where GRUB is known to work (on each given host). The text
mode and coreboot framebuffer modes are provided in each case, where feasible.
* The `list` command has been mostly unified, making it easier to tell (from
lbmk) what commands are available, without having to manually poke around
under `script/`.
* The `-T0` flag is now used, universally, on xz commands. This makes `xz` run
on multiple threads, greatly speeding up the creation of large tar archives.
* Universally use `-j` in make commands, for multi-threading, but it relies
on `nproc` to get thread count, so this only works if you have `nproc` (you
probably don't, if you run BSD; BSD porting is still on TODO for Canoeboot)
* File names as arguments now universally have quotes wrapped around them, and
similar auditing has been done to all variables used as arguments everywhere
in lbmk. There were cases where multiple arguments were wrongly quoted then
treated as a single argument, and vice versa. This is now fixed.
* Re-wrote `.gitcheck`; now, a global git name/email config is always required.
The only behaviour (setting local config, and unsetting) was quite error-prone
under fault conditions, where cleanup may not have been provided, or when
execution was interrupted, resulting sometimes in accidentally committing
to `lbmk.git` as author named `lbmkplaceholder`.
* The new BSD-like coding style is now used on *all* shell scripts in lbmk. A
few scripts still used the old lbmk coding style, as of audit 2.
* Scripts no longer directly exit with non-zero status, under fault conditions;
instead, `x_` or `err` is used to provide such behaviour. This results in all
exits from lbmk being consolidated to `err`, under fault conditions. - zero
exits are also consolidated, going only through the main script, which has its
own exit function called `lbmk_exit` that provides `TMPDIR` cleanup.
* BSD-style error handling implemented, with an `err` function (and functions
that use it) inside `include/err.sh`; there is also `x_` which can be used
to run a command and exit automatically with non-zero status, useful because
it provides more verbose output than if you just relied on `set -e`, and it
still works when a script *does not* use `set -e` - however, it is not used
on all functions, because it works by executing `$@` directly, which can break
depending on arguments. Therefore, some scripts just default to `|| err` for
providing breakage in scripts.
* Memtest *6.2* now used (instead of *5.x* releases). This is essentially a
re-write, and it works on the coreboot framebuffer, whereas previous revisions
only worked on text mode setups.
* NO MAKEFILE. The Makefile in lbmk has been removed. It was never meaningfully
used because all it did was run lbmk commands, without implementing any logic
itself. A Makefile may be added again in the future, but with a view to
installing *just the build system* onto the host system, to then build ROM
images under any number of directories. Lbmk's design is strictly no-Makefile,
but it uses Makefiles provided by third party source trees when building them.
* Safer GRUB configuration file handling between GRUB memdisk and coreboot CBFS;
it is no longer possible to boot without a GRUB config, because the one in
GRUB memdisk is provided as a failsafe, overridden by *inserting* one in CBFS,
but there is no config in CBFS by default anymore.
* The build system *warns* users about `elf/` vs `bin/`, when it comes to
flashing coreboot ROM images; it tells them to use `bin/` because those
images do contain payloads, whereas the ones under `elf/` do not.
* VASTLY more efficient build process; all coreboot ROMs without payload are
now cached under `elf/`, as are payloads, then they are joined separately by
the usual ROMs build script, and these cached ROMs contain many changes in
them that were previously handled by `moverom` in the main ROM build script.
Under the new design, repetitive steps are avoided; payloads are inserted into
a copy of the cached ROMs under `TMPDIR`, *before* being copied for keymaps
and small files; this eliminates delays caused by slow compression (LZMA is
always used, when inserting payloads). After crossgcc and the payloads are
compiled, the ROM with coreboot builds in under a minute, whereas it would
have previously taken several minutes on most Canoeboot-supported hardware.
* VASTLY reduced GRUB payload size; modules that aren't needed have been removed
resulting in much smaller GRUB payloads, that also boot faster.
* ALL defconfig creation, updating and modification are handled by the same
script that *also* handles compiling, as mentioned in the bullet-point below.
* ALL main source trees are now compiled, downloaded, configured and cleaned
using the same script. The *download* (Git) logic is a separate file
under `include/` and its functions are called by the main build script, which
provides a stub for this.
* Scripts are no longer executed directly, ever, except the main script. All
scripts are otherwise executed from `script/`, inheriting the `TMPDIR`
variable set (and exported) by lbmk.
* Generally improved user feedback in scripts, especially the vendor scripts.
* Coreboot, U-Boot and SeaBIOS are now downloaded, configured and compiled using
the exact same script. Although these codebases differ wildly, their build
systems use the same design, and they are compatible from a user-interface
perspective.
* Vastly improved `/tmp` handling; a universal `TMPDIR` is set (environmental
variable) and exported to all child processes running lbmk scripts. On exit,
the main tmp directory is purged, cleaning all tmp directories under it.
* General simplification of coding style on all shell scripts.
* Fixed some variable initialisations in the coreboot ROM image build script
* Don't enable u-boot on QEMU x86 images (due to buggy builds, untested)
* Fixed coreboot-version file inserted into coreboot trees, when compiled
on Canoeboot release archives.
* Very general auditing has been done, finding and fixing bugs.
* Reduced the number of scripts significantly. There were about 50 scripts in
the nonGeNUine Boot 20230717 build system. There are closer to *20* in today's
Canoeboot 20231026 revision.
* Many scripts that were separate are now unified. For example: the scripts
handling defconfigs files on SeaBIOS, u-Boot and coreboot have now been
merged into a single script, performing the same work *better* in less code.
* Ditto many other scripts; repeated logic unified, logic generalised. The
logic for *downloading* coreboot and u-boot was unified into one script,
basing off of the coreboot one, and then expanding to also cover SeaBIOS.
Most building (e.g. handling of Makefiles) is now done in a single script.
* Far superior error handling; in many scripts, the `-e` option in `sh` was
heavily relied upon to catch errors, but now errors are handled much more
verbosely. *Many* fault conditions previously did not make lbmk *exit* at all,
let alone with non-zero status, and zero status was sometimes being returned
under some edge cases that were tested. Error handling is more robust now.
* `util/ich9utils` (containing `ich9gen`) was *removed*, thus eliminating about
3000 source lines (of C code) from lbmk. The `nvmutil` program, also provided
by and originating from the Canoeboot project, can already change GbE MAC
addresses. Coreboot's bincfg can generate ich9m descriptors, and ifdtool can
manipulate them; so the features provided by ich9utils were superfluous, since
they are available in other projects that we ship. We now ship pre-built
ifd/gbe configs on these machines, which can be modified or re-assembled
manually if you want to. This eliminates a moving part from Canoeboot, and
speeds up the build a little bit.
* ROM images (of coreboot) build *much faster*: no-payload coreboot ROMs are
cached on disk, as are payloads, where previously only the latter was cached.
These cached images have as much inserted into them as possible, to eliminate
redundant steps in the build process. The `elf` directory contains these, and
the existing `bin` directory still holds the full ROM images (containing
payloads) when compiled.
* GRUB payload: vastly reduced the size of the payload, by eliminating GRUB
modules that were not needed. About 100KB of compressed space saved in flash!
* GRUB payload: [argon2 key derivation supported](argon2.md) - this means LUKS2
decryption is now possible in GRUB. This work was performed by Nicholas
Johnson, rebasing from Axel's AUR patch for GRUB 2.06 (Canoeboot currently
uses GRUB 2.12).
* The *new* coding style is now used on many more scripts, including
the `build/boot/roms_helper` script - the new style is much cleaner,
mandating that logic be top-down, with a `main()` function defined; it's
basically inspired by the OpenBSD coding style for C programs, adapted to
shell scripts.
* All GRUB keymaps now included; a single `grub.elf` is now used on all ROM
images. The `grub.cfg` goes in GRUB memdisk now, but can be overridden by
inserting a `grub.cfg` in CBFS; many behaviours are also controlled this way,
for example to change keymaps and other behaviours. This results in *much*
faster builds, because a different GRUB payload doesn't have to be added to
each new ROM image; such takes time, due to time-expensive LZMA compression.
This, plus the optimised set of GRUB modules, also makes GRUB itself load
much faster. All of the fat has been trimmed, though still quite a lot more
than a Crumb.
* A lot of scripts have been removed entirely, and their logic not replaced;
in many cases, Canoeboot's build system contained logic that had gone unused
for many years.
* More reliable configs now used on desktop mainboards: SeaBIOS-only for start,
but GRUB still available where feasible (in the SeaBIOS menu). This makes it
more fool proof for a user who might use integrated graphics and then switch
to a graphics card; the very same images will work.
* TMPDIR environmental variable now set, and exported from main parent process
when running lbmk; child processes inherit it, and a single tmp dir is used.
This is then automatically cleaned, upon exit from lbmk; previously, lbmk did
not cleanly handle `/tmp` at all, but now it's pretty reliable.
Hardware supported in this release
==================================
All of the following are believed to *boot*, but if you have any issues,
please contact the Canoeboot project. They are:
### Servers (AMD, x86)
- [ASUS KFSN4-DRE motherboard](../docs/hardware/kfsn4-dre.md)
- [ASUS KGPE-D16 motherboard](../docs/hardware/kgpe-d16.md)
Desktops (AMD, Intel, x86)
-----------------------
- [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
- [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
- [Apple iMac 5,2](../docs/hardware/imac52.md)
- [ASUS KCMA-D8 motherboard](../docs/hardware/kcma-d8.md)
### Laptops (Intel, x86)
- **[Dell Latitude E6400](../docs/hardware/e6400.md) (easy to flash, no disassembly, similar
hardware to X200/T400)**
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](../docs/hardware/r400.md)
- [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
- [Lenovo ThinkPad T500](../docs/hardware/t500.md)
- [Lenovo ThinkPad W500](../docs/hardware/t500.md)
- [Lenovo ThinkPad R500](../docs/hardware/r500.md)
- [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
### Laptops (ARM, with U-Boot payload)
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
Downloads
=========
You can find this release on the downloads page. At the time of this
announcement, some of the rsync mirrors may not have it yet, so please check
another one if your favourite one doesn't have it.
Special changes
===============
Besides deblobbing, there are two critical differences in how Canoeboot's
build system works in this release, versus the Libreboot 20231021 build system:
* Single-tree git submodules are not downloaded in Canoeboot; none of them are
used in the Libreboot release, but using them simplified `config/git/` because
many of those entries were defined as submodules by each given project; in
some serprog-related repositories, proprietary drivers get downloaded that are
never actually compiled or executed in any way. Rather than deblob these in
Canoeboot, the Canoeboot build system simply skips downloading those
repositories altogether.
* Thus, several entries in under `config/git/` for Canoeboot 20231026, that do
not exist under Libreboot 20231021.
This quirk is only a minor difference. Severals scripts that handled
dependencies for building non-FSDG-compliant boards (such as blob download
scripts) have been *excluded* in this Canoeboot release, because they are
not needed.
As a result, the Canoeboot build system is about 1250 sloc when counting shell
scripts of the build system; the Libreboot build system is about 1750. This
comparison is between Canoeboot 20231026 and Libreboot 20231021 - by contrast,
Libreboot 20230625 was 3388 sloc, and GNU Boot 0.1 RC is 2111 sloc (counting
shell scripts, because it uses the same design as lbmk and cbmk).
That ~1250 sloc in Canoeboot is *with* all the extra features such as serprog
integration and U-Boot support (on actual mainboards, that you can flash it
with). The build system in Canoeboot 20231026 is *[extremely
efficient](../docs/maintain/)*.
Backports
=========
In addition to the Libreboot 20231021 changes, the following Libreboot patches
were backported into this Canoeboot release, from Libreboot revisions pushed
after the Libreboot 20231021 release came out:
* <https://browse.libreboot.org/lbmk.git/commit/?id=3b92ac97b6ed2216b5f0a17ff9c015f0d8936514>
* <https://browse.libreboot.org/lbmk.git/commit/?id=280bccebb5dfbbb7fd3eceab85165bac73523f7c>
* <https://browse.libreboot.org/lbmk.git/commit/?id=444f2899e69e9b84fd5428625aa04b00c1341804>
* <https://browse.libreboot.org/lbmk.git/commit/?id=03c830b2e9dd8f0847045700349c69ab40458ad8>
* <https://browse.libreboot.org/lbmk.git/commit/?id=b353b0c7134d155feb53b3ab17fdf6ad959ba668>
* <https://browse.libreboot.org/lbmk.git/commit/?id=f1785c3f43734108443fed9c6b91ffcb835ae097>
* <https://browse.libreboot.org/lbmk.git/commit/?id=85bc915684cbeb562d8c6fbf81f9e35064ac04f1>
* <https://browse.libreboot.org/lbmk.git/commit/?id=df031d422a1c0b76edbea1cdee98796ad3d1392f>
* <https://browse.libreboot.org/lbmk.git/commit/?id=5f6ba01d414e2d98d7db049347b8c5c5d125ba61>
Changes NOT included in this release
====================================
These entries are from the Libreboot 20231021 change log, but these changes
are *not* present in the Canoeboot 20231026 release:
* Better integrity checking when downloading vendor files
* Scrubbing of vendor files *now* handled by the inject script, rather than
the release script. This enables more robust handling of configs pertaining
to vendor files, that tell lbmk where the files are and how to insert them; it
therefore follows that this same script should be used to delete them.
* Unified handling of git/vendor config files, containing URLs, revisions,
checksums and so on. This is handled by a single function
under `include/option.sh`
* Intel ME extraction is now provided in one function, instead of two, when
downloading vendor files per mainboard, before running it
through `me_cleaner`
* Unified checking of the destination file, when downloading vendor updates.
This results in more reliable checking of whether a vendor file has already
been downloaded or not, where it is only handled if missing.
* Vendor scripts: archive extraction is now unified, the same method used for
each archive. This enables more robust checking of hashes and so on.
* More deeply integrated the Intel MRC download script (from coreboot) into
Canoeboot's vendor scripts, removing its download logic and re-using that
from Canoeboot's scripts instead; now, the MRC script only contains extraction
logic, and it is an *include* file, rather than a standalone script.
* Where no-microcode ROM images are provided, ensure that the ROM hashes still
match when running the vendor inject script. This is only useful on the
Dell Latitude E6400, which is otherwise FSDG-compatible but (in Canoeboot)
comes with or without microcode updates, and with or without the Nvidia VGA
ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
previously failed, under certain conditions, when inserting that VGA ROM.
* Vendor scripts: don't use `/tmp` for ROM images when inserting vendor files.
In case `/tmp` is a tmpfs and not much RAM is available, it is paramount that
the user's file system is used instead, where there is likely greater capacity;
it is done under `tmp/` in lbmk (not to be confused with `/tmp`).
* move `me7_updater_parser.py` to `util/` (not under `script/`)
* The directory containing vendor files no longer exists in lbmk, because it
is instead created when needed; the ifd/gbe files were moved to `config/ifd`
so the vendorfile directory became redundant.
* Don't support removal of microcode (during release time) on untested targets.
Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
compatible, in other words.
* Improved Dell Latitude E6400 support; the same image now provides iGPU and
dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
to be used (if the VGA ROM is missing, only the Intel GPU will work)
* Only remove microcode (where that behaviour is enabled per board) in release
ROMs, but not during build time. This results in reduced disk usage during
development, but release archives still contain the no-microcode option if
you want to use that; manual removal is also still possible, during development.
* *Copy* `dl_path`, don't move it, when downloading and extracting a vendor
file. This reduces the change of it being missing later when lbmk is run again.
* Improved handling of vendor file hashes; previously, the backup would only
be tried if the first one failed to download, but if the first file succeeded
and yet had a bad hash, the backup would not be tried. Now the backup is tried
when either the first download fails OR it has a bad hash, making downloads
of vendor files more resilient to network failure.
* When extracting ME files from vendors, more types of archives are supported
for decompression at build time.
* Fixed bug where vendor files were always being downloaded from backup URLs
at build time.
* Spoof the user agent string mimicking that of Tor Browser, when downloading
vendor files at build time. This circumvents restrictions based on user agent
string, when lbmk interacts with certain HTTP servers.
* Abort (with non-zero exit) if KBC1126 EC firmware fails to download at build
time.
* Haswell (libre MRC) coreboot tree: fixed acpica downloads, which no longer
work on the upstream URL. Old acpica binaries now hosted on Canoeboot rsync.
* Blobutil: generally more reliable now at downloading vendor files, especially
under fault conditions; for example, if a download failed before, it'd try
a backup link, but now it also tries the backup link if main download succeeds
but checksum verification didn't; and SHA512 checksums are now used, for
greater security, whereas nonGeNUine Boot 20230717 used sha1sum (now we use
sha512sum). A user agent is specified in wegt, matching that used by Tor
Browser (which in turn mimics Firefox running on Windows). This is needed
for some vendors, which seem to dislike wget's default user agent.
Excluded mainboards
===================
The following boards are *missing* in Canoeboot 20231026, but are supported in
the Libreboot 20231021 release; this is because they do not comply with FSDG
policy:
* Dell Latitude E6430
* Dell Precision T1650
* HP EliteBook 2170p
* HP EliteBook 2560p
* HP EliteBook 2570p
* HP EliteBook 8470p
* HP 8200 SFF
* HP 8300 USDT
* HP EliteBook 9470m
* Lenovo ThinkPad T420
* Lenovo ThinkPad T420S
* Lenovo ThinkPad T430
* Lenovo ThinkPad T440p
* Lenovo ThinkPad T520
* Lenovo ThinkPad T530
* Lenovo ThinkPad W530
* Lenovo ThinkPad W541
* Lenovo ThinkPad X220/X220T
* Lenovo ThinkPad X230/X230T
Removed/modified code, in the build system
-------------------------------------------
Again, certain features cannot be merged from Libreboot and into Canoeboot,
because of the restrictions set by Canoeboot policy (adhering to GNU FSDG). Here
is an overview of the code present in Libreboot 20231021 that is *missing* in
Canoeboot 20231026:
* **coreboot and u-boot download scripts:** Binary blobs are now removed during
download. A list of blobs is programmed into the build system, based on
scanning of each tree with the linux-libre `deblob-check` script. (yes, it
works on other code bases, besides Linux). **This means that most mainboards
no longer compile, in coreboot, and many u-boot targets no longer compile.**
* **`build/roms`:** These scripts build ROM images. For **zero-blob boards**,
in other words boards that do not require binary blobs, *regular* Libreboot
inserts **CPU microcode** by default, but copies each ROM to produce a
corresponding, parallel zero-blobs version **without** CPU microcode. **This**
censored version of Libreboot modifies the script in the following way: since
the coreboot and uboot download scripts **remove blobs** anyway, including CPU
microcode, the default compiled ROMs exclude microcode. Therefore, *this*
version simply removes that logic, because it's not needed.
* **`blobutil`:** Anything pertaining to the downloading of vendor blobs
has been removed. This includes `me_cleaner`, `ME7 Update Parser` and the like.
It is not needed, in this version of Libreboot. Directories such
as `resources/blobs/` (containing code and config data) has been removed.
In regular Libreboot, there are certain required binary blobs that we cannot
legally distribute on certain mainboards, so `blobutil` auto-downloads them
from the vendor while compiling ROM images, then it processes them (if needed)
and inserts them; the scripts that produce release archives will *delete*
these blobs, for the release, and those same scripts can be re-run on release
ROMs, to re-insert binary blobs. It is *completely automated*, removing any
need for manual intervention by the user, thus saving hours of time in some
cases. Blobutil snaps them up like *that* and everything *Just Works*.
It does this for *many* different types of blobs, including: Intel ME, Intel
MRC, HP KBC1126 EC firmware, VGA ROMs - you just run 1 command on 1 ROM (or
an entire collection of ROMs) and it does it, automatically detecting what
is needed for the given ROM image, per mainboard definition. Very easy to use.
This *highly innovative* technology does not exist in Censored Libreboot.
* Blobs: Removed Intel Flash Descriptors and GbE configuration files. These are
non-copyrightable, non-software blobs, just binary-encoded config. They are
not needed, in this Libreboot version. NOTE: ICH9M ones remain, because they
are needed (but they are not software).
* Blobs: Anything downloaded and inserted by `blobutil`, during the build
process or post-release in the Libreboot build system. This includes:
Intel ME firmware, Intel MRC firmware, HP KBC1126 EC firmware and VGA option
ROM for Nvidia GPU variant of Dell Latitude E6400.
* `lbmk`: Code that executes blob-related scripts has been removed.
* Patches: Any custom coreboot patches, for mainboards that require binary
blobs, have been removed. They are not needed in this Libreboot version.
* `update/release`: correspondingly deleted files
are no longer copied by these scripts (they are the scripts that generate
tar archives for Libreboot releases, after everything is compiled). The build
logic no longer bothers to scrub non-redistributable inserted binary blobs
from certain ROM images, because 1) those corresponding mainboards are no
longer supported anyway and 2) the logic for downloading/inserting those
blobs no longer exists. So there's nothing to do.
It's not actually a lot of code that was removed. The actual diff that did this
is very large, because it also removed the coreboot configs for the removed
boards, and those configs are very large.
Libreboot is superior to Canoeboot, in every way. You should use Libreboot.
Use of Canoeboot is even *dangerous*, because lack of microcode updates in
Canoeboot could potentially lead to data loss due to memory corruption.
Read more about the [Binary Blob Reduction
Policy](https://libreboot.org/news/policy.html) of the Libreboot project. The
Canoeboot project is provided as a proof of concept, to demonstrate just how
awful Libreboot used to be, before it implement the new policy in November 2022.
Canoeboot is a worthless project, but engineered to a high standard. It's
necessary to do this, because there are some people who won't adequately see
the problem unless it actually exists; Canoeboot is not a problem, because it's
not the only choice, but there was a time when osboot didn't even exist, let
alone the new Libreboot, and the other more pragmatic coreboot distros do not
support as much hardware as Libreboot does today.
You should use Libreboot, even if your hardware is compatible with Canoeboot.
I make these Canoeboot releases, specifically so that I have something to crap
all over. I could criticise GNU Boot more heavily, but GNU Boot is even more
inferior; I make Canoeboot as good as it can feasibly be at any point in time,
and criticise *that* result. My arguments are stronger when an *example* exists,
especially a strong example such as Canoeboot.
[Download Libreboot 20231021 instead](https://libreboot.org/news/libreboot20231021.html).
Censored Libreboot 20230710 release
===================================
On this day, the websites of Censored Libreboot and nonGeNUine Boot are being
redirected (HTTP 301 return) to the Canoeboot website.
An archive of nonGeNU 20230717's announcement is contained on this website,
but not Censored Libreboot 20230717; it was virtually identical to
nonGeNUine Boot 20230717, the latter of which was just a re-brand of
Censored Libreboot.
If you do want to see either nonGeNU or C-Libreboot, go to these links:
* <https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625>
* <https://codeberg.org/libreboot/lbwww/commits/branch/c20230710>
* <https://libreboot.org/news/censored-libreboot20230710.html>
And for nonGeNUine Boot, though the code (website and code) is included in
the Canoeboot repositories, here are the original repositories:
* <https://codeberg.org/vimuser/gbmk>
* <https://codeberg.org/vimuser/gbwww>
* <https://codeberg.org/vimuser/gbwww-img>
You can find the actual software release archives for nonGeNUine Boot 20230717
and Censored Libreboot 20230710 under Libreboot rsync mirrors,
in the `canoeboot` directory. They have been moved there, from where they
were previously hosted.

4
site/news/news-list.md.include
View File

@ -1,9 +1,9 @@
---
title: nonGeNUine GNUs
title: Canoeboot news
x-toc-enable: true
...
News about nonGeNUine Boot, both technical and organisational. Releases are also
News about Canoeboot, both technical and organisational. Releases are also
announced here.
-------------------------------------------------------------------------------

4
site/news/news.cfg
View File

@ -1,2 +1,2 @@
BLOGTITLE="News for libreboot.org"
BLOGDESCRIPTION="News for libreboot.org"
BLOGTITLE="News for canoeboot.org"
BLOGDESCRIPTION="News for canoeboot.org"

3
site/news/nongenuineboot20230717.md
View File

@ -115,7 +115,8 @@ And now, the changes (summarised, relative to Libreboot 20220710):
older coreboot revisions prior to that change. The corresponding tarballs
are now hosted on Libreboot rsync, and used by nonGeNUine Boot's build
system, [gbmk](../docs/maintain/) (itself a fork of the Libreboot build
system, named `lbmk`).
system, named `lbmk`). (**NOTE: gbmk was renamed to cbmk, when the project
became Canoeboot**)
* A [HUGE build system audit](https://libreboot.org/news/audit.html) inherited
from Libreboot, has been assimilated by nonGeNUine Boot; the entire build system was
re-written in a much cleaner coding style, with much stricter error handling

Some files were not shown because too many files have changed in this diff Show More