PhracturedBlue

I don't think the usb_storage module is involved in libusb bulk transfers?  I did try playing around with CPU affinity for the USB interrupts, but it didn't change anything.

I have a ToupTek MU300 USB2 camera that I was trying to get working with my LePotato.
The camera does not have native kernel support, but the manufacturer provides an SDK with a pre-compiled lib for x86/arm, and additionally I have a kernel module which works on X86/X64 with this camera as well as userspace libusb based code to access the camera.
 
The camera is very sensitive to having buffers available during bulk transfer, otherwise the image will be corrupted.  Generally synchronous bulk transfer is not fast enough, and requires multiple buffers supplied in asynchronous mode.
 
On x86-64 and Rpi3/4, everything works as expected.  I can grab images via the vendor supplied SDK as well as with my libusb based code (and on x86-64 the kernel module...which is untested on RPi).
 
However on the amlogic boards I have, the exact same code results in corrupted image frames being returned.  The camera responds properly to control messages, and I do get data via bulk transfer, but the packets are not uniformly sized as they should be, and data is missing (converting the raw data to an image shows broken line alignment, indicating missing data)
 
What I've tried:
Tested 5.9.14 and 4.19 kernels Tested armhf and aarch64 Tested LePotato and ODroid-C4 Tested Kernerl-module, libusb, binary SDK Tested synchronous and asynchronous bulk transfers Tested with powered USB hub as well as directly plugged into SBC Tested with conservative and performance governors  
In all the above cases the camera performs the same way, yet there are no issues on RPi3, RPi4 or X86-64.  I'm not sure what other options I might have to debug.  I'm guessing it is something related to the USB stack, but it must be subtle, since I've seen no issues with other USB devices.  I have looked at the traces in wireshark, and there is nothing obvious (besides that the bulk transfers are not uniformly the correct size)
 
Does anyone have any ideas for other ways I may continue debug?
 

https://dl.khadas.com/Hardware/VIM1/Datasheet/S905X_Datasheet V0.3 20170314publicversion-Wesion.pdf
and
https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing
Page 26, you can see that UART B and C live on I2C_A (The RPI's "ID" pins) and "PCM_DOUT/DIN" (Pins 19 and 21 on Le Potato)
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L764
Shows the definition of the UART's in question in the GXL dtsi,
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts#L266
shows where the A0 UART is enabled, it should be very similar for UART B and C
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi#L425
There are the pins that need referenced in the same manner as the AO one does.
 
If you're up for some "fun with device tree", or are quite creative that should do the job.  I haven't tried it personally, but you have access to the pins and they have those alternate functions.
 
As to power management, I haven't used the 4.18 kernel to any real effect yet, so I can't speak to it's consumption, but I would guess some more "fun with device tree" in both u-boot and linux could disable all the stuff you're not using.    Also make sure you're using "conservative" or similar for your CPU governor.
 
If you can't get as low as you want, there are "SoM-style" H3 or H2+ boards that could also fit your needs like the NanoPi Neo/Core/Duo, or even the Libre Computer Tritium H2/3, if you want to keep the flexibility of maintaining the ports.  If you search the forums you'll find a ton of "minimize consumption on H3" information.

See https://github.com/libre-computer-project/libretech-linux/commit/9b6b181a0700b329876b7998eb75283ce0b338cc
 
The previous USB patches that were posted to the libre-computer-project 4.14 branch were not the final ones.
 
All of the out-of-tree patches for 4.14 can be found here: https://github.com/libre-computer-project/libretech-linux/commits/linux-4.14/libretech-cc-master

I guess you came across his first post: https://forum.armbian.com/topic/2419-armbian-for-amlogic-s905-and-s905x/
Once you have multiboot, you can backup the eMMC (especially the dtb), then copy Balbes armbian on eMMC and now you can tweak it how you like it.
eMMC needs many partitions, I don't know why.
 

I don't know and don't care so much about the u-Boot as long as it works as expected.
Balbes images are based on armbian 5.59 and Kernel 4.18 https://yadi.sk/d/pHxaRAs-tZiei/5.59/20180829
And as I wrote before, with Multiboot you can boot from every source obviously which might be useful doing it the hardway ;-)