linux-kernel - Smartmedia/xd card support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <466372.69780.qm@web36702.mail.mud.yahoo.com>
Date:	Thu, 17 Apr 2008 01:50:33 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Smartmedia/xd card support - request for comments

I've implemented, with generous help from JMicron, a native support for Smartmedia/xD picture card
media. Currently, only JMicron backend is available, but TI expressed some interest in this too,
so TI Flashmedia backend may soon follow.

Smartmedia cards are quite akin to the dumb flash chips, but they have their quirks that put them
aside as a separate media type.

I thought of the following merge structure:

include/linux/
    flash_bd.h
    xd_card.h

drivers/xd_card/
    xd_card_blk.c - protocol implementation
    xd_card_ecc.c - software version of Smartmedia ecc algorithm
    jmb38x_xd.c   - JMicron backend

lib/
    flash_bd.c    - generic FTL implementation

A few more words about flash_bd component. Legacy MemoryStick and SmartMedia cards require direct
management of flash memory. I studied the mtd layer, but found it to be not very helpful, so I
wrote my own FTL module.

Its requirements were:
1. Subsystem independent. For a given byte range it will produce a sequence of generic opcodes
needed to read or write such a range to/off the flash memory, assuming page grained access. This
is used not only for block device operations, but also for metadata retrieval.
2. No FTL related metadata is stored to the flash (as nothing can be assumed about other
readers/writers in interchange media formats).

My FTL implements random block replacement policy, as there's no spec-mandated way to maintain
wear counts on Smartmedia or Memorystick. It also supports block allocation zoning, as required by
these formats.

Current version will always issue whole block writes (no individual page programming). I,in fact,
implemented a version which tracks partially filled blocks, but experiments with some Olympus xd
cards triggered a lot of funny hardware problems with this, and then, it appeared that latest
version of xd card spec specifically disallows partial block writes.

MemoryStick spec does allow individual page writes, but so did an older version of xd card spec.
Given this, I decided to start with simpler version of FTL for now and replace it with a more
complex one if need arises.

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/