For an internal project, I wrote an emulator for card services that
supports enough
to be able to load and run memory_cs.o and ftl_cs.o and have them talk
to the
embedded flash. I had the advantge that my system was not (also) a
PCMCIA one
so I didn't have to worry about compatibility.
For the general case, I'd be inclined to use macros to change the name
of all
the external entry points in memory_cs and ftl_cs and build the same
type
of stub that I did (for whatever type of flash you have). Then you
should be
able to link it straight into the kernel.
My stub is around 1100 lines and supports the following operations:
case GetCardServicesInfo:
case RegisterClient:
case DeregisterClient:
case RegisterEraseQueue:
case DeregisterEraseQueue:
case GetFirstRegion:
case GetNextRegion:
case OpenMemory:
case ReadMemory:
case WriteMemory:
case CloseMemory:
case CheckEraseQueue:
case ReportError:
I also took lots of shortcuts - for example, I only support erasing a
single
block per request. It turns out that that is all that is needed. [My
development
strategy was to implement functions as required. Once done, a quick code
inspection of the memory_cs and ftl_cs revealed that no more operations
were
required.]
As a side note, the ftl_cs code reveals a significant problem with the
filesystem
layer -- there is no way for the filesystem to signal that a block is
unused. This
is important because once a flash disk is full, deleting files does not
reduce
the number of (flash) allocated blocks. This has an impact on the write
performance.
Philip
-- Philip Gladstone +1 617 487 7700 Raptor Systems, Waltham, MA http://www.raptor.com/