Google Nexus S Android Phone Suffers USB Death

Today I am a very lucky guy, in spite of the fact that the USB OTG functionality on my Google Nexus S has just vanished. Why does that make me lucky? Well, it doesn't, but luckily I had ordered a second Nexus S that works properly with Canadian HSDPA frequencies on the Rogers network, and it arrived literally the same second that my old Nexus S stopped working. Total coincidence... I think.

Actually, I should be more specific - nothing on the old phone has stopped working except for the USB OTG controller. So when I plug my in my phone to my workstation, I receive "unable to enumerate device on port... " under Linux and "USB Device Not Recognized" under Windows 7. In layman's terms, my phone no longer works as a USB disk. 

Being a clever hacker, I managed to get the dmesg output on my Nexus S, which I hope will be of some use for people at either Google or Samsung. The source code for the Nexus S (codenamed crespo) is available, so I might look into it further some time later. 

In reference to the dmesg output below, 

"The FSA9480 chip is used on some Samsung phones to detect various accessories using sensing resistors on the ID pin of the USB port." [1]

It's likely an authentication chip - there are several vendors that provide something similar. The datasheet is only available under NDA of course. Naturally, I've tried several cables, and several different workstations, to no avail. There are many layers of software and electronics at work (or rather not at work) here, so without some chip documentation / resources, there's not really a way that I can debug this just using the source code of the Linux driver.

But just to clarify - anytime an 'err -6' appears, that corresponds to with -ENXIO "No such device or address", and anytime 'err -5' appears, it corresponds to  -EIO "I/O error", so the outlook is not good. It's likely that the chip in question had a bad solder joint and is not powering up with the rest of the phone, or it experienced a "massive" current spike from my laptop that it couldn't handle.

I believe my device is still under warranty though, so I'll certainly be shipping it back for repair soon. 

The strangest part of this whole thing is that I've kept my phone in pristine condition, which (sadly) suggests that the design quality of this Nexus S was lacking, in spite of what Google has said in various marketing videos. It could also be Fairchild's fault, if in fact it turned out to be an ESD issue. Anything that's connected on the USB should be able to handle 'typical' levels of ESD from a PC's USB pins. 

[ 2066.560942] fsa9480 7-0025: dev1: 0x0, dev2: 0x0

[ 2068.234132] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.362855] fsa9480 7-0025: fsa9480_irq_thread: err -6

[ 2068.363813] fsa9480 7-0025: fsa9480_detect_dev: err -6

[ 2068.363919] fsa9480 7-0025: dev1: 0xfa, dev2: 0xff

[ 2068.374642] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.377227] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.377957] i2c i2c-7: sendbytes: NAK bailout.

[ 2068.378051] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2068.379090] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.975317] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.977052] fsa9480 7-0025: dev1: 0x1f, dev2: 0xff

[ 2068.978903] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2068.991221] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.992016] i2c i2c-7: sendbytes: NAK bailout.

[ 2068.992109] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2068.993178] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2068.994968] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.003127] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.004982] fsa9480 7-0025: dev1: 0x10, dev2: 0x3

[ 2069.006708] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.008463] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.009962] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.010054] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2069.010498] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.012253] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.014000] fsa9480 7-0025: dev1: 0x10, dev2: 0x1f

[ 2069.015793] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.035247] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.037069] fsa9480 7-0025: dev1: 0xff, dev2: 0xff

[ 2069.038796] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.041289] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.043017] fsa9480 7-0025: dev1: 0x10, dev2: 0xff

[ 2069.044765] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.048313] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.050040] fsa9480 7-0025: dev1: 0x17, dev2: 0xff

[ 2069.051853] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.060308] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.062035] fsa9480 7-0025: dev1: 0x13, dev2: 0xff

[ 2069.063858] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.067409] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.068963] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.069124] fsa9480 7-0025: fsa9480_detect_dev: err -5

[ 2069.069209] fsa9480 7-0025: dev1: 0xfb, dev2: 0xff

[ 2069.070971] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.091186] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.092983] fsa9480 7-0025: dev1: 0x10, dev2: 0x3

[ 2069.094731] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2069.104292] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2069.105018] i2c i2c-7: sendbytes: NAK bailout.

[ 2069.105108] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2069.106102] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.150280] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.152079] fsa9480 7-0025: dev1: 0xff, dev2: 0xff

[ 2070.153836] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.166528] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.167026] i2c i2c-7: sendbytes: NAK bailout.

[ 2070.167188] fsa9480 7-0025: fsa9480_reg_init: err -5

[ 2070.168389] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.192257] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[ 2070.193986] fsa9480 7-0025: dev1: 0x10, dev2: 0x1

[ 2070.195786] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

...

[ 2070.210682] fsa9480 7-0025: dev1: 0x10, dev2: 0x0

[1] http://electronics.stackexchange.com/questions/13041/how-do-i-make-the-fairchild-fsa9280-fsa9480-fsa880-boot-pin-trigger-samsung-gal

UNetbootin on Mac OS X

Just in case anyone wants to use UNetbootin to create e.g. an Ubuntu Live USB device and it isn't working, there are two key steps that are not performed by the UNetbootin binary for OS X.

After downloading the ISO, use Disk Utility to partition your USB device. Ensure that you've selected Options -> MBR . After formatting the disk...

1) Ensure that you've marked the partition active

fdisk -e /dev/rdisk1

f 1

write

exit

2) Download syslinux and write the critical mbr binary your device.

dd conv=notrunc bs=440 count=1 if=mbr.bin of=/dev/rdisk1

After that, just use UNetbootin as usual.

OMAP3 SGX EGL Drivers Add Wayland Support

Just in case anyone was wondering this is a pretty big deal. Imagination Technologies, whose 3D graphics cores drive most mobile displays, has announced support for the EGL_KHR_Image_Pixmap extensions used by the Wayland display server protocol.

For those who haven't been following, Wayland has gained a lot of momentum as a non-X-based window compositor for Linux-based operating systems. Wayland facilitates client-side rendering, similar to the Quartz compositor used in Mac OS X. It has since been adopted by Meego and Ubuntu as their preferred compositing backend.

The stated goal of Wayland is to provide a user experience where "every frame is perfect". This is a rather necessary and long overdue improvement since traditional Linux desktops based on the aging X11 display server tended to suffer from artifacts such as tearing, visible redrawing, and flickering. However, Wayland retains the capabilities to encapsulate the traditional rootless X server for legacy applications. Wayland rendering targets already exist for popular toolkits such as GTK+ and QT among others.

Check out the video below for a (slightly older) demo.

Today, Wayland support exists for graphics chipsets from Intel, AMD, NVIDIA (nouveau) and SGX (OMAP3) platforms. OMAP4 support probably isn't far off.

I guess it's time to fire up the old BeagleBoard ;-) Incidentally, happy birthday!