Here are some scenarios for ways that I want to use Debian on semi-embedded and embedded devices. So far there's not a good way to accomplish most of these, and each scenario needs at best a different approach, from flashybrid to Embdebian to ADS root builder to hand hacked images.

That will change, I hope, if the grand unified scheme I'm plotting comes to fruition. If some of these scenarios interest you, please check out the design at http://wiki.debian.org/RootSync.

openmoko

First, install Debian to a 2 gb microSD card in the phone, using d-i. Bog-standard Debian install (except for it being g-i running on a cell phone!), standard partitioning.

Boot the install and use it for a while. Install more stuff and tweak the system. Now you want to remove that microSD card, to save power. So, unmount it, and remove it. Debian continues running; all the files you normally use, including everything needed to boot the system, have already been copied over to the flash.

If the flash gets too full, just delete any files you don't need right now. If you later find you're missing a file, just plug the microSD back in, mount it, and you can access the file again. This is also an easy way to do a backups, a simple command can sync your changes up to the microSD card.

Also the microSD card can be plugged into a different openmoko phone, chrooted into, a command run, the phone rebooted, and it's been taken over, now running the same Debian install. Great party trick. ;-)

slug with a 32 mb USB stick

This is my sister's nslu2 box, that only does one thing, really: Dial up to the internet and route packets to the access point. It's also nice to get Debian security updates from time to time. And I don't want to have a noisy hard drive on it, so it runs from a small USB stick.

The initial install is done to USB drive, then I add the USB stick to the picture, boot the nslu2 up, configure ppp, run it, and I can remove the drive, it's ready to run in embedded mode from the USB stick.

Later I need to apply a security update, so I plug in the USB drive, mount it, run aptitude, and I'm done, just unmount the USB drive again, and the USB stick now has updated versions of the necessary files.

true embedded system development

A company is creating a real embedded arm system, it needs to run from 64 mb of flash, with a fair chunk for their own application, and a fair chunk free for user data. An engineer is using his development system to work on creating the jffs2 filesystem that will go on the production hardware. He starts by untarring the Debian armel port to a drive, and copies in the custom application.

Then he sets up an empty jffs2 filesystem on mtdblockN. After rebooting the system, the jffs2 contains the files needed to boot Debian on its own. The engineer runs the custom application, and the jffs2 is now ready to run that too.

But it's getting a bit tight for space on the jffs2. Time for busybox. He runs "busybox install [long list of busybox commands]", replacing lots of core commands with their smaller busybox versions. After a few reboots, all the init scripts are hacked up to work with the busybox stuff. (Argh.. Debian should work with it by default. Anyone want patches?) Maybe he goes on to run mklibs or do something with uclibc.

This might take a few iterations to get right, but he doesn't worry about screwing up the system -- he knows that at any point he can delete all the files on the jffs2, reboot, and be back to his unmodified system on the disk drive.

Once everything is ready, he can load the jffs2 onto production hardware and the new embedded system is ready to be tested and qualified.

slug thick client

My nslu2 box, used for handling some USB devices like my UPS, security camera, etc. When the network is up, and the storage server is up, it can nfs mount root, but that doesn't work when the power goes out and the server needs to come down. I want it to keep working in that case, as a kind of detached thick client. After hacking nfs root support into d-i at some future point :-) I have it booting with nfs root already.

There's around 3 mb of unused flash on the slug, so I set up a jffs2 partition using that, and through some trial and error get the right files on there to let the system keep running in a degraded mode when the nfs mount goes down. 3 mb does fill up pretty quickly if the camera notices motion, but it's good enough, so I decide not to put a USB stick on the box.