Re: Linux on CF-Cards
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
> rsmith@bitworks.com
>
>
>
> --
> To UNSUBSCRIBE, email to debian-embedded-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
--
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
Reply to: