Notes from building a minimum Linux Gentoo Kernel for a Raspberry Pi

Recently I have been working with more and more Raspberry Pi single board computers and as a person who likes the Linux Gentoo distribution I got the urge to make a bare minimum kernel.  These are basically some notes based on what I have learned trying to build a bare-bones custom kernel for the Raspberry Pi.

If you find issues with this kernel config, or find something I missed, please let me know in a comment so I can take a look into it and update information.

I am not going to go quite into detail how to build a kernel and such, this guide is just a reference to what drivers I found are necessary for a bare bones kernel, without any extra drivers.  The only extra things I think I added is for some USB-Serial drivers, since they are required for my application, they can be safely removed.

This is using the Raspberry Pi kernel sources sys-kernel/raspberrypi-sources-4.19.9999, emerge or update this before proceeding.  Also to note, this is for a 32-bit kernel.  I have not been able to get this to work on the new Raspberry Pi 4 yet, it just won’t boot… I will try to figure out why at a later date.

The version that I have installed now is 4.19.86, and this configuration is for that version.  You should be able to use this with newer kernel versions, just use make oldconfig before using make menuconfig.

I started with a minimum kernel with almost no drivers included, and slowly added the drivers necessary to obtain the functionality required, trying to get drivers for all the hardware on the board.  This process of building, checking, rebuilding took several full days and I would like to document what I found out is the minimum install necessary.

I am not quite confident the sound drivers are correct yet, but will hopefully get a chance to test this in the future.

This kernel config posted here works with the following hardware, since it is what I had on hand to test with:
+ Raspberry Pi Zero W
+ Raspberry Pi Zero WH
+ Raspberry Pi 3 Model B
+ Raspberry Pi 3 Model B Plus

In order to get the display to work right on the Raspberry Pi Zero W I had to edit the config.txt file on the boot partition and uncomment this line at the bottom… not sure why yet… only the Raspberry Pi Zero W appears to need it.


I started working with a Raspberry Pi 3 Model B, then after that was working moved onto testing on the Zero W and 3 Model B Plus.  Below is some detail of things I found to be specific to a specific platform…

Device Drivers – Network Device Support – USB Network Adapters – Multi-purpose USB Networking Framework – SMSC LAN95XX based USB 2.0 10/100 ethernet devices
+ Wired ethernet for Raspberry Pi 3B

Device Drivers – USB support – Synopsis DWC host support
+ USB for Raspberry Pi Zero W

Device Drivers – Network Device Support – USB Network Adapters – Microchip LAN78XX Based USB Ethernet Adapters
+ Wired ethernet for Raspberry Pi 3B Plus

Device Drivers – Network Device Support – Wireless LAN – Broadcom devices – Broadcom FullMAC WLAN driver
+ Wireless LAN driver

Device Drivers – Network Device Support – Wireless LAN – Broadcom devices – SDIO bus interface support for FullMAC driver
+ Wireless LAN driver support

Sheeva64, rebuilding the kernel

In this post I am going to take a look at rebuilding the Sheeva64’s kernel.  The Sheeva64 is a 64-bit ARM based single board computer based on a Marvell Armada 3720 SoC.  More information about the SoC can be found at Marvell’s website here (, or GlobalScale Technologies (the manufacturer) website here (

This process is also very similar to the guide at located here (  The SoC is identical, but the board layout and peripherals are slightly different, therefore the exact kernel configuration won’t have all the drivers necessary for the Sheeva64, but it doesn’t hurt to give it a try, it won’t break anything.

First I would like to give credit to the origianl source for most of this located at the below link.
I would like to thank the author for deciphring all the logic in the build system so I could come up with some parts of these instructions.

Next the website and their efforts to make a stand alone fully automated build solution for various single board computers, it is really quite impressive.  The system put together is a really, really nice build setup and recommend you try it if you have any supported boards.  Unfortinatly the Sheeva64 is not supported yet, but a very close match is the EspressoBin containing the exact same Marvell Armada 3720 SoC.
Because the peripherals and board are different the EspressoBin build will not work 100% correctly, but it helped me come up with the below script.  I sure hope they continue supporting and updating their build system.

The actual build environment, to which I sourced some information, such as the toolchains and patches, is here.

I will try to provide references to original sources and give credit where appropiate.  This is an effort to provide a detailed resource to assist others with the Sheeva64 kernel building process, no harm intended.
If there is something used here that is not referenced properly, please let me know and I will add the appropriate references.

While I try to be accurate, it is possible I missed something or made some mistakes, please double check what you do before you blindly copy-paste and run commands, just incase.  Especially with updating the actual /boot files on the Sheeva64, and u-boot environment, please be very careful and double check.  Some mistakes in here can be costly and take time to fix.

I shouldn’t have to remind you to make back up copies of these items you are going to download, in original unmodified form, incase they ever go away.  More often than not external links will disapear, with no easy way to get ahold of them again.

For peace of mind I would make sure you have an offline copy of these instructions and all required source files.
To ensure you have a build environment that always works, a VM or VirtualMachine is not a bad idea, it will always work and keep its last used state.

Personally I make tar/bz2 backups of sources in their original state for archive purposes.  The below command will help with that (the dot on the end is important, don’t forget it).

tar -jcvpf your_file_name.tar.bz2 –directory=/path_to_folder_you_want_to_archive .

Now onto the actual kernel creation process

rename all the “/your_build_root” to your actual build root.

Create your working folder
cd /your_build_root
mkdir sheeva64_kernel_builder_20190926
cd /your_build_root/sheeva64_kernel_builder_20190926

Grab the configuration file for the Sheeva64, you can get it by one of the following methods below, although I may upload it here soon.
This file will be used as the initial kernel configuration to base your new kernel on, since it has a known working configuration.
For this to work best, the kernel version should match, all the way down to the 120 at the end of the version number.
Use one of the below commands, result should be the same.
cat /proc/config.gz | gunzip > config_4.4.120-armada-18.09.2-g302564291ad5
zcat /proc/config.gz > config_4.4.120-armada-18.09.2-g302564291ad5

For the kernel version running, you can use the below command to name the file accurately.
This sniplet of code is from the below source.

echo “Modules dir: /lib/modules/$(uname -r) for kernel version $(uname -r)”

Next, grab the recommended toolchain from the below link.

Just use wget to grab it quick, if you would like a troublefree download.

You can see other files related to this toolchain by opening the folder
It is very likely others will work, but, this is what I used and works

Once you get this downloaded extract the tar file using the below command, it will end up in its own folder
tar -xvpf gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz

If the above link ever goes away, I will try to find a way to fix it or make it available

Grab kernel files from the Marvell repositiory
git clone

It might be a good idea to archive these, just incase, but optional
tar -jcvpf linux-marvell_20190927.tar.bz2 –directory=/your_build_root/sheeva64_kernel_builder_20190926/linux-marvell .

Change to the linux-marvell folder
cd linux-marvell

Checkout the correct version, this version (branch) for sure works, I have not tested others, you are welcome to try other branches
git checkout linux-4.4.120-armada-18.09

Apply patches
This automation script was obtained from here
Original maker’s webpage is here

The patch files are from here

You might find it easier just to use a git clone (git clone and download the entire repository, then copy out what you need instead of messing with downloading individual files.  These patches should be placed in the below folder to line up with the patch command, also below


I believe the “” folder is for later kernel versions, if you want to try that out, but I stuck with 4.14.120 since I know it works.

I believe these patches apply to 4.14.120, but not quite sure, they may already be patched into the linux-marvell source.
Including them just incase… it is possible you don’t need them
Currently this patch script also just runs all of the patches and applies the ones it can… maybe not the best way to do it, will get back to fixing it later

Run the next command inside the linux-marvell folder.
The working copy needs to be clean and there must be no untracked files.
Perform a “git reset –hard” to clean out any problems, all changes will be reverted to the last commit
A commit will be performed after each successful patch
Make sure the file is executable, if not fix it
chmod u+x ../
../ ../patches/kernel/mvebu64-default/0005-patch-4.14.120-121.patch

Copy over the configuration file
cp ../config_4.4.120-armada-18.09.2-g302564291ad5 .config

Update .config if changing to a new kernel using make oldconfig.
CROSS_COMPILE=/your_build_root/sheeva64_kernel_builder_20190926/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- ARCH=arm64 make oldconfig

With our kernel sources now prepared, we can go onto configuration and the actual building.

Run menuconfig to customize the kernel, if you would like to, can skip this if you happy with the original configuration.
CROSS_COMPILE=/your_build_root/sheeva64_kernel_builder_20190926/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- ARCH=arm64 make menuconfig

Now is your chance to turn on any driver support you may want for USB serial devices, etc.

Finaly build the kernel.
It takes the i7-9700K CPU @ 3.60GHz running Linux Gentoo that I recently put together for compiling about 5 minutes or so to compile the kernel with its original options.
CROSS_COMPILE=/your_build_root/sheeva64_kernel_builder_20190926/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- ARCH=arm64 make

Double check kernel modules got built.
CROSS_COMPILE=/your_build_root/sheeva64_kernel_builder_20190926/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- ARCH=arm64 make modules

Copy out the kernel modules, be careful here, if you leave off the INSTALL_MOD_PATH it will attempt to copy into your /lib/modules folder!!!
CROSS_COMPILE=/your_build_root/sheeva64_kernel_builder_20190926/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- ARCH=arm64 make modules_install INSTALL_MOD_PATH=/your_build_root/sheeva64_kernel_builder_20190926/modules_install

You will find your shiny new kernel under this path, copy it out to where you choose
This file will eventually make its way into your Sheeva64’s /boot folder, but I would change the name and not overwrite the original, just incase.

Also the kernel modules will be needed too, copy them into /lib/modules on the Sheeva64

The dtb file, or flattened device tree will be located here, you should not need to update it though, it will be slightly off since there is not one taylored specifically for the Sheeva64 and you will find some devices won’t work, or will be unstable.  If you choose to compile a different kernel version, this DTB file *might* need to be updated as well.
I can’t recommend a specific one since there is not a direct match for the Sheeva64, but you are welcome to experiment with any of the files marked for the armada-3720 if you want to test things out.

Thats it! Place your new kernel into your Sheeva64 and see if it boots up correctly!
Personally these are the steps I do to update the kernel.
+ scp the files over
+ the Image file goes in /boot but I would rename it to something like Image_20190927 and append the date, don’t overwrite your original
+ the copy the entire kernel modules folder, 4.4.120-armada-18.09.2-g4b3df2c67631, into /lib/modules
+ plug in the mini-USB cable
+ fire up minicom or a terminal program so I can see what the Sheeva64 is doing (115200-8-N-1, no flow control)
+ issue a sudo “shutdown -r now” to restart the Sheeva64 gracefully
+ interrupt the u-boot autoboot process on the terminal when it comes up
+ use “env edit image_name” to direct u-boot to boot the new kernel
+ use “env save” to save the above changes
+ use “boot” to continue the boot process, or “reset” to reset the Sheeva64 and let it autoboot

At this point, you can see in the terminal window if your kernel boots or not, if all goes well, you will see the login prompt
If there are any issues, freezes, or panics, there is a problem with your kernel build, missing an important driver, or other issues
If this is the case perform these steps to bring back the original kernel
+ restart the Sheeva64 by cycling power
+ interrupt the autoboot process in terminal
+ use “env edit image_name” to restore your previous kernel
+ use “env save” to save your changes
+ use “boot” to continue the boot process, or “reset” to reset the Sheeva64 and let it autoboot

Your Sheeva64 should now be back on the old kernel and booting up.
At this point you can try to identify what went wrong and attempt another kernel build changing options in menuconfig as necessary.

Bringing a 6 year old DreamPlug (arm based) Gentoo installation up to date…

I am posting these notes on my blog hoping it is useful to someone in the future… and saves someone the 3 days it took me to come to these conclusions.

This is a post in progress so I will update this again a little later, it may have a few mistakes for the time being.

I had a very old (from the year 2013) Gentoo install on a ARM based GlobalScale DreamPlug and wanted to bring it up to date (as of 2019-08-23).

The first thing that needs to be done is to bring the package manager, portage (emerge), up to date which was a little tricky due to dependencies. The idea here is to install the absolute minimum required to get portage up to date, then use the new portage to bring the rest of the system up to date.

In order to update portage, an update to python is absolutely required, which means filling the requirements of python… some side stepping can be done to achieve this, which I had to do. One of the annoying roadblocks was the EAPI requirement, which this current setup was at ‘5’, but the latest python needs ‘6’ or ‘7’ to update… which in turn is needed by portage.

We have to solve this chicken and egg problem, so after a lot of trial and error I resorted to the very unconventional method of editing the portage tree of the packages I needed to update and decreased their EAPI to 5, hoping nothing would break… and for the required packages it worked nicely. Just make sure you resync your portage tree after to erase all these ‘hacks’ that are needed.

After each successful time consuming step I performed a complete tar backup of the system so I could recover to that step if I messed up the system, and I have done that multiple times already.

The following tar commands can be used to create an archive in that case…
Be careful with copy paste… it might miss some of the dots or double hyphons.

Backup command

sudo tar -jcvpf ~/dev_dreamplug/dreamplug_rootfs_2019-08-21.tar.bz2 --directory=/media/dreamplug-000/ --exclude=/proc/* --exclude=/dev/pt --exclude=/tmp/* --exclude=/.Trash* --exclude=/original .

Format command (to clean the partition and prep it for a restore, I don’t remind everyone that this will delete everything on it… do I?)

sudo mkfs -t ext3 -L dreamplug-000 /dev/sdb2

Restore command

sudo tar -xjpf ~/dev_dreamplug/dreamplug_rootfs_2019-08-21.tar.bz2 --directory=/media/dreamplug-000


After these are updated, install new portage (emerge) and the rest of the updates will be easier to resolve once portage is up to date.
Most of the trouble arises from the EAPI flag, which this old version of portage is a ‘5’ but all the new emerges require a ‘6’ or ‘7’, this blocks the emerge on several packages, although the necessary packages emerge just fine with this old version of portage.

Since portage will attempt to rebuild the manifest with our changes, if we want to edit ta single .ebuild file, we have to edit all in the folder since it will attempt to rebuild the manifest… and it won’t recognize a EAPI greater than 5 when it does this. This means all .ebuilds in a single folder will have to have their EAPI changed to 5. Don’t worry it will all revert when we do an emerge –sync to erase all our nasty hacks.

One downside to editing the portage tree is that the digest CRC check will fail since the package has been edited. We can bypass the digest check by adding the –digest flag to the emerge command.

This change to the portage tree is only temporary and as soon as portage is up to date, it is recommended to revert or resync the portage tree to reset everything back. Once the new portage is installed the EAPI changes will not be required as the new portage is EAPI 7 compatible.

Go ahead and sync the portage tree now, my portage tree was mounted to /usr/portage from a squash filesystem (read only) to save space, so I had to copy out the contents, unmount the /usr/portage, and move contents into the new empty /usr/portage directory.

emerge –sync

You will have to reselect the profile, in my case I chose 1
eselect profile set 1

Below, change EAPI to 5 in all the .ebuilds in the below folders…
We should all know this is not the best way of doing things, but I was left with no other choice, and it worked in my situation. Changing the EAPI can run you into issues if some feature not available in EAPI 5 is required. I was lucky. nCurses, however, requires eapply, implemented in EAPI6, luckily I could hold off on this as I had 5.9 currently installed, and it was enough to get through the portage update.

The following below packages need to be changed to EAPI ‘5’.
This is located at the top of each .ebuild file.
These can all be found in /usr/portage.


Next, with the above changes, we need to get python updated, I was using a system with python 2.7, I did not have python3 installed at all. This may have complicated things for be, but, this is the process I followed. I did this all without installing python3. Simply I have a minimum build system where space is a luxury, and wanted to avoid all I could, so python3 is not included in the build.

Begin by taking care of the prerequisite s.

emerge -av –digest –oneshot =sys-devel/automake-1.15.1-r2

emerge -av –digest –oneshot elt-patches

Finally we can emerge the new python, in my case 2.7.15.
emerge -av –digest –oneshot –nodeps =dev-lang/python-2.7.15

We need to take care of a few more depends required my the new portage (version 2.3.69).
emerge -C python-exec
emerge -C eselect-python
***we unmerged select-python, the python link is now broken, we need to fix it***
sudo rm /usr/bin/python
sudo ln -s /usr/bin/python2 /usr/bin/python
***emerge should now be working so continue with the emerge***

emerge -av –digest –oneshot python-exec

At last portage can be emerged, ignoring dependencies.
sudo emerge -av –oneshot –nodeps portage

sudo mkdir /usr/local/portage/metadata
echo ‘masters = gentoo’ >> /usr/local/portage/metadata/layout.conf

***this should get portage up to date***

***below is what my portage information looked like after bringing portage up to date***

Performing a emerge –version resulted in the following output…
This should give you an idea of minimum requirements to get this version of portage working enough continue with the process.

emerge --version
Portage 2.3.69 (python 2.7.15-final-0, default/linux/arm/17.0, gcc-4.6.3, glibc-2.15-r3, 3.2.5-dreamplug armv5tel)

emerge --info
Portage 2.3.69 (python 2.7.15-final-0, default/linux/arm/17.0, gcc-4.6.3, glibc-2.15-r3, 3.2.5-dreamplug armv5tel)
System uname: Linux-3.2.5-dreamplug-armv5tel-Feroceon_88FR131_rev_1_-v5l-with-gentoo-2.2
KiB Mem: 513668 total, 19280 free
KiB Swap: 0 total, 0 free
Timestamp of repository gentoo: Wed, 21 Aug 2019 15:30:01 +0000
Head commit of repository gentoo: cdda9adf72b626d020a063419c1f376755d1b456
sh bash 4.2_p45
ld GNU ld (GNU Binutils) 2.22
distcc 3.1 armv5tel-softfloat-linux-gnueabi [disabled]
app-shells/bash: 4.2_p45::gentoo
dev-lang/perl: 5.12.4-r1::gentoo
dev-lang/python: 2.7.15::gentoo
dev-util/pkgconfig: 0.28::gentoo
sys-apps/baselayout: 2.2::gentoo
sys-apps/openrc: 0.11.8::gentoo
sys-apps/sandbox: 2.5::gentoo
sys-devel/autoconf: 2.69::gentoo
sys-devel/automake: 1.12.6::gentoo, 1.15.1-r2::gentoo
sys-devel/binutils: 2.22-r1::gentoo
sys-devel/gcc: 4.6.3::gentoo
sys-devel/gcc-config: 1.7.3::gentoo
sys-devel/libtool: 2.4-r1::gentoo
sys-devel/make: 3.82-r4::gentoo
sys-kernel/linux-headers: 3.7::gentoo (virtual/os-headers)
sys-libs/glibc: 2.15-r3::gentoo

location: /usr/portage
sync-type: rsync
sync-uri: rsync://
priority: -1000
sync-rsync-verify-jobs: 1
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-max-age: 24

location: /usr/local/portage
masters: gentoo
priority: 0

CFLAGS="-Os -march=armv5te -pipe"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d"
CXXFLAGS="-Os -march=armv5te -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
USE="acl arm bash-completion berkdb bzip2 cli crypt cxx dri fortran fuse gdbm iconv ipv6 ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl svg tcpd unicode usb vim-syntax xattr zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="exynos fbdev omap dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Next is to fix (resync) the portage tree, this will wipe out all of our EAPI hacks (changes) that we made to the portage tree.
emerge –sync
At this point you should have a working portage system capable of bringing the rest of the system up to date.
Some other useful information, since the DreamPlug has only 512MB RAM it may be necessary to create a swap file to emerge large things like gcc. The below commands will create and activate a swap file.

***temporary swap file***
***this creates a 512MB sized swap file***
osaka screen # dd if=/dev/zero of=/swapfile count=1M
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 47.2674 s, 11.4 MB/s

***if you want a 1024MB swap file, execute the below command instead
osaka screen # dd if=/dev/zero of=/swapfile count=2M

***next format the swap file with the below command***
osaka screen # mkswap /swapfile
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=e62f5859-f995-45a6-86ce-d60246a7cd69

***finally activate the swap file***
osaka screen # swapon /swapfile

***verify memory usage***
osaka screen # cat /proc/meminfo
***you should see the swap file showing up now***

***command to add to /etc/fstab***
***if you want to make this swap file permanent***
***otherwise just delete the above created file after you are done and either disabled swap or restarted
/swapfile none swap sw,loop 0 0

Another note, you may not want to do this in a SD card, especially the swap file, I recommend a USB hard disk for this.
The SD card will get hammered not only by the swap file, but by all the compiling.

A note about installing Perl that I ran into,
Please see the reference here for the bug information, this is still present in version 5.30.0

Basically when installing perl you will need to use this command…
EXTRA_ECONF=”-Dd_u32align” emerge -av —oneshot perl

The EXTRA_ECONF will append -Dd_u32align onto the configure command to force 32-bit alignment, which is not being detected properly for some reason or another right now.