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
