Off topic CF questions

[Alan Mimms]

We have information from a Compact Flash manufacturer that says you
should have hardware to solve this problem - I do not believe there is a
software solution.  The problem is caused by the fact (as you state)
that CF stores metadata in the flash blocks along with the disk block
data.  If the metadata is corrupted by an aborted write, it can affect
all of the disk blocks stored in the flash block, and the metadata can
even be so corrupt that you lose unrelated blocks.  Our most common
scenario for failure is to lose disk block #0, which, of course, is the
boot block for our OS.
We solve this using hardware.  You need to use buffers to disconnect the
CF's ATA reset, output-enable and write-enable signals from their source
on the bus, and hold up DC power to the pull-ups, the buffers and the CF
itself for at least 10ms-20ms after detecting the imminent loss of
power.
This is being implemented in our new hardware designs, and we have not
yet gotten one back from fabrication to test.  But it sure looks like it
will work to solve the problem.
Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
Liberty Lake, Washington
v: 509-343-3524   f: 509-343-3501


-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of tyson at irobot.com
Sent: Monday, November 24, 2003 4:47 PM
To: LinuxBIOS
Subject: Off topic CF questions

This is a bit off topic, but I need some pointers and we seem to have 
quite a few really smart people on this list. ;-)

I'm trying to learn about the issues and solutions to using CF cards for

data logging in appliances where the power may be pulled at any time.

There are sort of two classes of logging.  One would be classic "write 
only" logging.  The other would be things like total run time, an 
odometer, that sort of thing where you might want to something that 
amounts to erase the old value and over write it with a new one. 
Obviously the second case would degenerate a bit with at least "double 
buffering" and could get as "bad" as a "write only" log history.

I say write only, meaning that the download/reset/erase procedure could 
be under controlled conditions and not a concern.

My issue is that CF cards present and IDE abstraction that hides the 
underlying block sizes and the fact that FLASH is erased as a block (and

unknown block) and rewritten from scratch.  I have absolutely no idea 
what size these blocks are such that I might separate my "read-only" 
partitions from my "write only" partitions with a buffer partition.  I 
also have absolutely no idea what happens to these things when the power

is pulled, esp. in the middle of an erase/write cycle or how these 
erase/write cycles might be optimised.

Any pointers or suggestions would be greatly appreciated.

Thanks!
Ty

-- 
Tyson D Sawyer                             iRobot Corporation
Senior Systems Engineer                    Military Systems Division
tsawyer at irobot.com                         Robots for the Real World
603-654-3400 ext 206                       http://www.irobot.com

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios