Serial ATA Staggered Spin-Up

September 2004 Serial ATA Staggered Spin-Up September 2004 Revisin 1.0 A WHITEPAPER BY: Intel Crpratin www.intel.cm

Cntents 1 Summary...4 2 Keywrds...4 3 Supprting Staggered Spin-up...6 3.1 Perfrming the Staggered Spin-up Sequence During POST...6 3.2 Supprting Staggered Spin-Up During Resume frm the D3 cld Device Pwer State...7 3.2.1 HBA Behaviral Assumptins...7 3.2.2 System Firmware Cnsideratins...8 3.2.3 Operating System Cnsideratins...8 3.3 Supprting Staggered Spin-Up During Resume frm the D3 ht System Pwer State...9 3.3.1 HBA Behaviral Assumptins...9 3.3.2 System Firmware Cnsideratins...9 3.3.3 Nn-native SATA Aware OS Cnsideratins...9 3.3.4 Native SATA Aware OS Cnsideratins...9 3.3.5 HBA D3->D0 Implementatin Cnsideratins...10 2

Legal Ntices: NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. The Intel lg is a trademark r registered trademark f Intel Crpratin r its subsidiaries in the United States and ther cuntries. *Other names and brands may be claimed as the prperty f thers. Cpyright 2004, Intel Crpratin 3

1 Summary Platfrms that include numerus Serial ATA hard disk drives may be presented with pwer system design issues related t the electrical current lad presented during system pwer-up. Staggered spin up prvides a simple mechanism by which SATA HBAs can sequence disk drive initializatin and spin-up. Specific details with regards t SATA and staggered spin-up can be fund in Serial ATA II: Extensins t Serial ATA 1.0 Rev 1.0 specificatin (available frm the Serial ATA Wrking Grup at: http://www.serialata.rg). This paper prvides a basis fr understanding hw the staggered spin-up feature can be supprted by bth the platfrm system BIOS and perating system specific device drivers (staggered spin-up aware and nn-staggered spin-up aware). 2 Keywrds The fllwing terms will be used thrughut this paper: BIOS Basic Input/Output System. This is the firmware embedded n a chip (typically FLASH memry) that is respnsible fr executing the POST sequence and fr testing and initializing the system cmpnents befre bting an perating system. D0 1 Device pwer state in which a device is n and running. It is receiving full pwer frm the system and is delivering full functinality t the user. All devices must supprt this pwer state. D0 active Device pwer state where the device has been cnfigured and enabled by sftware and is functinal. D0 uninitialized A device pwer state that a device enters as result f PCI RST# being asserted r when instructed by sftware t transitin frm D3ht t the D0 state. D1 Device pwer state in which the device is in a light sleep pwer cnservatin state. This pwer state is ptinal and can nly be entered frm the D0active pwer state. D2 Device pwer state in which the device is in a deeper sleep state than D1 but less than D2ht. This pwer state is ptinal and can nly be entered frm the D0active and D1 states. D3 Full Off Device pwer state in which a device is ff. In this state a device lses its cntext and pwer is remved frm the device. All devices must supprt this pwer state. D3 ht Device pwer state that ccurs when a device transitins t D3, yet still has Vcc applied. D3 cld Device pwer state that ccurs when a device transitins t D3, but Vcc is nt applied. Emulatin mde Optinal mde supprted by a SATA HBA. Allws nn-native SATA aware sftware t access SATA devices via traditinal task file registers. HDD Hard Disk Drive. 1 Device pwer state definitin and behavir can be fund in the PCI Specificatin v2.3 which is available frm www.pcisig.cm. 4

HBA Hst Bus Adaptr. Hst sftware Refers t sftware running n the platfrm and includes system firmware as well as perating system sftware. IHV Independent Hardware Vendr Native SATA aware refers t system sftware (BIOS, ptin ROM, perating system, etc) that cmprehends a particular SATA HBA implementatin and understands its prgramming interface and pwer management behavir. Nn-native SATA aware - refers t system sftware (BIOS, ptin ROM, perating system, etc) that des nt cmprehend a particular SATA HBA implementatin and des nt understand its prgramming interface r pwer management behavir. Typically, nn-native SATA aware sftware will use a SATA HBA s emulatin interface (e.g. task file) t cntrl the HBA and access its devices. Native mde Optinal mde supprted by a SATA HBA. Allws native SATA aware sftware t access SATA devices via registers that are specific t the HBA. OROM Optin ROM POST Pwer-n Self Test. This is the part f the BIOS that takes cntrl immediately after the cmputer is pwered-n. The POST cde initializes the cmputer hardware s that an perating system can be bted. System Firmware Refers t system BIOS and/r ptin ROM sftware. S0 2 System pwer state. While the system is in the S0 state, it is in the system wrking state. Device states are individually managed by the perating system sftware and can be in any device state (D0, D1, D2, r D3). S1 System Pwer State. This is a lw wake latency sleeping state. The S1 state is defined as a lw wakeup latency sleeping state. In this state n system cntext is lst (CPU r chip set), and the hardware is respnsible fr maintaining all system cntext, which includes the cntext f the CPU, caches, memry, and all chipset I/O. S2 System Pwer State. The S2 state is a lw wakeup latency sleep state. This state is similar t the S1 sleeping state; except that the CPU and system cache cntext is lst (the OS is respnsible fr maintaining the cache and CPU cntext). The hardware is respnsible fr maintaining chipset and memry cntext. S3 System Pwer State. The S3 state is a lw wakeup latency sleep state, where all system cntext is lst except fr system memry. CPU, cache, and device cntext is lst in this state; the OS and drivers must restre all device cntext. Hardware must maintain chipset, memry cntext and restre sme CPU and L2 cnfiguratin cntext. S4 System Pwer State. The S4 sleeping state is the lwest pwer, lngest wake latency sleeping state supprted. In rder t reduce pwer t a minimum, it is assumed that the hardware platfrm has pwered ff all devices (D3 cld ). Platfrm cntext is maintained. This system pwer state is als refered t as the hibernatin state. S5 System Pwer State. The S5 state is similar t the S4 state except that the OS des nt save any cntext. The system is in the sft ff state and requires a cmplete bt when it wakes. 2 System pwer state definitin and behavir can be fund in the ACPI 2.0b specificatin which is available frm www.acpi.inf 5

3 Supprting Staggered Spin-up Fr platfrms that are staggered spin-up enabled, system firmware shuld always prvide staggered spin-up supprt because: 1. On a multi-drive platfrm, the system firmware may nt cmprehend which attached HDD cntains the perating system that the user wishes t bt t. Typical PC system firmware requires that the HDDs are spun-up and ready prir t presenting the user with a list f btable devices. This system firmware requirement cmbined with the pwer supply limitatins assciated with a staggered spin-up enabled platfrm requires that any attached SATA HDDs be spun-up in a cntrlled manner. Ding s will prevent verlading f the platfrm pwer supply. 2. System firmware may nt cmprehend if the target perating system natively supprts the staggered spin up feature and as such requires that all attached devices are in a spun-up and ready state prir t OS bt. This is particularly imprtant when the target perating system is nn-native SATA aware; as it will nt cmprehend the staggered spin-up feature which may lead t inaccessible devices. This perating system requirement cmbined with the pwer supply limitatins assciated with a staggered spin-up enabled platfrm requires that any attached SATA HDDs be spun-up in a cntrlled manner. Ding s will prevent ver-lading f the platfrm pwer supply. Cmplete supprt f the staggered spin-up feature requires that hst sftware implement staggered spin-up supprt fr the fllwing pwer states: Pwer-n Self Test (POST) Resume frm D3 cld Resume frm D3 ht 3.1 Perfrming the Staggered Spin-up Sequence During POST Fr each SATA prt implemented by the SATA HBA, the hst perfrms the staggered spin-up sequence as fllws: Nte: Because HBA implementatin may vary in design, all examples in this paper assume a generic HBA with register/bits that prvide spin-up cntrl, device presence detectin and device readiness detectin. 1. The hst attempts t establish PHY cmmunicatins with the device attached t the SATA prt. PHY cmmunicatins is initiated via a hst issued COMRESET. It is the establishment f PHY cmmunicatins that causes the attached device t begin rtatin f its spindle. (Refer t the Serial ATA II extensins t Serial ATA 1.0a specificatin fr the exact hst t device signal exchange). 2. The hst then waits fr a psitive indicatin that a device is attached t the prt. The exact details f hw a hst detects device presence are beynd the scpe f this paper. Hwever, as per the Serial ATA 1.0a Specificatin, a device must respnd with COMINIT within 10ms f detecting a hst COMRESET. As such, it is reasnable t expect that an HBA will take advantage f this behavir and prvide an apprpriate mechanism fr hst sftware t use. If the hst des nt implement a 6

device detectin mechanism accessible by hst firmware, then waiting fr the (ptential) device t becme ready is an alternate mechanism. 3. If it is determined that n device is present, then the hst prceeds t step 5. Otherwise, the hst waits fr indicatin that the attached SATA drive is ready. The device indicates readiness when BSY and DRQ are bth clear (0) 3. This is identical t hw device presence/readiness is determined fr P-ATA devices. It is reasnable t expect that an HBA will prvide a hst sftware accessible mechanism whereby device readiness can be determined (e.g. emulated task file registers r HBA specific registers). 4. If the SATA device indicates readiness, then the hst cntinues the staggered spinup sequence using the next available prt (g t step 1). 5. Cleanup. If n device is detected r the device des nt indicate ready, then the hst perfrms whatever steps are required by the HBA implementatin and leaves the prt in a state that is expected by the perating system. Since HBA implementatins and perating systems vary in design, an exact descriptin f this is beynd the scpe f this paper. The hst then cntinues the staggered spin-up sequence using the next available prt (g t step 1). Nte: Because the staggered spin-up sequence described in this sectin is highly sequential, it des nt represent the mst ptimized slutin available. This sequence illustrates the fundamental requirements needed t supprt staggered spin-up. Any ptimizatins are beynd the scpe f this paper and are left as an exercise fr the implementer. 3.2 Supprting Staggered Spin-Up During Resume frm the D3 cld Device Pwer State This sectin describes hw system firmware supprts staggered spin-up during resume frm the D3 cld device pwer state. The term device in this cntext refers t a SATA HBA and nt an attached SATA HDD. 3.2.1 HBA Behaviral Assumptins A SATA HBA is in the D3 cld device pwer state when its Vcc is remved as a result f the system being placed in the suspend state (S3), hibernatin state (S4) r pwer ff state (S5). Typically, system firmware des nt differentiate between the S4 and S5 states and as such it will fllw the sequence utlined in sectin 3.1 Perfrming the Staggered Spin-up Sequence During POST. When the HBA transitins frm the D3 cld pwer state t the D0 device pwer state, the fllwing is true: The HBA is placed int the D0 uninitialized state (causes a change in device pwer state, D3 cld ->D0 uninitialized ). As per the PCI v2.3 Specificatin, the result f this transitin is: The HBA PCI Cnfiguratin space is reset The HBA memry mapped space is reset Register restratin is the respnsibility f ne r mre f the fllwing: system firmware, the perating system, and device driver sftware System firmware can participate in resume path prcessing. 3 The maximum amunt f time that a SATA device is permitted t take befre indicating readiness is specified in the ATA/ATAPI-6 specificatin which is available frm the T13 Technical Cmmittee at www.t13.rg). 7

Nte that this is nt true fr SATA HBA ptin ROMs; ptin ROMs (regardless f device type) nly get initialized during initial system pwer n. As such, the perating system and/r device driver has full respnsibility fr re-initializing the SATA HBA. Nte: Pwer t any attached SATA devices will be lst nce a SATA HBA transitins int the D3 cld state. As such, any attached SATA devices will lse their prgramming and will require subsequent reprgramming by system sftware nce the SATA HBA transitins int the D0 active state. 3.2.2 System Firmware Cnsideratins T supprt staggered spin-up n the platfrm when the SATA HBA is resuming frm the device D3 cld pwer state and the system firmware is participating in the resume path (e.g. S3), the system firmware perfrms the fllwing: 1. Thse registers required fr nrmal perating system peratin (i.e. capability bits) are initialized. 2. If the system firmware is resuming t an perating system that prvides native-sata supprt, then the system firmware s participatin in the staggered spin-up sequence is cmplete. It is expected that the perating system will cmplete the remaining steps required t spin up the drives. Eliminating the actual spin-up f the drives (frm a system firmware perspective) will expedite the resume prcess (e.g. reduce resume latencies). Otherwise, the user culd be presented with a blank screen during the interval when the system firmware is sequentially spinning up each drive in the platfrm. 3. If the system firmware is resuming t an perating system that des nt prvide native- SATA supprt (i.e. the device sub-class cde is IDE (01) and as a result, the perating system uses the emulatin capabilities f the SATA HBA) then system firmware cmpletes the steps utlined in sectin Supprting Staggered Spin-up During System Pst. System firmware must perfrm the cmplete staggered spin up sequence fr this case as a nn-native SATA aware perating system will nt be cgnizant f the staggered spin-up feature. 3.2.3 Operating System Cnsideratins T supprt staggered spin-up n the platfrm when the SATA HBA is resuming frm a D3 cld device pwer state, an perating system device driver that is native SATA aware implements ne f the fllwing spin-up strategies: Nte: Because ptin ROMs are nt re-initialized when a device is resuming frm the D3 cld device pwer state, the perating system device driver assumes that the SATA HBA s spin-up cntrl bit can be fund in its default state (ff). 1. D nt spin-up any f the drives until an access request is made (e.g. read/write). Care must be taken when simultaneusly accessing any remaining spun dwn drives (i.e. must be accessed in a serialized manner until all remaining drives are spun up). 2. Spin up nly the drive that cntains the perating system r perating system key data (i.e. page file) as this drive is typically accessed first. Care must be taken when simultaneusly accessing any remaining spun dwn drives (i.e. must be accessed in a serialized manner until all remaining drives are spun up). 8

3. Sequentially spin up all f the drives during resume phase. Each strategy described abve has its wn advantages and shrt cmings. The chice f which strategy t implement may be dependent upn many factrs including (but nt exclusively): perating system pwer management plicy, device driver architecture, hst cntrller capabilities, SATA device capabilities, etc. 3.3 Supprting Staggered Spin-Up During Resume frm the D3 ht System Pwer State This sectin describes hw system sftware supprts staggered spin-up during resume frm the D3ht device pwer state. 3.3.1 HBA Behaviral Assumptins A SATA HBA will enter the D3 ht device pwer state whenever: The system is in the S0 system pwer state and the SATA HBA has been prgrammed t enter the D3 device pwer state. The system is transitining t the S1 system pwer state and the SATA HBA has been prgrammed t enter the D3 device pwer state. Upn resuming frm the S1 system pwer state, the fllwing is true: The SATA HBA will experience a D3 ht ->D0 transitin Results in the HBA being placed int a D0 active. SATA HBA PCI Cnfiguratin space may r may nt be reset. SATA HBA memry mapped space may r may nt be reset. System firmware cannt participate in resume path prcessing. Any cnnected SATA device will remain pwered and will nt lse its prgramming. 3.3.2 System Firmware Cnsideratins Since system firmware cannt participate in the D3->D0 resume path, it has n requirements fr supprting staggered spin-up. 3.3.3 Nn-native SATA Aware OS Cnsideratins Since SATA devices maintain pwer when the SATA HBA is in the S1 system pwer state, each device will spin up upn being accessed (e.g. a request is made that that requires media access), prvided the device was placed int standby/sleep via an ATA cmmand issued by an perating system device driver. As such, when resuming frm a D3 ht device state, the OS must ensure that it des nt permit simultaneus access t all attached devices until they have been accessed serially, at least nce. Fr nn-native SATA aware perating system device drivers, this can be managed if the devices are re-enumerated sequentially during resume prcessing (e.g. any device previusly placed int STANDBY/SLEEP state will begin spinning up upn receipt f an ATA cmmand). 3.3.4 Native SATA Aware OS Cnsideratins Same as resume frm D3 cld, except n prgramming f the SATA devices is required as pwer t the devices is maintained in the S0 and S1 system pwer states. 9

3.3.5 HBA D3->D0 Implementatin Cnsideratins If the SATA HBA implements a pwer management plicy that is in strict cmpliance with the PCI v2.3 specificatin, then supprting staggered spin-up n a platfrm that is bting t a nn-native SATA aware perating system may nt be pssible. This is due t hw PCI devices are expected t perfrm when experiencing a D3->D0 transitin. The PCI spec states that this transitin is suppsed t place the device int a D0 uninitialized state, where PCI cnfiguratin space and I/O space is reset. Because a nn-native SATA aware perating system will nt cmprehend the prgramming interface specific t the SATA HBA, it may nt be able t restre the SATA HBA t a wrking state. Therefre, t maintain cmpatibility with lder perating sftware, SATA HBA IHVs may want t take this int cnsideratin when designing their hardware. The impact t perating systems that are native SATA aware is less than fr thse that are nt native SATA aware. Since a native SATA aware perating system will cmprehend bth the prgramming interface and behaviral aspects f the HW, it is therefre reasnable t expect that the perating system can restre the SATA HBA t a functinal state (fllwing a D3->D0 transitin). 10