1.1 Why Linux ?2 Linux as real time operating system (RTOS)
1.2 Minimal configuration ?
2.1 RT-Linux3 Linux & flash Cards, flash eproms
3.1 Pcmcia flash cardsReferences
3.2 DiskOnChip
3.3 Flash Limited write cycles3.3.1 solutions
authors: Zivkov Ivo, Ingo Cyliax
authors: Bernard Nahas
links to Linux & Real Time may be found there.
Pcmcia flash cards are seen as standard hard disk, while using the pcmcia package.
M-Systems provides DiskOnChip, this is a flash eprom pluggable on most single board computer or PC/104. There is drivers for most DiskOnChips products ( 2000, Millenium ). Drivers are a binary patch, no source available, over 2.03x kernels. Please contact Esther Spanjer <> for last info on m-sys & linux products.
Memory Technology Device (MTD) Subsystem for Linux David Woodhouse is working on a generic Linux subsystem for memory devices, especially Flash devices. The aim of the system is to make it simple to provide a driver for new hardware, by providing a generic interface between the hardware drivers and the upper layers of the system a gpl driver now works with DiskOnChip
authors: Spanjer Esther
Flash have limited write cycles capabilities from 200 000 to 400 000. Using swap on such device is dangerous. 300 000 writes gives you 200 days at 1 write / minute and 83 hours at 1 write / second. More, If you interrupt power at arbitrary times while the device is writing,
you can lose the integrity of the file system being modified. The loss is not limited to the 512 byte sector being modified, as it generally
is with rotating disks; you can lose an entire erase block, maybe 64K at once. The risk goes up as the "disk" approaches full, because erase rewrite cycles happen more often in this condition. Un*x file systems spread their super block tables around the "disk", in the hope that at least one will survive a head crash. Create one file, then /bin/sync: what percentage of the device's erase blocks get hit?
* Two partitions
Nicolas uses a Sandisk 4 MB flash disk to hold the whole system in a read-only partition and a read write partition is used to save some data. The partition are set to be on flash block boundaries so if a crash occurs, only the second partition must be rebuild. And there might be no need to install a file system on the writable partition so the application may check for some magic number and reset the structure in this partition by itself if needed. The trick is to access /dev/hda2 as any regular file for example. Now to be safe from power crash, we have made the power state be controlled by software. So if the user turns off the power switch (which is only wired to one of the parallel port pins), the application then takes the time needed to write its data to the flash, to sync the buffers and only then drop the power by dropping a line again on the parallel port. Since his device is made to be used on batteries, the AC power can be unplugged and everything still goes on. Of course, another line on the parallel port is used to monitor the batteries's charge and force a power down if the charge goes too low. So the flash is written only during the shutdown procedure which limits write cycles and there is very very little possibility it can crash due to power failure.
* Loading contents of system into a ram disk
Paul Moody's mini-HOWTO gives one approach to using a Flash memory drive with Linux, by loading the contents into a ram disk at boot time. One of the good point is that RAM is cheaper than Flash.
* Mounting root file system read-only
If you're stuck with less RAM than Flash, or if you're using a real hard drive, you may mount the root file system from the drive read-only. This retains many of the benefits of resisting corruption of the drive and avoiding write cycles (which would quickly wear out a flash drive), because no data is ever written to the root file system. Even with a real hard drive, the root file system is not corrupted (and fsck is not run on reboot) if the power is cycled. Of course, it's complicated by the fact that Linux usually wants/needs to write data to its root file system. This problem can be solved principally by modifying /etc/rc.sysinit to create and mount a ramdisk on the read-only root file system, instead of remounting the root file system in read write mode. This technique takes advantage of the fact that a read write device can be mounted on the file system of a read-only device, to create a read write directory subtree within an otherwise read-only hierarchy. Note that mounting a new device merely stores an entry in a kernel table and does not write to the device holding the file system upon which the new device is being mounted. Here's a sketch of the places on the root file system
where Linux traditionally wants to write, and how to cope with them:
- /var Most dynamic stuff happens here, so this is where I mount the ramdisk. The mods to /etc/rc.sysinit include creating (or copying) the usual directory structure under /var onto the ram disk before remounting it here.
- /tmp Usually publicly writable, and "sticky". Make /tmp a symlink to a new directory /var/tmp, on the ramdisk mounted on /var. Alternatively, mount another ramdisk on /tmp.
- /dev Suprising at first, but login/getty programs change the ownership of /dev/tty* files when users log in, so some /dev files need to be on a writable filesystem. Again, make /dev a symlink to /var/dev, and "cp -a" or mknod all the devices required into the ramdisk.
- /etc/mtab, /etc/HOSTNAME These get written at various points. Each file is made a symlink to. /var/etc/..., so they can be written.
- /etc/issue Some distributions like to rewrite this in the /etc/rc.d scripts. Just nuke the part of the scripts which do that.
authors: Paul Moody, Carry O'Brien, Nicolas Pitres, Graham Stoney, Steven Work.