User:Rebeltrouper/Raspberry Pi4 and PI400 64 bit install

The Raspberry Pi 4 increase in power has made it a popular choice for specific tasks. These can include hosting servers, samba shares, streaming devices, and many more. The main problem is the weak hardware of the Raspberry Pi when compared to CPUs. The main point of this guide is to Article description::install Gentoo on a Raspberry Pi using crossdev and qemu to speed up the compiling process for bootstrapping. Then set up a binhost so the PI can download from an computer. The Pi itself is too slow to do compiling for most programs as general tasks can take hours. Finally getting a working X env.

This process will be bootstrapping a Gentoo install from a stage2. Some additional steps will be outlined in making it a stage3 then a stage4. This will be more for an advanced user as certain things can get weird. If you want the easiest way to install and slow way to install Gentoo will be listed later on.

Setup using a normal way that gets complicated. later on a different way where crossdev is built inside a chroot
Crossdev has a problem were a specific package will put certain flags and compilier options from your host machine. This cannot really be fixed as it is auto probing your host machine. The best way to get by this is to compile as many features as you can on the  machine and compile what fails on the  machine itself.

Install crossdev on the PC
An initial set up for the pi is needed in order for it to boot. The PI will need a toolchain in order to build the rest of the system. Crossdev creates a toolchain on the main computer to cross-compile the code into aarch64/arm64 executable code. This will give a major speed boost over trying to do this on the pi itself and should be the main attempt in install and maintaining the pi. To understand the complexity of crossdev, one should read the section on crossdev itself as some familiarity will be assumed from this point on.

It will compile the tools needed and a base system and put them in the folder /usr/aarch64-unknown-linux-gnu. From now on in the crossdev system this is where all of the crossdev building will be put to and compiled into.

kernel compiling and modules
Lastly for the initial set up git will needed to fetch the Raspberry Pi kernel to compile. First create a directory for the pi kernel to exist and will compile it. This will create a temp directory and put everything in there. Then it will git the Raspberry Pi kernel sources, compile the correct config setup for them, allow modifications with menuconfig, compile an image and modules and dtbs for the pi to work, and finally move them into a boot folder to just copy over to your SD card.

Now the kernel is done and will focus on the hard part of getting your system stage2 working. At the end booting will be discussed as arm does not boot the same as amd64.

RPI4 upgrading kernel
The PI iteself can compile its own kernel after it is bootstrapped. It differs slightly than the above method. Below is an example of upgrading a kernel by using the RP4s 4 cores.

Stage2 creation
Now the directory /usr/aarch64-unknown-linux-gnu should exist. The crossdev has build a tool-chain for it to use but not the tool-chain that the system needs. From this point on emerge can be used as normal emerge but instead replace it with emerge-aarch64-unknown-linux-gnu and will use crossdev to compile it into /usr/aarch64-unknown-linux-gnu. Now we need to build the pi actual system.

First edit your make.conf file in /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf and add any optimizations you would like. One recommended one is -mcpu=cortex-a72.

An example of my make.conf is below. The two CFLAGS is that some packages will not compile with corssdev and the first debug should be to remove -mcpu=cortex-a72.

Now you need to build the tool-chain.

Since you are missing most folders in your system, you will have to make them. Some things you will need to remember to add are below.


 * package.use
 * package.accept
 * /home
 * fstab (although it should be done later)
 * proc
 * dev
 * sys

Binfmt setup
In order to chroot into arm64, you will need the instruction set. Pleases look at binfmt on the gentoo wiki in order to complete the build and to chroot into the system. This is needed becasue the system is no longer amd64 but aarch64 and need the correct instruction set.

Chroot into your system to finish building
Crossdev has a problem as stated earlier and thus the only sane way to build anything at this point is to chroot into the system. This is much slower than using crossdev but the only safe way to know things will work. Most X packages will not compile however crossdev should work fine if you are making this headless.

First the system must be prepared to be chroot into it and will have some bugs that need fixed. First need to put qemu inside of the chroot.

Now to change your make.conf file for chroot.

Now add this to your new make.conf

There is one more thing that need to be done to emerge itself and to set up your profile.

This is because an error will occur and to link the python correctly to portage.

It now is close to a stage3 and can follow something like the amd64 install for steps similar to after the chroot.

Chroot advice and speed ups
The chroot system is by far the best way to get things to compile when you are having problems. It is very slow though. One good strategy to get the system to work is to binhost from your own system. The chroot will have nothing in its world and it will want to download and redo every package. It will try and redo things even if you cross-compiled it. So setting up a binhost to download from itself is by far the best way to speed this up. You can cross-compile all the packages you are able to and refinish compiling it in the chroot and not have to redo any steps.

Understanding chroot and crossdev problems
Certain packages will just not compile unless you are very good at coding and can fix them yourself. I am not that good and my solution is to use package.mask liberally some times. One example is that python3.11 will not compile so I masked it and force all programs to use python3.10 instead. Also make sure to check that you are install stable branches and not testing branches. For some reason th chroot likes to install testing versions.

create your SD card and move the items over
Booting from a pi is different than amd64. I believe the pi4 is mostly hardcoded to boot form kernel8.img and it reads a config.txt and cmdline.txt for how to do the boot. An example I use is from Raspbian. If you wish to boot from another kernel, you will have to set kernel= in your config.txt

config.txt

cmdline.txt

Create your USB device you want and read what other people have done. There are optimizations and things like that can be important.

Now your boot and your modules and your root folder should be set up. Add the cmdline.txt and the config.txt to your mount boot.

This system should be bootable in its current state. Although it will only contain what you put in it for the stage4. Now to set up a binhost and change the pi make.conf.

Setting up binhost in your pi
At this point your pi will boot and you can proceed with everything inside the pi via ssh. The PI itself will need a new make.conf. The main point of this version is to finally remove all the qemu/crossdev from it and have it use packages.

My pi make.conf is show below.

The main thing for this make.conf is to set up where the PORTAGE_BINHOST will look. The easiest for me was to just have it scp it over and use ssh-agent and ssh-add for pass wordless authentication. You can run all the heavy compiling in the QEMU on your AMD64 and just pull the packages you want via this way.

In general it should just work and no python workarounds are needed. On the PI it is now a normal gentoo operating system.

Wifi
To get wifi to work you need to install two packages for the RPI4. The following two packages are.

Getting X working
X seems to have problems in crossdev for setting up the correct paths. In order to get X you may need to recompile all of the X related programs on the pi itself. It should still work with bin-hosting afterwards though. An additional item is needed though and that is to tell the pi to have graphics enabled. The following method can enable it in the config.txt

Crossdev without chroot is the best solution I can think of.
Crossdev has problems where it gets confused with your make.conf file of your real system and the crossdev make.conf. There is one solution and that is to build a VM or chroot env where you have only qemu/binfmt/crossdev inside of it. After the system is built and configured you can delete or rename your make.conf in your chroot/VM environment. This will let you use crossdev only in your system giving a MASSIVE speed up. Most packages will compile now unlike before but some will have problems. This gets weird in the sense that you may have a chroot inside of a chroot to do this.

However setting this up in some VM amd64 system following the system and deleting as a said would work the best and probably the most sane. Then you can set up a bridged network device in virt-manager and expose the VM to your network and binhost will work. So far this method has done me wonders as I have setup a binhost system via this method. Seems to have problems with vim/firefox though with crossdev.

Bridge eth0 with br0 to pass through with to virt-manager to expose VM to local network
Creating a VM seems to be a very good setup as a whole for doing this. You can "fix" a lot of the problems and still expose the device to the network.

To create your bridge do the following command.

Now pass this over in virt-manager and do all steps in the first part. Your VM will be the entire section you want to deal with and rename your make.conf to make.conf.bak and cross-dev should work much better.

Installing inside the VM
Since the install is to be as minimal as possible, only get what is needed to boot, dhcpcd, crossdev, and qemu. After you build the system, you need to remove the make.conf file from your host system inside the VM.