I was told by SanDisk when CF first came out to ignore
what the "lynix guys" (sic) were saying when I was
excoriated on this list for saying that everything
one needs to do is already incorporated into the
Compact Flash and it needs only to be treated as a
disk, nothing else!

Compact Flash is not just some flash RAM with an
IDE interface plug. It contains both static RAM
and flash RAM. It goes by pages and a stale page
is flushed to flash when a new page is being
accessed, or when other (propriatary) events are
true. The result is that most of the accesses
go to static RAM.

We have devices in the field with Linux embedded
in them for about 4 years that continuously write
to Compact Flash because the CF is mounted as
the root file-system and there is both log activity
and NTPD activity. The stuff still works and, in fact,
we have lost processors, power supplies, and Ethernet
controllers, but never CompactFlash.

There was some version of Linux that blacklisted the
CompactFlash that we were using. It thought it was
some hard disk that it didn't like. I removed the
black-listing and it worked fine. That was in a
device that had a RAM disk mounted on /tmp and
/var to minimize "wear." Eventually, we got rid of that.

On Tue, 6 May 2008, Yigal Sadgat wrote:

quoted text
> We wrote the Kernel to support CF drives (in IDE mode) several years ago but
> now there are strange things coming back from the field that compel us to go
> back and re-evaluate many design decisions.
>
> For instance,
> (1) Can you really ignore bit(2) (CORR) in the Status register offset 7 that
> tells
> you that the CF has detected and corrected a soft error?, etc.
> (2) An engineer at SanDisk Engineering told me NOT to do wear leveling.
> The file allocation table is written very frequently back into the flash. So
> is it really safe to assume that I don't need wear leveling???
> (3) Re. the BUSY bit in the status register (offset 7, bit D7), anybody
> experienced
> time outs?
> (4) Re Error register (offset 1) bit D7 (BBK), again, I was told that it
> cannot (???)
> happen since the CF performs read-after-write and it automatically switches
> good blocks
> for bad ones... Is this correct?
>
> We get many "soft" errors and I cannot wait to put my hand on a system to
> test but
> thought I would draw on your collective experience before we dive into these
> issues again.
>
> Any comments would be greatly appreciated.
>
> Yigal Sadgat
> General Computer Technology (GCT)
> YSadgat1@gcte.com
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/