how to implement expresscard solutions on mobile platforms ken stufflebeam hardware evangelist...

How to Implement ExpressCard Solutions on Mobile Platforms

Ken StufflebeamHardware EvangelistMicrosoft Corporation

Brad SaundersSenior Mobile Systems ArchitectIntel Corporation

Session OutlineSession Outline

ExpressCard technologyBrief overview of ExpressCard

Key behavioral characteristics

Behavioral topicsCurrent Windows support for graceful removal

Windows codenamed “Longhorn” support

Compliance testing and Windows Logo requirements

Mechanical topicsThermal considerations

Electrical topicsPCI Express reset timing and reference clock control

PCI bridge support for modules under current OSs

Session GoalsSession Goals

Attendees should leave this session with the followingA better understanding of:

Supporting ExpressCard technology in Windows XPand Windows 2000

The Windows codenamed “Longhorn” solution

Compliance and Interoperability testing Common failures and solutions

Troubleshooting aids

Expectations when attending an interoperability event

ExpressCard implementation details Recent thermal requirements changes

Reference Clock control

ExpressCard bridge support

Knowledge of where to find resources for Interface specifications

Interoperability event scheduling

ExpressCard Technical SummaryExpressCard Technical Summary

Replacement to CardBus PC Card technology

ExpressCard Logo license granted to compliant products and components

3.3V, 1.5V, 3.3Vaux26-pin connector

Native bus attach

Two sizes

Power Management SupportPower Management Support

ACPI device power management modelMinimum support: D0, D3HOT, D3COLD

PCI Express link power managementRequired: ASPM (L0, L0s, L1), L2/L3 Ready, L3

WAKE# - sideband request to wake the system

Reference clock control – CLKREQ#

USB interface power managementBus-suspend support required (equates to D3)

In-band wake per USB specification

Behavioral Characteristics: The User ExperienceBehavioral Characteristics: The User Experience

Upon module installation No software pre-install required

Hot-plug does not wake system from standby/suspend

Upon module removal Desirable that graceful removal is supported through remove request icon in toolbar

Surprise removal does not wake system from standby/suspend

OS performs system recovery and clean-up

Benefits of Graceful RemovalBenefits of Graceful Removal

Allows user interaction with device and OSInstills confidence of data integrity

For some users, it’s an expected behavior

Enabling the user to stop the moduleProtects against data loss or corruption

Assures clean unloading of the driver

Closes open files associated with a hardware data stream

Notifies appropriate applications of hardware removal

What hardware should participate in graceful removal?

Any device that is part of creating or storing data

Current Windows Graceful Removal SupportCurrent Windows Graceful Removal Support

For this discussion, “current OS” = Windows XP and Windows 2000

Graceful and surprise removal are part of the device class drivers for USB modules

For device classes not defined, use class predicates as a guide for providing graceful removal support

Discovery (insertion and removal) supported for all devices

Under Windows Longhorn, graceful removal and discovery of PCI Express devices will be as seamless as USB is today

Current Windows do not support discovery of PCI hardware natively

Enumeration and tear-down are supported

Current Windows Graceful Removal SupportCurrent Windows Graceful Removal Support

Current OS support is complicated as the ExpressCard specification allows building products that use both PCI Express and USB interfaces on the same module

Further complicated by linked USB 2.0 andUSB 1.1 companion controllers

Current OSs rely on ACPI to manage these types of dependencies

Docking, as an example

Eject dependency lists

The Graceful Removal ProcessThe Graceful Removal Process

Present in Current OSsEnumerationDriver load

Driver unloadStopping the moduleApplication support

OS Power Management

Insertion detectOS notify

Hardwaredependencies

Removal detectOS notify

Discovery and Graceful Removal ToolsDiscovery and Graceful Removal Tools

IRP_MN_QUERY_CAPABILITIESIf the Removable or SurpriseRemovalOK flag is set TRUE when the IRP_MN_QUERY_CAPABILITIES query is made, then the module will be treated as a hot-pluggable device and will appear in the safe remove tray

Implemented by a filter bus driver – not desirable

Module dependant – not a generic fix

Doesn’t tell us anything regarding dependencies

Doesn’t solve discovery problem

Requires pre-installation – not desirable

ACPI Eject DependencyUse _EJD to declare hardware dependencies

Doesn’t allow three-way dependencies

By itself, doesn’t solve discovery

These two tools don’t solve the total problem!

The Discovery ProcessThe Discovery Process

To support graceful removal, the OS must first know (discover) the device being removed

Use \_SB._INI and load table by default – assumes a current operating system

Use _OSC to determine if table needs to be unloaded because OS supports native discovery

Scope (\_SBMethod (_INI) {

LoadTable (“OEM1”, “OEMID”, “Table1”, “\\_SB-EXC1”,,)

LoadTable (“OEM1”, “OEMID”, “Table2”, “\\_SB.EXC2”,,)

} // end _INI

} // end _SB scope

PROPOSAL IN

PROGRESS

ExpressCard \_SB MethodExpressCard \_SB Method

For \_SB._INI method, BIOS will create an \_SB.EXCx device where ‘x’ represents the slot number, one for each slotExample: \_SB.EXC1 for slot 1, \SB.EXC2 for slot 2

Each device has a _HID that is system specificExample: “FOO2005”

The slot-associated PCI Express and USB ports (Low-, Full- and High-speed ports inclusive) have _EJD dependencies that point to this device

_RMV is set to ‘0’ indicating that it is not removable to prevent this device from appearing in the hot removal applet until a device is actually present

PROPOSAL IN

PROGRESS

\_SB._INI Example (abbreviated)\_SB._INI Example (abbreviated)

// Define tables for ExpressCard slot 1 eject dependencies

Device (\_SB.EXC1) {

Name (_HID, (“FOO2005”)) //platform specific name

Method (_STA,0) {…} //check if device present

…PCI Express Function //specifies path to object

Name (_EJD, “\\_SB.EXC1”) //eject dependency

Name (_RMV, 0) //device not available

…USB1.1.1 Function//USB Low- or Full-speed device on port 1

Name (_EJD, “\\_SB.EXC1”)

Name (_RMV, 0)

…USB2.0.1 Function//USB High-speed device on port 1

Name (_EJD, “\\_SB.EXC1”)

Name (_RMV, 0)

}

//Define table for ExpressCard slot 2 eject dependencies

Device (\_SB.EXC2) {

Name (_HID, (“BAR2005”)) // platform specific name

PROPOSAL IN

PROGRESS

PROPOSAL IN

PROGRESSUse _OSC to determine Operating System support for native discovery

If native discovery supported, must also unload the EXCx tables

On return, flag indicating OS has control of the port would be set

OS will handle discovery via PCI Express in-band presence change interrupt

Operating systems that do not run _OSC will not support native discovery

Windows XP Design ExampleWindows XP Design Example

Windows XP Design ExampleWindows XP Design Example

If OSPM runs _OSC, platform checks fornative discoveryDevice(PCI0) // Root PCI bus {

Name(_HID,EISAID("PNP0A08")) // PCI Express Root Bridge

Name(_CID,EISAID("PNP0A03")) // Compatible PCI Root Bridge

Name(SUPP,0) // PCI _OSC Support Field value

Name(CTRL,0) // PCI _OSC Control Field value // bit flags for capabilities supported

Method(_OSC,4) { // Check for proper UUID and revision ID {

// Disable GPEs and unload support if OS granted native control.

If(And(CTRL,0x01)) // Hot plug control granted? {

Store(0,HPCE) // clear the hot plug SCI enable bit

Store(1,HPCS) // clear the hot plug SCI status bit

Unload (EXC1)

Unload (EXC2)

}

} // End _OSC

} // End PCI0

PROPOSAL IN

PROGRESS

Check for nativediscovery capabilityand if supported, disable BIOS discovery and unload ACPI dependency tables

System INF: User Friendly NameSystem INF: User Friendly Name

System builder provides an Operating System INF file that associates a user-friendly, meaningful name (‘ExpressCard Slot 1’) that matches the _HID*FOO2005.DeviceDesc=“ExpressCard Slot 1”

*BAR2005.DeviceDesc=“ExpressCard Slot 2”

PROPOSAL IN

PROGRESS

How The Example WorksHow The Example Works

EXCx has a status method (_STA) that sets or clears a “device present” bit based on insertion and removal events

BIOS issues bus check in response to a PCI Express link insertion / removal event – this handles the surprise removal event

Indicates to OSPM the need to run the PnP enumeration operation

Use the PCI Express event as the start mechanismThis event is the re-directed presence detect interrupt generated by the PCIe port upon discovery of a down-stream device

Result: a parent device appears in the hot-plug applet and “removing” it will remove any combination PCI Express and USB device that are in the slot

Based on the _STA status, the parent device will disappear from the hot-plug applet when the device is no longer present

PROPOSAL IN

PROGRESS

The Longhorn SolutionThe Longhorn Solution

Longhorn will not rely on ACPI for discoveryLonghorn will perform the discovery process natively

Both insertion and removal, just like USB today

How Longhorn will understand the physical dependencies

When a PCI Express device is inserted, the bus drivers (USB and PCI Express) will extract the GUID, if present

Each will “ask” the other if it has a device with this serial number

If yes, when its device is stopped, it will “talk” to the other bus driver and “ask” to stop that device also

InteroperabilityInteroperability

Three Interoperability Events already completed20 platforms and 15 modules to date

50% of the units fail to pass at these events!Discovery (failure to detect insertion and / or removal)

Returning from suspended state upon insertion or removal

Failure to support bridge requirements

Don’t bring platforms and modules that are less than production intent to these events

System swapping will not pass

Mechanical requirements are as integral as electrical

Windows XP Professional SP2 is preferred OS

Discovery and Sx StatesDiscovery and Sx States

Behavioral Failure - Module Insertion/Removal During and Across Sx States

The Standard requires that insertion and removal events will not cause a resumption to the S0 state

Returning to S0 on insertion or removal is a common failure

Device presence changes during suspend state and fail to be reported when returning to S0

When returning to S0 from a lower power state, BIOS must check for and report device presence changes

Ensure all ExpressCard ports (USB Low-, Full- and High-Speed and PCI Express) are checked

Comm

on

Interoperability

Problem

Interoperability Troubleshooting Aids and TipsInteroperability Troubleshooting Aids and Tips

Use device manager to watch devices come and go

Make sure the device tree and hot-plug system tray tool reflect the same states

Some devices won’t appear in system tray tool if not necessary, e.g. HID devices

Expect delay in device tree update upon resume from low power system state

If a yellow exclamation point or question mark appears

Check for possible error code associated with it for clues regarding failure

Interoperability Troubleshooting Aids and TipsInteroperability Troubleshooting Aids and Tips

Open the Device Manager and leave it open during the exercise

Including suspend state and hibernation testing!

Watch devices appear and disappear in the device tree as they are inserted and removed

Device tree presence should track with the remove request icon

If they don’t, the sequence may leave a clue

Before module insertedBefore module inserted

Using the Device Manager as a Using the Device Manager as a Troubleshooting ToolTroubleshooting Tool

Module inserted OKModule inserted OK


?

Module removed but Module removed but device driver remains device driver remains

??


Windows Logo Requirements for LonghornWindows Logo Requirements for Longhorn

PCI Express based modules must implement ASPM link states including support for the L0s and L1 states

PCI Express based modules must enable ASPM link state L1 by default

Mobile systems must initialize ExpressCard links with ASPM L0s state enabled

Modules implementing both USB and PCI Express interfaces must implement the common GUID as defined in the ExpressCard Standard

Longhorn will use this to identify and establish the physical dependency for modules that implement both interfaces

Session OutlineSession Outline

ExpressCard TechnologyBrief overview of ExpressCardKey behavioral characteristics

Compliance testing and Windows Logo requirementsBehavioral topics

Current OS support for graceful removalLonghorn support

Mechanical topicsThermal considerations

Electrical topicsPCI Express reset timing and reference clock controlPCI bridge support for modules under current OSs

Thermal Design ConsiderationsThermal Design Considerations

Host slot design needs to support an increased thermal dissipation spec for ExpressCard/34* modules

Compliance requirements for thermals being added

Host shall not exceed maximum ambient slot temperature of 65ºC

Steady-state measurement in un-powered but filled slot using latest BAPCo SYSmark* as stimulus

Module TDP set at 2.1W independent of module size

Or meet a 90ºC maximum surface temperature limit

Under a “reasonable but high performance usage” condition

Specification

Update

PERST# Reset Timing for Mobile DevicesPERST# Reset Timing for Mobile Devices

Reset release from power valid time (TPCRL) can be much less for mobile platforms than desktops - as short as 1ms

Additional initialization time following end of reset available

PCIe* Ref Clock Control With CLKREQ#PCIe* Ref Clock Control With CLKREQ#

Reduce EMI/EMC in absence of PCI Express module

Reduce clock power during L1 link power state: dynamic clock control

Up to 60mW per clock savings

CLKREQ# support required by moduleDynamic clock control support mandated for all but original 1.0-compliant modules

Specification

Update

Required to Implement CLKREQ#Required to Implement CLKREQ#

Clock source needs to support clock output gating

Multiple configurations possible depending onNumber of slots/sockets that are in platform

Number of independent clock controls supported by the clock source

PCI Express Capability StructurePCI Express Base Specification Revision 1.1

Link Capabilities Register (offset 0Ch) : Clock Power Management (bit 18) indicates support in the module

Link Control Register (offset 10h) : Enable Clock Power Management (bit 8) enables the feature on the port

CLKREQ# Design Example #1: CLKREQ# Design Example #1: “Best”“Best”

Independent clock control using devices with multiple control inputs: e.g. DB800

ExpressCardSlot

CLKCLKREQ#

ExpressCardSlot

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

ClockDriver

CLK1OE1#CLK2OE2#CLK3OE3#CLK4OE4#

CLK_

3.3V 3.3V 3.3V 3.3V

Stop

CLKREQ# Design Example #2: CLKREQ# Design Example #2: “OK”“OK”

Hybrid clock control using devices with limited inputs: e.g. DB400 & some CK410M variants

ExpressCardSlot

CLKCLKREQ#

ExpressCardSlot

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

ClockDriver

CLK1OE1#CLK2OE2#

CLK3

CLK4

CLK_

3.3V

3.3V 3.3V

Stop

CLKREQ# Design Example #3: CLKREQ# Design Example #3: “Worst”“Worst”

Dependent clock control using devices with limited inputs: e.g. CK410M

1234

ExpressCardSlot

CLKCLKREQ#

3.3V

ExpressCardSlot

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

PCI ExpressDevice

CLKCLKREQ#

ClockDriver

CLKCLKCLKCLK

CLK Stop_

Dynamic Clock ControlDynamic Clock Control

CLKREQ# de-assertion allows host to park the reference clock & module to shut off PLL

Module asserts CLKREQ# to return to L0Do not rely on REFCLK to detect need to return to active state


Firmware Failure: PCI Bridging on Modules

Modules can implement multiple PCI functions leading to on-module bridging

Hot-plug bridge support needs to be comprehended in host system BIOS when configuring PCI Express bridges used for ExpressCard slots

Implication is for current OSsBus numbering: need to cover child buses that may appear

Memory and I/O range: need to reserve adequate ranges to cover multiple end-points

Comm

on

Problem


PCI Bridging on Modules

On module child buses increase gap needed in root port bus numbering

Comm

on

Problem

Conventional PCI Endpoints Multiple PCI Express Endpoints



Platform BIOS shall allocate resources at boot time for each ExpressCard slot

Enables current Operating Systems to subsequently configure hot-plug devices

Module vendors are advised not to exceed specified minimum allocations for best compatibility across platforms

If exceeded, could lead to configuration errors

PROPOSAL

IN PROGRESS

Minimum Allocations

Bus numbering Eight (8) per slot Allows up to six on-

module end-points



Proposed bus numbering requirements

PROPOSAL

IN PROGRESS



Proposed memory & I/O range requirements

PROPOSAL

IN PROGRESS

Minimum Allocations

Memory window 128M per slot

Shared equally between prefetchable and non-prefetchable BARs

I/O range 4K per slot Only available to the first

downstream PCIe port (see below)

4K I/O4K I/O

No I/O X

Locate all legacy I/O needs here

Call to ActionCall to Action

Take your products to the next PCMCIA ExpressCard compliance event

Watch www.expresscard.org for details

Provide feedback regarding interest in detailed ExpressCard development seminars

Contact experts @ pcmcia.org

Community ResourcesCommunity Resources

Windows Hardware & Driver Central (WHDC)www.microsoft.com/whdc/default.mspx

Technical Communitieswww.microsoft.com/communities/products/default.mspx

Non-Microsoft Community Siteswww.microsoft.com/communities/related/default.mspx

Microsoft Public Newsgroupswww.microsoft.com/communities/newsgroups

Technical Chats and Webcastswww.microsoft.com/communities/chats/default.mspx

www.microsoft.com/webcasts

Microsoft Blogswww.microsoft.com/communities/blogs

Additional ResourcesAdditional Resources

PCMCIAwww.expresscard.org for specifications and compliance support

experts @ expresscard.org for the ask-the-experts line specific to ExpressCard technology

Interface specificationswww.pcisig.com for PCI Express specifications, design collaterals and compliance support

www.usb.org for USB specifications and compliance support

Microsoftwww.microsoft.com/whdc/default.mspx for Windows Hardware and Driver Central

www.microsoft.com/whdc/system/bus/pci/default.mspx - PCI and PCI Express: Architecture and Driver Support

http://www.microsoft.com/whdc/winlogo/downloads.mspx - Windows logo program

Intelwww.intel.com/technology/pciexpress/devnet for Intel Developer Network for PCI Express Architecture

how to implement expresscard solutions on mobile platforms ken stufflebeam hardware evangelist...

Documents

windows longhorn

benefits of graceful

windows xp

data slide

module removal desirable

expresscard solutions

toolbar surprise removal

cleanup slide