M-Systems Flash Disk compliance.

Chris Caudle ccaudle at pdq.net
Wed Nov 15 20:39:35 UTC 2000


>===== Original Message From 	Erik Ivanenko <erik.ivanenko at utoronto.ca> =====
>First, I need to know: Can grub be loaded onto the M-Systems Flash disk
>to boot pc-386?

Yes, that works fine.

>Also, I've heard suggestions that RTEMS may soon have native file system
>support.  Hopefully, this is M-Systems compatible.

Probably not.
Here is what goes on, from my understanding:
Background:  Flash devices have limited write lifetimes, with various numbers 
of writes before error rates start going up quickly, from 10k to 100k writes.
A "flash file system" will try to map blocks used across the device with some 
type of fairness algorithm such that no block on the device has a much larger 
proportion of writes than other blocks.  What that would mean in practice is 
that if a particular file system block had heavy write activity, the mapping 
between the file system block and the flash memory location would have to 
change with time.

M-Systems have a file system for that purpose, but it is not open source.
The Disk-On-Chip devices work by installing a handler for interrupt 13 which 
includes the flash "wear levelling" code.  GrUB loads the executable image by 
using calls to int 13.  A native file system on RTEMS would presumably expect 
a block device interface interface of some kind, so there would have to be a 
block device interface wrapped around the wear leveling code.
M-Systems will provide you that code, I believe, but you would not be able to 
distribute it, so it would not become a generic solution for RTEMS.

If you noticed, the number of writes before you had to worry about the device 
wearing out was relatively large.  If you can deal with a mostly read only 
file system, you would not have to worry about wear leveling, and just a plain 
ROM based file system should work.  The IMFS might even work if you could 
convince it to use a memory space other than heap, but I'm not sure of the 
details of that implementation.

A different but similar option is to use one of the M-Systems IDE interface 
products, rather than the Disk-On-Chip.  With those, you just write a generic 
IDE driver, and the M-Systems device handles all of the wear levelling 
internally.  The cost is a little higher, but the advantage is that you can 
move back and forth between real IDE hard drives, and the M-Systems solid 
state drive without changing your code.

-- Chris Caudle




More information about the users mailing list