User:Rebeltrouper/Raspberry Pi4 and PI400 64 bit install

= Raspberry Pi 4b/400 32/64 bit install =

Overview
The raspberry pi 4 increase in power has made it a popular choice for specific tasks. These can include hosting servers, samba share, streaming devices, and many more. The main problem is the weak hardware of the raspberry pi when compared to amd64 cpus. The main point of this guide is to install gentoo on a raspberry pi using crossdev and qemu to speed up the compiling process for bootstrapping. Then set up a binhost your pi so that it can download from you amd64 computer. The PI itself is to slow to do compiling, unless you want to wait days for something to finish. Finally setting up X in your pi to show off.

This process will be bootstrapping a gentoo install from a stage2 that you create. 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 where it will confuse your make.conf with the target causing failure. The best way to do this is to set up a chroot environment just for the crossdev. After you set it up and compile crossdev and things like that, you will actually delete your make.conf in the chroot and the make.profile.

The best way I can think of is doing this in a VM and go to part2 first and then do the steps of part 1. However a little more knowledge will be needed in how a system works though. But the speed up doing that way can be over 10 fold.

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 your main amd64 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 maintain 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 for your system to build arm64 inside of a user group /usr/aarch64-unknown-linux-gnu. From now on in the crossdev system this is where you will be building things in your system.

kernel compiling and modules
Lastly for the initial set up you will needed git and to fetch the raspberry pi kernel to compile. You will 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 setupt 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.

Stage2 creation
You now should have a directory /usr/aarch64-unknown-linux-gnu. The crossdev has build a tool-chain for it to use but not the tool-chain that the system needs needs. From this point on you can use emerge as you would normally 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 for openrc and systemd to get it working on your system.

For systemd you can use the following commands

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.

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.

Currently testing
If the above method works I may post an iso file with it preconfigured so that it can just work. I guess docker would work better but I do not understand that as well. It should just be a run it in virt-manager and you can edit the size and other stuff.

Initial testing with the VM/crossdev is working very well. So far no problems and when you bridge you can have a real IP. This makes it the most advantageous way to do his. You can get a real system that you do not care if you update as much or not and have it be a host for building all your crossdev packages.

Next step of testing is thinking of a good way to sync /etc/portage with each other. If you change one it will auto update the other. Current thought process is to put a script in your VM and do all the compiling there. Then rsync that setup over to your pi.

World files will be different between chroot and emerge-aarch64
The world files will not be shared. So if you need to chroot in the system will have to reinstall everything as it gets confused. The packages should already be in there though, they just need to be understood that they exist. Maybe even binhosting to itself since all the packages exist. I think maybe setting up a build package may be good to fix this. Maybe ccache (I have never used this though).