USB booting AML boards - a long strange trip

In the beginning, I got a Sweet Potato (sweetp, as I called it in local DNS). For a variety of reasons, one of my goals was to boot and run from a USB attached SSD, but that just didn’t work. There was (and still is) a problem with the USB and resets that disconnect the storage at some point in the boot. What I didn’t know at the time, and which confused things, is that the disk enclosure I used - because I had it already - had problems with UAS, at least on sweetp.

At some point I decided to try a La Frite (referred to as frite), since it sounded like the issue might be due to the USB hub chip. Well, frite didn’t work any better with the SSD, though it had no problem with several different thumb drives, so I was still unenlightened.

Today I came across this article which discussed an apparently known issue that a common JMicron USB:SATA bridge chip had with UAS operation. Guess which bridge chip is in the Orico enclosure? But it’s not so straightforward - the enclosure works fine with the UAS driver on other machines, so the AML USB hardware and driver seem to be part of the problem. Or maybe it’s an unholy combination of all of those…

Anyway. The magic boot option described in that article

usb-storage.quirks=152d:0578:u

makes frite happy to boot and run with the Orico. Hurrah! With this victory behind me, I was motivated to try this on sweetp, but that culminated in a “disconnected” message about 15 seconds into the Linux boot, followed by many BTRFS errors that were helpful only to draw my eye back up to that disconnect report. Okay, this is the USB/hub issue.

After lunch I got to wondering. Back at the start of all this I had seen errors with the OTG port as well as the others, which are routed through the hub. Since quite early I had avoided the OTG port on sweetp, probably because it hadn’t worked any better earlier, and a suspicion that there might be some code that messed with it as part of supporting OTG operation. But it doesn’t go through the hub, and now that I know the Orico works (sans UAS) with the AML USB hardware…

Well, imagine that! With the UAS disabling option in place, and using the OTG port, even sweetp can boot and run from an external SSD! Now if I could tell the me of several months ago about this magic workaround…

Caveat: I have NOT tried this with any other USB devices connected…
2024-07-05: I forgot that sweetp was still connected to a GPS module, so I do have confirmation that at least some USB devices can be connected through the hub without interfering with the SSD through the OTG port.

Speculation: I’ve heard that some thumb drives have UAS support. None of the ones I have on hand do, but these are mostly smaller (8G is the most common size) and USB2, so if you have a fire-breathing thumb drive that doesn’t work with these SBCs, you might want to check and see if it gets assigned the UAS storage driver.

Further adventures in USB Land…

It’s not only the on-board hub that the AML is allergic to; OTOH, it’s not allergic to all hubs. An old Belkin port, which had its external power source plugged in, disconnected some time into the boot. An Orico four port acted like it was short of power. Turned out the ports had the same jacks for external 5V power, so I tried the Orico hub again with external power, and…

Okay, why did that work? I mean, that it needed the power to the hub is understandable, but why does one work and the other not?

Belkin hub reports as 05e3:0608 Genesys Logic (twice, cascaded four port chips).

Orico hub reports as 05e3:0610 Genesys Logic. Can’t find any info about what might account for the different results.