search

sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
926 stars 127 forks source link
64-bit camera gentoo hw-codecs kodi mmal raspberry-pi rpi rpi3 rpi3b rpi3b-plus rpi4 v4l2 v4l2-m2m xfce4

readme

gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi 4 Model B, and Pi 3 B and B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera & h/w codec support, profile 17.0, weekly-autobuild binhost

30 Oct 2020: sadly, due to legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the images may be of use still in certain applications); however, there will be no further updates to the underlying binhost etc., nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

Gentoo itself on the aarch64 / 64-bit RPi platform remains very much a going concern of course; please see e.g. this forum for more details.

With sincere apologies, sakaki ><

Description

[Raspberry Pi 4B, 3B and B+]

This project is a bootable, microSD card 64-bit Gentoo image for the Raspberry Pi 4 model B, 3 model B and 3 model B+ single board computers (SBC).

The image's userland contains a complete (OpenRC-based) Gentoo system (including a full Portage tree) - so you can run emerge operations immediately - and has been pre-populated with a reasonable package set (Xfce v4.14, LibreOffice v6.4.4.2, Firefox Quantum v77.0.1, Chromium v84.0.4147.30, Thunderbird v68.9.0, VLC v3.0.10-r1, Kodi v18.7.1, GIMP v2.10.18-r1 etc.) so that you can get productive without having to compile anything first! Unless you want to, of course; this being Gentoo, GCC v10.1.0, Clang v10.0.0, IcedTea v3.16.0 (OpenJDK 8), Go v1.14.4, Rust v1.44.0 and various versions of Python are of course bundled also ^-^ As of version 1.2.0 of the image, all userland software has been built under Gentoo's 17.0 profile, and, as of version 1.5.0 of the image, the new RPi4 Model B is also supported (and to reflect this, the project itself has been renamed, from gentoo-on-rpi3-64bit to gentoo-on-rpi-64bit ^-^).

The kernel and userland are both 64-bit (arm64/aarch64), and support for the Pi's VC4 GPU (VC6 on the Pi4) has been included (using vc4-fkms-v3d / Mesa), so rendering performance is reasonable (e.g., glxgears between 400 and 1200fps, depending on load and system type; real-time video playback). The Pi's onboard Ethernet, WiFi (dual-band on the RPi3 B+ / Pi4 B) and Bluetooth adaptors are supported, as is the official 7" touchscreen (if you have one). Sound works too, both via HDMI (given an appropriate display), and the onboard headphone jack. As of version 1.1.0 of the image, a weekly-autobuild binhost, custom Gentoo profile, and binary kernel package have been provided, making it relatively painless to keep your system up-to-date (and, because of this, genup has been configured to run automatically once per week, by default). As of version 1.4.0 of the image, access to the RPi3's hardware video codecs (and camera module, if you have one) is supported too, via the V4L2 framework, and, as of version 1.5.0, these features are available on the RPi4 also. Additionally, on the RPi4, the use of dual monitors is supported (but not required) as of version 1.5.0 (as is accelerated graphics, via V3D / Mesa). And, there is no 3GiB 'memory ceiling' anymore: if you are fortunate enough to own a 8GiB Pi4, all 8GiB of that RAM is usable. As of 1.5.2, 64-bit MMAL userland is supported (and used by bundled tools like raspivid), as is automated update of the RPi4's onboard EEPROM firmware. And finally, as of 1.6.0, rpi-5.4.y kernels are supported, the FOSS Jitsi videoconferencing server is bundled, and elogind is used in place of consolekit.

Here's a screenshot of the image running on a dual-display RPi4 B (click to show a higher resolution view):

[gentoo-on-rpi-64bit in use on Pi4 (screenshot)]

The image may be downloaded from the link below (or via wget, per the instructions which follow).

Variant Version Image Digital Signature
Raspberry Pi 4B, 3B/B+ 64-bit Full v1.6.0 genpi64.img.xz genpi64.img.xz.asc
Raspberry Pi 4B, 3B/B+ 64-bit Lite v1.6.0 genpi64lite.img.xz genpi64lite.img.xz.asc

NB: most users will want the first, full image (genpi64.img.xz) - the 'lite' variant (genpi64lite.img.xz) boots to a command-line (rather than a graphical desktop), and is intended only for experienced Gentoo users (who wish to to e.g. set up a server).

The previous release versions are still available (together with a detailed changelog) here. If you have a significant amount of work invested in an older release of this image, I have also provided manual upgrade instructions (from 1.0.0 thru 1.5.4 → 1.6.0) here.

Please read the instructions below before proceeding. Also please note that all images (and binary packages) are provided 'as is' and without warranty. You should also be comfortable with the (at the moment, unavoidable) non-free licenses required by the firmware and boot software supplied on the image before proceeding: these may be reviewed here.

It is sensible to install Gentoo to a separate microSD card from that used by your default Raspbian system; that way, when you are finished using Gentoo, you can simply power off, swap back to your old card, reboot, and your original system will be just as it was.

Please also note that support for arm64 is still in its early stages with Gentoo, so it is quite possible that you may encounter strange bugs etc. when running a 64-bit image such as this one. A lot of packages have been * ~* keyworded to get the system provided here to build... but hey, if you like Gentoo, little things like that aren't likely to put you off ^-^

Table of Contents

Prerequisites

To try this out, you will need:

Downloading and Writing the Image

Choose either the full (recommended for most users) or 'lite' (command-line only) variant, then follow the appropriate instructions below (full or lite).

If you are using a Windows or Mac box, or prefer to use a GUI tool in Linux, I recommend you download your preferred image via your web browser using the links above, and then check out either of the the free, open-source, cross-platform tools Etcher or usbimager to write it to microSD card. Then, once you've done that, continue reading at "Booting!" below.

Alternatively, for those who prefer the Raspberry Pi NOOBS installer GUI, both images are now available for installation using PINN (called gentoo64 and gentoo64lite there). PINN is a fork of NOOBS and includes a number of additional advanced features. Please see this post for further details. Many thanks to procount for his work on this.

Full Image (genpi64.img.xz)

On your Linux box, issue (you may need to be root, or use sudo, for the following, hence the '#' prompt):

# wget -c https://github.com/sakaki-/gentoo-on-rpi-64bit/releases/download/v1.6.0/genpi64.img.xz
# wget -c https://github.com/sakaki-/gentoo-on-rpi-64bit/releases/download/v1.6.0/genpi64.img.xz.asc
RPi4 Running Full Image

to fetch the compressed disk image file (~1,961MiB) and its signature.

Next, if you like, verify the image using gpg (this step is optional):

# gpg --keyserver hkp://ipv4.pool.sks-keyservers.net:80 --recv-key DDE76CEA
# gpg --verify genpi64.img.xz.asc genpi64.img.xz

Assuming that reports 'Good signature', you can proceed. (Warnings that the key is "not certified with a trusted signature" are normal and may be ignored.)

Next, insert (into your Linux box) the microSD card on which you want to install the image, and determine its device path (this will be something like /dev/sdb, /dev/sdc etc. (if you have a USB microSD card reader), or perhaps something like /dev/mmcblk0 (if you have e.g. a PCI-based reader); in any case, the actual path will depend on your system - you can use the lsblk tool to help you). Unmount any existing partitions of the card that may have automounted (using umount). Then issue:

Warning - this will destroy all existing data on the target drive, so please double-check that you have the path correct! As mentioned, it is wise to use a spare microSD card as your target, keeping your existing Raspbian microSD card in a safe place; that way, you can easily reboot back into your existing Raspbian system, simply by swapping back to your old card.

# xzcat genpi64.img.xz > /dev/sdX && sync

Substitute the actual microSD card device path, for example /dev/sdc, for /dev/sdX in the above command. Make sure to reference the device, not a partition within it (so e.g., /dev/sdc and not /dev/sdc1; /dev/sdd and not /dev/sdd1 etc.)

If, on your system, the microSD card showed up with a path of form /dev/mmcblk0 instead, then use this as the target, in place of /dev/sdX. For this naming format, the trailing digit is part of the drive name (partitions are labelled as e.g. /dev/mmcblk0p1, /dev/mmcblk0p2 etc.). So, for example, you might need to use xzcat genpi64.img.xz > /dev/mmcblk0 && sync.

The above xzcat to the microSD card will take some time, due to the decompression (it takes between 5 and 25 minutes on my machine, depending on the microSD card used). It should exit cleanly when done - if you get a message saying 'No space left on device', then your card is too small for the image, and you should try again with a larger capacity one.

Note that on first boot, the image will automatically attempt to resize its root partition (which, in this image, includes /home) to fill all remaining free space on the microSD card, by running this startup service; if you do not want this to happen (for example, because you wish to add extra partitions to the microSD card later yourself), then simply rename the (empty) sentinel file autoexpand_root_partition (in the top level directory of the vfat filesystem on the first partition of the microSD card) to autoexpand_root_none, before attempting to boot the image for the first time.

Now continue reading at "Booting!" below.

Lite Image (genpi64lite.img.xz)

Please note: this image boots to a command line, not a GUI, and is only suitable for experienced Gentoo users. If unsure, choose the full image above, instead.

On your Linux box, issue (you may need to be root, or use sudo, for the following, hence the '#' prompt):

# wget -c https://github.com/sakaki-/gentoo-on-rpi-64bit/releases/download/v1.6.0/genpi64lite.img.xz
# wget -c https://github.com/sakaki-/gentoo-on-rpi-64bit/releases/download/v1.6.0/genpi64lite.img.xz.asc
[RPi4 Running Lite Image]

to fetch the compressed disk image file (~755MiB) and its signature.

Next, if you like, verify the image using gpg (this step is optional):

# gpg --keyserver hkp://ipv4.pool.sks-keyservers.net:80 --recv-key DDE76CEA
# gpg --verify genpi64lite.img.xz.asc genpi64lite.img.xz

Assuming that reports 'Good signature', you can proceed. (Warnings that the key is "not certified with a trusted signature" are normal and may be ignored.)

Next, insert (into your Linux box) the microSD card on which you want to install the image, and determine its device path (this will be something like /dev/sdb, /dev/sdc etc. (if you have a USB microSD card reader), or perhaps something like /dev/mmcblk0 (if you have e.g. a PCI-based reader); in any case, the actual path will depend on your system - you can use the lsblk tool to help you). Unmount any existing partitions of the card that may have automounted (using umount). Then issue:

Warning - this will destroy all existing data on the target drive, so please double-check that you have the path correct! As mentioned, it is wise to use a spare microSD card as your target, keeping your existing Raspbian microSD card in a safe place; that way, you can easily reboot back into your existing Raspbian system, simply by swapping back to your old card.

# xzcat genpi64lite.img.xz > /dev/sdX && sync

Substitute the actual microSD card device path, for example /dev/sdc, for /dev/sdX in the above command. Make sure to reference the device, not a partition within it (so e.g., /dev/sdc and not /dev/sdc1; /dev/sdd and not /dev/sdd1 etc.)

If, on your system, the microSD card showed up with a path of form /dev/mmcblk0 instead, then use this as the target, in place of /dev/sdX. For this naming format, the trailing digit is part of the drive name (partitions are labelled as e.g. /dev/mmcblk0p1, /dev/mmcblk0p2 etc.). So, for example, you might need to use xzcat genpi64lite.img.xz > /dev/mmcblk0 && sync.

The above xzcat to the microSD card will take some time, due to the decompression (it takes between 5 and 10 minutes on my machine, depending on the microSD card used). It should exit cleanly when done - if you get a message saying 'No space left on device', then your card is too small for the image, and you should try again with a larger capacity one.

Note that on first boot, the image will automatically attempt to resize its root partition (which, in this image, includes /home) to fill all remaining free space on the microSD card, by running this startup service; if you do not want this to happen (for example, because you wish to add extra partitions to the microSD card later yourself), then simply rename the (empty) sentinel file autoexpand_root_partition (in the top level directory of the vfat filesystem on the first partition of the microSD card) to autoexpand_root_none, before attempting to boot the image for the first time.

Now continue reading at "Booting!", immediately below. Note, however, that in the case of this 'lite' image, after the startup / resize process has completed, you will be landed at a console login prompt (although it is simple enough to parlay to a basic X11 desktop if you wish). The login credentials are the same as for the full image, viz.:

Hint: you can use the bundled tool nmtui to easily establish a WiFi network connection from the command line.

Hint: if you wish to use your RPi3/4 in a headless context, as of v1.5.2 of the image you can edit the file startup.sh on the first partition, to e.g. set up fixed network IP addresses, specify WiFi login passphrases etc. The file can be edited on any PC (since the first partition is formatted FAT) and you need to make any changes prior to first boot. The shipped startup.sh contains a number of (commented) examples to help get you oriented. Users booting the image on a system with attached mouse, keyboard and monitor can ignore this facility of course, since networking can be configured via the GUI, once booted.

Booting!

Begin with your RPi4 (or RPi3) powered off. Remove the current (Raspbian or other) microSD card from the board (if fitted), and store it somewhere safe.

Next, insert the (Gentoo) microSD card you just wrote the image to into the Pi. Ensure you have peripherals connected (with the main display plugged into the HDMI0 port - the one nearer the USB-C power connector - if using an RPi4), and apply power.

You should see the Pi's standard 'rainbow square' on-screen for about 2 seconds, then the display will go blank for about 10 seconds, and then (once the graphics driver has loaded) a text console will appear, showing OpenRC starting up. On this first boot (unless you have renamed the sentinel file autoexpand_root_partition in the microSD card's first partition to autoexpand_root_none), the system will, after a further 10 seconds or so, automatically resize the root partition to fill all remaining free space on the drive, and, having done this, reboot (to allow the kernel to see the new partition table). You should then see the 'rainbow square' startup sequence once more, and then the system will resize its root filesystem, to fill the newly enlarged partition. Once this is done, it will launch a standard Xfce desktop, logged in automatically to the pre-created demouser account. A simple configuration application will also be autostarted; this allows you to e.g. change screen resolution, if required:

[Baseline Xfce desktop]

If your display looks OK, there's no need to make any changes immediately - just click OK to dismiss the welcome dialog, and then click on the Cancel button to close out the configuration tool itself.

The whole process (from first power on to graphical desktop) should take less than three minutes or so (on subsequent reboots, the resizing process will not run, so startup will be a lot faster).

The initial root password on the image is raspberrypi64. The password for demouser is also raspberrypi64 (you may need this if e.g. the screen lock comes on; you can also do sudo su --login root to get a root prompt at the terminal, without requiring a password). These passwords are set by the autoexpand-root startup service. Note that the screensaver for demouser has been disabled by default on the image.

NB - if your connected computer monitor or TV output appears flickering or distorted, you may need to change the settings in the file config.txt, located in the microSD card's first partition (this partition is formatted vfat so you should be able to edit it on any PC; alternatively, when booted into the image, it is available at /boot/config.txt). Any changes made take effect on the next restart. For an explanation of the various options available in config.txt, please see these notes (the shipped defaults should work fine for most users, however). As of v1.3.1 of this image, you can also use the bundled GUI tool (shown in the screenshot above) to modify (some of) these settings. The program, pyconfig_gen, is, as noted, automatically started on first login, and is available under Applications→Settings→RPi Config Tool.

If the edges of the desktop appear "clipped" by your display (this mostly happens when using HDMI TVs), issue sudo mousepad /boot/config.txt, comment out the line disable_overscan=1 (so it reads instead #disable_overscan=1), save the file, and then reboot (from v1.3.1, you can also enable and configure overscan via the Rpi Config Tool, as noted above). Please note that with modern boot firmware, overscan is ignored if a DMT mode is set.

Tip: if you'd like to set up a persistent dual-monitor setup on an RPi4, please see my short tutorial on this project's open wiki here (this also contains useful hints for setting up a single display).

Using Gentoo

The supplied image contains a fully-configured ~arm64 Gentoo system (not simply a minimal install or stage 3), with a complete Portage tree already downloaded, so you can immediately perform emerge operations etc. Be aware that, as shipped, it uses UK locale settings, keyboard mapping, timezone and WiFi regulatory domain; however, these are easily changed if desired. See the Gentoo Handbook (here and here) for details on the first three; to customize the WiFi regulatory domain, start the Applications→Settings→RPi Config Tool app, select the WiFi tab, choose your location from the drop-down, click Save and Exit, and reboot when prompted.

Please note that for non-UK keyboards, prior to v1.5.4 of the image, you will also need to edit the file /etc/X11/xorg.conf.d/00-keyboard.conf and replace gb in the line Option "XkbLayout" "gb" with the appropriate code from this list. Leave the rest of the file as-is, save, then reboot for the change to take effect. You will need to be the root user, or use sudo to edit this file (e.g., type sudo mousepad /etc/X11/xorg.conf.d/00-keyboard.conf in a terminal). From v1.5.4 however, a simpler GUI-driven method is available. Simply click Applications→Settings→Keyboard, select the Layout tab, ensure Use system defaults is unchecked, and then, in the Keyboard layout section, click on Add to insert the layouts you need to use. For example, the image has English (UK) and English (US) selected, but you should obviously choose whatever works for you. Do not add more than four layouts (or the switcher plugin will not work correctly). You can use the arrow keys to re-order the list (if you have more than one layout); the one at the top will be the default activated at login time. Once done, click on Close to dismiss the dialog. You should now find that you can switch layouts (if you have specified more than one) either by clicking on the top panel-bar keyboard plugin (the one next to the Demo User text on the far right) or by pressing the hotkey (by default, this is Windows KeySpace).

If you have an RPi4, and would like to configure a dual monitor setup, please see these notes (also contains some useful hints for single monitor deployment, applicable to all models).

If you wish to add Bluetooth peripherals (e.g., a wireless mouse and/or keyboard) to your RPi, please see below.

If you would like to run benchmarks on your RPi system, please see these notes.

For hardware-accelerated YouTube playback, please see this post. Also please note that as of v1.5.4 of the image, you can (particularly on a Pi4B with a fast Internet connection) use Applications→Internet→SMTube (YouTube, Hi-Res) to play back videos from YouTube in 1080p, where available; this is significantly better than the currently bundled browsers (Firefox and Chromium) can achieve.

The @world set of packages (from /var/lib/portage/world) pre-installed on the image may be viewed here (note that the version numbers shown in this list are Gentoo ebuilds, but they generally map 1-to-1 onto upstream package versions).

The full package list for the image (which includes @system and dependencies) may also be viewed, here.

The system on the image has been built via a minimal install system and stage 3 from Gentoo (arm64, available here), but all binaries (libraries and executables) have been rebuilt (with profile 17.0) to run optimally on the Raspberry Pi 4 B's Cortex-A72-based SoC, while still retaining backwards compatibility with the older Pi 3 (B and B) model's Cortex-A53. The /etc/portage/make.conf file used on the image may be viewed here, augmented by the custom profile's make.defaults. The CHOST on the image is aarch64-unknown-linux-gnu (per these notes). All packages have been brought up to date against the Gentoo tree as of 11 June 2020. The image contains two kernels: one (bcmrpi3-kernel-bis) is used when booting on the RPi3 B/B+, and the other (bcm2711-kernel-bis) when booting on an RPi4. The correct kernel is chosen automatically at boot time. Each kernel has a distinct release name, and so a separate module set in /lib/modules/.

Note: the CFLAGS used for the image build is -march=armv8-a+crc -mtune=cortex-a72 -O2 -pipe. You can of course re-build selective components with more aggressive flags yourself, should you choose. As the SIMD FPU features are standard in ARMv8, there is no need for -mfpu=neon mfloat-abi=hard etc., as you would have had on e.g. the 32-bit ARMv7a architecture. Note that AArch64 NEON also has a full IEEE 754-compliant mode (including handling denormalized numbers etc.), there is also no need for -ffast-math flag to fully exploit the FPU either (again, unlike earlier ARM systems). Please refer to the official Programmer’s Guide for ARMv8-A for more details. Neither the Pi3 nor Pi4 is shipped with the ARMv8 hardware crypto extensions enabled, unfortunately.

When logged in as demouser, it is sensible to change the password (from raspberrypi64) and root's password (also from raspberrypi64). Open a terminal window and do this now:

demouser@pi64 ~ $ passwd
Changing password for demouser.
(current) UNIX password: <type raspberrypi64 and press Enter>
New password: <type your desired password, and press Enter>
Retype new password: <type the desired password again, and press Enter>
passwd: password updated successfully
demouser@pi64 ~ $ su -
Password: <type raspberrypi64 and press Enter, to become root>
pi64 ~ # passwd
New password: <type your desired password for root, and press Enter>
Retype new password: <type the desired root password again, and press Enter>
passwd: password updated successfully
pi64 ~ # exit
logout
demouser@pi64 ~ $

If you want to create your own account, you can do so easily. Open a terminal, su to root, then issue (adapting with your own details, obviously!):

pi64 ~ # useradd --create-home --groups "adm,disk,lp,wheel,audio,video,cdrom,usb,users,plugdev,portage,cron,gpio,i2c,spi" --shell /bin/bash --comment "Sakaki" sakaki
pi64 ~ # passwd sakaki
New password: <type your desired password for the new user, and press Enter>
Retype new password: <type the desired password again, and press Enter>
passwd: password updated successfully

You can then log out of demouser, and log into your new account, using the username and password just set up. When prompted with the Welcome to the first start of the panel dialog, select Use default config, as this provides a useful 'starter' layout.

Depending on how quickly you select Use default config, you may find you are left with a black desktop background. This issue should resolve itself after your next login, however.

Then, once logged in, you can delete the demouser account if you like. Open a terminal, su to root, then:

pi64 ~ # userdel --remove demouser
userdel: demouser mail spool (/var/spool/mail/demouser) not found

The mail spool warning may safely be ignored. Also, if you want your new user to be automatically logged in on boot (as demouser was), substitute your new username for demouser in the file /etc/lightdm/lightdm.conf.d/50-autologin-demouser.conf (and if you do not want autologin, this file may safely be deleted).

One hint worth bearing in mind: desktop compositing is on for new users by default (unless you are using a Pi3 and have a very high-resolution display, when it will automatically be turned off for you). This gives nicely rendered window shadows etc. but if you find video playback framerates (from VLC etc.) are too slow, try turning it off (Applications→Settings→Window Manager Tweaks, Compositor tab).

Note that as of version 1.1.2 of the image, a number of Xfce 'fixups' will automatically be applied when a new user logs in for the first time; these include:
1) synchronizing compositing to the vertical blank (without which menus flash annoyingly under VC4);
2) setting window move and resize opacity levels; and
3) ensuring the desktop background displays on login (otherwise it often stays black; note that this fix sometimes does not work for the first login of a new user, as noted above).
They are managed by the xfce-extra/xfce4-fixups-rpi3 package (which inserts an entry into /etc/xdg/autostart/).

Keeping Your System Up-To-Date

You can update your system at any time. As there are quite a few steps involved to do this correctly on Gentoo, I have provided a convenience script, genup (source, manpage) to do this as part of the image.

Note that by default, this script will run automatically once per week, commencing the second week after first boot (see the task installed in /etc/cron.weekly). Review the logfile /var/log/latest-genup-run.log to see changes made by the latest auto-update run.

As of version 1.3.0 of the image, a number of additional 'fixups' will also be applied weekly - these are small scripts (which may be viewed here) used to address emergent issues that e.g. may prevent your system updating correctly. The output may be reviewed in /var/log/latest-fixup-run.log. Disabling auto-updating (see text immediately below) will also disable the fixup cronjob.

If you would rather not use auto-updating, simply edit the file /etc/portage/package.use/rpi-64bit-meta so it reads (the relevant line is the last one):

# Enable/disable any metapackage USE flags you want here, and then
# re-emerge dev-embedded/rpi-64bit-meta to have the effect taken up
# e.g. you might set (uncommented):
#
#    dev-embedded/rpi-64bit-meta -weekly-genup
#
# to disable the automated weekly genup (package update)
# run.
#
# Unless you override them, the default metapackage flags are used.
# At the time of writing, those are (default flag status shown as + or -):
#
#  + boot-fw : pull in the /boot firmware, configs and bootloader
#  + kernel-bin : pull in the binary kernel package
#  - porthash : pull in repo signature checker, for isshoni.org rsync
#  + weekly-genup: pull in cron.weekly script, to run genup automatically
#  + innercore: pull in essential system packages for image (RPi initscripts etc.)
#  + core: pull in main packages for image (clang etc.) (requires innercore)
#  + xfce: pull in packages for baseline Xfce4 system (requires core)
#  - pitop: pull in Pi-Top support packages (NB most users will NOT want this;
#      the Pi-Top is a DIY laptop kit based around the RPi3) (requires xfce)
#  - apps: pull in baseline desktop apps (libreoffice etc.) (requires xfce)
#
# NB the main point of the core, xfce, pitop and apps USE flags is just to let
# you reduce what is in your @world set (/var/lib/portage/world).
dev-embedded/rpi-64bit-meta -weekly-genup

Then re-emerge the meta package, which will remove the cron entry (NB: doing it this way ensures the entry stays removed, even if you later manually update your system):

pi64 ~ # emerge -v rpi-64bit-meta

Of course, you can always use genup directly (as root) to update your system at any time. See the manpage for full details of the process followed, and the options available for the command.

Bear in mind that a genup run will take around three to six hours to complete, even if all the necessary packages are available as binaries on the binhost. Why? Well, since Gentoo's Portage - unlike most package managers - gives you the flexibility to specify which package versions and configuration (via USE flags) you want, it has a nasty graph-theoretic problem to solve each time you ask to upgrade (and it is mostly written in Python too, which doesn't help ^-^). Also, many of the binary packages are themselves quite large (for example, the current libreoffice binary package is >100MiB) and so time-consuming to download (unless you have a very fast Internet connection).

When an update run has completed, if prompted to do so by genup (directly, or at the tail of the /var/log/latest-genup-run.log logfile), then issue:

pi64 ~ # dispatch-conf

to deal with any config file clashes that may have been introduced by the upgrade process.

For more information about Gentoo's package management, see my notes here.

You may also find it useful to keep an eye on this project's (sticky) thread in the 'Gentoo on ARM' forum at gentoo.org, as I occasionally post information about this project there.

Installing New Packages Under Gentoo

The following is only a very brief intro to get you started. For more information, see the Gentoo handbook.

You can add any additional packages you like to your RPi. To search for available packages, you can use the (pre-installed) eix tool. For example, to search for all packages with 'hex editor' in their description:

demouser@pi64 ~ $ eix --description --compact "hex.editor"
[N] app-editors/curses-hexedit (--): full screen curses hex editor (with insert/delete support)
[N] app-editors/dhex (--): ncurses-based hex-editor with diff mode
[N] app-editors/hexcurse (--): ncurses based hex editor
[N] app-editors/lfhex (--): A fast hex-editor with support for large files and comparing binary files
[N] app-editors/qhexedit2 (--): Hex editor library, Qt application written in C++ with Python bindings
[N] app-editors/shed (--): Simple Hex EDitor
[N] app-editors/wxhexeditor (--): A cross-platform hex editor designed specially for large files
[N] dev-util/bless (--): GTK# Hex Editor
Found 8 matches

(your output may vary).

Then, suppose you wanted to find out more about one of these, say shed:

demouser@pi64 ~ $ eix --verbose app-editors/shed
* app-editors/shed
     Available versions:  *1.12 *1.13 ~*1.15
     Homepage:            http://shed.sourceforge.net/
     Find open bugs:      https://bugs.gentoo.org/buglist.cgi?quicksearch=app-editors%2Fshed
     Description:         Simple Hex EDitor
     License:             GPL-2

(again, your output may vary, depending upon the state of the Gentoo repo at the time you run the query, your version of eix, etc.)

That '*' in front of versions 1.12 and 1.13 indicates that the package has not yet been reviewed by the Gentoo devs for the arm64 architecture, but that its versions 1.12 and 1.13 have been reviewed as stable for some other architectures (in this case, amd64, ppc and x86 - you can see this by reviewing the matching ebuilds, at /usr/portage/app-editors/shed/shed-1.12.ebuild and /usr/portage/app-editors/shed/shed-1.13.ebuild). Version 1.15 is also marked as being in testing (the '\~*') for those (other) architectures.

However, you will find that most packages (which don't have e.g. processor-specific assembly or 32-bit-only assumptions) will build fine on arm64 anyway, you just need to tell Gentoo that it's OK to try.

To do so for this package, become root, then issue:

pi64 ~ # echo "app-editors/shed * ~*" >> /etc/portage/package.accept_keywords/shed

The above means to treat as an acceptable build candidate any version marked as stable on any architecture (the '\') or as testing on any architecture (the '\~*'). The second does not imply the first - for example, shed-1.12 is not marked as testing on any architecture at the time of writing, so just '~\' wouldn't match it.

Then you can try installing it, using emerge:

pi64 ~ # emerge --verbose app-editors/shed

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    *] app-editors/shed-1.15::gentoo  86 KiB

Total: 1 package (1 new), Size of downloads: 86 KiB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-editors/shed-1.15::gentoo
>>> Installing (1 of 1) app-editors/shed-1.15::gentoo
>>> Recording app-editors/shed in "world" favorites file...
>>> Jobs: 1 of 1 complete                           Load avg: 1.25, 0.56, 0.21
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

Once this completes, you can use your new package!

Note that if you intend to install complex packages, you may find it easier to set ACCEPT_KEYWORDS="* ~*" in /etc/portage/make.conf, since many packages are not yet keyworded for arm64 yet on Gentoo. Obviously, this will throw up some false positives, but it will also mostly prevent Portage from suggesting you pull in 'live' (aka -9999, aka current-tip-of-source-control) ebuilds, which can easily create a nasty dependency tangle.

Once you get a package working successfully, you can then explicitly keyword its dependencies if you like (in /etc/portage/package.accept_keywords/...), rather than relying on ACCEPT_KEYWORDS="* ~*" in /etc/portage/make.conf. Should you do so, please feel free to file a PR against the genpi64:default/linux/arm64/17.0/desktop/genpi64 profile with your changes, so that others can benefit (I intend to submit keywords from this profile to be considered for inclusion in the main Gentoo tree, in due course).

Have fun! ^-^

If you need to install a particular package that isn't currently in the Gentoo tree, note that it is possible to install binary packages from Raspbian (or other 32-bit repos) on your 64-bit system. For further details, please see these notes.

Alternatively, to install source packages with highly resource-intensive build profiles (such as dev-lang/rust), you can temporarily mount the image within a binfmt_misc QEMU user-mode chroot on your Linux PC, and perform the emerge there. This technique allows you to easily leverage the increased memory and CPU throughput of your regular desktop machine. For further details, please see my wiki tutorial here.

Miscellaneous Configuration Notes, Hints, and Tips (↓skip)

You don't need to read the following notes to use the image, but they may help you better understand what is going on!

NB some of the following notes need updating for the new 1.6.0 image. I plan to do this shortly.

Maintenance Notes (Advanced Users Only) (↓skip)

The following are some notes regarding optional maintenance tasks. The topics here may be of interest to advanced users, but it is not necessary to read these to use the image day-to-day.

NB some of the following notes need updating for the new 1.6.0 image. I plan to do this shortly.

Optional: Switch Back to a 'Pure' bcmrpi3_defconfig / bcm2711_defconfig Kernel

As of version 1.2.2 of the image, the default binary kernel package has changed, to sys-kernel/bcmrpi3-kernel-bis-bin, the underlying kernel for which uses a slightly augmented version of the upstream bcmrpi3_defconfig, thereby enabling a number of useful additional facilities (such as KVM, ZSWAP etc). And, as of version 1.5.0 of the image, a second default kernel package is used, sys-kernel/bcm2711-kernel-bis-bin, the underlying kernel for which uses an augmented version of the upstream bcm2711_defconfig for the RPi4.

However, if you'd rather use the 'vanilla' sys-kernel/bcm{rpi3,2711}-kernel-bin (i.e., "pure" bcm{rpi3,2711}_defconfig) kernel packages, as was the case for <= v1.2.1 of the image, you can do so easily; simply become root, and issue:

pi64 ~ # emerge --ask --verbose --oneshot sys-kernel/bcm{rpi3,2711}-kernel-bin

Once this completes, reboot immediately, and you'll be using the "old default" binary kernel packages again (and this choice will be respected during e.g. genup system update runs, going forward).

Switching back to the "-bis" binary kernel package pair, should you subsequently wish to do so, is just as straightforward; simply become root again and issue:

pi64 ~ # emerge --ask --verbose --oneshot sys-kernel/bcm{rpi3,2711}-kernel-bis-bin

Reboot immediately the above command completes.

Optional: Compiling a Kernel from Source

If you'd like to compile a kernel from source on your new system, rather than using the provided binary package, you can do so easily.

Because (at the time of writing) 64-bit support for the RPi3/4 is fairly 'cutting edge', you'll need to download the source tree directly, rather than using sys-kernel/raspberrypi-sources. You'll need to use at least version rpi-4.19.y (to get camera and V4L2 M2M access to the RPi3/4's hardware video codecs), with rpi-5.4.y preferred (and bundled as of version 1.6.0 of the image).

Actually, you can also use sys-kernel/raspberrypi-sources if you like, as that has a 4.19.9999 ebuild. However, to keep things straightforward, I have retained the 'direct clone' instructions in what follows.

The tree you need is maintained here.

However first, since it generally makes sense to use a 'stable' branch compiler and binutils for kernel builds, but the RPi3/4 image uses the 'testing' (aka ~arm64) branch for all packages by default, begin by downgrading your gcc compiler and binutils on the RPi3 to the 'stable' variants (these versions are also available on the binhost, so the following process shouldn't take long). Become root, and issue:

pi64 ~ # echo "sys-devel/gcc -~arm64" >> /etc/portage/package.accept_keywords/gcc
pi64 ~ # echo "sys-devel/binutils -~arm64" >> /etc/portage/package.accept_keywords/binutils
pi64 ~ # emerge --update --oneshot sys-devel/gcc sys-devel/binutils
pi64 ~ # gcc-config --list-profiles

Take a note of the index number of the 'stable branch' version of the compiler returned by the last command above (this will probably be 1), and then ensure the profile is set (substitute it for 1 in the below, if different):

pi64 ~ # gcc-config 1
pi64 ~ # env-update && source /etc/profile
pi64 ~ # FEATURES="-getbinpkg" emerge --oneshot sys-devel/libtool

This process only needs to be done once. It won't affect your ability to build other packages on your RPi3/4.

NB: if you are running Gentoo on a microSD card, please be sure that you have an expanded root partition (as described above) on a >=16GB card, before attempting to build a kernel.

Now, suppose you wish to build the most modern version of the rpi-5.4.y kernel (same major/minor version as on the image). Then, begin by pulling down a shallow clone of the desired version's branch from GitHub (users with sufficient bandwidth and disk space may of course clone the entire tree, and then checkout the desired branch locally, but the following approach is much faster).

Working logged in as your regular user, not root (for security), issue:

user@pi64 ~ $ mkdir -pv kbuild && cd kbuild
user@pi64 kbuild $ rm -rf linux
user@pi64 kbuild $ git clone --depth 1 https://github.com/raspberrypi/linux.git -b rpi-5.4.y

This may take some time to complete, depending on the speed of your network connection.

When it has completed, go into the newly created linux directory, and set up the baseline configuration. You'll actually need to build two kernels, one for the RPi3, another for the RPi4. So let's begin by building an RPi3 kernel, which uses bcmrpi3_defconfig. Issue:

user@pi64 kbuild $ cd linux
user@pi64 linux $ make distclean
user@pi64 linux $ make bcmrpi3_defconfig

Next, modify the configuration if you like to suit your needs (this step is optional, as a kernel built with the stock bcm{rpi3,2711}_defconfig will work perfectly well for most users):

user@pi64 linux $ make menuconfig

When ready, go ahead and build the kernel, modules, and dtbs. Issue:

user@pi64 linux $ nice -n 19 make -j4 Image modules dtbs

This will a reasonable time to complete. (Incidentally, the build is forced to run at the lowest system priority, to prevent your machine becoming too unresponsive during this process.)

With the kernel built, we need to install it. Assuming your first microSD card partition is mounted as /boot (which, given the /etc/fstab on the image (visible here), it should be), become root.

Next, remove the provided binary kernel. Edit the file /etc/portage/package.use/rpi-64bit-meta so it reads (the relevant line is the last one):

# Enable/disable any metapackage USE flags you want here, and then
# re-emerge dev-embedded/rpi-64bit-meta to have the effect taken up
# e.g. you might set (uncommented):
#
#    dev-embedded/rpi-64bit-meta -weekly-genup
#
# to disable the automated weekly genup (package update)
# run.
#
# Unless you override them, the default metapackage flags are used.
# At the time of writing, those are (default flag status shown as + or -):
#
#  + boot-fw : pull in the /boot firmware, configs and bootloader
#  + kernel-bin : pull in the binary kernel package
#  - porthash : pull in repo signature checker, for isshoni.org rsync
#  + weekly-genup: pull in cron.weekly script, to run genup automatically
#  + innercore: pull in essential system packages for image (RPi initscripts etc.)
#  + core: pull in main packages for image (clang etc.) (requires innercore)
#  + xfce: pull in packages for baseline Xfce4 system (requires core)
#  - pitop: pull in Pi-Top support packages (NB most users will NOT want this;
#      the Pi-Top is a DIY laptop kit based around the RPi3) (requires xfce)
#  - apps: pull in baseline desktop apps (libreoffice etc.) (requires xfce)
#
# NB the main point of the core, xfce, pitop and apps USE flags is just to let
# you reduce what is in your @world set (/var/lib/portage/world).
dev-embedded/rpi-64bit-meta -kernel-bin

Then re-emerge the meta package, to delete the binary kernel package itself:

pi64 ~ # emerge -v rpi-64bit-meta
pi64 ~ # emerge --depclean

Important: do not try to restart your system yet - with the binary kernel uninstalled, you must install the new kernel (and DTBs and module set) you have just built, or the image will no longer boot. We will do that next.

Next, substituting your regular user's account name (the one you logged into when building the kernel, above) for user in the below, issue:

pi64 ~ # cd /home/user/kbuild/linux
pi64 linux # cp -v arch/arm64/boot/Image /boot/kernel8.img

Note that by default, the kernel does not require a separate U-Boot loader.

Next, copy over the device tree blobs (at the time of writing arm64 was still using the 2710 dtb, but this may change to 2837 in future, so for safety, copy both of these, and also the RPi3 B+ and compute module 3 variants):

pi64 linux # cp -v arch/arm64/boot/dts/broadcom/bcm{2710,2837}-rpi-3-b.dtb /boot/
pi64 linux # cp -v arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b-plus.dtb /boot/
pi64 linux # cp -v arch/arm64/boot/dts/broadcom/bcm2710-rpi-cm3.dtb /boot/

Interestingly, even if you have a RPi3 B+, you don't actually need the bcm2710-rpi-3-b-plus.dtb dtb to boot it - the system's firmware will intelligently patch your standard bcm2710-rpi-3-b.dtb file, if that's all it can find. Nevertheless, it is better hygiene to include it.

Then, copy across the device tree overlay blobs (these are now the responsibility of the kernel, not the boot firmware, package, so it is essential you add them):

pi64 linux # cp -rv arch/arm64/boot/dts/overlays/ /boot/

Lastly, install the modules:

pi64 linux # make modules_install
pi64 linux # sync

We don't do a make firmware_install here, since that build target has been dropped for >= 4.14.

Once that is done, we'll loop back and build and install the Pi4 kernel. Issue:

user@pi64 linux $ make distclean
user@pi64 linux $ make bcm2711_defconfig
user@pi64 linux $ make menuconfig

Make sure to set CONFIG_LOCALVERSION to something distinct (like "-2711") to ensure the release names of the two kernels are distinct - you don't want their modules getting co-mingled in /lib/modules/<kernel-release-name>/.... Make any other changes you want, then save and exit the configuration tool, and issue:

user@pi64 linux $ nice -n 19 make -j4 Image modules dtbs

Once done, copy across the kernel, dtb and modules (note the modified name used for the RPi4 kernel in /boot, to distinguish it from the RPi3 kernel (kernel8.img) that we built and copied over earlier):

pi64 linux # cp -v arch/arm64/boot/Image /boot/kernel8-p4.img
pi64 linux # cp -v arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb /boot/
pi64 linux # make modules_install

There is no need to copy the overlays directory, as that is identical between the RPi3 and RPi4 64-bit builds, and you have already copied it over.

All done! After you reboot, you'll be using your new kernels.

It is also possible to cross-compile a kernel on your (Gentoo) PC, which is much faster than doing it directly on the RPi. Please see the instructions later in this document.

Alternatively, if you set up distcc with crossdev (also covered in the instructions below), you can call pump make instead of make to automatically offload kernel compilation workload to your PC. However, if you do use distcc in this way, be aware that not all kernel files can be successfully built in this manner; a small number (particularly, at the start of the kernel build) may fall back to using local compilation. This is normal, and the vast majority of files will distribute OK.

If you want to switch back to the binary kernel package again, simply comment out the line you added at the end of /etc/portage/package.use/rpi-64bit-meta, and issue:

pi64 ~ # emerge -v rpi-64bit-meta

You will receive warnings about file collisions (as the kernel package overwrites your /boot/kernel8.img, /boot/kernel8-p4.img etc.) but it should go through OK. Reboot, and you'll be using your binary kernels again!

At this point, you may wish to clean up your old, source-built kernels' modules from /lib/modules/<your-kernel-release-names>, to save space.

Have your Gentoo PC Do the Heavy Lifting!

The RPi3 (and even the RPi4, although significantly better) does not have a particularly fast processor when compared to a modern PC. While this is fine when running the device in day-to-day mode (as a IME-free lightweight desktop replacement, for example), it does pose a bit of an issue when building large packages from source.

Of course, as the (>= 1.1.0) image now has a weekly-autobuild binhost provided, this will only really happen if you start setting custom USE flags on packages like app-office/libreoffice, or emerging lots of packages not on the original pre-installed set.

However, there is a solution to this, and it is not as scary as it sounds - leverage the power of your PC (assuming it too is running Gentoo Linux) as a cross-compilation host!

For example, you can cross-compile kernels for your RPi3/4 on your PC very quickly (around 5-15 minutes from scratch), by using Gentoo's crossdev tool. See my full instructions here, here and here on this project's open wiki.

Should you setup crossdev on your PC in this manner, you can then take things a step further, by leveraging your PC as a distcc server (instructions here on the wiki). Then, with just some simple configuration changes on your RPi3 (see these notes), you can distribute C/C++ compilation (and header preprocessing) to your remote machine, which makes system updates a lot quicker (and the provided tool genup will automatically take advantage of this distributed compilation ability, if available).

Since they share the same ARMv8a architecture (march), binaries built in this manner can be used on either a RPi3 Model B, B+ or an RPi4 Model B, without modification.

Using your RPi3/4 as a Headless Server

If you want to run a dedicated server program on your RPi3 or RPi4 (for example, a cryptocurrency miner), you won't generally want (or need) the graphical desktop user interface. To disable it, issue (as root):

pi64 ~ # rc-update del xdm default

You can also reclaim the memory reserved for the vc4 graphics driver (this is optional). To do so, issue:

pi64 ~ # nano -w /boot/config.txt

and comment out the following line, so it reads:

#dtoverlay=vc4-fkms-v3d

(Your setup may have a cma specification following the vc4-fkms-v3d; it's still the same line, and should be commented.)

Also ensure that the camera module support software is not loaded, and that only a minimal amount of GPU memory is allocated - to do so, ensure the below lines in the file read as follows:

#start_x=1
gpu_mem=16

Leave the rest of the file as-is. Save, and exit nano.

Reboot your system. You will now have a standard terminal login available only, which greatly saves on system resources.

Should you wish to completely remove the graphical desktop's packages from your system too, please see my notes here.

Next, ensure that your system won't autoupdate (since this can cause high system load at an unpredictable moment). Log in as root, then issue:

pi64 ~ # echo "dev-embedded/rpi-64bit-meta -weekly-genup" > /etc/portage/package.use/rpi-64bit-meta
pi64 ~ # emerge -v rpi-64bit-meta

You can now arrange for your server program to start on boot, either by creating an explicit OpenRC service file in /etc/init.d/ or by adding an (executable) startup script, named /etc/local.d/<servicename>.start, in which you fork off the server using start-stop-daemon (or similar).

I recommend that you run your service at the lowest possible system priority (i.e., highest positive number niceness), particularly if it is CPU intensive. This will ensure that you're able to log in successfully using ssh, even if the daemon is in a tight CPU-bound loop.

It is generally more reliable to use the Ethernet rather than the WiFi network interface when running a headless server in this manner. Also, make sure your system has an adequate heatsink fitted (or even active CPU cooling, for particularly demanding applications), since the RPi3 (particuarly when running in 64-bit mode) can get quite hot, leading to thermal throttling or even protective system shutdown if your cooling is insufficient. The RPi3 Model B+ has a integral heat-spreader, so (in addition to having a higher clock speed) it may be a somewhat better choice than the RPi3 Model B for more demanding applications. The RPi4 has even more significant thermal challenges than the RPi3, so active cooling is recommended for demanding applications.

Of course, take the normal precautions when running an internet-exposed server in this manner: for example, set up an appropriate firewall, consider running the server process under firejail, modify the shipped-default passwords, and keep your system up-to-date by (manually) running genup, from time to time.

Should you wish to revert back to using the graphical desktop at some point in the future, simply issue (as root):

pi64 ~ # rc-update add xdm default

Then, if you edited /boot/config.txt above, undo that change now. Issue:

pi64 ~ # nano -w /boot/config.txt

and uncomment the following line, so it reads:

dtoverlay=vc4-fkms-v3d

With modern boot firmware, the recommendation is not to set an explicit cma parameter on vc4-fkms-v3d.

If you wish to use the camera, and hardware video codecs, also ensure that the below lines read as follows (if not, this step may be omitted):

start_x=1
gpu_mem=128

Leave the rest of the file as-is. Save, and exit nano. Reboot your system, and you should have your full graphical desktop back again!

Miscellaneous Points (Advanced Users Only) (↓skip)

The following are some notes about the detailed structure of the image. It is not necessary to read these to use the image day-to-day.

RPi-Specific Ebuilds

As of version 1.1.0 of the image, all the required firmware and startup files have now been placed under ebuild control, for ease of maintenance going forward:

New Features to Expedite Regular System Updating

In addition to the above, as of version 1.1.0 of the image, a number of other changes have been made to expedite the process of keeping your 64-bit Gentoo RPi3 up-to-date:

These features, viz.:

make updating a typical system (with few user-added packages) possible with a near 100% hit rate on the binhost's binaries. As such, updating (via genup, for example, or an old-school eix-sync && emerge -uDUav --with-bdeps=y @world) is much less onerous than before, and so has been automated on the image (via the app-portage/weekly-genup package, which installs a script in /etc/cron.weekly). This automated weekly updating can easily be disabled if you do not wish to use it (simply edit the file /etc/portage/package.use/rpi-64bit-meta and set the -weekly-genup USE flag, then emerge -v rpi-64bit-meta).

Subscribed Ebuild Repositories (aka Overlays)

The image is subscribed to the following ebuild repositories:

Project Wiki

In addition to the notes in this README, this project also has an associated open wiki, containing a number of short tutorial articles you may find helpful when using 64-bit Gentoo on your RPi3 or RPi4.

You can view the wiki homepage here. Feel free to add your own material!

Help Wanted!

You've got this far through the README - I'm impressed ^-^. In fact, you may be just the sort of person to help get arm64 into a more stable state in the main Gentoo tree...

To that end, if you have managed to get additional packages (not included in the original pre-installed set) working reliably on your gentoo-on-rpi-64bit system, please feel free to submit PRs for the relevant profile elements of the genpi64 overlay (for example, package.accept_keywords, package.bashrc and package.use entries). Not only will upstreaming your changes help other users in the short term, it will also create a shared knowledge base (about how to get various packages working on arm64) that can be used as a sourcebook for keywording PRs (etc.) to the main Gentoo tree.

Within reason, I'm also happy to consider adding working packages to the set maintained by the weekly-autobuild binhost; just open an issue to request this.

Acknowledgement

I'd like to acknowledge NeddySeagoon's work getting Gentoo to run in 64-bit mode on the RPi3 (see particularly this thread, which was a really useful reference when putting this project together originally).

Feedback Welcome!

If you have any problems, questions or comments regarding this project, feel free to drop me a line! (sakaki@deciban.com)