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