UNH InterOperability Lab

SATA Chapters 11 and 12 Device Command Layer Protocols UNH InterOperability Lab

Presentation Topics Device Command Layer Protocol Power-on and COMRESET Device Idle EXECUTE DEVICE DIAGNOSITC DEVICE RESET DMA data-in FPDMA QUEUED (Host and Device) Other Command Layer Protocols

Command Layer Protocols Series of inter-related state machines Guidelines for devices and hosts on steps to take when processing and incoming or outgoing command

Power-on and COMRESET • On reception of COMRESET from a Host, devices shall execute the hardware reset protocol regardless of current device command layer state or power management state • Covers the basic power on procedures to be used by both Packet and Non-packet devices

Power-on and COMRESET • DHR0: Hardware_reset_asserted • Command Layer has received a message from the Transport Layer that a COMRESET has been asserted • Device stays in this state until message from Phy State Machine is received saying that the hardware reset has been negated • Only transitions to DHR1

Power-on and COMRESET • DHR1: Execute_diagnostics • During this state, a Device initializes its hardware and executes its power up diagnostic routines • Upon completion of power up diagnostic routines a Device can transition to DHR2 or DHR3

Power-on and COMRESET • DHR2: Send_good_status • In this state, a Devices transmits a Register FIS to the Host indicating that the power up diagnostics have been completed successfully • The Device then transitions to DI0: Device_idle

Power-on and COMRESET • DHR3: Send_bad_status • In this state, a Devices transmits a Register FIS to the Host indicating that the power up diagnostics have NOT been completed successfully • The Device then transitions to DI0: Device_idle

Device Idle Protocol • The default state for all SATA Devices • Awaiting the reception of a FIS from the Host • State machine defines how to process commands and how to decide which command specific state machine to enter based on the received FIS

Device Idle Protocol • DI0: Device Idle • Default State • Just waiting for something to happen from the Host • Numerous possible transitions from this state based on Host actions

Device Idle Protocol • DI1: Check_FIS • Entered from DI0 upon reception of a FIS • Check C-bit and SRST-Bit of the FIS • If C-bit asserted → DI2: Check_command • If SRST-bit asserted → DSR0: Software_reset_asserted • Any other FIS → DI0: Device_idle

Device Idle Protocol • DI2: Check_command • Check the fields of the command • 15 possible transitions out of this state based on the command type found when checking fields

Device Idle Protocol • DI3: No_Command • Entered when a Device receives a command not supported • ABRT-bit of command set to one → DI0: Device_idle • DI4: Set_service • Entered when Device is ready to complete data transfer for a queued command • SERV-bit of command set to one → DI0: Device_idle

Device Idle Protocol • DI5: Service_test • Entered when a SERVICE Command is received • Check the command to see if a Register FIS needs to be transmitted for DRQ bit and to set the Tag • If PACKET PIO In/Out → DI7: Service_decode • Else → DI6: Service_send_tag

Device Idle Protocol • DI6: Service_send_tag • Entered when a SERVICE command has been received • Device waits for a Register FIS with the BSY-bit de-asserted, DRQ-bit asserted, and an appropriate tag • Upon reception of the FIS → DI7: Service_decode

Device Idle Protocol • DI7: Service_Decode • Check the command that has been received after the required Register FIS has been received • 6 Possible transitions based on the command type

Execute Device Diagnostics Protocol • Command Class for the EXECUTE DEVICE DIAGNOSTIC command • If COMRESET or a FIS with SRST-bit asserted is received, the Device shall execute the COMRESET Command Protocol or the Software Reset Command Protocol respectively • Describes the process for EXECUTE DEVICE DIAGNOSTIC command

Execute Device Diagnostics Protocol • DEDD0: Execute_device_diag • In this state, a Device will execute its internal diagnostic procedures • If diagnostics completed successfully → DEDD1: Send_good_status • Else → DEDD2: Send_bad_status • From DEDD1 and DEDD2 → DI0: Device_Idle

Device Reset Protocol • Command Class for the DEVICE RESET command • If COMRESET or a FIS with SRST-bit asserted is received, the Device shall execute the COMRESET Command Protocol or the Software Reset Command Protocol respectively • When this command is received, a Device will stop all activity

Device Reset Protocol • DDR0: Device_reset • Upon reception of this command, a Device will halt all execution of any outstanding commands and will hald all background activity • When activity has ceased → DDR1: Send_good_status • DDR1: Send_good_status • Device requests the Host transmit a Register FIS • Upon reception of this FIS → DI0: Device_Idle

DMA Data-in Protocol • Command Class for the READ DMA and READ DMA EXT commands • Execution of this command induces the transfer of one ore more blocks of data from the device to the host use using a DMA transfer • Command Protocol for most read operations in modern, non-packet devices

DMA Data-in Protocol • DDMAI0: DMA_in • In this state, a Device will prepare the date for transfer to the host • When Data FIS is ready → DDMAI1: Send_data • Otherwise, command has been completed or aborted → DDMA2: Send_status

DMA Data-in Protocol • DDMAI1: Send_data • In this state, the Device shall transmit the prepared FIS to the host • DDMAI2: Send_status • A Device enters this state when all the data for a command has been transmitted to a Host or an error has caused the command to abort

FPDMA Queued Protocol • Command Class for READ FPDMA QUEUED and WRITE FPDMA QUEUED commands • Special Read and Write commands for Native Command Queuing features found in SATA2+

FPDMA Queued Protocol • DFPDMAQ1: AddCommandToQueue • Upon determining a FPDMA command has been received, a Device will add the command to its internal queue and store the command's TAG value • Successful en-queuing → DFPDMAQ2: CleareInterfaceBsy • Else → DFPDMAQ12: BrokenHost_ClearBusy

FPDMA Queued Protocol • DFPDMAQ2: ClearInterfaceBsy • Transmit a Register FIS to the host with BSY and DRQ bits deasserted, indicating the Device is ready to receive the next command • Upon transmission → DI0: Device_idle

FPDMA Queued Protocol • DFPDMAQ3: DataPhaseReadSetup • State entered when the device is ready to transmit data from a previously queued READ FPDMA QUEUED command • In this state, a Device will attempt to setup up a host memory write DMA connection with the Host • Once the connection is established, a Device will transition to DFPDMAQ8

FPDMA Queued Protocol • DFPDMAQ4: DataPhasePreWriteSetup • State entered when the device is ready to receive data from a previously queued WRITE FPDMA QUEUED command • In this state a Device needs to determine if Auto-Activate is supported an enabled • If yes, → DFPDMAQ5: DataPhase_WriteSetup • Else → DFPDMAQ6: DatePahse_OldWriteSetup

FPDMA Queued Protocol • DFPDMAQ5: DataPhase_WriteSetup • This state is entered when a Device is ready to Auto-Activate • A device transmits a DMA Setup FIS to the host with a DMA buffer Id, the queued TAG value, the direction bit cleared (Host Memory Read), and the AA bit set to one • Once Setup FIS is completed → DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol • DFPDMAQ6: DataPhase_OldWriteSetup • This state is entered when Auto-Activate is not supported or enabled • A device transmits a DMA Setup FIS to the host with a DMA buffer Id, the queued TAG value, the direction bit cleared (Host Memory Read), and the AA bit set to zero • Once Setup FIS is completed → DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol • DFPDMAQ7: DataPhaseXmit_Activate • This state is entered after a device completed setup for a WRITE DPDMA QUEUED command • While in this state a Device transmits a DMA Activate FIS indicating its readiness to receive DATA FISes • The device then transitions to DFPDMAQ9: DataXmitWrite

FPDMA Queued Protocol • DFPDMAQ8: DataXmitRead • This state is entered after a device has completed setup for a READ FPDMA QUEUED command • A device continues to transmit Data FISs until the command has been completed or an error has been encountered • Device transitions to DI0: Device_idle upon completion

FPDMA Queued Protocol • DFPDMAQ9: DataXmitWrite • This state is entered after a device has completed setup for a WRITE FPDMA QUEUED command • A device continues to receive DATA FISes until the command has been completed or an error has been encountered • Device transitions to DI0: Device_idle upon completetion

FPDMA Queued Protocol • DFPDMAQ10: SendStatus • This state is entered after a device has completed the data transfer associated with a command • In this state, a device will transmit a Set Device Bits FIS to the host indicating the completion of the command • Following the transmission of this FIS, a device will transition to DI0: Device_idle

FPDMA Queued Protocol • DFPDMAQ11: Error • This state is entered when a device has encountered an unrecoverable error • When this state is entered, a device halts all transmissions and transmits a Set Device Bits FIS to the host indictating the error condition • A device then transitions to DFPDMAQ13: WaitforClear

FPDMA Queued Protocol • DFPDMAQ12: BrokenHost_ClearBusy • This state is entered when a device receives a READ or WRITE FPDMA QUEUED command with a tag that exists already in the queue or a non-queued command is received while there are still outstanding commands in the queue • Upon entering this state, a device will transmit a Register FIS to the host indicating the error condition and then transition to DFPDMAQ13

FPDMA Queued Protocol • DFPDMAQ13: WaitforClear • This state is entered when a device has transmitted an error FIS and is waiting for a READ LOG EXT command or a Soft-Reset • All other commands will be responded to with an Error FIS • When the READ LOG EXT command is received the device shall transition to DFPDMAQ12

FPDMA Queued Protocol • DFPDMAQ14: SendQueue_CleanACK • This stae is entered when the Host has responseded to an error FIS with a READ LOG EXT command • The Device will discard all queued commands remaining and transmit a Set Device Bits FIS with the ERR bit cleared, Error Field cleared, and Sactive = FFFFFFFFh and interup cleared • Upon transmission of this FIS, the device shall transition to DPIOI0:PIO_in

FPDMA Queued Protocol (Hosts) • This state machine describes the behavior for Native Command Queuing Hosts • This class is largely similar to the behavior of the devices but also covers: • TAG assignment • Error Recovery • Retrying Failed Commands

Software Reset Protocol • This state machine covers how a device handles receiving a FIS with the SRST bit asserted • Essentially the same as the DEVICE RESET Command Protocol

Non-Data Protocol • This state machine describes how a device will handle receiving a non-data command FIS • Commands include: FLUSH CACHE, IDLE, MEDIA LOCK, SEEK, NOP, and SET MULTIPLE MODE among others

PIO Data-in and Data-out Protocol • These two state machines describe how commands will responds to PIO requests (Diagnostic and legacy commands from previous ATA standards) • Commands include IDENTIFY DEVICE, READ SECTORS, SMART READ DATA, DOWNLOAD MICROCODE, and WRITE SECTORS among others

Packet Protocol • This state machine describes how a device will handle receiving a packet based commands. Packet commands are used by Optical Disc Drives and other ATAPI device which do not utilize the traditional PIO and DMA interfaces defined with ATA

UNH InterOperability Lab