Turning a Griffin MultiDock into a self-contained OpenSTF device lab
The Intel Compute Stick comes with Ubuntu 14.04 LTS preloaded, running the full-fat Unity interface. In an effort to minimise RAM usage (to keep as much available for STF as possible), I've replaced Unity with lubuntu-desktop (LXDE) and removed a whole bunch of default packages which aren't relevant. If you choose to replace Unity with something lighter (such as Lubuntu/LXDE), it's probably a good idea to run `sudo apt-get clean` (and/or remove some unwanted packages) after installing lubuntu-desktop but before logging out of your Unity session, so that there's some storage space free; my Compute Stick ran out (a decent chunk of the already tiny 8GB is taken up by a recovery partition, which I may back up and then remove), resulting in neither Unity nor Lubuntu/LXDE wanting to start - both just showed the wallpaper after login, with no other UI, and wouldn't respond to anything. If you do get stuck in that state, try dropping to a console (ctrl+alt+F1) and running `sudo apt-get clean` in order to free up some space before you log in.
Closer inspection of the MultiDock's daughter boards reveals that the USB hub is connected to port 1 on the TS3USB221A. Per the datasheet, we should be able to tie the switch pin low in order to lock it to port 1. As the TS3USB221A is in a 10-Pin µQFN package, soldering directly to it would be a massive pain in the posterior. Luckily, the trace was reasonably easy to follow - a via right next to the pin drops it through to the back of the board, where it runs up to another via right next to pin 6 on the PIC. Each of the PIC's pins is almost as big as the entirety of the TS3USB221A, making it a much friendlier target for modding - and luckily, there's an ICSP header right next to the PIC, with a ground pin within easy reach.
Lifting the PIC's pin 6 from the board and soldering a jumper wire in its place, connected to the ICSP ground pin, does appear to have locked the TS3USB221A to port 1 - and one phone which didn't work with the unmodded MultiDock now happily works when plugged into the Orico hub via a modded daughter board. Unfortunately, that's not all that's needed; some devices seem to cause the PIC to switch something on the power rails (understandable, since it's trying to switch the port over to a dedicate charging port controller), resulting in the device's USB connection 'bouncing' continuously.
It's possible that the MultiDock's hub and/or daughter boards are broken, as I picked the MultiDock up second hand (well below full retail price) - and I've noticed a red LED blinking constantly on the MultiDock's main board, just beside the first USB2514B hub controller IC. With this in mind, and the lack of apparently quick-and-easy hack to make it work how I'd like it to, it's back to my original plan of removing the original electronics and replacing the whole lot.
Since the MultiDock's USB hub doesn't seem to be suitable for this project, it'll have to come out. I've done a bit of exploratory rummaging around inside it. As long as you have a T20 "security" torx bit (with a hole in the middle), the MultiDock is very easy to get into. Simply unscrew the back plate, then remove three screws and slide out the device tray, and the electronics are exposed. (Photos will be added soon - I need more light!)
The internal construction consists of a metal-cased power supply, a large flat PCB which holds the USB hub controllers (3x SMSC/Microchip USB2514B) and a few other components, and a series of 10 vertically-mounted boards with the USB sockets and status LEDs on them.
Each of the 10 vertical boards is connected to the main board by a short USB mini-B male to mini-B male contains a surprising amount of circuitry, including:
I haven't reverse engineered the whole thing yet (far from it), but so far I've been able to determine that the TS3USB221A is used to switch the USB port between the USB2514B hub and the TPS2511 dedicated charging port (DCP) controller. I'm guessing that the PIC is deciding whether to switch it to the hub or DCP controller, and that my compatibility issues are being caused by it connecting most of my devices to the DCP rather than the hub. I'm not currently sure how it decides - but may be able to figure it out from a closer inspection and/or a bit of probing. A minor hardware hack to tie the TS3USB221A's port selection pin either high or low (depending on which port is which) may also be an option, if I can find a safe/easy connection point. If I can force the ports to hub mode, it'll still remain to be seen whether that allows the devices to draw sufficient current to charge (or at least maintain, rather than draining the battery).
While I wait for the Compute Stick to arrive, I have OpenSTF deployed on my old ThinkPad T430. Plugging the MultiDock into the ThinkPad, it was recognised as three four-port USB hubs (two of them are connected to ports on the third, providing a total of 10 usable ports for devices - 4 on each of two hubs, plus two on the third hub). This seemed like a good start, but of the four devices which currently make up my OpenSTF device lab:
It doesn't seem to matter which port(s) I use on the MultiDock - each device behaves the same, no matter which port (and thus which internal hub) it's connected to. This means that the MultiDock's original electronics are going to be useless for this project, but that's not a big deal as I've already got an Orico 7-port powered hub on the way which should hopefully work.