[gentoo-embedded] Gentoo on a Arietta G25

Hi,

recently I bought a great little Linux board: Arietta G25
(http://www.acmesystems.it/arietta)

Since I like Gentoo I installed it instead of the provided Debian
system.  The system I used to compile the kernel is -- of course -- a
Gentoo -- Linux PC.

****************************************************************** NO
WARNING: THE BOARD CAN *NOT* BE BRICKED. THE WORST CASE WHICH COULD
HAPPEN IS THE NEED TO EDIT THE SDCARD WITH A DIFFERENT SYSTEM.  YOU
HAVE NOT BE WARNED! I WILL NOT TAKE ANY RESPONSIBILITY FOR ANY LUCK
WHICH MAY HAPPEN TO YOU! ITS YOUR SUCCESS - NOT MINE!
****************************************************************** ;)

These were the ingredients: Crosscompiler toolchain take from here
(scroll a little down)
https://eewiki.net/display/linuxonarm/AT91SAM9x5 Since Robert Nelson
(the author of the pages above as far as I know and the maintainer of
all Beaglebone systems) told me, it would be better to take a vanilla
Linux 3.18.rc7 right from Linus desktop (so to speak) I got that from:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

With the kernel 3.17.x kernel I got strange clock (RTC) drift problems
far beyond the normal drifts (several minutes/hours) and I couldn't
poweroff the system - it always reboots.

This does not happen with the Debian system and Linux 3.16.1. though.

Free Electrons put a lot of work into the mainline kernel (3.18...)
for AT91 systems, which the Arietta is one of. 

With that kernel, now reboot doesn't work instead - it always poweroff
(a "better" ...hrmmm... feature for a battery powered system though)

The clock drift problem went away -- if the original configuration by
Acmesystems is used. I changed some things and it is there again.  I
am on the way to track that down to a certain configuration item...but
this will take some time...even with a drifting clock at hand.

The original configuration was taken from Acmesystems site:
http://www.acmesystems.it/www/binary_repository/Arietta-30nov2014/acme-arietta_defconfig

The Devicetree dts-file was taken from here:
http://www.acmesystems.it/www/binary_repository/Arietta-30nov2014/acme-arietta.dts

The bootloader was build as described here:
http://www.acmesystems.it/compile_at91bootstrap (Newest sources are
here: https://github.com/tanzilli/at91bootstrap)

The original AT91Bootstrap loader by ATMEL seems not to work for this
board.

Finally the Gentoo stage3 rootfs was taken from here:
http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3-armv5tel/
(or a more recent incarnation of it)

HowTo:

1) Create a SD-Card with two partitions: 50MB (or less for people who
   dont want to experiment with different kernel
   versions/configurations) with an FAT16 filesystem.  The rest of the
   space of the SDcard is used for a second partition with an ext4
   filesystem.

2) Install the crosscompiler toolchain on your Gentoo box.

3) git clone the kernel (about 2Gigs of stuff!)

4) While git is pulling the kernel sources compile the bootloader and
   put it on the first partition as decribed by Acmesystems.

5) If you dont want to fiddle around with the dtc you can click
   together the pin configuration for your Arietta here:
   http://www.acmesystems.it/pinout_arietta and download the compiled
   dtb file then.

6) Put the dtb file onto the first partition too.

7) Now: Kernel Backery time! :) Compile the kernel as described here:
   http://www.acmesystems.it/compile_linux_3_16 but use the kernel
   sources of Linux 3.18.rc7 (or later).  Put the kernel image (called
   zImage) onto the first partition.
   Dont forget to copy the modules onto the rootfs, if step8) is done!

8) Uncompress the stage3 archive onto the second partition. Do this as
   root and mount the SDcard as root also.  Do the usual Gentoo
   configuration steps as described in the Gentoo handbook. The
   Arietta Board does Ethernet over USB so you need appropiate drivers
   for your PC also. For me, these does the trick: usbnet cdc_subset
   cdc_eem cdc_ether udc_core libcomposite usb_f_rndis u_ether. These
   may or may not too much modules...but with these it works...;)

   I am currently using static IP-adresses for my Arietta. Up to this
   moment I haven't figured out how to use dhcp/d properly or this board.
   If you will do...please post your solution.  For the moment I
   suggest to configure static IP-adresses too.


9) sync and unmount the SDcard.

10) Put the SDcard into your Arietta Board and boot it.

11) ssh into your board.

12) TADA!

The Arietta is powered by an AT91SAM9G25 CPU. This is neither a 3.6GHz
horse nor a 6 core starship but a 400MHz single core processor --
which is more than enough for a board of this kind.

That means: The upcoming time of populating the board with all
needed/wanted application not being part of the stage3 archive will be
an exercise of patience.

On the other hand: This great little board uses only one and a half
spark of electric energy. And: It really doesnt matter whether the
board does its compile task over three hours at night or seven hours.
The result is the same in both cases: Next morning its ready!  In this
context 'emerge <ebuild> -f' becomes handy! No need to run the DSL
modem/WLAN router or whatever over night!

Why not to use a separate partition as swap device?

The amount of writes to a SD card are limited.  I am not sure, whether
writes to a spearate swap partition will be handled by the SD card
logic (anti-wear out algorthm) the same way as it is true for writes
to files.  But I know, that this algorithm is working for files.  And:
Swapping on a SDcard is always the slowest of all worst cases of
swapping which may occur in general. So I put a swapfile on the root
partition and used that as a last resort swap device (the Arietta is
available with 128 MB and 256 MB RAM. For Gentoo -- since it is self
compiling - I suggest the 256 MB version.)

Why not crosscompiling the applications on your PC?  I tried
crosscompiling applications on my PC for my Beaglebone Black embedded
systems and failed in different ways: I tried distcc and plain cross
compiling.
Often it works but it fails too often to be used.
In most cases the application sources were not written for being
"compatible" to crosscompiling. Once in a sudden the cross compiler
was instructed by the sources to take the headers of the underlying
64bit AMD PC instead of the 32bit ARM system. Or: For compiling
the sources you need a second tool/preprozessor like 'moc'
for QTx applications. This confuses the process on a regular basis.
I quit that. I want to compile and not but hunt bugs.
Compiling on the Arietta is not the fastest thing which may happen on
planet earth and breaking the light barrier is something totally
different....but compiling on the Arietta works. And it works (at
least for me) far better than crosscompiling.

Crosscompiling the kernel is a different thing, because the kernel 
is "selfcontained" it does not (and is not allowed to) use any sources
from outside its own source tree. So crosscompiling the kernel is a
harmless task.

I am no native english speaker. Therefore I put all typos and wrong
uses of the English language under the GPL. Herewith you are allowed
to make copies of these typos and errors and make your own version of
them or even improve them.
The author take no responsibility for any harm or happiness with may
or may not result directly or indirectly from reading and using 
these instructions.
Have fun!

I am always interested in suggestions, corrections or anything else
regarding this topic.

HTH!
Best regards,
Meino