Fix reliability with modern computers

[dougg3]

Armed with a USB sniffer as I've discussed in the comments in #1, I have improved the compatibility of this tool to the point that it works perfectly on all the Linux machines I have on hand to test with. The command I'm using to test (with an original OMAP3530 BeagleBoard) is:

sudo ./omap_loader -p 0xd009 -f x-load.bin -f u-boot.bin -a 0x80800000 -j 0x80800000 -v

These machines already worked with the existing code. I'm just listing the CPU they have:

• Intel Core i3-2120
• Intel Core i7-920

These machines didn't work until at least some of these patches were added. The necessary patches vary by machine.

• Intel Core i7-6700K
• Intel Core i3-7100U
• AMD Ryzen 5 3600
• AMD Ryzen 7 5700G

Detailed info about this is available in #1, but the gist of it is:

• My traces seem to indicate that the OMAP's on-chip bootloader possibly has some weird bugs where it doesn't always handle USB 2.0 high speed PING/NYET properly if you try to talk to it too fast. I don't think it's a coincidence that my older machines work fine and my newer machines don't. I saw some NAK loops and STALL errors. Add a 1 ms delay before any bulk reads/writes to avoid this.
• There seems to be some issue (possibly with the Linux XHCI driver, or the XHCI controllers themselves?) where if we try to read from X-loader too quickly after loading it into the OMAP, something gets hung up. libusb never sees X-loader's initial response, but my sniffer shows the OMAP sending it. The host controller gets hung up trying to read more (nonexistent) data from the OMAP and never reports the data back to libusb. Adding a small 20 ms delay before trying to read from X-loader fixes this.
• I also opted to do small 512-byte-at-a-time reads. It doesn't slow down performance enough to really matter, and it fixes an issue I observed where if the bus was too loaded, libusb reported a memory error. It should also even further help to avoid the PING/NYET issues I saw that the 1 ms delay fixed.
• Minor fix for a kernel warning about using an interface without claiming it

With these fixes implemented, all 6 of the machines listed above work great with omap_loader. I did run into an unrelated issue where libusb's hotplug detection is too slow on the i3-7100U. I was able to build a custom libusb without udev support to test it out (udev seems to be the bottleneck), and also I found that if I booted into a fully updated Arch install it also works fine there too.

[dougg3]

One more data point to add to the list: AMD Athlon X2 4850e, works fine before and after this change.

[dougg3]

I did some more testing with omap_loader on three Raspberry Pis: a Raspberry Pi Zero, a Raspberry Pi 4B and a Raspberry Pi 5. On the 4B and 5, I tried both the USB 2.0 and USB 3.0 ports.

• The Pi Zero is too slow to respond unless I build a custom libusb-1.0 that uses netlink instead of udev for hotplug detection.
• Without these fixes applied, it usually fails to even load X-loader. Occasionally it loads X-loader correctly, but always fails to load U-Boot afterward.
• With these fixes, it always works fine.

So that's three more data points in favor of these changes.