Difference between revisions of "USB Stack"
m (added page to category Documentation)
|Line 136:||Line 136:|
Revision as of 11:01, 3 December 2008
The USB stack is the component which provides the communication between USB devices and their respective drivers and applications. It consists out of multiple files, each with a distinct function. The USB stack in ReactOS is currently extremely limited. This page documents the development of the new USB stack. Development on a USB 3 stack is not planned until around 2010 as hardware won't be available for it in sufficient quantities until then.
The goal is to develop a USB stack which:
- is USB 1.1 - 2 compliant
- uses WDM (NT 5) API
- is compatible with all USB devices and drivers (which adhere to the standard)
The entire stack will be fully documented and the implementation progress detailed on this page.
2008/12/03 - The ROS USB stack specification is being written. The first draft will be ready in a few weeks.
- USB.org's USB 2 specification.
- various books and sites on the WDM model, to be expanded later.
Historical (outdated) information
The information here is largely outdated and irrelevant to current development. It is shown here for historical purposes, later it may be moved to its own page or removed.
Roadmap of USB development for ReactOS
After some thinking and talking to X-Box guys, I decided to try implementing part of ReactOS USB Stack with help of a Linux USB Stack, but in a very special flavour - which is abstracted from Linux kernel, and from hardware also (this implementation is used in Cromwell).
So now we have two concurrent tasks going on:
- Porting Cromwell usb stuff to ReactOS (I already make it compiling into usbcore.sys and ohci.sys - this all is placed at reactos/drivers/usb/cromwell/, but hardware interface needs to be changed to use HAL)
- Creating compatible interface to higher level of USB drivers (e.g. Class drivers, etc) - so we can have compatibility with Windows XP here. This involves creating a usbport.sys driver, which have all IRPs and IOCTLs stubbed, and then we can fill it with calls to the ported usbcore.sys and ohci.sys.
- Creating drivers for other host controllers (currently only OpenHCI is done in Cromwell's usb drivers). Universal HCD would be a very nice thing to do, I think the best way is to get uhci hcd from linux stack, and adapt it to ReactOS.
- Creating class drivers and other higher-level stuff -- we can test our lower level drivers with class drivers from WinXP.
As there seems to be some interest in the current status of USB support on ReactOS, I'm going to keep a current status section on this wiki page.
Oct 19 2005
- Both OHCI and UHCI USB controllers work: they are detected, initialized and they detect connected devices, which are reported to Plug-and-play manager.
- Basic drivers for USB mice and keyboards are provided (but *disabled* due to a conflict with I8042prt driver)
- USB stack is fully PnP compliant, so it should work on every hardware without the need to add some registry entries as previously.
- About source files: They now live in reactos/drivers/usb/. OHCI and UHCI are in reactos/drivers/usb/miniport/xHCI and share most of their code.
- Work in progress: Fireball is now changing the code from a polled mode to an interrupt mode, to consume less CPU resources.
Aug 3 2005
- OHCI Drivers from Cromwell/Linux work under Microsoft Virtual PC. They initialize the hardware controller and the main hub, and they detect connected devices, and URBs can be transfered. On Xbox (which also has USB with OHCI controllers), connected devices are not reported. It may be due to the fact that Xbox has 2 USB controllers. The problem is under investigation.
- UHCI Drivers still don't work at the moment. The hardware controller and the main hub are initialized, but no connected device is detected.
- In both cases (OHCI and UHCI), main hub is reported to ReactOS plug-and-play manager. Connected devices are still not reported.
Feb 20 2005
- Initial working implementation of UsbCore+OHCI Drivers from Cromwell/Linux. They do everything needed, two things left:
1) make them running better (in fact currently there are an active waiting inside a thread - this wastes resources greatly - should be changed by WaitForSingleObject, and second - implement stubs for spinlocks - I think they are needed)
2) Understand public interface of Microsoft's usbport.sys/usbhub.sys, and implement it in usbcore/Xhci.
- I'm working on porting uhci from Linux now also. Since OHCI seems to be a rare controller, very few people can test it. But it isn't that straightforward (dma, etc), but I hope I can do it.
Feb 2 2005
- Started implementing the basics of USBPORT.SYS. It now keeps the large struct passed in from a miniport in a driver extention. This happens when the miniport registers itself with USBPORT.SYS.
- Added stubbed implementations for AddDevice, DispatchCreateClose, DispatchDeviceControl, and Unload. Still more to do to make these things actually work.
- Started stubbing out the IOCTLs for USB.
TO DO LIST
- NOTE: None of this work has been committed yet. I'm just keeping up with my promise to keep this status basically up to date.
- We need to implement USBD.SYS since that is mainly a library (in the XP stack) with utility routines for processing URBs. This would be a nice simple project for some one to do if they want to get started helping with the USB stack.
- We need to port uhci support from Linux to the Cromwell framework. VMWare on Windows does not have an ohci controller (the controller we currently have ported) so any testing in VMWare (and on lots of hardware platforms) will be useless without uhci.
- We need to port ehci support from Linux to the Cromwell framework. This will give us support for USB 2.0 hubs and devices.... well eventually anyway...
So any complaints about the slow pace of USB stack implementation can be sent to /dev/null. Any help would be welcome.
Jan 27 2005
- Committed initial port of Cromwell's USB stack. Need to port all hw calls to HAL.
Jan 17 2005
- USB stubs are committed to SVN with the paths listed on this page. Actually this happend earlier, but I figure that I might as well start this list somewhere.
- Building the headers for the ROS ddk to spec in the USBHUB.SYS -> USBPORT.SYS interface. This interface is not documented super well, but much of the needed information can be gathered online.
- Adding usb to the main ROS build.
- Adding the usbuhci startup registry entries to hivesys.inf. After this we can see USBUHCI.SYS and USBPORT.SYS actually load. They won't do anything, but at least they will load. Well... it's a start.
/reactos/ /reactos/drivers/ /reactos/drivers/usb /reactos/drivers/usb/usbport /reactos/drivers/usb/miniport/usbuhci /reactos/drivers/usb/miniport/usbehci /reactos/drivers/usb/miniport/usbohci /reactos/drivers/usb/usbhub /reactos/drivers/usb/usbd /reactos/drivers/cromwell/...
This driver is the main port driver for USB host controllers. In a nutshell, it receives all IRPs and IOCTLs, and translates them into information that is useful for miniports. It is responsible for managing all the host controllers on the system. Each host controller type is managed by a miniport driver.
The interface between the port driver and its miniports is not published or documented anywhere. This means that we are relatively free to implement this any way we choose. The plan is to try to leverage the host controller driver implementation from the Linux kernel (at least as a reference), and define our own protocol.
USBPORT.SYS does provide a public interface, and it understands a known list of IOCTLs. We must make sure that our version of USBPORT.SYS manages its public interface in a manner consistent with the USB stack on Windows XP.
This is the miniport for UHCI USB controllers.
This is the miniport for EHCI (USB 2.0) controllers.
This the miniport for OpenHCI USB controllers (this one is needed for XBOX-ReactOS project).
This is the USB hub driver.
This is a legacy USB bus driver from the Windows 2K system. In Windows XP it simply delegates all its methods to USBHUB.SYS and USBPORT.SYS. We will do the same thing in ReactOS (aiming WinXP was discussed many times, and considered finally a good choice than targeting old usb architecture of Win2k).
Windows XP (and ReactOS) USB Stack Startup
--thoughtfully provided by Ryan O'Connor (Polonium)