MacBook air Hacking - USB PORTS
If you ask Apple, they’ll say just one.
But, the “About This Mac” utility says something that reveals there may be more. According to the System Profiler, there are 7 busses, and only some of them are being used:
If you plug in an external device on the only known USB port, it’ll show up on the same bus as the iSight... so, why are there 4 other buses in the device without anything connected? That doesn’t seem to make any sense...
So, if you look in the developer documentation, it’ll refer you to Intel’s ICH-8 chip, where the USB controllers reside. The datasheet gets in to a lot of detail, but I’ll summarize it here: There are 5 low-speed controllers and 2 high-speed controllers. Each of these controllers can connect to two USB devices, so theoretically you could connect 14 devices. But, the chip only has pins for 10 ports, so you have to decide which controllers to use with which physical pins. Why did they do this? Pins are expensive - adding 12 more pins would have made the device physically bigger. Second is for compatibility -- the extra low-speed controllers would cost next-to-nothing to add and would function with older software that doesn’t recognize the high-speed controllers.
So, the driver chip has 5 low-speed controllers and 2 high-speed controllers. That fits with what the System Profiler is telling us... we just need to find the pins.
iFixIt did a great job disassembling and then publishing high-quality photographs of their MacBook Air. Their pictures clearly showed the ICH-8 southbridge chip, and, to my surprise, there were numerous test pads pins surrounding it. Test pads are little circles of metal on the printed circuit board that designers leave in to access hard-to-reach pins. Sometimes these pins are used for testing; sometimes they are left in to access unused functionality. I was hoping that some of these pins might be unused usb connectors.
According to the datasheet, all the USB ports are located on the bottom of the chip (as shown above; the datasheet shows it rotated 90 degrees). Since PC Board wires are usually kept short, that narrows down my search to the row of pins along the bottom.
First, I measured the voltage at each pin. This is a safest form of probing. Some had 3.3 volts on them, but, according to the USB spec, an unconnected port should have 0 volts on it -- so, I ignored those pins. Eight remaining pins had 0 volts on them. According to the ICH-8 spec, these should have a moderately high resistance to ground -- 15-25kΩ. Using a multimeter, I read 17kΩ, so there was a good chance I’d found something USB-related!
USB uses two data wires to communicate (the other two wires you see in the connector are power and ground). The design of USB is really ugly from an electrical standpoint, but one of the quirks is that the speed of a device is signaled by putting a little extra current in to one of these wires -- D+ for a full-speed, D- for a low-speed device. You don’t actually need to connect both data pins to sense a connection. You’ll get an error & won’t be able to communicate, but that’s all I need - I just want to determine which pins are connected to the USB controller.
I used a hacked-up memory key to probe the pins. I cut a short USB extension cable in two, and then reconnected the power pins. I used the data line from the memory key as a probe. It has a built-in 1.5kΩ resistor to 3.3v, so it’s limited in the amount of smoke-causing power it can supply... but I added an extra 5kΩ to the circuit to be safer.
I connected the memory key to the first pin to test (second from left -- the leftmost one had power on it), and lo and behold, the system log reported a USB error! That meant we had reached a pin associated with the controller!
Feb 10 00:06:47 john-maushammers-macbook-air kernel: USBF:3425.312
[0x3e4ed00] The IOUSBFamily is having trouble enumerating a USB device that has
been plugged in. It will keep retrying. (Port 1 of hub @ location: 0x3a000000)
Feb 10 00:06:49 john-maushammers-macbook-air kernel: USBF:3426.972
[0x3e4ed00] The IOUSBFamily was not able to enumerate a device.
I did the same test with the next pin (third from left), and got the same error result. So, next I connected the two pins of the memory key to the two USB pins I’d found on the motherboard... success!! It recognized the drive.
I repeated the process and found another usb port. Then I noticed something curious about the wires leading to the pad: the 4 usb wires I’d found were thicker than most of the others. When designers make PC Boards, they determine the width of the each wire. 99% of them are as small as they can make it, but some of the are wider -- either to carry more current, or to match impedance (a method of reducing noise in data circuits). I searched the area around the chip and found two more wires that were the same thickness as the ones I found. So, it looks like there are only 3 USB ports available on these test pads. The other USB ports are probably routed with the same thickness wire, but it’s done inside the PC Board where I can’t see.
Here are the three ports illustrated:
The colors follow the standard USB color code: D+ is green, D- is white. You’ll have to find your own ground and +5v power supply. Be aware that there is no over-load protection for that +5v power -- that regulator is an additional part that isn’t included in the ICH-8.
The identifiers refer to the locationID as seen in the IORegistry Explorer (which is part of the Developer’s utilities):
Unfortunately, these three ports are all controlled by the USB 1.0 controller, not the faster 2.0 controller. I imagine that these pins are on Apple’s secret unused connector:
I’d need my microscope to probe that connector... Did I mention that this chip has an unused SATA controller?