Raspberry Pi4 64 Bit Install

From Gentoo Wiki
Jump to:navigation Jump to:search

This wiki page explains how to install a 64bit Gentoo system on the Raspberry Pi 4.

What works

Everything that was tested. Read the next paragraph about what is untested.

Not tested

  • Analogue Video Output
  • Analogue Audio Output
  • Camera
  • Screen

Instal procedure

The install procedure of Gentoo on the Pi 4 is a standard Gentoo installation similar to the one described in the AMD64 Handbook but without a live medium: the storage (SD card or external SSD) that will be used by the Pi 4 needs to be setup on a separate Gentoo machine (whose platform is probably not aarch64)

Preparing the external storage

Follow AMD64 handbook on Preparing the disks.

The Pi 4 supports GPT partition tables. It needs a fat32 /boot partition with the required firmware and kernel blobs. Around 512MB is sufficient. A minimal partition layout is / and /boot.

Installing the Gentoo installation files

Follow AMD64 handbook on Installing the Gentoo installation files with the tweaks exposed in this section.

In the rest of the article, we will assume that the Stage 3 tarball has been extracted to /mnt/gentoo and that the boot partition is at /mnt/gentoo/boot

CFLAGS

Note
For the Raspberry Pi 4B, users should pass the -mcpu=cortex-a72 flag to the compiler and avoid using -march and -mtune altogether, as the behavior for arm64 is different from amd64. Source
CFLAGS="-mcpu=cortex-a72 -ftree-vectorize -O2 -pipe -fomit-frame-pointer"

With -ftree-vectorize and -fomit-frame-pointer to utilize more registers.

-mcpu=native could be used but may cause issues with distcc.

Installing the Gentoo base system

Follow the Installing the Gentoo base system from the AMD64 Handbook with the tweaks described in this section.

QEMU user chroot

If the gentoo machine being used to setup the Pi's storage device is not aarch64 (e.g. amd64), QEMU needs to be setup and configured on it to be able to chroot into /mnt/gentoo: QEMU user chroot.

Once QEMU is setup, copy over /usr/bin/qemu-aarch64 to /mnt/gentoo/usr/bin/

root #cp /usr/bin/qemu-aarch64 /mnt/gentoo/usr/bin/

VIDEO_CARDS

The mesa drivers the Pi 4 needs to have full hardware acceleration are v3d and vc4

FILE /etc/portage/make.conf
VIDEO_CARDS="v3d vc4"

It also needs specific firmware, loaded in the section "BIOS" configuration

Firmware / Boot partition

The Raspberry Pi 4 does not need a boot loader. Instead, the GPU manages loading the needed firmware and the kernel for the CPU.

The firmware, the kernel, initramfs and the "BIOS" configuration are all saved in the boot partition as files with with specific names. The boot partition needs to be in fat32/vfat format.

The firmware needed to boot and properly utilize the Pi are in the sys-boot/raspberrypi-firmware package:

root #emerge --ask sys-boot/raspberrypi-firmware

which essentially copies the official firmware files to the boot partition. With two extra configuration files that need tweaking:

"BIOS" configuration: /boot/config.txt

From the official documentation

   The Raspberry Pi uses a configuration file instead of the BIOS you would expect to find on a conventional PC. The system configuration parameters, which would traditionally be edited and stored using a BIOS, are stored instead in an optional text file named config.txt.

The following options may be useful (see the documentation for a full list):

FILE /boot/config.txt
# enable GPU acceleration
dtoverlay=vc4-kms-v3d
# file name of the kernel binary
kernel=vmlinuz
# file name to read the kernel command line from, defaults to cmdline.txt
cmdline=cmdline.txt
# file name of the initramfs/initrd and at what address to put it ('followkernel' means right after the kernel binary)
initramfs init.gz followkernel
# Boot the kernel in 64bit mode and load proper firmware
arm_64bit=1
# enable 1.8GHz frequency boost instead of 1.5Ghz
arm_boost=1
# Enable the audio output, I2C and SPI interfaces on the GPIO header
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=spi=on

Note as well there is a new alternative audio mode that does not use the audio=on dtparamater.

Kernel command line: /boot/cmdline.txt

This file /boot/cmdline.txt contains the command line that is given to the kernel. One important information it needs to contain is where the root file system is.

FILE /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=[root-partition-uuid] fsck.repair=yes rootwait

or

FILE /boot/cmdline.txt
console=serial0,115200 console=tty1 root=UUID=[root-filesystem-uuid] fsck.repair=yes rootwait
Important
root=UUID=[root-filesystem-uuid] requires an initrd to provide the userspace mount command.

Kernel

The kernel can either be manually compiled and fully customized or the official binary kernel from Raspberry can be installed.

Important
Make sure the kernel blob filename in /boot is referenced correctly in /boot/config.txt

Raspberry official binary kernel

Install sys-kernel/raspberrypi-image and sys-kernel/raspberrypi-sources

root #emerge --ask sys-kernel/raspberrypi-image sys-kernel/raspberrypi-sources

Manual build

Get the aarch64-unknown-linux-gnu cross toolchain.

To cross compile the kernel:

user $ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make bcm2711_defconfig

Check the other kernel configuration settings given in configure the kernel.

Kernel config tweaks

The Pi 4 USB 3 supports USB Attached SCSI (CONFIG_USB_UAS). Unlike bulk mode, it allows commands to USB storage devices to be overlapped. Enable USB Attached SCSI in the kernel if a USB3 storage device will be used (USB_UAS):

KERNEL
<*>   USB Attached SCSI

The default CPU governor (CPU_FREQ_DEFAULT_GOV) is powersave. This runs the CPU at 600MHz all he time. CPU governors can be controlled in /proc or the default CPU governor can be changed to be ondemand.

Power Over Ethernet requires a .dto file to be loaded as well as kernel support.

The 4G RAM Pi 4 can build the 64 bit kernel in about an hour but a 64 bit toolchain is required, so the very first kernel cannot be built natively on the Pi.

Build and install the kernel

Build and install the kernel, device tree, and kernel modules an described in Raspberry Pi 3 article.

Build and install the device tree and overlays by running make dtbs, then copy the resulting device tree and overlay files to /boot

user $ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make dtbs
root #mkdir -p /mnt/gentoo/boot/overlays
root #cp -vR arch/arm64/boot/dts/overlays/*.dtbo /mnt/gentoo/boot/overlays
root #cp -v arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb /mnt/gentoo/boot/

Note, that the dtb may change during kernel updates, remember to keep updating them when you update the rest of the kernel.

In order to install the kernel on a Pi 400, install the relative device tree

root #cp -v arch/arm64/boot/dts/broadcom/bcm2711-rpi-400.dtb /mnt/gentoo/boot/

Configuring the system

The AMD64 handbook can be followed starting Configuring the system until the end, except for Configuring the bootloader which is taken care of in #Firmware / Boot partition section. Then, the storage can be safely unmounted and plugged in the Pi 4 and have it successfully booting and working as expected.

Misc

WiFi

WiFi needs three firmware files from in /lib/firmware/brcm/:

brcmfmac43455-sdio.bin
brcmfmac43455-sdio.clm_blob
brcmfmac43455-sdio.txt

Which is almost but not quite the same as the Pi3. The catch is in brcmfmac43455-sdio.txt where grep boardflags3 produces different results for the Pi3 and Pi4 files.

The Pi4 version returns boardflags3=0x44200100
The Pi3 version returns boardflags3=0x48200100

With the wrong brcmfmac43455-sdio.txt file, bluetooth will work but not WiFi.

These files, including the Pi 4 version of above file, are found in sys-firmware/raspberrypi-wifi-ucode, to install it you'll also need to install sys-kernel/linux-firmware with the savedconfig USE flag and remove the conflicting files from the saved configuration, and then re-emerge linux-firmware to apply the new de-conflicted saved configuration:

/lib/firmware/brcm/brcmfmac43430-sdio.bin
/lib/firmware/brcm/brcmfmac43430-sdio.txt
/lib/firmware/brcm/brcmfmac43436-sdio.bin
/lib/firmware/brcm/brcmfmac43436-sdio.clm_blob
/lib/firmware/brcm/brcmfmac43436-sdio.txt
/lib/firmware/brcm/brcmfmac43455-sdio.bin
/lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
/lib/firmware/brcm/brcmfmac43455-sdio.txt
/lib/firmware/brcm/brcmfmac43456-sdio.bin
/lib/firmware/brcm/brcmfmac43456-sdio.clm_blob
/lib/firmware/brcm/brcmfmac43456-sdio.txt

EEProm updates

dev-embedded/rpi-eeprom provides the eeprom files and the updater, and as well as a service to check and apply the updates.

There are 3 release channels of firmware updates:

  • critical - Default - rarely updated
  • stable - Updated when new/advanced features have been successfully beta tested.
  • beta - New or experimental features are tested here first.

To configure which release channel you'd like the updater service to follow, edit /etc/conf.d/rpi-eeprom-update.

Power over Ethernet

The Pi3b PoE HAT will power the P4 and a USB SSD.

Fan control works.

microSD trim/discard

The microSD interface supports the trim command:

Pi4_~arm64 ~ #fstrim -av

 /boot: 7.7 GiB (8250073088 bytes) trimmed on /dev/mmcblk0p1

If you have a suitable microSD card, consider adding fstrim to a weekly or monthly cron job.

USB attached SSD

Users with USB3 attached SSDs may have noticed that trim is not supported. It is a feature of USB storage that trim is disabled by default. Trim can be enabled with mixed success. Only USB3 is supported and the USB3 to SSD bridge device must be able to pass the trim command.

One other thing to note, the Raspberry pi currently only supports booting from usb mass storage devices (including external hard drives) that have a 512 byte logical sector size. You may need to reformat (with the drive manufacturer's utility) them to enable 512 byte emulation.

Cross-compiling

Cross-compiling is by far the fastest way to create packages for aarch64. Afterwards, binhost can be set up to download the packages that you desire. It is possible to create the entire RPI4 by using cross-compile and creating it through a stage2. Distcc is also another great method for compiling aarch64 code. Code can be offloaded onto the main computer. Distcc will have more difficulties in boostraping though, unlike Cross-compiling.

See also

Acknowledgements

NeddySeagoon for taking over maintenance and upstreaming many ebuilds from sakaki's overlay after sakaki's retirement ( Neddy's fork )

sakaki's topic on the Raspberry Pi forums

All the contributors to issue 3032 on the Raspberry Pi GitHub repository.