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.
Afterwards, I will rest.
