Mailing List Archive: Linux: Kernel

Plan for adding XD support in mtd layer

Index | Next | Previous | View Threaded

maximlevitsky at gmail

Nov 24, 2009, 3:50 PM

Post #1 of 11 (864 views)
Permalink

Plan for adding XD support in mtd layer

Here is my plan for adding the XD format into MTD subsystem.
Please review.

New additions are marked with '->'

Chip driver:

no problems with that, in fact ricoh controller I reverse engineered is
very similar conceptually
to jmicron.
I can take original jmicron driver almost verbatim.
This will live in new sub folder of mtd and call into base XD driver

Base XD mtd driver:

* No way to tell that readsize = 512, but write & erase size isn't.
Not such a big deal, since higher level FTL driver can hardcode that
assumption, and access via mtdblk isn't necessary, since FTL will
replace it for XD, and the raw access will be done through mtdchar.

* it is possible to export 'extra' via oob. FTL will use that, and will
be available to user via char device

* No need to export CIF block, it will be available for user via char
device by scanning the device (using a new utility)

-> I need new mtd_info member for at least for card identification, and
will be nice to have zone/block/page size
This will be used by FTL and mtdchar to be exported to user space

FTL driver:

I will write new XD/smartmedia FTL driver.

* Will read ID/type from device and do all the work based on that,
(figure page size/zone count/block size, etc...) or will get that info
from mtd driver

* Will cache read/writes (this will overlap with mtdblk)

* Will provide normal block level access to filesystems, and user.
(using common block device of course)

* No debugging information or/and device specific ioctls.

Char driver:

* Already exists, and I will need to modify it, so I could read ID/media
type
Also would be nice to pass info about sizes (zones/pages/blocks) to
userspace
If not, I will put translation table to userspace utility based on media
ID

Userspace utility:
* Will allow user to read FTL maps (based on oob), Media ID, CIF, all
using char device
* Will also allow low level format.

Best regards,
Maxim Levitsky

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

joern at logfs

Nov 25, 2009, 2:40 AM

Post #2 of 11 (838 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Wed, 25 November 2009 01:50:10 +0200, Maxim Levitsky wrote:
>
> Chip driver:
>
> no problems with that, in fact ricoh controller I reverse engineered is
> very similar conceptually
> to jmicron.
> I can take original jmicron driver almost verbatim.
> This will live in new sub folder of mtd and call into base XD driver

Ok. Is the code available somewhere or can you send it? And what
devices would one have to buy to test it?

> Base XD mtd driver:
>
> * No way to tell that readsize = 512, but write & erase size isn't.
> Not such a big deal, since higher level FTL driver can hardcode that
> assumption, and access via mtdblk isn't necessary, since FTL will
> replace it for XD, and the raw access will be done through mtdchar.
>
> * it is possible to export 'extra' via oob. FTL will use that, and will
> be available to user via char device
>
> * No need to export CIF block, it will be available for user via char
> device by scanning the device (using a new utility)
>
>
> -> I need new mtd_info member for at least for card identification, and
> will be nice to have zone/block/page size
> This will be used by FTL and mtdchar to be exported to user space

Block and page size already exist as mtd->erasesize and mtd->writesize
respectively. I'm not sure whether the zone size should become part of
the mtd interface - it looks more like a property of the ftl.

> FTL driver:
>
> I will write new XD/smartmedia FTL driver.
>
> * Will read ID/type from device and do all the work based on that,
> (figure page size/zone count/block size, etc...) or will get that info
> from mtd driver
>
> * Will cache read/writes (this will overlap with mtdblk)
>
> * Will provide normal block level access to filesystems, and user.
> (using common block device of course)
>
> * No debugging information or/and device specific ioctls.
>
>
> Char driver:
>
> * Already exists, and I will need to modify it, so I could read ID/media
> type
> Also would be nice to pass info about sizes (zones/pages/blocks) to
> userspace
> If not, I will put translation table to userspace utility based on media
> ID

What userspace programs would need this information? I can imagine some
sort of xd_format or mkxd in case the card has been corrupted or used
raw. Anything else?

> Userspace utility:
> * Will allow user to read FTL maps (based on oob), Media ID, CIF, all
> using char device

What would this be needed for?

> * Will also allow low level format.

Jörn

--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

maximlevitsky at gmail

Nov 25, 2009, 5:20 AM

Post #3 of 11 (832 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Wed, 2009-11-25 at 11:40 +0100, Jörn Engel wrote:
> On Wed, 25 November 2009 01:50:10 +0200, Maxim Levitsky wrote:
> >
> > Chip driver:
> >
> > no problems with that, in fact ricoh controller I reverse engineered is
> > very similar conceptually
> > to jmicron.
> > I can take original jmicron driver almost verbatim.
> > This will live in new sub folder of mtd and call into base XD driver
>
> Ok. Is the code available somewhere or can you send it? And what
> devices would one have to buy to test it?
Currently jmicron support is found in aspire one.
My acer has ricoh device I know how works.
Alex dubov said that TI has interest in a driver.
As soon as core is written and accepted, writing drivers will be very
easy if one has documentation.

I also plan to write a 'dummy' driver to test subsystem against.

Other that work of Alex Dubov, I need to write the code, but I don't
want to repeat his mistake and write code that isn't accepted on basis
of lack for fitness in existing subsystems.

>
> > Base XD mtd driver:
> >
> > * No way to tell that readsize = 512, but write & erase size isn't.
> > Not such a big deal, since higher level FTL driver can hardcode that
> > assumption, and access via mtdblk isn't necessary, since FTL will
> > replace it for XD, and the raw access will be done through mtdchar.
> >
> > * it is possible to export 'extra' via oob. FTL will use that, and will
> > be available to user via char device
> >
> > * No need to export CIF block, it will be available for user via char
> > device by scanning the device (using a new utility)
> >
> >
> > -> I need new mtd_info member for at least for card identification, and
> > will be nice to have zone/block/page size
> > This will be used by FTL and mtdchar to be exported to user space
>
> Block and page size already exist as mtd->erasesize and mtd->writesize
> respectively. I'm not sure whether the zone size should become part of
> the mtd interface - it looks more like a property of the ftl.
You didn't understand me.
I can't nether write nor erase individual blocks (writing is technically
possible, but is disallowed by recent XD spec (this is what Alex Dubov
says)

However I can _read_ individual sectors
sector is 512 bytes, block is usually around 32 sectors.

>
> > FTL driver:
> >
> > I will write new XD/smartmedia FTL driver.
> >
> > * Will read ID/type from device and do all the work based on that,
> > (figure page size/zone count/block size, etc...) or will get that info
> > from mtd driver
> >
> > * Will cache read/writes (this will overlap with mtdblk)
> >
> > * Will provide normal block level access to filesystems, and user.
> > (using common block device of course)
> >
> > * No debugging information or/and device specific ioctls.
> >
> >
> > Char driver:
> >
> > * Already exists, and I will need to modify it, so I could read ID/media
> > type
> > Also would be nice to pass info about sizes (zones/pages/blocks) to
> > userspace
> > If not, I will put translation table to userspace utility based on media
> > ID
>
> What userspace programs would need this information? I can imagine some
> sort of xd_format or mkxd in case the card has been corrupted or used
> raw. Anything else?

I can imagine a format application, a rescue application, and an debug
application that will show how healthy is the card.

There are actually two pieces of the data.
One is an ID, a serial number that can be used for example by udev for
permanent mapping.

Other is the media type, and this has to be used to know the sizes of
sectors, zones, pages, how many spares there are etc...

>
> > Userspace utility:
> > * Will allow user to read FTL maps (based on oob), Media ID, CIF, all
> > using char device
>
> What would this be needed for?
A rescue operation, of just for curiosity...
Also to edit CIF to bypass vendor lock-in as explained in Wikipedia
article

Access via mtdblock can be used to use the card as raw device too.

ECC corecting will be done in the base mtd driver, but userspace
application will be able to determine if block is good or bad.
If it is good, it can use oob information to determine of ECC correction
was applied or not, and report overall health of the card.

Thus I think that XD can be integrated in the core quite easily with
only minor modifications.

Best regards,
Maxim Levitsky

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

joern at logfs

Nov 25, 2009, 7:34 AM

Post #4 of 11 (833 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

Hello Maxim

On Wed, 25 November 2009 15:20:58 +0200, Maxim Levitsky wrote:
>
> Currently jmicron support is found in aspire one.
> My acer has ricoh device I know how works.

Those are card readers built into notebooks, right? How are they
attached? Via PCI or USB?

> Other that work of Alex Dubov, I need to write the code, but I don't
> want to repeat his mistake and write code that isn't accepted on basis
> of lack for fitness in existing subsystems.

> > > -> I need new mtd_info member for at least for card identification, and
> > > will be nice to have zone/block/page size
> > > This will be used by FTL and mtdchar to be exported to user space
> >
> > Block and page size already exist as mtd->erasesize and mtd->writesize
> > respectively. I'm not sure whether the zone size should become part of
> > the mtd interface - it looks more like a property of the ftl.
> You didn't understand me.
> I can't nether write nor erase individual blocks (writing is technically
> possible, but is disallowed by recent XD spec (this is what Alex Dubov
> says)
>
> However I can _read_ individual sectors
> sector is 512 bytes, block is usually around 32 sectors.

It has been a while since I looked at the spec, but I believe there are
two parts to it. The flash hardware allows block erases, sector reads
and sector writes. On top of that you have the FTL that adds further
restrictions.

If you use you xD card without the FTL, as a raw MTD device, you can do
almost anything you want. Format it with JFFS2, for example. But if
used _with_ the FTL, that card now has a corrupt format and may be
unusable.

Or is the FTL already implemented in the card reader hardware?

> > What userspace programs would need this information? I can imagine some
> > sort of xd_format or mkxd in case the card has been corrupted or used
> > raw. Anything else?
>
> I can imagine a format application, a rescue application, and an debug
> application that will show how healthy is the card.

Format and rescue certainly make sense. I'm not sure how a debug
application would measure the health, but maybe that's possible as well.

> There are actually two pieces of the data.
> One is an ID, a serial number that can be used for example by udev for
> permanent mapping.

Ok, makes sense.

> Other is the media type, and this has to be used to know the sizes of
> sectors, zones, pages, how many spares there are etc...

That would be available when using mtdchar or mtdblock to read the
device. Which ought to be enough for format, rescue and debug, I
believe.

> ECC corecting will be done in the base mtd driver, but userspace
> application will be able to determine if block is good or bad.
> If it is good, it can use oob information to determine of ECC correction
> was applied or not, and report overall health of the card.

With mtdchar it is possible to do ECC correction in userspace as well.
Not that I would consider it a good idea, but the information is
certainly available and can be controlled if a compelling reason can be
found.

Jörn

--
Invincibility is in oneself, vulnerability is in the opponent.
-- Sun Tzu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

maximlevitsky at gmail

Nov 25, 2009, 8:17 AM

Post #5 of 11 (839 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Wed, 2009-11-25 at 16:34 +0100, Jörn Engel wrote:
> Hello Maxim
>
> On Wed, 25 November 2009 15:20:58 +0200, Maxim Levitsky wrote:
> >
> > Currently jmicron support is found in aspire one.
> > My acer has ricoh device I know how works.
>
> Those are card readers built into notebooks, right? How are they
> attached? Via PCI or USB?
Mostly in notebooks.
External readers usually implement standard mass-storage protocol.

They are usually PCI , however some USB devices work the same, for
example
alluda device that currently has two drivers in the kernel, one mtd for
raw access, and another self-contained USB driver that does FTL and
exposes device as an SCSI device.

>
> > Other that work of Alex Dubov, I need to write the code, but I don't
> > want to repeat his mistake and write code that isn't accepted on basis
> > of lack for fitness in existing subsystems.
>
>
> > > > -> I need new mtd_info member for at least for card identification, and
> > > > will be nice to have zone/block/page size
> > > > This will be used by FTL and mtdchar to be exported to user space
> > >
> > > Block and page size already exist as mtd->erasesize and mtd->writesize
> > > respectively. I'm not sure whether the zone size should become part of
> > > the mtd interface - it looks more like a property of the ftl.
> > You didn't understand me.
> > I can't nether write nor erase individual blocks (writing is technically
> > possible, but is disallowed by recent XD spec (this is what Alex Dubov
> > says)
> >
> > However I can _read_ individual sectors
> > sector is 512 bytes, block is usually around 32 sectors.
>
> It has been a while since I looked at the spec, but I believe there are
> two parts to it. The flash hardware allows block erases, sector reads
> and sector writes. On top of that you have the FTL that adds further
> restrictions.
if this is the case, then no problems.
Alex said something about firmware bugs though, that I belive is
connected to raw block writes.

I also know that driver for my ricoh based controller does always block
based cow writes.

when I say block I mean area that can be erased independently, and it
consists of several 512 byte sectors.
(Very old incarnation of smartmedia format had 256 byte sectors that
were tied together in pairs)

>
> If you use you xD card without the FTL, as a raw MTD device, you can do
> almost anything you want. Format it with JFFS2, for example. But if
> used _with_ the FTL, that card now has a corrupt format and may be
> unusable.
>
> Or is the FTL already implemented in the card reader hardware?
No, I have to implement it.
And yes, XD can give ready to use testing ground for flash based file
systems, like JFFS2.

>
> > > What userspace programs would need this information? I can imagine some
> > > sort of xd_format or mkxd in case the card has been corrupted or used
> > > raw. Anything else?
> >
> > I can imagine a format application, a rescue application, and an debug
> > application that will show how healthy is the card.
>
> Format and rescue certainly make sense. I'm not sure how a debug
> application would measure the health, but maybe that's possible as well.
I can count bad sectors, ecc corrected sectors, see how many spares
remain in each block, etc...

>
> > There are actually two pieces of the data.
> > One is an ID, a serial number that can be used for example by udev for
> > permanent mapping.
>
> Ok, makes sense.
>
> > Other is the media type, and this has to be used to know the sizes of
> > sectors, zones, pages, how many spares there are etc...
>
> That would be available when using mtdchar or mtdblock to read the
> device. Which ought to be enough for format, rescue and debug, I
> believe.

Yes this is enough, but how I expose media type in the mtd driver, there
is a field for that I missed?

And same question for the ID.

Note that media type /ID is _not_ stored on the media (well it is but is
not accessible that way)
There is need for special command to read it from the device.

>
> > ECC corecting will be done in the base mtd driver, but userspace
> > application will be able to determine if block is good or bad.
> > If it is good, it can use oob information to determine of ECC correction
> > was applied or not, and report overall health of the card.
>
> With mtdchar it is possible to do ECC correction in userspace as well.
> Not that I would consider it a good idea, but the information is
> certainly available and can be controlled if a compelling reason can be
> found.
Exactly.

Best regards,
Maxim Levitsky

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

joern at logfs

Nov 25, 2009, 12:59 PM

Post #6 of 11 (830 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Wed, 25 November 2009 18:17:46 +0200, Maxim Levitsky wrote:
> On Wed, 2009-11-25 at 16:34 +0100, Jörn Engel wrote:
> >
> > Those are card readers built into notebooks, right? How are they
> > attached? Via PCI or USB?
> Mostly in notebooks.
> External readers usually implement standard mass-storage protocol.

Ok. I guess I won't buy a new notebook just to test a driver then.

> They are usually PCI , however some USB devices work the same, for
> example
> alluda device that currently has two drivers in the kernel, one mtd for
> raw access, and another self-contained USB driver that does FTL and
> exposes device as an SCSI device.

Yes. I've written the mtd driver for that one.

> > It has been a while since I looked at the spec, but I believe there are
> > two parts to it. The flash hardware allows block erases, sector reads
> > and sector writes. On top of that you have the FTL that adds further
> > restrictions.
> if this is the case, then no problems.
> Alex said something about firmware bugs though, that I belive is
> connected to raw block writes.
>
> I also know that driver for my ricoh based controller does always block
> based cow writes.

If you only ever want to use the device with the FTL on top, that is
perfectly acceptable. But it is an FTL restriction, not part of the
hardware. Apart from firmware bugs, of course.

> when I say block I mean area that can be erased independently, and it
> consists of several 512 byte sectors.
> (Very old incarnation of smartmedia format had 256 byte sectors that
> were tied together in pairs)

Some also had 256 or 512 blocks per zone. These days everything seems
to have 512+16 Byte sectors, 16 sectors per block, 1024 physical (1000
logical) blocks per zone and as many zones as the device can fit. Or at
least that was the case two years ago.

> > Format and rescue certainly make sense. I'm not sure how a debug
> > application would measure the health, but maybe that's possible as well.
> I can count bad sectors, ecc corrected sectors, see how many spares
> remain in each block, etc...

Iirc the number of bad blocks never changes. Either a block is
factory-marked or it will stay in use forever. A smart FTL could try to
store the erase count or the number of correctable/uncorrectable errors
for each block somewhere, but I don't believe it is done - or could be
done while staying compatible with the xD spec.

So that pretty much leaves the number of correctable/uncorrectable
errors currently on the device.

> > That would be available when using mtdchar or mtdblock to read the
> > device. Which ought to be enough for format, rescue and debug, I
> > believe.
>
> Yes this is enough, but how I expose media type in the mtd driver, there
> is a field for that I missed?
>
> And same question for the ID.
>
> Note that media type /ID is _not_ stored on the media (well it is but is
> not accessible that way)
> There is need for special command to read it from the device.

Right. I forgot about that one. In fact, I tried fairly hard to
forget. ;)

According to FMTP140E.PDF, CIS and IDI are stored in sector 0 or the
first non-defective block. In other words, it can be read and written
normally, without any magic. Certainly not the atrocities I tried not
to remember.

And even if there are some atrocities hidden, we can abtract them out in
the driver. When reading/writing block 0, just do the magic
transparently.

Jörn

--
There are two ways of constructing a software design: one way is to make
it so simple that there are obviously no deficiencies, and the other is
to make it so complicated that there are no obvious deficiencies.
-- C. A. R. Hoare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

maximlevitsky at gmail

Nov 25, 2009, 3:22 PM

Post #7 of 11 (823 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Wed, 2009-11-25 at 21:59 +0100, Jörn Engel wrote:
> On Wed, 25 November 2009 18:17:46 +0200, Maxim Levitsky wrote:
> > On Wed, 2009-11-25 at 16:34 +0100, Jörn Engel wrote:
> > >
> > > Those are card readers built into notebooks, right? How are they
> > > attached? Via PCI or USB?
> > Mostly in notebooks.
> > External readers usually implement standard mass-storage protocol.
>
> Ok. I guess I won't buy a new notebook just to test a driver then.
>
> > They are usually PCI , however some USB devices work the same, for
> > example
> > alluda device that currently has two drivers in the kernel, one mtd for
> > raw access, and another self-contained USB driver that does FTL and
> > exposes device as an SCSI device.
>
> Yes. I've written the mtd driver for that one.
>
> > > It has been a while since I looked at the spec, but I believe there are
> > > two parts to it. The flash hardware allows block erases, sector reads
> > > and sector writes. On top of that you have the FTL that adds further
> > > restrictions.
> > if this is the case, then no problems.
> > Alex said something about firmware bugs though, that I belive is
> > connected to raw block writes.
> >
> > I also know that driver for my ricoh based controller does always block
> > based cow writes.
>
> If you only ever want to use the device with the FTL on top, that is
> perfectly acceptable. But it is an FTL restriction, not part of the
> hardware. Apart from firmware bugs, of course.
Exactly.

>
> > when I say block I mean area that can be erased independently, and it
> > consists of several 512 byte sectors.
> > (Very old incarnation of smartmedia format had 256 byte sectors that
> > were tied together in pairs)
>
> Some also had 256 or 512 blocks per zone. These days everything seems
> to have 512+16 Byte sectors, 16 sectors per block, 1024 physical (1000
> logical) blocks per zone and as many zones as the device can fit. Or at
> least that was the case two years ago.
Yes that the same I see.

>
> > > Format and rescue certainly make sense. I'm not sure how a debug
> > > application would measure the health, but maybe that's possible as well.
> > I can count bad sectors, ecc corrected sectors, see how many spares
> > remain in each block, etc...
>
> Iirc the number of bad blocks never changes. Either a block is
> factory-marked or it will stay in use forever. A smart FTL could try to
> store the erase count or the number of correctable/uncorrectable errors
> for each block somewhere, but I don't believe it is done - or could be
> done while staying compatible with the xD spec.

>
> So that pretty much leaves the number of correctable/uncorrectable
> errors currently on the device.
Exactly.

>
> > > That would be available when using mtdchar or mtdblock to read the
> > > device. Which ought to be enough for format, rescue and debug, I
> > > believe.
> >
> > Yes this is enough, but how I expose media type in the mtd driver, there
> > is a field for that I missed?
> >
> > And same question for the ID.
> >
> > Note that media type /ID is _not_ stored on the media (well it is but is
> > not accessible that way)
> > There is need for special command to read it from the device.
>
> Right. I forgot about that one. In fact, I tried fairly hard to
> forget. ;)
>
> According to FMTP140E.PDF, CIS and IDI are stored in sector 0 or the
> first non-defective block. In other words, it can be read and written
> normally, without any magic. Certainly not the atrocities I tried not
> to remember.
I wish I had the spec.
I don't know the format of the CIS, and I know that special command is
used to query the ID.
CIS these days isn't used for anything and I hoped not to touch that
thing.

I wont argue on that one with you, but why not to add the new field.
It is quite generic, it could be card vendor information or so?
Few bits of custom information to assign for each card no?

I am taking about these:

struct xd_card_id1 {
unsigned char maker_code;
unsigned char device_code;
unsigned char option_code1;
unsigned char option_code2;
} __attribute__((packed));

struct xd_card_id2 {
unsigned char characteristics_code;
#define XD_CARD_CELL_TYPE_MASK 0xc0
#define XD_CARD_MULTI_BLOCK_MASK 0x30

unsigned char vendor_code1;
unsigned char size_code;
unsigned char vendor_code2;
unsigned char vendor_code3;
} __attribute__((packed));

struct xd_card_id3 {
unsigned char vendor_code1;
unsigned char vendor_code2;
unsigned char id_code;
unsigned char vendor_code3;
} __attribute__((packed));

Are these 32 bit values copied from CIF?

These values are read using commands:

XD_CARD_CMD_ID1 = 0x90,
XD_CARD_CMD_ID2 = 0x91,
XD_CARD_CMD_ID3 = 0x9a

I need especially the xd_card_id1.device_code because this specifies the
media type, but xd_card_id3.id_code is used to detemine if media is
smartmedia or XD.

Best regards,
Maxim Levitsky

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

joern at logfs

Nov 26, 2009, 12:27 AM

Post #8 of 11 (828 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Thu, 26 November 2009 01:22:45 +0200, Maxim Levitsky wrote:
> >
> > According to FMTP140E.PDF, CIS and IDI are stored in sector 0 or the
> > first non-defective block. In other words, it can be read and written
> > normally, without any magic. Certainly not the atrocities I tried not
> > to remember.
> I wish I had the spec.

It used to be semi-free. You could download it for your name and
address. But I believe I'm not legally able to forward it to you and
the official site seems to be down. Most of the information can also
be found here:
http://www.win.tue.nl/~aeb/linux/smartmedia/SmartMedia_Format.pdf
And there seems to be a copy available at pudn:
http://en.pudn.com/downloads137/doc/fileformat/detail585996_en.html

> I don't know the format of the CIS, and I know that special command is
> used to query the ID.
> CIS these days isn't used for anything and I hoped not to touch that
> thing.

:)

> I wont argue on that one with you, but why not to add the new field.
> It is quite generic, it could be card vendor information or so?
> Few bits of custom information to assign for each card no?
>
>
> I am taking about these:
>
> struct xd_card_id1 {
> unsigned char maker_code;
> unsigned char device_code;
> unsigned char option_code1;
> unsigned char option_code2;
> } __attribute__((packed));
>
> struct xd_card_id2 {
> unsigned char characteristics_code;
> #define XD_CARD_CELL_TYPE_MASK 0xc0
> #define XD_CARD_MULTI_BLOCK_MASK 0x30
>
> unsigned char vendor_code1;
> unsigned char size_code;
> unsigned char vendor_code2;
> unsigned char vendor_code3;
> } __attribute__((packed));
>
> struct xd_card_id3 {
> unsigned char vendor_code1;
> unsigned char vendor_code2;
> unsigned char id_code;
> unsigned char vendor_code3;
> } __attribute__((packed));
>
>
> Are these 32 bit values copied from CIF?
>
> These values are read using commands:
>
> XD_CARD_CMD_ID1 = 0x90,
> XD_CARD_CMD_ID2 = 0x91,
> XD_CARD_CMD_ID3 = 0x9a
>
>
> I need especially the xd_card_id1.device_code because this specifies the
> media type, but xd_card_id3.id_code is used to detemine if media is
> smartmedia or XD.

If you add this information to a struct xD_card and have mtd->priv point
to said structure, wouldn't that be enough for your purposes?

Jörn

--
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

maximlevitsky at gmail

Nov 26, 2009, 5:02 AM

Post #9 of 11 (821 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Thu, 2009-11-26 at 09:27 +0100, Jörn Engel wrote:
> On Thu, 26 November 2009 01:22:45 +0200, Maxim Levitsky wrote:
> > >
> > > According to FMTP140E.PDF, CIS and IDI are stored in sector 0 or the
> > > first non-defective block. In other words, it can be read and written
> > > normally, without any magic. Certainly not the atrocities I tried not
> > > to remember.
> > I wish I had the spec.
>
> It used to be semi-free. You could download it for your name and
> address. But I believe I'm not legally able to forward it to you and
> the official site seems to be down. Most of the information can also
> be found here:
> http://www.win.tue.nl/~aeb/linux/smartmedia/SmartMedia_Format.pdf
This one I have, and there is a brief description of the CIS format,
which seems to indicate that its contents are predefined.

> And there seems to be a copy available at pudn:
> http://en.pudn.com/downloads137/doc/fileformat/detail585996_en.html
>
> > I don't know the format of the CIS, and I know that special command is
> > used to query the ID.
> > CIS these days isn't used for anything and I hoped not to touch that
> > thing.
>
> :)
>
> > I wont argue on that one with you, but why not to add the new field.
> > It is quite generic, it could be card vendor information or so?
> > Few bits of custom information to assign for each card no?
> >
> >
> > I am taking about these:
> >
> > struct xd_card_id1 {
> > unsigned char maker_code;
> > unsigned char device_code;
> > unsigned char option_code1;
> > unsigned char option_code2;
> > } __attribute__((packed));
> >
> > struct xd_card_id2 {
> > unsigned char characteristics_code;
> > #define XD_CARD_CELL_TYPE_MASK 0xc0
> > #define XD_CARD_MULTI_BLOCK_MASK 0x30
> >
> > unsigned char vendor_code1;
> > unsigned char size_code;
> > unsigned char vendor_code2;
> > unsigned char vendor_code3;
> > } __attribute__((packed));
> >
> > struct xd_card_id3 {
> > unsigned char vendor_code1;
> > unsigned char vendor_code2;
> > unsigned char id_code;
> > unsigned char vendor_code3;
> > } __attribute__((packed));
> >
> >
> > Are these 32 bit values copied from CIF?
> >
> > These values are read using commands:
> >
> > XD_CARD_CMD_ID1 = 0x90,
> > XD_CARD_CMD_ID2 = 0x91,
> > XD_CARD_CMD_ID3 = 0x9a
> >
> >
> > I need especially the xd_card_id1.device_code because this specifies the
> > media type, but xd_card_id3.id_code is used to detemine if media is
> > smartmedia or XD.
>
> If you add this information to a struct xD_card and have mtd->priv point
> to said structure, wouldn't that be enough for your purposes?

I am afraid not.

My plan is to create one 'meta' mtd driver for all XD controllers, and
plug in small drivers.

The meta driver and small driver will share the ->priv structure.

I need a way to pass the ID from mtd driver to FTL, and to userspace via
mtdchar.

Best regards,
Maxim Levitsky

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

joern at logfs

Nov 26, 2009, 5:42 AM

Post #10 of 11 (827 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Thu, 26 November 2009 15:02:54 +0200, Maxim Levitsky wrote:
>
> This one I have, and there is a brief description of the CIS format,
> which seems to indicate that its contents are predefined.

That is my understanding, yes. Essentially an xD card is just nand
flash in cheap packaging with the first block filled by CIS/IDI.

> I am afraid not.
>
>
> My plan is to create one 'meta' mtd driver for all XD controllers, and
> plug in small drivers.
>
> The meta driver and small driver will share the ->priv structure.
>
> I need a way to pass the ID from mtd driver to FTL, and to userspace via
> mtdchar.

You can also add a ->priv field to struct xD_data. Or you can have it
contain the mtd_info, and use container_of to access the xD information.

But those are details. Feel free to write the code either way. We can
sort out which method to use later.

Jörn

--
Audacity augments courage; hesitation, fear.
-- Publilius Syrus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

maximlevitsky at gmail

Nov 26, 2009, 1:38 PM

Post #11 of 11 (820 views)
Permalink

Re: Plan for adding XD support in mtd layer [In reply to]

On Thu, 2009-11-26 at 14:42 +0100, Jörn Engel wrote:
> On Thu, 26 November 2009 15:02:54 +0200, Maxim Levitsky wrote:
> >
> > This one I have, and there is a brief description of the CIS format,
> > which seems to indicate that its contents are predefined.
>
> That is my understanding, yes. Essentially an xD card is just nand
> flash in cheap packaging with the first block filled by CIS/IDI.
>
> > I am afraid not.
> >
> >
> > My plan is to create one 'meta' mtd driver for all XD controllers, and
> > plug in small drivers.
> >
> > The meta driver and small driver will share the ->priv structure.
> >
> > I need a way to pass the ID from mtd driver to FTL, and to userspace via
> > mtdchar.
>
> You can also add a ->priv field to struct xD_data. Or you can have it
> contain the mtd_info, and use container_of to access the xD information.
>
> But those are details. Feel free to write the code either way. We can
> sort out which method to use later.

Thanks, no more questions, I will publish code as soon as I write one.

Best regards,
Maxim Levitsky

>
> Jörn
>

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads