Allow user to configure endpoints twice

[kjopek_gmail.com]

Summary

Revision 356545 changed the behaviour of xhci controller to avoid configuring endpoints multiple times
and effectively made BladeRF 2 unusable with FreeBSD.

Since I cannot verify what other devices may be affected I propose to make xhci controller behaviour
configurable. I do not have also any evidence that r356545 broke anything else than BladeRF 2.

The other option is BladeRF is somehow dependent on original behaviour of xhci controller,
however, similar problem did not appear when using USB 2.0 controller.

Test Plan

Tested on RockPro64:

With post-r356545 behaviour

# bladeRF-cli -l /usr/share/firmware/hostedxA4.rbf 
Loading fpga...
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:123] _bladerf2_initialize: dev->backend->get_fpga_version(dev, &board_data->fpga_version) failed: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:2186] bladerf2_load_fpga: _bladerf2_initialize(dev) failed: An unexpected error occurred
Error: failed to load FPGA: An unexpected error occurred
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1936] bladerf2_trigger_init: Board state insufficient for operation (current "FPGA Loaded", requires "Initialized").
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:1936] bladerf2_trigger_init: Board state insufficient for operation (current "FPGA Loaded", requires "Initialized").

With pre-r356545 behaviour:

# sysctl hw.usb.xhci.pre356545=1
hw.usb.xhci.pre356545: 0 -> 1
# bladeRF-cli -l /usr/share/firmware/hostedxA4.rbf
Loading fpga...
Successfully loaded FPGA bitstream!

[• hselasky]

Could you do a usbdump of the USB traffic and possibly enable XHCI debug to extract the exact error code.

Thank you!

[kjopek_gmail.com]

Maybe I will share results from my investigation.

First of all, I created minimal program to reproduce issue (mainly by extraction of the code from libbladerf):

rf_debug.c10 KBDownload

The problem was exactly after firmware upload. Version detection worked... totally unstable, typically libusb returned LIBUSB_ERROR_OTHER (-99).
I initially thought the problem is somehow related to corruption of firmware image. But when I compared USB traffic from working machine (FreeBSD 12.1 @ AMD64)
with RockPro64 there was no difference.
I recorded USB traffic to debug this problem, here is textual log:

t1.txt64 KBDownload

Original recording:

usbdump-rockpro.pcap2 MBDownload

Also, output from rf_debug:

rflog.txt7 KBDownload

And finally xhci debug messages:

xhci_log.txt23 KBDownload

[• hselasky]

Hi,

Can you try this patch instead:

xhci.diff964 BDownload

xhci_check_transfer: slot=1 epno=4 remainder=0 status=27
xhci_check_transfer: slot=1 epno=4 remainder=16 status=4

Means the following errors:

#define XHCI_TRB_ERROR_LENGTH 0x1B
#define XHCI_TRB_ERROR_XACT 0x04

--HPS

[kjopek_gmail.com]

Hi,

your patch works perfectly. BladeRF is usable again.

Thank you.

[shichun_ma_dell.com]

It's a good fix.