extreme cleanup / grandiose gesture
make canoeboot a truly GNU FSDG compliant coreboot distro, by removing all overly positive reference to Libreboot; what remains is technical in nature, so as to provide historical context since Canoeboot is a fork of Libreboot. I've stated before that I wish to take a more neutral tone toward the FSF, in contrast to the *coldboot war* of 2023 when GNU Boot started. Canoeboot was heavily linking to Libreboot, even going so far as to call itself "inferior" and tell the reader to use Libreboot. From now on, Canoeboot will be maintained as though I actually believed in FSF propoganda. I don't, but its users do. Treat them with respect. My reason for providing Canoeboot is precisely that I wish for such people to have a high quality coreboot distro, much unlike the inferior *GNU Boot* project; inferior because to this day, it's still based on very old Libreboot, with not much changed (of any real substance) relative to the Libreboot 20220710 release on which it forked. In general, I've also found a lot of stragglers from when Canoeboot started, where paragraphs referred to Libreboot that should have actually referred to Canoeboot, or paragraphs with Libreboot-specific information that does not make sense in the Canoeboot project e.g. references to vendor scripts. The resulting canoeboot.org will now look no different to any typical reader than a typical FSF-aligned project. There is a next stage to this, which will become apparent to everyone if I have my way. Signed-off-by: Leah Rowe <info@minifree.org>master
Leah Rowe
parent
3e3dfaa856
commit
1b9e28c3b8
141
site/about.md
141
site/about.md
|
|
@ -20,39 +20,56 @@ 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
|
||||
same way that *Trisquel* is a GNU+Linux distro. Similar projects now exist, today,
|
||||
inspired by Libreboot's example. Coreboot is notoriously difficult to configure and install
|
||||
for most non-technical users, but Libreboot and Canoeboot make it easier.
|
||||
|
||||
However, *Libreboot* no longer complies with GNU policy. In November 2022,
|
||||
Libreboot adopted a more progmatic policy of allowing any board from coreboot
|
||||
to be supported, while reducing the number of binary blobs as much as possible.
|
||||
|
||||
Prior to November 2022, Libreboot complied fully with GNU policy in providing
|
||||
an entirely blob-free coreboot distribution. The rest of this article will go
|
||||
into a lot more detail, both on this and on the technical aspects, but the
|
||||
gist of it is this:
|
||||
|
||||
Canoeboot is, in spirit and in practise, a continuation of the *old* Libreboot
|
||||
project, prior to that policy change. It maintains sync with Libreboot as closely
|
||||
as possible, while removing any and all non-free code, and disabling/removing
|
||||
any code that could possibly handle it (for example modifying coreboot so as
|
||||
to never add microcode updates or download blobs, even if told to by coreboot
|
||||
configs, since the upstream coreboot project is otherwise engineered to handle
|
||||
these if requested by the user).
|
||||
|
||||
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
|
||||
and such adherence (to GNU FSDG) is the main purpose of Canoeboot. It consequently supports far less
|
||||
hardware than Libreboot. *However*, this also means that Canoeboot is an
|
||||
excellent choice for the purists out there who adhere to the GNU Free Software
|
||||
ideology, and wish to use nothing but *Free Software*.
|
||||
|
||||
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.*
|
||||
|
||||
I'm writing in the first person. Who's this *I* you're reading about? It's me,
|
||||
Leah Rowe; I am the founder and lead developer of Libreboot, *and also* the
|
||||
founder and lead developer of Canoeboot! I maintain both projects, keeping them
|
||||
in relative sync between releases, often performing same-day simultaneous
|
||||
Canoeboot and Libreboot releases.
|
||||
|
||||
Who?
|
||||
------
|
||||
|
||||
|
|
@ -64,6 +81,49 @@ 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.
|
||||
|
||||
Why?
|
||||
----
|
||||
|
||||
Canoeboot originally started as a *protest* against the FSF, who initially
|
||||
attempted what many (myself included) believed was a hostile fork; they tried
|
||||
to make their own Libreboot project, without changing the name. There was a
|
||||
lot of arguing back and forth, but the fork was later renamed to *GNU Boot*.
|
||||
|
||||
Canoeboot started at around the same time as Canoeboot, first announced
|
||||
on July 10th, 2023 (GNU Boot's savannah page first became operational
|
||||
in June 2023). The reason *Canoeboot* started, initially, was to try and provide
|
||||
the GNU Boot project with a better base to start from, because they were using
|
||||
a very old Libreboot revision at the time (Libreboot 20220710 tag). Canoeboot
|
||||
originally was called *nonGeNUine Boot*, sort of as a joke name because it was
|
||||
never intended to be a serious long-term project.
|
||||
|
||||
The GNU Boot project didn't accept any of Canoeboot's proposals, instead trying
|
||||
to re-write all of Libreboot themselves. I (Leah Rowe) had intense disagreement
|
||||
over the technical direction of the GNU Boot project. They wanted to rewrite
|
||||
the build system to use the Guix package manager for everything, which I felt
|
||||
was a prime example of *over-engineering* that would greatly increase the
|
||||
maintenance burden for the project, especially to new contributors. Canoeboot's
|
||||
general design and infrastructure is lightweight, designed to be as direct as
|
||||
possible when it comes to configuration and deployment, with clean code and
|
||||
a general tendendency towards frugal design.
|
||||
|
||||
You can read about Canoeboot's design in the [cbmk maintenance
|
||||
manual](docs/maintain/). Long story short, the name *Canoeboot* was adapted in
|
||||
October 2023, and became an official project from then on, directly competing
|
||||
with GNU Boot. The motivation was (and still is) that if there is going to
|
||||
be another FSF-aligned coreboot distro, it better be done to a high standard.
|
||||
I have over 10 years of experience working on coreboot distros. I've advised
|
||||
other projects aswell, e.g. Heads.
|
||||
|
||||
So instead of complaining, and probably annoying the GNU Boot developers even
|
||||
more than is necessary, I made my own project. I do everything myself, re-basing
|
||||
upon each new Libreboot release (just like Trisquel re-bases on each Ubuntu
|
||||
release, for example).
|
||||
|
||||
Simply speaking: there are still people out there who want a GNU FSDG compliant
|
||||
coreboot distro, and Canoeboot is the best one available today, thanks to its
|
||||
[extremely conservative design](docs/maintain/), and rigorous release engineering.
|
||||
|
||||
Release schedule
|
||||
--------------
|
||||
|
||||
|
|
@ -71,6 +131,11 @@ 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.
|
||||
|
||||
The intention, moving forward, is that Canoeboot will track *stable* releases
|
||||
of Libreboot. Development is done mainly on Libreboot, and ported over to
|
||||
Canoeboot periodically; any work that isn't suitable for Canoeboot (such as
|
||||
scripts for handling binary blobs) are *not* ported over to Canoeboot.
|
||||
|
||||
How releases are engineered
|
||||
-----------------
|
||||
|
||||
|
|
@ -146,51 +211,3 @@ 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,8 +3,9 @@ title: Project contributors
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
Leah Rowe made this website for fun, based on Libreboot.
|
||||
Leah Rowe, that's who. Leah single-handedly maintains Canoeboot, re-basing
|
||||
upon newer releases of Libreboot every now and then. Leah Rowe is the founder
|
||||
and lead developer for *both* projects; Leah maintains both
|
||||
Canoeboot *and* Libreboot.
|
||||
|
||||
It is only a proof of concept. You should otherwise use Libreboot:
|
||||
|
||||
<https://libreboot.org/>
|
||||
If you have a patch, or beef, talk to Leah.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ FreeBSD та corebootfb
|
|||
----------------------
|
||||
|
||||
Припущений поламаним, тому будь ласка переконайтесь, що ви завантажуєтесь з корисним навантаженням SeaBIOS в текстовому
|
||||
режимі (lbmk образи ROM з `txtmode` в імені файлу, не `corebootfb`).
|
||||
режимі (cbmk образи ROM з `txtmode` в імені файлу, не `corebootfb`).
|
||||
|
||||
Попередження для користувачів X11
|
||||
----------------------
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Environmental variables
|
|||
=======================
|
||||
|
||||
Please read about environmental variables in [the build
|
||||
instructions](../maintain/), before running lbmk. You should set
|
||||
instructions](../maintain/), before running cbmk. You should set
|
||||
your variables accordingly, though you do not technically need to; some
|
||||
of them may be useful, e.g. `CBMK_THREADS` (sets the number of build threads).
|
||||
|
||||
|
|
@ -110,35 +110,21 @@ time or date can cause connections to be dropped during negotiation.
|
|||
First, install build dependencies
|
||||
---------------------------------
|
||||
|
||||
Check `config/dependencies/` for list of supported distros.
|
||||
|
||||
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.
|
||||
according to the selected GNU+Linux distro.
|
||||
|
||||
Some examples (run them as root, use use e.g. `sudo`, `doas`):
|
||||
|
||||
./build dependencies ubuntu
|
||||
|
||||
or
|
||||
For example:
|
||||
|
||||
./build dependencies debian
|
||||
|
||||
or
|
||||
|
||||
./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:
|
||||
use the dedicated configuration file (the Trisquel 11 config symlinks to this):
|
||||
|
||||
./build dependencies ubuntu2004
|
||||
|
||||
Check: `config/dependencies/` for list of supported distros.
|
||||
|
||||
Technically, any Linux distribution can be used to build canoeboot.
|
||||
Technically, any GNU+Linux distribution can be used to build canoeboot.
|
||||
However, you will have to write your own script for installing build
|
||||
dependencies.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,6 +86,9 @@ 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).
|
||||
|
||||
## Debian or Devuan net install
|
||||
|
||||
NOTE: This will also apply to Trisquel GNU+Linux (an Ubuntu-based distro).
|
||||
|
||||
Download the Debian or Devuan net installer. You can download the Debian ISO
|
||||
from [the Debian homepage](https://www.debian.org/), or the Devuan ISO from
|
||||
[the Devuan homepage](https://www.devuan.org/).
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Modifying grub.cfg in CBFS
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
Before you follow this guide, it is advisable that you have the ability to
|
||||
|
|
@ -130,17 +130,16 @@ gets put inside CBFS.
|
|||
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.
|
||||
menu to switch to, if present. This contrasts behaviour in older revisions.
|
||||
|
||||
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`.
|
||||
You can find `grub.cfg` under cbmk (for this purpose, it's best to use the
|
||||
cbmk one, not the release one - unless you're using a release image).
|
||||
Find it at path (in current cbmk): `config/grub/config/grub.cfg`.
|
||||
|
||||
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.
|
||||
|
||||
In Libreboot 20230625 and older, GRUB memdisk always loaded the config from
|
||||
In older revisions of Canoeboot, 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
|
||||
|
|
|
|||
|
|
@ -33,9 +33,7 @@ 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 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>
|
||||
GNU+Linux kernel), this can greatly improve system security.
|
||||
|
||||
For your reference: a reproducible build is one where, given a precise (and
|
||||
well documented) development setup, the exact same binary can be produced each
|
||||
|
|
|
|||
|
|
@ -6,6 +6,34 @@ x-toc-enable: true
|
|||
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.
|
||||
|
||||
Regarding FSF-endorsed distros
|
||||
------------------------------
|
||||
|
||||
These guides will often make reference to mainstream distros for the sake
|
||||
of completeness, especially to newcomers who will be familiar with them, but some
|
||||
users may prefer a GNU+Linux distro endorsed by the Free Software Foundation
|
||||
as per the *GNU Free System Distribution Guidelines*. See:
|
||||
<https://www.gnu.org/distros/> - just know that, these distros are entirely
|
||||
blob-free, including the kernel; they use a special kernel called *linux-libre*,
|
||||
which strips out all binary firmwares. What this means is that these distros
|
||||
may not work correctly with all hardware (think wifi adapters, modern graphics
|
||||
cards and so on). A *lot* of hardware needs binary blobs to function, so
|
||||
watch out!
|
||||
|
||||
The Free Software Foundation maintains this website:
|
||||
<https://h-node.org/>
|
||||
|
||||
The *h-node* website is a volunteer-run database of hardware known to work
|
||||
with *deblobbed* kernels like (and including) linux-libre.
|
||||
|
||||
If you want good wireless support *and* you want linux-libre, the following
|
||||
cards are known to work well: any Atheros/Qualcomm card using
|
||||
the `ath5k`, `ath9k` or `ath9k_htc` driver in the kernel. You can find these
|
||||
on the H-Node website.
|
||||
|
||||
GNU GRUB
|
||||
--------
|
||||
|
||||
This page is useful for those who wish to use the GRUB GRUB payload directly.
|
||||
If you're using SeaBIOS, the boot process will work similarly to traditional
|
||||
BIOS systems; refer to the SeaBIOS documentation
|
||||
|
|
@ -46,6 +74,14 @@ Then still as root, do these commands:
|
|||
export PATH="$PATH:/sbin"
|
||||
update-grub
|
||||
|
||||
NOTE: `update-grub` is very much Debian-centric. Not all distros will have it.
|
||||
On Arch-based distros for instance, you might do:
|
||||
|
||||
grub-mkconfig -o /boot/grub/grub.cfg
|
||||
|
||||
The `update-grub` command is provided on Debian for user convenience, but on
|
||||
all distros, you may want to just use `grub-mkconfig`. Use what works for you.
|
||||
|
||||
Now your distro's GRUB menu should work, when your distro's GRUB bootloader is
|
||||
executed from Canoeboot's SeaBIOS payload.
|
||||
|
||||
|
|
@ -93,7 +129,7 @@ has argon2 support, but older releases only supported PBKDF2 which would make
|
|||
LUKS2 dysfunctional unless you swapped it to use PBKDF2 (not argon2) and/or
|
||||
downgraded to LUKS1.
|
||||
|
||||
With modern Canoeboot, you can just use LUKS2 as-is, on most/all Linux distros.
|
||||
With modern Canoeboot, you can just use LUKS2 as-is, on most/all GNU+Linux distros.
|
||||
At the time of the Canoeboot 20231026 release, the GRUB upstream (on gnu.org)
|
||||
did not have these argon2 patches in its source tree, but Canoeboot merges and
|
||||
maintains them out of tree.
|
||||
|
|
|
|||
|
|
@ -75,6 +75,9 @@ affects the GPU configuration and the number of available SPI flash footprints:
|
|||
- LA-3805P: iGPU, single SPI flash (4MiB)
|
||||
- LA-3806P: dGPU, unknown SPI configuration (likely at least 4MiB)
|
||||
|
||||
NOTE: dGPU variants are not supported in Canoeboot. Those are the ones with
|
||||
Nvidia graphics. Canoeboot *only* supports the model with Intel graphics.
|
||||
|
||||
These PCB numbers can be found either under the black plastic in the RAM slots
|
||||
on the bottom (CPU side) of the board, the top left corner near the VGA port
|
||||
(top side, under the keyboard and palmrest), or near the CPU backplate (only
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ will update both the BIOS and EC version. See:
|
|||
- [../install/#flashprog](../install/#flashprog)
|
||||
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
NOTE: this can only be done when you are using Lenovo BIOS. How to
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ for building a high-powered workstation. Powered by Canoeboot.
|
|||
Flashing instructions can be found at
|
||||
[../install/\#flashprog](../install/)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
Form factor {#formfactor}
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Current issues {#issues}
|
|||
can put a kernel in CBFS or on SATA and boot from that, which
|
||||
can be on a SAS drive. The linux kernel can use those SAS drives
|
||||
(via PIKE module) without an option ROM).
|
||||
- SeaBIOS lacked serial console support out-of-the-box in Libreboot 20160907
|
||||
- SeaBIOS lacked serial console support out-of-the-box in GNU Libreboot 20160907
|
||||
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)
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ MacBook2,1 can always be flashed internally, even if running Apple firmware:
|
|||
|
||||
sudo flashprog -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w your.rom
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
The MacBook1,1 can't be flashed internally if running the Apple EFI firmware.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
|
|||
Flashing instructions can be found at
|
||||
[../install/\#flashprog](../install/#flashprog)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
EC update {#ecupdate}
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
|
|||
Flashing instructions can be found at
|
||||
[../install/\#flashprog](../install/#flashprog)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
EC update {#ecupdate}
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
|
|||
Flashing instructions can be found at
|
||||
[../install/\#flashprog](../install/#flashprog)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
EC update {#ecupdate}
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
|
|||
Flashing instructions can be found at
|
||||
[../install/\#flashprog](../install/#flashprog)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
EC update {#ecupdate}
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ X200S та X201S; знову ж таки, це неперевірено. *Шви
|
|||
Інструкції з перепрошивки можна знайти за адресою
|
||||
[../install/\#flashprog](../install/#flashprog)
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
Оновлення EC {#ecupdate}
|
||||
|
|
|
|||
|
|
@ -23,14 +23,14 @@ 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).
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom, but the chromium fork
|
||||
is another fork of flashrom, and you should use that on chromebooks.
|
||||
|
||||
Depthcharge payload (obsolete)
|
||||
------------------------------
|
||||
|
||||
This board was also supported in Libreboot 20160907, with the Depthcharge
|
||||
This board was also supported in GNU 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*).
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Use this to find out:
|
|||
|
||||
flashprog -p internal
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
Flashing instructions {#clip}
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ now. The `flashprog` 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.
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
NOTE: BSD is mentioned above, but the only BSD tested for `dell-flash-unlock`
|
||||
|
|
|
|||
|
|
@ -66,5 +66,5 @@ 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
|
||||
you flash both chips!
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
|
|
|||
|
|
@ -3,11 +3,10 @@ title: ich9utils
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
**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**
|
||||
**THIS PAGE IS OBSOLETE. No Canoeboot releases have ever used ich9utils in
|
||||
any way, instead opting for use of the newer nvmutil. This documentation is
|
||||
a relic from Libreboot, upon which Canoeboot is based, and provided for
|
||||
historical purposes (Libreboot also uses nvmutil these days).**
|
||||
|
||||
**If all you want to do is change the MAC address, you might use `nvmutil`
|
||||
instead. See: [nvmutil documentation](../install/nvmutil.md).**
|
||||
|
|
@ -78,7 +77,14 @@ ich9utils
|
|||
|
||||
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/`.
|
||||
so), and find it under `util/ich9utils/`. NOTE: And I *do say Libreboot* intentionally, because
|
||||
no Canoeboot release has ever included ich9utils, which was originally written
|
||||
to handle the ThinkPad X200; Canoeboot and Libreboot now include the IFD and
|
||||
GbE pre-generated (it's config data), and can be re-generated using the
|
||||
bincfg utility in coreboot, or indeed ich9utils! Modern Canoeboot uses nvmutil
|
||||
for changing the GbE MAC address.
|
||||
|
||||
Anyway, back to Libreboot:
|
||||
|
||||
Go in there and type `make` to get the binaries: `ich9deblob`, `ich9gen`
|
||||
and `ich9show`.
|
||||
|
|
|
|||
|
|
@ -310,6 +310,15 @@ example of the push pin as a proof of concept:
|
|||
|
||||
#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashrom_lenovobios}
|
||||
|
||||
The sections below will tell you to use staticly linked executables built from
|
||||
Libreboot 20160907 sources, because no Libreboot or Libreboot-based release since
|
||||
then (at least as of 8 May 2024) has provided these, but the ones in
|
||||
Libreboot 20160907 will still work just fine. Libreboot 20160907 is GNU FSDG
|
||||
compliant (it was even one of the three *GNU Libreboot* releases), so FSF fans
|
||||
needn't worry. There won't be any magic numbers. Though, gdb symbols were
|
||||
accidentally not turned off during build so those binaries are quite huge. That's
|
||||
just about the only idiosyncrasy.
|
||||
|
||||
**NOTE: the section below pertaining to Libreboot 20160907 static binaries references
|
||||
flashrom. Canoeboot recommends flashprog nowadays, but if you're using that
|
||||
utils archive, please note that it is from a time when Canoeboot used
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ entire next section to it:
|
|||
Use flashprog
|
||||
------------
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
If you wish to operate on the GbE section that's already
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Use this to find out:
|
|||
|
||||
flashprog -p internal
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
MAC address {#macaddress}
|
||||
|
|
|
|||
|
|
@ -51,7 +51,8 @@ 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.
|
||||
but that is not needed for following this guide; Canoeboot will not provide
|
||||
that firmware because it's non-free and would therefore violate GNU FSDG policy.
|
||||
|
||||
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,
|
||||
|
|
@ -62,11 +63,6 @@ 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>
|
||||
|
||||
You can also find the source code for these, under `src/` in Canoeboot release
|
||||
archives (source code tarball), and/or under `src/` in `cbmk.git` if downloading
|
||||
using the build instructions below.
|
||||
|
|
@ -473,7 +469,7 @@ script is also applicable to newer ubuntu versions
|
|||
If the `ubuntu2004` script complains about missing dependencies, just modify
|
||||
the dependencies config to remove those dependencies. The script is located
|
||||
at `config/dependencies/ubuntu2004` and it is written for
|
||||
Ubuntu 20.04, but it should work fine in other Linux distributions that use
|
||||
Ubuntu 20.04, but it should work fine in other GNU+Linux distributions that use
|
||||
the `apt-get` package manager.
|
||||
|
||||
A `flashprog/` directory will be present, with a `flashprog` executable inside
|
||||
|
|
|
|||
|
|
@ -43,14 +43,9 @@ 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,
|
||||
Copy the relevant `.uf2` file 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
|
||||
|
|
@ -60,8 +55,8 @@ 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.
|
||||
at `bin/serprog_rp2040/serprog_pico.uf2`. Canoeboot provides these builds
|
||||
in releases.
|
||||
|
||||
Disconnect the Pico and proceed to wire it to your
|
||||
[flash chip](/docs/install/spi.html#identify-which-flash-type-you-have).
|
||||
|
|
@ -314,9 +309,9 @@ RPi 的自由固件
|
|||
|
||||
Flashrom 是用来读出、擦除、重写 NOR flash 内容的软件。
|
||||
|
||||
使用 Git 仓库中的 canoeboot 构建系统，你可以下载并安装 flashprog。首先下载 [lbmk Git 仓库](https://codeberg.org/libreboot/lbmk)，然后执行：
|
||||
使用 Git 仓库中的 canoeboot 构建系统，你可以下载并安装 flashprog。首先下载 [cbmk Git 仓库](https://codeberg.org/canoeboot/cbmk)，然后执行：
|
||||
|
||||
cd lbmk
|
||||
cd cbmk
|
||||
sudo ./build dependencies ubuntu2004
|
||||
|
||||
注意：你可以输入 debian、arch 或 void 来替换 ubuntu。debian 脚本也可以用于新版 ubuntu。
|
||||
|
|
@ -687,7 +682,7 @@ WSON8 IC：\
|
|||
|
||||
本页面及其照片，以 [CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt) 发布。请检查 Git 仓库历史，了解本文档何部分归谁所有。
|
||||
|
||||
部分这些资源源自于*旧的* Canoeboot git 仓库，Canoeboot 随后分离成了单独的仓库，包括 `lbmk` 仓库。
|
||||
部分这些资源源自于*旧的* Canoeboot git 仓库，Canoeboot 随后分离成了单独的仓库，包括 `cbmk` 仓库。
|
||||
|
||||
展示了 BeagleBone Black 的照片，以 GNU Free Documentation License 许可，如同本网站的其他页面和图像。如果你想的话，你也可以在 CC-BY-SA 4.0 下使用它们（我，Leah Rowe，拥有本页展示的全部 BBB 照片的所有权，除了 beaglebone 网站上的那一张以外；而那一张只是在这里链接的，而不是托管在 av.canoeboot.org 服务器的）。
|
||||
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ sudo ldto merge spicc spicc-spidev
|
|||
Using Flashprog
|
||||
==============
|
||||
|
||||
Some linux distros will provide flashprog in their default repositories.
|
||||
Some GNU+Linux distros will provide flashprog in their default repositories.
|
||||
|
||||
```
|
||||
sudo apt update
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Flashing the ThinkPad T400 externally
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
Dell Latitude E6400
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: ThinkPad T500 external flashing
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
**If you haven't bought a T500 yet: the [Dell Latitude
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: ThinkPad T60 Recovery guide
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
This section documents how to recover from a bad flash that prevents
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: First-time ThinkPad X200 flashing
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
**If you haven't bought an X200 yet: the [Dell Latitude
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Прошивка ThinkPad X200 вперше
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
NOTE: Canoeboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
|
||||
now, as of 3 May 2024, which is a fork of flashrom.
|
||||
|
||||
**If you haven't bought an X200 yet: the [Dell Latitude
|
||||
|
|
|
|||
|
|
@ -9,9 +9,7 @@ now, as of 3 May 2024, which is a fork of flashrom.
|
|||
In addition to this manual, you should also refer to [porting.md](porting.md)
|
||||
and [testing.md](testing.md).
|
||||
|
||||
Please also read about the [cbmk coding style and design](style.md). This
|
||||
document, and the cbmk build system, is a direct fork of *lbmk*, which is the
|
||||
[Libreboot](https://libreboot.org/) build system.
|
||||
Please also read about the [cbmk coding style and design](style.md).
|
||||
|
||||
Automated coreboot build system
|
||||
===============================
|
||||
|
|
@ -24,9 +22,9 @@ for **C**anoe**B**oot **M**a**K**e).
|
|||
|
||||
The homepage of Canoeboot says that Canoeboot is a *coreboot distro*, providing
|
||||
the necessary integration of coreboot, payloads and utilities so as to provide
|
||||
releases, much like Linux distros do for your operating system, but here we are
|
||||
releases, much like GNU+Linux distros do for your operating system, but here we are
|
||||
concerned about the *boot firmware* instead. Canoeboot is to coreboot, what
|
||||
Debian is to Linux. It provides easier, more automated configuration and
|
||||
Trisquel is to GNU+Linux. It provides easier, more automated configuration and
|
||||
installation.
|
||||
|
||||
The build system, cbmk, *is* that coreboot distro, at its very core. You can
|
||||
|
|
@ -60,6 +58,15 @@ build system itself, to make your own private modifications or even release
|
|||
your own coreboot distro (based upon Canoeboot - and you have this freedom
|
||||
with Libreboot too). Many choices are available!
|
||||
|
||||
Some of the more seasoned FSF fanatics may not like this, but it's simply
|
||||
more efficient to work on Libreboot first and port to Canoeboot afterward. It
|
||||
is essentially no different to the Trisquel development model, where development
|
||||
from each new Ubuntu releases is adapted for new Trisquel releases; and Trisquel
|
||||
has a policy of providing its own builds for everything, rather than directly
|
||||
using Ubuntu's own builds - so too does Canoeboot provide its own builds, without
|
||||
using any of the builds provided in Libreboot releases. Same sh\*\*, different
|
||||
smell. Just plug your nose or something.
|
||||
|
||||
Environmental variables
|
||||
=======================
|
||||
|
||||
|
|
@ -103,7 +110,13 @@ you're reading now, is available as the [lbmk maintenance
|
|||
manual](https://libreboot.org/docs/maintain/); since Canoeboot is based on
|
||||
Libreboot, you may find it useful to know *Libreboot*. This and the lbmk manual,
|
||||
in addition to Canoeboot vs Libreboot generally, are two sides of the same coin,
|
||||
and both projects are lead by the same developer (Leah Rowe).
|
||||
and both projects are lead by the same developer (Leah Rowe). Libreboot and
|
||||
Canoeboot are light and dark, but which is which depends on your perspective.
|
||||
|
||||
As stated elsewhere, the preference is for most/all development to go in
|
||||
Libreboot first, because Canoeboot simply re-bases patches from Libreboot.
|
||||
This is done, to reduce duplication of labour, since both projects are
|
||||
maintained by the same developer.
|
||||
|
||||
The follow sections will cover subdirectories, within cbmk. Contrary to what
|
||||
some may otherwise assume, it's best to learn about everything *except* scripts
|
||||
|
|
@ -529,7 +542,7 @@ other than `default`, which is the default if the option is missing.
|
|||
The `grub_scan_disk` option specifies can be `ahci`, `ata` or `both`, and it
|
||||
determines which types of disks are to be scanned, when the `grub.cfg` file in
|
||||
GRUB payloads tries to automatically find other `grub.cfg` files supplied by
|
||||
your Linux distribution. On some machines, setting it to `ata` or `ahci`
|
||||
your GNU+Linux distribution. On some machines, setting it to `ata` or `ahci`
|
||||
can improve boot speed by reducing delays; for example, trying to scan `ata0`
|
||||
on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that
|
||||
machine it is advisable to set this option to `ahci` (becuse the default HDD
|
||||
|
|
@ -1173,7 +1186,6 @@ than `release`. For example:
|
|||
|
||||
If `-d` is not passed, they will go under `release/` in your cbmk repository.
|
||||
The script is engineered to re-initialise git if ran from a release archive.
|
||||
Canoeboot releases after 20230625 include `.gitignore` in the src archive.
|
||||
|
||||
This builds release archives, containing ROM images for coreboot and/or serprog
|
||||
programmers. It works simply: cbmk clones *itself*, and builds itself in its
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ 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.
|
||||
based (Canoeboot's version is called *cbmk*, short for CanoeBoot MaKe).
|
||||
|
||||
Here is an *excellent* introduction to posix `sh` scripting:
|
||||
<https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html>
|
||||
|
|
|
|||
|
|
@ -7,6 +7,9 @@ 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 Canoeboot; it is
|
||||
even older now. It's almost a tradition now, that this page is never updated.
|
||||
|
||||
You should assume that these instructions no longer work. Otherwise, if you
|
||||
wish to test them and send changes, patches are very much welcome!
|
||||
|
||||
High Pitched Whining Noise on Idle in Arch-based distros
|
||||
==============================================================
|
||||
|
||||
|
|
@ -93,8 +96,8 @@ 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.
|
||||
|
||||
The following guide is for Ubuntu, but it should work in Debian and
|
||||
Devuan, to enable a serial console using GeTTY:\
|
||||
The following guide is for Ubuntu, but it should work in Debian-based distros,
|
||||
Devuan, Trisquel etc, to enable a serial console using GeTTY:\
|
||||
<https://help.ubuntu.com/community/SerialConsoleHowto>
|
||||
|
||||
Note: part of the tutorial above requires changing your grub.cfg. Just
|
||||
|
|
@ -237,8 +240,8 @@ Get the panel name:
|
|||
|
||||
Or look in `/sys/class/drm/card0-LVDS-1/edid`
|
||||
|
||||
Alternatively you can use i2cdump. In Debian and Devuan, this is in the
|
||||
package i2c-tools.
|
||||
Alternatively you can use i2cdump. In Debian-based distros or Trisquel, this is
|
||||
in the package i2c-tools.
|
||||
|
||||
sudo modprobe i2c-dev
|
||||
sudo i2cdump -y 5 0x50 (you might have to change the value for -y)
|
||||
|
|
|
|||
|
|
@ -3,12 +3,11 @@ title: U-Boot payload
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
+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
|
||||
Canoeboot has experimental support for using U-Boot as a coreboot payload.
|
||||
Refer to [docs/hardware/](../hardware/) for a complete list of U-Boot
|
||||
targets in Libreboot. Canoeboot inherited 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
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@ x-toc-enable: true
|
|||
Background
|
||||
==========
|
||||
|
||||
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.
|
||||
|
||||
The following process should theoretically be applicable to other U-Boot devices and GNU/Linux distributions, but the focus here is specifically on ArchLinuxARM.
|
||||
|
||||
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)
|
||||
|
|
|
|||
|
|
@ -475,12 +475,6 @@ 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).
|
||||
|
||||
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?
|
||||
--------------------------------------------------------------------------------------------------------
|
||||
|
||||
|
|
@ -803,9 +797,6 @@ 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
|
||||
|
|
|
|||
14
site/git.md
14
site/git.md
|
|
@ -13,6 +13,10 @@ 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).
|
||||
|
||||
Exceptions are often made. Since only a subset of Libreboot changes are suitable
|
||||
for Canoeboot at any given time, the result is that a given Libreboot release
|
||||
may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
|
||||
|
||||
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.
|
||||
|
|
@ -21,6 +25,16 @@ 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).
|
||||
|
||||
While not everyone(especially the more hardened FSF fanatics) may not like it,
|
||||
this is how Canoeboot is more developed. It is essentially no different
|
||||
to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
|
||||
simply more efficient, enabling a general reduction in the duplication of labour.
|
||||
|
||||
Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
|
||||
enables a tight grip on both projects, ensuring that they are always in
|
||||
absolutely perfect sync with each other (with the exception that Canoeboot
|
||||
will only include those changes which comply with GNU FSDG criteria).
|
||||
|
||||
Canoeboot repositories
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -13,6 +13,10 @@ 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).
|
||||
|
||||
Exceptions are often made. Since only a subset of Libreboot changes are suitable
|
||||
for Canoeboot at any given time, the result is that a given Libreboot release
|
||||
may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
|
||||
|
||||
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.
|
||||
|
|
@ -21,6 +25,16 @@ 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).
|
||||
|
||||
While not everyone(especially the more hardened FSF fanatics) may not like it,
|
||||
this is how Canoeboot is more developed. It is essentially no different
|
||||
to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
|
||||
simply more efficient, enabling a general reduction in the duplication of labour.
|
||||
|
||||
Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
|
||||
enables a tight grip on both projects, ensuring that they are always in
|
||||
absolutely perfect sync with each other (with the exception that Canoeboot
|
||||
will only include those changes which comply with GNU FSDG criteria).
|
||||
|
||||
репозиторії Canoeboot
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Tatsächlich versucht Canoeboot so nah am regulären Coreboot zu bleiben wie mö
|
|||
für jedes Board, aber mit vielen automatisch durch das Canoeboot Build System zur
|
||||
Verfügung gestellten verschiedenen Konfigurationstypen.
|
||||
|
||||
Ebenso wie *Alpine Linux* eine *Linux Distribution* ist, ist Canoeboot eine
|
||||
Ebenso wie *Trisquel* eine *GNU+Linux Distribution* ist, ist Canoeboot eine
|
||||
*Coreboot Distribution*. Sofern Du ein ROM Image von Grund auf herstellen möchtest,
|
||||
musst Du zunächst Konfigurationen auf Experten Level durchführen,
|
||||
und zwar für Coreboot, GRUB sowie sämtliche Software die Du sonst noch verwenden
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ pas de fournir un Coreboot déblobbé; ceci n'est simplement qu'une
|
|||
des politiques de Canoeboot, une importante certes, mais qui n'est qu'un
|
||||
aspect mineur de Canoeboot.
|
||||
|
||||
De la même façon que *Alpine Linux* est une distribution Linux, Canoeboot
|
||||
De la même façon que *Trisquel* est une distribution GNU+Linux, Canoeboot
|
||||
est une *distribution coreboot*. Si vous voulez compilé une image ROM
|
||||
en partant des bases, vous devez alors effectuer une configuration experte
|
||||
de Coreboot, GRUB et n'importe quel autre logiciel dont vous avez besoin
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ In effetti, Canoeboot tenta di essere il piu' possibile simile alla versione *uf
|
|||
per ogni scheda, ma con diversi tipi di configurazione forniti automaticamente dal sistema di
|
||||
compilazione automatico di Canoeboot.
|
||||
|
||||
Esattamente come *Alpine Linux* e' una *distribuzione Linux*, Canoeboot e' una
|
||||
Esattamente come *Trisquel* e' una *distribuzione GNU+Linux*, Canoeboot e' una
|
||||
*distribuzione coreboot*. Per fare un immagine ROM da zero, hai bisogno di esperienza necessaria
|
||||
nel configurare coreboot, GRUB e qualunque altra cosa ti serve. Con *Canoeboot*,
|
||||
che puoi scaricare da Git o da un archivio di codici sorgenti, puoi far partire `make`,
|
||||
|
|
|
|||
|
|
@ -28,8 +28,7 @@ and [better security](docs/gnulinux/grub_hardening.md). It's extremely powerful
|
|||
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
|
||||
ensuring that everything in the boot flash is *free software*. *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
|
||||
|
|
@ -67,7 +66,7 @@ In fact, Canoeboot tries to stay as close to *stock* coreboot as possible,
|
|||
for each board, but with many different types of configuration provided
|
||||
automatically by the Canoeboot build system.
|
||||
|
||||
In the same way that *Alpine Linux* is a *Linux distribution*, Canoeboot is
|
||||
In the same way that *Trisquel* is a *GNU+Linux distribution*, Canoeboot is
|
||||
a *coreboot distribution*. If you want to build a ROM image from scratch, you
|
||||
otherwise have to perform expert-level configuration of coreboot, GRUB and
|
||||
whatever other software you need, to prepare the ROM image. With *Canoeboot*,
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ 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>
|
||||
|
||||
Таким же самим чином, як *Debian* це дистрибутив Linux, Canoeboot це
|
||||
Таким же самим чином, як *Trisquel* це дистрибутив Linux, Canoeboot це
|
||||
*дистрибутив coreboot*. Якщо ви хочете зібрати образ ROM з нуля, вам
|
||||
інакше довелось би виконати налаштування експертного рівня coreboot, GRUB та
|
||||
будь-якого іншого потрібного програмного забезпечення, для підготування образа ROM. З *Canoeboot*,
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Canoeboot 不是 coreboot 的分支
|
|||
|
||||
事实上，Canoeboot 对每一块主板，都尽可能保持与*标准*的 coreboot 接近，但 Canoeboot 构建系统也自动提供了许多不同类型的配置。
|
||||
|
||||
Canoeboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Canoeboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `cbmk`（Canoeboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
|
||||
Canoeboot 是一个 *coreboot 发行版*，就好比 *Trisquel* 是一个 *GNU+Linux 发行版*。如果你想要从零开始构建 ROM 镜像，那你需要对 coreboot、GRUB 以及其他所需软件进行专业级别的配置，才能准备好 ROM 镜像。有了 *Canoeboot*，你只需要下载 Git 仓库或者源代码归档，然后运行 `make`，接着就能构建整个 ROM 镜像。一套自动构建系统，名为 `cbmk`（Canoeboot Make），将自动构建 ROM 镜像，而无需任何用户输入或干预。配置已经提前完成。
|
||||
|
||||
如果你要构建常规的 coreboot，而不使用 Canoeboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,6 @@ 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
|
||||
versions. A version of that is also provided in `cbmk.git` as a GRUB
|
||||
background, and under `cbwww.git` as the favicon icon for the Canoeboot website
|
||||
hosted at *canoeboot.org*.
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@ Introduction
|
|||
============
|
||||
|
||||
*This* new release, Canoeboot 20231026, released today 26 October 2023, is
|
||||
based on the [Libreboot 20231021](https://libreboot.org/news/libreboot20231021.html)
|
||||
release.
|
||||
based on Libreboot 20231021.
|
||||
|
||||
Canoeboot provides boot firmware for supported x86/ARM machines, starting a
|
||||
bootloader that then loads your operating system. It replaces proprietary
|
||||
|
|
@ -35,8 +34,7 @@ firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/gnulinux/)
|
|||
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).
|
||||
as policy, ensuring that all of the software provided by it is *free software*.
|
||||
|
||||
Work done since last release
|
||||
============================
|
||||
|
|
@ -83,21 +81,13 @@ 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.
|
||||
TWO massive audits. 50% code size reduction in cbmk.
|
||||
--------------------------------------------
|
||||
|
||||
Libreboot's build system, lbmk, is written entirely in shell scripts. It is
|
||||
Canoeboot's build system, cbmk, 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.
|
||||
images that are easier to install.
|
||||
|
||||
The primary focus of Libreboot 20231021 cultiminated in two *audits*, namely
|
||||
[Libreboot Build System Audit 2](https://libreboot.org/news/audit2.html) and
|
||||
|
|
@ -112,7 +102,7 @@ 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
|
||||
In addition to coreboot firmware, the Canoeboot build system (cbmk) can now
|
||||
build *serprog* firmware, specifically `pico-serprog` and `stm32-vserprog`, on
|
||||
all devices that these projects support.
|
||||
|
||||
|
|
@ -203,7 +193,7 @@ mostly the results of the two audits (mentioned above):
|
|||
* 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
|
||||
* Always re-inialitise `.git` within cbmk, 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
|
||||
|
|
@ -227,7 +217,7 @@ mostly the results of the two audits (mentioned above):
|
|||
* 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)
|
||||
project is multi-tree within cbmk)
|
||||
* 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,
|
||||
|
|
@ -238,7 +228,7 @@ mostly the results of the two audits (mentioned above):
|
|||
* 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
|
||||
re-created by the release script, because it clones the current cbmk 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
|
||||
|
|
@ -252,11 +242,9 @@ mostly the results of the two audits (mentioned above):
|
|||
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,
|
||||
little memory available; clone into `tmp/gitclone` instead, within cbmk,
|
||||
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
|
||||
|
|
@ -266,7 +254,7 @@ mostly the results of the two audits (mentioned above):
|
|||
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
|
||||
broken on a lot of distros nowadays, and cbmk 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.
|
||||
|
|
@ -298,7 +286,7 @@ mostly the results of the two audits (mentioned above):
|
|||
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
|
||||
* Running as root is now forbidden, for most commands; cbmk 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.
|
||||
|
|
@ -306,7 +294,7 @@ mostly the results of the two audits (mentioned above):
|
|||
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
|
||||
cbmk) 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.
|
||||
|
|
@ -315,20 +303,18 @@ mostly the results of the two audits (mentioned above):
|
|||
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
|
||||
in cbmk. 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.
|
||||
to `cbmk.git` as author named `cbmkplaceholder`.
|
||||
* 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 from cbmk 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.
|
||||
own exit function called `cbmk_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
|
||||
|
|
@ -340,8 +326,8 @@ mostly the results of the two audits (mentioned above):
|
|||
* 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
|
||||
* NO MAKEFILE. The Makefile in cbmk has been removed. It was never meaningfully
|
||||
used because all it did was run cbmk 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,
|
||||
|
|
@ -373,14 +359,13 @@ mostly the results of the two audits (mentioned above):
|
|||
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.
|
||||
variable set (and exported) by cbmk.
|
||||
* 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,
|
||||
variable) and exported to all child processes running cbmk 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
|
||||
|
|
@ -397,11 +382,11 @@ mostly the results of the two audits (mentioned above):
|
|||
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,
|
||||
verbosely. *Many* fault conditions previously did not make cbmk *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
|
||||
3000 source lines (of C code) from cbmk. 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
|
||||
|
|
@ -443,8 +428,8 @@ mostly the results of the two audits (mentioned above):
|
|||
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
|
||||
when running cbmk; child processes inherit it, and a single tmp dir is used.
|
||||
This is then automatically cleaned, upon exit from cbmk; previously, cbmk did
|
||||
not cleanly handle `/tmp` at all, but now it's pretty reliable.
|
||||
|
||||
Hardware supported in this release
|
||||
|
|
@ -516,9 +501,8 @@ 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.
|
||||
scripts of the build system; considerably smaller than older revisions,
|
||||
accounting for an approximate *50% reduction* in the amount of code.
|
||||
|
||||
That ~1250 sloc in Canoeboot is *with* all the extra features such as serprog
|
||||
integration and U-Boot support (on actual mainboards, that you can flash it
|
||||
|
|
@ -542,82 +526,11 @@ after the Libreboot 20231021 release came out:
|
|||
* <https://browse.libreboot.org/lbmk.git/commit/?id=df031d422a1c0b76edbea1cdee98796ad3d1392f>
|
||||
* <https://browse.libreboot.org/lbmk.git/commit/?id=5f6ba01d414e2d98d7db049347b8c5c5d125ba61>
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
the Libreboot 20231021 release; this is because they do not comply with GNU FSDG
|
||||
policy:
|
||||
|
||||
* Dell Latitude E6430
|
||||
|
|
@ -640,87 +553,6 @@ policy:
|
|||
* 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.
|
||||
|
||||
I say again. Canoeboot is inferior. An inferior, but well-engineered monster.
|
||||
|
||||
[Download Libreboot 20231021 instead](https://libreboot.org/news/libreboot20231021.html).
|
||||
|
||||
Post-release errata
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,11 @@
|
|||
% Leah Rowe in Canoe Leah Mode™
|
||||
% 1 November 2023
|
||||
|
||||
A corresponding [Libreboot 20231101
|
||||
release](https://libreboot.org/news/libreboot20231101.html) is also available.
|
||||
Simultaneous same-day release!
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
*This* new release, Canoeboot 20231101, released today 1 November 2023, is
|
||||
based on the [Libreboot 20231101](https://libreboot.org/news/libreboot20231101.html)
|
||||
release, porting changes in it on top of
|
||||
based on the Libreboot 20231101 release, porting changes in it on top of
|
||||
[Canoeboot 20231026](canoeboot20231026.md) as a base. The previous
|
||||
release was Canoeboot 20231026, released on 26 October 2023.
|
||||
|
||||
|
|
@ -41,8 +36,7 @@ firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/gnulinux/)
|
|||
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).
|
||||
as policy, ensuring that everything in the boot flash is entirely *free software*.
|
||||
|
||||
Work done since last release
|
||||
============================
|
||||
|
|
|
|||
|
|
@ -37,8 +37,7 @@ firmware, but not Canoeboot! Booting Linux/BSD is also [well](../docs/gnulinux/)
|
|||
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).
|
||||
as policy, ensuring that everything in the boot flash is entirely *free software*.
|
||||
|
||||
Work done since last release
|
||||
============================
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@ Introduction
|
|||
============
|
||||
|
||||
*This* new release, Canoeboot 20231107, released today 7 November 2023, is
|
||||
based on the recent
|
||||
[Libreboot 20231106](https://libreboot.org/news/libreboot20231106.html) release.
|
||||
based on the recent Libreboot 20231106 release.
|
||||
The previous release was [Canoeboot 20231103](canoeboot20231103.md), released
|
||||
on 3 November 2023. Today's release has focused
|
||||
on minor bug fixes, plus tweaks to the GRUB payload. It imports certain fixes
|
||||
|
|
|
|||
|
|
@ -2,25 +2,17 @@
|
|||
% Leah Rowe
|
||||
% 4 May 2024
|
||||
|
||||
A simultaneous [Libreboot 20240504
|
||||
release](https://libreboot.org/news/libreboot20240504.html) is also available.
|
||||
Canoeboot *skipped* the January 2024 and February 2024 testing releases of
|
||||
Libreboot, because I knew I would do a new stable Libreboot release during
|
||||
May 2024. Therefore, the changelog below is relative to November 2023
|
||||
releases of Canoeboot/Libreboot, whereas today's Libreboot release announcement
|
||||
is relative to February 2024 when the last Libreboot release was.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Canoeboot is a free/open source BIOS/UEFI replacement on x86 and ARM, providing
|
||||
boot firmware that initialises the hardware in your computer, to then load an
|
||||
operating system (e.g. Linux/BSD). It is specifically a *coreboot distribution*,
|
||||
in the same way that Debian is a Linux distribution. It provides an automated
|
||||
in the same way that Trisquel is a GNU+Linux distribution. It provides an automated
|
||||
build system to produce coreboot ROM images with a variety of payloads such as
|
||||
GNU GRUB or SeaBIOS, with regular well-tested releases to make coreboot as easy
|
||||
to use as possible for non-technical users. From a project management perspective,
|
||||
this works in *exactly* the same way as a Linux distro, providing the same type
|
||||
this works in *exactly* the same way as a GNU+Linux distro, providing the same type
|
||||
of infrastructure, but for your boot firmware instead of your operating system.
|
||||
It makes use of [coreboot](https://www.coreboot.org/) for hardware initialisation,
|
||||
and then a payload such as [SeaBIOS](https://www.seabios.org/SeaBIOS)
|
||||
|
|
@ -52,7 +44,7 @@ These and other examples are just the start. Canoeboot provides a *superior* boo
|
|||
experience compared to proprietary BIOS/UEFI, giving you the same power and level of
|
||||
control that running a Linux or BSD operating system does. It's *your* computer
|
||||
to boot however you wish. Canoeboot lets you get more out of the hardware. All
|
||||
your favourite Linux distros and BSDs are compatible, even Qubes(on most machines).
|
||||
your favourite GNU+Linux distros are compatible, even Qubes(on most machines).
|
||||
|
||||
If you're fed up of the control that proprietary UEFI vendors have over you,
|
||||
then Canoeboot is *for you*. Although many would agree that it is a major step
|
||||
|
|
@ -65,11 +57,6 @@ be a human right that everyone *must* have, and the same is true of hardware.
|
|||
Your computer is *your property* to use as you wish. Free Software protects you,
|
||||
by ensuring that you always have control of the machine.
|
||||
|
||||
*This* new release, Canoeboot 20240504, released today 4 May 2024, is
|
||||
a new *stable* release of Canoeboot, based on today's
|
||||
simultaneous [Libreboot 20240504
|
||||
release](https://libreboot.org/news/libreboot20240504.html).
|
||||
|
||||
Hardware supported in this release
|
||||
==================================
|
||||
|
||||
|
|
@ -108,18 +95,6 @@ This release supports the following hardware:
|
|||
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
|
||||
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
|
||||
|
||||
Libreboot 20240504 also released!
|
||||
=========================
|
||||
|
||||
I've done simultaneous Canoeboot and Libreboot releases, today. I strongly
|
||||
recommend that everyone uses Libreboot, which adheres to Libreboot's own
|
||||
own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html) and therefore supports more
|
||||
boards. Canoeboot is a parallel effort, that I also maintain, but Canoeboot
|
||||
adheres to GNU FSDG as policy and therefore supports far fewer mainboards. See:
|
||||
|
||||
[Libreboot 20240504 release](https://libreboot.org/news/libreboot20240504.html)
|
||||
|
||||
Highlights
|
||||
==========
|
||||
|
||||
|
|
@ -135,10 +110,13 @@ Modest code size reduction
|
|||
|
||||
See: [Libreboot build system audit 4](https://libreboot.org/news/audit4.html)
|
||||
|
||||
These and subsequent changes are included in today's release. The build system
|
||||
These and subsequent changes were adapter for today's release. The build system
|
||||
has been further optimised, both in terms of code size and performance.
|
||||
|
||||
Canoeboot is maintained in parallel with Libreboot, by the same person.
|
||||
Canoeboot is maintained in parallel with Libreboot, by the same person, so a
|
||||
lot of code is shared back and forth between the two, while ensuring that
|
||||
Canoeboot strictly complies with the *GNU Free System Distribution Guidelines*,
|
||||
or *GNU FSDG* for short.
|
||||
|
||||
GRUB 2.12 revision now used
|
||||
---------------------------
|
||||
|
|
@ -178,23 +156,22 @@ standalone project, but some people may find this useful.
|
|||
Flashprog now used, not flashrom
|
||||
---------------------------
|
||||
|
||||
The reasoning can be found in the Libreboot 20240225 release; Canoeboot
|
||||
now inherits this change.
|
||||
|
||||
Essentially, flashprog has better leadership and is more stable than flashrom;
|
||||
flashrom has had new leadership for a while now, and in my view they are not
|
||||
doing a very good job. That is the executive summary; the full reasoning, again,
|
||||
can be found in the Libreboot 20240225 release.
|
||||
|
||||
Flashprog is superior. It is a spiritual successor of the Flashrom project that
|
||||
Libreboot previously knew and loved.
|
||||
Flashprog started due to disagreement between its founder (Nico Huber) and the
|
||||
new leadership of the flashrom project. Flashprog focusus on stability, while
|
||||
also adding newer chips all the time. Indeed, flashrom started becoming unreliable
|
||||
on a lot of older platforms such as i945 thinkpads, whereas flashprog is more
|
||||
stable.
|
||||
|
||||
Canoeboot will use flashprog from now on, not flashrom.
|
||||
|
||||
Work done since Canoeboot 20231107
|
||||
============================
|
||||
|
||||
Today's release, Canoeboot 20240504, is a stable release, as its based also
|
||||
on today's simultaneous Libreboot release, which is a stable release.
|
||||
|
||||
The following log will now acount for changes since Canoeboot 20231107, from
|
||||
most recent descending to very earliest commits. The most interesting changes
|
||||
are highlighted in bold:
|
||||
|
|
@ -246,7 +223,7 @@ are highlighted in bold:
|
|||
the board directory inside cbmk, with a message that will be printed when
|
||||
building; you can use this to warn the user about specific issues.
|
||||
* i945 targets (ThinkPad X60/T60, Macbook2,1): switch back to the February 2023
|
||||
coreboot revision used in Canoeboot 20230625 for now, to work around an issue
|
||||
coreboot revision used in Libreboot 20230625 for now, to work around an issue
|
||||
that was reported by some users; it will be updated again in a future release.
|
||||
* Export environmental variables from `err.sh`, to ensure that they are always
|
||||
exported and therefore universally consistent in all parts of cbmk, once
|
||||
|
|
@ -403,11 +380,10 @@ are highlighted in bold:
|
|||
* `grub.cfg`: Support scanning for *extlinux* configs, which are essentially the
|
||||
same as syslinux ones. If found, they are passed through GRUB's syslinux
|
||||
parser, which then presents a menu as if it were a GRUB configuration. This
|
||||
should increase compatibility with distros that use extlinux, such as
|
||||
the Alpine Linux distribution.
|
||||
should increase compatibility with distros that use extlinux.
|
||||
* `grub.cfg`: Handle GRUB *and* syslinux/extlinux configs, on the USB boot menu
|
||||
option. Now it scans for both, thus increasing compatibility with many modern
|
||||
Linux distro installers. Before this change, Canoeboot's design was made with
|
||||
GNU+Linux distro installers. Before this change, Canoeboot's design was made with
|
||||
BIOS systems in mind, because we historically only supported systems that were
|
||||
BIOS-based, whereas GRUB is more common as a bootloader on UEFI-based install
|
||||
media, but in the past we mostly assumed isolinux/syslinux for that.
|
||||
|
|
@ -420,7 +396,9 @@ are highlighted in bold:
|
|||
This will increase compatibility with a wide variety of distros, *without*
|
||||
introducing UEFI support yet on x86, because those same Linux kernels can
|
||||
also run on bare metal (and this is exactly how it works, when you use GRUB
|
||||
as a payload).
|
||||
as a payload). NOTE: This change probably doesn't benefit Canoeboot much,
|
||||
since none of the supported Canoeboot hardware implements UEFI in factory
|
||||
firmware, but this change is relatively harmless so it's included.
|
||||
* `grub.cfg`: Don't boot linux unless there is a grub.cfg file provided on
|
||||
the HDD/SSD. Previously, a fallback entry existed as a last resort, if all
|
||||
else failed, but it made several assumptions that are mostly no longer valid
|
||||
|
|
@ -442,7 +420,7 @@ are highlighted in bold:
|
|||
of Leah Rowe.
|
||||
* cbmk scripts: Did a general sweep with shellcheck, fixing errors that it
|
||||
flagged, such as lack of double quotes in some places, and non-standard
|
||||
behaviour being used. The actual [patch](https://browse.libreboot.org/cbmk.git/commit/?id=1eb4df6748f94a08d44c623a56417199b99b371d)
|
||||
behaviour being used. The actual [patch](https://browse.libreboot.org/lbmk.git/commit/?id=1eb4df6748f94a08d44c623a56417199b99b371d)
|
||||
shows what is meant by this. Patch courtesy of Leah Rowe.
|
||||
* cbmk scripts: Handle exit status correctly, when dealing with subshells. This
|
||||
continues on from the other fix below, after doing a sweep of the entire
|
||||
|
|
@ -485,8 +463,6 @@ release archives, while still permitting them to be re-built.
|
|||
|
||||
All of the following boards have been disabled in the build system:
|
||||
|
||||
D510MO and D945 images not included either, due to lack of testing.
|
||||
D510MO and D945GCLF images not included either, due to lack of testing.
|
||||
|
||||
*All other boards have ROM images in this release.*
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $if(title)$
|
|||
<header>
|
||||
<div class="title">
|
||||
<p class="title-logo">
|
||||
<img class="title-logo" alt="Libreboot logo" src="/favicon.ico" />
|
||||
<img class="title-logo" alt="Canoeboot logo" src="/favicon.ico" />
|
||||
</p>
|
||||
<h1 class="title">$title$</h1>
|
||||
</div>
|
||||
|
|
@ -77,7 +77,6 @@ $endif$
|
|||
<li><a href="https://codeberg.org/canoeboot/cbmk/issues">Bugs</a></li>
|
||||
<li><a href="/git.de.html">Patch senden</a></li>
|
||||
<li><a href="/contact.de.html">Kontakt</a></li>
|
||||
<li><strong><a href="https://libreboot.org/">Back to libreboot.org</a></strong></li>
|
||||
</ul>
|
||||
<hr/>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $if(title)$
|
|||
<header>
|
||||
<div class="title">
|
||||
<p class="title-logo">
|
||||
<img class="title-logo" alt="Libreboot logo" src="/favicon.ico" />
|
||||
<img class="title-logo" alt="Canoeboot logo" src="/favicon.ico" />
|
||||
</p>
|
||||
<h1 class="title">$title$</h1>
|
||||
</div>
|
||||
|
|
@ -77,7 +77,6 @@ $endif$
|
|||
<li><a href="https://codeberg.org/canoeboot/cbmk/issues">Bugs</a></li>
|
||||
<li><a href="/git.html">Send patch</a></li>
|
||||
<li><a href="/contact.html">Contact</a></li>
|
||||
<li><strong><a href="https://libreboot.org/">Back to libreboot.org</a></strong></li>
|
||||
</ul>
|
||||
<hr/>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $if(title)$
|
|||
<header>
|
||||
<div class="title">
|
||||
<p class="title-logo">
|
||||
<img class="title-logo" alt="Libreboot logo" src="/favicon.ico" />
|
||||
<img class="title-logo" alt="Canoeboot logo" src="/favicon.ico" />
|
||||
</p>
|
||||
<h1 class="title">$title$</h1>
|
||||
</div>
|
||||
|
|
@ -77,7 +77,6 @@ $endif$
|
|||
<li><a href="https://codeberg.org/canoeboot/cbmk/issues">Difetti (bugs)</a></li>
|
||||
<li><a href="/git.html">Spedisci correzioni (patches)</a></li>
|
||||
<li><a href="/contact.html">Contatti</a></li>
|
||||
<li><strong><a href="https://libreboot.org/">Back to libreboot.org</a></strong></li>
|
||||
</ul>
|
||||
<hr/>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $if(title)$
|
|||
<header>
|
||||
<div class="title">
|
||||
<p class="title-logo">
|
||||
<img class="title-logo" alt="Логотип Libreboot" src="/favicon.ico" />
|
||||
<img class="title-logo" alt="Логотип Canoeboot" src="/favicon.ico" />
|
||||
</p>
|
||||
<h1 class="title">$title$</h1>
|
||||
</div>
|
||||
|
|
@ -77,7 +77,6 @@ $endif$
|
|||
<li><a href="https://codeberg.org/canoeboot/cbmk/issues">Помилки</a></li>
|
||||
<li><a href="/git.uk.html">Відправити виправлення</a></li>
|
||||
<li><a href="/contact.uk.html">Зв'язок</a></li>
|
||||
<li><strong><a href="https://libreboot.org/">Back to libreboot.org</a></strong></li>
|
||||
</ul>
|
||||
<hr/>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $if(title)$
|
|||
<header>
|
||||
<div class="title">
|
||||
<p class="title-logo">
|
||||
<img class="title-logo" alt="Libreboot 图标" src="/favicon.ico" />
|
||||
<img class="title-logo" alt="Canoeboot 图标" src="/favicon.ico" />
|
||||
</p>
|
||||
<h1 class="title">$title$</h1>
|
||||
</div>
|
||||
|
|
@ -77,7 +77,6 @@ $endif$
|
|||
<li><a href="https://codeberg.org/canoeboot/cbmk/issues">缺陷</a></li>
|
||||
<li><a href="/git.html">发送补丁</a></li>
|
||||
<li><a href="/contact.html">联系</a></li>
|
||||
<li><strong><a href="https://libreboot.org/">Back to libreboot.org</a></strong></li>
|
||||
</ul>
|
||||
<hr/>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -3,8 +3,9 @@ title: Who develops Canoeboot?
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
Leah Rowe made this website for fun, based on Libreboot.
|
||||
Leah Rowe, that's who. Leah single-handedly maintains Canoeboot, re-basing
|
||||
upon newer releases of Libreboot every now and then. Leah Rowe is the founder
|
||||
and lead developer for *both* projects; Leah maintains both
|
||||
Canoeboot *and* Libreboot.
|
||||
|
||||
It is only a proof of concept. You should otherwise use Libreboot:
|
||||
|
||||
<https://libreboot.org/>
|
||||
If you have a patch, or beef, talk to Leah.
|
||||
|
|
|
|||
Loading…
Reference in New Issue