Mtk Based China Phones briefing

Posted by Nazim Ali | 21:47 | 0 comments »

Starting...
As someone with some experience in the embedded development field I will try to explain the procedure to successfully hook an MTK phone up to a computer. I make this work to be as thorough and logical as possible. My target is, provideing all who is interested about chinese mircale phones to make the best and safety action on MTK based phones. I hope you find this thread useful.
Let's begin.


What are we dealing with?

My preferred way of looking at MTK based cell phones is that of looking at small ARM
based embedded platforms. The MTK baseband chips have 33-66 MHz ARM cores. They
come with 4-8 megabytes of SDRAM, and either a NOR or NAND flash for storage.



Q: Is it possible, in theory to run Android on these phones?
A: No. Android has much higher minimum requirements.


My target when interfacing with these phones is to read/write the contents of the flash chip, so we will focus on that for a bit.

The flash chip contains 2 things: the firmware and a file system section. The firmware of course is the program (OS) that works the phone. It handles user interface, communicates with all the attached devices (microSD card, camera, BT module, GSM module, etc..) it’s the central piece of program. 

Firmware


MediaTek sells a reference firmware platform to its licensees which they all use (after varying levels of modification). What this means is that all MediaTek firmwares are based on the same code base, and thus all MTK phones have similar, if not identical basic features. For example:basic UI code, such as language handling, input handling, and resource handling code will be the same. This is why a single MTK Firmware Editor can open almost all MTK firmwares, and successfully edit the resources contained within.




This reference platform comes with no support for external executables. All functionality is linked into the firmware at compile time, so adding new features or applications afterwards is infeasible, and without months of reverse engineering, by skilled developers, impossible.There are no such projects so at the time of writing there is no way to run outside code on the MTK platform (unless the firmware of interest has Java support, or NES emu compiled in).




Q: Can I add new apps to the phone?
A: No. (Unless your firmware has Java support or NES emu)
Q: Can I create my own apps that run natively on the phone’s CPU?
A: No.




Usually release firmwares come compiled with a specific set of drivers for the target hardware configuration. Different model phones will not have the same type of LCD display, FM tuner chip, BT chip, camera(s) etc.. But there’s no guarantee that same model phones, manufactured on different dates do either. Indeed same model phones manufactured just a few weeks (or days) apart can have different hardware. It is because of this that 5 different firmware versions of Model X could have been release not because of firmware improvements/bugfixes, but because the hardware in the phone has changed and new drivers were required.



What this also means is that most of the time trying to “upgrade” the firmware on these phones will result in bricking, or the loss or malfunction of an attached device (display, camera(s), BT, etc.)



For example: White screen, black screen, no screen, after flashing, but hearing the phone play the startup chime is because the phone’s display is either different, or connected differently in hardware, and the driver in the firmware we’ve flashed isn’t able to handle it. Similarly, loss of camera support, or malfunctioning keys are all symptoms of this. 

A number of firmwares MAY have several drivers compiled into them, with the right one being selectable from the Engineer Menu, so in some cases that may work. Also a model’s hardware configuration may be stagnant, because of an overabundance of the parts used in the original design, in this case upgrading would be feasible, and likely worth it. Sadly however, this is not the case most of the time. It is because of this, and other factors that I’ll talk about
later, that it is HIGHLY recommended to ALWAYS BACK UP the FULL flash image, that was originally on the phone. 5-10 minutes of annoyance, can save you hours/days of frustration.



Q: Can I use firmwares from other MTK phones? They have features I want.

A:
90% chance the phone won’t even start. 100% it won’t work entirely right.

Q:
Can I upgrade the firmware version on my phone?

A:
You can try, but ALWAYS BACK UP the original flash content, as it’s
unlikely that you’ll get the desired outcome.





Identifying firmwares by version


MTK firmwares have a so called, version code, that when entered will output the firmware version of the phone. You can find a set of these in Appendix A, but the most common ones are *#8375#, and *#4853*#


The phone should immediately display the version screen once you enter the correct code.You should not need to press anything else. If it does not, then you’re not trying the right code for your phone. It is also likely, that your phone has a code that isn’t in the Appendix, as one of the first things some firmware developers seem to do is change these to a random value.When entering these codes you will get a version string (ex.: A6V2.2.2) and a Build Time(ex.:2007/12/04 18:31)


Now you might think that checking just one of these would be enough to identify the firmware, and you would be wrong. The two firmwares below are different, and the hardware of the two phones doesn’t match. So flashing one of these to a phone that had the other one on
it originally, will produce a white screen, and unusable phone.

* A6V2.2.2 - [BUILD TIME: 2007/12/04 18:31]
* A6V2.2.2 - [BUILD TIME: 2007/12/18 14:46]

This can also happen the other way around with Build Times being identical and version strings being different. It is my experience that comparing both string and build time is sufficient to discern firmware versions, but I usually read back the first 10kilobytes of the firmware from the phone and compare it with the version I have on file, just to make sure.


File system



The file system section comes after the firmware on the flash chip. Different flashing solutions call it differently including FAT, FFS, NVRAM, System/User FS, etc..


This section contains several actual file systems (FAT12, FAT32) on top of a proprietary structured data store layer. I know of no software that can handle this top layer, so access to the file systems within is only possible through the phone itself for the time being. These file
systems contain all the data used by the firmware from system data like device driver settings, to user data like the phonebook, messages, or data account settings. When people refer to formatting a phone, they’re referring to these file systems. Formatting as with formatting file systems on regular PC hard disks, or flash drives erases all data stored in these file systems. Upon starting the phone after a format it will recreate all of its needed files inside these file
systems, and fill them with hardcoded defaults. This includes all calibration data, and device driver settings. Contrary to popular belief formatting these file systems without backing up is anything but safe. As hardcoded defaults can differ from factory set values, so there could beseveral things that you’re influencing by letting the phone use the hardcoded defaults. It is best to back up the FAT of each phone that passes through your hands, as they’re only a small portion of the flash content so it takes about 15-30 seconds, and once again: You may be saving yourself from lots of frustration in the long run. What you should keep in mind about the file system is that IMEI, and personal data are also stored here, so you may want to think twice about publishing your firmwares with FAT included, because of the privacy issue. Also if the people who end up using your firmware are ignorant to these facts, they could end up
making several phones that use the same IMEI (Yours!). Which depending on carrier, may result in banning the IMEI from the network, instantly rendering all phones that use it, inoperable, or another case, where a phone with said IMEI is reported stolen.




Supposing you have 10 phones with the same firmware, you download the firmware from Phone #1 modify it with an editor, save a Full Image then flash said image onto Phones #2- #10. You now have 10 phones with the SAME IMEI. What you should’ve done is either back up the file systems from all the phones and write the originals back after the full flash, or if possible, patch-flashed your phones. (This means flashing only the parts you wish to modify and leaving the rest of the flash chip intact, this isn’t always possible.)




Another thing to keep in mind is that there could be factory protections that use the file system. For example the PSN protection: in this protection form, a serial code generated from a unique hardware ID is stored in a file on the file system. If you flash a full image from one of these phones onto another, even if they’re the same version, the target phone will start up with “Register Mercury” And will STOP FUNCTIONING after a few weeks. If you haven’t backed up the file system of such a phone you essentially have a phone that needs a file system reformat every few weeks to start up, or in other words, a phone that can’t be sold. Few repair boxes can fix PSN, and they’re expensive. So once again: The thing to keep in mind is to ALWAYS HAVE A BACKUP. Best is to have full backups, but at the very least, if you already have a full backup for the specific firmware version on the phone, you should still take that 1 minute to back up the file systems from all the phones. You just may be thanking yourself later.



Q: What should I back up?

A: At least 1 full backup per fw version, and the file systems section for each phone.


Interface



There are usually at least 2 ways in which you can interface with an MTK phone. With the supplied data cable: through USB, through a 3.3v serial UART, and through BT.The grid below illustrates what you can do with each interface.







As you can see, you can’t access the flash chip with the supplied USB Data Cable. You will need to buy an interface for the Serial UART of the phone if you wish to access it. This is unfortunate, but there’s no way around it. But wait, you say. Your phone has a COM Port in the USB Menu, so surely you could use that. You could not. The usb virtual UART cannot be active at the time it would be needed to boot and flash the phone, as it is only active while the firmware’s running.
The RS/EIA232 Serial UART (or commonly just: serial port) is a very common interface supported by almost every computing platform in the world. Older PCs have COM Ports for example. Those would be an example. Most microcontrollers have either software or hardware based UARTs (universal asynchronous receiver/transmitter). Serial ports require at the minimum 3 wires to work. One Tx(that the device transmits on) one Rx(that the device receives on) and the ground. There are however differences in electrical specifications, and supported data transfer rates. The MTK platform is a 3.3v based system. That means that that most everything in the phone is running off 3.3volts that is generated by a voltage regulator connected to the 3.7v battery. The maximum voltage for logical HIGH states is 3.3volts. The serial port works at 3.3volts as well. On the other hard, a PC’s serial port works at 12volts. You do not wish to connect a 3.3volt system to a 12 volt system directly
.   

Direct COM Interface (slow)



This is where level shifters come into play: one example of an RS232 level shifter would be the MAX3232.








If you build the above schematic, and supply it 3-5 volts (Phone’s battery works fine) you would be ready to hook up to your MTK phone through your PC’s Com port. Great! If you have one of these chips lying around, this would be your cheapest and quickest solution.


Another option to further simplify the circuit above would be the MAX3233, which has integrated capacitors.






Be sure to use 3233, and not 233. 233 works on 5v, and the phone battery only supplies around 4.2 when fully charged. (In practice 233 would most probably work just as well, but if you have a choice to get either one, get 3233.)


However PC serial ports regardless of what their drivers’ report are limited to 115200 bits per second.

Let’s do the math:

(16 megabytes) / (115 200 bits) = 1 165.08444

1165 seconds = 19.4166667 minutes

20 minutes to read a common 16megabyte firmware chip. Not the fastest solution everinvented. 32 megabyte chips are gaining ground in the MTK platform, but I’ve already seen 64 and 128 megabyte NOR chips as well.


(64 megabytes) / (115 200 bits) = 4 660.33778
4660 seconds = 77.6666667 minutes


If you’re patient, this solution would indeed work for you. But it’s far from ideal, and is not generally used except by hobbyists who are just looking to flash their own phones once in a while. If you feel that you fit in this category, go right on ahead.
 

USB Serial Interface



The serial ports on MTK phones support up to 460800 bits per second. But how can you take advantage of that with a PC? Through a USB Serial cable. Unlike regular PC serial ports USB Serial chips are capable of speeds of up to 921600 bits per second. The MTK phone will initiate communication at this speed, but it won’t be stable, only at 460800 does it work reliably. Let’s check the math again.


(16 megabytes) / (460 800 bits) = 291.271111
291 seconds = 4.85 minutes



Now that’s a lot more promising In practice you can get close to 5 minutes during readbacks.Flashing is usually somewhat slower.


That said, you shouldn’t go out and buy just any USB Serial cable, as the ones that come with a DB9 socket, and sold as USB Serial Ports were made to be used as replacements of regular PC serial ports. So you would probably have the same problems with them as with regular serial ports. They might have on-chip level shifting, that you can’t even disable, or have extra chips that you would need to remove. What you should look for are flashing cables sold for cell phones. There are several available online for an assortment of models, most of them can be modified for the purpose. The procedure differs based on what kind of serial port the phone has that the cable was made for, and what kind of usb-serial converter chip is used, and
whether the cable has any plus features, or the phone any additional steps required to initiate communication on the cable.



For example I used a PL2303 based Nokia DKU-5 clone.
The PL2303 has a special pin that sets the voltage at which the serial port should work. This had to be connected to a 3.3volt regulator that I had to add externally as the PCB of the cable was in a “poured” connector, and couldn’t be accessed without force, and possible damage. PL2303 based cables don’t necessarily have this pin exposed. They could be connected to a 3.3volt regulator on-board, in which case no modification would be needed to use it.



These are FTDI chip based cables. FTDI chips are the chips of choice for usb serial interfacing, so they should be ideal for this purpose, and since you’re buying a cable that was intended for another MTK phone you shouldn’t need to modify anything, except the connector.

Another way for connection:
"The Multimeter method"




1. Plug your new connector into your phone, with solder pads/pins exposed
2. Put Multimeter into fault-check. (or if unavailable, then it’s highest resistance range)
3. Keep negative Multimeter probe on negative battery connector in phone.
4. Touch each pin of the connector in sequence with the other probe until you hear a beep ( or see 0.000 resistance )
5. Note this connector pin as GNDPin
6. Now install battery and switch on Phone
7. Put Multimeter into DC voltage measurement
8. Keep negative Multimeter probe on GNDPin
9. Touch other pins of the connector in sequence and note pins that have voltage between 2.6 and 2.9 volts.(be careful not to short pins )
10. You should end up with a list of 2 or 3 pins. RX and TX will be among these.
11. Try all combinations of RX and TX with these pins you found.



I’ve found several hundred pinouts with the method above. It works 99% of the time, and takes about 2 minutes once you’re in practice.
So you now have your RX, TX, GND wires on your interface end, and your pinout or set of pinouts to try for the phone. It’s time to dive into the flashing in practice.


Flashing theory



After the connection has been established, flashing the phone happens the following way:
Phone is turned off.
Boot process is initiated on the PC in the flashing software. This continuously starts sending a certain byte out on the serial port.
The phone’s power button is pressed, phone reads it’s com port, and if it detects this byte it goes into remote boot mode, otherwise starts the firmware. The piece of software that does this is an internal bootloader that is inaccessible and protected. Meaning, that you will never lose the ability to flash your phone, as long as the hardware is intact, regardless of how much you mess it up while flashing. You can’t corrupt the bootloader, so you will be able to connect to your phone even if the flash chip is completely empty. Once the phone has entered remote boot mode, the flashing software sends it a piece of code called a Download Agent, or DA. The bootloader loads the DA up into ram and starts executing it. This piece of code is actually what’s doing all the hard work related to flashing: Detecting the onboard flash chip, reading and writing content and communicating on the
serial port. The flashing software on the PC side merely sends commands to the DA from this point on.



DA Bugs:
It’s worth mentioning that the DA, like all other pieces of software can have bugs. As the DA is a closed source piece of proprietary software, these are also unlikely to be fixed. One such persistent bug is that certain 32meg+ flash chips cannot be patch flashed.What’s patch flashing you ask? Patch flashing is writing only a specific section into the flash chip, say 414 bytes starting at 0x223421, instead of everything from 0x0 to <CHIP_SIZE>


Boxes


Flashing boxes are capable of opening the Security Zone before a full flash. No, let me rephrase that: The software that comes with flashing boxes is capable of opening the Security Zone before a full flash, allowing the full flashing of phones; this is actually one of the many
things that warrant their existence. Boxes are essentially hardware keys that protect the software that was coded for them, combined with USB Serial adapters. Some also include dynamic pin configuration and automatic pinout finding circuitry. They can cost several hundred USD, but come with support, cables for most MTK phones and flashing software. Some also provide firmware editing software, either in the basic package or as an addon for a fee. Qualities of these vary from box to box.




Flashing in practice, using MTK flashtool



MTK FlashTool is the “official” tool used to flash MTK phones. It’s used by the factories and developers. It is also where the DA originates from.
The features of MTK FlashTool include
· Reading(Read-back) and Writing(Download) the flash
· Formatting the File systems



Probaly guides and videos already posted in forum but ı want to inform everybody by pictures.


Reading a full backup with MTK FlashTool





This is MTK FlashTool. You can set your Serial Port settings in the Options menu. If you’re using the Direct COM interface, select COM1/2 and 115200 bps from the Baudrate submenu. Otherwise select the virtual com port number of your USB serial cable, and 460800. Also set Options->Operation Method->NOR (this book only talks about NOR flash)


Click over to the Read Back tab, remove everything you may find in the list, then click Add.
This is what you should see:





Now double click on ROM_0, and Select where you wish to save your image.
Then you will be greeted with the dialog below






It’s fairly obvious what we need to do here. For a full backup we will start at address 0x0000000, this means the very beginning of the flash chip. The length has to be equal the size of our flash chip. Don’t know this? Try reading a small chunk first, and I’ll show you how to find it.


Click Ok, and Click Read back. At this point you should have your phone physically connected to the PC, with it being switched off. Push the power button. Your phone should start booting the DA, nothing will appear on most models while doing this. Some will turn on the back light, some will produce a hissing sound through their speaker. These are all normal.


If the phone turns on and starts the firmware, then your interface, settings are wrong/faulty If you’ve used the Multimeter method now would be the time to try the next possible combination. If it just doesn’t seem to work in any combination, you should loopback test
your interface cable. Or it’s also possible that your phone doesn’t have UART on it’s data cable connector, only on test points, at this time I’m not going to write about finding the right test points on such phones.



Try and try again, until it works. If you’ve read your first backup, Congrats!


Ok, now if you didn’t know your flash chip size the bottom right corner is where you should look, after your initial smaller readback.





You’re interested in NOR: (256Mb+64Mb)
What this means is that this phone has NOR Flash, 256 MegaBITs of it, and 64 MegaBITs of RAM.
Now you can use Google.
Use the following search without the quotes, and substitute the number you got:
“256 *131072 in hex” The result in this case:
256 * 131 072 = 0x2000000
0x2000000 is what you would need to enter in the length field to get a full backup of this chip.



As a quick reference:
128 MB = 0x1000000 (usual file system start: 0xE00000, length:0x200000)
256 MB = 0x2000000 (usual file system start: 0x1C00000, length: 0x400000)
512 MB = 0x4000000
   




Full Flashing with MTK FlashTool



Full flashing, with no regard for the Security Zone, as discussed above, this will create bricked phone unless you continue with the the fullflash guide, have an image with an open Security Zone, or one with Security Zone protection disabled.
First open notepad (that’s right notepad) Insert the following line:
ROM 0x0
And save it as reflash.txt
Now in FlashTool click the Download Tab.
Click the Scatter-loading button, and locate your reflash.txt
This is what you should see:






Double click ROM, and select the image you wish to flash to your phone.Hit Download, and press the power button on the phone. Sit back and enjoy.

Firmware Editors


Now that you’ve gotten a pretty good idea about how to interface with your MTK phone, and the caveats of flashing we come to the subject of firmware editors.Firmware editors allow you to change internal resources of MTK firmwares, like language packs, graphics, internal ringtones, and fonts.


Notice: there is no free solution to edit firmwares at the moment only paid solutions.(Infinity box---z3x team products----spiderman box----cpf products---Mc tool ---etc.)


For now ı finish my thread but who know in future will continue this thread with new cpu type.

0 comments