Cross Compile in the Cloud

In my previous post I explained why I want to compile my own code for the Synology DiskStation DS215j.  Being an admitted non-Linux-dev noob, I wasn't familiar with the concept of cross-compiling and I had heard of "Toolchains", but I wasn't entirely sure why you wanted or needed one.  Well, now I do.

Synology has a decent 3rd party development guide document on their website that gives a pretty basic explanation of what needs to be setup to cross compile for a DiskStation.  In case you don't know how Google search works, here is the link:
https://global.download.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf

Right off the bat, I'm going to need a 32bit Linux dev host.  Said it before and I'll say it again, I'm not a Linux guy, so I don't have a Linux box just laying around and I don't feel like goofing around with dual-booting my personal Windows desktop.  So - since I won't be using it that much, how about a cloud IaaS resource to run Linux?

Through my work I have an MSDN subscription.  (It's a great benefit!) With that subscription comes a certain annual free "allowance" of Azure services - assumed to be used for dev purposes, of course.  That sounds perfect.  Except.  ALL Azure VM instances are 64bit OS images. No 32bit support. Crap.

OK, well, we're also working with Google in my work and I have access to a couple of non-production Google for Work domain instances and I have the ability to provision a limited amount of GAE/GCE resources - free to me.  Great!  Except.  GCE has the same limitation - only 64 bit OS images.  Crap.

So, leaving the realm of "free", I come to AWS.  I have an AWS account already since I have been using Glacier for backup basically since it was initially offered (how can you go wrong for $.01 a month per GB!), but I have never worked with EC2, their IaaS offering.  I do some reading and discover that you can have 32bit OS images on EC2.  Finally!

When you walk through the EC2 instance setup process, you have to pick what Amazon calls an AMI (Amazon Machine Image).  There are currently 22 "quick start" images with various OSs. Only 2 of those choices are 32bit - and they are both Windows Server images.  (Seriously?  Why is anyone running Windows Server as a 32bit OS??)  So the next step is to search the "Community AMIs".  Wow.  So my choices went from 22 to 39,690 and counting.  Seriously - how am I supposed to know what image to pick from a list of almost 40K?

I've actually worked a little with Ubuntu before, so I'll pick Ubuntu and of course it has to be 32bit.

Great - so that narrows my choices to just over 6,100.  Now, what do I do?  I notice that most of these images names are labeled "server".  So - I add a search string for "desktop" instead.  I have no idea what difference that makes - other than I guess a server image wouldn't have a desktop interface pre-installed.  Not that I'm going to be using that, but who knows.

After that, I just pick an Ubuntu Long Term Support (LTS) release - 12.04 LTS.  Again, there are multiple images for this release, so in the end I just picked one from the list. Not until after I already had the image setup did I realize that the Ubuntu website has a page to help you pick the right AMI:
http://cloud-images.ubuntu.com/locator/ec2/  Oh, well.

I picked the smallest instance type available.  (At the time, it was t1.micro, which isn't available anymore for some reason...)  The instance gets billed at $.02/hour, with a 1-hour minimum each time it gets started up.  Not bad at all.  SSH is the default method of accessing the instance and their website does a good job of explaining how to use Putty and/or WinSCP to connect to the instance once you have turned it on.  The only part that may be slightly confusing if you've used other cloud IaaS providers is that the public DNS for your instance changes when you stop it and then restart it. So, you will need to update the WinSCP/Putty connection each time with the info from the AWS instance console.

Connect with Putty and you get the most comforting UI ever.

OK, so nobody said it would be pretty.

First step - find the Synology toolchain that matches your DiskStation.  For a DS215j running DSM 5.1 your choices are here.  I had to do some reading to figure out why I would want the softfp version of the toolchain or the hard.  I want the hard version because I am looking to take full advantage of the FPU that is part of the Armada 375 architecture.

So - I'm following the doc from Synology and aside from the fact that it hasn't been updated to include any references to the DS215j architecture, it says to extract the toolchain files to /usr/local - as an example.

OK - so

cd /usr/local

wget http://iweb.dl.sourceforge.net/project/dsgpl/DSM%205.1%20Tool%20Chains/Marvell%20Armada%20375%20Linux%203.2.40/gcc464_glibc215_hard_armada375-GPL.tgz

Right?  Nope.  You need root access to write to /usr/local

First rule of Linux, if at first you don't succeed, just try it again with "sudo".

sudo wget http://iweb.dl.sourceforge.net/project/dsgpl/DSM%205.1%20Tool%20Chains/Marvell%20Armada%20375%20Linux%203.2.40/gcc464_glibc215_hard_armada375-GPL.tgz

sudo tar zxpf gcc464_glibc215_hard_armada375-GPL.tgz -C /usr/local/

sudo rm gcc464_glibc215_hard_armada375-GPL.tgz

This downloads the file with the toolchain, unzips everything and then, for good measure, we cleanup the original file. If all is well, your /usr/local directory now looks like this:

Now we have an environment to do some dev work.  Next post, we'll see what we can get built...