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, recovering/reloading U-Boot from a bricked state

This took a while to get back to but I actually just now bricked my Sheeva64 (corrupted U-Boot) so I could repeat this procedure and make sure everything works correctly.

The layout of the blog doesn’t help with making this easy to read, especially the longer lines, going to look into trying out some different themes soon to address this…

I am actually writing this up as I am confirming and actually doing the steps, so hopefully it all goes well, if not I will have a cool new paperweight!
I just ran through ALL the instuctions written here again after writing this, so there should be no issues, if there are, please leave me a comment!

First of all a brief introduction to the bootloader and some general information… can be skipped if you are familiar with it, just to be complete I will include it.

This is a procedure that took a while to work out, after that I was directed to the official method by GlocabScale Technologies, which I will also provide at the end.

When we are talking about a bricked Sheeva64 there are a few different ways to brick it…
1. Somehow or another the kernel image or internal eMMC (SD card) or whatever you are booting off from is corrupted.
This is actually not very serious and can be repaired without much trouble, which I will write about in another post.
2. The bootloader (U-Boot) is corrupted or been erased.  U-Boot is essentially what is first executed when the Sheeva64 CPU is turned on.

U-Boot is responsible for a couple of very important functions, first it initializes very low level stuff.
This includes things like the CPU clocks, DDR memory controller and other peripherals, ethernet, etc.

It this provides this information to the kernel that is loaded so the kernel knows what devices exist, etc in the hardware.
U-Boot, having support for FAT and sometimes other filesystems, reads the kernel image (its only a few megabytes) and
copies that into DDR memory at a predetermined expected address then executes that kernel code.

This essentially loads the kernel and passes control to the kernel which then loads the operating system, following a similar path to how a normal x86/x64 system boots up.

The difference here with the Sheeva64 it is does not have a traditional BIOS, which is normally responsible for low level initialization functions in a x86/x64 PC.  This is where U-Boot comes in, it takes on the role of low level initializtion and then loads and executes the kernel.

This U-Boot loader is stored in a small chip called a SPI NOR (or NAND) memory chip, it only has a few megabytes of storage space, just enough for the U-Boot loader to fit.
If this bootloader (the code first executed by the Sheeva64 CPU) is not present… nothing happens when you turn it on… the device is practically bricked.

While the Sheeva64 is bricked, and there is no bootable U-Boot in the SPI NOR flash, it can still be brought up manually, but, after it is brought up a new U-Boot will need to be written to restore the ability for the Sheeva64 to self boot again.

With the DreamPlug, another product by GlobalScale Technologies, which I have used for many years, it was possible to connect a JTAG debugger to the CPU and put the CPU into debug mode and upload a U-Boot image into the DDR memory, then execute it, allowing the DreamPlug to be brought up when U-Boot was corrupted.

However, while I can JTAG into the Sheeva64 CPU (I have tried) I can read the CPU ID information, etc, but have not managed to be able to initialize the CPU correctly or bring it up by hand through the JTAG debug interface, and I think this has something to do with the new security features of the new Armada A3700 CPU.  It requires a very specific initialization sequence to be followed, and lucky for us, it has its own debug interface now which is automatically entered if U-Boot can’t be loaded, or if a boot mode jumper is set.

Basically, long story short, you don’t even need to open up the Sheeva64 to be able to recover the U-Boot since JTAG access is no longer necessary.
We are going to use the recovery prompt built into the A3700 CPU available through the debug serial port (mini USB) connection.

Now onto the recovery process… first we are going to verify that the recovery command prompt shows up correctly on your Sheeva64.
Connect a micro USB table to the debug port on the Sheeva64 and open a serial terminal using the following settings… 115200-8-N-1
I am going to upload a python program that can also be used, and I recommand and encourage you to look at the python source before executing it on your own PC to make sure it doesn’t contain anything bad…

python3 -m –raw –eol CR –encoding ascii /dev/ttyUSB0 115200

The debug USB (serial) port on the Sheeva64 is powered from the USB connection so you won’t lose the USB connection if power is removed from the Sheeva64, which is good for us because we will need a way to reset it.
With the cable connected, and your serial terminal open, reset the Sheeva64 by unplugging it and plugging it back in, you should see a prompt similar to this image…


Just press enter here and if you get a “E” or error response back you are good, you have access to the CPU recovery console.
Next we are going to instruct the CPU to expect an upload of some bootable code, there are a few files that have to be uploaded, and it will take some time.
I am going to provide the files that I generated here, which is a lengthy process, which I will also outline how to do in this post.

Grab the “sheeva64_debricker_20191203.tar.bz2” file and extract it to a location of your choice, it should all be self-contained.
tar -xjf sheeva64_debricker_20191203.tar.bz2

We are going to do a couple things, and they have to be done rather quickly, so having three terminal windows ready to execute these commands might be useful.
I recommend having the following three terminal windows open and will refer to them as termianl 1, 2, and 3.
1. The terminal with the recovery console open, it turns out the python script above is a little more friendly as it auto disconnects correctly when we execute the next command in terminal 2.
2. The terminal that we will use to upload the new RAM bootable U-Boot image and other related processor specific code.
3. The terminal that you will use with minicom or your favorite terminal software to open as soon as the CPU is executing the U-Boot.

Here is am image of how I had my screen setup for this, lining up each window side by side.


Change to the folder that the above tar.bz2 file was extracted in for terminal 2, we will be executing some things from in there.
As a note, this process might need sudo access to the /dev/ttyUSB0 device, if you are not comfortable with this setup a VM to sandbox this, or setup a throw away livecd install on another machine.
/dev/ttyUSB0 is assumed below, please adjust things if necessary…

After U-Boot loads up, it will continue, just like normal, to load up your kernel and start up your OS, we don’t want that to happen so be quick to connect up in terminal 3 and press that “any key” to interrupt the U-Boot process… most likely your OS will not even load correctly as this RAM version of U-Boot functions just enough to bring the system up to rewrite the U-Boot loader into SPI NOR flash.

There are a couple small things to warn about.  This RAM loaded U-Boot is capable of overriting your enviornment variables, so don’t try to save any U-Boot settings, it might foul them up.
If your U-Boot settings are also corrupted, I will include some instructions below to reset those back.

Here is the sequence we are going to do…
I think you will need pyserial for this, some reference is here
If you can’t use the below command it doesn’t hurt to try another serial software and disconnect it after typing in the wtp command.
On terminal 1 execute
sudo python3 -m –raw –eol CR –encoding ascii /dev/ttyUSB0 115200

type “wtp” and press enter.
The CPU will be put into a mode to wait for an upload from this same USB serial debug cable you are connected to now.


On terminal 2, execute the following command…
sudo ./WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E




This is glitchy and sometimes does not work.  It should not stop, or appear frozen during any time of execution.
If it appears frozen, something went wrong, Ctrl + C it and reset the Sheeva64 by unplugging and reconnecting power… wait a few seconds after unplugging to be sure its fully reset.
After it is reset, do the above wtp step again to put it in the serial upload mode and try again.  It took me many attempts to figure this part out, but it can be a little finicky.

The upload process will take a little over a minute to complete (around 1min and 15sec on my setup), be watching your screen and be prepared to connect minicom or another serial terminal software quickly (on terminal 3), you need to interrupt the boot sequence, press any key when that message pops up (on terminal 3) to interrupt the startup process.
After upload is complete and command prompt is returned on terminal 2 get connected on terminal 3 and now we should have a U-Boot interface to work with.


Remember, now U-Boot is running from RAM so if we reset or remove power now we have to begin again from step 1, we still havent’t copied the bootloader back into the NOR flash, this is the next step.
Grab a USB memory stick that you have laying around, it should be formatted VFAT or FAT32 (possibly FAT16 works too) and copy the sheeva64-bootloader-cpu-1000-ddr4-1cs-1g-atf-711ecd32-uboot-gc338309136-utils-57a8e47-20190625-REL.bin over to it in the root folder.  This is in the “u-boot_images” folder in the “sheeva64_debricker_20191203.tar.bz2” file.

A brief explination of the filename here, the CPU operates at 1000Mhz, DDR is DDR4 type, 1CS setting, and 1GB in quantity.
There are some other files avaialble from the GlobalScale Technologies website so be sure to grab the if needed.

Insert this into the Sheeva64’s bottom USB2.0 port, the USB3.0 won’t work, I think the USB3.0 driver is not working correctly in the make-shift recovery bootloader yet…
Execute this command in the U-Boot console, this will rewrite your bootloader…

bubt sheeva64-bootloader-cpu-1000-ddr4-1cs-1g-atf-711ecd32-uboot-gc338309136-utils-57a8e47-20190625-REL.bin spi usb

This will take a little time to complete, be patient and give it some time, erasing and writing to NOR flash isn’t the fastest thing in the world.
Once writing to the NOR flash is complete the USB memory stick can be removed and you can reset the Sheeva64 with the “reset” command.
It should now self-boot into the U-Boot console.  Next, if your U-Boot enviornment variables are fouled up you will still have to fix those, but, the hard part is done.
To fix the U-Boot variables execute the below commands in the U-Boot console…

*** none of these commands will save until the “saveenv” or “hw_info store” command is used, so if you make a mistake, just use “reset” and try again.
*** these fix the enviornment variables
env default -a
setenv image_name boot/Image
setenv fdt_name boot/armada-3720-sheeva64.dtb
setenv bootcmd ‘mmc dev 1; ext4load mmc 1:1 $kernel_addr_r $image_name; ext4load mmc 1:1 $fdt_addr_r $fdt_name; setenv bootargs $console root=PARTUUID=89708921-01 rw rootwait net.ifnames=0 biosdevname=0; booti $kernel_addr_r – $fdt_addr_r’

*** these will fix your ethernet address, if it somehow got changed…
*** ethaddr is printed on the label on the back of the Sheeva64, but I don’t know where eth1addr comes from, I am going to have to bring this up to GlobalScale and ask them about it.
setenv pcb_rev 5.0.1
setenv ethaddr xx:xx:xx:xx:xx:xx
setenv eth1addr xx:xx:xx:xx:xx:xx
hw_info store

*** the below command will execute the boot process

This concludes the recovery process of the U-Boot boot loader.  If the SD card or internal eMMC is corrupted, this is a different recovery procedure.
There is information on the GlobalScale Technologies website here to help with that…
From here open up the Downloads section and V5.
A direct link is also below

I have trouble opening this up in Safari on my MacBook, it seems FTP is not a built in feature of browsers anymore…

Next, if the above binary does not work for you, or you want to build this from scratch and get your own U-Boot enviornment setup, this next section is for you.

I do want to put a thank you out to the following website which provided some invaluable insight into how to build some of the files used above.

Original source for some of this information is here… it is a good read, but also quite a bit technical.

Now onto the more technical explination and how to generate the needed files from scratch.  All necessary things are open source and avaiable to download as of this writing.

To generate everything I used from scratch, first download the following four sources and set the branches to the things listed below…
I will provide the exact commands below.

marvel-tools:, branch A3700_utils-armada-18.12
marvell-ddr:, branch mv_ddr-armada-18.12
ATF:, branch atf-v1.5-armada-18.12
U-Boot:, branch u-boot-2018.03-armada-18.12

This is going to be wierd, but we will need not one, but two GCC toolchains to build this correctly.
The first toolchain is for the ARM64 Sheeva64 Marvell Armanda A3700 SoC (CPU).
The second toolchain is for our own PC, to generate the code.  I am assuing you are on a x86 or x64 system here…
If your platform is different (this was performed on a x64 based i7 platform), please modify the instructions to your setup… which I will not go into detail here how to do this…


Will other toolchains work? Maybe, but why not just use what is known to work for this process… then once you have a working setup you can experiment with other things such as toolchains.
I am going to host all these files on this blog site for completeness sake, and for the reason that stuff on the internet goes missing a lot these days and links break.

A few of the harder to extract parts are here for download hosted here, but they were originally sourced from open source sources.  For these few files I will add a section of how to extract these at a later date.

Then of course, if you are in doubt at all about trusting anything you download here, set yourself up a sandboxed or a throw-away VM machine and conduct the Sheeva64 recovery from a system that you have no concerns about breaking.

As of writing this post I tested each step as writing the instructions so everything should be good.

I am going to basically write somewhat of a script below, and you should almost be able to copy paste line-for-line and just execute them.

First we need to make a folder for where we will be working from, and I am choosing the following.

mkdir /home/user/sheeva64_debricker
cd /home/user/sheeva64_debricker

mkdir /home/user/sheeva64_debricker/downloads
cd /home/user/sheeva64_debricker/downloads


*** extract some misc necessities
cd /home/user/sheeva64_debricker
tar -xjvf /home/user/sheeva64_debricker/downloads/sheeva64_debricker_blobs.tar.bz2
tar -xjvf /home/user/sheeva64_debricker/downloads/sheeva64_debricker_patches.tar.bz2
tar -xjvf /home/user/sheeva64_debricker/downloads/sheeva64_debricker_u-boot_images.tar.bz2

mkdir /home/user/sheeva64_debricker/toolchains
cd /home/user/sheeva64_debricker/toolchains

*** extract the downloaded toolchains here
tar -xvpf /home/user/sheeva64_debricker/downloads/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu.tar.xz
tar -xvpf /home/user/sheeva64_debricker/downloads/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabi.tar.xz

*** grab the required utilities
mkdir /home/user/sheeva64_debricker/utils

cd /home/user/sheeva64_debricker/utils
git clone
cd A3700-utils-marvell
git checkout A3700_utils-armada-18.12

cd /home/user/sheeva64_debricker/utils
git clone
cd mv-ddr-marvell
git checkout mv_ddr-armada-18.12

cd /home/user/sheeva64_debricker/utils
git clone
cd atf-marvell
git checkout atf-v1.5-armada-18.12

cd /home/user/sheeva64_debricker/utils
git clone
cd u-boot-marvell
git checkout u-boot-2018.03-armada-18.12

*** build the tools
cd /home/user/sheeva64_debricker/utils/atf-marvell

make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_800_DDR_800 DDR_TOPOLOGY=2 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 CROSS_COMPILE=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-

cp /home/user/sheeva64_debricker/blobs/espressobin/DDR_TOPOLOGY_2-*.txt /home/user/sheeva64_debricker/utils/A3700-utils-marvell/tim/ddr/.

cd /home/user/sheeva64_debricker/utils/u-boot-marvell
git apply /home/user/sheeva64_debricker/patches/u-boot/u-boot-mvebu64/0001-espressobin-enable-emmc.patch
cp /home/user/sheeva64_debricker/patches/u-boot/dts/armada-3720-sheeva64.dts /home/user/sheeva64_debricker/utils/u-boot-marvell/arch/arm/dts/.

cp /home/user/sheeva64_debricker/utils/atf-marvell/build/a3700/debug/bl31.bin /home/user/sheeva64_debricker/utils/u-boot-marvell/.
cd /home/user/sheeva64_debricker/utils/u-boot-marvell

make mvebu_espressobin-88f3720_defconfig CROSS_COMPILE=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
make DEVICE_TREE=armada-3720-sheeva64 LOCALVERSION=-ambian CROSS_COMPILE=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-

if compiler error because gcc is too old, edit the below file
vi /home/user/sheeva64_debricker/utils/u-boot-marvell/arch/arm/
change line 70, the version change “0600” to “0500” to bypass the gcc version check, then try again, messy, but works

make DEVICE_TREE=armada-3720-sheeva64 LOCALVERSION=-ambian CROSS_COMPILE=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-

cd /home/user/sheeva64_debricker/utils/atf-marvell
make MV_DDR_PATH=/home/user/sheeva64_debricker/utils/mv-ddr-marvell CROSS_COMPILE=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=5 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip BL33=/home/user/sheeva64_debricker/utils/u-boot-marvell/u-boot.bin WTP=/home/user/sheeva64_debricker/utils/A3700-utils-marvell CROSS_CM3=/home/user/sheeva64_debricker/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-

All the above commands hopefully finished without error…
The U-Boot that is built using this method is actually ment for the EspressoBIN, which is based off the same Marvell A3700 Armanda SoC, but with different peripherals, therefore it is not 100% stable on the Sheeva64, but stable enough to reload the factory U-Boot image, which is all we really need it for.

Now you have built all the necessary files to boot the Sheeva64 from a bricked (very very bricked) state.
The loading command will change a little since we need to reference the files that are all spread out that we just made.
I have found this easiest to do the following way…

We still use our original commands in terminal 1 to set the wtp mode.
sudo python3 -m –raw –eol CR –encoding ascii /dev/ttyUSB0 115200

In terminal we will modify some stuff, change to the following folder, then execute the load command.

cd /home/user/sheeva64_debricker/utils/atf-marvell/build/a3700/debug/uart-images
sudo /home/user/sheeva64_debricker/utils/A3700-utils-marvell/wtptp/linux/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E

This will start the upload process as above, and the final recovery process is the same, copy the sheeva64-bootloader-cpu-1000-ddr4-1cs-1g-atf-711ecd32-uboot-gc338309136-utils-57a8e47-20190625-REL.bin file (located in u-boot_images) to a USB memory stick, insert it into the USB2.0 port (by the ethernet port) and finish recovery with the below command.

bubt sheeva64-bootloader-cpu-1000-ddr4-1cs-1g-atf-711ecd32-uboot-gc338309136-utils-57a8e47-20190625-REL.bin spi usb

I really hope the above information is useful as I had to do most of this from scratch as this is still kind of a new device with little resources available.

GlobalScale Technologies does have some recovery inforation, which I will share, but I have not personally tested it yet.
There might be a easier recovery method, but the above method should 100% gurantee a recovery.

Finally, here are the commands to execute in the U-Boot console to reset your enviornment variables…
*** none of these commands will save until the “saveenv” or “hw_info store” command is used, so if you make a mistake, just use “reset” and try again.
*** these fix the enviornment variables
env default -a
setenv image_name boot/Image
setenv fdt_name boot/armada-3720-sheeva64.dtb
setenv bootcmd ‘mmc dev 1; ext4load mmc 1:1 $kernel_addr_r $image_name; ext4load mmc 1:1 $fdt_addr_r $fdt_name; setenv bootargs $console root=PARTUUID=89708921-01 rw rootwait net.ifnames=0 biosdevname=0; booti $kernel_addr_r – $fdt_addr_r’

*** these will fix your ethernet address, if it somehow got changed…
*** ethaddr is printed on the label on the back of the Sheeva64, but I don’t know where eth1addr comes from, I am going to have to bring this up to GlobalScale and ask them about it.
setenv pcb_rev 5.0.1
setenv ethaddr xx:xx:xx:xx:xx:xx
setenv eth1addr xx:xx:xx:xx:xx:xx
hw_info store

*** the below command will execute the boot process

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.

Inside the new GlobalScale Technologies Sheeva64

Time to take a look inside the new Sheeva64 and see what has changed from the original SheevaPlug.

There is an introduction post located at with some initial testing and thoughts on this new platform.  The manufacture’s website is located here where you can order your very own Sheeva64.

With a new toy, we all have to take it apart to see what makes it “tick” don’t we?  There is a “warranty void if seal broken” sticker holding the two halfs together, but, nothing that an exacto knife won’t fix!  Removing the four friction fit rubber feet to expose the standard Philips screws, and in a few minutes we have the two halfs apart.

This wasn’t just for the pictures, but I did some JTAG experimenting as well, and will follow up in another post about my findings with the JTAG, but story short, I can detect the Marvell Armada 3720, and connect in, but that is as far as I have gotten.  I need more detail about the low level initialization to go further.  This must be in the u-boot source code if I dig deep enough.

Now what we all have been waiting for, the internal pictures of the new Sheeva64!  This is also very similar to the GlobalScale Technologies EspressoBin single board computer (same 64-bit Arm based Marvell Armada A3720 SoC, so those who have the EspressoBin should notice some similarities.

GlobalScale Sheeva64 main PCB top
GlobalScale Sheeva64 main PCB top
GlobalScale Sheeva64 main pcb top
GlobalScale Sheeva64 main pcb top
GlobalScale Sheeva64 main PCB bottom
GlobalScale Sheeva64 main PCB bottom
GlobalScale Sheeva64 showing top and bottom just opened
GlobalScale Sheeva64 showing top and bottom just opened
GlobalScale Sheeva64 PCB inside case top
GlobalScale Sheeva64 PCB inside case top
GlobalScale Sheeva64 PCB inside case top
GlobalScale Sheeva64 PCB inside case top

We can see that the Sheeva64 has a real RTC (real time clock) to keep time when not powered, which is a very welcomed feature.  It is rare to find on single board computers these days, mostly to save cost I suppose… the Sheeva64 comes with a RTC and a battery to keep time, just like your desktop or laptop computer.

This is the non-WiFi version, we can see the pads where the WiFI and one more DDR4 chip would be placed.  This model only has 1GB of DDR4, but there is a place reserved for one more DDR4 memory chip.

The two gigabit ethernet ports are visible, along with the USB2.0 and USB3.0 ports.  There is an external SD card slot also visible and the mini-USB for the serial console and u-boot tweaking/repair.

We also have the 10-pin standard JTAG connector visible, along with the jumper to set boot mode (Armada 3270 internal ROM or external SPI).  The boot mode from the factory is of course SPI, the internal ROM mode is used to invoke the internal ROM boot loader, which can be used for recovery purposes.  However, if the SPI does not load up right, you might end up in the ROM boot loader anyway regardless of the jumper setting.

I did not remove the heat sink off the bottom of the board, but the Marvell Armada 3720 will be located under that large aluminum heat sink.  This is a fanless design, while I believe the original SheevaPlug had a fan inside it.  Will have to do some testing and load up the CUP with some Gentoo source compiling (will happen soon) and see how the temperatures are.  The heatsink and chips are interfaced with some thick white/greyish colored thermal tape the stuff, the kind of stuff often seen interfacing graphics card memory chips to heatsinks.

A very clean and compact board design, all with a dual core 64-bit processor.

GlobalScale Sheeva64 case top
GlobalScale Sheeva64 case top
GlobalScale Sheeva64 case top
GlobalScale Sheeva64 case top

The plastic case is generous in space and everything appears to have ample space to spare, but this does carry over the same case dimensions as the original SheevaPlug, the insides have been updated, however.

It is worth noting that the screw holes for the four screws holding the top and bottom halfs together appear to be a little soft, and not that deep, keep that in mind that you might not want to disassemble and reassemble too many times, the screw holes may be stripped.  The first time reassembling the screws did not seem to grip well and I may have already stripped mine out to a degree, so it is a good idea to keep that in mind for reassembling.

GlobalScale Sheeva64 case bottom with power supply
GlobalScale Sheeva64 case bottom with power supply
GlobalScale Sheeva64 case bottom with power supply
GlobalScale Sheeva64 case bottom with power supply

The power supply is very compact, but appears to be able to supply 900mA to the USB ports… not specific if that is total current between both ports, or the current for each port. There is a small cushion pushing up against the PCB, I believe to hold the power supply in place and avoid rattles.  The original SheevaPlug did have some occasional issues (a small failure rate) with failed power supplies, the part for the original SheevaPlug is available at this URL,, but not 100% sure it is a suitable replacement for the Sheeva64.  I am hoping that improvements were made on the power supply to reduce the failure rate.

Besides the slight concerns about the power supply, for the $89 USD (non WiFi/Bluetooth) or $105 USB (WiFi/Bluetooth included) including internal power supply, it is not a bad price for a dual core 64-bit single board (all self contained) computer that can literally just be plugged in anywhere.

I will be digging into the u-boot and recovery methods in another post soon.  If, by chance, anyone has a bricked (u-boot is corrupted or gone) device before then, leave a comment below and I will see if I can provide you with what you need to recover the SPI flash on your Sheeva64.

Sheeva64 single board computer by GlobalScale Technologies first thoughts

I recently put in an order for the new Sheeva64 from GlobalScale last Monday, and received it on Friday.  After using the SheevaPlug and DreamPlug by the same company I thought I would give this one a try.  I believe the Sheeva64 was announced in February 2019 and began shipping April 2019.

Below are some detailed pictures of the exterior, I will be reviewing the interior in another post, but without further due, here is the new Sheeva64.  It is very similar to the original SheevaPlug in design, and I will warn, the plastic where the screws are threaded in, if you take it apart (and cut your “void if opened” sticker) you won’t want to be opening it too often, the screws might strip out.

Anyway the screws are located under the four rubber feet on the bottom, you will be breaking the warranty sticker, by the way, but a “warrenty void if broken “sticker has never stopped us hardware people anyway… has it?

Clicking on the pictures should open the full resolution version.

GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 exterior
GlobalScale Sheeva64 power plug, external cord connection showing
GlobalScale Sheeva64 power plug, external cord connection showing
GlobalScale Sheeva64 exterior with plug attached
GlobalScale Sheeva64 exterior with plug attached
GlobalScale Sheeva64 power plug with plug half attached
GlobalScale Sheeva64 power plug with plug half attached

First off I have been mostly successful with the Linux Gentoo install, and I am sure other flavors of Linux will work as well.  The Sheeva64 plug computer ships with Ubuntu 18.04 pre-loaded.

While the SheevaPlug and DreamPlug are based on a 32-bit Arm core, the new Sheeva64 is based on a Arm 64-bit core, specifically a Marvell Armada 3720 SoC with 1GB of DDR4.  The specs show the Sheeva64 can be configured with 2GB of DDR4, but only the 1GB DDR4 model is being produced now.  Looking at the specs on this new chip it has two cores, and runs up to 1.2 Ghz, according to the web site at Globalscale Technologies in the link below.  There are non-WiFi and WiFi models available.  I mistakenly ordered the non-WiFi model so I will be making another order soon.  The WiFi model looks impressive coming with Bluetooth as well.

Very impressive is the dual gigabit ethernet, directly connected to the CPU, not though USB, along with the USB3.0 port, which would make this ideal as a router or NAS server.  Globalscale Technologies also has a product very similar to the Sheeva64, which was released quite a bit ago, the EspressoBin with specs located here.

The SoC is the exact same as used in the Sheeva64, however, the memory and other board configurations are slightly different.  However, the EspressoBin should not be overlooked as a router or NAS server as well, the EspressoBin also has an SATA connection on the board and can achieve some fast transfer speeds, from what I have read.  I do not have one of these, but I am really thinking of ordering some of the configurations sold and test them out, but this will be a topic for another discussion.

As with the SheevaPlug and DreamPlug, I installed Linux Gentoo on it, but, have not over-written the internal eMMC (internal SD).  I have just edited the boot configuration in u-boot to boot off the external disk.

While I was successful in the Linux Gentoo install, I have not yet been able to build a working kernel (edit, kernel build has been successful, please see this post).  I am now using the original kernel on the eMMC card and just changed the root to use the external USB hard disk as the rootfs.

There are several reasons for this, when doing a Gentoo install, it is built from source, and you really don’t want to be hammering a SD card, or eMMC memory with compiling, so an external rotating hard disk, that does not have a practical limit on writes, is more ideal for this task.  Once the Linux Gentoo installation is finalized it will be stunk down and placed on the internal eMMC or an SD card.

Concerning booting off external USB devices… I am still confirming but I have had problems getting u-boot to wait long enough for the external hard disk to spin up before detection.  It is just a little too fast and won’t wait just a few more seconds for the USB hard disk to spin up before deciding nothing is connected.  I am hoping to rebuild the u-boot boot loader and add in a delay.

So far I am impressed with the Sheeva64, its small form factor, and ability to just be plugged in anywhere, all self contained.

There is very little documentation out on these new Marvell Armada A3720 chips, and recovery information was very hard to locate, but I will be putting together a full set of instructions and downloads in another post soon.  This will include some details of how the u-boot process works.  The best (or worst) part about the single board computers from GlobalScale Technologies is that u-boot resides in some kind of flash memory (SPI in the case of the Sheeva64).  This is good in regards that you have full access to rewrite any part of the boot loader and fix bugs… the bad news… you can brick (read semi brick) the device if you erase the boot loader residing in the SPI flash.

It took 3 days of hard work, but I have come up with a method to recover (read unbrick) the Sheeva64 from any state assuming no physical damage.  This includes being able to recover from a corrupted u-boot and rewrite the internal SPI memory without opening or desoldering any chips.  I will be making a separate fully detailed post with the full process of how to do this, but, it is very similar to how the EspressoBin is recovered (the CPU, SoC is the same Marvell Armada A3720).

Edit, finally got the recovery process documented and posted at if you run into any issues please leave a comment and I will try to fix the documentation.

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.