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