On Thu, Jan 22, 2004 at 10:51:00AM -0600, Richard Smith wrote: Yes, it is true that CF has a rather limited write cycle, compared to other persistent storage. But, I don't think anybody doing serious embedded systems will want to use the CF as a hard disk. CF is a great way to boot up the system. Then, most of its content should be mounted as read-only on a ram-based root filesystem. The writable-part should be on the ramdisk, and should be updated to the CF only occasionally.
Does Linux have union-mount yet, in 2.6.x? It will make my life less miserable in building embedded systems. Bao > J?r?me Warnier wrote: > > >>I was looking for some inexpensive IDE to CF converters on ebay, > >>ended up buying some IDE with CF modules attached: > > > > CF cards in embedded systems are very touchy if you have write access > enabled. Basically if your power supply goes south during a write the > meta-data on the CF card can become corrupted and it's trashed. I've > had personal experience with this and read of many other reports of this. > > To make a CF robust under write conditions there are specific signals > that _must_ retain power during a write. A normal CF->IDE adapter will > not do this for you. > > Here's a piece I received outlineing the issue further: > > 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 > > > -- > Richard A. Smith > [EMAIL PROTECTED] > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] -- Best Regards. Bao C. Ha Hacom OpenBrick Distributor USA http://www.hacom.net voice: (714) 530-8817 fax: (714) 530-8818 8D66 6672 7A9B 6879 85CD 42E0 9F6C 7908 ED95 6B38
