1. What specifically is the proposal that we are reviewing? This case provides official OpenBoot device bindings for SAS controllers. No such bindings exist at this time, and in the past, the SCSI-3 parallel bindings were used for SAS controllers. It specifies to use the SASAddress, a globally unique identifier, as the unit address in OpenBoot for SAS target devices. The canonical path returned by OpenBoot will reflect this. These new bindings will mean a change to the existing SAS controller drivers (i.e. LSI 1064/1068) that currently utilize the "Target ID", a vendor specific identifier as the target device's unit address. Solaris drivers will need to be able to correlate the address string in the canonical path for a boot device with the device instance. This will require driver enhancements. In addition, an alternative addressing scheme is defined using the phy number on the host controller used to communicate to the target to allow a simple way to open devices directly attached to the HBA. This also buys us legacy support, since in the past, the vendor specific Target IDs always had a one to one correspondence with the phy number. One thing to note is that the phy number can only be used for attached disks, and cannot be used for drives attached to a SAS expander. To allow SATA devices consistent behavior with SAS devices, a third addressing mode is being introduced that uses persistent information from the SATA device. Without this feature SATA devices will not retain their addresses when moved around within a SAS fabric. 2. What is the motivation for it? Up until this time we have only used SAS disks that are directly attached to the controller. There are now several projects incorporating SAS expanders. The addressing scheme used for directly attached disks will break for disks attached through a SAS expander. 3. What is its plan? A prototype for the SASAddress support has been created and successfully tested. No design review has been done. 4. Are there related projects in Sun? Yes. Any future SAS work will need to incorporate this addressing scheme (i.e. Loki, Fishworks, new HBAs, etc. ). 5. What is the technical content of the project? This is defined in the SAS bindings specification portion of this ARC case. 6. How is the project delivered into the system? The changes will be made to the FCode for SAS controller drivers built into OpenBoot images as well as the FCode programmed on expansion cards. 7. What are the project's hardware platform dependencies? Is it expected to work on all systems (Desktop thru servers)? Any system that uses a SAS controller will be affected. 8. What is its FW operational environment: * Environment variables? none * Exit status? Signals issued? none * Command line or calling syntax: o What options are supported? At the OpenBoot prompt the user can either boot: device-path/disk@PhyNum or device-path/disk@wSASAddress or device-path/disk@sSATAUniqueID Note: Target IDs will still work in legacy platforms, since to date the Target ID has always corresponded to the phy number. * Does it depend on non-1275 kernel features? A complementary Solaris SAS MPT driver will need to be implemented. 9. What is its user interface (tty, graphical, leds, sound, etc.)? The user will address a boot drive from the OpenBoot prompt. 10. What are your project's other external interfaces (exported and imported)? * Exported public library APIs and ABIs Please refer to interfaces-sas.txt in the materials directory. * Protocols (public or private) none * Are the interfaces documented clearly enough for a non-Sun client to use them successfully? yes * What is the classification of these interfaces in the Interface Taxonomy (e.g. "Standard", "Stable", "Evolving", etc.; see the interface taxonomy document in /shared/sac/doc/interface.taxonomy)? Evolving 11. What are its other significant internal interfaces (inter-subsystem and inter-invocation)? * Protocols (public or private) none * Other none 12. Is the interface extensible? How is the interface expected to evolve? * How is versioning handled? The new address formats are obviously different from the existing format and can be easily identified. * What was the commitment level of the previous version? Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? The old interface had no committment level since it was never officially sanctioned. * What are the clients over which a change should be managed? How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? The admin will first need to update the Solaris MPT driver, and then the firmware. * Does this scale from low-end Desktops to high-end Servers? What, if any, trade-offs are involved? N/A 13. How do the interfaces adapt to a changing world? * What is its relationship with (or difficulties with) System Service Processors? Device path information that used to be statically provided by the SP now needs to have dynamic handling on the host. * What security issues do you address in your project? none 14. What internationalization issues are involved? N/A 15. How will the project contribute (positively or negatively) to "system load" and "perceived performance": * What are the performance goals of the project? How were they evaluated? On what type of test platform? The goal is to not affect the boot time. * Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? No it doesn't pause. * Does memory usage or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? No * What are the project's effects on boot time requirements? There should be no perceptible changes to boot time. 16. How does the project deal with failure and recovery? * How will it respond to failures? (Does it ever require reset? Use of stop key? Can it lock up?) * Does it attempt to isolate and contain the failure to allow for automatic recovery? * How does it communicate a fault event? Does it depend on a working console device? Attempting to open a non-existent SASAddress will fail. 17. Issues? Please identify the issues which you would like the ARC to address. * Interface classification, deviations from standards, architectural conflicts, release constraints... Exposure of SAS initiator port is not addressed by this proposal. 18. Security N/A 19. Database Does your project use or ship database or persistent storage software? No 20. Appendices: * List of exported and critical imported interfaces with their prior and proposed classifications. Please refer to interfaces-sas.txt * One-Pager. Please refer to onepager-SAS.txt * Prototype specification. * References to other documents. (Place copies in case directory.) http://t10.org/ftp/t10/drafts/sam4/sam4r13.pdf - SAS 1.1 spec http://t10.org/ftp/t10/drafts/sam4/sam4r13.pdf - SCSI Architecture Model 4 http://t10.org/ftp/t10/drafts/sat/sat-r09.pdf - SCSI ATA Translation http://noho.eng/1275/practice/spi/spi1_0.ps - SCSI-3 Parallel Bindings #pragma ident "@(#)fwarc-20Q.txt 1.4 09/28/05 SMI"