Re: Fwd: USB DBC hang during earlyprintk initialization

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 10/31/25 15:15, Milan Oravec wrote:
> I'm sorry but I can't provide better feedback. When the USB cable is
> connected during initramfs loading DbC is connected, but the system
> stops booting with no messages in the DbC host. When I let USB
> connected prior to the boot, DbC is not initialized. What should I try
> else? Any ideas? Thank you!
> 

I was able to set up a similar system, and I could reproduce this.

I think that firmware/BIOS is controlling xHCI and uses it for debugging before kernel loads,
so if cable is connected too early then it gets stuck in firmware control.

I can see on the host side that a usb device is connected almost immediately after
power on, and it has a different vendor and product ID than what early xdbc driver sets:

host log if cable is connected before power on:

   [3474920.221407] usb 4-1: new SuperSpeed USB device number 65 using xhci_hcd
   [3474920.233582] usb 4-1: LPM exit latency is zeroed, disabling LPM.
   [3474920.233673] usb 4-1: New USB device found, idVendor=8087, idProduct=0b21, bcdDevice= 0.00
   [3474920.233677] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

host log if cable is connected when loading kernel:

   [3475961.148597] usb 4-1: new SuperSpeed USB device number 73 using xhci_hcd
   [3475961.160775] usb 4-1: LPM exit latency is zeroed, disabling LPM.
   [3475961.161016] usb 4-1: New USB device found, idVendor=1d6b, idProduct=0010, bcdDevice= 0.10
   [3475961.161020] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
   [3475961.161022] usb 4-1: Product: Linux USB GDB Target
   [3475961.161023] usb 4-1: Manufacturer: Linux Foundation
   [3475961.161025] usb 4-1: SerialNumber: 0001
   [3475961.162413] usb_debug 4-1:1.0: xhci_dbc converter detected
   [3475961.162480] usb 4-1: xhci_dbc converter now attached to ttyUSB2

when actual xhci driver is later loaded it resets the controller, which then gives
linux kernel full control.

Maybe we should reset xHCI in early xdbc driver as well.

Regarding "system stops booting with no messages in the DbC host" issue,
it appears either messages or whole boot is blocked if nobody is reading the
messages.

try to read them and see if it helps.
"minicom -D /dev/ttyUSB2" on host worked for me

Thanks
Mathias