Canoeboot 20231026 website
Signed-off-by: Leah Rowe <leah@libreboot.org>master 20231026
parent
b1d84fda49
commit
deaec646fe
4
site.cfg
4
site.cfg
|
@ -1,5 +1,5 @@
|
|||
TITLE="-T nonGeNUine 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"
|
||||
|
|
|
@ -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/).
|
|
@ -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/>
|
||||
|
|
|
@ -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/>
|
||||
|
|
|
@ -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/>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
|
@ -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!
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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):
|
||||
|
||||
```
|
||||
|
|
|
@ -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`
|
||||
|
||||
|
|
|
@ -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,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>
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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/)
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 )`。
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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,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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 має декілька переваг, напр. краще поводження
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
|
@ -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,
|
||||
|
|
|
@ -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,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.
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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)。
|
|
@ -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.
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -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.
|
|
@ -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'
|
||||
|
|
|
@ -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'
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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
175
site/download.md
|
@ -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)
|
||||
|
|
|
@ -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
170
site/faq.md
|
@ -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 <insert random system here>, 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)
|
||||
|
|
|
@ -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) або будь-яке інше, випущ
|
|||
Це також стосується викривачів або будь-кого, кому потрібна справжня конфіденційність та
|
||||
безпека.
|
||||
|
||||
Привіт, у мене <вставте сюди випадкову систему>, чи підтримується вона?
|
||||
<вставте сюди випадкову систему>, чи підтримується вона?
|
||||
--------------------------------------------------------------------------------------------------------
|
||||
|
||||
Якщо в 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
BIN
site/favicon.ico
Binary file not shown.
Before Width: | Height: | Size: 1.5 KiB After Width: | Height: | Size: 7.1 KiB |
Binary file not shown.
After Width: | Height: | Size: 6.8 KiB |
Binary file not shown.
After Width: | Height: | Size: 7.0 KiB |
|
@ -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)
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
|
|
@ -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)
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
|
|
@ -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)
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
|
@ -2,10 +2,9 @@
|
|||
-------------------------------------------------------------------------------
|
||||
|
||||
* [Редагувати цю сторінку](/git.md)
|
||||
* [Хто розробляє nonGeNUine Boot?](/who.md)
|
||||
* [Хто розробляє Canoeboot?](/who.md)
|
||||
* [Ліцензія](/license.md)
|
||||
* [Шаблон](/template-license.uk.md)
|
||||
* [Логотип](/logo-license.md)
|
||||
* [Автори](/contrib.md)
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
|
|
@ -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
262
site/git.de.md
|
@ -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
247
site/git.md
|
@ -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
249
site/git.uk.md
|
@ -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>
|
||||
|
|
|
@ -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%;
|
||||
}
|
||||
}
|
||||
|
|
|
@ -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%;
|
||||
}
|
||||
}
|
|
@ -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/).
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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/).
|
|
@ -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
|
||||
|
|
|
@ -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 попередньо зібраними, і ви можете просто встановити їх, не маючи спеціальних
|
||||
знань або навичок, окрім можливості
|
||||
слідувати [спрощеним інструкціям, написаним для нетехнічних
|
||||
|
|
|
@ -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/)。
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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 +1,2 @@
|
|||
canoeboot20231026.md
|
||||
nongenuineboot20230717.md
|
||||
|
|
|
@ -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.
|
|
@ -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.
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
|
|
@ -1,2 +1,2 @@
|
|||
BLOGTITLE="News for libreboot.org"
|
||||
BLOGDESCRIPTION="News for libreboot.org"
|
||||
BLOGTITLE="News for canoeboot.org"
|
||||
BLOGDESCRIPTION="News for canoeboot.org"
|
||||
|
|
|
@ -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
Loading…
Reference in New Issue