User:Maffblaster/Projects/GenPi64

[[Article description::A short set of notes for working with embedded disk images on Linux, specifically Build.Dist disk images produced by the GenPi64 project.]] It is easy to use a more powerful machine in order to operate on disk images.

Get the code
Currently upstream is using the  branch for development. Helps to have the code around for troubleshooting and/or debugging purposes.

Configuring a Gentoo system for development
Instead of compiling the images from a Raspberry Pi, GenPi64 developers generally use a cross-chroot development environment to build the image files on more powerful  hardware. In order to accomplish these development standards, the system may need a kernel recompile and some new packages with special USE flags.

Generally, follow the Embedded Handbook's guide for Compiling with a QEMU user chroot. Specifically the sections for prerequisites binary format handlers.

Kernel configuration
The system kernel will need support for miscellaneous binary formats.

Be aware that building in the symbol like shown above will require system restart; it may take less time to build support as a module and manually modprobe it via:

When not built-in, this feature must be mounted each time it is used:

Packages
It may be helpful to put the following packages in a new set, since the Build.Dist does not have an ebuild specifying or requiring dependencies.

Be sure to add the following necessary USE flags for :

Install the prerequisite packages:

Building the image
When building from a system running systemd as the init system, it is important set the following variables before running

Download, extract, and mount image
As of the present, the community ran GenPi64 project produces zstd compressed files. In order to actively work with one of these images, a few setup steps are necessary.

Download the image from GenPi64.com, or alternatively, obtain an image from the building the stage file instead.

Extract the image to a work area. Tips this can be in zram, tmpfs, or the generic filesystem.

Follow the extraction by mounting the image using. If everything goes well and there are no other loop devices mounted, the output of the command will be :

Long listing the device will show all available partitions for the loop mounted image. For GenPi64 the output should look like the following:

Finally, create mount points if necessary and mount the partitions:

Chrooting
tends to save a few steps in mounting all the virtual file systems.

Alternative mound (without ):

Kernel
Follow the guide from the Raspberry Pi Foundation for compiling the kernel. At the time of this writing, compilation for the Raspberry Pi 4 looks like:

Writing the image
Generally the image will be written to a microSD card via mmc connection:

Custom kernel compiling
Download a branch of the Raspberry Pi Foundation sources from GitHub. For this example rpi-5.11.y will be used:

Modify the kernel following the directions on

After modifying the kernel, manually tweak the CONFIG_LOCALVERSION configuration value so that the installed modules do not clobber existing modules in :

Appending the suffix  specifies the build is for the Pi 4.

CPU frequency scaling
Being a general purpose device, the base clock of the Rpi 4 is 700 MHz, however the clock speed should scale as appropriate for the duties performed. Here are a few tips to help adjust from the alpha5 GenPi64 base image:


 * Change the default CPUfreq governor from  to.
 * Scaling governor can be checked via:
 * Install
 * Set the governor to ondemand:
 * Measure CPU frequency speed with:
 * Overclock the ARM core to at least 1200 MHz via . Default arm_freq value for the Rpi4 is  according to this list.

Bootloader firmware update
It is wise to check the firmware for updates every few months:

Set static IP address
By default the system will pull a DHCP address. In order to set a static IP on the network, NetworkManager is the utility available for this purpose. It will need added to the default runlevel (for OpenRC images).

Verify ntp and ntp-client will maintain system time
Most single board computers (true at least until Raspberry 4) do not include onboard hardware clocks, it is important for the system to query the network in order to set the software clock while the system is running. This generally occurs once during system boot time, and then is maintained while the system has power and a connection to an NTP server in order to prevent clock drift. It is generally useful to not see the command return a time from the 1970s.