MPIO Project
Users
Developers
Misc.
USB Protocol
Documentation of the USB protocol used by the MPIO mp3 player series from digitalw@ys written by Markus Germeier. It is (as always ;-) slightly outdated.
This document gathers informations found in various places. Special thanks go to Yuji Touya and Daniel Beichl whos works were a great help to me.
Preface
The MPIO mp3 players from digitalw@ys are a series of solid state music players. They use the SmartMedia technology developed by Toshiba and Samsung. To understand the working of the mp3 player, one has to understand the functioning of the SmartMedia memory.
SmartMedia
SmartMedia cards are available from 1MB to 128MB chips. To keep this document as simple as possible, we will only consider cards from 16MB to 128MB.
SmartMedia(tm) is the trademark for the SSFDC "Solid State Floppy Disc Card which mean that data is logically stored as it would be on a common floppy disc or a small (<=128MB) hard disc drive. Data is split up into sectors and are grouped into cluster,
Data on the SmartMedia card is protected by an ECC "Error checking & correction" alogrithm. To each data sector (512 bytes) a "Spare Area" (16 bytes) is asigned. This area contains the ECC informations for this sector. Each sector is devided into two 256 bytes chunks. For every 256 bytes chunk, a 3 Byte ECC checksum is calculated and stored in the "Spare Area". see Format Introduction, page 16.
For the physical storage on a SmartMedia card, 32 sectors are grouped together as a block (32 * 512 bytes = 16KB). On a logical view of the SSFDC 32 sectors are grouped together as a cluster (32 * 512 bytes = 16KB). (see Format Introduction, page 6+7) Therefore logical clusters can be mapped one to one to physical blocks.
On every SmartMedia card we found all informations found on a "usual" floppy disc: Master Boot Sector, Partition Boot Sector, 2 *FAT, Root Directory (fixed to 256 entries), File area. ( Format Introduction, page 7)
To make the format a little more intersting, high density SmartMedia cards (32MB and above) have a "Zone-based block management". Which basically means that the physical blocks are not as continuing as there logical cluster counterparts. Every zone contains 1024 physical blocks which in turn only store 1000 logical clusters. While mapping logical clusters to physical blocks you have to take into account that there is a 24 block gap after 1000 blocks.
The physical structure of the SmartMedia memory type makes it necessary that every physical block is erased before it can rewritten!
FAT and directory
The structure of the FAT and root directory layout can be found elsewhere. I consider these usefull:
MPIO
The MPIO player series have an internal SmartMedia memory and most are capable of handling an external SmartMedia card. Two points make the support off the MPIO players difficult
- the internal memory may be devided into up to 4 chips (models with 1, 2 and 4 are known)
- the internal and external memory are treated totally different
The external memory is handled as one would it expect it from a SmartMedia card. (Read Master Boot Sector, Read Partition Boot Sector, calculate size and offsets of FAT, root directory, file area). e.g reading of a file:
- filename is looked up in root directory
- directory entry reveals logical start cluster
- repeat until all data from file is read:
- find physical block from logical cluster number and spare area block status informations
- reading of physical block
- check ECC informations and correct error if possible
- next cluster of this file can be looked up in the FAT
mapping logical cluster/blocks <-> physical blocks:
TODO
The internal memory setup is much simpler. There is no Master Boot Sector, or Partition Boot Sector. The "Spare Area" is used for storing the FAT informations. There is no ECC storing/checking. The root directory always starts at physical block/sector 0. [I'm unsure about the Zone-based management, but I don't believe it is used for intermal memory. -mager]
Fat layout in "spare area":
000010 : aa 06 00 02 ff ff 43 01 00 00 40 00 00 00 50 43 *......C...@...PC* 0x00: 0xaa start sector for file 0xee "simple" sector for file 0x01: index number of file 0x02-0x03: number of blocks in file 0x04-0x05: unknwon/unused 0x06: file type 0x07-0x0a: location of next block 0xffffffff: end of file 0x07: memory chip (1 or 2) 0x08-0x0a: start sector of next block 0x0b-0x0d: unknwon/unused 0x0e-00x0f: "PC" ID?/unknwon/unused
In the directory entry of the internal memory there are no references to cluster/sector numbers, but instead to the index number of the file within the FAT.
Beware: All values on the external memory card are stored little-endian , while the values in the internal FAT are big-endian.
MPIO Protocol
command codes:
0x01 Get_Version 0x02 Get_Block 0x03 Put_Sector 0x04 Del_Block 0x05 0x06 Get_Sector 0x07 Get_Spare_Area 0x08 Put_Block
return codes:
0xc0 ACK of Del_Block (0x04) 0xc1 Error Code from Del_Block (0x04) => block is defect
general command packet format: 64 Bytes:
0x01 byte command code 0x02 byte memory: 0x01 internal-1, 0x02 internal-2, 0x04 internal-3, (assumed, not confirmed yet) 0x08 internal-4 (assumed, not confirmed yet) 0x10 external 0x80 external on the MPIO-DMG series 0x03 0x00 always 0x00 ??? 0x04-0x06 bytes little endian adress of - physical sector - first sector of physical block 0x06 set to 0xff is memory chip is 32MB or less (sectors can be address with 2 bytes) 0x07 byte size of a data transfer for write operation (size in KB??, value is always 0x48 -> on block with spare area) * 0x00 padding 0x3b-0x3f string[5] "jykim"
Detailed MPIO command packets
Code 1: Get Version
0000: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d Answer: (example of DME-64, one internal chip, 128 SM card inserted) 0000: 4d 50 49 4f 2d 45 20 20 20 20 20 20 30 31 37 33 0010: 32 30 30 31 31 31 31 32 ec 76 00 00 00 00 00 00 0020: ec 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00-0x0a: String[11] Identification 0x0b-0x0f: char[4] Firmware Version %c%c.%c%c 0x10-0x13: String[4] Firmware Year 0x14-0x15: String[2] Firmware Month 0x16-0x17: String[2] Firmware Day 0x18-0x19: bytes[2] Internal Memory (1) (manufacturer ID / model ID) 0x1a-0x1b: bytes[2] Internal Memory (2) (manufacturer ID / model ID) 0x1c-0x1d: bytes[2] Internal Memory (3) (manufacturer ID / model ID) 0x1e-0x1f: bytes[2] Internal Memory (4) (manufacturer ID / model ID) 0x2x-0x2y: bytes[2] External Memory (manufacturer ID / model ID) (the exact location of this is model dependant)Meaning of the memory IDs can be found here: SmartMedia(tm) White Paper, page 7
Code 2: Get Block
0000: 02 xx 00 yy yy yy 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memory yyyyyy: start sector of physical block to readAnswer:
- Files are chunked into pieces of Blocks (16KB for SmartMedia 16-128MB)
- 1 Block are 32 sectors (a 512 bytes)
- after each block the "spare area" is sent
- whole last cluster is send back (e.g. File is padded to 16KB)
Code 3: Put Sector
0000: 03 xx 00 yy yy yy 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memory yyyyyy: address of physical sector to readSend:
- 512 Bytes sector
- +32 Bytes spare area for sector
Code 4: Del Block
0000: 04 xx 00 yy yy yy 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memory yyyyyy: start sector of physical block to erase answer Codes 0xc0 (everything OK) 0xc1 (block is defect)After a block is deleted it can be rewritten again. If this does not happen before a write, the written data will most likely get corrupted.
Code 6: Get Sector
0000: 06 xx 00 yy yy yy 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memory yyyyyy: address of physical sector to readAnswer:
- 512 Bytes sector
- +32 Bytes spare area for sector
Code 7: Get Spare Area
0000: 07 xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memoryAnswer:
- yy KB FAT (dependant of chip size xxMB -> xxKB) [sure?? -mager]
- chunked into transfers of 64 bytes
Code 8: Put Block
0000: 08 xx 00 yy yy yy ss 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 00 00 00 00 00 00 00 6a 79 6b 69 6d xx: memory yyyyyy: start sector of physical block to write ss: size of data transfer in KB (seems always to be 0x48 one block 0x4000 + "Spare Area" 0x0800)Data Transfer:
- Files are chunked into pieces of Blocks (16KB vor SmartMedia 16-128MB)
- 1 Block are 32 sectors (a 512 bytes)
- after each block the "spare area" is sent.
misc
Blocks per Medium 128MB 0x4000 64MB 0x2000 32MB 0x1000 16MB 0x0800 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Sector locations for certain sectors (fixed on external memory): CIS: 0x0020 (Card Information System) MBR: 0x0040 (Master Boot Sector) This one is *not* fixed as I previously assumed!!!