SDcard One Pager (Draft)

Template Version: @(#)onepager.txt 1.34 07/08/27 SMI

Copyright 2007 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:
   	SDcard Stack

   1.2. Name of Document Author/Supplier:
   	Garrett D'Amore

   1.3. Date of This Document:
	9-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 separatly.

	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.  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 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 SDmemory, 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).

5. Reference Documents:
   	The following two documents are available for download from
	www.sdcard.org:

   	SD Simplified Host Controller Specification
   	SD Simplified Physical Layer Specification

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_80
	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 mid-Nov 2007.

   7.2. Prototype Cost:
	// Subset of Cost of Effort to leave "prototype" stage.