https://guix.gnu.org/feeds/blog/cross-compilation.atomGNU Guix — Blog — Cross-compilationfeed author nameGNU Guixhttps://guix.gnu.org/themes/initial/img/icon.png2024-03-20T10:57:53Zhttps://guix.gnu.org/blog/2023/building-toolchains-with-guix//Building Toolchains with GuixMitchell Schmeisser2023-03-15T16:00:00Z2023-03-15T16:00:00Z In order to deploy embedded software using Guix we first need to teach Guix
how to cross-compile it. Since Guix builds everything from source, this
means we must teach Guix how to build our cross-compilation toolchain. The Zephyr Project uses its own fork of GCC with custom configs for
the architectures supported by the project. In this article, we
describe the cross-compilation toolchain we defined for Zephyr; it is
implemented as a Guix
channel . About Zephyr Zephyr is a real-time operating system from the Linux Foundation.
It aims to provide a common environment which…<p>In order to deploy embedded software using Guix we first need to teach Guix
how to cross-compile it. Since Guix builds everything from source, this
means we must teach Guix how to build our cross-compilation toolchain.</p><p>The <a href="https://zephyrproject.org">Zephyr Project</a> uses its own fork of GCC with custom configs for
the architectures supported by the project. In this article, we
describe the cross-compilation toolchain we defined for Zephyr; it is
implemented as a <a href="https://github.com/paperclip4465/guix-zephyr">Guix
channel</a>.</p><h1>About Zephyr</h1><p>Zephyr is a <em>real-time operating system</em> from the Linux Foundation.
It aims to provide a common environment which can target even the most
resource constrained devices.</p><p>Zephyr introduces a module system which allows third parties to share code
in a uniform way. Zephyr uses CMake to perform <em>physical component composition</em>
of these modules. It searches the filesystem and generates scripts which
the toolchain will use to successfully combine those components into a
firmware image.</p><p>The fact that Zephyr provides this mechanism is one reason I chose to
target it in the first place.</p><p>This separation of modules in an embedded context is a really great thing.
It brings many of the advantages that it brings to the Linux world such as
code re-use, smaller binaries, more efficient cache/RAM usage, etc.
It also allows us to work as independent groups and compose
contributions from many teams.</p><p>It also brings all of the complexity. Suddenly most of the problems
that plague traditional deployment now apply to our embedded
system. The fact that the libraries are statically linked at compile
time instead of dynamically at runtime is simply an implementation detail.
I say most because everything is statically linked so there is no runtime
component discovery that needs to be accounted for.</p><h1>Anatomy of a Toolchain</h1><p>Toolchains are responsible for taking high level descriptions of programs
and lowering them down to a series of equivalent machine instructions.
This process involves more than just a compiler. The compiler uses the
<a href="https://www.gnu.org/software/binutils">GNU Binutils</a>
to manipulate its internal representation down to a given architecture.
It also needs the use of the C standard library as well as a few other libraries
needed for some compiler optimizations.</p><p>The C library provides the interface to the underlying kernel. System
calls like <code>write</code> and <code>read</code> are provided by <a href="https://www.gnu.org/software/libc">GNU C Library
(glibc)</a> on most distributions.</p><p>In embedded systems, smaller implementations like <a href="https://sourceware.org/newlib/">RedHat's
newlib</a> and
newlib-nano are used.</p><h1>Bootstrapping a Toolchain</h1><p>In order to compile GCC we need a C library that's been compiled for
our target architecture. How can we cross compile our C library if we
need our C library to build a cross compiler? The solution is to build
a simpler compiler that doesn't require the C library to function.
It will not be capable of as many optimizations and it will be very slow,
however it will be able to build the C libraries as well as the complete version
of GCC.</p><p>In order to build the simpler compiler we need to compile the Binutils to
work with our target architecture.
Binutils can be bootstrapped with our host GCC and have no target dependencies.
More information is available in <a href="https://crosstool-ng.github.io/docs/toolchain-construction/">this
article</a>.</p><p>Doesn't sound so bad right? It isn't... in theory.
However internet forums since time immemorial have been
littered with the laments of those who came before.
From incorrect versions of ISL to the wrong C library being linked
or the host linker being used, etc.
The one commonality between all of these issues is the environment.
Building GCC is difficult because isolating build environments is hard.</p><p>In fact as of <code>v0.14.2</code>, the Zephyr “software development kit” (SDK) repository took down the build
instructions and posted a sign that read
"Building this is too complicated, don't worry about it."
(I'm paraphrasing, but
<a href="https://github.com/zephyrproject-rtos/sdk-ng/tree/v0.14.2#build-process">not by much</a>.)</p><p>We will neatly sidestep all of these problems and not
risk destroying or polluting our host system with garbage
by using Guix to manage our environments for us.</p><p>Our toolchain only requires the first pass compiler because
newlib(-nano) is statically linked and introduced to the toolchain
by normal package composition.</p><h1>Defining the Packages</h1><p>All of the base packages are defined in
<a href="https://github.com/paperclip4465/guix-zephyr/blob/master/zephyr/packages/zephyr.scm"><code>zephyr/packages/zephyr.scm</code></a>.
Zephyr modules (coming soon!) are defined in
<a href="https://github.com/paperclip4465/guix-zephyr/blob/master/zephyr/packages/zephyr-xyz.scm"><code>zephyr/packages/zephyr-xyz.scm</code></a>,
following the pattern of other module systems implemented by Guix.</p><h2>Binutils</h2><p>First thing we need to build is the <code>arm-zephyr-eabi</code> binutils.
This is very easy in Guix.</p><pre><code class="language-scheme">(define-public arm-zephyr-eabi-binutils
(let ((xbinutils (cross-binutils "arm-zephyr-eabi")))
(package
(inherit xbinutils)
(name "arm-zephyr-eabi-binutils")
(version "2.38")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/zephyrproject-rtos/binutils-gdb")
(commit "6a1be1a6a571957fea8b130e4ca2dcc65e753469")))
(file-name (git-file-name name version))
(sha256 (base32 "0ylnl48jj5jk3jrmvfx5zf8byvwg7g7my7jwwyqw3a95qcyh0isr"))))
(arguments
`(#:tests? #f
,@(substitute-keyword-arguments (package-arguments xbinutils)
((#:configure-flags flags)
`(cons "--program-prefix=arm-zephyr-eabi-" ,flags)))))
(native-inputs
(modify-inputs (package-native-inputs xbinutils)
(prepend texinfo bison flex gmp dejagnu)))
(home-page "https://zephyrproject.org")
(synopsis "Binutils for the Zephyr RTOS"))))</code></pre><p>The function
<a href="https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/cross-base.scm?id=2397f4768091210b0a705ef750f2f38d6946fb89#n84"><code>cross-binutils</code></a>
returns a package which has been configured for the given GNU triplet.
We simply inherit that package and replace the source. The Zephyr build
system expects the binutils to be prefixed with <code>arm-zephyr-eabi-</code> which
is accomplished by adding another flag to the <code>#:configure-flags</code>
argument.</p><p>We can test our package definition using the <code>-L</code> flag with <code>guix build</code>
to add our packages.</p><pre><code class="language-sh">$ guix build -L guix-zephyr zephyr-binutils
/gnu/store/...-zephyr-binutils-2.38</code></pre><p>This directory contains the results of <code>make install</code>.</p><h2>GCC sans libc</h2><p>This one is a bit more involved. Don't be afraid!
This version of GCC wants ISL version 0.15. It's easy enough
to make that happen. Inherit the current version of ISL and swap
out the source and update the version. For most packages the build process doesn't
change that much between versions.</p><pre><code class="language-scheme">(define-public isl-0.15
(package
(inherit isl)
(version "0.15")
(source (origin
(method url-fetch)
(uri (list (string-append "mirror://sourceforge/libisl/isl-"
version ".tar.gz")))
(sha256
(base32
"11vrpznpdh7w8jp4wm4i8zqhzq2h7nix71xfdddp8xnzhz26gyq2"))))))
</code></pre><p>Like the binutils, there is a <a href="https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/cross-base.scm?id=2397f4768091210b0a705ef750f2f38d6946fb89#n242"><code>cross-gcc</code>
function</a>
for creating cross-GCC packages. This one accepts keywords specifying
which binutils and libc to use. If libc isn't given (like here), gcc is
configured with many options disabled to facilitate being built without
libc. Therefore we need to add the extra options we want (I got them
from the SDK configuration scripts in the <a href="https://github.com/zephyrproject-rtos/sdk-ng"><code>sdk-ng</code>
Git repository</a> as well as the
commits to use for each of the tools).</p><pre><code class="language-scheme">(define-public gcc-arm-zephyr-eabi-12
(let ((xgcc (cross-gcc "arm-zephyr-eabi"
#:xbinutils zephyr-binutils)))
(package
(inherit xgcc)
(version "12.1.0")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/zephyrproject-rtos/gcc")
(commit "0218469df050c33479a1d5be3e5239ac0eb351bf")))
(file-name (git-file-name (package-name xgcc) version))
(sha256
(base32
"1s409qmidlvzaw1ns6jaanigh3azcxisjplzwn7j2n3s33b76zjk"))
(patches (search-patches
"gcc-12-cross-environment-variables.patch"
"gcc-cross-gxx-include-dir.patch"))))
(native-inputs (modify-inputs (package-native-inputs xgcc)
;; Get rid of stock ISL
(delete "isl")
;; Add additional dependencies that xgcc doesn't have
;; including our special ISL
(prepend flex
isl-0.15)))
(arguments
(substitute-keyword-arguments (package-arguments xgcc)
((#:phases phases)
`(modify-phases ,phases
(add-after 'unpack 'fix-genmultilib
(lambda _
(patch-shebang "gcc/genmultilib")))
(add-after 'set-paths 'augment-CPLUS_INCLUDE_PATH
(lambda* (#:key inputs #:allow-other-keys)
(let ((gcc (assoc-ref inputs "gcc")))
;; Remove the default compiler from CPLUS_INCLUDE_PATH to
;; prevent header conflict with the GCC from native-inputs.
(setenv "CPLUS_INCLUDE_PATH"
(string-join (delete (string-append gcc
"/include/c++")
(string-split (getenv
"CPLUS_INCLUDE_PATH")
#\:)) ":"))
(format #t
"environment variable `CPLUS_INCLUDE_PATH' changed to `a`%"
(getenv "CPLUS_INCLUDE_PATH")))))))
((#:configure-flags flags)
;; The configure flags are largely identical to the flags used by the
;; "GCC ARM embedded" project.
`(append (list
"--enable-multilib"
"--with-newlib"
"--with-multilib-list=rmprofile"
"--with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm"
"--enable-plugins"
"--disable-decimal-float"
"--disable-libffi"
"--disable-libgomp"
"--disable-libmudflap"
"--disable-libquadmath"
"--disable-libssp"
"--disable-libstdcxx-pch"
"--disable-nls"
"--disable-shared"
"--disable-threads"
"--disable-tls"
"--with-gnu-ld"
"--with-gnu-as"
"--enable-initfini-array")
(delete "--disable-multilib"
,flags)))))
(native-search-paths
(list (search-path-specification
(variable "CROSS_C_INCLUDE_PATH")
(files '("arm-zephyr-eabi/include")))
(search-path-specification
(variable "CROSS_CPLUS_INCLUDE_PATH")
(files '("arm-zephyr-eabi/include" "arm-zephyr-eabi/c++"
"arm-zephyr-eabi/c++/arm-zephyr-eabi")))
(search-path-specification
(variable "CROSS_LIBRARY_PATH")
(files '("arm-zephyr-eabi/lib")))))
(home-page "https://zephyrproject.org")
(synopsis "GCC for the Zephyr RTOS"))))</code></pre><p>This GCC can be built like so.</p><pre><code class="language-sh">$ guix build -L guix-zephyr gcc-cross-sans-libc-arm-zephyr-eabi
/gnu/store/...-gcc-cross-sans-libc-arm-zephyr-eabi-12.1.0-lib
/gnu/store/...-gcc-cross-sans-libc-arm-zephyr-eabi-12.1.0
</code></pre><p>Great! We now have our stage-1 compiler.</p><h2>Newlib(-nano)</h2><p>The newlib package package is quite straight forward (relatively).
It is mostly adding in the relevent configuration flags and patching
the files the <code>patch-shebangs</code> phase missed.</p><pre><code class="language-scheme">(define-public zephyr-newlib
(package
(name "zephyr-newlib")
(version "3.3")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/zephyrproject-rtos/newlib-cygwin")
(commit "4e150303bcc1e44f4d90f3489a4417433980d5ff")))
(sha256
(base32 "08qwjpj5jhpc3p7a5mbl7n6z7rav5yqlydqanm6nny42qpa8kxij"))))
(build-system gnu-build-system)
(arguments
`(#:out-of-source? #t
#:configure-flags '("--target=arm-zephyr-eabi"
"--enable-newlib-io-long-long"
"--enable-newlib-io-float"
"--enable-newlib-io-c99-formats"
"--enable-newlib-retargetable-locking"
"--enable-newlib-lite-exit"
"--enable-newlib-multithread"
"--enable-newlib-register-fini"
"--enable-newlib-extra-sections"
"--disable-newlib-wide-orient"
"--disable-newlib-fseek-optimization"
"--disable-newlib-supplied-syscalls"
"--disable-newlib-target-optspace"
"--disable-nls")
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'fix-references-to-/bin/sh
(lambda _
(substitute# '("libgloss/arm/cpu-init/Makefile.in"
"libgloss/arm/Makefile.in"
"libgloss/libnosys/Makefile.in"
"libgloss/Makefile.in")
(("/bin/sh") (which "sh")))
#t)))))
(native-inputs
`(("xbinutils" ,zephyr-binutils)
("xgcc" ,gcc-arm-zephyr-eabi-12)
("texinfo" ,texinfo)))
(home-page "https://www.sourceware.org/newlib/")
(synopsis "C library for use on embedded systems")
(description "Newlib is a C library intended for use on embedded
systems. It is a conglomeration of several library parts that are easily
usable on embedded products.")
(license (license:non-copyleft
"https://www.sourceware.org/newlib/COPYING.NEWLIB"))))</code></pre><p>And the build.</p><pre><code class="language-sh :exports both">$ guix build -L guix-zephyr zephyr-newlib
/gnu/store/...-zephyr-newlib-3.3</code></pre><h2>Complete Toolchain</h2><p><em>Mostly</em> complete. libstdc++ does not build because
<code>arm-zephyr-eabi</code> is not <code>arm-none-eabi</code> so a dynamic link check is
performed/failed. I cannot figure out how crosstool-ng handles this.</p><p>Now that we've got the individual tools it's time to create our complete toolchain.
For this we need to do some package transformations.
Because these transformations are going to have to be done for every combination of
binutils/gcc/newlib it is best to create a function which we can reuse for every version
of the SDK.</p><pre><code class="language-scheme">(define (arm-zephyr-eabi-toolchain xgcc newlib version)
"Produce a cross-compiler zephyr toolchain package with the compiler XGCC and the C\n library variant NEWLIB."
(let ((newlib-with-xgcc
(package
(inherit newlib)
(native-inputs
(modify-inputs (package-native-inputs newlib)
(replace "xgcc" xgcc))))))
(package
(name (string-append "arm-zephyr-eabi"
(if (string=? (package-name newlib-with-xgcc)
"newlib-nano")
"-nano"
"")
"-toolchain"))
(version version)
(source #f)
(build-system trivial-build-system)
(arguments
'(#:modules ((guix build union)
(guix build utils))
#:builder (begin
(use-modules (ice-9 match)
(guix build union)
(guix build utils))
(let ((out (assoc-ref %outputs "out")))
(mkdir-p out)
(match %build-inputs
(((names . directories) ...)
(union-build (string-append out "/arm-zephyr-eabi")
directories)))))))
(inputs `(("binutils" ,zephyr-binutils)
("gcc" ,xgcc)
("newlib" ,newlib-with-xgcc)))
(synopsis "Complete GCC tool chain for ARM zephyrRTOS development")
(description
"This package provides a complete GCC tool chain for ARM
bare metal development with zephyr rtos. This includes the GCC arm-zephyr-eabi cross compiler
and newlib (or newlib-nano) as the C library. The supported programming
language is C.")
(home-page (package-home-page xgcc))
(license (package-license xgcc)))))</code></pre><p>This function creates a special package which consists of the toolchain
in a special directory hierarchy, i.e <code>arm-zephyr-eabi/</code>.
Our complete toolchain definition looks like this.</p><pre><code class="language-scheme">(define-public arm-zephyr-eabi-toolchain-0.15.0
(arm-zephyr-eabi-toolchain gcc-arm-zephyr-eabi-12 zephyr-newlib
"0.15.0"))</code></pre><p>To build:</p><pre><code class="language-sh">$ guix build -L guix-zephyr arm-zephyr-eabi-toolchain
/gnu/store/...-arm-zephyr-eabi-toolchain-0.15.0</code></pre><blockquote><p>Note: Guix now includes a <a href="https://guix.gnu.org/manual/en/html_node/Platforms.html">mechanism to describe
<em>platforms</em></a>
at a high level, and which the <a href="https://guix.gnu.org/manual/en/html_node/Additional-Build-Options.html"><code>--system</code> and <code>--target</code> build
options</a>
build upon. It is not used here but could be a way to better
integrate Zephyr support in the future.</p></blockquote><h1>Integrating with Zephyr Build System</h1><p>Zephyr uses CMake as its build system. It contains numerous CMake files in both the so-called <code>ZEPHYR_BASE</code>,
the zephyr source code repository, as well as a handful in the SDK which help select the correct toolchain
for a given board.</p><p>There are standard locations the build system will look for the SDK. We are not using any of them.
Our SDK lives in the store, immutable forever.
According to <a href="https://docs.zephyrproject.org/3.1.0/develop/west/without-west.html">the Zephyr documentation</a>, the variable <code>ZEPHYR_SDK_INSTALL_DIR</code> needs to point to our custom spot.</p><p>We also need to grab the CMake files from the
<a href="https://github.com/zephyrproject-rtos/sdk-ng">repository</a>
and create a file, <code>sdk_version</code>, which
contains the version string <code>ZEPHYR_BASE</code> uses to find a compatible SDK.</p><p>Along with the SDK proper we need to include a number of
python packages required by the build system.</p><pre><code class="language-scheme">(define-public zephyr-sdk
(package
(name "zephyr-sdk")
(version "0.15.0")
(home-page "https://zephyrproject.org")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/zephyrproject-rtos/sdk-ng")
(commit "v0.15.0")))
(file-name (git-file-name name version))
(sha256
(base32
"04gsvh20y820dkv5lrwppbj7w3wdqvd8hcanm8hl4wi907lwlmwi"))))
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build union)
(guix build utils))
#:builder (begin
(use-modules (guix build union)
(ice-9 match)
(guix build utils))
(let ((out (assoc-ref %outputs "out"))
(cmake-scripts (string-append (assoc-ref
%build-inputs
"source")
"/cmake"))
(sdk-out (string-append out "/zephyr-sdk-0.15.0")))
(mkdir-p out)
(match (assoc-remove! %build-inputs "source")
(((names . directories) ...)
(union-build sdk-out directories)))
(copy-recursively cmake-scripts
(string-append sdk-out "/cmake"))
(with-directory-excursion sdk-out
(call-with-output-file "sdk_version"
(lambda (p)
(format p "0.15.0"))))))))
(propagated-inputs (list arm-zephyr-eabi-toolchain-0.15.0
zephyr-binutils
dtc
python-3
python-pyelftools
python-pykwalify
python-pyyaml
python-packaging))
(native-search-paths
(list (search-path-specification
(variable "ZEPHYR_SDK_INSTALL_DIR")
(separator #f)
(files '("")))))
(synopsis "Zephyr SDK")
(description
"zephyr-sdk contains bundles a complete gcc toolchain as well
as host tools like dtc, openocd, qemu, and required python packages.")
(license license:apsl2)))</code></pre><h1>Testing</h1><p>In order to test we will need an environment with the SDK installed.
We can take advantage of <code>guix shell</code> to avoid installing test packages into
our home environment. This way if it causes problems we can just exit the shell
and try again.</p><pre><code class="language-sh">guix shell -L guix-zephyr zephyr-sdk cmake ninja git</code></pre><p><code>ZEPHYR_BASE</code> can be cloned into a temporary workspace to test our toolchain functionality.
(For now. Eventually we will need to create a package for <code>zephyr-base</code> that
our Guix <code>zephyr-build-system</code> can use.)</p><pre><code class="language-sh">mkdir /tmp/zephyr-project
cd /tmp/zephyr-project
git clone https://github.com/zephyrproject-rtos/zephyr
export ZEPHYR_BASE=/tmp/zephyr-project/zephyr</code></pre><p>In order to build for the test board (k64f in this case) we need to get a hold of the vendor
Hardware Abstraction Layers and CMSIS.
(These will also need to become Guix packages to allow the build system to compose modules).</p><pre><code class="language-sh">git clone https://github.com/zephyrproject-rtos/hal_nxp && \
git clone https://github.com/zephyrproject-rtos/cmsis</code></pre><p>To inform the build system about this module we pass it in with <code>-DZEPHYR_MODULES=</code> which is
a semicolon separated list of paths containing a module.yml file.</p><p>To build the hello world sample we use the following incantation.</p><pre><code class="language-sh">cmake -Bbuild $ZEPHYR_BASE/samples/hello_world \
-GNinja \
-DBOARD=frdm_k64f \
-DBUILD_VERSION=3.1.0 \
-DZEPHYR_MODULES="/tmp/zephyr-project/hal_nxp;/tmp/zephyr-project/cmsis" \
&& ninja -Cbuild</code></pre><p>If everything is set up correctly we will end up with a <code>./build</code>
directory with all our build artifacts. The SDK is correctly installed!</p><h1>Conclusion</h1><p>A customized cross toolchain is one of the most difficult pieces of
software to build. Using Guix, we do not need to be afraid of the
complexity! We can fiddle with settings, swap out components, and do
the most brain dead things to our environments without a care in the
world. Just exit the environment and it's like it never happened at
all.</p><p>It highlights one of my favorite aspects of Guix, every package is a
working reference design for you to modify and learn from.</p><h4>About GNU Guix</h4><p><a href="https://guix.gnu.org">GNU Guix</a> is a transactional package manager and
an advanced distribution of the GNU system that <a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects user
freedom</a>.
Guix can be used on top of any system running the Hurd or the Linux
kernel, or it can be used as a standalone operating system distribution
for i686, x86_64, ARMv7, AArch64 and POWER9 machines.</p><p>In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management. Guix is highly customizable
and hackable through <a href="https://www.gnu.org/software/guile">Guile</a>
programming interfaces and extensions to the
<a href="http://schemers.org">Scheme</a> language.</p>https://guix.gnu.org/blog/2021/new-supported-platform-powerpc64le-linux//New Supported Platform: powerpc64le-linuxChris Marusich and Léo Le Bouter2021-04-12T00:00:00Z2021-04-12T00:00:00Z It is a pleasure to announce that support for powerpc64le-linux
(PowerISA v.2.07 and later) has now been
merged to the master branch of
GNU Guix! This means that GNU Guix can be used immediately on this platform
from a Git
checkout .
Starting with the next release (Guix v1.2.1), you will also be able to
download a copy of Guix pre-built for
powerpc64le-linux .
Regardless of how you get it, you can run the new powerpc64le-linux
port of GNU Guix on top of any existing powerpc64le GNU/Linux
distribution. This new platform is available as a "technology preview". This means
that although it is…<p>It is a pleasure to announce that support for powerpc64le-linux
(PowerISA v.2.07 and later) has now been
<a href="https://issues.guix.gnu.org/47182">merged</a> to the master branch of
GNU Guix!</p><p>This means that GNU Guix can be used immediately on this platform
<a href="https://guix.gnu.org/manual/en/html_node/Building-from-Git.html">from a Git
checkout</a>.
Starting with the next release (Guix v1.2.1), you will also be able to
<a href="https://guix.gnu.org/manual/en/html_node/Binary-Installation.html#Binary-Installation">download a copy of Guix pre-built for
powerpc64le-linux</a>.
Regardless of how you get it, you can run the new powerpc64le-linux
port of GNU Guix on top of any existing powerpc64le GNU/Linux
distribution.</p><p>This new platform is available as a "technology preview". This means
that although it is supported,
<a href="https://guix.gnu.org/manual/en/html_node/Substitutes.html">substitutes</a>
are not yet available from the build farm, and some packages may fail
to build. Although powerpc64le-linux support is nascent, the Guix
community is actively working on improving it, and this is a great
time to <a href="https://guix.gnu.org/manual/en/html_node/Contributing.html">get
involved</a>!</p><h3>Why Is This Important?</h3><p>This is important because it means that GNU Guix now works on the
<a href="https://www.raptorcs.com/content/base/products.html">Talos II, Talos II Lite, and Blackbird
mainboards</a> sold
by <a href="https://www.raptorcs.com/">Raptor Computing Systems</a>. This
modern, performant hardware uses <a href="https://wiki.raptorcs.com/wiki/POWER9">IBM
POWER9</a> processors, and it is
designed to respect your freedom. The Talos II and Talos II Lite have
<a href="https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom">recently received Respects Your Freedom (RYF)
certification</a>
from the FSF, and Raptor Computing Systems is currently pursuing RYF
certification for the more affordable Blackbird, too. All of this
hardware <a href="https://wiki.raptorcs.com/wiki/Platform_Comparison">can run without any non-free
code</a>, even the
bootloader and firmware. In other words, this is a freedom-friendly
hardware platform that aligns well with GNU Guix's commitment to
software freedom.</p><p>How is this any different from existing RYF hardware, you might ask?
One reason is performance. The existing RYF
<a href="https://ryf.fsf.org/products?category=1&vendor=All&sort_by=created&sort_order=DESC">laptops</a>,
<a href="https://ryf.fsf.org/products?category=5&vendor=All&sort_by=created&sort_order=DESC">mainboards</a>,
and
<a href="https://ryf.fsf.org/products?category=30&vendor=All&sort_by=created&sort_order=DESC">workstations</a>
can only really be used with Intel Core Duo or AMD Opteron processors.
Those processors were released over 15 years ago. Since then,
processor performance has increased drastically. People should not
have to choose between performance and freedom, but for many years
that is exactly what we were forced to do. However, the POWER9
machines sold by Raptor Computing Systems have changed this: the free
software community now has an RYF-certified option that <a href="https://www.phoronix.com/scan.php?page=article&item=power9-threadripper-core9&num=1">can compete
with the performance of modern Intel and AMD
systems</a>.</p><p>Although the performance of POWER9 processors is competitive with
modern Intel and AMD processors, the real advantage of the Talos II,
Talos II Lite, and Blackbird is that they were designed from the start
to respect your freedom. Modern processors from <a href="https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom">both Intel and AMD
include back
doors</a>
over which you are given no control. Even though the back doors can
be removed <a href="https://www.fsf.org/news/libreboot-x200-laptop-now-fsf-certified-to-respect-your-freedom">with significant effort on older hardware in some
cases</a>,
this is an obstacle that nobody should have to overcome just to
control their own computer. Many of the existing RYF-certified
options (e.g., the venerable Lenovo x200) use hardware that can only
be considered RYF-certified after someone has gone through the extra
effort of removing those back doors. No such obstacles exist when
using the Talos II, Talos II Lite, or Blackbird. In fact, although
<a href="https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/">Intel</a>
and
<a href="https://www.extremetech.com/computing/292722-amds-secure-processor-firmware-is-now-explorable-thanks-to-new-tool">AMD</a>
both go out of their way to keep you from understanding what is going
on in your own computer, Raptor Computing Systems releases <a href="https://git.raptorcs.com/git/">all of the
software and firmware used in their
boards</a> as free software. They even
include circuit diagrams when they ship you the machine!</p><p>Compared to the existing options, the Talos II, Talos II Lite, and
Blackbird are a breath of fresh air that the free software community
really deserves. Raptor Computing Systems' commitment to software
freedom and owner control is an inspiring reminder that it <strong>is</strong>
possible to ship a great product while still respecting the freedom of
your customers. And going forward, the future looks bright for the
open, royalty-free Power ISA stewarded by the OpenPOWER Foundation,
<a href="https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/">which is now a Linux Foundation
project</a>
(see also: <a href="https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/">the same announcement from the OpenPOWER
Foundation</a>.</p><p>In the rest of this blog post, we will discuss the steps we took to
port Guix to powerpc64le-linux, the issues we encountered, and the
steps we can take going forward to further solidify support for this
exciting new platform.</p><h3>Bootstrapping powerpc64le-linux: A Journey</h3><p>To build software, you need software. How can one port Guix to a
platform before support for that platform exists? This is a
<a href="https://guix.gnu.org/manual/en/html_node/Bootstrapping.html">bootstrapping
problem</a>.</p><p>In Guix, all software for a given platform (e.g., powerpc64le-linux)
is built starting from a small set of "bootstrap binaries". These are
binaries of Guile, GCC, Binutils, libc, and a few other packages,
pre-built for the relevant platform. It is intended that the
bootstrap binaries are the only pieces of software in the entire
package collection that Guix cannot build from source. In practice,
<a href="https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html">additional bootstrap roots are
possible</a>,
but introducing them in Guix is highly discouraged, and our community
<a href="https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/">actively</a>
<a href="https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/">works</a>
to <a href="https://guix.gnu.org/en/blog/2018/bootstrapping-rust/">reduce</a> our
overall bootstrap footprint. There is one set of bootstrap binaries
for each platform that Guix supports.</p><p>This means that to port Guix to a new platform, you must first build
the bootstrap binaries for that platform. In theory, you can do this
in many ways. For example, you might try to manually compile them on
an existing system. However, Guix has <a href="https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?id=5d8c2c00d60196c46a32b68c618ccbe2b3aa48f4">package
definitions</a>
that you can use to build them - using Guix, of course!</p><p>Commonly, the first step in <a href="https://guix.gnu.org/manual/en/html_node/Porting.html">porting Guix to a new
platform</a> is to
use Guix to cross-compile the bootstrap binaries for that new platform
from a platform on which Guix is already supported. This can be done
by running a command like the following on a system where Guix is
already installed:</p><pre><code class="language-scheme">guix build --target=powerpc64le-linux-gnu bootstrap-tarballs</code></pre><p>This is the route that we took when building the powerpc64le-linux
bootstrap binaries, as described in commit
<a href="https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8a1118a96c9ae128302c3d435ae77cb3dd693aea">8a1118a</a>.
You might wonder why the target above is "powerpc64le-linux-gnu" even
though the new Guix platform is called "powerpc64le-linux". This is
because "powerpc64le-linux-gnu" is a GNU
<a href="https://wiki.osdev.org/Target_Triplet">triplet</a> identifying the new
platform, but "powerpc64le-linux" is the name of a "system" (i.e., a
platform) in Guix. Guix contains code that converts between the two
as needed (see <code>nix-system->gnu-triplet</code> and <code>gnu-triplet->nix-system</code>
in
<a href="https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm?id=83991a34d5c1d4985e54dd029a81412277ad062a"><code>guix/utils.scm</code></a>.
When cross-compiling, you only need to specify the GNU triplet.</p><p>Note that before you can even do this, you must first update the
<code>glibc-dynamic-linker</code> and <code>system->linux-architecture</code> procedures in
Guix's code, as described in
<a href="https://guix.gnu.org/manual/en/html_node/Porting.html">Porting</a>. In
addition, the versions of packages in Guix that make up the GNU
toolchain (gcc, glibc, etc.) must already support the target platform.
This pre-existing toolchain support needs to be good enough so that
Guix can (1) build, on some already-supported platform, a
cross-compilation toolchain for the target platform, (2) use, on the
already-supported platform, the cross-compilation toolchain to
cross-compile the bootstrap binaries for the target platform, and (3)
use, on the target platform, the bootstrap binaries to natively build
the rest of the Guix package collection. The above <a href="https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html#Invoking-guix-build"><code>guix build</code></a>
command takes care of steps (1) and (2) automatically.</p><p>Step (3) is a little more involved. Once the bootstrap binaries for
the target platform have been built, they must be published online for
anyone to download. After that, Guix's code must be updated so that
(a) it recognizes the "system" name (e.g., "powerpc64le-linux") that
will be used to identify the new platform and (b) it fetches the new
platform's bootstrap binaries from the right location. After all that
is done, you just have to try building things and see what breaks.
For example, you can run <code>./pre-inst-env guix build hello</code> from your
Git checkout to try building GNU Hello.</p><p>The actual bootstrap binaries for powerpc64le-linux are stored on the
<a href="https://alpha.gnu.org/gnu/guix/bootstrap/powerpc64le-linux/20210106/">alpha.gnu.org FTP
server</a>.
Chris Marusich built these bootstrap binaries in an x86_64-linux Guix
System VM which was running on hardware owned by Léo Le Bouter. Chris
then signed the binaries and provided them to Ludovic Courtès, who in
turn verified their authenticity, signed them, and <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669#125">uploaded them to
alpha.gnu.org</a>.
After that, we updated the code to use the newly published bootstrap
binaries in commit
<a href="https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8a1118a96c9ae128302c3d435ae77cb3dd693aea">8a1118a</a>.
Once all that was done, we could begin bootstrapping the rest of the
system - or trying to, at least.</p><p>There were many stumbling blocks. For example, to resolve some test
failures, we had to update the code in Guix that enables it to make
<a href="https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b57de27d0331198c9cafb09a1cf8a5fa4f691e36">certain</a>
<a href="https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c29bfbfc78ccd9e5c10d38faf3d269eafed12854">syscalls</a>
from scheme. In another example, we had to <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46253">patch GCC so that it
looks for the 64-bit libraries in
/lib</a>, rather
than /lib64, since that is where Guix puts its 64-bit libraries by
convention. In addition, some packages required in order to build
Guix failed to build, so we had to debug those build failures, too.</p><p>For a list of all the changes, see <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47182">the patch
series</a> or the
actual commits, which are:</p><pre><code>$ git log --oneline --no-decorate 8a1118a96c9ae128302c3d435ae77cb3dd693aea^..65c46e79e0495fe4d32f6f2725d7233fff10fd70
65c46e79e0 gnu: sed: Make it build on SELinux-enabled kernels.
93f21e1a35 utils: Fix target-64bit? on powerpc64le-linux.
8d9aece8c4 ci: %cross-targets: Add powerpc64le-linux-gnu.
c29bfbfc78 syscalls: Fix RNDADDTOENTCNT on powerpc64le-linux.
b57de27d03 syscalls: Fix clone on powerpc64le-linux.
a16eb6c5f9 Add powerpc64le-linux as a supported Guix architecture.
b50f426803 gnu: libelf: Fix compilation for powerpc64le-linux.
1a0f4013d3 gnu: texlive-latex-base: Fix compilation on powerpc64le*.
e9938dc8f0 gnu: texlive-bin: Fix compilation on powerpc64le*.
69b3907adf gnu: guile-avahi: Fix compilation on powerpc64le-linux.
4cc2d2aa59 gnu: bdb-4.8: Fix configure on powerpc64le-linux.
be4b1cf53b gnu: binutils-final: Support more Power architectures.
060478c32c gnu: binutils-final: Provide bash for binary on powerpc-linux.
b2135b5d57 gnu: gcc-boot0: Enable 128-bit long double for POWER9.
6e98e9ca92 gnu: glibc: Fix ldd path on powerpc*.
cac88b28b8 gnu: gcc-4.7: On powerpc64le, fix /lib64 references.
fc7cf0c1ec utils: Add target-powerpc? procedure.
8a1118a96c gnu: bootstrap: Add support for powerpc64le-linux.</code></pre><p>In the end, through the combined efforts of multiple people, we slowly
worked through the issues until we reached a point where we could do
all of the following things successfully:</p><ul><li>Build Guix manually on a <a href="https://wiki.debian.org/ppc64el">Debian GNU/Linux
ppc64el</a> machine (this is Debian's
name for a system using the powerpc64le-linux-gnu triplet), and
verify that its <code>make check</code> tests passed.</li><li>Build GNU Hello using Guix and run it.</li><li>Run <a href="https://guix.gnu.org/manual/en/html_node/Invoking-guix-pull.html#Invoking-guix-pull"><code>guix pull</code></a>
to build and install the most recent version of Guix, with
powerpc64le-linux support.</li><li>Build a release binary tarball for powerpc64le-linux via: <code>make guix-binary.powerpc64le-linux.tar.xz</code></li><li>Use that binary to install a version of Guix that could build/run
GNU Hello and run <code>guix pull</code> successfully.</li></ul><p>This was an exciting moment! But there was still more work to be
done.</p><p>Originally, we did this work on the
<a href="https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc64le">wip-ppc64le</a>
branch, with the intent of merging it into core-updates. By
convention, the "core-updates" branch in Guix is <a href="https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html">where changes are
made if they cause too many
rebuilds</a>.
Since we were updating package definitions so deep in the dependency
graph of the package collection, we assumed it wouldn't be possible to
avoid rebuilding the world. For this reason, we had based the
wip-ppc64le branch on core-updates.</p><p>However, Efraim Flashner proved us wrong! He created a separate
branch, wip-ppc64le-for-master, where he adjusted some of the
wip-ppc64le commits to avoid rebuilding the world on other platforms.
Thanks to his work, we were able to merge the changes directly to
master! This meant that we would be able to include it in the next
release (Guix v.1.2.1).</p><p>In short, the initial porting work is done, and it is now possible for
anyone to easily try out Guix on this new platform. Because <code>guix pull</code> works, too, it is also easy to iterate on what we have and work
towards improving support for the platform. It took a lot of
cooperation and effort to get this far, but there are multiple people
actively contributing to this port in the Guix community who want to
see it succeed. We hope you will join us in exploring the limits of
this exciting new freedom-friendly platform!</p><h3>Other Porting Challenges</h3><p>Very early in the porting process, there were some other problems that
stymied our work.</p><p>First, we actually thought we would try to port to powerpc64-linux
(big-endian). However, this did not prove to be any easier than the
little-endian port. In addition, other distributions (e.g.,
<a href="https://www.debian.org/ports/">Debian</a> and
<a href="https://fedoraproject.org/wiki/Architectures">Fedora</a>) have recently
dropped their big-endian powerpc64 ports, so the little-endian variant
is more likely to be tested and supported in the community. For these
reasons, we decided to focus our efforts on the little-endian variant,
and so far we haven't looked back.</p><p>In both the big-endian and little-endian case, we were saddened to
discover that the bootstrap binaries are not entirely reproducible.
This fact is documented in <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669">bug
41669</a>, along
with our extensive investigations.</p><p>In short, if you build the bootstrap binaries on two separate machines
without using any substitutes, you will find that the derivation which
cross-compiles %gcc-static (the bootstrap GCC, version 5.5.0) produces
different output on the two systems. However, if you build
%gcc-static twice on the same system, it builds reproducibly. This
suggests that something in the transitive closure of inputs of
%gcc-static is perhaps contributing to its non-reproducibility. There
is an interesting graph <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669#137">toward the end of the bug
report</a>,
shown below:</p><p><img src="https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;msg=137;filename=nonreproducible-drvs-small.png;bug=41669" alt="DifferingDerivations" /></p><p>This graph shows the derivations that produce differing outputs across
two Guix System machines, when everything is built without
substitutes. It starts from the derivation that cross-compiles
%gcc-static for powerpc64-linux-gnu (from x86_64-linux) using Guix at
commit 1ced8379c7641788fa607b19b7a66d18f045362b. Then, it walks the
graph of derivation inputs, recording only those derivations which
produce differing output on the two different machines. If the
non-reproducibility (across systems) of %gcc-static is caused by a
non-reproducible input, then it is probably caused by one or more of
the derivations shown in this graph.</p><p>At some point, you have to cut your losses and move on. After months
of investigation without resolving the reproducibility issue, we
finally decided to move forward with the bootstrap binaries produced
earlier. If necessary, we can always go back and try to fix this
issue. However, it seemed more important to get started with the
bootstrapping work.</p><p>Anyone who is interested in solving this problem is welcome to comment
on the bug report and help us to figure out the mystery. We are very
interested in solving it, but at the moment we are more focused on
building the rest of the Guix package collection on the
powerpc64le-linux platform using the existing bootstrap binaries.</p><h3>Next Steps</h3><p>It is now possible to install Guix on a powerpc64le-linux system and
use it to build some useful software - in particular, Guix itself. So
Guix is now "self-hosted" on this platform, which gives us a
comfortable place to begin further work.</p><p>The following tasks still need to be done. Anyone can help, so please
get in touch if you want to contribute!</p><ul><li>Solve <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669">the GCC bootstrap binary reproducibility
issue</a>
described above.</li><li>Get <a href="https://guix.gnu.org/manual/en/html_node/System-Installation.html">Guix
System</a>
to work on powerpc64le-linux.</li><li>Get CI infrastructure to work
(<a href="https://guix.gnu.org/en/cuirass/">Cuirass</a> (see also: <a href="https://guix.gnu.org/manual/en/html_node/Continuous-Integration.html">Cuirass in
the Guix
manual</a>,
<a href="https://git.cbaines.net/guix/build-coordinator/">guix-build-coordinator</a>
(see also: <a href="https://guix.gnu.org/manual/en/html_node/Guix-Services.html">Guix Build Coordinator in the Guix
manual</a>,
<a href="https://guix.gnu.org/manual/en/html_node/Substitutes.html">substitutes</a>,
etc.)</li><li>Try to build your favorite packages using Guix, <a href="https://guix.gnu.org/manual/en/html_node/Tracking-Bugs-and-Patches.html">report
problems</a>,
<a href="https://guix.gnu.org/manual/en/html_node/Contributing.html">try to fix
them</a>,
and <a href="https://guix.gnu.org/en/help/">ask for help</a> if you're feeling
stuck or not sure how to start.</li><li>Try building rust, and if it works, judiciously re-introduce the
librsvg dependency for powerpc64le-linux in gtk+ and gtk+-2, since
<a href="https://git.savannah.gnu.org/cgit/guix.git/commit/?id=5d2863dfe4613d5091e61800fcd5a48922c8ce4e">it is currently
missing</a>.</li><li>Upgrade the default GCC to 8 on core-updates, try to build guix
(e.g., <code>./pre-inst-env guix build guix</code>), and report/fix whatever
issues occur. We want to upgrade GCC to 8 because, on the
core-updates branch, glibc has been upgraded from 2.31 to 2.32.
Unfortunately, on powerpc64le-linux, upgrading glibc from 2.31 to
2.32 without also upgrading the default GCC (it's currently 7.5.0)
causes a lot of problems. Right now, we believe the best path
forward is probably just to upgrade to GCC 8 on core-updates.</li><li>Merge core-updates to master after that.</li></ul><h4>About GNU Guix</h4><p><a href="https://guix.gnu.org">GNU Guix</a> is a transactional package manager and
an advanced distribution of the GNU system that <a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects user
freedom</a>.
Guix can be used on top of any system running the Hurd or the Linux
kernel, or it can be used as a standalone operating system distribution
for i686, x86_64, ARMv7, and AArch64 machines.</p><p>In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management. Guix is highly customizable
and hackable through <a href="https://www.gnu.org/software/guile">Guile</a>
programming interfaces and extensions to the
<a href="http://schemers.org">Scheme</a> language.</p>https://guix.gnu.org/blog/2017/porting-guixsd-to-armv7//Porting GuixSD to ARMv7Mathieu Othacehe2017-12-22T14:00:00Z2017-12-22T14:00:00Z GuixSD porting to ARMv7 is a difficult topic. There are plenty of
different machines, with specific hardware configurations and
vendor-tuned bootloaders, and ACPI support is still experimental. For
those reasons it is currently impossible to provide a GuixSD image
that runs on most ARMv7 machines like on x86_64 targets. The GuixSD port on ARMv7 has to be done machine by machine and the
first supported one is the BeagleBone Black. It was choosen mainly
because it runs with mainline U-Boot and Linux-libre kernel. As Guix already supported armv7, only three things were missing: A rework of the GuixSD bootloader layer…<p>GuixSD porting to ARMv7 is a difficult topic. There are plenty of
different machines, with specific hardware configurations and
vendor-tuned bootloaders, and ACPI support is still experimental. For
those reasons it is currently impossible to provide a GuixSD image
that runs on most ARMv7 machines like on x86_64 targets.</p><p>The GuixSD port on ARMv7 has to be done machine by machine and the
first supported one is the BeagleBone Black. It was choosen mainly
because it runs with mainline U-Boot and Linux-libre kernel.</p><p>As Guix already supported armv7, only three things were missing:</p><ol><li>A rework of the GuixSD bootloader layer to support not just GRUB but
also U-Boot and Extlinux. This has been integrated in the <a href="https://www.gnu.org/software/guix/blog/2017/gnu-guix-and-guixsd-0.14.0-released/">0.14
release</a>.</li><li>Some developments and fixes on Guix scripts to support image generation,
system reconfiguration and installation on ARMv7 in the same way as it is
already possible on i686 and x86_64 machines.</li><li>The definition on an installation image for the BeagleBone Black.</li></ol><p>Points 2 and 3 were addressed recently so we are now ready to show you
how to run GuixSD on your BeagleBone Black board!</p><h4>Installing GuixSD on a BeagleBone Black</h4><p>Let's try to install GuixSD on the 4GB eMMC (built-in flash memory) of
a BeagleBone Black.</p><p>Future Guix releases will provide pre-built installer images for the
BeagleBone Black. For now, as support just landed on "master", we need
to build this image by ourselves.</p><p>This can be done this way:</p><pre><code>guix system disk-image --system=armhf-linux -e "(@ (gnu system install) beaglebone-black-installation-os)"</code></pre><p>Note that it is not yet possible to cross-compile a disk image. So you
will have to either run this command on an armhf-linux system where
you have previously installed Guix manually, or offload the build to such a
system.</p><p>You will eventually get something like:</p><pre><code>installing bootloader...
[ 7710.782381] reboot: Restarting system
/gnu/store/v33ccp7232gj5wdahdgpjcw4nvh14d7s-disk-image</code></pre><p>Congrats! Let's flash this image onto a microSD card with the command:</p><pre><code>dd if=/gnu/store/v33ccp7232gj5wdahdgpjcw4nvh14d7s-disk-image of=/dev/mmcblkX bs=4M</code></pre><p>where mmcblkX is the name of your microSD card on your GNU/Linux machine.</p><p>You can now insert the microSD card into you BeagleBone Black, plug in a
UART cable and power-on your device while pressing the "S2" button to
force the boot from microSD instead of eMMC.</p><p><img src="https://www.gnu.org/software/guix/static/blog/img/guixsd-bbb1.jpg" alt="GuixSD installer on BeagleBone Black" /></p><p>Let's follow the <a href="https://www.gnu.org/software/guix/manual/en/html_node/Preparing-for-Installation.html#Preparing-for-Installation">Guix documentation
here</a>
to install GuixSD on eMMC.</p><p>First of all, let's plug in an ethernet cable and set up SSH access in order to
be able to get rid of the UART cable.</p><pre><code>ifconfig eth0 up
dhclient eth0
herd start ssh-daemon</code></pre><p>Let's partition the eMMC (/dev/mmcblk1) as a 4GB ext4 partition,
mount it, and launch the cow-store service, still following the
documentation.</p><pre><code>cfdisk
mkfs.ext4 -L my-root /dev/mmcblk1p1
mount LABEL=my-root /mnt
herd start cow-store /mnt</code></pre><p>We have reached the most important part of this whole process. It is now
time to write the configuration file of our new system.
The best thing to do here is to start from the template
<code>beaglebone-black.scm</code>:</p><pre><code>mkdir /mnt/etc
cp /etc/configuration/beaglebone-black.scm /mnt/etc/config.scm
zile /mnt/etc/config.scm</code></pre><p>Once you are done preparing the configuration file, the new system must be initialized
with this command:</p><pre><code>guix system init /mnt/etc/config.scm /mnt</code></pre><p>When this is over, you can turn off the board and remove the microSD card. When you'll
power it on again, it will boot a bleeding edge GuixSD---isn't that nice?</p><h4>Preparing a dedicated system configuration</h4><p>Installing GuixSD on eMMC is great but you can also use Guix
to prepare a portable microSD card image for your favorite server configuration. Say
you want to run an mpd server on a BeagleBone Black directly from microSD card,
with a minimum of configuration steps.</p><p>The system configuration could look like this:</p><pre><code class="language-scheme">(use-modules (gnu) (gnu bootloader extlinux))
(use-service-modules audio networking ssh)
(use-package-modules screen ssh)
(operating-system
(host-name "my-mpd-server")
(timezone "Europe/Berlin")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-beaglebone-black-bootloader)
(target "/dev/sda")))
(initrd (lambda (fs . rest)
(apply base-initrd fs
;; This module is required to mount the sd card.
#:extra-modules (list "omap_hsmmc")
rest)))
(file-systems (cons (file-system
(device "my-root")
(title 'label)
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "mpd")
(group "users")
(home-directory "/home/mpd"))
%base-user-accounts))
(services (cons* (dhcp-client-service)
(service mpd-service-type)
(agetty-service
(agetty-configuration
(extra-options '("-L"))
(baud-rate "115200")
(term "vt100")
(tty "ttyO0")))
%base-services)))</code></pre><p>After writing this configuration to a file called <code>mpd.conf</code>, it's possible to
forge a disk image from it, with the following command:</p><pre><code>guix system disk-image --system=armhf-linux mpd.conf</code></pre><p>Like in the previous section, the resulting image should be copied to a microSD card.
Then, booting from it on the BeagleBone Black, you should get:</p><pre><code>...
Service mpd has been started.
This is the GNU system. Welcome.
my-mpd-server login:</code></pre><p>With only two commands you can build a system image from a configuration file, flash it
and run it on a BeagleBone Black!</p><h4>Next steps</h4><ul><li>Porting GuixSD to other ARMv7 machines.</li></ul><p>While most of the work for supporting ARMv7 machines is done, there's
still work left to create specific installers for other machines.
This mostly consists of specifying the right bootloader and initrd
options, and testing the whole thing.</p><p>One of the next supported systems might be the
<a href="https://www.crowdsupply.com/eoma68/micro-desktop">EOMA68-A20</a> as we
should get a pre-production unit soon. Feel free to add
support for your favorite machine!</p><p>This topic will be discussed in a future post.</p><ul><li>Allow system cross-compilation.</li></ul><p>This will be an interesting feature to allow producing a disk image from
a desktop machine on x86_64 for instance. More development work is needed,
but we'll keep you informed.</p><h4>About GNU Guix</h4><p><a href="https://www.gnu.org/software/guix">GNU Guix</a> is a transactional package
manager for the GNU system. The Guix System Distribution or GuixSD is
an advanced distribution of the GNU system that relies on GNU Guix and
<a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects the user's
freedom</a>.</p><p>In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. Guix uses low-level
mechanisms from the Nix package manager, except that packages are
defined as native <a href="https://www.gnu.org/software/guile">Guile</a> modules,
using extensions to the <a href="http://schemers.org">Scheme</a> language. GuixSD
offers a declarative approach to operating system configuration
management, and is highly customizable and hackable.</p><p>GuixSD can be used on an i686, x86_64 and armv7 machines. It is also
possible to use Guix on top of an already installed GNU/Linux system,
including on mips64el and aarch64.</p>https://guix.gnu.org/blog/2017/state-of-aarch64-on-guix//State of aarch64 on GuixEfraim Flashner2017-07-24T15:30:00Z2017-07-24T15:30:00Z Since the recent 0.13.0 release, Guix supports building software for
aarch64 (64-bit ARM architecture). Here’s the current status. Currently aarch64 support in Guix is pretty good, as long as you don't
mind compiling for yourself :). Potential downfalls are too little RAM
(I limited my boards to 2GB minimum) and using an SD card. For building
packages I made sure that between RAM and swap I have at least 6 GB,
which I don't recall giving me any issues. There were problems with actually building the Guix binary in time for
the 0.13 release. It has since been fixed and I…<p>Since the recent 0.13.0 release, Guix supports building software for
aarch64 (64-bit ARM architecture). Here’s the current status.</p><p>Currently aarch64 support in Guix is pretty good, as long as you don't
mind compiling for yourself :). Potential downfalls are too little RAM
(I limited my boards to 2GB minimum) and using an SD card. For building
packages I made sure that between RAM and swap I have at least 6 GB,
which I don't recall giving me any issues.</p><p>There were problems with actually building the Guix binary in time for
the 0.13 release. It has since been fixed and I have an unoffical
aarch64 binary install tarball at http://flashner.co.il/~efraim/. Also there is
the signing key for my odroid running
<a href="https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-publish.html"><code>guix publish</code></a>.
The URL of my <code>guix publish</code> server is <code>http://git.flashner.co.il:8181</code>.</p><p>General problem points/packages:</p><ul><li>Java is currently out, <code>sablevm-classpath</code> doesn't compile, so currently
there is no path for Java. A quick check showed about 140 packages
depend on <code>sablevm-classpath</code>.</li><li>Go: go-1.4.x doesn't support aarch64 (or mips). I have a patch against
our GCC to build gccgo, and it produces a <code>go</code> binary, but it fails to
actually build anything. When I checked Debian I saw they cross-compile
their arm64 <code>go</code> binary from amd64. I believe there may be an issue with
using gccgo and linking against glibc.</li><li>OCaml 4.01.0: Doesn't build on aarch64, haven't investigated.</li><li>Julia: aarch64 is officially supported, but it has only been tested on
superpowerful boards, like the ThunderX. I haven't gotten it to build
yet. The issue is related to <code>__fp16</code>.</li><li>clisp: our current version doesn't build on aarch64, there isn't
support yet. There are newer builds but no offical release yet, and I
haven't tested those yet.</li><li>gprolog: No upstream support and AFAICT no one is working on it.</li><li>LDC: 1.x is supposed to support aarch64, 0.17.x, aka ldc-bootstrap,
doesn't, it fails while compiling phobos, which has no aarch64 support
in that version.</li><li>Rust: Has upstream support, our package uses the i686 version as a
bootstrap, so only i686 and x86_64 have support in guix ATM.</li><li>Haskell: There is no upstream aarch64 binary to use for bootstrapping.
I'm thinking of trying to use qemu-system-x86_64 as the shell and
emulate x86_64 on my aarch64 board to cross-compile it to aarch64. <code>guix package -A ghc | wc -l</code> shows 293 packages.</li><li>Qt 4: does not build, I've hardly put any time into it.</li><li>Gnucash: The ancient WebKit version they use didn't build on aarch64,
I haven't tried to fix it.</li><li>Linux-libre: While many boards do require specific patches and
versions of the kernel, there have been great increases in recent
kernel versions for many ARM boards. It remains to be seen how much
support these boards have after the kernel has been deblobbed.</li></ul><p>It sounds like its all doom and gloom, but its not too bad. <code>guix package -A | wc -l</code> shows me 5,341 (5,208 without <code>sablevm-classpath</code>),
compared with ~5,600 on x86_64. Most of the difference is Haskell. In
addition, I personally believe that aarch64 actually has fewer
packages that fail to build than armhf.</p><p>Currently the project’s build farm lacks aarch64 build machines. If you
would like to help,
please <a href="https://gnu.org/software/guix/donate/">get in touch with us</a>!</p><h4>About GNU Guix</h4><p><a href="https://www.gnu.org/software/guix">GNU Guix</a> is a transactional package
manager for the GNU system. The Guix System Distribution or GuixSD is
an advanced distribution of the GNU system that relies on GNU Guix and
<a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects the user's
freedom</a>.</p><p>In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. Guix uses low-level
mechanisms from the Nix package manager, except that packages are
defined as native <a href="https://www.gnu.org/software/guile">Guile</a> modules,
using extensions to the <a href="http://schemers.org">Scheme</a> language. GuixSD
offers a declarative approach to operating system configuration
management, and is highly customizable and hackable.</p><p>GuixSD can be used on an i686 or x86_64 machine. It is also possible to
use Guix on top of an already installed GNU/Linux system, including on
mips64el, armv7, and aarch64.</p>https://guix.gnu.org/blog/2015/porting-guix-and-guixsd//Porting Guix and GuixSDLudovic Courtès2015-09-07T00:00:00+02002015-09-07T00:00:00+0200 Quite a lot has happened lately when it comes to porting Guix and GuixSD to other systems. A few weeks ago, Manolis Ragkousis announced the completion of the GSoC project whose purpose was to port Guix to the Hurd. The system distribution, GuixSD, cannot run GNU/Hurd yet, but the package manager itself can both cross-compile from GNU/Linux to GNU/Hurd and build natively on GNU/Hurd. The work of Manolis is being gradually merged in the main branch. More recently, Mark H Weaver posted a series of patches…<div><p>Quite a lot has happened lately when it comes to porting Guix and GuixSD to other systems.<br /></p><p>A few weeks ago, Manolis Ragkousis <a href="https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00379.html">announced</a> the completion of the GSoC project whose purpose was to port Guix to the Hurd. The system distribution, GuixSD, cannot run GNU/Hurd yet, but the package manager itself can both cross-compile from GNU/Linux to GNU/Hurd and build natively on GNU/Hurd. The work of Manolis is being gradually merged in the main branch.<br /></p><p>More recently, Mark H Weaver <a href="https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00500.html">posted</a> a series of patches porting GuixSD to MIPS (Lemote Yeeloong), making it the first GuixSD port to non-Intel-compatible hardware (the package manager itself has supported mips64el <a href="/news/distro-of-the-linux-based-gnu-system-ported-to-mips.html">for two years</a> already.) By removing several platform-specific assumptions, this work paves the way for future ports.<br /></p><p>Lastly, we are glad to report the <a href="http://www.gnu.org/software/guix/donate/">donation</a> of <a href="https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00134.html">two ARM machines</a> for our build farm. They will allow us to continuously test the ARM port, which was completed <a href="/news/gnu-guix-ported-to-arm-and-other-niceties-of-the-new-year.html">earlier this year</a>, and to publish pre-built binaries on our <a href="http://hydra.gnu.org/jobset/gnu/master">build farm</a>. We are grateful to the donors whose contribution makes a big difference for the development of Guix on ARM. If you would like to help out with hardware and/or hosting, <a href="http://www.gnu.org/software/guix/donate/">please get in touch</a>!<br /></p><h4>About GNU Guix</h4><p><a href="http://www.gnu.org/software/guix">GNU Guix</a> is a functional package manager for the GNU system. The Guix System Distribution or GuixSD is an advanced distribution of the GNU system that relies on GNU Guix and <a href="http://www.gnu.org/distros/free-system-distribution-guidelines.html">respects the user's freedom</a>.<br /></p><p>In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native <a href="http://www.gnu.org/software/guile">Guile</a> modules, using extensions to the <a href="http://schemers.org">Scheme</a> language. GuixSD offers a declarative approach to operating system configuration management, and is highly customizable and hackable.<br /></p><p>GuixSD can be used on an i686 or x86_64 machine. It is also possible to use Guix on top of an already installed GNU/Linux system, including on mips64el and armv7.<br /></p></div>https://guix.gnu.org/blog/2013/distro-of-the-linux-based-gnu-system-ported-to-mips//Distro of the Linux-based GNU system ported to MIPSLudovic Courtès2013-10-28T00:00:00+01002013-10-28T00:00:00+0100 The Guix-based distro has been ported to MIPS64 , specifically to the Loongson processors notably found in the free-software-friendly Yeeloong laptops . Technically, "porting" here means that the "bootstrap binaries" were cross-compiled to +mips64el-linux-gnu+, and then used as an input to the distro's bootstrapping process ---a purely functional, and trackable, process. Thanks to Mark and Nikita for their tireless work to make this happen! …<div><p>The Guix-based distro <a href="https://lists.gnu.org/archive/html/guix-devel/2013-10/msg00174.html">has been ported to MIPS64</a>, specifically to the <a href="http://en.wikipedia.org/wiki/Loongson">Loongson</a> processors notably found in the free-software-friendly <a href="http://en.wikipedia.org/wiki/Lemote#Netbook_computers">Yeeloong laptops</a>.<br /></p><p>Technically, <a href="http://www.gnu.org/software/guix/manual/guix.html#Porting">"porting"</a> here means that the "bootstrap binaries" were cross-compiled to +mips64el-linux-gnu+, and then used as an input to the <a href="http://www.gnu.org/software/guix/manual/guix.html#Bootstrapping">distro's bootstrapping process</a>---a purely functional, and trackable, process.<br /></p><p>Thanks to Mark and Nikita for their tireless work to make this happen!<br /></p></div>https://guix.gnu.org/blog/2013/guix-gets-cross-compilation-support//Guix gets cross-compilation supportLudovic Courtès2013-06-26T00:00:00+02002013-06-26T00:00:00+0200 Recently , Guix gained cross-compilation support. What this means is that existing package definitions can be reused to cross compile packages. So for instance one can cross-compile Guile and its dependencies for MIPS with: guix build --target=mips64el-linux-gnu guile This may sound like an unexpected feature for a "package manager". In fact, it is particularly useful when porting the GNU system distribution to new platforms. The distribution being self-contained, it is bootstrapped from a small set of pre-built binaries. With cross-compilation support, porting to…<div><p><a href="http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00114.html">Recently</a>, <a href="http://www.gnu.org/software/guix/">Guix</a> gained cross-compilation support. What this means is that existing package definitions can be reused to cross compile packages. So for instance one can cross-compile Guile and its dependencies for MIPS with:<br /></p><div class="example"><pre>guix build --target=mips64el-linux-gnu guile </pre></div><p>This may sound like an unexpected feature for a "package manager". In fact, it is particularly useful when porting the GNU system distribution to new platforms. The distribution being self-contained, it is bootstrapped from a small set of pre-built binaries. With cross-compilation support, porting to a new platform boils down to <a href="http://lists.gnu.org/archive/html/bug-guix/2013-06/msg00147.html">cross-compiling the bootstrap binaries</a> for that platform.<br /></p></div>