Legacy memstick support + FTL questions

Legacy memstick support + FTL questions

[Maxim Levitsky]

Hi,

Since my xD/SmartMedia support is done (will send small update
tomorrow), I am switching focus to MemStick conteroller.

Since I am a perfectionist (at lest still am...) I want to have support
for both MemStick and MemStick pro.

Alex, I see that your PRO support is in kernel, not legacy support
isn't. Why?

Legacy MemSticks also are barebone like XD and thus need an FTL.
However, they don't have NAND interface.

My current goal is to take your ms_block.c, understand it, port to
latest kernel, and attempt a merge.

Its also possible to do the same I did with XD, write an MTD driver and
another FTL.

Since legacy memsticks are rare. I would like not to write mtd driver.

Also, any information, about memsticks is welcome. It would help me a
lot.

I assume that both Memstick, and Memstick Duo are similiar on hardware
level, (both bare flash).

Same for, Memstick PRO and MemStick PRO Duo.

Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> 
> Alex, I see that your PRO support is in kernel, not legacy
> support
> isn't. Why?

I had no time to finish debugging it on two controllers I was trying to
cover in the same time (TI and Jmicron).

> 
> Legacy MemSticks also are barebone like XD and thus need an
> FTL.
> However, they don't have NAND interface.
> 

Legacy memorysticks are sort-of barebone. In general, they can be seen as
MTD targets if you take into account that their oob field is actually a
register, not a directly accessible memory.



      __________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> 
> 
> I would like to know more about the registers.
> 
> 
> struct ms_status_register {
>     unsigned char reserved;
>     unsigned char interrupt;

* command can not be executed
> #define MEMSTICK_INT_CMDNAK 0x01

* MS IO stuff. Probably superseded by Pro IO protocol.
> #define MEMSTICK_INT_IOREQ  0x08
> #define MEMSTICK_INT_IOBREQ 0x10

* card is ready for data transfer (actual read/write block data)
> #define MEMSTICK_INT_BREQ   0x20

* some error occured
> #define MEMSTICK_INT_ERR    0x40

* command completed (either successfully or erroneously)
> #define MEMSTICK_INT_CED    0x80
> 
>     unsigned char status0;

* media is write protected
> #define MEMSTICK_STATUS0_WP  0x01

* media is sleeping (not very useful, as far as I can see)
> #define MEMSTICK_STATUS0_SL  0x02

* media buffer full (used when reading)
> #define MEMSTICK_STATUS0_BF  0x10

* media buffer empty (used when writing)
> #define MEMSTICK_STATUS0_BE  0x20

* flash busy
> #define MEMSTICK_STATUS0_FB0 0x40

* media busy (applies to built-in controller)
> #define MEMSTICK_STATUS0_MB  0x80
> 
>     unsigned char status1;


* uncorrectable flag error
> #define MEMSTICK_STATUS1_UCFG 0x01

* flag error (applies to "overwrite flag" field in extra data)
> #define MEMSTICK_STATUS1_FGER 0x02

* uncorrectable extra data error
> #define MEMSTICK_STATUS1_UCEX 0x04

* extra data (oob) error
> #define MEMSTICK_STATUS1_EXER 0x08

* uncorrectable data error (single bit errors are correctable)
> #define MEMSTICK_STATUS1_UCDT 0x10

* data error
> #define MEMSTICK_STATUS1_DTER 0x20

* flash busy (if media is busy, FB1 is not set, but FB0 is, the stick is
in invalid state)
> #define MEMSTICK_STATUS1_FB1  0x40

* media busy (same meaning as in status0)
> #define MEMSTICK_STATUS1_MB   0x80
> } __attribute__((packed));
> 
> Could you explain meaning of these flags?
> I understand some but not all.

> 
> Hardware register #16 (on my reader) seems to hold some
> status flags as well,
> It is interesting that there are many status flags, and
> they don't seem
> to fit nether jmicron nor TI flag register
> This register is polled to wait after an TPC, but several
> different bits are polled
> I thought that there is a relation between it and memstick
> status register.

It is quite possible. Some controllers will automatically retrieve an
"interrupt" field from the status register on each media access (in fact,
this behavior is mandated in parallel mode). Check if the bits fit "inter-
rupt" register bits.

> 
> struct ms_id_register {
>     unsigned char type;
>     unsigned char if_mode;
>     unsigned char category;
>     unsigned char class;
> } __attribute__((packed));
> 
> This register set is used to determine all kinds of
> things,
> could you explain its meaning?

This is an informal media id register. The mess you can see with its field
values is caused purely by Sony's inability to make its mind.
You can use it to differentiate between legacy, Pro and IO devices, but
that's roughly it.

> 
> 
> struct ms_param_register {
>     unsigned char system;

* 0 - serial, 1 - parallel mode
> #define MEMSTICK_SYS_PAM  0x08

* always 1 on legacy sticks
> #define MEMSTICK_SYS_BAMD 0x80

> These correspond to parallel and serial modes, right?
> There seems to be a large dance around switching these
> modes.
> You seem to mention 8 bit serial mode. How that could be
> possible?
> 

MS Pro HG sticks have 8bit capability as well as extended address space.
Each of the data pads on such sticks is split in two.

* physical block address 
>     unsigned char block_address[3];

* block access mode modifier
>     unsigned char cp;

* read/write data + extra data and autoincrement page address pointer
> #define MEMSTICK_CP_BLOCK     0x00

* read/write data + extra data and stay at the same page
> #define MEMSTICK_CP_PAGE      0x20

* read/write extra data only and stay at the same page
> #define MEMSTICK_CP_EXTRA     0x40

* read/write flag area and stay at the same page
> #define MEMSTICK_CP_OVERWRITE 0x80
> I have rough idea what that means, but an explanation won't
> hurt.
> Especially MEMSTICK_CP_OVERWRITE

The idea is that "overwrite flag" field in the extra data area can be
accessed separately, has its own error correction logic and otherwise
behaves as a separate entity (it even has dedicated bits in the status1
register). This field is used by software to store advisory information
and to aid recovery from interrupted flash operations.

* page address within block
>     unsigned char page_address;
> } __attribute__((packed));
> 
> 
> struct ms_extra_data_register {
>     unsigned char  overwrite_flag;

* 1 - block is stable, 0 - block is being updated
This bit can be reset on blocks which are scheduled for relocation/update.
If operation in question is abruptly terminated, information in this bit
should assist in subsequent restoration of media's logical integrity.
> #define MEMSTICK_OVERWRITE_UDST  0x10

* 3 - page is ok, 2/1 - page should not be accessed, 0 - page can be
accessed, but its data integrity can not be assured
> #define MEMSTICK_OVERWRITE_PGST1 0x20
> #define MEMSTICK_OVERWRITE_PGST0 0x40

* 1 - block is ok, 0 - block should not be accessed
> #define MEMSTICK_OVERWRITE_BKST  0x80
> 

* This register does not seem to be very useful. It is used to specify
that page in question has special meaning, which mostly applies to DRM
implementations (superseded by MS Pro) or severely RAM restricted systems.
>     unsigned char  management_flag;

* page is used for system purposes (?)
> #define MEMSTICK_MANAGEMENT_SYSFLG 0x04

* page is used to store temporary physical to logical mapping table
> #define MEMSTICK_MANAGEMENT_ATFLG  0x08

* DRM crap
> #define MEMSTICK_MANAGEMENT_SCMS1  0x10
> #define MEMSTICK_MANAGEMENT_SCMS0  0x20
> 

* logical address of the block (must obey zoning restrictions)
Each zone has 512 physical blocks.
The very first zone is only allowed 494 logical blocks, all other have
496 logical blocks. The rest of the physical blocks in each zone are used
as spares and must be reused within the zone boundaries.
>     unsigned short logical_address;
> } __attribute__((packed));
> 
> Same here, mangement flag seems to be used often by
> driver.

Management flag should not be used at all. The only possible use for it
(apart from DRM) is to mark volatile pages which can be used to store the
block look-up table. If there's enough RAM, no such tricks are necessary.
Default value for the unused flags is 0xff and it better be set.

On the other hand, overwrite flag should be used quite extensively.


> 
> 
> struct ms_register {
>     struct ms_status_register 
>    status;
>     struct ms_id_register   
>      id;
>     unsigned char       
>          reserved0[8];
>     struct ms_param_register   
>   param;
>     struct ms_extra_data_register
> extra_data;
>     unsigned char       
>          reserved1[2]; /* pad
> to word boundary */
> }
> I guess that first two fields of ms_extra_data_register
> should belong to 
> ms_param_register, for alignment.

No. They are separate hardware registers on the media side, and the
offsets are like this.

> Also, I don't get why status register has so many flags.
> As I understand it, TPCs are send in both directions, and
> nothing more.
> There are no dedicated lines, or something like that.

TPC means "transport protocol command" and it is only send from host to
media. Generally speaking, the whole thing works like this (each point
is a TPC):

1. Host selects media register access window.
2. Host modifies media register values.
3. Host invokes media command.
4. Host reads media registers.
5. Host moves data around.
6. Lather, rinse, repeat.

> 
> So status should be a content of the answer TPC or
> something like that.

It is not.

> 
> 
> I wish I had the memstick spec (original not pro)
> 

There's an email address on Sony's website.



      __________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Sun, 2010-02-14 at 07:06 -0800, Alex Dubov wrote: 
> > 
> > 
> > I would like to know more about the registers.
> > 
> > 
> > struct ms_status_register {
> >     unsigned char reserved;
> >     unsigned char interrupt;
> 
> * command can not be executed
> > #define MEMSTICK_INT_CMDNAK 0x01
> 
> * MS IO stuff. Probably superseded by Pro IO protocol.
> > #define MEMSTICK_INT_IOREQ  0x08
> > #define MEMSTICK_INT_IOBREQ 0x10
> 
> * card is ready for data transfer (actual read/write block data)
> > #define MEMSTICK_INT_BREQ   0x20
> 
> * some error occured
> > #define MEMSTICK_INT_ERR    0x40
> 
> * command completed (either successfully or erroneously)
> > #define MEMSTICK_INT_CED    0x80
> > 
> >     unsigned char status0;
> 
> * media is write protected
> > #define MEMSTICK_STATUS0_WP  0x01
> 
> * media is sleeping (not very useful, as far as I can see)
> > #define MEMSTICK_STATUS0_SL  0x02
> 
> * media buffer full (used when reading)
> > #define MEMSTICK_STATUS0_BF  0x10
> 
> * media buffer empty (used when writing)
> > #define MEMSTICK_STATUS0_BE  0x20
> 
> * flash busy
> > #define MEMSTICK_STATUS0_FB0 0x40
> 
> * media busy (applies to built-in controller)
> > #define MEMSTICK_STATUS0_MB  0x80
> > 
> >     unsigned char status1;
> 
> 
> * uncorrectable flag error
> > #define MEMSTICK_STATUS1_UCFG 0x01
> 
> * flag error (applies to "overwrite flag" field in extra data)
> > #define MEMSTICK_STATUS1_FGER 0x02
> 
> * uncorrectable extra data error
> > #define MEMSTICK_STATUS1_UCEX 0x04
> 
> * extra data (oob) error
> > #define MEMSTICK_STATUS1_EXER 0x08
> 
> * uncorrectable data error (single bit errors are correctable)
> > #define MEMSTICK_STATUS1_UCDT 0x10
> 
> * data error
> > #define MEMSTICK_STATUS1_DTER 0x20
> 
> * flash busy (if media is busy, FB1 is not set, but FB0 is, the stick is
> in invalid state)
> > #define MEMSTICK_STATUS1_FB1  0x40
> 
> * media busy (same meaning as in status0)
> > #define MEMSTICK_STATUS1_MB   0x80
> > } __attribute__((packed));
> > 
> > Could you explain meaning of these flags?
> > I understand some but not all.
> 
> > 
> > Hardware register #16 (on my reader) seems to hold some
> > status flags as well,
> > It is interesting that there are many status flags, and
> > they don't seem
> > to fit nether jmicron nor TI flag register
> > This register is polled to wait after an TPC, but several
> > different bits are polled
> > I thought that there is a relation between it and memstick
> > status register.
> 
> It is quite possible. Some controllers will automatically retrieve an
> "interrupt" field from the status register on each media access (in fact,
> this behavior is mandated in parallel mode). Check if the bits fit "inter-
> rupt" register bits.
Doesn't seem to map to anything.




0x10 is polled on register writes
0x20 is polled on command writes, and then 0x10 is polled
0x50 (0x40 | 0x10) if polled after MS_TPC_GET_INT and only it

0x03 is mask for error detection, if found in any of above polls, error
out.

The above was for register #19 (0xXX000000) 

after the MS_TPC_READ_LONG_DATA, 0x40 is polled, and register #18 is
polled for 0x20 clear. These are all bits that are accessed.

You try to tell me that controller itself issues TPCs, reads their
responses, and puts that in registers, right? This is very interesting.

Bus is half duplex, and there is a line that indicates who sends data.

I currently understand that host sends an TPC, then card sends a
response. Is it another TPC?




> 
> > 
> > struct ms_id_register {
> >     unsigned char type;
> >     unsigned char if_mode;
> >     unsigned char category;
> >     unsigned char class;
> > } __attribute__((packed));
> > 
> > This register set is used to determine all kinds of
> > things,
> > could you explain its meaning?
> 
> This is an informal media id register. The mess you can see with its field
> values is caused purely by Sony's inability to make its mind.
> You can use it to differentiate between legacy, Pro and IO devices, but
> that's roughly it.
> 
> > 
> > 
> > struct ms_param_register {
> >     unsigned char system;
> 
> * 0 - serial, 1 - parallel mode
> > #define MEMSTICK_SYS_PAM  0x08
> 
> * always 1 on legacy sticks
> > #define MEMSTICK_SYS_BAMD 0x80
> 
> > These correspond to parallel and serial modes, right?
> > There seems to be a large dance around switching these
> > modes.
> > You seem to mention 8 bit serial mode. How that could be
> > possible?
> > 
> 
> MS Pro HG sticks have 8bit capability as well as extended address space.
> Each of the data pads on such sticks is split in two.
> 
> * physical block address 
> >     unsigned char block_address[3];
> 
> * block access mode modifier
> >     unsigned char cp;
> 
> * read/write data + extra data and autoincrement page address pointer
> > #define MEMSTICK_CP_BLOCK     0x00
> 
> * read/write data + extra data and stay at the same page
> > #define MEMSTICK_CP_PAGE      0x20
> 
> * read/write extra data only and stay at the same page
> > #define MEMSTICK_CP_EXTRA     0x40
> 
> * read/write flag area and stay at the same page
> > #define MEMSTICK_CP_OVERWRITE 0x80
> > I have rough idea what that means, but an explanation won't
> > hurt.
> > Especially MEMSTICK_CP_OVERWRITE
> 
> The idea is that "overwrite flag" field in the extra data area can be
> accessed separately, has its own error correction logic and otherwise
> behaves as a separate entity (it even has dedicated bits in the status1
> register). This field is used by software to store advisory information
> and to aid recovery from interrupted flash operations.
> 
> * page address within block
> >     unsigned char page_address;
> > } __attribute__((packed));
> > 
> > 
> > struct ms_extra_data_register {
> >     unsigned char  overwrite_flag;
> 
> * 1 - block is stable, 0 - block is being updated
> This bit can be reset on blocks which are scheduled for relocation/update.
> If operation in question is abruptly terminated, information in this bit
> should assist in subsequent restoration of media's logical integrity.
> > #define MEMSTICK_OVERWRITE_UDST  0x10
> 
> * 3 - page is ok, 2/1 - page should not be accessed, 0 - page can be
> accessed, but its data integrity can not be assured
> > #define MEMSTICK_OVERWRITE_PGST1 0x20
> > #define MEMSTICK_OVERWRITE_PGST0 0x40
> 
> * 1 - block is ok, 0 - block should not be accessed
> > #define MEMSTICK_OVERWRITE_BKST  0x80
> > 
> 
> * This register does not seem to be very useful. It is used to specify
> that page in question has special meaning, which mostly applies to DRM
> implementations (superseded by MS Pro) or severely RAM restricted systems.
> >     unsigned char  management_flag;
> 
> * page is used for system purposes (?)
> > #define MEMSTICK_MANAGEMENT_SYSFLG 0x04
> 
> * page is used to store temporary physical to logical mapping table
> > #define MEMSTICK_MANAGEMENT_ATFLG  0x08
> 
> * DRM crap
> > #define MEMSTICK_MANAGEMENT_SCMS1  0x10
> > #define MEMSTICK_MANAGEMENT_SCMS0  0x20
> > 
> 
> * logical address of the block (must obey zoning restrictions)
> Each zone has 512 physical blocks.
> The very first zone is only allowed 494 logical blocks, all other have
> 496 logical blocks. The rest of the physical blocks in each zone are used
> as spares and must be reused within the zone boundaries.
> >     unsigned short logical_address;
> > } __attribute__((packed));
> > 
> > Same here, mangement flag seems to be used often by
> > driver.
> 
> Management flag should not be used at all. The only possible use for it
> (apart from DRM) is to mark volatile pages which can be used to store the
> block look-up table. If there's enough RAM, no such tricks are necessary.
> Default value for the unused flags is 0xff and it better be set.
> 
> On the other hand, overwrite flag should be used quite extensively.
> 
> 
> > 
> > 
> > struct ms_register {
> >     struct ms_status_register 
> >    status;
> >     struct ms_id_register   
> >      id;
> >     unsigned char       
> >          reserved0[8];
> >     struct ms_param_register   
> >   param;
> >     struct ms_extra_data_register
> > extra_data;
> >     unsigned char       
> >          reserved1[2]; /* pad
> > to word boundary */
> > }
> > I guess that first two fields of ms_extra_data_register
> > should belong to 
> > ms_param_register, for alignment.
> 
> No. They are separate hardware registers on the media side, and the
> offsets are like this.
> 
> > Also, I don't get why status register has so many flags.
> > As I understand it, TPCs are send in both directions, and
> > nothing more.
> > There are no dedicated lines, or something like that.
> 
> TPC means "transport protocol command" and it is only send from host to
> media. Generally speaking, the whole thing works like this (each point
> is a TPC):
> 
> 1. Host selects media register access window.
> 2. Host modifies media register values.
> 3. Host invokes media command.
> 4. Host reads media registers.
> 5. Host moves data around.
> 6. Lather, rinse, repeat.

> 
> > 
> > So status should be a content of the answer TPC or
> > something like that.
> 
> It is not.
> 
> > 
> > 
> > I wish I had the memstick spec (original not pro)
> > 
> 
> There's an email address on Sony's website.
And the chances they give me the specs without NDA and a lump of money
are higher that winning a lottery?

It is very sad to see these proprietary devices and protocols.

I actually did pay for all the licence costs, because I did buy the
device, and a driver....


Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> > 
> > It is quite possible. Some controllers will
> automatically retrieve an
> > "interrupt" field from the status register on each
> media access (in fact,
> > this behavior is mandated in parallel mode). Check if
> the bits fit "inter-
> > rupt" register bits.
> Doesn't seem to map to anything.
> 
> 
> 
> 
> 0x10 is polled on register writes
> 0x20 is polled on command writes, and then 0x10 is polled
> 0x50 (0x40 | 0x10) if polled after MS_TPC_GET_INT and only
> it
> 
> 0x03 is mask for error detection, if found in any of above
> polls, error
> out.
> 
> The above was for register #19 (0xXX000000) 

So, it's probably an implementation specific register.
There's no common standard for MS interfaces.

> 
> after the MS_TPC_READ_LONG_DATA, 0x40 is polled, and
> register #18 is
> polled for 0x20 clear. These are all bits that are
> accessed.
> 
> You try to tell me that controller itself issues TPCs,
> reads their
> responses, and puts that in registers, right? This is very
> interesting.
> 
> Bus is half duplex, and there is a line that indicates who
> sends data.
> 
> I currently understand that host sends an TPC, then card
> sends a
> response. Is it another TPC?


Not at all.
I answered this already.
See below.

> > > As I understand it, TPCs are send in both
> directions, and
> > > nothing more.
> > > There are no dedicated lines, or something like
> that.
> > 
> > TPC means "transport protocol command" and it is only
> send from host to
> > media. Generally speaking, the whole thing works like
> this (each point
> > is a TPC):
> > 
> > 1. Host selects media register access window.
> > 2. Host modifies media register values.
> > 3. Host invokes media command.
> > 4. Host reads media registers.
> > 5. Host moves data around.
> > 6. Lather, rinse, repeat.
> 
> > 
> > > 
> > > So status should be a content of the answer TPC
> or
> > > something like that.
> > 
> > It is not.
> > 

Legacy MS protocol uses 3 meaningful lines: SCLK (clock), SDIO (data/
command IO) and BS (bus state lane). There may be additional 3 or 7
DIO lines but they are only used for bulk data transfer.

There are 4 hw states:

1) BS at low - media is idle
2) BS goes to high - TPC is clocked in on SDIO
3) BS goes to low - host waits for level change on SDIO
4) BS goes to high - data can be clocked in/out on all data lines
5) BS goes to low again -> same as 1 (idle)

Media can not initiate anything and can not send anything to host.
Host is responsible to query the media state as necessary.

> > > I wish I had the memstick spec (original not
> pro)
> > > 
> > 
> > There's an email address on Sony's website.
> And the chances they give me the specs without NDA and a
> lump of money
> are higher that winning a lottery?
> 

They will give you the spec for nothing if you're a certified sony
developer. How do you become one is different question, but it is not
money dependent.



      __________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Tue, 2010-02-16 at 06:15 -0800, Alex Dubov wrote: 
> > > 
> > > It is quite possible. Some controllers will
> > automatically retrieve an
> > > "interrupt" field from the status register on each
> > media access (in fact,
> > > this behavior is mandated in parallel mode). Check if
> > the bits fit "inter-
> > > rupt" register bits.
> > Doesn't seem to map to anything.
> > 
> > 
> > 
> > 
> > 0x10 is polled on register writes
> > 0x20 is polled on command writes, and then 0x10 is polled
> > 0x50 (0x40 | 0x10) if polled after MS_TPC_GET_INT and only
> > it
> > 
> > 0x03 is mask for error detection, if found in any of above
> > polls, error
> > out.
> > 
> > The above was for register #19 (0xXX000000) 
> 
> So, it's probably an implementation specific register.
> There's no common standard for MS interfaces.
I think I now more or less understand what this reg means.

> 
> > 
> > after the MS_TPC_READ_LONG_DATA, 0x40 is polled, and
> > register #18 is
> > polled for 0x20 clear. These are all bits that are
> > accessed.
> > 
> > You try to tell me that controller itself issues TPCs,
> > reads their
> > responses, and puts that in registers, right? This is very
> > interesting.
> > 
> > Bus is half duplex, and there is a line that indicates who
> > sends data.
> > 
> > I currently understand that host sends an TPC, then card
> > sends a
> > response. Is it another TPC?
> 
> 
> Not at all.
> I answered this already.
> See below.
I  mean when controller reads the 'int status' it does send a TPC?
(I am sure that it does)

However mine can't do that and int status is read normally (yay...)


> 
> > > > As I understand it, TPCs are send in both
> > directions, and
> > > > nothing more.
> > > > There are no dedicated lines, or something like
> > that.
> > > 
> > > TPC means "transport protocol command" and it is only
> > send from host to
> > > media. Generally speaking, the whole thing works like
> > this (each point
> > > is a TPC):
> > > 
> > > 1. Host selects media register access window.
> > > 2. Host modifies media register values.
> > > 3. Host invokes media command.
> > > 4. Host reads media registers.
> > > 5. Host moves data around.
> > > 6. Lather, rinse, repeat.
> > 
> > > 
> > > > 
> > > > So status should be a content of the answer TPC
> > or
> > > > something like that.
> > > 
> > > It is not.
> > > 
> 
> Legacy MS protocol uses 3 meaningful lines: SCLK (clock), SDIO (data/
> command IO) and BS (bus state lane). There may be additional 3 or 7
> DIO lines but they are only used for bulk data transfer.
> 
> There are 4 hw states:
> 
> 1) BS at low - media is idle
> 2) BS goes to high - TPC is clocked in on SDIO
> 3) BS goes to low - host waits for level change on SDIO
> 4) BS goes to high - data can be clocked in/out on all data lines
> 5) BS goes to low again -> same as 1 (idle)
Thanks a lot for this explanation. Much better that in free ms spec.


> 
> Media can not initiate anything and can not send anything to host.
> Host is responsible to query the media state as necessary.
Now I understand. Just like USB I see.


> 
> > > > I wish I had the memstick spec (original not
> > pro)
> > > > 
> > > 
> > > There's an email address on Sony's website.
> > And the chances they give me the specs without NDA and a
> > lump of money
> > are higher that winning a lottery?
> > 
> 
> They will give you the spec for nothing if you're a certified sony
> developer. How do you become one is different question, but it is not
> money dependent.
I don't think this is easy, but maybe I give it a try.
Now I more or less understand what is going on.


Thank you very much!

Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> I  mean when controller reads the 'int status' it does
> send a TPC?
> (I am sure that it does)
> 
> However mine can't do that and int status is read normally
> (yay...)
> 

There are two things to know:
1. In serial mode, some controllers issue GET_INT TPC automatically
after each command, but only if certain configuration bit is set.

2. In parallel mode, the meaningful bits of the interrupt register
are exposed on the DIO pins of the media at the end of command execution
and can be latched by the controller (this is a suggested behavior).

If you want to write a generic legacy MS support, you must take into
account that this behavior is not there for granted.

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Tue, 2010-02-16 at 18:26 -0800, Alex Dubov wrote: 
> > I  mean when controller reads the 'int status' it does
> > send a TPC?
> > (I am sure that it does)
> > 
> > However mine can't do that and int status is read normally
> > (yay...)
> > 
> 
> There are two things to know:
> 1. In serial mode, some controllers issue GET_INT TPC automatically
> after each command, but only if certain configuration bit is set.
> 
> 2. In parallel mode, the meaningful bits of the interrupt register
> are exposed on the DIO pins of the media at the end of command execution
> and can be latched by the controller (this is a suggested behavior).
> 
> If you want to write a generic legacy MS support, you must take into
> account that this behavior is not there for granted.
> 

Thank you very very much.
This clears this issue for good.

Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Thu, 2010-02-18 at 01:39 +0200, Maxim Levitsky wrote: 
> On Tue, 2010-02-16 at 18:26 -0800, Alex Dubov wrote: 
> > > I  mean when controller reads the 'int status' it does
> > > send a TPC?
> > > (I am sure that it does)
> > > 
> > > However mine can't do that and int status is read normally
> > > (yay...)
> > > 
> > 
> > There are two things to know:
> > 1. In serial mode, some controllers issue GET_INT TPC automatically
> > after each command, but only if certain configuration bit is set.
> > 
> > 2. In parallel mode, the meaningful bits of the interrupt register
> > are exposed on the DIO pins of the media at the end of command execution
> > and can be latched by the controller (this is a suggested behavior).
> > 
> > If you want to write a generic legacy MS support, you must take into
> > account that this behavior is not there for granted.
> > 
> 
> Thank you very very much.
> This clears this issue for good.
In fact I found out that these 'meaningful bits of the interrupt
register' are indeed exposed as a part of reg #16, but at different
place.

Alex, could you explain how a single TPC is performed?

I currently first send MS_TPC_SET_RW_REG_ADRS, and then MS_TPC_READ_REG

When I send the TPC I specify both the tpc number and its len. Is the
len transmitted?

I see that if I set addr.r_length != MS_TPC_READ_REG len, I get errors
in reg #16, but different errors depending if i set it lower or higher.

Currently I think that a level change on the #SDIO is the signal for
host to start reading, but who sets the #BS to high? Host or card.

Does card signal end of transmission?

Also it seems that if I write to 'param' register, I can't read it back
(maybe I do something wrong). Is this register write only?

Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> 
> Alex, could you explain how a single TPC is performed?
> 
> I currently first send MS_TPC_SET_RW_REG_ADRS, and then
> MS_TPC_READ_REG
> 
> When I send the TPC I specify both the tpc number and its
> len. Is the
> len transmitted?

Of course, it is. How otherwise media would know how many bits to sample
in?

> 
> I see that if I set addr.r_length != MS_TPC_READ_REG len, I
> get errors
> in reg #16, but different errors depending if i set it
> lower or higher.

This is an undefined behavior. You're confusing the state machine on the
media side. By the way, left over bytes from the incorrectly ordered
or formatted TPC can spill into block data buffer (this will cause an
apparent data corruption - I've seen this happen).

> 
> Currently I think that a level change on the #SDIO is the
> signal for
> host to start reading, but who sets the #BS to high? Host
> or card.

BS line is always mastered by host.

> 
> Does card signal end of transmission?
> 

Yes, on a data line (there's CRC as well, which must be handled by the host
transparently).

> Also it seems that if I write to 'param' register, I can't
> read it back
> (maybe I do something wrong). Is this register write only?
> 

There are no write only registers in the MS spec. Moreover, you need to 
read the param register if you're doing multi-page transfer (page address
will be updated during the transfer to point to the last accessed page).

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Mon, 2010-02-22 at 06:04 -0800, Alex Dubov wrote: 
> > 
> > Alex, could you explain how a single TPC is performed?
> > 
> > I currently first send MS_TPC_SET_RW_REG_ADRS, and then
> > MS_TPC_READ_REG
> > 
> > When I send the TPC I specify both the tpc number and its
> > len. Is the
> > len transmitted?
> 
> Of course, it is. How otherwise media would know how many bits to sample
> in?
By watching the #BS?
Every clock cycle media reads 1 or 4 bits, when #BS goes low it stops
reading...
Why otherwise one would need the #BS line?


Thanks for explanation.




> 
> > 
> > I see that if I set addr.r_length != MS_TPC_READ_REG len, I
> > get errors
> > in reg #16, but different errors depending if i set it
> > lower or higher.
> 
> This is an undefined behavior. You're confusing the state machine on the
> media side. By the way, left over bytes from the incorrectly ordered
> or formatted TPC can spill into block data buffer (this will cause an
> apparent data corruption - I've seen this happen).
I know that it is undefined, but I try to understand the meaning of
status flags, thats why I try it. Now it is much clearer to me.

Just one more question, when the host say reads the data buffer (512
bytes), it does so in one run, or it reads it in packets, or it reads it
in 8 byte packets, then  waits for some condition (#SDIO maybe)?

> 
> > 
> > Currently I think that a level change on the #SDIO is the
> > signal for
> > host to start reading, but who sets the #BS to high? Host
> > or card.
> 
> BS line is always mastered by host.
Thanks for explanation.

> 
> > 
> > Does card signal end of transmission?
> > 
> 
> Yes, on a data line (there's CRC as well, which must be handled by the host
> transparently).
I have seen on some datasheet that crc is involved. It is handled
transparently.


> 
> > Also it seems that if I write to 'param' register, I can't
> > read it back
> > (maybe I do something wrong). Is this register write only?
> > 
> 
> There are no write only registers in the MS spec. Moreover, you need to 
> read the param register if you're doing multi-page transfer (page address
> will be updated during the transfer to point to the last accessed page).
Very interesting, probably I do that wrong then.


Thanks a lot,
Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> > > Alex, could you explain how a single TPC is
> performed?
> > > 
> > > I currently first send MS_TPC_SET_RW_REG_ADRS,
> and then
> > > MS_TPC_READ_REG
> > > 
> > > When I send the TPC I specify both the tpc number
> and its
> > > len. Is the
> > > len transmitted?
> > 
> > Of course, it is. How otherwise media would know how
> many bits to sample
> > in?
> By watching the #BS?
> Every clock cycle media reads 1 or 4 bits, when #BS goes
> low it stops
> reading...
> Why otherwise one would need the #BS line?

It is so and not so.
It appears, length is not transmitted as part of actual TPC payload.
However, number of data payload bytes is always determined by the media
register values. If this condition is not maintained all sorts of bad
things may happen.



      __________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

Re: Legacy memstick support + FTL questions

[Maxim Levitsky]

On Tue, 2010-02-23 at 01:01 -0800, Alex Dubov wrote: 
> > > > Alex, could you explain how a single TPC is
> > performed?
> > > > 
> > > > I currently first send MS_TPC_SET_RW_REG_ADRS,
> > and then
> > > > MS_TPC_READ_REG
> > > > 
> > > > When I send the TPC I specify both the tpc number
> > and its
> > > > len. Is the
> > > > len transmitted?
> > > 
> > > Of course, it is. How otherwise media would know how
> > many bits to sample
> > > in?
> > By watching the #BS?
> > Every clock cycle media reads 1 or 4 bits, when #BS goes
> > low it stops
> > reading...
> > Why otherwise one would need the #BS line?
> 
> It is so and not so.
> It appears, length is not transmitted as part of actual TPC payload.
> However, number of data payload bytes is always determined by the media
> register values. If this condition is not maintained all sorts of bad
> things may happen.
It is finally clear to me.
While googling I found that in fact the CRC is transmitted after data in
both directions
(ieeexplore.ieee.org/iel5/40/18745/00865865.pdf?arnumber=865865)

So, if host transmits too much or little that media expects, it will
treat wrong bytes as the CRC, and vise versa. thus both ends have to
know exactly how many bytes to expect.

One last thing that I probably will accepts as is. It appears that card
has some special way to tell the host that command if complete
regardless or serial/parallel mode, since there is special hw register
(bit 29 of register 16) that is polled only after commands, and I
verified that it takes significant time to turn that bit on, thus I
suspect that card can somehow inform the host that it not only accepted
the TPC, but actually done with the command.

Other that that, I have no more questions, thanks you again very much.

Best regards,
Maxim Levitsky

Re: Legacy memstick support + FTL questions

[Alex Dubov]

> > 
> > It is so and not so.
> > It appears, length is not transmitted as part of
> actual TPC payload.
> > However, number of data payload bytes is always
> determined by the media
> > register values. If this condition is not maintained
> all sorts of bad
> > things may happen.
> It is finally clear to me.
> While googling I found that in fact the CRC is transmitted
> after data in
> both directions
> (ieeexplore.ieee.org/iel5/40/18745/00865865.pdf?arnumber=865865)
> 
> So, if host transmits too much or little that media
> expects, it will
> treat wrong bytes as the CRC, and vise versa. thus both
> ends have to
> know exactly how many bytes to expect.

Yes, the CRC is there as well. 

> 
> One last thing that I probably will accepts as is. It
> appears that card
> has some special way to tell the host that command if
> complete
> regardless or serial/parallel mode, since there is special
> hw register
> (bit 29 of register 16) that is polled only after commands,
> and I
> verified that it takes significant time to turn that bit
> on, thus I
> suspect that card can somehow inform the host that it not
> only accepted
> the TPC, but actually done with the command.
> 

There are no any special modes.
It's just sampling the SDIO line at the right time.

This is, however, should not be of any importance, because a proper
driver should always establish the reason for the failure. It means
you better read the interrupt register and upon checking it, get status
register values as well.

TI adapters, for instance, do not support all these tricks (which are
mostly helpful when dealing with MSPro, with its much refined and more
sensible command set). On the other hand, they are the best adapters around
and closely follow Sony's reference design (or, quite probably, reference
design was made by TI in the first place).