1、ANSI INCITS 325-1998 (R2003)(formerly ANSI NCITS 325-1998)for Information Technology Serial Bus Protocol 2 (SBP-2)ANSINCITS 325-1998American National Standardfor Information Technology Serial Bus Protocol 2 (SBP-2)SecretariatInformation Technology Industry CouncilApproved November 20, 1998 American
2、National Standards Institute, Inc.AbstractThis standard specifies a protocol for the transport of commands, data and status between devices con-nected by Serial Bus, a memory-mapped split-transaction bus defined by ANSI/IEEE 1394-1995, Ameri-can National Standard for a High Performance Serial Bus.Ap
3、proval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has bee
4、n reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted effort be madetowards their resolution.The use of American National
5、Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does
6、 not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpret
7、ations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to
8、 reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished byAmerican National Standards Institute, Inc.11 West 42nd Street,
9、New York, NY 10036Copyright 1999 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in
10、the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents that may be re-quired for the implementation of the standard disclose such patents to the publisher. However, nei-ther the developers nor the publisher have undertaken a patent search in order
11、 to identify which, ifany, patents may apply to this standard. As of the date of publication of this standard, followingcalls for the identification of patents that may be required for the implementation of the standard,notice of one or more such claims has been received. By publication of this stan
12、dard, no positionis taken with respect to the validity of this claim or of any rights in connection therewith. The knownpatent holder(s) has (have), however, filed a statement of willingness to grant a license underthese rights on reasonable and nondiscriminatory terms and conditions to applicants d
13、esiring to ob-tain such a license. Details may be obtained from the publisher. No further patent search is con-ducted by the developer or publisher in respect to any standard it processes. No representation ismade or implied that this is the only license that may be required to avoid infringement in
14、 the use ofthis standard.iContentsPageForeword v1 Scope and purpose. 11.1 Scope 11.2 Purpose 12 Normative references . 22.1 Approved references 22.2 References under development 23 Definitions and notation 33.1 Definitions. 33.1.1 Conformance 33.1.2 Glossary 33.1.3 Abbreviations 63.2 Notation 63.2.1
15、 Numeric values . 63.2.2 Bit, byte and quadlet ordering. 63.2.3 Register specifications 73.2.4 State machines . 94 Model (informative). 114.1 Unit architecture . 114.2 Logical units 114.3 Requests and responses 114.4 Data buffers 124.5 Target agents 144.6 Ordered and unordered execution 155 Data str
16、uctures . 165.1 Operation request blocks (ORBs) 175.1.1 Dummy ORB. 185.1.2 Command block ORBs. 185.1.3 Management ORBs 205.2 Page tables. 275.2.1 Unrestricted page tables. 285.2.2 Normalized page tables 285.3 Status block 295.3.1 Request status 315.3.2 Unsolicited device status 336 Control and statu
17、s registers 346.1 Core registers . 346.2 Serial Bus-dependent registers 346.3 MANAGEMENT_AGENT register. 356.4 Command block agent registers . 356.4.1 AGENT_STATE register. 366.4.2 AGENT_RESET register 376.4.3 ORB_POINTER register . 376.4.4 DOORBELL register . 386.4.5 UNSOLICITED_STATUS_ENABLE regis
18、ter 39iiPage7 Configuration ROM. 407.1 Power reset initialization . 407.2 Bus information block . 417.3 Root directory . 427.3.1 Module_Vendor_ID entry 427.3.2 Node_Capabilities entry 427.3.3 Unit_Directory entry 427.4 Unit directory. 437.4.1 Unit_Spec_ID entry. 437.4.2 Unit_SW_Version entry 437.4.3
19、 Command_Set_Spec_ID entry. 447.4.4 Command_Set entry. 447.4.5 Command_Set_Revision entry. 447.4.6 Firmware_Revision entry 457.4.7 Management_Agent entry 457.4.8 Unit_Characteristics entry. 457.4.9 Reconnect_Timeout entry. 467.4.10Logical_Unit_Directory entry. 467.4.11Logical_Unit_Number entry 467.4
20、.12Unit_Unique_ID entry . 477.5 Logical unit directory. 477.5.1 Command_Set_Spec_ID entry. 487.5.2 Command_Set entry. 487.5.3 Command_Set_Revision entry. 487.5.4 Logical_Unit_Number entry 487.6 Unit unique ID leaf 488 Access 508.1 Access protocols. 508.2 Login. 508.3 Reconnection 518.4 Logout. 529 C
21、ommand execution. 539.1 Requests and request lists . 539.1.1 Fetch agent initialization (informative) 539.1.2 Dynamic appends to request lists (informative) 549.1.3 Fetch agent use by the BIOS (informative). 559.1.4 Fetch agent state machine . 559.2 Data transfer. 589.3 Completion status. 589.4 Unso
22、licited status 5910 Task management 6010.1 Task sets 6010.2 Basic task management model. 6010.3 Error conditions. 6110.4 Task management requests . 6110.4.1Abort task 6110.4.2Abort task set 6210.4.3Logical unit reset. 6310.4.4Target reset 6310.5 Task management event matrix . 64iiiPageTables1 Data t
23、ransfer speeds. 202 Management request functions. 21F.1 SAM-2 Service responses. 83Figures1 Bit ordering within a byte. 72 Byte ordering within a quadlet. 73 Quadlet ordering within an octlet. 74 CSR specification example . 85 State machine example. 106 Linked list of ORBs. 127 Directly addressed da
24、ta buffer 138 Indirectly addressed data buffer (via page table) 139 Address pointer. 1610 ORB pointer 1611 ORB family tree. 1712 ORB format . 1713 Dummy ORB. 1814 Command block ORB . 1915 Management ORB 2116 Login ORB. 2217 Login response 2318 Query logins ORB . 2419 Query logins response format. 24
25、20 Reconnect ORB 2521 Logout ORB 2622 Task management ORB 2723 Page table element (unrestricted page table) . 2824 Page table element (when page_size equals four). 2825 Status block format . 3026 TRANSPORT FAILURE format for sbp_status. 3227 MANAGEMENT_AGENT format. 3528 AGENT_STATE format. 3629 AGE
26、NT_RESET format. 3730 ORB_POINTER format . 38ivPage31 DOORBELL format. 3932 UNSOLICITED_STATUS_ENABLE format 3933 Configuration ROM hierarchy . 4034 Bus information block format 4135 Module_Vendor_ID entry format. 4236 Node_Capabilities entry format 4237 Unit_Directory entry format. 4338 Unit_Spec_I
27、D entry format . 4339 Unit_SW_Version entry format . 4340 Command_Set_Spec_ID entry format 4441 Command_Set entry format 4442 Command_Set_Revision entry format 4443 Firmware_Revision entry format. 4544 Management_Agent entry format . 4545 Unit_Characteristics entry format . 4546 Reconnect_Timeout en
28、try format . 4647 Logical_Unit_Directory entry format . 4648 Logical_Unit_Number entry format. 4649 Unit_Unique_ID entry format 4750 Unit unique ID leaf format. 4851 Fetch agent initialization with a dummy ORB . 5452 Fetch agent state machine . 56B.1 SCSI command block ORB 67B.2 SCSI control byte 67
29、B.3 Status block format for SCSI sense data 68C.1 Set password ORB . 73D.1 Basic configuration ROM 75D.2 SCSI configuration ROM 77AnnexesA Minimum Serial Bus node capabilities 65B SCSI command and status encapsulation 67C Security extensions. 72D Sample configuration ROM. 75E Serial Bus transaction
30、error recovery . 79F SCSI Architecture Model conformance. 81vForeword (This foreword is not part of American National Standard ANSI NCITS 325-1998.)This standard defines a transport protocol within the domain of Serial Bus, as de-scribed in ANSI/IEEE 1394-1995, that is designed to permit efficient,
31、peer-to-peeroperation of input output devices (disks, tapes, printers, etc.) by upper-layer proto-cols such as operating systems or embedded applications. Vendors that wish to im-plement devices that connect to Serial Bus may follow the requirements of this andother normatively referenced standards
32、to manufacture an SBP-2 compliant device.This standard was developed by T10 during 1996 and through early 1998. Althoughsome early SBP mock-up devices were demonstrated in 1993, significant proof-of-concept, in the form of prototype implementations, has proceeded contemporane-ously with the developm
33、ent of this standard.This standard bears the name SBP-2 because there was an ancestral standard, Seri-al Bus Protocol (SBP), which has since been withdrawn by ANSI. SBP was extantduring most of the development of this standard, which was consequently calledSBP-2 to avoid confusion.There are six anne
34、xes in this standard. Annexes A, B and C are normative and partof this standard. Annexes D, E and F are informative and are not considered part ofthis standard.Requests for interpretation, suggestions for improvement and addenda, or defect re-ports are welcome. They should be sent to the NCITS Secre
35、tariat, Information Tech-nology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC 20005-3922.This standard was processed and approved for submittal to ANSI by National Com-mittee for Information Technology Standardization (NCITS). Committee approval ofthis standard does not necessaril
36、y imply that all committee members voted for ap-proval. At the time it approved this standard, NCITS had the following members:Karen Higginbottom, ChairDavid Michael, Vice-ChairMonica Vago, SecretaryOrganization Represented Name of RepresentativeAMP, Inc. John HillCharles Brill (Alt.)Apple Computer,
37、 Inc. David MichaelJerry Kellenbenz (Alt.)AT The protocol should enable the initiator to form an arbitrarily large set of tasks without considerationof implementation limits in the target; The protocol should allow the initiator to dynamically add tasks to this set while the target is active inexecu
38、tion of earlier tasks. The addition of new tasks should not interfere with the targets processingof tasks currently active; Although the protocol should enable varying levels of features and performance in target implemen-tations, strong focus should be kept on a minimal set deemed adequate for entr
39、y-level environ-ments; Within the constraints posed by the preceding goal, the hardware and software design of the initiatorshould not be unduly affected by variations in target capabilities; In order to promote the scalability of aggregate system performance, the protocol should distributethe DMA c
40、ontext from the initiator adapter to the target devices.Although SBP-2 has been designed for Serial Bus as currently specified by ANSI/IEEE 1394, the Techni-cal Committee anticipates that it will be appropriate for use with future extensions to Serial Bus as they arestandardized.ANSI NCITS 325-19982
41、2 Normative referencesThe standards named in this clause contain provisions which, through reference in this text, constituteprovisions of this American National Standard. At the time of publication, the editions indicated were valid.All standards are subject to revision; parties to agreements based
42、 on this American National Standard areencouraged to investigate the possibility of applying the most recent editions of the standards indicatedbelow.Copies of the following documents can be obtained from ANSI:Approved ANSI standards;Approved and draft regional and international standards (ISO, IEC,
43、 CEN/CENELEC and ITU-T); andApproved foreign standards (including BIS, JIS and DIN).For further information, contact the ANSI Customer Service Department by telephone at (212) 642-4900,by FAX at (212) 302-1286 or via the world wide web at http:/www.ansi.org.Additional contact information for documen
44、t availability is provided below as needed.2.1 Approved referencesANSI/IEEE 1394-1995, High Performance Serial BusANSI/ISO/IEC 9899-1990 (R1997), Programming Languages - CISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer Buses1)2.2 References under developmentAt th
45、e time of publication, the following referenced standards were still under development.IEEE P1394a, Draft Standard for a High Performance Serial Bus (Supplement)2)BSR X3 PN 1157-D, Information Technology - SCSI Architecture Model 2 (SAM-2)3)BSR NCITS PN 1236-D, Information Technology - SCSI Primary
46、Commands 2 (SPC-2)3)_1)Available from the American National Standards Institute, 11 West 42nd Street, New York, NY 10036.2)Available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ08855-1331.3)Available from the National Committee for Informat
47、ion Technology Standards, 1250 Eye Street, NW, Suite 200,Washington, DC 20005-3922.ANSI NCITS 325-199833 Definitions and notation3.1 Definitions3.1.1 ConformanceSeveral keywords are used to differentiate levels of requirements and optionality, as follows:3.1.1.1 expected: A keyword used to describe
48、the behavior of the hardware or software in the designmodels assumed by this standard. Other hardware and software design models may also be imple-mented.3.1.1.2 ignored: A keyword that describes bits, bytes, quadlets, octlets or fields whose values are notchecked by the recipient.3.1.1.3 may: A key
49、word that indicates flexibility of choice with no implied preference.3.1.1.4 reserved: A keyword used to describe objectsbits, bytes, quadlets, octlets and fieldsor thecode values assigned to these objects in cases where either the object or the code value is set aside forfuture standardization. Usage and interpretation may be specified by future extensions to this or otherstandards. A reserved object shall be zeroed or, upon development of a future standard, set to a valuespecified by such a standard. The recipient of a reserved object shall not check its value. The re
