Request to SBC, SBC-2 from Fuji

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Tue Dec 17 23:40:03 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*

Hello SBC, SBC-2 people,

I would like to ask (request) 2 items to SBC on behalf of Mt.Fuji 5
members. Currently, we are discussing Enhanced Defect Reporting method for
Software Defect Management on CD/DVD-RW media in MMC4 and Fuji. Currently
we have PER (Post Error) bit to allow Recovered Error reporting for direct
access device. But we conclude that it is not sufficient to implement
Software Defect Management on CD/DVD-RW media.

Item 1: Allocate new 2 bits field (for EMCDR) at Byte 7, bit 1-0 of
Read/Write Error Recovery Parameters Mode Page.
Item 2: Allocate new 1 bit field (for streaming) at Byte 6, bit 7 of VERIFY
(10) Command.

-- Item 1 --
Enhanced Defect Reporting method for Software Defect Management consists of
2 systems.

1. Standard Playback model definition and 2 level error types
DM (Defect Management) supports re-writable media interchangeability
between devices. We define Standard Playback model that DM must keep
playability of the packet (a set of sectors). In case of DVD-RW, Standard
Playback model is ordinary DVD Player that has PI error correction - PO
erasure error correction and EDC error detection.
We define 2 levels of error, Type 1 error level and Type 2 error level.
Type 1 error level shows that the packet may cause EDC error by Standard
Playback model after 50 - 100 direct overwrite cycles. Type 2 error level
shows that the packet should cause EDC error by Standard Playback model,
but should not cause fatal error at reading by the writer device itself.
Usually writer device has additional error correction capability and can
accept worse error level packet.
Host software can detect correct information by those definitions and can
perform DM for interchangeability.

2. Flexible certification and error reporting control
We conclude that media certification and recovered error reporting shall be
controlled with more flexibility. For example, DVD Video playback software
can read recorded DVD-RW disc directly. They have UDF purser, then they do
not use installed file system on OS. If Read command reported Check
Condition for recovered error, DVD Video playback software can not work
well. So we define 4 level control state by EMCDR (Enhanced Media
Certification and Defect Report) field.

PER=0 and
EMCDR=0: Off mode, no media certification, no recovered error reporting.
EMCDR=1: polling mode, media certification On, no recovered error
reporting.
EMCDR=2: verify mode, media certification On, recovered error reporting on
Verify and Write&Verify.
EMCDR=3: read mode, media certification On, recovered error reporting on
Read, Verify and Write&Verify.
ASC/ASCQ of Recovered error for DM shall be 1/18/05 RECOMMEND REASINGMENT.
This is unified error code for DM.
- Off mode allows the highest reading speed to device. Usually DVD-RW
device supports high reading speed e.g. 6X CAV. But in such speed, device
can not perform correct media certification. For correct media
certification, low read speed similar to write speed is required.
- Polling mode allows no recovered error using. By Get Performance command
type 4 Defect Block Information, host software can retrieve defect block
information after Read, Verify command.

PER=1 and
EMCDR=0: legacy mode, media certification On, recovered error reporting on
any command
ASC/ASCQ of Recovered error for DM can be vender specific.
PER=1, EMCDR not 0: recovered error reporting on any command is allowed,
but ASC/ASCQ of Recovered error for DM shall be 1/18/05 RECOMMEND
REASINGMENT.

So we would like to ask Item 1 that allocate new EMCDR field at Byte 7, bit
1-0 of Read/Write Error Recovery Parameters Mode Page.

-- Item 2 --
MMC device supports streaming Read/Write by setting of streaming bit in
Read 12, Write 12. Some members pointed out that device behavior of Read 12
streaming=1 may be different with streaming=0. And to recover from fatal
error quickly (for example fatal error due to finger print), I proposed
another behavior when streaming bit is set to 1, for example short time out
length comparing with streaming=0.
Ordinary Read operation will take 7 - 10 sec time length when device
performed retry seek/read and was encountered fatal error. To find clear
place beyond finger print, 7 - 10 sec time length is too long. Therefor to
use Verify command onto Real time packet, streaming bit is required.

So we would like to ask Item 2 that allocate new streaming bit at Byte 6,
bit 7 of VERIFY (10) Command.

I will attend the next MMC WG at Portland. So if you have comment or
question, please visit MMC WG meeting. Also I welcome your comment via
T10/Fuji reflector.

Best regards,

Keiji Katata
PIONEER CORP.



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list