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.