VIA VL805 xHCI donor on CaptainDMA_35T: Windows USBXHCI Code 10 and BAR0 reads FF

[CClast]

Description

Problem

I generated a CaptainDMA 35T firmware from a VIA VL805 xHCI donor dump.
The firmware enumerates as the donor device, but Windows fails to start the
Microsoft USB xHCI driver.

Windows device error:

PCI\VEN_1106&DEV_3483&SUBSYS_34831106&REV_01\6&1aefe097&0&0028000A
Driver: usbxhci.inf
Service: USBXHCI
Problem: 0xA
Problem Status: 0xC000000D

This device cannot start. (Code 10)
An invalid parameter was passed to a service or function.

Hardware / Software

• Board: CaptainDMA 35T
• Target: 35t484_x1
• Vivado: 2023.2
• Donor: VIA VL805 xHCI USB 3.0 controller
• Donor IDs: 1106:3483, revision 01, subsystem 1106:3483
• Donor class: 0C0330
• Windows driver: Microsoft USBXHCI

Project path:

D:\PCILeechGen\pcileech_datastore\CaptainDMA_35T\CaptainDMA_35T.xpr

Observed Behavior

• Device enumerates as VIA Technology XHCI USB Controller (PCIE).
• Windows binds usbxhci.inf.
• Device Manager reports Code 10 with 0xC000000D.
• BAR0 memory briefly shows zeros during driver start, then reads as all FF.
• Running setpci.exe -s 0000:05:00.0 COMMAND=0x06 does not restore BAR0 reads after the driver fails.

Donor Data

The generated datastore files are populated and do not look empty:

• device_context.json
• config_space_init.hex
• pcileech_cfgspace.coe
• pcileech_bar_zero4k.coe

The donor BAR0 is a 4 KB 64-bit memory BAR:

{
  "index": 0,
  "type": "mem64",
  "is_64bit": true,
  "size": 4096
}

Donor BAR0 contains xHCI capability/runtime data, including:

0x0000: 01000020
0x0004: 05000420
0x0008: 04000031
0x000C: 00e70004
0x0010: 002841eb
0x0014: 00000100
0x0018: 00000200
0x00A0: 00000401
0x00A4: c0000000
0x00B0: 02000802
0x00D0: 03008c02
0x0300: 0001000a
0x0328: 000000a0
0x0420: 400202e1

Diagnostics Tried

I built a few local test variants to narrow the issue:

1. Stock/Xilinx network identity with forced BAR0 loopback:

   • BAR0 reads work.

2. VIA VID/DID with network class and forced BAR0 loopback:

   • After removing the stale xHCI devnode, Windows shows a network adapter without a driver.
   • BAR0 reads work.

3. VIA xHCI class 0C0330:

   • Windows loads USBXHCI.
   • Device fails with Code 10.
   • BAR0 reads become all FF after failure.

This suggests the basic FPGA BAR path works, but the xHCI driver start path fails.

Possible Mismatches Found

These may or may not be related, but they are the main differences I noticed:

• The donor BAR0 is mem64, while the generated Vivado PCIe IP initially used a 32-bit BAR0.
• The donor conventional capability chain is at 0x80 -> 0x90 -> 0xC4, while Windows appears to see the Xilinx PCIe hard IP capability layout instead.
• The generated xHCI BAR model exposes registers, but I do not see an xHCI command/event ring responder that reads command TRBs and writes event TRBs back to host memory.

Questions

1. Is a VIA VL805 xHCI donor expected to work with the current generated BAR model?
2. Should PCILeechGen preserve donor BAR0 as 64-bit for this type of device?
3. Is the Xilinx PCIe hard IP config-space capability layout expected to differ from the donor?
4. Does xHCI support require a command/event ring DMA responder in addition to BAR register emulation?

I can provide the generated datastore/project files if needed.

Error Type

Code 10 (device cannot start)

Device Context File

device_context.json

Windows Event Log

Device Manager Error Details

No response

Terminal Output

[sercanarga]

i looked into this. the problem is that the current xhci support is register emulation only, there is no dma responder that fetches command trbs from the command ring and writes completion events back to the event ring. the driver writes the doorbell and then waits forever for a completion that never comes, that is why you get code 10 and bar0 goes to ff.

for comparison, nvme has a full admin responder and dma bridge, hda has a rirb dma module, but xhci has neither. this is not a quick fix, it needs a new systemverilog module similar to what nvme has. the minimum command set would be no-op, enable slot, and address device, plus dma read/write tlp generation for command and event rings. probably a couple weeks of work.

the 64-bit bar thing is a separate smaller issue, tclgen hardcodes 32-bit but xhci needs 64-bit when the donor has it. that one i can fix soon.

if you need something working right now, nvme is the best bet. the nvme admin responder and dma bridge are fully implemented, so identify controller and identify namespace commands get real responses back to the driver. most nvme ssds work as donors. hda audio also works with the rirb dma module. network class with forced bar0 loopback works too as you already tested, but obviously no actual networking. xhci is going to take a while.

i will keep the issue open and update it when there is progress. patches welcome if you want to take a shot at the verilog side.