“Is there people dressed up in costumes in the TV”, my brilliant little one asked me. I briefly considered saying “Yes”, but opted for responsible instead (just this once); didn’t want her to get freaked out about little people trapped in there or anything :)

Later she asked my wife “can I go into the TV?”; again, my wife thought about saying ‘yes’, then realized .. our kid _would find a way in_, so best not to encourage that :)

Posting this to my favourite forum over at gp32x:

Word to the wise –

I don’t know how the TS (touchscreen) on the Pandora display is made/etc/so/on, but for PDAs I’ve done an infinite amount of development over the last 15 years. The way you wreck the TS on a PDA touchscreen is this — _removing_ a screen protector. Putting them on is an art (keep a credit card handy for pushing out bubbles if its a soft film kind), but the trick is removing them — especially if its been on for awhile. (Most protectors suggest removal and cleaning every month or two, because they want you to buy more; but in practice unless you hammer the hell out of them, you can leave them on for months or years. But when you take them off, the things are pretty suckered on there — if you pull them at a 90 degree peel, then you’re essentially pulling directly up on the TS and separating it from the underlieing screen. And what that means is you’re creating a very good opportunity to cause displacement in where the touch is registering, relative to where you’re actually touching it.

And guess what — when you’re applying your screenprot and you get it not quite right, you’ll want to peal it off and retry right?

Be gentle — last thing you want to do with your screenprot is bugger up your TS day one :)

I don’t have time right now for a full and proper right up, but hopefully these tips will get you going or experimenting.

Aside; I think DJWillis has a script that will pull the firmware out of NAND and deposit it on an SD card ready to go (more or less), so that will probably come to light soon. For now, suffer with my quike write-up!

The full ‘raw’ boot process goes through a number of steps (ie: The OMAP itself knows how to read a bit from a FAT filesystem on SD, and bull up a file called MLO to be first stage of the boot process, which in turn can pull up stage 2, etc.) I’m not going to go into that here, but our good man DJWillis posted in some detail here at Distant Earth

Fortunately, most people will have a flashed unit, where the boot files (such as MLO/etc) are in NAND and good to use. This makes the whole process a lot easier and less fiddly – we can piggy back on these guys, and our dear friend notaz has added some grand features to make booting from SD while using these bootfiles a piece of cake. Namely – you can set up a file called ‘autoboot.txt’ to tell the system what to do with a firmware on SD when the user doesn’t do anything special, and you can set up a file called ‘boot.txt’ to instruct the loader what to do when the user explicitly asks for an SD boot.

I’m writing this off the cuff; normally for development we booted the full bootfiles from SD, and after doing that several thousand times I can tell you how to do that in my sleep (maybe I should, for completeness, in another article.) Due to being over-busy the last couple weeks I’ve not had time to fiddle with this approach yet, so please let me know if the sun crashes into the Earth.

The basic process should be something like this…

Prepare the SD card

Nowadays, this is a much simpler thing than it was earlier during Pandora’s development lifecycle.

Format the SD as one big ext2 partition.

For Linux, it should be a piece of cake; for Windows/OSX you may well need an ext2fs driver, etc, but of course I heartily recommend either dual botting with Linux (or FreeBSD!), or setting up a VM (such as VMWare, VirtualBox, etc) to do your development and SD hacking in.

(You can also use ext3 as far as I know, but in my experience ext3 seems more prone to meltdown when cutting the power without a sync, and also took much longer to perform sync after large volume of data writes. Hence, ext2fs was my choice most of the time; note also that ext2fs does not like to be cut off before a sync, so when booting from SD .. be sure to always shutdown normally, otherwise you risk SD corruption leading to a fresh format; not really a problem since you’ll likely keep all your user data on SD2, but still.)

A few minutes ago, I wrote up the following; it doesn’t have to be like this anymore, so its much easier to just skip to the next section now ;)

Out of date:

In short; you’ll want to partition the SD into two (or more of course) partitions — the first one being small and formatted to FAT, and then the main body being a larger one, formatted (ideally) to ext2fs.

EDIT: Actually, it turns out boot.txt can be read from ext2fs, so we do not need the FAT partition at all; just format the whole SD as ext2fs ine one big partition, drop boot.txt on it, and good to go.

Order is important — first should be FAT, the second should be ext2fs. (Historically, we’ve used a small first partition since OMAP seems to not like giant multi-GB partitions, but thats probably a non-issue for our purposes here.)

The long version:

Edit: Make one big partition, and format it to ext2fs; previously I noted the two partition approach:

To partition and format the SD under Linux, this page seems a pretty good how-to: Linux Beagleboard Guide

For Windows, I imagine using the built in Disk Manager tools would be sufficient; sometimes you need to hit the SD with a good solid format, often using Panasonic formatter or the HP formatter, etc; they do a good thorough job. Try this guy, for instance: HP Formatter (requires USB SD widget, often will not recognize built in SD slots on a laptop)

Set up boot.txt

The NAND bootfiles take care of most of our heavy lifting; we do not need to set up MLO, u-boot or other handy bits. (Thanks notaz!)

We do need a boot script to instruct how to load the system. I’ve not had time to try this file out, so please let me know how it goes; this should boot the kernel from NAND (flash), and then start up the firmware from the second partition on the first SD (in your ext2fs partition.)

Using your favourite TEXT EDITOR (vi, emacs, windows Notepad, etc .. but not MS Word, etc) create “boot.txt” on your SD, in the FAT partition. As always, thanks to notaz:

setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 vram=6272K omapfb.vram=0:3000K
ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr}

The firmware

You could probably just copy much of the firmware right off your NAND onto your second partition of your SD, using the Terminal or even Thunar directory browser. ie: cp / /media/mmcblk0p1 and good to go :)

An _OUT OF DATE_ firmware file in tarball format can be found here: Codejedi site

Untar this into your ext2fs partition, and you should be good to go.

(One untarred, you could further edit it to change /etc, add more packages, modify its boot, etc. Do that later if you want, a firmware on SD is pretty handy; pop it into your parent Linux box and hack away!)

Fire it up

When powering up the Pandora, hold right-trigger down to get presented with a boot menu; here you can select an alternate boot option (other than NAND, say), or power the unit off again. Pick “SD1:1″ and hit “B” to start the boot process, and it should read your boot.txt and fire up the firmware, without touching your NAND (beyond the bootfiles/kernel.)

Let me know how it goes, I’m jugglgin 35 things right now, so can’t keep on top of everything :)

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!