Database Info

[FAQ] Why are so many applications randomly force closing?

Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes

When i did mine i did the 2048 for the first setting and watched it complete.
NEVER got the second option.

Allenfx said:
When i did mine i did the 2048 for the first setting and watched it complete.
NEVER got the second option.
Click to expand...
Click to collapse
it is possible that it will not give you the second option. as long as you choose 2048 for partition size and then 0 if asked for a swap size then you are good.
i think the second options isnt there if you use Rom Manager from the market to install your ClockWork Recovery.

ext3 journal errors for /data partition
I had this problem and it was due to ext3 journal errrors in the /data partition which caused it to be mounted as read only at startup (thus all applications force closing when they cannot write its data).
See: http://forum.xda-developers.com/showthread.php?t=895628
There might be other causes but I strongly suspect that this is the same since only a re-partitioning of the sdcard helps in this case as well (believe me, I have basically tried every other possible and impossible option).
Why the ext3 file system becomes inconsistent/corrupt (not sure of the right term) I don't know. Anyone has an idea or a way to prevent it from happening in the future?

fr33h33l said:
I had this problem and it was due to ext3 journal errrors in the /data partition which caused it to be mounted as read only at startup (thus all applications force closing when they cannot write its data).
See: http://forum.xda-developers.com/showthread.php?t=895628
There might be other causes but I strongly suspect that this is the same since only a re-partitioning of the sdcard helps in this case as well (believe me, I have basically tried every other possible and impossible option).
Why the ext3 file system becomes inconsistent/corrupt (not sure of the right term) I don't know. Anyone has an idea or a way to prevent it from happening in the future?
Click to expand...
Click to collapse
Agreed on the journal idea. A few things come to mind - dirty shutdowns from power button issues could potentially cause a problem, though in theory that shouldnt be an issue with ext3.
The other possible cause is something to do with the way Clockwork Mod wipes that data partition, sometimes leaving the journal state inconsistent with the newly wiped state.
Most significantly, this seems to only happen once to many users. That could mean the initial journal state is weird in some way from the factory and repartitioning once sets it up properly, never to occur again.
Sent from my VEGAn-TAB-v1.0.0B5 using Tapatalk

rothnic said:
Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes
Click to expand...
Click to collapse
This also seems to be the fix for 'boot looping" and the market not having enough space error

Stuck this nice post

rothnic said:
Symptoms:
Many people have this issue with the stock tablet. Everything may work fine, then all of a sudden you will get applications force closing all over. You can do a fresh install of TnT stock, with a factory reset, and still get the FC's.
Issue:
We don't know exactly what it is, but is related to something in the /data partition causing issues that a regular wipe doesn't fix. For most people this fix will only need to be done once for the life of your tablet.
Solution:
Warning, this will wipe your Data and internal sdcard(meaning backups are gone)
1) Copy your backups/data from your internal sdcard to your computer
2) Install clockwork
3) Boot into clockwork by holding volume+ and power until you see the black text pop up
4) Go to the advanced menu
5) Select Partition SDCARD
6) Select 2048 for first option presented
7) Select 0 for second option presented
8) Apply the settings and wait for it to be finished
9) Go back to main menu and do a factory reset to be safe
10) Reboot, and hopefully no more force closes
Click to expand...
Click to collapse
I am getting this same problem, everything was working fine yesterday. But when I turned the tablet on, Everything FC's except for stock android apps. I am using Vegan my partion is setup as 2040/0.

papote18:
Did you literally mean 2040/0? Or is the 2040 a typo?
It should be 2048, but it's beyond me what would happen if you used another value!?
Rev

Solution works great, thanks.

iDroidNow said:
it is possible that it will not give you the second option. as long as you choose 2048 for partition size and then 0 if asked for a swap size then you are good.
i think the second options isnt there if you use Rom Manager from the market to install your ClockWork Recovery.
Click to expand...
Click to collapse
Confirmed.
I am using clockwork premium from the market.

Does Viewsonic Have a Fix for This?
Does Viewsonic Have a Fix for This that does not involve installing software that Viewsonic says will void your warranty?
This does not seem right to me that the way to fix this problem is to install third party management software and partition the SD card.
If Viewsonic doesn't offer a fix for this, then in effect there is a hardware problem with the G Tablet and Staples was completly justified in pulling the product.
I was having all kinds of forced close issues and restored the tablet in settings to factory reset and that fixed the problem for now.
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?

GaryHypnosis said:
Does Viewsonic Have a Fix for This that does not involve installing software that Viewsonic says will void your warranty?
This does not seem right to me that the way to fix this problem is to install third party management software and partition the SD card.
If Viewsonic doesn't offer a fix for this, then in effect there is a hardware problem with the G Tablet and Staples was completly justified in pulling the product.
I was having all kinds of forced close issues and restored the tablet in settings to factory reset and that fixed the problem for now.
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?
Click to expand...
Click to collapse
Its a software problem. The hardware is fine.

butchconner said:
papote18:
Did you literally mean 2040/0? Or is the 2040 a typo?
It should be 2048, but it's beyond me what would happen if you used another value!?
Rev
Click to expand...
Click to collapse
It was a typo, I am going to repartion the SD card and update to Vegan 5.1 hopefully that fixes the problem.

Manufacturing Issue
thebadfrog said:
Its a software problem. The hardware is fine.
Click to expand...
Click to collapse
I think Viewsonic had said that the recall by Staples was due to a customer experience problem and not with a manufacturing issue. This is not a direct quote but very close.
An internal SD card is hardware, and this defect seems to be that these were possibly not formatted correctly by Viewsonic or their supplier prior to being installed into the G Tablets. And, that is a manufacturing issue. I don't want to get into a flame war with you over the terms software or hardware. My point here is that the solution should come from Viewsonic. Many people on this forum are quite comfortable with these MODs. That is not the point of my post. These may be wonderful ways of making your tablet perform the way you want it to. My problem with these solutions is that once you have made them, you have let Viewsonic "off the hook" because you have voided your warranty.
Here is a quote from Roebeet talking about opening the case on the G Tablet to push the reset button in another post. However the same could be said for all of these issues! "We shouldn't have to void our warranty (open the case and push the hard reset button), just to do a hard reset". Here is my quote "We shouldn't have to void our warranty just to get the tablet to work at an acceptable level either".
Viewsonic should provide a way to partition the SD card that does not involve voiding your warranty! Until Viewsonic comes up with a way to fix these problems in software, their stock answer when you call their tech support line is to send the unit in for repair.

GaryHypnosis said:
I think Viewsonic had said that the recall by Staples was due to a customer experience problem and not with a manufacturing issue. This is not a direct quote but very close.
An internal SD card is hardware, and this defect seems to be that these were possibly not formatted correctly by Viewsonic or their supplier prior to being installed into the G Tablets. And, that is a manufacturing issue. I don't want to get into a flame war with you over the terms software or hardware. My point here is that the solution should come from Viewsonic. Many people on this forum are quite comfortable with these MODs. That is not the point of my post. These may be wonderful ways of making your tablet perform the way you want it to. My problem with these solutions is that once you have made them, you have let Viewsonic "off the hook" because you have voided your warranty.
Here is a quote from Roebeet talking about opening the case on the G Tablet to push the reset button in another post. However the same could be said for all of these issues! "We shouldn't have to void our warranty (open the case and push the hard reset button), just to do a hard reset". Here is my quote "We shouldn't have to void our warranty just to get the tablet to work at an acceptable level either".
Viewsonic should provide a way to partition the SD card that does not involve voiding your warranty! Until Viewsonic comes up with a way to fix these problems in software, their stock answer when you call their tech support line is to send the unit in for repair.
Click to expand...
Click to collapse
And they will update the software

GaryHypnosis said:
Third party programs (clockworks and new ROMs ) should not be the solution for fixing problems with the G Tablet. These problems need to be addressed by Viewsonic!
Doesn't anybody else feel this way?
Click to expand...
Click to collapse
I think I understand what you are saying, but at the same time they have released the source code and are giving updates. Another option would be just to abandon it and come out with a new device (ie samsung). I bet the majority of people buying these just think they don't work and return them. Viewsonic is probably eating their hat on this whole issue. This will be how they learn. "Return for service" seems like a really stupid way to deal with all these issues people are having
On the other hand, how many problems have you had with windows or linux which required 3rd party software to solve? I can think of quite a few.
I'm just thankful people on here 1/ know what they are doing and 2/ care enough to share answers. Thanks.

I agree with GaryHypnosis comments, as for the past 24 hours i've been struggling with a brand-new G Tablet that crashed within 5 hours of being first powered up.
Unfortunately for me, i bought it from an ebay dealer that will not accept returns and after i called the Viewsonic G Tabet line the rep told me that the best thing to do would be to return it and ask for a new one, or try to do a reset from the "settings" control tab (since my G Tablet crashed i can't even access that any longer), or WAIT FOR 30 DAYS FROM DATE OF PURCHASE TO SEND IT TO VIEWSONIC FOR REPAIR [email protected]#f**k !?
At this point i am not even sure that Viewsonic will accept it under warranty considering that i bought it from an ebay dealer...
I can't download these Mod files because my G Tablet's web access is blocked due to the fact that i can't sign-in because the tablet's keyboard doesn't appear onscreen any longer and i tried downloading Mods by way of an USB connection between my desktop and the G Tablet, but it did not work.
Right now i feel that i committed a huge mistake by buying this piece of crap that uses an unfinished OS that doesn't even offer disk defragmentation or disk clean-up, let alone a hard button for re-set. I understand there is such a hard button located internally, but i don't see why buyers should have to deal with opening the case and voiding whatever warranty it comes with.
I will never buy another product from VIewsonic, and after my call to the company's G Tablet "experts" phone line and hearing what he told me, i would advise people to do likewise

As best I can tell, no one has actually permanently bricked one of these things. Anyone have a broken one for doing software mods?
Anything you install on it can be changed back to the "stock" software and I'm not sure how anyone would even know you had done anything to it. Returning it to viewsonic for software problems is equivalent to killing a gnat with a nuclear weapon. It doesn't seem worth the cost and time. I'd only do that if I lost a monitor or a touchscreen went bad (ie truly hardware related failure).
It only takes installing clockworkmod, and then vegan (5) already had working market and flash for me. It was the easiest one yet. The newer tntlite had working flash. To get the market working required about ten button presses and a reset.
I still don't understand why people try to keep going on the tnt software at all (unless you count tntlite...). OBVIOUSLY the people who made that didn't do an A+ job.
Hope I don't sound mean here, but with the wealth of knowledge on this website, why would you expect a minimum wage worker answering at the call center to know 1/10th as much as the people developing custom roms?

Is there a way to confirm the partitoning worked? I am on tntlite 4.0 and things seem to have gotten worse with more force closures after the partition. This is what I did:
Clockwork backup of tntlite 3.1.4
Clockwork partitioning
reboot
clockwork update from update.zip of 4.0
Any help appreciated.

Observations as to why market breaks / force close, and other anomolies

As I suspected early on the issues boil down to corruption within the User Data or Cache partitions, less often on the system partition due to an unexpected shutdown of the device. Shut on these devices need to follow the proper shutdown routine as any linux environment. Following this best practice will ensure that all data is written out to its corresponding file system by flushing all cache, unmounting the file system, etc..
Here are the culprits of why we see so frequent random Force Closes, Market Resetting, etc. ultimately resulting in an unclean shutdown, corrupting some data.
1. The button we use is also a forced off button. Typically if you hold it down too long you are powering off the device.
2. Some times when in sleep mode you see the Viewsonic logo upon starting - that means that the system shutdown (most likely crashed).
3. If your running Vegan your hitting the reboot.. I dont know for sure but I suspect this is NOT performing a clean shutdown... (I dont have a copy of the source)
Anyway... wanted to pass this on... as last night my data partition became corrupt after using the Reboot function on the Poweroff menu of Vega 5.1..

shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing

My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.

roebeet said:
My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.
Click to expand...
Click to collapse
I have been on stock since I got the device just moving to the newer versions when they come as OTAs and have never ever had to mess with my partition, so I don't THINK the issue is in the stock software. In fact, the only problems I've ever encountered were when I used the enhancement pack, in which case my screen started to become unresponsive and the calibration.ini I was told to try did not work. Since then I went back to 3389 and the device has been perfect ever since.
I could be wrong though and just very, very lucky....here's to hoping. Another thing to consider is maybe the memory is going bonkers for some reason. I've had flash memory that lasted forever and I've had flash memory that has gone wacky over a period of 6 months....even a wipe by the utility designed to do it doesn't fix it properly. I don't know how CWM wipes or partitions the memory, I do know there's supposed to be a special way to do it.
If it's not faulty memory off the bat, then that leaves something in the 'extras' being put into these ROMs. Maybe some of the newer tegra drivers or some coding to make the ROMs faster - I'm just saying, can't leave any stone unturned.
Has anyone that has stayed loyal to stock encountered these issues? We have to ask that question I think. Then we ask how many of the people playing with ROMs are seeing the issues, this would include people that have used CWM to partition and mess with their mounts initially.
I can say I've never seen data disappear from my internal memory or my SD and I can also say I've never seen multiple FCs except after putting in the enh. pack (keep in mind I got my tab on Dec 20something, so I had 3053 and then 3389 soon after).
The first sign of anything being 'corrupted' on it's own at stock and I'll be sending mine back. As an owner of Android since Android's been around, I've never had my G1 or MT4G (or any smartphone before it) become corrupted due to not being shutdown or reboot properly and while this is a tablet I think the fundamentals should be the same. Pampering 'faulty' memory is a risk. You can wipe and re-do all you want, but if it's faulty it's going to stay that way.

Ive done that but I guess you can say unfortunately I have had only clean shutdowns since then... The last corruption I had I formatted my data and cache partitions before I ran logcat.... Of course thought of that afterward....
Generally if any has FCs, etc. etc. run a logcat and post it here... we will be able to confirm this...
We could change the way the partitions are created and add a sync which will further reduce chances BUT will take a performance hit...
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I reviewed the out of the box framework source on the google GIT and technically if a reboot command is given a clean shutdown is performed via the framework... but the widget on the shutdown screen I suspect is not calling the method properly or is not being called at all... All speculation at this point... But for sure there is corruption occurring..
Since the last corruption I switch over to pershoots kernel... Even though his kernel seems to be a little slower he seems to have included the latest drivers which other items relate to data integrity (im reading into the release notes).
NEO: The first thing I did when I got my device install CW, Vegan... Updated Kernels also... Never had an issue until the first time (yes about a day ago) I used the reboot feature of Vegan. That corrupted my user data. I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
But again.. between the wrongly placed power switch, the unprovoked reboots (ie viewsonic screen showing when trying to wake up the device) and the reboot button possibly not performing a proper shutdown will sure increase the chances in a wider distribution of users. So it may not be a CW issue and just some poor design.
When I have time today I will verify if the reboot function performs a clean shutdown... if anyone has the time please post the logcat... Im going to be running around today and will try to get to it..
watson540 said:
shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing
Click to expand...
Click to collapse

stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
Click to expand...
Click to collapse
AFAIK they're running yaffs ATM. Next move is to ext4...
Read some articles about this several weeks ago, apparently many apps do not properly flush file caches. One of the articles was a Google developer post about file corruption along with their API method which did a cache flush prior to a close, then a bit later was the Google indication that they were planning to move to ext4 FS to further help alleviate the problem.

stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
Click to expand...
Click to collapse
That's my point. How many times since we've had our Android and smart phones have we had situations where they are turned off or rebooted without the proper procedures? Power drains till they die, they drop and reboot, we clog them up with stuff or some app drives them nuts and they reboot or shut off....Yet you rarely if ever hear about a phone's data being 'corrupted' with stock software. Sure it may happen with official OTAs etc, but never just off-the-bat like what's happening with the G-Tab. But it's not happening to everyone either so I'm just looking to see if there's a pattern.
Even since the G1 and newer phones, you don't really hear about or see file corruption issues on stock software with these phones. It's when users start going to ROMs that you hear of issues cropping up. That's not to say it doesn't happen at all at stock, I just think we're seeing it in a more concentrated fashion here because of all the formatting, re-partitioning, etc. At first you hear, 4GB is a great partition size, then you hear there are problems so move to 2048, then you hear 256MB swap, then no swap since Android doesn't use it. Then dataloop for speed, then no dataloop because of critical issues. Rules and instructions change almost on a daily basis. I think it's more than these poor flash drives can take I find sometimes it's good to keep it simple.
I owned a Vibrant for a while...decided it was a PoS when at stock I was seeing bad lag (because of Sam's terrible FS). People said...do the speedhack, it'll be fast!, but what was the caveat? Having to reboot the phone almost weekly, sometimes several times a week, and people were seeing what? Data corruption. That's not for me. Give me something that is lag free (doesn't have to be a bullet train, just don't skip on video or audio and make sure my live wallpaper and drawer animation is fluid and I'm happy!). Point being....keeping it simple may help to alleviate some of the issues. If people are seeing these problems with stock, then you're absolutely right and it would be a point of contention that the failsafe isn't working right.
Otherwise it seems the stock OS on these things are able to self correct in most situations and it may just be some of the many tweaked features in these ROMs doing something it shouldn't - or, I may just be very lucky indeed.
I'm still dying to get the OTA - I haven't seen one since 3899 yet.

eMMC sudden death research

Update from Feb 17th:
Samsung has started to upgrade eMMC firmwares on the field - only for GT-I9100 for now.
See post #79 for additional details.
Update from Feb 13th:
If you want to dump the eMMC's RAM yourself, go ahead to post #72.
I'm looking for a dump of firmware revision 0xf7 if you've got one.
-----------------------
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?

Oranav said:
Since it's very likely that the recent eMMC firmware patch by Samsung is their patch for the "sudden death" issue, it would be very nice to understand what is really going on there.
According to a leaked moviNAND datasheet, it seems that MMC CMD62 is vendor-specific command that moviNAND implements.
If you issue CMD62(0xEFAC62EC), then CMD62(0xCCEE) - you can read a "Smart report". To exit this mode, issue CMD62(0xEFAC62EC), then CMD62(0xDECCEE).
So what are they doing in their patch?
1. Whenever an MMC is attached:a. If it is "VTU00M", revision 0xf1, they read a Smart report.
b. The DWORD at Smart[324:328] represents a date (little-endian); if it is not 0x20120413, they don't patch the firmware. (Maybe only chips from 2012/04/13 are buggy?)​2. If the chip is buggy, whenever an MMC is attached or the device is resumed:a. Issue CMD62(0xEFAC62EC) CMD62(0x10210000) to enter RAM write mode. Now you can write to RAM by issuing MMC_ERASE_GROUP_START(Address to write) MMC_ERASE_GROUP_END(Value to be written) MMC_ERASE(0).
b. *(0x40300) = 10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00
c. *(0x5C7EA) = E3 F7 89 FD
d. Exit RAM write mode by issuing CMD62(0xEFAC62EC) CMD62(0xDECCEE).​10 B5 looks like a common Thumb push (in ARM architecture). Disassembling the bytes that they write to 0x40300 yields the following code:
Code:
ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------
Disassembling what they write to 0x5C7EA yields this:
Code:
ROM:0005C7EA BL 0x40300
Looks like it is indeed Thumb code.
If we could dump the eMMC RAM, we would understand what has been changed.
By inspecting some code, it seems that we know how to dump the eMMC RAM:
Look at the function mmc_set_wearlevel_page in line 206. It patches the RAM (using the method mentioned before), then it validates what it has written (in lines 255-290). Seems that the procedure to read the RAM is as following:
1. CMD62(0xEFAC62EC) CMD62(0x10210002) to enter RAM reading mode
2. MMC_ERASE_GROUP_START(Address to read) MMC_ERASE_GROUP_END(Length to read) MMC_ERASE(0)
3. MMC_READ_SINGLE_BLOCK to read the data
4. CMD62(0xEFAC62EC) CMD62(0xDECCEE) to exit RAM reading mode
I don't want to run this on my device, because I'm afraid - messing with the eMMC doesn't sound like a very good idea on my device (I don't have a spare one).
Does someone have a development device which he doesn't mind to risk, and want to dump the eMMC firmware from it?
Click to expand...
Click to collapse
:crying: --> **Ultimate GS3 sudden death thread** :crying:
Just wanted to link to a prior thread with some information/testing that as been done. Completely understand if you nuke it because it doesn't meet the proper criteria or is way to noobish to be posted here. Anyway, just though it _might_ help, so giving it a shot..

So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.

Oranav said:
So I decided to do a small RAM dump after all.
Before the patch, 0x5C7EA reads FD F7 C2 FA, which is "BL 0x59D72".
As I thought, they replace a function call to the new one.
I will dump function 0x59D72 later this week.
Click to expand...
Click to collapse
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.

odewdney said:
So it looks like the new function calls the old function, and then if it returns ZERO then in goes into an INFINITE loop?!?
Seems like an odd fix, maybe self presevation?
Oli
Click to expand...
Click to collapse
Right, haven't spotted this. Thanks for the observation.
Self preservation sounds possible.
Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
This could be possible - this patch looks like a quick and dirty fix, so maybe they didn't have the time to properly fix this. Instead, they just avoid the bug absolutely (with the cost of data corruption).
But I don't think this would cause lockups - I believe the chip has a watchdog...
All in all, I think the best thing we can do right now is to dump the whole firmware out of it. I will do it soon.

there is also a chance that this is just a temporary workaround to prevent further bricking - until there is a final fix.
As of now we asume that this is the fix as it directly adresses the eMMC in concern, but all this is just based on asumptions.

Rob2222 said:
WELL... after I changed to XXELLA stock firmware and stock kernel in 01/13 my 06/12 SGS3 had the _first freeze ever_ on XXELLA. Maybe its completely unrelated and was only a random thing.
But, could it be, that this fix temporary (until reboot) locks the eMMC in a bad situation to avoid damaging internal data structures?
But then in this cases you get a phone freeze, cause the eMMC is temporary unaviable so the phone crashes until you reboot it. But it avoided eMMC data structure damage.
Sounds not very logical, but when you have to fix a problem and only have a few bytes to patch it (cause it must be run on every emmc-start), and the problem only occurs on a hand full devices (out of millions) then it is maybe acceptable to have a freeze instead of a dead eMMC in that rare cases that it occurs.
But this is only a idea... don't now if it is like that.
BR
Rob
PS: Oranav, thank you very much for your effort.
Click to expand...
Click to collapse
I think we can prove that the fix is actualy locking into loop ,but you must risk your phone :/ . If you are in ->
1) Flash back to older version without the fix
2) Wait and pray
a) If your phone dies --> the guys were right about the fix and the loop
b) If it stays alive ,then ...
We wont know for sure ,but your phone is maybe in the "perfect" condition for the test :/ .
(Sorry if this makes no sence)

@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert

Rob2222 said:
I have no idea if it's that way, I just wanted to post it as theory to think about.
Click to expand...
Click to collapse
The problem is that there are too many theories imaginable, but I can't think of no way to prove them but to reverse engineer the MoviNAND firmware.
Rob2222 said:
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
Click to expand...
Click to collapse
Certainly not. Watchdogs are slow, drivers running on a Cortex-A9 are blazing fast.
But I do think Linux's MMC driver can handle device restarts during an MMC operation.

Rob2222 said:
@ivan:
Sorry, can't do that. Cause of high air humidity my humidity indicator is already a little soaked. Cause of the warranty-repair reports in out local forums I am not sure if I would get warranty. I think theres a fair chance, that they would deny my warranty. Cause of that I don't want to take any extra risk. I am on unrooted stock at the moment, cause of that.
@Oranav:
In our local forum we get some reports about a rising count of locks and restarts on S3's in the last time. Some like my freeze.
It also seems that after a while this problems gets better and even disappear completely.
Cause of that I am thinking, if it could be, that the fix maybe locks the eMMC if it finds a bad data structure, then this locks maybe could bring a phone-freeze (already stated that), and in the same time it repairs the data structure in this block with the bad data structure.
At least this would explain some rising count of freezes with the fix and the point, that the freezes become less and less over time.
I have no idea if it's that way, I just wanted to post it as theory to think about.
BTW, do you think when the watchdog restarts the eMMC that it goes that fast that the phone isn't affected?
BR
Robert
Click to expand...
Click to collapse
if those freezes are really caused by the firmware fix, I don't see how the would disappear over time...
I mean if it really is the case that the fix trades data corruption for eMMC survival, it would make sense to see freezes... but depending on what data is affected, they should only be treatable by reinstalling the affected app or deleting its data/cache.
updated theory:
for all we know the error condition where the eMMC dies is quite rare, since most devices have been used for month before they passed away. So under the assumption that the error condition appears randomly and that there is a chance of data corruption every time the condition appears with fixed kernel, we could expect to see freezes and other problems some time after the fix was applied. So that would explain the raising number of freezes reported. Furthermore I'd assume that people getting freezes would try to do something about it, like reinstalling/deleting apps wiping caches and/or data... or even reflashing, thus repairing the corrupted data. So freezes would disappear.
Wait, doesn't most evidence point to the fact that the error condition does NOT appear in a random fashion, since there were no cases in the beginning, and then a lot all of a sudden? Well, it might be that this is just the way we perceive the issue. Maybe there were cases before, but they weren't reported... phones died, people sent them in, got new ones and went on with their lives. But after some time the issue got known... bloggers wrote about it... and so on... people realized their phones died because of a wider problem... voila, steep raise in reported cases. Also the number of dying S3s would simply rise by a rising number of overall S3s, I mean Samsung kept selling phones, right?
But even under the assumption the bug is related to wear-levelling and not random, here is another idea: I have no clue how the algorithms work, but maybe it uses some sort of pseudo-random data to do whatever, with the same seed on all eMMCs... and thus all of them go through the same series of numbers. And now imagine the error condition is only triggered by a specific number or number set (say someone screwed up a boundary condition). Under this theory the error condition wouldn't appear randomly, but after a certain amount of write ops (or something).
Another question I asked myself is: shouldn't there be cases were data corruption does damage beyond all repair except for reflashing?
Well, it might be, but it seems reasonable to assume that it is a lot less likely than user-data corruption, since most critical files on the phone shouldn't be opened writeable (or are on a read-only mounted partition in the first place), hence shouldn't be affected by ****-ups during writes.
Like the previous poster I want to add that this is most likely all bull****... but it is what came to my mind looking for a theory that supports the data we got.

Okay, got a RAM dump
I won't post it here (or anywhere else for that matter) because I don't want to get sued by Samsung.
I might release a kernel which allows you to dump the RAM yourself if there's enough demand, but I don't want to right now, because:
1. The code is ugly as hell, not implemented as a kernel module, not thread-safe etc.
2. It is highly dangerous (messing with the eMMC chip - I really don't know how much stable this thing is), so if you want to do it on your device, you should be an expert. In that case, you can write the code yourself (with little effort)
Anyway, I hope the FTL is Whimory, since I'm familiar with it. Would be easier.
I'll let you know if I find anything interesting.
PS I've attached a little teaser. (Yes, this is the patched function. 0x40300 is red because I've opened a partial RAM dump.)
EDIT - Some initial results:
0. The CPU is a Cortex-M3.
1. No strings at all Just some uninteresting release asserts ("REL_ASSERT")
2. Found the Smart Report generator function -> found the MMC command handlers.
3. Most MMC commands handlers are stored in a function table. There are 3 special commands: MMC60, MMC62, MMC64. Depends on the arguments these special commands are provided, they modify the function table (this is the so called "vendor mode").
4. There are a lot of possible arguments for MMC62, not the only ones we know.
5. If you trace back the function they patch all the way up the call stack, you get to MMC24 and MMC25 handler. These commands are MMC_WRITE_BLOCK and MMC_WRITE_MULTIPLE_BLOCK. Since the function they patch is deep down the call stack, it's very likely that it is the wear level.
Anyway, because of the lack of strings I guess it would be very hard to truly understand the SDS bug we're facing

Odp: eMMC sudden death research
i cant say i have an idea whats going on inside emmc but usually in this case of mistakes/failures debug or diagnostics code is used for release.
maybe some debug info repeatedly written triggers wear levelling failure
so fix has to simply disable it

Awesome research.
So we're dealing with bug in exactly the same eMMC subsystem as in faulty SGS2 eMMC chips, but in device that was released after proving SGS2 eMMCs to be faulty.
Oranav, for some reason I cannot send you PMs. Could you send me your dump? Does your eMMC come from faulty serie?

Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.

owl74 said:
Hi all, after reading this thread, I am now scared....
I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3
The above all include the fix for SDS and Exynos hole.
I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.
This is weird, never experienced this before... I am now scared the phone will die unexpectedly.
Click to expand...
Click to collapse
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.

I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app

Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Click to expand...
Click to collapse
Damn Oranav, nice work!
So does it mean you get a total screen freeze? Every time?
BR
Robert

thealgorithm said:
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.
Click to expand...
Click to collapse
About 2 weeks. Forgot to mention i reebooted the phone before I charged it. I will return this phone before it dies on me.... I think I will get an S3 but I will check if it has a new chip... otherwise I will return again and stick to my desire hd which is already running S3 rom....
---------- Post added at 02:24 PM ---------- Previous post was at 02:22 PM ----------
Oranav said:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.
Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
So everyone's speculation is right about thw fix causing the freeze...

AW: eMMC sudden death research
Suppose this fix addresses wear leveling. If firmwares without this fix wear out the eMMC would then not the device still boot and then crash? As far as I know flash is still readable but not writable any more when worn out. Could it be that the wear leveling algorithm has a problem so that after some time it replaces cells from the bootloader and that causes the death?
In short: I want to know if it had a negative effect using the old firmware for some time because that old software caused extreme aging for the eMMC.

Lenovo A850 Bricked and cannot use USB

I have a bricked Lenovo A850 with a faulty USB connector, while it can charge it cannot connect to the computer. It goes into a bootloop and all I can access is the Android System Recovery 3e. Without a custom recovery installed and without the possibility to connect this phone via SP Flash Tool/ADB I feel clueless about what should I attempt. I ordered a replacement part, a dock charging board which I believe could bring back this phone to life. It is not a driver issue, I do not reach the point where I can see something in Device Manager or USBDeview. All I see in USBDeview is "Unknown USB Device (Device Descriptor Request Failed). Meanwhile can anyone provide me some hints about what is possible to do.
Since the Android System Recovery can only load a update.zip file I have no idea if is possible to flash a stock ROM from the Android System Recovery. Without CWM/TWRP I feel totally lost. I tried to install some image file for CWM/TWRP, by renaming them to update.zip but I did not work. I got the impression that a stock phone does want us to push a custom recovery and flash a ROM. The fact that the Android System Recovery starts gives me some hope that it is not a hard brick yet.

René Droidz said:
I have a bricked Lenovo A850 with a faulty USB connector, while it can charge it cannot connect to the computer. It goes into a bootloop and all I can access is the Android System Recovery 3e. Without a custom recovery installed and without the possibility to connect this phone via SP Flash Tool/ADB I feel clueless about what should I attempt. I ordered a replacement part, a dock charging board which I believe could bring back this phone to life. It is not a driver issue, I do not reach the point where I can see something in Device Manager or USBDeview. All I see in USBDeview is "Unknown USB Device (Device Descriptor Request Failed). Meanwhile can anyone provide me some hints about what is possible to do.
Since the Android System Recovery can only load a update.zip file I have no idea if is possible to flash a stock ROM from the Android System Recovery. Without CWM/TWRP I feel totally lost. I tried to install some image file for CWM/TWRP, by renaming them to update.zip but I did not work. I got the impression that a stock phone does want us to push a custom recovery and flash a ROM. The fact that the Android System Recovery starts gives me some hope that it is not a hard brick yet.
Click to expand...
Click to collapse
I can only assume four things:
1. Your phone had OTA and you installed it, therefore ANY kind of flashing will not work before you flash stock.
2. You have the generic chinese (non-ROW) unit, therefore there is 2% success rate of flashing anything with the generic tools, not the specific tools made by Chinese devs.
3. In the USB department, your work does not end there, as there is few more steps you have to do, GreatApo made a post about that.
4. As I said, SPFlashtool is the wrong tool. Use the tool made specifically for MTK phones like the MTKDroidtools.
And FYI, this particular model (some units) does not support flashing via ADB commands, as those libs are removed by SOME manufacturer, well they want you to STICK WITH THEIR FLASHY STOCK ROM WHICH ISN'T PRACTICAL.

Thanks for shedding a bit of light on my dead Lenovo’s phone. I really appreciate your insight. :good:
I have a 15 years of experience as a Windows desktop application developer, while I love Android there are some issues on their platforms that sometime can be counter intuitive. I personally only had Samsung and HTC phones, was always a breeze to flash, root and maintain. This MTK phone is giving me headaches. If ADB libs were indeed removed I will need to go through a yoga sessions before I throw this phone on the wall! :silly:
This is my girlfriend’s phone, everything was stock, standard and unrooted. If OTA was installed, well I really don’t know for sure but it was certainly not her who install it.
If Chinese or ROW I got no idea. This phone was bought here in Vietnam from a reputable Lenovo authorized retailer and my girlfriend said it was "Chinese". I assume that the proximity with China’s market would point out to a non-ROW model. Android System Recovery 3e is posting some message at the bottom in Vietnamese, it really makes me wonder if it could be ROW? I wish there could be some kind of indication into the model/serial number to sort this out once for all. Anyway, I ran unto MTKDroidtools, looks interesting but it remains useless for the time being. I will try my 1st best shot at MTKDroidtools once I restore the USB connection.
The USB connector has been loose and had intermittent charging issues for very long time. For more than a year my girlfriend gave to it all sort of bending, twisting and tilting at every possible angles in order to fully charge her phone. She even played into the connector with some hair pins! I guess the charging board had enough beating and at 4$ a replacement part it may worth to replace it and pray for a miracle. :angel:
Beside the USB connectivity issues, for long time her phone was constantly out of internal storage and that was triggering all sort of problems. Removing applications was never freeing enough space to keep the phone functional long enough. She had this problem 18 months long, before even meeting me! Lenovo prevents to move apps to SD. With all those issues and with the battery draining bloatware I have seen enough of Lenovo’ crap. I was considering to schedule a full flash on this phone with possibly a custom ROM on her next day off in two weeks. I assumed her phone would hold it up till then. Meanwhile I finally managed to free a good chunk of memory by removing Viber’s pictures and logs, something like 300mb. I felt her phone was breathing and running smooth again, it did well for two weeks until the recent fatal boot loop incident happen. After I freed some space her phone went into many updates, I did not really pay attention to what needed to be updated. I guess after 18 months a lot of updates where pending. If firmware updates were pushed in her phone through OTA, I have no idea but it sounds plausible.
The one thing that puzzled me was the fact that this phone says it has two SD cards, one must be some kind of software emulation. I noticed that when her phone was still functional but I never had the time to dig into this. Even Android System Recovery is looking for updates.zip on two different SD, so it looks like some kind of low level partition to me. Was there something on that second SD that I could have deleted by accident that could have created this boot loops?
I will work more on my USB connectivity issues and I will share my findings about my outcomes!
Thank you so much!

René Droidz said:
Thanks for shedding a bit of light on my dead Lenovo’s phone. I really appreciate your insight. :good:
I have a 15 years of experience as a Windows desktop application developer, while I love Android there are some issues on their platforms that sometime can be counter intuitive. I personally only had Samsung and HTC phones, was always a breeze to flash, root and maintain. This MTK phone is giving me headaches. If ADB libs were indeed removed I will need to go through a yoga sessions before I throw this phone on the wall! :silly:
This is my girlfriend’s phone, everything was stock, standard and unrooted. If OTA was installed, well I really don’t know for sure but it was certainly not her who install it.
If Chinese or ROW I got no idea. This phone was bought here in Vietnam from a reputable Lenovo authorized retailer and my girlfriend said it was "Chinese". I assume that the proximity with China’s market would point out to a non-ROW model. Android System Recovery 3e is posting some message at the bottom in Vietnamese, it really makes me wonder if it could be ROW? I wish there could be some kind of indication into the model/serial number to sort this out once for all. Anyway, I ran unto MTKDroidtools, looks interesting but it remains useless for the time being. I will try my 1st best shot at MTKDroidtools once I restore the USB connection.
The USB connector has been loose and had intermittent charging issues for very long time. For more than a year my girlfriend gave to it all sort of bending, twisting and tilting at every possible angles in order to fully charge her phone. She even played into the connector with some hair pins! I guess the charging board had enough beating and at 4$ a replacement part it may worth to replace it and pray for a miracle. :angel:
Beside the USB connectivity issues, for long time her phone was constantly out of internal storage and that was triggering all sort of problems. Removing applications was never freeing enough space to keep the phone functional long enough. She had this problem 18 months long, before even meeting me! Lenovo prevents to move apps to SD. With all those issues and with the battery draining bloatware I have seen enough of Lenovo’ crap. I was considering to schedule a full flash on this phone with possibly a custom ROM on her next day off in two weeks. I assumed her phone would hold it up till then. Meanwhile I finally managed to free a good chunk of memory by removing Viber’s pictures and logs, something like 300mb. I felt her phone was breathing and running smooth again, it did well for two weeks until the recent fatal boot loop incident happen. After I freed some space her phone went into many updates, I did not really pay attention to what needed to be updated. I guess after 18 months a lot of updates where pending. If firmware updates were pushed in her phone through OTA, I have no idea but it sounds plausible.
The one thing that puzzled me was the fact that this phone says it has two SD cards, one must be some kind of software emulation. I noticed that when her phone was still functional but I never had the time to dig into this. Even Android System Recovery is looking for updates.zip on two different SD, so it looks like some kind of low level partition to me. Was there something on that second SD that I could have deleted by accident that could have created this boot loops?
I will work more on my USB connectivity issues and I will share my findings about my outcomes!
Thank you so much!
Click to expand...
Click to collapse
Human breathren, I see that thee art having a problem with thy phone, and I knoweth jump what thee hath felt. As such, alloweth me pray pardon me to thee what actually is going on.
Lenovo is technically a Chinese company, but the good one. They make great smartphones at such a price you can say "YEP, TOTALLY WORTH IT, 1080P SCREEN AT $100!", and that's a success Lenovo made. Because of that, unauthorized shippers ( and recently manufacturers) taking this advantage and gain money by "sideloading" units of their phones, that is SUPPOSEDLY for the country China only, to shippers who chooses to pay minimum shipping taxes, to WORLDWIDE.
Thus you may see Lenovo smartphones at 20% cheaper than original retail price plus taxes. These discounted phones are TOTALLY Chinese models that contain bloatwares that somewhat nonsense and useless.:silly::silly:
Chinese ROMs that come with it is really paced to straightforward users, that are not planning to customize their phone at framework level. So all bloatwares you see now is actually making sense for them, only, not for us power users.
First problem that I see now is your USB port. Well it's all about construction of the USB port opening (the plastic inner housing). The thing is, there is a significant little gap between the metal port and the housing, so for a long period of time, the metal housing bends thus damages the port until it becomes unusable. I lived with this, experienced this....it's so painful I know. See pic.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Second problem I see is storage problems. This particular phone has TWO partitions of system storage, namely internal and USB storage, totals up your 4GB you are getting. The one that ALWAYS getting full is your internal or C drive or '/sdcard0' (That's why if you want to move apps to SD card, the option is 'Move to USB storage') . Only Chinese ROMs have these because the second partition can emulate the functionality of a real SD card, and the point you ask? Well, easy for them to bulk flash their modified Chinese ROMs, with their special type of recovery and kernel which TILL NOW I cannot understand HOW it works.
What is left is 300MB+ of space for your apps, appdata and appcache. Bummer right?
So my workaround is, getting root, remove most of the bloatwares via Uninstaller[Thats the app icon colour]. And also (in planning, because I do not want to take risks before I confirm it'll work), moving entire /data from /system to /sdcard1.
SO THERE YOU HAVE IT.:victory:
huuhh.....
Source code for this phone just recently released. So I waiting a CM for this phone.:laugh::laugh:

Updates and problem solved!
UPDATES
After successfully replacing my charging board for 4$, I was finally able to flash a stock ROM and bring this phone back to life. Unfortunately, it wasn't smooth as I expected. I was challenged by two more issues:
1) MT65xx Preloader Problems: Dispite been able to update the driver to the right version "MediTek PreLoader USB VCOM Port" could not stay connected more than five seconds. I could clearly see in USBView that I could get a green connection but there was no obvious way that I could maintain it. Feeling hopeless, I started SP Flash Tool v3 1316, loaded the scatter file from a stock ROM and launched the download process knowing that nothing would happen since SP Flash Tool would be searching endlessly for a connection. Then I unplug/replug my phone, by some kind of magic the download process started and finished without a glitch! First boot went well and this phone was back in business. It seems that the USB connection could not stand being idle in Pre Loading, that some kind of command must be issue to keep the connection alive. After the first boot from a fresh Android, my computer correctly recognized my device as "Lenovo A850" without any issue.
2) Invalid IMEI. For some reasons I could not use my two SIM cards as previously since IMEI of both SIM slot were not identified by my new OS. I had to do some engineering tricks by using "Engineer Mode MTK Shortcut" and tutorial on Youtube. Lucky enough, my sticker inside my phone was still intact and could set those IMEI digits back on this phone. Everything seems to be functional now.
Will I buy a Lenovo phone again in my life? No! :crying: While the process of restoring this phone was interesting, the amount of time I spent on this phone was not worth it. My time is worth more than hours of trials and errors and having to deal with "Chinese customization" was not by cup of tea. I will get my girlfriend an Asus Zenfone 2 once this Lenovo gives up again.

René Droidz said:
UPDATES
After successfully replacing my charging board for 4$, I was finally able to flash a stock ROM and bring this phone back to life. Unfortunately, it wasn't smooth as I expected. I was challenged by two more issues:
1) MT65xx Preloader Problems: Dispite been able to update the driver to the right version "MediTek PreLoader USB VCOM Port" could not stay connected more than five seconds. I could clearly see in USBView that I could get a green connection but there was no obvious way that I could maintain it. Feeling hopeless, I started SP Flash Tool v3 1316, loaded the scatter file from a stock ROM and launched the download process knowing that nothing would happen since SP Flash Tool would be searching endlessly for a connection. Then I unplug/replug my phone, by some kind of magic the download process started and finished without a glitch! First boot went well and this phone was back in business. It seems that the USB connection could not stand being idle in Pre Loading, that some kind of command must be issue to keep the connection alive. After the first boot from a fresh Android, my computer correctly recognized my device as "Lenovo A850" without any issue.
2) Invalid IMEI. For some reasons I could not use my two SIM cards as previously since IMEI of both SIM slot were not identified by my new OS. I had to do some engineering tricks by using "Engineer Mode MTK Shortcut" and tutorial on Youtube. Lucky enough, my sticker inside my phone was still intact and could set those IMEI digits back on this phone. Everything seems to be functional now.
Will I buy a Lenovo phone again in my life? No! :crying: While the process of restoring this phone was interesting, the amount of time I spent on this phone was not worth it. My time is worth more than hours of trials and errors and having to deal with "Chinese customization" was not by cup of tea. I will get my girlfriend an Asus Zenfone 2 once this Lenovo gives up again.
Click to expand...
Click to collapse
*cries with you*:crying:
Just..give up man. Lenovo A850 is an architectural failure for me. Just wait for K3 Note for the CM to be released. Mine's dead already because of the USB failure and I gave up.

Wacky firmware

Joying "N2" firmware.
Looking into the process for booting to recovery, I started looking into the Joying firmware, specifically, the file fwu_image.bin. This is an interesting file, it appears to be a bootloader and/or some kind of hypervisor.
Some strings in it led me to find a tool called the "Intel Phone Flash Tool"
There is a LOT of potentially useful information in this thread; http://forum.xda-developers.com/gen...70-3g-sofia-atom-x3-c3130-quad-t3103085/page2
Other interesting strings;
USB Driver Bootcore module --- something about booting via USB?
There is a bunch of stuff about **fastboot**.
"rockchip,power-key-pressed-time" -- interesting. Does it respond differently to holding the power key for different lengths of time?
"%s BCB is boot-normal, set NVM to normal mode." -- this seems to be related to selecting boot modes based on data on NVM, i.e., what happens when you issue "reboot recovery".
Wonder what would happen if you ran "reboot bootloader"?
Some stuff about "special" key...
This stuff.... some kernel parameters, and, of course, the SERIAL NUMBER that freaks tomtom out;
Code:
phyBlk = 0x%x die = %d block_in_die = 0x%x 0x%x
0123456789abcdef
(null)
0123456789ABCDEF
bug in vfprintf: bad base
SF_3GR_ver 1639.400
1639.400_M1S1
,dDK
,DDK
androidboot.bootloader
androidboot.serialno
loader_charged
normal
androidboot.mode
ptest
charger
0123456789012345678901234567890
0123456789012345
update-radio/hboot
boot-fb-pt-updated
boot-fastboot
boot-recovery
update-psi
fb_update_bl
At least partial kernel commandline as; "console=ttyFIQ0,115200n8 idle=halt earlyprintk=xgold notsc apic=sofia androidboot.hardware=sofiaboard nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=permissive x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=2 uvcvideo.en_autosuspend=0 selinux=0 limit_cpu=disable mvpipe.at_dbg_port=1"
Note: serial console on ttyFIQ0, I wonder where that could be found.
Also note: selinux is in a pointless state. Major copout.
There are a *LOT* of strings in there that tie it to the FYT SoM. The bootloader is, no doubt, incompatible with MTCD boards.
There seem to be a LOT of references to hardware that these units do not have. Even found the string "huawei" in it. Makes me thing that this is a lot more than just a simple bootloader. This looks like it actually contains a *complete Linux kernel*. No wait, actually TWO.
This is really weird. Perhaps a bootloader followed by 2 kernels?
"/local/zengguan/RK-release-for-eoi/1511-official-release/mobilevisor/core"
"Mobilevisor/bootloader boot shared info structure version mismatch!"
Ok, so here is what I'm thinking;
1) It might have fastboot.
2) The USB keyboard - boot to recovery process may well avoid starting the boot partition, I think that it may be starting one of the kernels in the hypervisor partition, and using that to adjust the NVM to cause a recovery boot.
3) NEITHER of those are guaranteed, further study would be required.
Found THIS immediately before what appears to be fastboot:
"-----BOOT_REASON_LONG_ON_KEY-----"
So what does that mean? Boots to fastboot if you hold down the ON key for a long time? What is an ON key?
This comes AFTER fastboot:
"------display screen start------"
Could be that fastboot mode has no display output.
Hmm...
%s line=%d DOWN bit is set
%s line=%d DOWN and Power bit is set
Another edit... they aren't calling it a hypervisor, they're calling it a MICROVISOR. Essentially, a combined hypervisor + microkernel. The main kernel accesses security sensitive resources via the microkernel. Think of it as TRUSTZONE.
I *think* that the watchdog is implemented in the microvisor. With any luck, they didn't completely bonehead it -- a complete mess up should (if implemented in a sane manner) result in a reboot into some mode where recovery is possible, such as fastboot or recovery.

Found this; https://translate.google.ca/transla...96%87%E4%BB%B6%E6%8F%90%E5%8F%96/&prev=search
First thing I notice is that the partition table of THAT device, aligns with Joying N2 devices. This is very good news, because it means that we can learn about our device from it.
So that big file "fwu_image.bin" that I was looking into, is being written to ImcPartID122. This is important, because that website I linked above indicates that 122 is something of a "special" partition. Ok, by special, I really mean SCREWBALL.
Normally, your storage devices are laid out as following;
/dev/typeN --- for the "base" device, representing the entire storage area as a single file. Counts from 0 up.
and
/dev/typeNpM which splits out the different partitions of the device.
So if you just wanted to write a block of binary data to the beginning of the storage device, you normally would dd if=source of=/dev/typeN and be done with it.
But these devices are a bit screwball. ImcPartID122, for instance, seems to link to /dev/block/nand0p12 <-- 12th partition? Ok, its labeled as "ALL", so I think we can assume that this is somewhat similar in concept to /dev/block/nand0. Or maybe with some special offset? Probably would make a bit of sense for me to actually look at the real partition table to figure out what is going on.
NOTE: Yes, it is certainly possible for device partitions to overlap. Nothing to worry about in that regard.
So "ALL", explains why I was able to find two copies of the linux kernel in there. It actually *INCLUDES* both the boot and the recovery partitions! Or maybe boot and boot-backup, don't quite know just yet. So next you're going to say that this can't be so, since the file isn't sparse, and the boot partition comes after the system partition.... while it *looks* like the boot partition comes after the system partition (boot: ImcPartID071, system: ImcPartID068), this is not actually the case. Those "ImcPartID"'s are actually just names. 068 -> /dev/block/nand0p14, 071 -> /dev/block/nand0p9... Plus, the partition number really doesn't have to correspond to its physical ordering on the device, and as the "All" partition indicates, on these, it doesn't. So no conflicts -- that is good.

Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!

rcll said:
Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!
Click to expand...
Click to collapse
I used to use tomtom... back in around 2005-2008. They had a version that ran on PalmOS 5.whatever, so it was good for the old Treo 650. I'm not at all fond of the subscription model that they've taken on -- to hell with that!
For offline nav, I use Alk Copilot: https://play.google.com/store/search?q=copilot&c=apps&hl=en
As far as changing the serial number, I'm going to have to track it to what partition it is actually in, and figure out its layout.... determine if there are any other implications to altering it besides just changing the serial number. Would hate to see it cause BRICKING.