Wednesday 25 February 2015

8-layer PCB Scanning - Practice Run (T100s)

If you don't own an MRI (I did check ebay and dealextreme just in case!) then this is a fairly easy, effective, but very slow way of recreating PCB artwork from a multilayer board.

I imagine a Dremel would rip through this in seconds... but that's probably going to cause problems when you only want to remove a few microns at a time. Instead I went for a combo of 120grit alox and 400grit carbide paper. I also nearly got screwed over by HP and their bullshit claims of 1200dpi! Take a look; on the left is a corner scanned on a HP at "1200dpi". On the right, the same corner scanned on a £50 Canon I got from PC World, also set to 1200dpi:

The phone was broken by the way, it just buzzed from somewhere on the back of the board... although I did get a complete eMMC dump by jamming it in a vice with a bit of an IDE connector putting pressure on whatever was broken. It took a few goes as when it warmed up it must have moved just enough to switch off. I also forgot that without a battery you only ever get 13.5 minutes in bootrom mode before it switches off (MT6592). Finally with a PSU pretending to be a battery, I got it imaged in about 17-18 hours.

The concept is straightforward:

While you have remaining layers,
1. Scan a layer
2. Remove half* a layer

*Micro vias are impossible to see if you only scan the copper layers. Take a scan part-way through the epoxy as well. They are pretty small at around 100μm in diameter:

(yes, I was too lazy to rotate one of these)

(Lesson I learnt is I should have put scrap PCBs around the sides to prevent this from happening)

2 more layers! On the left, remaining 2 copper layers. On the right, sheet of standard 80gsm printer paper. Photo through a 30X lens.

And after:

Chinese magic phone dust is probably highly toxic and definitely stains your hands green, brown or grey. It also ended up in my ears somehow!

Then with a set of scanned layers, use your favourite image editing software to isolate the copper coloured bits. Combine all of those, align them all, job done:

Further improvements that I'd do if this wasn't just a practice would be to neaten up the few areas the colour processing got wrong, and square off the tracks / non-round pads.

I'm still trying to find a program to visualise the layers in 3D. If it was a vector image then it would be straightforward but I couldn't find the equivalent for raster. There isn't even a good file type to save it in... Adobe psd seems to be the most popular :/
If I find something appropriate then I'll upload the whole thing, but at the moment it's 1.2GB and not very friendly.

Saturday 7 February 2015

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!

Monday 2 February 2015

Where's the beef?!

And now for something completely different...

Dolmio used to make a convenient and tasty pasta sauce in a microwaveable pouch product named "Dolmio Express". I say used to - technically they still make a product with this name, but the recipe got ruined (and they're still showing the nice one on their website)

(<-- on the left) Nice version, before the change, taken from the Dolmio website today. Ingredients list inaccurate.

(on the right -->) Ruined version, insufficient beef, taken from Tesco's website.

I mean, who replaces beef with carrots!? It went from a nice beefy
sauce to something closer to a tomato-ey water with a tiny amount of beef floating in it (that looks more like tuna). Oh and don't forget the carrots! Urgh.

Suggestion: revert changes. Charge more if needed instead of ruining it. If you absolutely have to use less beef, replace it with TVP or something, not carrots.

Sunday 1 February 2015

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.


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!