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 :)