Off topic CF questions
Alan Mimms
a.mimms at f5.com
Tue Nov 25 13:34:00 CET 2003
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
More information about the coreboot
mailing list