As we work to stabilize Haiku and move closer to the R1 beta releases, USB driver issues are becomming more apparent.
I started looking at the isochronous streams stuff a few months back but it was hard going - there was a lot to learn and I couldnāt dedicate enough time to it to get anywhere useful.
Whoever takes this on, I recommend looking at maybe one of the BSD XHCI drivers to get an idea of how that implements the specifications above, and only when you feel you fully understand it, go for it. In my experience, itās easy to get started on something and ārun out of bricksā because itās hard to see the full picture from the get-go.
Iām not sure anyone else is actively working on this, but this is what I have found so far.
Iāve been doing all my development on real hardware. By chance, all computers that I have access to happen to have the NEC/Renesas USB chipset, uPD720200 series. None of the computers ever had any success what so ever with the xhci driver.
I added a bunch of debug code, and found that the Noop() works consistently, so Command Transfers are working fine.
However, the driver would always fail trying to get the device descriptors.
I found a bug, and now the driver is able to complete getting the device descriptors for connected devices.
Thereās still a problem with the buffer and TRB completion handling that causes transfers to stop at some point after.
I had no previous USB experience, but since you posted this a few months ago, Iāve been digging in and learning. Iām going to continue working on it and hopefully get it working.
Thanks for digging in! Never be afraid to take a look at an issue, youāll likely not be stepping on anyones toes and the community will appreciate the help more than anything. Everyone has to start somewhere 
great work so farā¦
try and learnā¦
and you will make us all happy tooā¦ thx
Thanks for investigating this. If you found bugs, donāt forget to submit patches for review at http://dev.haiku-os.org .
So I was formatting a patch to submit, and I thought I would update my source to the latest HREV, using the command
git pull --rebase
So, it wouldnāt build, so I then did a
jam clean
Still no luck same error.
So I renamed my source directory and did a complete fresh clone of āhaikuā. I ran configure again, and I still got the same errors trying to build.
command_checksum.cpp:(.text+0x35c): undefined reference to BPrivate::SHA256::SHA256(void)' command_checksum.cpp:(.text+0x36e): undefined reference toBPrivate::SHA256::Init(void)ā
command_checksum.cpp:(.text+0x3a1): undefined reference to BPrivate::SHA256::~SHA256(void)' ... /boot/home/haiku/generated/objects/haiku_host/x86_gcc2/release/tools/package/command_checksum.o: In functionChecksumIO::~ChecksumIO(void)ā:
command_checksum.cpp:(.gnu.linkonce.t._._10ChecksumIO+0x25): undefined reference to `BPrivate::SHA256::~SHA256(void)ā
I know the SHA256 was changed, but I thought it was working. Also, I know that there was an ABI change, but I didnāt think that would actually impact the build process on my machine.
I also canāt seem to do a clone of an earlier HREV. I saw the note in UserBuildConfig, but that didnāt help, and Iām not sure how it would because the latest source is already on my machine.
Any suggestions??
You need to update your running system to match the sources you are working with. This is a limitation of building Haiku within Haiku: you are in a grey area between cross-compiling and compiling native binaries, so, strange things happen. In this particular case, we compile some tools for the host Haiku system and assume the API is compatible with the target system. But in your case, it is not.
So hereās my status update. I am attaching a PATCH to the first ticket 13343 that you reference, but I didnāt actually work in QEMU. Actually, it may impact all those tickets. Iāve been looking at the code trying to find bugs in general.
Iāve been investigating the xhci (usb3) driver and found a few things.
All of my hardware that I have access to happens to have the NEC/Renesas chipset. Previously,
none of the hardware was even recognized, and it would fail at getting the device descriptors.
With the patch that I have submitted and attached, things are starting to work, and the attached
devices are reported, and even working.
What Iāve found though, is that early rev. chips, 0.96 seem to have an issue and interrupts seem
to stop being generated. I believe it is related to an errata for missing interrupts on partial
transfers. I havenāt been able to come up with a solution yet.
Now the same chipsets that are later revisons work much better for me. I was able to mount
drives, watch videos, and even boot from a USB3 port. Although, sometimes it was tough to even
get the bios to recognize the thumbdrive attached. I donāt believe itās stable yet though.
Back to the early rev. chipsets, it may be a regression in system performance until a solution is found.
If a device is connected to the xhci port, and you right click in Tracker to āMountā it takes some
time to respond while the system tries to query the device, but receives no response. And I did get an occasional KDL on boot, so I think there is still a memory allocation or access issue.
Iām not sure how the project wants to proceed with the patch, but I wanted to get it out there and
hopefully some others can help debugging. I am still working on it, but maybe those with more
USB knowledge will have some ideas.
Great job Greg! You definitely solved #13343!
Weāre one step closer to R1!!
Thanks a bunch, Greg! You also fixed #12883 - āLaggy mouseā and #12895 - āPANIC: did not find any boot partitions!ā when booting from USB3 port.
Good job!
I have a USB3 controller card with Renesas chipset too, will try it out on the weekend.
Wow! Thatās great to hear! Closing bugs is good. I donāt have any USB 3.1 devices yet. Iām curious how those will behave.
Great job thank you very muchā¦
Add https://dev.haiku-os.org/ticket/13062 to that list, so finally I can use these two other USB ports on my laptop and donāt need to carry a hub everywhere. Thanks!
aaaaaaaa this is great