Focaltech touchscreen oops / Leagoo customer service

I've been playing around with the Leagoo Lead 3 for some time now. Initially I chose this due to price and the fact that it was not just another "counterfeit samsung" like many others. Apart from it having a fairly low spec (but still great for £50!) I really like this in terms of build quality, official ROM update availablility, and as I've just found out, Leagoo customer service is great too!

Nice packaging

It's an unbrickable device - even a full eMMC wipe can be recovered from as the SoC has an internal bootrom that will emulate a low speed uart over usb, which you can then flash the preloader back and go from there.

There is however one more "secret" flash storage area that unfortunately can be erased. It turns out that Focaltech CTPMs have an 8051-based controller with... firmware stored in its own flash memory. A couple of days ago I (somehow) managed to wipe the contents of one, rendering the touchscreen completely useless. The device that you need the part number from is this:

I tried a bunch of random firmwares with (obviously) no luck. They're each tailored to a specific screen. In a last ditch attempt before microwaving the brick* I contacted Leagoo customer services to see if they would send me the firmware. A few emails later... I got it :)

Working touchscreen again

The strange device-to-host i2c comms of this thing still confuse me, but it should be possible to write a kernel module to dump a backup of the firmware which could come in handy when dealing with phones from companies with useless (or nonexistent) customer service *cough* Cubot, Axgio, Landvo *cough*



*and of course a closer look at the mainboard - if anyone has a broken Lead 3 they want to send me for that purpose then I will do!

Reconstructing MTK LCM drivers

This is another one of my "why didn't I think of that sooner" ideas that could have saved me a few days. Basically Chinese touchscreen datasheets do not exist, or not that I can find for free anyway. Out of all of the phones on my desk I only got 1 "close" match for the controller datasheet and it wasn't any use for writing a driver as the screen initialisation info is in the LCD datasheet (I couldn't even find the company that apparently made this screen. I think it probably begins with J!).

From the LK or kernel console, the LCD timings are easy enough to pick out. If you're lucky enough not to have bought an "agold" special then you also should have the name of the LCM controller. Some phones have multiple supported in each firmware (important).

That's great - apart from you don't have the initialisation commands. Again if you're incredibly lucky (or paid extra and got a Wiko/Lenovo/Acer/etc) then you might be able to find the exact driver on github. If not, then either you could randomly keep trying similar sounding drivers (...bad idea!) or just pull the struct from a working firmware's lk.bin. Most (but not all) of the drivers are boilerplate and using the same struct to store the data - there shouldn't be much to change between devices.

Example:

qHD 4.5" screen, driver IC either RM68191 or OTM9605

Looking at lk.bin, in the chunk of data at the end: the RM68191 data was first (sequences start with "0x55 0xAA 0x52 0x08 0x03" as seen in similar drivers), then the OTM9605 data that I wanted for this phone. It's in the same layout that you would expect knowing the struct: cmd (yellow), count (green), para_list (red)

22 columns made things line up nicely

I dd'ed just the initialisation data out and formatted it ready to copy/paste using this (note: minimal error checking etc - common sense may be required!)

Then put it all together and try it out to see if you missed anything...

This sort of thing happens if you miss a bracket!

Typo fixed and then it worked fine. Figured it was pointless to add a photo of a working phone though!

Mystery solved!

I discovered that the mystery bootloader (see previous post) is from a Mediatek (urgh, again?!) MT6260. Oddly, flashable through USB1.1 instead of serial like I was expecting.

The download agent detected the external flash as a 32Mbit Winbond, and read it without trouble. I get the feeling there's a bit missing as I assume there to be internal flash in the SoC... but I don't know yet.

Mystery bootloader & Work in progress

Does anyone recognise this SoC bootloader output? The actual IC is hidden under a sealed metal can that I don't really want to have to remove.There's a chance it is a Mediatek MT6xxx part, or an ST32*. It's part of a chinese clone of a GPRS module and doesn't output much more than this:

XT897 UART. "Can't be done" according to 'the internet'. Sure it can:
(disclaimer: work in progress; and only currently possible after the bootloader has finished)

I'll detail it once I figure out how the hardware bit is supposed to work (as opposed to how it is above - e.g. hold this wire here for 2 seconds, once that changes to this, swap that wire to this pin, etc)

And finally, just to show a reader who is having MTK trouble... framebuffer console is definitely possible :) The UART was invaluable in being able to write the LCM driver, although a good plan B is cause a kernel panic on purpose, and the android kernel dumps the last chunk of its ring buffer to a fixed location in RAM, which is accessible after a reboot (into 'recovery', for example)

This is also a W-I-P with the aim of eventually getting an up-to-date upstream+patches kernel running on this hardware (MT6582).

Motorola Photon Q (XT897) SIM mod

Original version is here: http://forum.xda-developers.com/showthread.php?t=1929143
Here's how my first attempt looks. Second one (next week?) should look neater I hope! It worked first time :)

 
The blue sleeve looked neat but was far too wide to stay. Although the pads are tiny, the pin pitch is huge so shouldn't cause any issues soldering unless you don't see the resistors just inside where the can used to sit

The tape is there for extra electrical insulation and to hold the springy wire in place... The SIM slot is soldered.

I removed plastic up until the antenna, and it fits with no room to spare

GB EPROM cart finally built, after about 10 years of never getting around to it!

Everyone's done one of these so I won't add much other than some photos. I already had the stuff... except the PLCC socket - I was still using UV EPROMS (DIP!) when I first got the rest of the stuff.

See kids, this is how you *actually* do a real ROM dump... none of that nandroid(etc) cheating! No virus-filled rapidshare downloads and a poorly written msword doc for this either!

Yeah, this was totally not worth the effort that went in to making it :P

MTK (Mediatek) debug cable

Reverse engineering crappy Android Linux hardware/platforms is much easier with a serial console when you have a working kernel, but no source (of course first attempt being GPL request, then when that fails, github/google). Many (most?) cheap smartphones at the moment are made using Mediatek SoCs like the MT6582, MT6589, or older MT6572. An interesting feature I found in these is that after the preloader stage, the LK bootloader and also the main kernel provides a 921600 baud TTL UART console port on the USB data lines, providing that it "sees" it during startup (else you get normal USB).

A "Prolific" PL2303HX cable will cost you about £2 from ebay. A CP210x might be a better choice, but they were just open boards so didn't look as nice.

The "2 minute" version is just swap the cable for a micro USB cable. The phone will charge if you connect the 5v wire, but the safe approach would be just connect the other 3 and leave 5v disconnected. Note that I put the green and white TX/RX the wrong way around here, on purpose to demonstrate what not to do *ahem*

That's the easy way... but the 5v input meant the phone boots up as soon as the cable is plugged in, which wasn't ideal. The few hours battery was no use really. I could have just put a switch on the cable - but that would have looked a mess. I opted for switching this using the DTR signal (ctrl-T in picocom). You might get lucky and find that DTR (pin 2 on the PL2303) is already connected up to a spare track or pad, but if not, SSOP isn't too small:

Take some switching parts from an old PC motherboard or something, I used a P-Channel MOSFET, NPN and a 10k & a 1k resistor, as shown in this non-standard & badly labelled diagram:

I tested it before compacting it! (also added an LED to show charging on/off). The phone is on the other end of the cable here... the LED isn't drawing 700mA :)

There's plenty of space to fit it inside the USB plug. If you can't use SMD parts, it'd probably sit above the PCB without issue.

The finished cable. "Why that horrible green?" - stops me thinking it's just a normal micro usb cable and plugging it in to something else and exploding it