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 ...
[ message continues ]

drivers/mtd/nand/alauda.c already does page writes.  You didn't know the

existing wheel and invented new one.  That happens and there is nothing

wrong with it.
Your chances of merging your new code as-is are roughly zero.  But I

would still like to see the code and see where yours is better and ours
Are Memory Sticks covered by your code?  That would be a worthwhile

improvement.
Jörn
--

Joern's library part 3:

http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf

--

Smartmedia cards _ARE_ dumb NAND flash chips in a thin plastic cover

with gold contacts. The access to those cards is supported in the mtd

subsystem since ages. Why are you trying to reinvent the wheel ?
The only missing piece is the FTL layer, but there was a halfways
Err, why is MTD not helpful ? It covers all the low level access to

the NAND Flash and has a flexible interface to adapt to hardware.
We really do not need a second incarnation of NAND flash software in

the kernel.
Thanks,

	tglx
--

They're NAND chips, just with a standard ECC/block replacement

stratergy... why isn't this under drivers/mtd ?
--

Ben (ben@fluff.org, http://www.fluff.org/)
  'a smiley only costs 4 bytes'

--

They have nothing to do with JFFS or UBI (it's an interchange format).

They require FTL.

On the other hand, "SmartMedia reader" is a rather definite kind of animal that exists on its own.
      ____________________________________________________________________________________

Be a better friend, newshound, and

know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--

MTD is independent of JFFS2 and UBI. It's the hardware abtraction
No it is not. SmardMedia is a bare NAND chip, which is already covered

by MTD. There are already other FTLs on top of MTD and the SmartMedia

format just can be added to those.
Thanks,

	tglx
--

Isn't drivers/mtd/ssfdc.c - despite its name - an implementation of the

SmartMedia FTL?  When I last looked at it, I failed to see any

functional differences.
Jörn
--

Doubt is not a pleasant condition, but certainty is an absurd one.

-- Voltaire

--

On Thu, 17 Apr 2008, J

Indeed.  If some janitor or kernel-newbie is looking for a fun project,

most of the code in drivers/usb/storage/*.c can be abstracted out to a

library implementation and possibly combined with drivers/mtd/ssfdc.c,

drivers/mtd/nand/alauda.c and some others.
Jörn
--

The only good bug is a dead bug.

-- Starship Troopers

--

Unfortunately, I must say, Smartmedia is not supported on linux for any reasonable definition of

the word.
First, with all the respect to Jorn, alauda driver can only be considered "proof of concept". It

does not try to abstract any smartmedia functionality.
Second, ssfdc is hopelessly obsolete and requires rewrite.
Third, there's no attempt made by mtd to support advanced functionality present in many smartmedia

and all memorystick readers: adapter side copy and multi page programming (this mostly relates to

memorystick, of course). I also failed to see any support for device writing policy, needed to

discern, for example, sequential page programmable devices vs. block programmable devices. I also

failed to see an unified approach to page-accessible devices, meaning duplication of "bouncing"

code in the backends.
In general, block device emulation layer of mtd is incomplete at best.
No infrastructure exists for exporting and manipulation of metadata in userspace.
And, in general, architecture of mtd is suboptimal, relying on blocking calls (as opposed to

callback based architecture).
Considering all this, amount of effort needed for satisfactory support of smartmedia through mtd

was found by me to be far greater than coming with stand-alone implementation. I do agree, that

eventually my work can be merged into mtd. I don't see what prevents merging of my implementation

as is on an interim basis, considering there are no real alternatives.
In case somebody is actually interested in looking at the code:
http://svn.berlios.de/wsvn/tifmxx/trunk/driver/#_trunk_driver_
      ____________________________________________________________________________________

Be a better friend, newshound, and

know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--

"Proof of concept" is the wrong term.  The goal of

drivers/mtd/nand/alauda.c is to get raw access to the flash.  It

explicitly does not abstract anything because I don't want the

abstraction.  I want a raw piece of flash, represented via mtd.  And I

believe it does match those goals - modulo some bugs.
You seem to want something else.  I have a rough idea what that might
When using the raw mtd, it does.  After block device translation, it
Correct.  Erase() is the only callback-based function and every single

driver implements it synchronous anyway.  Improving this situation is

needed for mtd's own sake anyway.  Either that or replacing mtd with
As Thomas already stated, the kernel crowd has little sympathy for

duplication.  In general, if someone comes along and sais "A if not good

enough, so I wrote B", the answer is "go fix A instead".  Not always in

a polite way, I might add.
Sometimes there are good reasons not to fix A.  Usually the reason is to

remove A after B has been merged.  Which does not apply here.  So you

should prepare to explain yourself rather well, if you ever want to see

your code merged.
That said, I personally like duplication and believe it is the way to go

in many causes.  If your code can ignore all the issues with A, you can

focus on the problem at hand and write the best code possible.  But that

is just the first step.  In a second step, any common code of the two

pieces gets generalized and used by both.
The reason why I prefer generalizing late rather than early is that

almost noone gets the abstractions right before seeing all users.

Certainly not me.  The end result is better by being specialized first

and generalize later.  But you have to do the generalization step.
And your chances of getting the code merged before the generalization

are low.  Particularly when adding new userspace interfaces, because we
Sure am.  You should use explicitly sized types in most of your data

structures, like here:

struct xd_card_extra {

        un...
[ message continues ]

As you understand, both smartmedia media and hosts follow certain spec (publicly available here:

http://www.ssfdc.or.jp/spec/index_e.htm, basic registration required). xd card spec is almost

identical, adding some cosmetic features and restrictions (such as prohibition of single page

programming). This means, that smartmedia access protocol can be abstracted out in the

reader-independent way. You can seen in the xd_card_blk.c that it can operate both completely dumb

controllers, while taking protocol shortcuts (using host->caps) to accommodate smarter readers

(the only feature currently not there is adapter-side page copy - it can be easily added under

FBD_COPY clause in xd_card_trans_req). The backend itself (jmb38x_xd.c) should not concern itself
I meant here the ability of user to look and modify CIS page, as well as look at the current block
I was not moving to submit just yet. As it's not my first submission, I "prefetched" some time for

an usual flame war.
      ____________________________________________________________________________________

Be a better friend, newshound, and

know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--

On Fri, 18 Apr 2008, Alex Dubov wrote:
First off, can you please use a mail client which does line breaks at
That's all fine. Nobody asked for the backend to know about smartmedia

on FLASH format details. The MTD NAND FLASH layer does not care about

on FLASH data format at all. It provides merily access on the hardware

level.
I agree that your approach of making the SM/XD layer capable of

handling clever and dumb hardware adapters is a good one.
The point where I stringly disagree is that your implementation is

forcing people with dumb hardware (see drivers/mtd/nand/*) to

reimplement the (maybe already) existing drivers in order to make use

of the ssfdc format, which will not work with the following real world

example:
------------------

| NAND controller |----------| On board NAND

| with HW ECC     |

|                 |----------| SmartMedia Card

------------------
Having a separate driver infrastructure for clever controllers, which

provide only semi raw access to the FLASH chip is fine simply because
Well, you probably do this with an iotctl anyway. So what's preventing

you to modify the mtd block layer to handle client private ioctls.
Also there is no real requirement to use the mtd block layer at all
That's the best excuse I ever heard for not improving code which has

shortcomings.
Thanks,

	tglx

--

Shouldn't both smartmedia and legacy memorystick controllers can be considered
I think ioctls are nowhere as convenient as sysfs file. I believe many people

share this point of view - after all, ioctls throw a lot of different
I see that raw mtd operates on buffer pointers, rather than scatterlists. From

my understanding, it demands "map" and possibly "bounce" operation elsewhere,

incurring sizable overhead on performance (for fast media, the waits in the

blocking read/write operations will also have considerable effect). Are there
Can't agree. It's one of the most commonly used, according to my experience.
      ____________________________________________________________________________________

Be a better friend, newshound, and

know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--

It would also be nice if it wouldn't drop the name "Jörn Engel" from my

mail (indication for spam, mail ends in a different folder), kept a

References: or In-Reply-To: header and could deal with utf8.
Jörn
--

Fancy algorithms are buggier than simple ones, and they're much harder

to implement. Use simple algorithms as well as simple data structures.

-- Rob Pike

--

And instead of addressing the missing features and shortcomings you

add a new duplicated code layer which is only useful for a restricted
Yeah and you made this decision on your own w/o even discussing the

issues at hand with the mtd developers before implementing a separate

code stack. And now we should be impressed and merge it. That's not
Merging your code as is is a bad idea as it contains userspace visible

changes which can not be undone easily. Interim solutions burden more

problems on us than they solve.
Thanks,

	tglx

--

I do not expect you, or anybody, to be "impressed" with anything. As I said before, from my

analysis of mtd it will require a great deal of patching to acquire certain functionality. This

will invariably require a large time span, as many people depend on the mtd in it present state.
If your position on the proposed interim solution is definite "no", I'll make an effort to rewrite

the driver in the mtd-friendly way.
This brings me to the first technical question:
mtd_blkdevs breaks the block layer request into separate pages, effectively disabling lower layer

from making decision based on a real data block size, and using dma to any useful extent. What is

the proposed way to deal with this?
(By the way, first question already puts us into a "quirk" area of the statement "smartmedia are

flash chips with quirks". Both memorystick and smartmedia are always operated in tandem with their

controllers, as you could notice.)
      ____________________________________________________________________________________

Be a better friend, newshound, and

know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--

Wrong in two aspects. 
1) it does not break the request into separate pages. It breaks it

into mtd_blktrans_ops->blksize chunks, which is set by the blkdev

user.
2) Using DMA on raw NAND Flash is on per page basis except you have an

"intellegent" controller chip which does the low level handling of the
I have no idea what you want to tell me. there is no quirk in a

smartmedia card.
Thanks,

	tglx
--

Or does using them according to the interchange spec require FTL?
(That is, it would be really cool to finally have a supported MTD device

that doesn't need to be soldered on to the motherboard, so I could plug

the thing in and run UBIFS / JFFS2 / whatever.  I wouldn't be able to

use it for a camera, then, but it would be great for little machines

that don't need full hard drives, or for developing MTD filesystems on

readily-available hardware.)
--Andy

--

There is one MTD driver for Smartmedia/xD in the kernel, see

drivers/mtd/nand/alauda.c. It is derived from the USB mass storage

driver drivers/usb/storage/alauda.c, which contains another copy of

the SM FTL.
	Arnd <><

--