System software also uses the Configure Endpoint Command to inform the xHC of pipe changes due to selecting an Alternate Interface on a device. Typically an Alternate Interface setting is used to modify the payload size or bandwidth requirement of a pipe, however it may also be used to disable or enable one or more pipes. The Input Control Context data structure of the Input Context allows software to explicitly identify which pipes are enabled, disabled, or modified by a target Alternate Interface setting. The parameters of the Input Endpoint Contexts for enabled or modified pipes shall correlate target pipe settings (Endpoint Type, Max Packet Size, etc.). If the Configure Endpoint Command does not complete successfully, software shall not issue a SET_INTERFACE request to the device.

The Configure Endpoint Command points to an Input Context data structure, which defines the target configuration parameters for the xHC. For proper operation of the xHC, every endpoint that will be enabled by a target device configuration shall be defined in a respective Endpoint Context data structure of the Input Context, and the parameters of the Endpoint Contexts shall correlate target endpoint settings (Endpoint Type, Max Packet Size, Burst Size, etc.). xHC and device behavior will be undefined if there are any mismatches. This also means that if the Configure Endpoint Command does not complete successfully, software shall not issue a SET_CONFIGURATION request to the device.

The Disable Slot Command is issued by software to inform the xHCI that a Device Slot is no longer needed, and that any resources assigned to the slot can be released. This command would be issued when a device is detached from the USB. A disabled Device Slot is available for assignment by the Enable Slot Command.

The Enable Slot Command is issued by software to obtain an ID for an available Device Slot. System software uses the Slot ID returned by the command as an index into the Device Context Base Address Array to link a Device Context data structure for the USB device to a xHC Device Slot.

The No Op Command may be issued by software to exercise the TRB Ring mechanism of the xHC without affecting any xHC or USB Device state, or to report the current value of the Command Ring Dequeue Pointer. Refer to section 4.6.2 for more information on the No Op Command.

Evaluate Context Informs xHC that software has modified selected Context parameters. Reset Endpoint Resets selected Endpoint. This command is used to recover from a halted endpoint. Stop Endpoint Stops or aborts operation on selected Endpoint. Set TR Dequeue Pointer Updates the Transfer Ring Dequeue Pointer of an enabled endpoint. Reset Device Resets selected Device Slot. This command is used to synchronize the state of a Device Slot when resetting a USB device. Force Event Used with virtualization by a VMM to force a TRB on to an Event Ring owned by a VM. Negotiate Bandwidth Initiates Bandwidth Request Events. Set Latency Tolerance Used by software to set the Best Effort Latency Tolerance (BELT) value for the xHC. Get Port Bandwidth Provides a means for software to identify the periodic bandwidth available on xHC Root Hub Ports. Force Header Allows software to generate SS LMPs or TPs to a Root Hub Port

No Op Tests TRB Ring mechanism Enable Slot Returns a Device Slot ID and transitions the Device Slot from the Disabled to the Default state. Disable Slot Transitions the selected Device Slot from any state to the Disabled state. Any pending transfers are terminated and the slot is made available again. Address Device Enables the Default Control Endpoint, optionally issues a SET_ADDRESS request to the USB device, and transitions the Device Slot to the Addressed state. Configure Endpoint Enables and/or Disables selected endpoints for the device.

The table below provides a summary of the xHCI command set. The remainder of this section provides a high level description of each of the commands.

Commands are executed by the xHC in the order that they are placed on the Command Ring. System software may add CDs to the Command Ring while it is running, however the execution of CDs should be stopped if software wants to delete or reorder (i.e. raise the priority of) scheduled CDs. Special Command Ring controls allow commands to be stopped or aborted.

All commands result in a Command Completion Event being placed on the Event Ring, which reports the completion status of the command.

To manage the xHC and the devices attached to it, the xHC provides an independent Command Ring interface. A work item on a Command Ring is called a Command Descriptor (CD). Command Ring operation is very similar to that of Transfer Rings, software issues a command to the xHC by placing a CD on the Command Ring then rings the Host Controller doorbell. The size of the Command Ring can be modified using the same Link TRB mechanism that Transfer Rings use.

When system software issues a SET_CONFIGURATION request to a USB Device, it enables a specific set of endpoints (pipes) in the device, which are defined by the respective Configuration Descriptor. To simplify the xHC hardware implementation, the xHC does not read descriptors from a device or monitor SET_CONFIGURATION (or SET_INTERFACE) requests to a device. Instead, the xHC depends on system software to coordinate the pipes configured in the xHC with those configured in the device. System software uses the Configure Endpoint Command to explicitly identify to the xHC the pipes that would be enabled by a target configuration and the characteristics of those pipes. Not only does the Configure Endpoint Command inform the xHC of the target USB Device configuration, but it also gives the xHC an opportunity to reject a configuration if the necessary USB bandwidth or xHC internal res ources are not available.

A Transfer Ring may include an Event Data TRB. Rather than pointing to a Data buffer this TRB contains a 64-bit value which software may use to tag a TD and generate a special Transfer Event to pass that tag back to software when the TD is complete. Refer to section 4.11.5.2 for more information.

Figure 3-6 illustrates a Transfer TRB Ring with multiple pending TDs. The Enqueue Pointer identifies the next TRB location available to system software for scheduling work (TDs) to the Ring. The Dequeue Pointer identifies the next TRB in the Transfer Ring to be executed by the xHC. Upon completion of a Transfer TRB, the Length and Status of the transfer may optionally be reported in a Transfer Event TRB. Refer to section 6.4.2.1 for more information on the Transfer Event TRB.

The Control Dword in the TRB shall contain a TRB Type field and may contain one or more of the following fields: Chain (CH), Interrupt On Completion (IOC), Immediate Data (IDT), No-Snoop (NS), Interrupt-on Short Packet (ISP), Start Isoch ASAP (SIA), and Frame ID. Refer to section 6.4.1 for more information on the contents and use of the Transfer TRB Control Dword.

The Data Buffer Pointer field of a TRB provides byte granularity for data addressing. The Length field, which resides in the Status Dword, identifies the size of the buffer referenced by the Data Buffer Pointer. The maximum value the Length field may contain is 64K. When Length bytes are transferred, the next TRB in the ring is automatically accessed by the xHC. It is system software’s responsibility to ensure that the Length field is consistent with any Page crossings that may be encountered.

The longer a system is running, the harder it is to find contiguous pages in physical memory. If due to runtime changes in workload demands, hot -plug events, etc., the host needs to increase the size of an existing Transfer Ring or allocate a multi-page Transfer Ring, then a special Link TRB may be used to extend a ring to include additional non-physically contiguous Segments.

For small, single buffer operations (of which many are required in the USB protocol) a TD will be composed of a single TRB. For large multi-buffer operations (e.g. Scatter/Gather), TRBs can be chained to form a complex TD. The small size of the TRB data structure allows up to 256 individual buffers to be defined in a 4K Segment (page of memory).

A Transfer Request Block (TRB) is a data structure constructed in memory by software to transfer a single physically contiguous block of data between host memory and the xHC. TRBs contain a single Data Buffer Pointer, the size of the buffer, and some additional control information.

By including this definition, you can create a patch.xp3 file with its original folder structure. Remember to move the Config.tjs file to the root directory (originally located in the system folder), as Config.tjs is read before the Kirikiri engine gains the ability to read folders.

By default, Kirikiri only reads data in the root directory of the patch.xp3 file. This can result in an ugly internal structure, as all data including images, tjs, and scenarios are collected in one folder. Moreover, it does not allow files with the same name that were previously in different folders. However, there is a way to make the KAG engine read the folder structure within patch.xp3. This can be achieved by adding a definition in the Config.tjs file. Here’s an example of the patch’s structure definition inside Config.tjs:

Understanding the Structure of patch.xp3

3. Click “Process” and wait until the process is completed. 4. Copy the newly created xp3 file into the root folder of your game.

To repack the translated materials back into an xp3 file, you can use the Translator++ xp3 repacker tool. Here’s how you can create an xp3 patch:

1. Export (not inject) your project into a blank folder. 2. Open the Translator++ XP3 repacker tool and select the directory you created in the previous step in the “Select directory” field. Also, select the target xp3 file. Note: The naming of the xp3 files matters, as the content of patch2.xp3 will overwrite patch.xp3, and so on.

Second way of applying translation: Creating patch.xp3

First way of applying translation: Extracting data.xp3 into the data folder

Extract the contents of data.xp3 into the data folder. Various tools such as GarBro or KrkrExtract can be used to extract xp3 files. Inject or apply your translation. Important: Remove the original data.xp3 file. This ensures that the game will load the data folder instead.

This behavior allows us to create translations without modifying the original data.xp3 file or any of the original assets in the game. Instead, we can create a patch.xp3 file. Thus, there are at least two ways to inject mods or apply translations using the KiriKiri engine:

By default, the KiriKiri game reads resources in the specified folder/archive sequentially. If a script is found later, it will overwrite the previous resource. The order of resource reading is as follows:

For example, if there is a “first.ks” scenario in the Data folder, it will be overwritten by the “first.ks” in data.xp3. Similarly, the “first.ks” in data.xp3 will be overwritten by the version found in patch.xp3, and so on.

After a Transfer Ring is initialized Transfer Descriptors (comprised of one or more TRBs) may be placed on it. A “ring” is formed by the placement of a special Link TRB at the end of a Transfer Ring which jumps the TRB execution back to its beginning.

The Transfer Ring Enqueue and Dequeue Pointers are not accessible through physical xHC registers. They are logical entities, maintained internally by both system software and the xHC. Refer to section 4.9.2 for more information on Enqueue and Dequeue Pointers.

In the simplest case, software defines a Transfer Ring by allocating and initializing a memory buffer for it, then setting the Enqueue and Dequeue Pointers to the address of this memory buffer and writing it into the TR Dequeue Pointer field of the associated Endpoint or Stream Context. Each memory buffer that comprises a Transfer Ring is called a Segment. Multiple Segments may be linked together to form large rings, and Segments may be added or removed from a ring during runtime. A Transfer Ring is empty when the Enqueue Pointe r equals the Dequeue Pointer.

A Transfer Ring exists for each active endpoint or Stream declared by a USB device. Transfer Rings contain “Transfer” specific TRBs. Section 4.11.2 for more information on Transfer TRBs.

Transfers to and from the Endpoint of a USB device are defined using a Transfer Descriptor (TD), which consists of one or more Transfer Request Blocks (TRBs, refer to sections 4.11 and 6.4). Transfer Descriptors are managed through Transfer Rings that reside in host memory. A Chain flag in the TRB is used to identify the TRBs that comprise a TD. Therefore, a TD refers to a consecutive set of TRB data structures on a Transfer Ring, where the Chain flag is set in all but the last TRB of a TD. Note that a TD may consist of a single TRB, whose Chain flag shall not be set.

The Command Ring is used by system software to issue commands to the xHC. The Event Ring is used by the xHC to return status and results of commands and transfers to system software. Transfer Rings are used to move data between system memory buffers and device endpoints. Below is a description of the operation of a Transfer Ring. All ring types employ the same basic mechanisms to transfer information between the xHC and host memory.

A Ring is a circular queue of data structures. Three types of Rings are used by the xHC to communicate and execute USB operations:

One for each Endpoint or Stream

One for the xHC

One for each Interrupter (refer to section 4.17)

Refer to section 6.2.5.1 for more information on the Input Control Context.

For example: to set up the xHC to support a particular USB device configuration, software will initialize the Endpoint Context data structures of an Input Context with the target endpoint configuration information, insert a Configure Endpoint Command on the Command Ring that points to the Input Context, and ring the Host Controller Doorbell. The Input Endpoint Context information would include: type, Max Packet Size, Interval, etc. The Add flags in the Inp ut Control Context indicate which endpoints software wants to be added to the xHC’s list of valid endpoints, i.e. which Input Endpoint Contexts are valid. If the command is successful, the endpoint information in the Input Context is copied by the xHC

The Input Control Context data structure contains two groups of flags (Drop and Add) organized as bit vectors. The interpretation of these flags is command dependent, but generally they are used to indicate which endpoints are affected by the command and how.

Throughout this document Slot Context or Endpoint Contexts contained in an Input Context are also referred to as “Input” Slot or Endpoint Contexts. Refer to section 6.2.5 for more information on the Input Context.

The Input Context data structure is used by system software to define device configuration and state information that will be passed to the xHC by an Address Device, Configure Endpoint, or Evaluate Context Command. It consists of an Input Control Context data structure, followed by a Slot Context, and 1 -31 Endpoint Context data structures. The Input Control Context data structure qualifies which of the remaining contexts are affected by the command. After a command is complete, software may reuse or free the Input Context data structure.

The Stream Context data structure provides a pointer to the Stream’s Transfer Ring and provides some opaque (scratchpad) space for the xHC.

A Stream Context Array is employed to define the Transfer Rings of a USB3 endpoint that supports Streams. A Stream Context Array consists of Stream Context data structures. The number of Stream Context data structures in a Primary Stream Context Array and its location are defined by fields in the parent Endpoint Context. Figure 4-20 illustrates how a Stream Context Array may be used to extend the number of Transfer Rings that are supported by an endpoint.

An xHCI Reserved area of the Endpoint Context is available as an xHC implementation defined scratchpad.

As an Input Context member, the Endpoint Context data structure is used by system software to pass endpoint related command parameters to the host controller. In this document the Endpoint Context data structure of an Input Context is also referred to as “Input Endpoint Context”. If a command referencing an Input Context is successful, the xHC will update the Output Endpoint Context to reflect the parameter values that it is actively using to manage the endpoint prior to generating a Command Completion Event.

As a Device Context member, the Endpoint Context data structure is used by the xHC to report the current values of endpoint related parameters to system software. In this document the Endpoint Context data structure of a Device Context is also referred to as “Output Endpoint Context”.

The Endpoint Context also contains some fields that are helpful in debugging the transfer operations associated with the pipe. An Error Counter (CErr) may be used to force unlimited retries of USB transactions.

Note that the Device Context and Input Context data structures provide for all possible (31) endpoints that can be declared by a USB device. Most devices declare only a small number of endpoints, which means that many of the Endpoint Context data structures in a Device Context or Input Context may be unused.

Most of the fields of the Endpoint Context contain endpoint related type, control, state, and bandwidth information, that correspond to the information in the associated endpoint related descriptors reported by the device. An Endpoint Context also defines a TR Dequeue Pointer field, which norm ally provides a pointer to the Transfer Ring associated with the pipe. There is a special case for USB3 Bulk endpoints where Streams may be associated with an endpoint. Streams allow the data stream of an endpoint to be multiplexed between Transfer Rings by the device (refer to section 4.12 for more information on Streams). In this case, a level of indirection is introduced to access the Transfer Rings associated with the endpoint, and the Endpoint Context TR Dequeue Pointer field contains a pointer to a Stream Context Array data structure (commonly referred to as a Stream Array), where each Stream Context data structure in the array may contain a NULL pointer (if the Stream ID is not assigned) or point to the Transfer Ring or another Stream Context Array associated with the respective Stream.

The Endpoint Context data structure defines the configuration and state of a specific USB endpoint. This data structure is defined as a member of the Device Context and Input Context data structures. Refer to section 3.2.5 for information on the Input Context data structure.

An xHCI Reserved area of the Slot Context is available as an xHC implementation defined scratchpad. All Reserved fields in the Slot Context are for the exclusive use of the xHC and shall not be modified by system software except when the Slot is in the Dis abled state.

As an Input Context member, the Slot Context data structure is used by system software to pass command parameters to the host controller. The Slot Context data structure of an Input Context is also referred to as “Input Slot Context”. If a command targeted at a Device Slot is successful, the xHC will update the Output Slot Context to reflect the parameter values that it is actively using to manage the device prior to generating a Command Completion Event.

As a Device Context member, the Slot Context data structure is used by the xHC to report the current values of device parameters to system software. The Slot Context data structure of a Device Context is also referred to as “Output Slot Context”.

The information provided by the Slot Context includes; control, state, addressing, and power management. The Slot States reported by the xHC identify the current state of a device and map closely to the USB Device States described in the USB specification. The addressing informat ion is used for a variety of purposes; The USB Device Address, assigned by the xHC, is available for developers to trace device related USB activity with a bus analyzer. The Route String is used by the xHC to target Enhanced SuperSpeed packets. And the Speed, Parent Port Number, and Parent Hub Slot ID fields allow the xHC to execute the split transactions necessary to address low- and full-speed devices attached to high-speed hubs. The power management information includes the Max Exit Latency, used by the xHC to determine the scheduling of Isoch packets on the bus.

The Slot Context data structure contains information that relates to the device as a whole, or affects all endpoints of a USB device. This data structure is defined as a member of the Device Context and Input Context data structures. Refer to section 3.2.5 for information on the Input Context data structure.

‘0’. Ownership of the data structure is then passed to the xHC with an Address Device Command. The xHC maintains ownership of the Device Context until the device slot is disabled with a Disable Slot Command. The Device Context data structure shall be treated as read-only by system software while it is owned by the xHC.

The Device Context data structure is managed by the xHC and used to report device configuration and state information to system software. The Device Context data structure consists of an array of 32 data structures. The first context data structure (index = ‘0’) is a Slot Context data structure (6.2.2). The remaining context data structures (indices 1-31) are Endpoint Context data structures (6.2.3).

Note that the first entry (Slot ID = ‘0’) in the Device Context Base Address Array is utilized by the xHCI Scratchpad mechanism. Refer to section 4.20 for more information.

The Device Context Base Address Array (DCBAA) provides the xHC with a Slot ID based lookup table for accessing the Device Context data structure associated with each slot. This data structure consists of an array of pointers to Device Context data structures. When a device attach is detected: system software initializes a Device Context data structure, requests a Slot ID from the xHC, and inserts a pointer to the newly created Device Context into the DCBAA at the location indicated by the Slot ID.

The xHC is expected to run in virtual memory environments where the size of a contiguous block of physical memory will be limited by the Page size of the system. The data structures that the xHC uses to manage devices and endpoints are designed to accommodate this limitation, by either keeping the data structure under 4K Bytes (the minimum Page size supported), or providing mechanisms to link non-contiguous blocks of physical memory to form larger, logically contiguous data structures, e.g. circular queues of data structures t hat point to the data buffers used for transferring USB data to or from the host. The data buffers referenced by these data structures may be byte aligned and reference from 1 to 64K bytes of contiguous physical data.

All three types of rings support the ability for system software to grow or shrink them while they are active. Special TDs written to the Transfer and Command rings allow software to change their size, however since the Event Ring is read - only to software, the Event Ring Segment Table is provided so that software may modify its size.

A Transfer Ring is used by software to schedule work items for a single USB Endpoint. A Transfer Ring is organized as a circular queue of Transfer Descriptor (TD) data structures, where each Transfer Descriptor defines one or more Data Buffers that will be moved to or from the USB. Transfer Rings are

The Event Ring is used by the xHC to pass command completion and asynchronous events to software. The Event Ring shall be treated as read -only by system software. Refer to section 4.9.4 for a discussion of Event Ring Management.

The Command Ring is used by software to pass device and host controller related commands to the xHC. The Command Ring shall be treated as read-only by the xHC. Refer to section 4.9.3 for a discussion of Command Ring Management.

The Device Context Base Address Array supports up to 255 USB devices or hubs, where each element in the array is a pointer to a Device Context data structure.

The term Device Slot is used as a generic reference to a set of xHCI data structures associated with an individual USB device. Each device is represented by an entry in the Device Context Base Address Array, a register in the Doorbell Array register, and a device’s Device Context. The term Slot ID refers to the index used to identify a specific Device Slot. For example the value of Slot ID will be used as an index to identify a specific entry in the Device Context Base Address Array.

The Doorbell Array is an array of up to 256 Doorbell Registers, which supports up to 255 USB devices or hubs. Each Doorbell Register provides system software with a mechanism for notifying the xHC if it has Slot or Endpoint related work to perform. A DB Target field in the Doorbell Register is written with a value that identifies the reason for “ringing” the doorbell. Doorbell Register 0 is allocated to the Host Controller for Command Ring management.

The xHCI Extended Capabilities specify optional features of an xHC implementation, as well as providing the ability to add new capabilities to implementations after the publication of this specification.

The Runtime and Operational Registers specify host controller configuration and runtime modifiable state, and are used by system software to control and monitor the operational state of the host controller. These registers ar e partitioned as a function of those that are heavily accessed during runtime and those that are accessed only at initialization time or only lightly during runtime to better support virtualization of the xHCI.

The Capability Registers specify read-only limits, restrictions and capabilities of the host controller implementation. These values are used as parameters to the host controller driver.

The USB Base Address Register (BAR) in the PCI Config Space points to the base address of the xHC register interface. The xHC register interface consists of 4 major components: Capability Registers, Operational Registers, Runtime Registers, and the Doorbell Array. The Operational and Capability Regist ers are concatenated in MMIO space. The Runtime Registers are actually just an extension of the Operational Registers. Their partitioning allows the xHC to better support virtualization, by allowing the Runtime Registers to reside on a separate page boundary. A xHCI Capabilities Pointer mechanism (similar to that defined by PCI) is presented in the Capability Registers to point to new or optional capabilities of an xHC implementation.

The xHCI provides support for two categories of USB transfer types: asynchronous and periodic. Isochronous and Interrupt transfers are Periodic transfer types. Asynchronous transfer types include Control and Bulk. Figure 3-3 illustrates that the xHCI provides a homogeneous mechanism (Transfer Rings) for each category of transfer type.

This space is defined by the control data structures (Device Context Base Address Array, Device Contexts, Transfer Rings, etc.) and data buffers that are allocated and managed by the xHC Driver to enable the endpoint traffic of individual devices. This sp ace is allocated in the Kernel and User areas of the Memory Address Space.

The Register Space represents the hardware registers presented by the xHC to system software that reside in the Memory Address Space. The Register Space provides for the implementation - specific parameters defined in the xHCI normal and Extended Capabilities registers, the Operational and Runtime control and status registers, and the Doorbell Array used to flag accesses to individual USB devices. This space, normally referred to as I/O space, is implemen ted as Memory-Mapped I/O (MMIO) space.

Every xHC implementation shall include a means of identifying and enumerating the host controller by system software. This specification provides a PCI example of the Host Configuration Space, which is referred to as PCI Config Space. The PCI Config Space definition provides a working example of configuration space use for system xHC enumeration and resource (interrupt, power, virtualization, etc.) management.

The xHCI interface defines three interface spaces (refer to Figure 3-3):

The xHC always manages the respective speed USB devices connected to its Root Hub ports. Depending on the implementation, the resources of a USB bus instance (bandwidth, device addressability, etc.) may be presented on each root hub port, shared across multiple root hub ports, or a combination of allocations. This specification defines the registers and interfaces for the eXtensible Host Controller Interface.

Note that Figure 3-2 does not imply a particular xHC implementation, however the functional partitioning that it illustrates is useful for this discussion. The Host Interface Logic manages the Registers and DMA associated with the xHC.

The xHCI architecture allows the USB3 host controller to provide USB functionality for all speed devices without requiring, as in previous generations, companion controllers along with the associated software support for their respective drivers. The enhanced features of the xHCI architecture are key to delivering this simplified operating environment.

The xHCI is used for all communications to devices connected through the Root Hub ports of the USB3 host controller.

Native OS support for Device Classes allows a compliant device to provide a user with basic functionality if the vendor Device Class drivers are not available, however a vendor can define their own Class Driver to add value. Many commodity USB device vendors (mice, keyboard, etc.) take advantage of those provided by OS vendors and don’t bother to offer their own Class Drivers. If a vendor offers a USB device that does not fall under one of the standard USB defined Device Classes supported by an OS then they shall offer their own Class Driver.

Working groups in the USB-IF have defined several standard USB Device Classes (Mass Storage, Audio, etc.). A USB device vendor may choose to define a proprietary Device Class for their product or utilize part or all of an appropriate USB-IF defined Device Class. The USB-IF defined Device Classes provide a baseline set of features, for their respective class. Several USB Device Classes are supported natively by today’s Operating Systems.

“value add” that a vendor may provide. As long as the USB Framework presented through the USBDI remains unchanged, the USB Class Drivers do not have to change because the USB bus driver does (e.g. to support the xHCI)

The USB bus driver (USBD) provides a standard method of interfacing to the transport mechanisms (USB Framework) defined by the USB architecture (Isoch, Interrupt, Control, and Bulk Pipes) and the Device Class driver is where all the application specific knowledge resides.

The Device Framework allows the USB architecture to separate the details of the “Bus” interface from that of the application specific (“Device”) interface, resulting in a split driver model (xHCD/Class Driver). Note that in this context, Device Class refers to the portion of a USB device that performs some useful end user application specific function (e.g. Mass Storage, Audio, Human Interface, etc.).

A key feature of the USB architecture is the Device Framework that it presents. The Device Framework defines the interface between a USB device and a Class Driver, which is independent of the particular host controller interface that a system employs to communicate with the USB. This interface consists of a Default Pipe, and zero or more additional class defined Pipes. The Default Pipe (also referred to as the Default Control Endpoint) is used to enumerate and manage a USB device. It can also be used to provide access to application specific features of the device. The class defined Pipes provide specialized Quality-of-Service requirements to perform device class specific functions.

This is a hardware device that expands the bus topology (hub) or performs a useful end-user function. Interactions with USB devices flow from the applications through the software and hardware layers to the USB devices.

The host controller is the specific hardware implementation of the host controller architecture. There is one host controller specification for the USB3 host controller, which enables support for Low-, Full-, High-, SuperSpeed, and SuperSpeedPlus devices. The interface presented by the xHC to the system is referred to as the eXtensible Host Controller Interface or the xHCI.

xHCD provides the software layer between the Host Controller hardware and the USBD. The details of the host controller driver depend on the host controller hardware register interface definition.

The USBD is a system software Bus Driver that abstracts the details of the particular Host Controller Driver for a particular operating system. The generic USB interface p resented to the system by USBD is referred to as the USB Driver Interface or the USBDI.

This software executes on the host PC corresponding to a particular “class” of USB device (Mass Storage, Human Interface, Audio, etc.). Class Driver software is typically part of the operating system or provided with the USB device.

This software uses the services provided by one or more USB devices. Application software interfaces with USB devices through standardized interfaces provided by the Class Drivers.

A USB Host System is composed of a number of hardware and software layers. Figure 3-1 illustrates a conceptual block diagram of the building block layers in a host system that work in concert to support USB 3.x.

Adopters and Contributors of the eXtensible Host Controller Interface Specification for Universal Serial Bus (xHCI) have signed the eXtensible Host Controller Interface (xHCI) Specification Contributor Agreement in order to be licensed to use and implement this Specification. This Contributors Agreement provides Contributors and Adopters with a reciprocal, royalty-free license to certain intellectual property rights from Intel and other Adopters and Contributors for their products that are compliant with the xHCI specification. Adopters and Contributors can demonstrate compliance with the Specification through the testing program as defined by Intel.

Through use of the PCIe SR-IOV specification, the xHCI provides a Virtual Machine Manager with the ability to enable Virtual xHCs

Support for Virtual Memory. All xHCI register and data structures are designed to support the “coarse-grain” Scatter/Gather requirements of page based virtual memory architectures. Support for “fine-grain” Scatter/Gather. The interface supports a hardware scatter/gather method for all data transfers that may be used for accessing memory. The EHCI scatter/gather mechanism was an example of Coarse Grain scatter/gather. It was tailored specifically to work with page based virtual memory, specifying a Start Offset, a Transfer Length and a list of Page aligned addresses. The xHCI scatter/gather mechanism is not constrained by memory page boundary or size limitations. xHCI scatter/gather lists may be comprised of buffers starting on any byte boundary and any byte length. This feature allows the xHCI scatter/gather mechanism to be used for accessing page aligned data, as well as at the application level to minimize software data copies.

Over the implementation lifetime of this specification, it is expected that xHCI controllers will be used increasingly in architectures that support more than 32-bits of addressable memory space. The xHCI inherently supports up to 64-bits of addressing.

The xHCI provides a simple interface for software to provide the host controller with parameterized Transfer Requests that the host controller uses to execute transactions on the USB. The interface allows software to asynchronously add work to the interface while the host controller is executing, without requiring the use of software synchronization primitives.

The xHCI’s data transfer model eliminates the memory based transaction schedules that existed in previous host controller architectures. It utilizes Transfer level operations to decrease the average number of memory accesses required to execute USB operations.

The xHCI specification enables solutions to a myriad of issues, which have proven to be problematic for USB host controllers. Some of the issues resolved in the xHCI specification include: Memory thrashing, Memory access efficiency, and conflicts with CPU power management. The xHCI architecture provides both new specific features and optimizations to its architecture to solve the legacy issues.

51 by the xHCI. Special attention has been paid to minimizing power consumption when the system is Idle. USB is a critical component in delivering a consistent, coherent and robust user experience. If the implementation includes PCI configuration registers, then the host controller is required to implement a PCI Power Management Interface (PCI PM).

System Power Management. Current PC architectures are providing ubiquitous support for aggressive power management. The USB3 architecture focuses on power conservation to improve battery life in mobile, battery powered applications. USB2 LPM (Link Power Management) extensions are also supported

Support for all USB device speeds. The xHCI specification defines support for all USB device speeds including; USB 2.0 Low-, Full-, and High-speed devices, and USB 1.1 Low- and Full-speed.

Robust Support for all USB 3.x Features. This specification describes a host controller architecture that is capable of supporting compliant USB 3.x SuperSpeedPlus and SuperSpeed devices. This includes new USB 3.x features such as asynchronous transactions and other extensions to the protocol.

 Efficient operation – idle power and performance better than current USB host controller architectures.  A device level programming model that is fully consistent with the existing USB software model  Decouple the host controller interface presented to software from the underlying USB protocols  Minimize host memory accesses, fully eliminating them when USB devices are idle  Eliminate the “Companion Controller” model  Enable hardware “fail-over” modes in system resource constrained situations so devices are still accessible, but perhaps at less optimal power/performance point  Provide the ability for different markets to differentiate hardware capabilities, e.g. target host controller power, performance and cost trade-offs for specific markets  Define an extensible architecture that provides an easy path for new USB specifications and technologies, such as higher bandwidth interfaces, optical transmission medium, etc., without requiring the definition of yet another USB host controller interface

The goal of xHCI architecture is to define a USB host controller to ultimately replace UHCI/OHCI/EHCI, to provide highly power efficient operation, higher performance, and extensibility to new USB specification s, such as USB3 and beyond. Key xHCI architectural goals are:

The eXtensible Host Controller Interface addresses these factors. In addition, the xHCI architecture provides a new industry standard means for interfacing to USB devices that delivers the extensibility necessary to meet future needs.

Virtualization is beginning to play a key role in system architectures and the legacy USB host controller architectures exhibit some serious shortcomings when applied to virtualized environments. Legacy USB host controller interfaces define a data pump; where critical state related to overall bus management (Bandwidth allocation, Address assignment, etc.) reside in the software driver. Trying to apply the standard hardware IO virtualization technique, of replicating IO interface registers, to the legacy USB host controller interface is problematic because critical state that must be managed across Virtual Machines (VMs) is not available to hardware. The xHCI architecture moves the control of this critical state into hardware, enabling USB resource management across VMs. The xHCI virtualization features also provide for: 1) Direct-Assignment of individual USB devices (irrespective of their location in the bus topology) to any VM, 2) minimizing run-time inter-VM communications, and 3) support for native USB device sharing.

When USB was originally developed, it was targeted at desktop platforms and performance was the primary objective, which meant that host power consumption was not an important consideration. Since then, mobile platforms have become the platform of choice, and their batteries have made host power consumption and idle time efficiency key considerations. The xHCI elimination of the host memory based transaction schedules and its support for the advanced USB3 power management features are key to providing more power efficient platforms without sacrificing performance.

The storage capacities of portable devices have been increasing with Moore’s Law. Vendors of these devices need high performance interfaces so that these high capacity devices can be loaded in reasonable amounts of time. The Enhanced SuperSpeed support of the xHCI addresses this need.

The development of the eXtensible Host Controller Interface was driven by 3 key factors; Speed, Power Efficiency, and Virtualization.

The abbreviation i.e. is for the Latin phrase id est which means that is. The abbreviation e.g. is for the Latin phrase exempli gratia which means for example.

The symbol combination “=>” shall be read as “transitions to”. e.g. OCA => ‘1’ means the value of OCA transitions to ‘1’.

Throughout this document pseudo code is used to illustrate operating principals. Comments are demarcated by the double forward slashes “//”. The pseudo code conventions include: If/else condition statements:

The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).

The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).

The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situation s

Hexadecimal numbers are written with a lower case “h” suffix, e.g., FFFFh and 80h. Hexadecimal numbers larger than four digits are represented with a space dividing each group of four digits, as in 1E FFFF FFFFh. Binary numbers are written with a lower case “b” suffix, e.g., 1001b and 10b. Binary numbers larger than four digits are written with a space dividing each group of four digits, as in 1000 0101 0010b. All other numbers are decimal.

Terms or names in bold text indicate the sentence provides a basic xHCI definition of the respective term/name. All other references to an xHCI defined term/name use the exact same text string as the definition so that you can search on it easily. Refer to section 1.5 for more information on searching.

Implementation Notes should not be considered to be part of this specification. They are included for clarification and illustration only. Implementation Notes within this document are enclosed in a box and set apart from other text.

The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the xHCI specification and from which no deviation is permitted (shall equals is required to).

Italic text is used to identify Capitalized names that are explicitly named xHCI; registers, register fields, or flags in registers.

Adopters can demonstrate compliance of their product(s) with this specification through the xHCI compliance testing program provided by Intel®. For details on the xHCI compliance testing program, please send email to ssusbcompliance@usb.org. The xHCI Compliance Test Suite provides an excellent reference of software expectations when communicating with the xHCI and a concise list of the test validation assertions associated with this specification.

Some terms are capitalized to distinguish their definition in the context of this document from their common English meaning. Words not capitalized have their common English meaning. When terms such as “memory write” or “memory read” appear completely in lower case, they include all transactions of that type.

Rather than enumerating the full specification name every time one of the above specs are referenced in this document, the abbreviation listed in the Spec Reference column shall be used.

Register names and the names of fields and bits in registers and headers are presented with the first letter capitalized and the remainder in lower case.

For example: To find all references to the Port Power (PP) field of the PORTSC register, in Reader® open the Search dialog box, and since this field has an acronym, enter the string “PP” in the ‘What word of phrase would you like to search for?’ text box. Check the ‘Whole words only’ and ‘Case-sensitive’ check boxes, and press the ‘Search’ button to list all references to the Port Power flag in this specification in the ‘Results’ window.

This document does not include an index. An effective substitute when viewing with Adobe® Reader® is to use the Search dialog box to locate all references to a specific xHCI feature or field.

This specification presents a view of the overall architect ure and detailed description of the operational model requirements of the host controller, using the defined registers and interface data structures.

The specification is primarily targeted to host controller developers and system OEMs, but provides valuable information for platform operating system and BIOS device driver developers, adapter IHVs/ISVs, and platform/adapter controller vendors. This specification can be used for developing new products and associated software.

The following documents are referenced throughout this specification. The Spec Reference defines a shorthand mnemonic used in this specification for the respective document listed below.

The eXtensible Host Controller Interface (xHCI) specification describes the register-level host controller interface for Universal Serial Bus Revision 2.0 and above. The specification includes a description of the hardware/software interface between system software and the host controller hardware.

The architecture (3) and operational (4) sections are followed by two sections of pure structural definitions that detail the register space (5) and interface data structures (6). These definition chapters contain little or no operational requirements or usage models. The final sections describe the xHCI Extended Capabilities (7), and the virtualization operational model (8). The Appendix covers useful information not included elsewhere in the specification.

This specification is intended for hardware component des igners, system builders and device driver (software) developers. The reader is expected to be familiar with the current Universal Serial Bus Specification revisions. In spite of due diligence, there may exist conflicts between this specification and the US B Specification. The USB Specifications take precedence on all issues of conflict.

式変形

回の場合の計算回数

が成立する。

x≡b1 (mod.m1) x≡b2

互いに素

Endpoint Context Data Structure

Slot Context Data Structure

Interrupter Register Set

Event Ring Segment Table

Device Context Base Address Array Pointer - RW. Default = ‘0’. This field defines high orderbits of the 64-bit base address of the Device Context Pointer Array. A table of address pointersthat reference Device Context structures for the devices attached to the host.

Number of Interrupters (MaxIntrs). This field specifies the number of Interrupters implementedon this host controller. Each Interrupter may be allocated to a MSI or MSI-X vector and controlsits generation and moderation.The value of this field determines how many Interrupter Register Sets are addressable in theRuntime Register Space (refer to section 5.5). Valid values are in the range of 1h to 400h. A ‘0’ inthis field is undefined.

Number of Device Slots (MaxSlots). This field specifies the maximum number of DeviceContext Structures and Doorbell Array entries this host controller can support. Valid values arein the range of 1 to 255. The value of ‘0’ is reserved.

The capability registers specify the limits, restrictions,and capabilities of a host controller implementation.These values are used as parameters to the hostcontroller driver.

(USBCMD)

Operational Base + (04h)

Refer to section 3.1 for a summary of the xHCI register architecture

Note that the xHCI does not require support for exclusive -access mechanisms(such as PCI LOCK) for accesses to the memory-mapped register space.Therefore, if software attempts exclusive-access mechanisms to the hostcontroller memory-mapped register space, the results are undefined.

The extensible USB Host Controller contains many software accessible hardwareregisters. A large portion of the registers appear as Memory -mapped HostController Registers. Other registers may appear using non-memory addressmechanisms, as in the case of a PCI or PCIe based Host Controller. For thesedesigns it is required to implement the required registers as defined by therespective specification.

This document describes the EDK II Platform Description file (DSC) format. The EDK Build Tools are included as part of the EDK II compatibility package. In order to use EDK II Modules or the EDK II Build Tools, an EDK II DSC and FDF file must be used.