This is a quick write-up just to provide a tipping-off point; if you would like a more in depth article, let me know (skeezix skeleton org) and I can write up something when I get a moment; I’m hoping that a few tidbits here will just provide some ‘eureka!’ moments and folks will be be off and going :) I wrote this seat of my pants, so don’t expect it to be very well organized!

Components you need to build ‘hello world’ for your Pandora (or other non-native platform.): a toolchain, libraries, and somewhere to run the toolchain.

Where to Run:

This usually a ‘given’ — you run on your PC, the very same one you’re using to run your web browser on

If you’re a little nutty like me, theres lots of other options, but normal folks – just skip this:  You could well build on a remote shell server, or your Pandora or smartphone, or any number of options (cloud based server?) So for most people.. think — you need a toolchain for Windows to run on your Windows box (or under cygwin, say.) But what I do is run from VMs, which I copy between USB and hard drives and all over the darned place. VM – a virtual machine. I’ve built up a number of them for various specific uses, and carry them around on a flash thumb drive (pick up a 16GB or 32GB flash drive for your keychain, say. Boot time is pretty fast actually, but shutting down the VM and storing the RAM snapshot etc back to a flash drive takes a few minutes. You could copy it to the local hard drive before/after if you wanted.) You could use the VM on a machine and never move it around, or transfer it on SD cards, whatever you like to do. (ie: There are uses for all combinations .. you might never move the VMs around, but want 5 different testing or build environments, or maybe you need move them all around all the time.) As an aside, an interesting hack is to make your flash drive bootable — I can boot from my flash drive into an OS, and I can run the VM off the flash drive to get the VM. To do both, I make a small bootable OS that has VMWare Player on it (use VirtualBox or whatever you prefer), then mount the VM and go. Or just use VMWare Player on the native OS wherever you’re sitting — so on the flash thumbdrive, I usually carry the VM, VMWare Player for installing to various OSes, and a bootable OS on the thumbdrive itself :)

I bought VMWare Workstation years ago and still use it, but you can get away for free with VMWare Player (and hand edit the conf files, or use online tools to generate them.) But VirtualBox and a half dozen other products are free or vary in price, so look around. Either way though you just get a VM hypervisor, a blank disk image (I keep zipped blank drive images around in a tiny zip file; since they’re _empty_, they compress like 99%, so one tiny zip has 1GB, 5GB, 8GB, 16GNB disk images, and its a few K of zip :), and OS .iso’s — suck down a Ubuntu .iso, and you can set it up into a VM in 20 minutes.

But for most people, they will just run the toolchain in their native OS.

Toolchain:

This is the ‘confusing part’; you can either roll your own (ie: build a cross compiler from sources, which takes an hour), or you can pull down someone elses prebuilt toolchain.

For purposes of the 5 minute setup, just grab CodeSourcery’s prebuilt gcc for the command line:

http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057

When using a prebuilt toolchain, just pick a directory and unpack it. Add it to your path, and you’re done.

ie: Create /code/toolchain and extract it all there, then add /code/toolchain/bin to your $PATH. Now you’ve got arm-none-linux-gcc (for example.) In CSL’s case, it comes with some basic core libs (like glibc) etc, so you can spit out Hello World there.

Consider: Extract, set path, build hello world — thats what, 1 minute of work, after the download?

Libraries:

For any remotely useful application, you need to link against libraries. And I dunno about you, I really don’t want to compile 200 libraries to get going, but you could do that. What I do, is use a copy of the Pandora firmware and pull all the libraries out of that.

We didn’t modify any headers, so you can compile against whatever Linux headers you already have (/usr/include); if you’re on Linux and don’t have them, you can ask your package manager to fetch them for you. If you’re on Windows, well, suck them out of a Linux distro’s .iso :)

As I code in a Linux VM (on a linux box, or a Mac, or Windows, or whatever), the Linux VM has my native and cross compiler toolchains and all the headers.

An OUT OF DATE copy of the Pandora first firmware is here:

http://www.codejedi.com/pandora/libpnd/pandora-xfce-image-omap3-pandora-20101705-image-for-checking-fixes.tar.bz2

Look in /usr/lib there, and you see a pile of libs you can use for linking.

Remember, those are already on real Pandora’s, so you don’t need to include them in your app or pnd-file. They’re _just for linking_, and then when you build hello.bin for running, thats the only file you need to copy around.

NOTE: Your toolchain’s linker naming policy might be different, so libfoo.so.1.2.3 in /usr/lib of the firmware might not get found when you -L to it; I created a short sh-script to ln -s to common names.. so libfoo.so.1.2.3 also gets a symlink of libfoo.so.1 and libfoo.so, so that it’ll be found by my cross compilers ld.

Tieing it all together:

1) Preparation; -> well, setting up a VM might take you 20mins, but I don’t count that in the timer; I already had one :)

i) Set up your VM, or whatever OS you want to run your toolchain in. ie: Install an OS. Make it have Linux headers, which is probably just default for many Linux distros, or maybe you need to add the basic developer package. (For random libs, you’ll want to pull down other packages too.. for SDL, your Linux distro will have the native libSDL, but not the SDL headers; so you might well need to apt-get sdl-1.3-dev (or whatever) to get the headers. We really should supply a list of packages to get, so that you have all the headers in your native linux that the Pandora would have libs for. But I digress, and its not hard to piecemeal them over time.)

ii) Build, or suck down a prebuilt, toolchain -> depends on your bandwidth speed of course :)

2) Set it up

i) Set the toolchain up in some well defined path; Try something like /devo/toolchains/arm/codesourcery/2009-q3/ (say), so that you have …../2009-q3/bin with the tools in it. It will use relative paths, so can find oits own libs and bits it needs. -> if using CodeSourcey (say), we’re saying: untar or unzip the files, and that takes .. 2 minutes.

ii) Set your PATH; something like “set PATH=${PATH}:/devo/toolchains/arm/codesourcery/2009-q3/bin”; then when you type arm-none-linux-gcc and hit return, it’ll say “no input files” instead of “file not found”, and that means you’re good to go. -> 30 seconds

iii) Extract the Pandora firmware to /devo/pandora/firmware/prerelease (say), so that …../prerelease/usr/lib has all the lib*so* files in it. -> 2 minutes

— thats it, 5 minutes of setup :)

3) Use it

i) When compiling., specify -I/usr/include – many prebuilt crosscompilers will drop native paths (rightly so), thinking you’ll tell them somewhere else to go; but I just use the native headers anyway, so -I/usr/include works fine

ii) Specify a lib path; something like -L/devo/pandora/firmware/prerelease/usr/lib (or whatever) will make most things happy; sometimes you’ll need to specify a hint to ld so that when it pulls in one lib, and that lib depends on another, it’ll still find the subsequent ones; its all pretty easy stuff.

iii) Set your CC/etc in the Makefile, since you want to use arm-none-linux-g++ instead of “g++” (the native one.)

Piece of cake!

I know, I’m glossing over quite a lot here, but feel free to ask!