SDIO - SD Card Interface SDIO is the SD host/eMMC interface on the Raspberry Pi. SD host signals are normally used for the microSD slot. These pins are 'SD host' on Alt0 and 'eMMC' on Alt3. The Raspberry Pi 3 and Pi Zero W (wireless) are equipped with 2.4 GHz WiFi 802.11n (150 Mbit/s) and Bluetooth 4.1 (24 Mbit/s) based on the Broadcom BCM43438 FullMAC chip with no official support for monitor mode (though it was implemented through unofficial firmware patching) and the Pi 3 also has a 10/100 Mbit/s Ethernet port.
The Raspberry Pi Compute Module 4 has been designed for industrial applications, it is the perfect option to embed Raspberry Pi functionality into your design. Based on the Raspberry Pi 4B, the CM4 has a quad-core CPU with a BCM2711 processor running at 1.5GHz. The compute module 4 differs in form factor from previous compute modules, with additional new interfaces allowing for more. The Raspberry Pi series of chips has a special function on a bunch of the GPIO pins that make it easier to talk to SDIO devices. SDIO is an extension of the SPI-like protocol that’s used with SD.
Raspberry Pi RTL8723BS SDIO GPIO 150Mbs WiFi + BT A board for adding WiFi and Bluetooth without using a USB port to any Raspberry Pi with a 40 pin header. Supports 802.11n upto 150Mbps.
The Raspberry Pi 3 with a 64-bit capable CPU became available on Feb. 2016. At the outset, it was difficult to install Gentoo on the Pi 3 in 64-bit mode. A lot of work by a lot of people has almost brought a 64-bit Gentoo install on the Pi 3 down to almost a standard handbook install.
All the Pi 3 hardware is supported in 64-bit mode. That's
The content of the microSD card will be wiped during the install.
There are no prebuilt kernel images for the Pi 3 in its arm64 mode. Until you have a arm64 kernel, you can't boot it in 64-bit mode.Its a little chicken and egg. Once the Pi is running, it can build its own kernels.
crossdev is Gentoos' tool for building cross compiler tool chains. Once its installed, we will use it to build the arm64 kernel on the Gentoo PC.
will install the crossdev tool.
You may need to nominate an overlay to store the cross ebuilds, crossdev will let you know.
There are other parameters you can pass to crossdev too.
Convert files as crossdev asks e.g.
by appending _file to the existing filename
root #
mv /etc/portage/package.env /etc/portage/package.env_file
making the directory
then moving package.env_file into the directory.
root #
mv /etc/portage/package.env_file /etc/portage/package.env
Rinse and repeat until crossdev is happy.
crossdev will take a while. It's building
When crossdev completes you will have a cross toolchain
It will also create an arm64 target root in /usr/aarch64-unknown-linux-gnu This is used by cross emerge.
Pure cross compiling, other than the kernel, is out of scope of this guide.
The Raspberry Pi Firmware is maintained in a git repository. You will need to install git if you don't have it.
Don't do anything you don't need to do as root.
As your normal user, make some space in the home directory for raspberry pi
will do nicely.
This will be for the Raspberry Pi firmware and kernel
user $
git clone -b stable --depth=1 https://github.com/raspberrypi/firmware
will fetch the Pi firmware into a directory called firmware
As we only need the /boot directory out of the stable branch, depth option is used so that not all the history will be fetched, but a lot of space, bandwidth and time is saved.
There is nothing to build. ~/raspberrypi/firmware/boot is used as is.
Stay in raspberrypi directory and
user $
git clone https://github.com/raspberrypi/linux
will fetch the kernel into a directory called linux.
With absolutely no fanfare at all, 64-bit support was added to this kernel tree late in 2016. No more searching for odd patches.
Not everything has been accepted by the mainline kernel yet but it's getting closer. Feel free to test for yourself.
The master branch may be broken as its commit by commit as it happens. Test if you want to. It's better to use a release branch. At the time of writing that is rpi-4.14.y. The 4.14 mainline kernel is still at -rc status.
user $
git checkout rpi-4.14.y
That's the kernel source tree in place, ready for configuring and cross compiling.
ARCH=arm64
must be specified everywhere or the kernel build system will use the host arch. This will destroy the arm64 .config fileAs your user
The bcmrpi3_defconfig config file is almost right as it stands. It defaults to the powersave CPU governor, which runs the Pi at 600MHz.All the governors are there. Ondemand is recommended.
user $
ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make bcmrpi3_defconfig
Either use menuconfig to change the default CPU governor, add something to the kernel command line, or change it after booting.
user $
ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make menuconfig
Search for CPU_FREQ_DEFAULT_GOV go to that location and set the default to Ondemand. Exit menuconfig, saving the change.
The kernel .config contains lots of support for hardware you don't have and possibly have never heard of. More confident readers may be tempted to trim things out now. A word of advice - don't, at least, not until the system boots.
The kernel will not link with the gold linker. It ends with
If you don't know what the gold linker is, you are not using it.
The build is conventional, other than telling the build system to build for arm64 and use the cross compiler.
user $
ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make -jX
Change X
to the number of parallel make jobs you want to run. Convention is cores+1.
The Raspberry Pi does not need a boot loader. There is no firmware for the ARM CPU, like there is in a PC. Instead, the GPU manages loading software for the CPU to execute, while the CPU is held reset. Its the GPU that has the 'BIOS' that gets everything started.
This makes it impossible to brick the Pi, since at worst, the microSD card needs to be reloaded.
This arrangement does impose some constraints on the microSD card.
The bootcode.bin file has some useful defaults that make setup easier, which we will take advantage of later.
Depending on how the microSD card is connected to you PC, it my be /dev/sdX or /dev/mmcblkY
In the example below, it's /dev/sdk.
Using the partitioning tool of your choice, make three partitions on your microSD card.
Using fdisk, and your microSD card block device, not my /dev/sdk
Make a new MS-DOS disklable
Add a new partition - this will be 128Mb for /boot
Has created a new partition 1 of type 'Linux' and of size 128 MiB.
Add a 2G partition 2 for swap.
Put the remaining space in partition 3 for root.
Check with
Using an 8G microSD card it should show
Toggle the bootable flag on partition 1
The bootable flag on partition 1 is enabled now.
Mark partition 1 as FAT
Mark partition 2 as swap
Check again.
Exit fdisk with either w or q
You know the block devices from the partitioning step above. Fill in the .. to match your system.
vfat for /boot
-F 32
switch. When using mkfs to make a vfat file system and -F 32
is not explicitly defined, mkdosfs will automatically select between 12, 16 and 32-bit, whatever mkdosfs thinks will fit better for the file system size, which in this case it would default to FAT16. This partition MUST be formatted FAT32 in order for the Raspberry Pi to boot.mkswap for swap
ext4 for root
-i 8192
makes an inode for every two filesystem blocks, 8kBThe inode count cannot be changed after filesystem creation and can limit the number of files on a files system.The Gentoo repository alone needs over 17,000 inodes.
To make it easy to cross refer to the Gentoo_Handbook
Mount the microSD card root filesystem at /mnt/gentoo
Fetch the arm64 stage3 and untar it with
root #
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo
/mnt/gentoo/tmp should be empty. Clear it now or the the Pi will do it at boot.
That may take a long time.
Before and after clearing /mnt/gentoo/tmp
This step is not actually needed to boot the Pi but emerge won't work without it. No software can be installed without the Gentoo repository containing the ebuilds to emerge.
Following the Handbook fetch and unpack aGentoo repository shapshot in the normal way.
Careful readers can copy their host /var/db/repos/gentoo as long as ./packages and ./distfiles are omitted.
If emerge-webrsync is not able to be executed, unpack the Gentoo repository snapshot manually like the following.
root #
tar xvpf portage-latest.tar.bz2 --strip-components=1 -C /mnt/gentoo/var/db/repos/gentoo
Mount the microSD card boot at /mnt/gentoo/boot. (The microSD card root should still be mounted at /mnt/gentoo)
As root, copy the content of your normal users ~/raspberrypi/firmware/boot to /mnt/gentoo/boot.
root #
cp -rv ~<user>/raspberrypi/firmware/boot/* /mnt/gentoo/boot
You should end up with files in /mnt/gentoo/boot, not a directory called boot.
Not all the files there are required. It's a one size fits all for all models of Raspberry Pi operating in 32-bit mode.
The kernel was built above, now to install it.
The kernel is in three parts
As root, copy the kernel binary from the build location
root #
cp /home/<user>/raspberrypi/linux/arch/arm64/boot/Image /mnt/gentoo/boot/kernel8.img
It is possible to use other kernel file names by adding entries to /boot/config.txt
The device tree binary (.dtb) describes the hardware to the kernel. This avoids having all the existing hardware configurations are coded into the kernel.
Due to the way the Raspberry Pi 64-bit kernel support has been added, there are going to be two different device trees with the same file name. A 32-bit version and a 64-bit version. They are not interchangeable. Move the 32-bit version out of the way.
For Raspberry Pi 3B:
root #
mv /mnt/gentoo/boot/bcm2710-rpi-3-b.dtb /mnt/gentoo/boot/bcm2710-rpi-3-b.dtb_32
For Raspberry Pi 3B Plus:
root #
mv /mnt/gentoo/boot/bcm2710-rpi-3-b-plus.dtb /mnt/gentoo/boot/bcm2710-rpi-3-b-plus.dtb_32
That's renamed the 32-bit version.
Copy the dtb from the build location
For Raspberry Pi 3B:
root #
cp /home/<user>/raspberrypi/linux/arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dtb /mnt/gentoo/boot
For Raspberry Pi 3B Plus:
root #
cp /home/<user>/raspberrypi/linux/arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b-plus.dtb /mnt/gentoo/boot
It is possible to use other device tree file names by adding entries to /boot/config.txt
From the top of the kernel tree, install the kernel modules.
root #
ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- make modules_install INSTALL_MOD_PATH=/mnt/gentoo
The INSTALL_MOD_PATH is the root of the filesystem the modules are to be installed into. Due to kernel naming
it's unlikely you will have a 4.10.0-rc6-v8+ so omitting INSTALL_MOD_PATH is probably harmless to your build host install.
Notice the two bcm2710-rpi-3-b.dtb device tree binaries and the kernel8.img.
Shows that the kernel modules were installed to the correct location.
Now that we have the base operating system in, we will need to do some file configuration by hand to get the peripherals working.
The Gentoo stage 3 comes with the default Gentoo serial port configuration. In Raspbian Jessie, udev rules exist that provide aliases for GPIO14:15 (/dev/serial0) and the Bluetooth serial port (/dev/serial1). If you're not using the pi3-miniuart-bt or the pi3-disable-bt device tree overlays, ttyS0 (mini UART) points to /dev/serial0 (GPIO14:15) while ttyAMA0 (Bluetooth) points to /dev/serial1 (Bluetooth).
If, however, the pi3-miniuart-bt overlay is in use, udev rules automagically make ttyAMA0 point to /dev/serial0 (GPIO14:15) while ttyS0 points to /dev/serial1 (Bluetooth). If the pi3-disable-bt overlay is in use, ttyAMA0 still points to /dev/serial0 (GPIO14:15) while Bluetooth/ttyS0 are disabled.
This allows the use of /dev/serial1 in any Bluetooth configuration files and command line arguments regardless of which serial port it is assigned to. It also allows the use of /dev/serial0 in any apps and/or configuration files/command line arguments which reference the GPIO14:15 pins regardless of which overlay is/is not in use.
In order to make things easier when working with the device tree overlays for the Bluetooth module as well as any applications which were written in a Raspbian environment that uses the serial0 and serial1 aliases, we'll need to first create a udev rule to mimic this behavior.
Open up /mnt/gentoo/etc/inittab -
Find this line and comment it out by appending a # at the beginning of the line -
/mnt/gentoo/etc/inittab
Save and exit the file. This prevents Gentoo from assigning the serial console to ttyAMA0 on /root mount, which will conflict with Bluetooth operation if left uncommented.
Next, create the empty file 99-com.rules in /mnt/gentoo/etc/udev/rules.d -
root #
nano -w /mnt/gentoo/etc/udev/rules.d/99-com.rules
Copy and paste this into the empty file, then save and exit the file - Beamng drive free download v0 17.0 2.
This will assign ttyS0 and ttyAMA0 to the dialout group just as they are in Raspbian Jessie. It will also provide the serial0 (GPIO14:15) and serial1 (Bluetooth) aliases, which eases the task of switching the serial ports around between the Bluetooth and GPIO14:15.
The Raspberry Pi 3 WiFi requires firmware to operate. The files brcmfmac43430-sdio.raspberrypi,3-model-b.txt and brcmfmac43430-sdio.bin are both required to be present in /mnt/gentoo/lib/firmware/brcm for Raspberry Pi 3B, while the files brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt and brcmfmac43455-sdio.bin are required for Raspberry Pi 3B Plus.
They can be downloaded via git.kernel.org. Alternatively, you can also pull them from /lib/firmware/brcm on an existing Raspbian installation. Copy the entire /lib/firmware/brcm directory from a Raspbian install into the Gentoo /mnt/gentoo/lib/firmware directory.
You'll also want to ensure that Broadcom IEEE802.11n embedded FullMAC WLAN driver with SDIO bus interface support is enabled in the kernel. In the menu shown below, this is all that needs to be enabled. You can set the FullMAC WLAN driver as a module or compile it into the kernel. If you plan to use only the onboard WiFi, everything else under the Wireless LAN menu can be disabled.
Once the firmware files are copied over to /mnt/gentoo/lib/firmware/brcm, the appropriate kernel settings are built, and a wireless network manager (such as wpa_supplicant) is installed, the WiFi should work.
The Raspberry Pi 3B needs the BCM43430A1.hcd firmware file, and the Raspberry Pi 3B+ needs the BCM4345C0.hcd firmware file. The firmware files can be found in the Raspbian bluez-firmware GitHub repository. The firmware files need to be placed in the /mnt/gentoo/lib/firmware/brcm directory.
Create the firmware directory:
Fetch the Raspberry Pi 3B Bluetooth firmware:
root #
wget -P /mnt/gentoo/lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM43430A1.hcd
Fetch the Raspberry Pi 3B+ Bluetooth firmware:
root #
wget -P /mnt/gentoo/lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM4345C0.hcd
After boot:
Attach the serial device /dev/ttyAMA0 to the Bluetooth stack using btattach, which is provided by the net-wireless/bluez package:
Alternatively, hciattach can be used if net-wireless/bluez is built with the deprecated
USE flag enabled:
root #
hciattach /dev/ttyAMA0 bcm43xx 3000000 flow - <bdaddr>
Both commands will create a HCI device (e.g. hci0) in /sys/class/bluetooth and load the required firmware. To have the HCI device created at boot using btattach, the following OpenRC init script can be used:
Make the init script executable:
After booting Pi
Start btattach:
Start btattach at boot:
The chroot environment is very handy as it allows you to configure your startup run levels (rc-update) as well as update your Portage snapshot (emerge --sync). Additionally, you can set the root password as well as create users in the chroot environment.
If you plan to only access your Pi via SSH, you'll need at least networking on startup, which requires either net.eth0 or dhcpcd to be added to the default run level, as well as OpenSSH itself (sshd).
Much of the setup prior to booting a new Gentoo install is done in a chroot. Chrooting into an arm64 install from some other arch is beyond the scope of this guide. Instead, only the bare minimum setup from outside the chroot is covered. Consult the Embedded Handbook/General/Compiling with qemu user chroot page to learn how to use qemu to establish a cross-chroot.
There are several ways to generate a password hash for /etc/shadow. I usually copy the hash from another system. My Pi uses an /etc/shadow root entry:
The matching password is raspberry.
Feel free to use that line to replace the root entry in /mnt/gentoo/etc/shadow
You can change the password once you are logged in.
On the Pi, the microSD card will be /dev/mmcblk0 with partitions /dev/mmcblk0p1, /dev/mmcblk0p2 and /dev/mmcblk0p3
Edit /mnt/gentoo/etc/fstab to match.
This file will not exist until its created. Create it with the following content.
/mnt/gentoo/boot/config.txt
Here is a config.txt file from a working Raspbian install. If the above does not work, this one should.
This file will not exist until its created. Create it with the following content.
/mnt/gentoo/boot/cmdline.txt
This boots the Pi with a kernel command line of
It really is one long line.
Here is the cmdline.txt file from a working Raspbian install. If the above does not work, this one should. Be sure to set root to your root partition, and rootfstype to your partition type. /dev/mmcblk0p7 and ext4
are shown below as examples.
This step is optional if you can log in using the default
Set the keymap to something you use, e.g.
/mnt/gentoo/etc/conf.d/keymaps
Unmount the microSD card.
root #
umount /mnt/gentoo
When the prompt returns, move the microSD card to the Raspberry Pi and power on.
For 10 seconds (it seems much longer) you should see the GPU 'Rainbow' test pattern, then the familiar boot messages.
Log in at the Pi console. Nothing was added to any runlevels during the install, so networking was not started, nor anything that depends on networking, like ntpd and sshd.
The Pi does not have a hardware real time clock. Its time will be Jan 1, 1970.
As always with Gentoo, if it booted, that's the hard bit done.
It's unlikely that WiFi or Bluetooth will work at first boot. Expect to add some control tools for both.
gcc-6.x allows the use of -march=native
but that will prevent the use of distcc. The above isthe same as gcc-6.3 would set for -march=native
anyway.
With only 1G RAM, and four cores, the conventional MAKEOPTS='-j5'
is a bit aggressive for building larger things. It will force swapping or even appear to lock up the Pi completely, to the point where it won't even respond to the console.
Use files in /etc/portage/env/ and entries in /etc/portage/package.env to set MAKEOPTS on a per package basis.
dhcpcd is not in the stage 3, nor is eth0
in the default runlevel.
will bring up eth0
The default configuration for sshd will not allow password based root logins.
Once you boot, you may have the desire to update @world
first thing. However, as of the time of this writing, the latest stage3 for arm64 was built in December 2016. A lot of things in the tool chain will be out of date with what is on the current Portage tree. Once you've booted the Raspberry Pi and confirmed that you have an internet connection, you'll want to first run emerge --sync to get the absolute latest tree, then run perl-cleaner --all to get all of your Perl packages up to date.
root #
perl-cleaner --all
The Raspberry Pi 3 does not have a hardware real time clock on board. There are vendors online where you can order RTC modules made for the Pi, but if you don't plan to run one, I highly recommend installing a NTP client.
First, we'll set the initial time using the date command. Date and time will be entered in mmddhhmmyyyy
format and the time is in 24-hr format -
As an example, if the time is 10:05PM on 7/31/2017 -
As with most things Gentoo, the NTP daemon is just an emerge away -
Or you can also use busybox variant:
Don't forget to edit the config file:
/etc/conf.d/busybox-ntpd
And start it:
Remove the hardware clock service hwclock from the boot runlevel and replace it with the software clock service swclock -
root #
rc-update add swclock boot
Make sure you have the correct time zone set to the area which most closely matches your locale in /usr/share/zoneinfo -
root #
echo '<YOUR_TIME_ZONE>' > /etc/timezone
As an example, if you live in California, you would do -
Install your timezone libraries -
Start the NTP client and add it to the default runlevel -
root #
rc-update add ntp-client default
On Internet Relay Chat
On the Gentoo Forums, start a new topic in the Gentoo on ARM forum.
I don't mind a PM on the forums with a link to your post. I don't do one to one help via email or the forums PM system. You will either get no response at all or a request to make a public post. That way others may learn from your misfortune.
Everyone contributing to the arm64 software base.
Especially Sakaki, who showed the way on the final steps.