Thursday, 19 March 2015
CK 3756 kynar wire stripper - buy one!
I wish I'd bought one of these sooner! Expensive, but it just works:
Sunday, 15 March 2015
Mini 3G 150M A5-V11 Router (internals/UART)
This is a generic/unbranded router from dealextreme (product 217078)
There's very little information in the product description, but for my 7 quid I ended up with a board known as "A5-V11", which has a RT5350, 4M SPI flash, 32M RAM. It is supported by openwrt (here) but the current bleeding edge with the defaults set is too big. It fits if you drop the IPv6 related packages.
It's already well documented so there isn't any need for much more here. Worth noting is that a standard SOIC clip (i.e. Pomona-style) won't quite make contact due to the position of the big capacitor in the middle. The micro USB port is only used for power... so for future experiments I wired the UART to it following the same pinout as Mediatek stuff. A resistor is required on RX or it won't boot (value not critical, also works fine with 330 ohm).
There's very little information in the product description, but for my 7 quid I ended up with a board known as "A5-V11", which has a RT5350, 4M SPI flash, 32M RAM. It is supported by openwrt (here) but the current bleeding edge with the defaults set is too big. It fits if you drop the IPv6 related packages.
It's already well documented so there isn't any need for much more here. Worth noting is that a standard SOIC clip (i.e. Pomona-style) won't quite make contact due to the position of the big capacitor in the middle. The micro USB port is only used for power... so for future experiments I wired the UART to it following the same pinout as Mediatek stuff. A resistor is required on RX or it won't boot (value not critical, also works fine with 330 ohm).
 |
| Maybe needs a couple of blobs of hot glue |
 |
| The jffs2 thing is a known bug |
Tuesday, 10 March 2015
HP Printer JTAG
Of course I couldn't leave something like that without at least attempting to find out what they were for! Luckily I hadn't yet destroyed any important bits so it went back together...
And typically, they didn't seem to do anything at all. Maybe because it had no cartridges? Well I certainly wasn't going to buy any, so I thought I'd take a ROM image and if I got bored enough some day I could have a poke around it. But then - I found a connector header covered over with soldermask. As a 2x19 with central ground pins I took a lucky guess at "Mictor 38" layout and got a JTAG connection.
--------------------------------------------------- VTarget = 2.691V Info: TotalIRLen = 4, IRPrint = 0x01 Info: CP15.0.0: 0x41059461: ARM, Architecure 5TE Info: CP15.0.1: 0x0F0D20D2: ICache: 4kB (4*32*32), DCache: 4kB (4*32*32) Info: Cache type: Separate, Write-back, Format B Found 1 JTAG device, Total IRLen = 4: #0 Id: 0x1594602B, IRLen: 04, IRPrint: 0x1, ARM946E-S Core Found ARM with core Id 0x1594602B (ARM9) ETM V1.3: 4 pairs addr.comp, 2 data comp, 8 MM decs, 2 counters, sequencer Target interface speed: 100 kHz ---------------------------------------------------
...and that's where my knowledge of JTAG debugging ends at the moment. The CPU is some kind of custom HP "top secret" NXP part that doesn't exist, which makes things a bit trickier. This probably isn't the best way to learn about JTAG either. Nevertheless, I'll just keep prodding it until something pops!
<-- "Door open"?! that's the least of your problems haha
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:
Before:
(yes, I was too lazy to rotate one of these)
During:
(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.
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:
Before:
(yes, I was too lazy to rotate one of these)
During:
(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:
 |
| 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!
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.
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)
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...
Typo fixed and then it worked fine. Figured it was pointless to add a photo of a working phone though!
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!
Thursday, 8 January 2015
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.
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.
Subscribe to:
Posts (Atom)