Running Linux from DiskOnModule?

Hi,

I have a PC/104 board that I'm working to get Linux running on. Are there any special considerations for installing onto a DiskOnModule or any other type of flash? From Linux's point of view it looks just like an IDE drive. Is it necessary to run Linux out of a ram disk? Or are access times fast enough that I can run directly from the DiskOnModule?

Thanks! Mark

Reply to
Mark
Loading thread data ...

(DiskOnModule is basically a CompactFlash with a different form factor.)

There are two things to consider when running a Linux System off a DOM or a CF:

  1. Wear

These devices use flash memory as their storage media. You can write to each block of flash memory only so many times (typically in the range of ten thousand to hundred thousand times). They do presumably implement some kind ow wear levelling internally (transparently distribute write accesses evenly over all available flash blocks) which improves things, but nevertheless, if the Linux system keeps writing data to files, such a device can be worn out in a matter of weeks. To deal with this, the system should avoid write accesses where possible (best is to mount it read only, if not possible, at least use the "-noatime" mount option).

  1. Sudden power loss

These devices are made to replace IDE disks, so they have apparently copied some of the problems of rotating had disk as well: It appears that, if power is lost while a write access was in progress, such a device can be seriously damaged. This has never been officialy acknowledged nor denied by any manufacturer as far as I am aware, but I have read numerous reports from credible people who have seen it happen. Some said that the device was damaged completely in the process, others said they were able to bring it back to life by doing a low-level format. In any case, all data on the device was lost.

In summary: If a sudden loss of power is an even remote possiblity for your application, the only way to safely use a DOM or CF is to keep it mounted read-only, and even if a power failure can be ruled out, there are still good reasons to keep it like that.

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

I do not know if I am credible :-) but I have experienced this myself whey testing CFs from several makes by cycling power when performing intensive write. One card was fully damaged whereas the others had varying degrees of problems varying from recoverable with fsck to recoverable only by mkfs'ing the partition.

Regards.

Elder.

Reply to
Elder Costa

I think you can get the correct drivers and boot sector for the DoM drive. I have seen them for DoC. Anybody know where to find them?

Bob McConnell N2SPP

Reply to
Bob McConnell

And what about a DOM or CF formatted with JFFS2 ? What about StrataFlash ? Could they have the same bweird behavoir ?

--Helix

Reply to
Helix

What's wrong with using a large capacitor (GoldCap??) to allow the write to finish? If you tie the CF reset line to a power fail detector, the CF should finish any pending writes safely. Use a 5V cap, a switching buck controller to 3.3V and calculate the worst case time needed to finish a sector write.

Rob

Reply to
Rob Turk

Note that DOC (DiskOnChip) adn DOM (DiskOnModule) are completely different beasts:

- a DOM device is interface compatible with a standard IDE drive, the software can't tell the difference, so consequently, you don't need any special boot sector or driver for it, the normal IDE driver and boot techniques will do. They do have some problems which I have tried to summarize in another posting in this thread.

- a DOC is basically a bank-switched flash memory device that comes with a tricky boot firmware preinstalled which replaces the BIOS's handlers for disk access calls. So the device *appears* as an IDE drive, but only as long as all accesses go through the BIOS. Since Linux does not use the BIOS, using a DOC requires a special device driver (which has been available for quite some time under "MTD Devices". For more info, look at the Linux MTD project at

formatting link

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

That might well do the trick. There have been rumors in this NG that some special CF devices are available now with a GoldCap integrated for exactly this purpose. I would like to see a confirmation from someone who successfully used such a thing (make/model?).

Anyone?

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

That won't help for several reasons:

  1. No read/write filesystem (neither JFFS* nor any other) can prevent a situation where a power failure happens while a write access is pending.
  2. In order to do proper wear-levelling, JFFS needs to know the underlying media's block structure. But this information is invisible at the IDE interface. It may even vary across different CF makes/models.

AFAIK, StrataFlash is just plain flash memory. Yes, it makes sense to use JFFS2 on Strataflash, and yes, such a configuration should be resilient to power failures.

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.com
Reply to
Robert Kaiser

That might be difficult, as the flash cards might use internal RAM sector buffers and they might do a lot of internal shifting, when they find a wear out condition on a sector that is to be written. I suppose there are no specs available about the worst case "access to writing done" time.

-Michael

Reply to
Michael Schnell

drive.

Hi guys, thanks for all the info!

Mark

Reply to
Mark

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.