This is the 2nd of the 2 simple guides I have put together to help you through the process of getting a working development environment and basic SDK going for the OpenPandora allowing you to build applications, compile up code, all of that neat stuff really.
Note: These guides and toolchain/SDK packages do not constitute an ‘official’ OpenPandora SDK or anything of the sort, they are just what I have put together during the development process in the hope somebody may find it useful.
There will be things missing libs and odd littke things that did not end up in the SDK package etc. at first and this article and the toolchains will evolve as time goes on.
Consider this 2nd part of the guide a work in progress.
With the OpenPandora you have 2 primary options for code development…
Want to write code for the OpenPandora on the OpenPandora, have a little read of this. Not the way I would recommend doing normal development but handy sometimes.
The is covered in part 1 of this article.
- Cross compiling
The most common method of code development for a device such as the OpenPandora. Requires access to a regular PC to using for building code.
The is covered by this part of the article.
I’ll aim to outline how you can start to develop code using either setup, and provide a really simple test app to prove your setup is working.
This is mainly aimed at C, C++ and Assembler developers who are familiar with GCC, build tools and Linux in general.
Cross compiling is by far and away the most common way of building code for small/embedded systems (the term is relative) like the OpenPandora.
Cross compiling allows you to make use of the capacities of a much bigger systems to compile code that will then run on the target device.
It also frees you from limits imposed by building on the device directly such as running out of memory or storage (both of these are used en-mass by larger application compiles).
Note: The entire OpenPandora OS is built using OpenEmbedded and OpenEmbedded cross compiles everything (in my case on 32bit and 64bit Linux boxs). None of the OS code is actually natively compiled on the device its self.
What’s included in the toolchain and SDK?
The toolchain included in the package below is the same toolchain used to build the OpenPandora OS images (all the toolchain scripts do is package it up neatly).
The initial SDK contains the toolchain and development libraries for most (it should really be all) of the libraries that are installed on the OpenPandora OS including the libraries/headers for the PowerVR SGX core’s OpenGL features.
This is something I am trying to make more slick so if you notice missing libraries or bugs please do let me know.
Setting up the environment:
The 1st thing to consider here is that I am only providing toolchains for recent 32bit and 64bit Linux distributions (with gLibC 2.11 >).
There are options for Windows users if you want to use a cross compiler targeting ARMv7 such as CodeSourcery providing you know how to add the libraries you need, but it’s not something I plan to cover in this article.
That said, these toolchains are perfectly happy inside a Linux virtual machine so assuming your using something with an x86 or x64 CPU you should be able to get them going.
32bit Linux: Toolchain & SDK
64bit Linux: Toolchain & SDK (To follow, I need to get my 64bit build box back)
Installing the toolchain and initial SDK:
Download the appropriate toolchain and SDK for your platform.
You will then need to install it. You should start by untar’ing the components to the root folder (/) of your Linux setup.
Note: Adjust the command to suit the file you have actually downloaded (32 or 64bit etc.). Depending on the distribution and your security setup you may need to pop ‘sudo’ in front of the command below.
Once this operation is finished you will find a new directory /usr/local/angstrom/arm/ and it contains the environment-setup script to setup various paths to allow the toolchain to work and tools to be found by the system.
Making sure you can access the toolchain:
Depending on the distribution and your security setup you may need to give your user explicit access to the new /usr/local/angstrom/arm folder you have just created before you can run anything. I recommend doing this as there is no reason to run cross-compiles as root (or sudo’ed etc.).
The following command would give your normal user full control of the files on Ubuntu.
You can adapt to suit your security needs/setup as appropriate. Obviously replace <your-name>.<your-name> with your username (and don’t forget the dot).
Testing the toolchain:
Before using the the toolchain you will need to source the environment. Don’t forget the preceding . to make sure the variables get added to the calling shell, you will need to do this once for every terminal you want to use to compile code.
With the environment setup your almost ready to go.
For testing of the cross compiler we will use exactly the same test app we used in part 1 to test the native compiler.
It is a REALLY simple test app that uses SDL to display a bitmap image.
This will show your toolchain and basic SDL are working. It’s not fit for any purpose what so ever and I don’t suggest you actually build code this way either (use a makefile ;)).
Compile it by opening a terminal window. Running the toolchain environment script (see above). Then change into the directory you extracted the test app to and issuing the following command.
Next up you can run the app.
To do this you will need to copy DisplayImage and test.bmp onto your OpenPandora.
Then you can open a terminal, change the the folder you copied it to and run.
Note: If you connecting to the OpenPandora remotely (i.e. over SSH) to run the app you will need to run sudo ./DisplayImage or SDL won’t be able to claim the screen.
It will show an image for 10 seconds then exit.
Adding additional development libraries to the toolchain:
One of the big plus points to using a cross compiler built using OpenEmbedded is that support for adding development libraries from the Ångström repositories is baked in. The toolchain ships with a version of OPKG (Ångström’s package manager) pre-configured to look for libraries in the feed.
The main difference from using ‘opkg’ on the device is that you use ‘opkg-target’ on your build system to install libraries into the ‘target’ (i.e. OpenPandora) environment.
The 1st thing you will want to do is update the repository feed data.
Make sure you have correctly run the environment-setup script first then run…
All you then need to do is find the development library in the Ångström repositories and just install it with a simple command.
The sample below will (re)install the development libraries and headers for libSDL 1.2 into the toolchain.
Of course, you are also free to compile up any libraries or support apps you may need if they are not in the repository.
With a little luck you should now be able to develop applications for the OpenPandora using whatever method you desire.
All the usual things you would expect with a cross-compiler should work fine, including passing custom CC/CXX etc. to configure/autotools scripts to have them work everything out.
Building the toolchain yourself
If the downloads above are unsuitable for your setup (or you just have to buiold everthing yourself you can always build the toolchain and SDK from OpenEmbedded metadata).
You will shortly be able to find the OpenEmbedded recipes used to create these toolchains in the OpenPandora overlay GIT, if you already have an OpenEmbedded environment setup you will be able to bake your own version of the toolchain & SDK with a simple…
You will then be able to pickup the .tar.bz2 from the deploy/glibc/sdk folder in your build tree and install it as documented above.
This is the first release I have done of this toolchain & SDK package, I fully expect there to be some issues.
I already know there are some issues with support scripts,like the appropriate target sdl-config (incorrect paths). I am working on fixing up stuff like this but I wanted to get the toolchain out ‘as is’ and update things in a few days as people seem very keen to get there hands on it.
If you notice other issues do please let me know (or better still send patches).
Anyway, once you have struggled thougth all the waffle above you should have a working toolchain and SDK to begin development for the OpenPandora. I’ll leave it up to the reader to decide what they want to develop :).