1. October 10, 20001

2. 2 USB 2.0 Software Roadmap & Architecture Update Robert Ingman Lead Program Manager Windows Division Microsoft Corp.

3. October 10, 20003 Software Roadmap Agenda w Microsoft plan w Microsoft’s ship criteria w “Early adopter” plan w Current status w USB 2.0 and storage devices

4. October 10, 20004 Microsoft Plan w Tentative “early adopter” USB 2.0 driver support for Windows 2000 in Q1, 2001 – Only if hardware is ready in time – Why Q1 next year? Hardware won’t be ready this year… w Tentative full USB 2.0 support in Windows “Whistler” releases in 2001 – consumer, workstation, and server releases w Tentative back-ports of USB 2.0 driver support by mid-2001 for Windows Me and Windows 98 SE w No driver support for Windows 98 gold

5. October 10, 20005 Why Windows 2000 First? w Windows 2000 is our USB 2.0 development platform – We develop and test on Windows 2000 code base first anyway – Reduces risk – Reduces test burden w Windows 2000 is Microsoft’s strategic foundation for all future OS efforts – Paves the way for USB 2.0 support in Windows “Whistler” and beyond w Enables early focus on business/commercial customers and “prosumers”

6. October 10, 20006 Microsoft’s Ship Criteria w Before Microsoft USB 2.0 driver stack ships, for any Windows OS, we need at least 3 months of solid end-to-end testing with the following hardware: – Production-quality USB 2.0 host controllers from at least 2 vendors – Production-quality USB 2.0 hubs from at least 3 vendors – Production-quality USB 2.0 peripherals from at least 6 vendors

7. October 10, 20007 “Early Adopter” Plan w “Early adopter” OEMs and IHVs should plan to spend time & resources at Microsoft this fall – We need MORE HARDWARE to test with! – Can you help? w 3-month final test pass for Win2000 can start only when we have enough production-quality hardware to test with w USB 2.0 host controllers, hubs, and peripherals as specified by our ship criteria need to be part of the entire test pass

8. October 10, 20008 “Early Adopter” Test Flow w First at Intel for hardware debugging – Low-level electrical work – Bus signaling work – Any work that requires extensive use of scopes, etc – Compliance and interop testing w Then at Microsoft when you are ready to – Have your device enumerated by a 2.0 host controller – Have Windows load a driver for it

9. October 10, 20009 Current Software Status w New USB 2.0 driver stack up & running – New port driver – New mini-port drivers for UHCI, OHCI, and EHCI w 2.0 HS interrupt and bulk is functional w Classic FS bulk works behind 2.0 hub/TT w Areas that need more work: – Classic LS devices behind 2.0 hub/TT – Classic FS isoch behind 2.0 hub/TT – 2.0 HS isoch w Test tools are being developed in parallel As of October 9, 2000

10. October 10, 200010 Current Hardware Status w Early testing of USB 2.0 driver stack on Win2000 with the following hardware: – Host controllers and hubs from one vendor – IDE-to-USB2 bridges from 2 vendors – Scanner from one vendor – Generic, programmable test device from Intel As of October 9, 2000

11. October 10, 200011 USB 2.0 and Storage Devices w USB 2.0 is fine for secondary add-on storage w Microsoft has no plans in place currently to support a USB 2.0 storage device as the primary, bootable device – This means no support for system boot partitions, paging, hibernation, or crash-dumps w “Recovery boot” from USB 2.0 CD-ROM drive will be supported, but requires specific BIOS support as well (El Torito specification) w Boot to MS-DOS from USB floppy done via BIOS support as well – El Torito or legacy emulation

12. October 10, 200012 Architecture Agenda w Overview of new USB 2.0 driver stack w USB Driver Interface for 2.0 w New USB UI for 2.0 w Selective Suspend w Conclusion

13. October 10, 200013 New USB Driver Stack w New USB port driver and mini-port driver for each host controller type replace monolithic Win9X/Win2000 host controller drivers – Port driver handles PnP, power mgmt, and other OS stuff – Mini-port drivers talk to the hardware w New generic parent/composite device driver w Hub driver now loads for hubs only (and not for composite devices) w New driver architecture reduces dependencies and isolates specific functionality in dedicated drivers

14. October 10, 200014 USB Driver Stack in “Whistler” USB Host Controller PCI Enumerator USBUhci.SysUSBUhci.SysUSBOhci.SysUSBOhci.Sys USBccgp.SysUSBccgp.Sys USBport.SysUSBport.Sys Client Driver USBhub.SysUSBhub.Sys USB Driver Interface (in DDK) USBEhci.SysUSBEhci.Sys Not Committed Yet! USBD.SYSUSBD.SYS

15. October 10, 200015 USB 2.0 Added to Win2000 USB Host Controller PCI Enumerator UHCD.SYSUHCD.SYSOPENHCI.SYSOPENHCI.SYSUSBPORT.SYSUSBPORT.SYS CLIENT DRIVER USBHUB.SYSUSBHUB.SYS USB Driver Interface (in DDK) USBEHCI.SYSUSBEHCI.SYS USBHUB20.SYSUSBHUB20.SYS USBD.SYSUSBD.SYS

16. October 10, 200016 Bulk, Interrupt, & Isochronous Classic 1.0/1.1 Devices w Connected to 2.0 HC via USB 2.0 hub/TT w USB Driver Interface remains exactly the same – Client drivers do not need to change w Transaction Translator support is built into USBEHCI mini-port driver w Some changes required to MS Hub driver – USBHUB.SYS updated in “Whistler” – USBHUB20.SYS for W2K and Win9X

17. October 10, 200017 2.0 High-Speed Devices w USB Driver Interface remains exactly the same w Client drivers do not need to change – Device just runs at higher speed – For example, the USB mass storage class driver in Windows 2000 does not need to be changed Bulk & Interrupt

18. October 10, 200018 2.0 High-Speed Isochronous w USB 2.0 isoch has micro-frame resolution – 8 packets per ms instead of 1 packet per ms Options: 1.Allow client drivers to submit 1 packet-sized data buffers – Would require new USB Driver Interface – Would introduce huge burden on system (8000 IRP’s/sec) 2.Keep min. data buffer size the same as for FS isoch – Data buffer must be able to hold at least 1ms worth of data – No need to expose current micro-frame number to client driver – USB Driver Interface can remain the same as for FS isoch w Plan is to go with option 2

19. October 10, 200019 USB UI Overview w Property pages in Device Manager: – Host controller bandwidth allocation (“Advanced” tab) – Hub power information per port (“Power” tab) w Pop-up error dialogs – Hub power exceeded (e.g. camera plugged into bus-powered hub) – Over-current/electrical surge on hub port – Failed bandwidth allocation – Cascading of more than 5 hubs – Enumeration failure (new in “Whistler”) – Non-unique serial numbers (new in “Whistler”)

20. October 10, 200020 New UI for USB 2.0 w Device Manager property pages will include USB 2.0 HC’s and hubs as well w New pop-up dialogs to cover new basic scenario: – 2.0 hub/device plugged into classic root port or hub w User will be guided to plug in 2.0 device into 2.0-capable port instead: – Free 2.0 port does exist: plug it in – Free 2.0 port does not exist: swap 1.0/2.0 devices – All 2.0 ports have 2.0 devices plugged in: trade device – System isn’t 2.0-capable: warning dialog

21. October 10, 200021 Selective Suspend w Allows individual devices to be selectively suspended (D2) when idle even when system itself is fully awake (S0) w Allows root ports to be suspended if all USB devices are idle, and the HC can be put into a low-power state (C3) – Will result in battery power savings for mobile systems w Scheme is cooperative, and requires that all devices + drivers go into idle state when inactive w Client drivers must be able to put devices into a low-power state even when system itself is awake w Microsoft will rev HID/keyboard/mouse, storage, and printer driver stacks to take advantage of this new feature w Sample driver in “Whistler” DDK (beta2) New Feature in “Whistler”

22. October 10, 200022 Selective Suspend w Power down – New IOCTL in USBHUB that client driver calls when device is idle – Callback routine tells client driver to power down device using standard PoXxx call – NOTE: client driver must post WAIT_WAKE IRP for wake-up capable device before powering down device w Power up – Wake-up capable device generates standard resume signaling when “activated” by the user, WAIT_WAKE IRP gets completed, and client driver issues Set_D0 request to device OR – Client driver issues Set_D0 request to device in response to host software “activation” Continued

23. October 10, 200023 Conclusion w USB 2.0 driver development work leverages what was done for USB 1.0 – Re-use of USB1.x driver code reduces risk w Microsoft’s USB team is staffed and fully committed to USB 2.0 w Microsoft’s ability to support USB 2.0 “early adopters” is gated on the early availability of enough host controllers, hubs, and peripherals

24. October 10, 200024 Call to Action w USB 2.0 driver support for Windows is gated on hardware availability – Contact us as soon as you are ready to work with us – Send email to MSUSB2@MICROSOFT.COM w Get on the Windows “Whistler” Beta program – Send email to USB-BETA@MICROSOFT.COM w Get the USB 2.0 PDK – Details on http://www.usb.org/developers/usb20/ – Includes Win2000 pre-release drivers from Microsoft