Template Version: @(#)onepager.txt 1.34 07/08/27 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SDcard Stack Phase I 1.2. Name of Document Author/Supplier: Garrett D'Amore 1.3. Date of This Document: 16-Nov-2007 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Andrew Roach 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: neal.pollack@sun.com 1.5.2. Responsible Engineer: garrett.damore@sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: laptop-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: This project provides a framework, and supporting drivers, for using SDcard media and slots. The project will supply functionality for using SD memory cards on the builtin-slots found on common laptops. 2.2. Risks and Assumptions: This stack relies on the Generic Block Driver to SCSI translator (blk2scsa) being reviewed seperatly (PSARC 2007/654). SDcard technology may be covered by patents. The specifications required to implement the basic functionality are open, but a license may be required to redistribute the code, and there may be annual recurring costs associated with that. An MMC license may be required as well, although it appears that all that is required is the purchase of the MMC specifications with a small one-time fee. SDcard performance may be limited by unless certain NDA information can be utilized. It is unclear what impact this will have, if any, on our ability to redistribute the source code. SDcard and MMC both have standard for general I/O support, and at least for SDcard, I/O devices exist. This project is attempting to design for future expansion to support that effort, but until we actually deliver peripheral support, we will not know for certain if core incompatible changes to the framework will be required. Likewise, we are only supporting one host controller with this project, although we are designing the framework to be able to support other host controller types. The author has experience with one other such controller, but it is not exhaustive. SDcard and MMC can both support an SPI (Serial Peripheral Interface) bus. We are assuming that there is no need for this in host computers. There could be significant changes to the framework required if this changes. 3. Business Summary 3.1. Problem Area: Many laptop products ship with slots for digital media. One of the most popular formats is called SDcard, which is an upgrade to MMC. (Generally SDcard slots can read MMC media.) It is widely used in digital cameras, MP3 players, mobile computing devices, etc. There is an immediate need to be able to support memory media in SDcard formats. 3.2. Market/Requester: The market is almost the complete set of laptops that can run Solaris. This in particular is needed to support certain OEM engagements with laptop vendors. 3.3. Business Justification: Lack of support for these SDcard slots is an inhibitor to Solaris adoption on laptop products. Very quickly, SDcard and MMC media are becoming one of the exchange formats of choice. 3.4. Competitive Analysis: Microsoft ships a complete SDcard stack, including support for I/O peripherals. Linux and NetBSD have at least support for memory media in these slots. Desktop computers generally have USB connected slots, which are supported by Solaris today through the scsa2usb driver. 3.5. Opportunity Window/Exposure: This is needed now to close a feature gap with other commodity operating systems on these platforms. 3.6. How will you know when you are done?: SDcard stack delivered into ON, with support for SDcard, MMC, and SDHC (high capacity) media on builtin slot readers found on common laptops. (We will be targetting a specific family line of laptop products, but there is a standard for these readers, so the driver will probably support nearly all modern laptops.) The support will include the ability to use the SDcard media just like it can be used in typical USB readers today. (I.e. it can be mounted just like a disk, and automatically mounts/unmounts in response to hot insertion and removal.) 4. Technical Description: 4.1. Details: This is Phase I of what is anticipated to be a two phase project. Phase I will deliver three kernel modules: sda, sdhost, and sdcard. The sda module (SD Architecture) will provide a common framework for SD (and MMC) nexus and target drivers. (This is similar in concept to USBA.) The sda module will have APIs for nexus drivers, and for target drivers. The target API will be split in two, since in the SD architecture, memory cards behave quite differently from other IO peripherals. The sdhost driver will be the nexus implementation for SDcard host controllers conforming to the "Standard Host Controller" specified by SDA. This is the slot driver. The sdcard driver will act as a target driver for sda, but will use blk2scsa to emulate a SCSI nexus with one target (an emulated SCSI disk with removable media) for each slot on the system. Phase II is planned to deliver IO peripheral support. It may also include support for emerging standards, such as 8-bit and faster (52MHz) MMC busses. It is hoped that Phase II will also raise the commitment level of the APIs so that it can be used by 3rd parties. 4.2. Bug/RFE Number(s): TBD 4.3. In Scope: SDcard, SDHC, and MMC media in SDcard slots, accessed as emulated SCSI disks. 4.4. Out of Scope: SDIO device support. SPI (Serial Peripheral Interface) bus support. Newer MMC standards (MMCplus, MMC I/O, 8-bit MMC bus support, etc.) SD one-time-programmable memory. DRM protected content on SD or MMC media. 4.5. Interfaces: * blk2scsa nexus imported * sda target and nexus APIs created 4.6. Doc Impact: * man pages: sda(7d), sdhost(7d), sdcard(7d) 4.7. Admin/Config Impact: None. Devices will appear as ordinary SCSI disk devices. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: A new package, SUNWsdcard, will be delivered. If the project is going to support root on SD memory cards, then it will need to deliver on the miniroot. At the moment, it is not clear that there is a need for this, since our boot loaders (grub) are not equipped to read from SD or MMC media. 4.11. Security Impact: None. Although SD stands for Secure Digital, we are not enabling any of the security features of SD (which are primarily aimed at DRM protected content.) 4.12. Dependencies: This project depends on the Generic Block-to-SCSA Translation Layer (blk2scsa), PSARC 2007/654. 5. Reference Documents: [1] SD Specifications Part 1: Physical Layer Simplified Specification, Version 2.00, September 25, 2006 (www.sdcard.org) [2] SD Specifications Part A2: SD Host Controller Simplified Specification, Version 2.00, February 8, 2007 (www.sdcard.org) [3] SD Specifications Part E1: SDIO Simplified Specification, Version 2.00, February 8, 2007 (www.sdcard.org) [4] Generic Block Device to SCSA Translation Layer, Functional Specification, Garrett D'Amore, November 13, 2007, PSARC 2007/654 6. Resources and Schedule: 6.1. Projected Availability: Fall 2007 6.2. Cost of Effort: Development: 2 engineer months Test Development: 1 engineer-week Docs: TBD 6.3. Cost of Capital Resources: No additional resources needed. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: TBD 6.4.5. Is this a necessary project for OEM agreements: Yes. Our OEM agreements with laptop vendors depend on it. 6.4.6. Notes: // See dependencies section above. 6.4.7. Target RTI Date/Release: snv_81 6.4.8. Target Code Design Review Date: Dec 2007 6.4.9. Update approval addition: At this time, only Nevada is targetted. However, nothing in the project would be difficult to backport to Solaris 10 if market conditions justify it. 6.5. ARC review type: Standard 6.6. ARC Exposure: open 6.6.1. Rationale: 7. Prototype Availability: 7.1. Prototype Availability: A fully-functional prototype is expected to be available by late Nov 2007. 7.2. Prototype Cost: // Subset of Cost of Effort to leave "prototype" stage.