This post will evolve over time as more info is found:
Latest Updates
6/24 Custom PIT repartition workaround posted by Jaymoon.
You lose 8GB (some of which might be further recoverable with extra work) and restores using the original PIT will lockup your phone again (a scenario that could happen if you brought your phone back to Sprint for some unrelated problem) so if you have the opportunity to get your phone replaced with little to no cost, IMO that should be your primary option.
http://forum.xda-developers.com/showthread.php?p=27852689#post27852689
E4GT specific PIT file here (theoretically instead of losing 8GB, you'll only lose 2GB):
http://forum.xda-developers.com/showpost.php?p=28070569&postcount=654
6/8 Update for other platforms waiting for fix
Codeworkx's contact with Samsung got following response [discussion]
Update 14:56 CEST:
Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
Click to expand...
Click to collapse
6/7 Update
Test plan posted - see bottom of post for results so far (esoteric68, krazy_smokezalot report success)
BIG THANKS to Esoteric68 (and robertm2011 before her) who took the plunge to benefit everyone else. She has completed the test plan and more. 6 flashes of CM9, 3 flashes of AOKP, 3 wipe data/factory resets, and 3 nandroid restores, 1 stock FF02 flash, all successful. We are ready to have more testers try out the test ROM installs. We are getting more confident the code analysis was correct.
6/2 Update
Less technical summary and preparation for new round of testing
5/31 Lots of discussion on the code path detailing how the problem occurs and where to put the workaround, select posts below
Call trace for CWM Recovery - wipe data/factory reset
Call trace for CWM Recovery - restore
Section of update-binary afflicted by same issue as wipe data/factory reset
Recap of where workarounds can be placed
MD5s of various update-binary executables
Pros/Cons of placing workaround in kernel vs libext4_utils.a
Are ICS nandroid backup/restores safe?
Are ICS recoveries safe?
Why do CM9/AOKP installs often brick in ICS but not in GB?
5/24 Update pretty much ties up all the loose ends - Thanks Mr. Sumrall, Garwynn, Entropy, and everyone else who pitched in!
http://forum.xda-developers.com/showthread.php?p=26521643#post26521643
Potentially very GOOD NEWS
It appears Sprint/Samsung tested the EMMC brick issue, confirmed the problem, and tested a fix that appears to resolve the problem:
http://forum.xda-developers.com/showthread.php?p=26465085#post26465085
thirdcoastraised said:
To clarify this...in testing done over the weekend, there was a small "subtest" group which consisted of 20 devices. This group was put together STRICTLY for the propose of testing the emmc bug and fix. The devices were all programmed with the data known to have cause bricks when wiping. Of those 20, all but 6 also had the code patch to resolve that issue, so there was a possibility for 6 hard bricks, only 4 actually bricked, therefore, on the build currently being tested, the "emmc break issue" has been deemed "resolved"
Click to expand...
Click to collapse
We now have an update on why this bug is happening and which PRV/fwrevs are affected. PRV/fwrev 0x19 are susceptible to the EMMC /data corruption issue (which should now be referred to as EMMC lockup issue). PRV/fwrev 0x25 has the fix for the lockup issue but has a separate 32KB of zeros data corruption issue, which is being patched in the kernel (our kernels don't have that patch). All these problems are in the EMMC firmware. It can potentially be updated, but nothing is publicly available. EMMC lockup issue is triggered on erasing the EMMC. The only piece we have not been able to explain is why GB-based kernels seem immune to the EMMC lockup problem whereas ICS seems more susceptible to the problem. Presumably both are doing ERASE commands, but possibly in slightly different ways. See these posts for more details [#1 / #2]
To get your PRV/fwrev, you can use this (if you have busybox installed):
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat cid | cut -b 19,20
19
Click to expand...
Click to collapse
If you don't have busybox installed just visually parse the line, match the serial # (0xd3f24fe6 - example only - yours will be different) with the cid, and look at the 2 numbers before the serial #.
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat serial cid
0xd3f24fe6
1501004d414734464119d3f24fe68e8b
Click to expand...
Click to collapse
It appears after looking at the code more closely and examining the results of the card info dumps, we do not have this fix in our kernel. It isn't clear whether the fix would resolve our /data EMMC brick issues, but the point is moot right now because we don't have the fix.
Possible BRICK here. Please do NOT do any more testing until further notice. Please do NOT use Wipe Data/Factory Reset. It is the main difference between first and 2nd round of testing and is the current suspect
FE10 repacks added to Resource section
Esoteric68, azyouthinkeyeiz, and robertm2011 are testing flashing different ROMs with FE07/FE10 repacked with unlocked recovery. We all owe them our thanks for risking their phones to help the community (taking one for the team) No bricks so far.
Separately we are still discussing whether the fix Samsung checked in will get applied to our phone. No firm conclusions yet. Even if it doesn't apply, the hope is the data we get from testing will help us produce more flexible "safe" flashing practices.
Please do NOT test CWM Touch for now. We want to isolate just the FE07 kernel and unlocked stock recovery before introducing new variables.
Executive Summary
Garwynn has found a recent checkin from Samsung in the kernel code handling EMMC memory that fixes a data corruption problem. It is possible this might fix the /data EMMC corruption we have been seeing, but we aren't sure if it is fixing the same problem. The first release to include that checked in code is FE07. There has been some communication with the developers in charge of that area to gather further info.
This thread's purpose is to foster discussion on the issue and to determine if the potential fix actually does fix our issue. Even if the fix doesn't address the issue, it is hoped in the process we are able to gather more info into specific "safe" and "unsafe" scenarios.
Please do NOT jump ahead and think it is fixed. It is TOO EARLY to make that claim.
Background
As many of you are aware since ICS has come out, there has been a nagging issue where in some situations flashing ROMs with an ICS-based kernel and custom recovery has left the phone with EMMC corruption. This EMMC corruption is so far non-recoverable, even with JTAG bit blasting, which should bypass all but hardware issues.
This problem is NOT limited to the Epic 4G Touch. Other GS2 models as well as Galaxy Note are experiencing the same thing as can be seen by this Public Service Announcement in the Galaxy Note section.
The problem first cropped up when people used ROM Manager to temporary "fake" flash CWM Touch onto an ICS-based kernel to do their flashing needs. In particular wipe data/factory reset seemed to often trigger the /data EMMC corruption. However later we found it wasn't limited to just CWM Touch and temporary flashing as CWM repacks with the ICS-based kernel also exhibited that behavior, albeit not as often.
Even more frustrating is that this bug is not always deterministic, in that you could do some operation 3 times and have it work fine, then on the 4th, trigger the /data EMMC corruption.
Complicating the testing/debugging is the issue that once the problem is triggered, your phone is basically not recoverable. You can try and ODIN a stock ROM on top which will basically work for all the components except the /data partition. Once it reaches the /data partition, ODIN will hang. Similarly if you try and wipe data/factory reset, it will hang or timeout after a while. Attempts to repartition and reformat using ODIN have not changed this behavior. Attempts to edit the partition info manually have not been successful. JTAG bit blasting has not been successful.
You can read about the past experiences in the Stuck at "Data.img" thru odin thread. By the time you get to ODIN, the damage to /data EMMC is already done. ODIN is NOT causing the damage. ODIN is hanging on data.img because the hardware won't let it write successfully to that area of EMMC.
This has led to many custom ROMs giving special procedures to go back to a GB-based kernel repacked with CWM recovery to do all your flashing (EL26+CWM). It is also the motivation for the How Not To Brick Your E4GT thread.
Details
The code checkin that has piqued our interest is in regards to data corruption caused by problem in the wear-level firmware code of the emmc. This is low-level code that runs on a processor in the emmc module. It basically tries to spread out the data writes so you get an even distribution of writes so as any one section of emmc memory does not get worn out prematurely. This code apparently can corrupt data by writing 32KB of incorrect data under some situations.
https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53
The code appears to restrict the firmware fix to only certain "affected" emmc modules. Also it is not able to persistently/permanently patch the firmware so this code must run at each startup. The following modules were identified in the code:
Name: VYL00M
HwRev: 0x0
FwRev: 0x25
Name: KYL00M
HwRev: 0x0
FwRev: 0x25
Name: MAG4FA
HwRev: 0x0
FwRev: 0x25
Unfortunately during ad-hoc polling we have found a case of an EMMC /data bricked phone with fwrev 0x0, so either we are not understanding what Samsung's fix is doing or they may not have addressed the full scope of the problem. Do NOT assume if your fwrev is 0x0 you are safe.
At this point, this does NOT mean the fix is not applicable. We might be looking at the wrong data. The kernel might not be exporting the data to us. The fix might need to be expanded to more modules. The fix could be for something else entirely but we might be able to avoid the bug anyway using stock recovery.
To determine what version you have (keep in mind we are at the preliminary stage, so this info might not be the right info to collect or could be meaningless for the /data EMMC corruption issue)
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial cid
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
0xd3f24fe6
1501004d414734464119d3f24fe68e8b
Click to expand...
Click to collapse
The comments for the code checkin give the following info:
/*
* There is a bug in some Samsung emmc chips where the wear leveling
* code can insert 32 Kbytes of zeros into the storage. We can patch
* the firmware in such chips each time they are powered on to prevent
* the bug from occurring. Only apply this patch to a particular
* revision of the firmware of the specified chips. Date doesn't
* matter, so include all possible dates in min and max fields.
*/
Click to expand...
Click to collapse
The critical piece of code appears to be the following:
Code:
/* set value 0x000000FF : It's hidden data
* When in vendor command mode, the erase command is used to
* patch the firmware in the internal sram.
*/
err = mmc_movi_erase_cmd(card, 0x0004DD9C, 0x000000FF);
if (err) {
pr_err("Fail to Set WL value1\n");
goto err_set_wl;
}
/* set value 0xD20228FF : It's hidden data */
err = mmc_movi_erase_cmd(card, 0x000379A4, 0xD20228FF);
if (err) {
pr_err("Fail to Set WL value2\n");
goto err_set_wl;
}
Action items
At this point we would like to
1) gather more info on which emmc modules folks have and see if we can detect any patterns, so if you could post your EMMC info and optionally include whether you have the ability to do testing (presumably because you have a way to replace your phone if it is damaged)
2) solicit one volunteer to try different flashing scenarios using the unlocked stock recovery and FE07 kernel repack (bigpeng indicated earlier he would be willing to do this for the community, but that was before the fwrev info, so he might have had a false sense of security, so no pressure on him if he changed his mind)
If we find that the volunteer does not see any corruption despite trying to do so, then we can expand testing to a few more people and also work on getting CWM repacks.
If the volunteer hits the bug, then we will know the issue is still there even with stock recovery and FE07 kernel.
Keep in mind, at some point someone will need to take one for the team or we will be forever in fear of bricking our phones using ICS-based kernels.
Resources
1) FE07-based repacks
Unlocked Recovery Only [update.zip / tar]
Plus (unlocked recovery, init.d, adb-root) [update.zip / tar]
2) FE10-based repacks
Unlocked Recovery Only [update.zip / tar]
Plus (unlocked recovery, init.d, adb-root) [update.zip / tar]
3) JEDEC eMMC documentation
Related threads
Galaxy Note CID investigation thread
Good job sfhub. I am learning new stuff everyday
Sent from my SPH-D710 using xda premium
This is mine. I can try to help but not till weekend when my other phone gets here.
MAG4FA
0x0
0x0
0x000015
0x0100
11/2011
MMC
Sent from my SPH-D710 using Tapatalk 2
Sorry I don't have anything majorly different than the normal, but I have this on my phone:
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
Mine is also the same,
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
I am not available to test. Sorry.
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
Also unable to risk the brick. Good luck guys.
MAG4FA
0x0
0x0
0x000015
0x0100
10/2011
MMC
I'll take one for the team if needed. I've been eyeballing the 720p Evo.
Full readings from my /data bricked device. Let me know if you want me to check anything else out:
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
I can risk a brick to save future ones. I can help test.
/*
MAG4FA
0x0
0x000015
0x0100
12/2011
MMC*/
Sent from my SPH-D710 using Tapatalk 2
Sorry for the delay on giving more details. I've got info that I'll be passing along soon, just want to read up on something a little more before I post it out here.
Regardless whether this fix turns out to be related to the issue we've been looking at, I want to throw this in now before getting into the weeds:
Big thanks to Ken Sumrall from the Android team as he's been good enough to share info with us about this bugfix. As the person who signed off on the change commit he's one of the best resources on this issue. Also want to give credit to Mr. Min of Samsung who developed the fix in question.
I'll be posting more shortly. Those with dev experience, particularly with C++ and/or Assembly may be able to help us as well.
MAG4FA
0x0
0x0
0x000015
0x0100
11/2011
MMC
If need be, will test.
Source Notes - Part 1
Source Notes - Part 1
(Please feel free to skip if you're not interested in the programming)
This section is just to document what models and versions are affected.
I'm posting this in rather lengthy detail in part for peer review and also as I misread this the first time.
If you want to see the results of this documentation you can skip to the bottom.
Again, you'll need the link to the change:
https://bitbucket.org/franciscofranco/android-tuna-omap/changeset/cea631bdac53
If I look at this part of code alone:
Code:
cid_rev(0, 0x25, 1997, 1)
...this tells me to look for a definition of cid_rev. So I do and get here:
Code:
#define cid_rev(hwrev, fwrev, year, month) \
(((u64) hwrev) << 40 | \
((u64) fwrev) << 32 | \
((u64) year) << 16 | \
((u64) month))
It's not included in this change as this was introduced previously.
But you can see the definition here:
https://bitbucket.org/franciscofranco/android-tuna-omap/src/388ae9aa9b26/include/linux/mmc/card.h
OK, so I should look for HW revision 0x0, FW revision 0x25, right?
Nope. This was nested in another function and I didn't look at that right:
Code:
MMC_FIXUP_REV("VYL00M", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
MMC_FIXUP_REV("KYL00M", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
MMC_FIXUP_REV("MAG4FA", 0x15, CID_OEMID_ANY,
cid_rev(0, 0x25, 1997, 1), cid_rev(0, 0x25, 2012, 12),
add_quirk_mmc, MMC_QUIRK_SAMSUNG_WL_PATCH),
OK, so back to the card.h file to get my definition of MMC_FIXUP_REV:
Code:
#define MMC_FIXUP_REV(_name, _manfid, _oemid, _rev_start, _rev_end, \
_fixup, _data) \
_FIXUP_EXT(_name, _manfid, \
_oemid, _rev_start, _rev_end, \
SDIO_ANY_ID, SDIO_ANY_ID, \
_fixup, _data) \
I also want to look at _FIXUP_EXT next:
Code:
#define _FIXUP_EXT(_name, _manfid, _oemid, _rev_start, _rev_end, \
_cis_vendor, _cis_device, \
_fixup, _data) \
{ \
.name = (_name), \
.manfid = (_manfid), \
.oemid = (_oemid), \
.rev_start = (_rev_start), \
.rev_end = (_rev_end), \
.cis_vendor = (_cis_vendor), \
.cis_device = (_cis_device), \
.vendor_fixup = (_fixup), \
.data = (_data), \
}
So to properly identify what is affected:
Model Name (.name) -> VYL00M, KYL00M or MAG4FA
Manu. Firwmare ID Manufacturer ID: --> 0x15
OEM ID: Any ID (easy extrapolation of CID_OEMID_ANY)
Revision Start (Range): The result of cid_rev(0, 0x25, 1997, 1). The date indicates a low limit value.
Revision End (Range: The result of cid_rev(0, 0x25, 2012, 12). The date indicates a high limit value.
Fixup: Function to call to add the fixup - in this case, add_quirk_mmc (data.h linked above)
Data: MMC_QUIRK_SAMSUNG_WL_PATH (Not 100% but looks like a label to me. Can't find a definition in change.)
Note:
The fix mentioned right above the models affected in a note: "Date doesn't matter, so include all possible dates in min and max fields." I misread how they were getting the low and high limits of the range.
The corrected eMMCs affected involve VYL00M, KYL00M or MAG4FA at Manufacturer Firmware ID 0x15.
I would like to apologize for providing inaccurate info the first time; after going through the code another time I'm fairly certain the correction to the affected model list is accurate.
This also confirms that those who have posted are in the affected list, which we knew but couldn't confirm until now.
So does this mean the new code in the kernel is to help this problem and what would be the steps to testing it?
Sorry if dumb questions, just trying to learn.
Sent from my SPH-D710 using Tapatalk 2
So theoretically, those of us who have posted are able to make full use of the ability to flash, backup, etc. with the proper modification to our kernels? (Hope I got this right.)
Sent from my SPH-D710 using Tapatalk 2
Azrael.arach said:
So does this mean the new code in the kernel is to help this problem and what would be the steps to testing it?
Sorry if dumb questions, just trying to learn.
Click to expand...
Click to collapse
I'm of the thought that 99% of all questions are never dumb. And that 1% is extremely rare.
The thread is somewhat of peer review and discussion about what we've found and as a community possibly confirm whether this is both the bug causing the bricks (and by doing so confirming that this is the fix.)
robertm2011 said:
So theoretically, those of us who have posted are able to make full use of the ability to flash, backup, etc. with the proper modification to our kernels? (Hope I got this right.)
Click to expand...
Click to collapse
It means that the fix applies to those devices. What still isn't closed is whether the bug that this squishes is *the* bug (causing the ICS based bricks). I'm going to be posting more about that part here shortly for feedback and discussion.
Very interesting but so far over my head....
/* Missed the first paragraph of the details section. Low level corruption would do what I was questioning. Nvm
Sent from my SPH-D710 using Tapatalk 2
Discussion with Android Team
OK, now on to the bug that this fixes. This post will only contain the discussions between myself and Mr. Sumrall of the Android team.
Initial inquiry to Mr. Sumrall:
Garwynn said:
1) Was the bug that this patched causing the eMMC failures on Samsung devices using an 3.0+ kernel?
2) If #1 is yes, is it known if this correct the I/O errors already experienced? Or is this perhaps preventative in nature?
Click to expand...
Click to collapse
Initial Response:
Ken Sumrall - Android Team said:
The bug was in the emmc firmware which ran on a small microprocessor inside the emmc chip, and it didn't matter what kernel was running on the device to which it was attached. However, it may be the case that a particular kernel version was more likely to trigger the bug.
With this patch, the bug is worked around, and the emmc chip should no longer corrupt data.
Click to expand...
Click to collapse
We also knew this from the code:
Code:
* There is a bug in some Samsung emmc chips where the wear leveling
* code can insert 32 Kbytes of zeros into the storage. We can patch
* the firmware in such chips each time they are powered on to prevent
* the bug from occurring.
Note: Snipped last part of comment as it is already covered.
OK, so it's putting potentially zeros in the storage; but it doesn't give us any clues as to where the possible storage was or how this could corrupt the filesystem. So I sent some follow-up questions and got the following responses. (Regular is question to Mr. Sumrall, bold is response.
1)*Can this release fix a device where the bug has already been triggered (resulting in I/O error)?
No. *The 32 Kbytes of zeros have already been inserted into the filesystem (usually in a particularly bad place, like the inode or block bitmaps, or the inode table) and the filesystem is now corrupt.
2) What would happen if a device is rolled back to a previous kernel - one without this fix? Would it be exposed again to the bug?
Yes, the corruption could happen on older kernels. *The fix doesn't permanently fix the firmware, it patches the firmware every time the device is powered on (initial power-on, wakeup from sleep).
The next question was one that has been bugging me so I figured it wouldn't hurt to learn more about this bug. Sorry if this rubs some people the wrong way.
3) The explanation in the bugfix mentions 32 Kb of zeros being added to storage. But I can't see this causing an I/O error unless it was doing this in the storage containing the instruction set. Was this somehow corrupting the I/O instruction set contained within the firmware?*I have spent several weeks defending the opinion that this was not a hardware failure but software-based.
When the ext4 filesystem detects an error, and the filesystem is set to panic or re-mount read-only on error, the function ext4_handle_error() will record an EIO *in the journal:
Code:
static void ext4_handle_error(struct super_block *sb)
{
if (sb->s_flags & MS_RDONLY)
return;
if (!test_opt(sb, ERRORS_CONT)) {
journal_t *journal = EXT4_SB(sb)->s_journal;
EXT4_SB(sb)->s_mount_flags |= EXT4_MF_FS_ABORTED;
if (journal)
jbd2_journal_abort(journal, -EIO);
}
.
.
.
.
}
So it doesn't have to be an actual low-level IO error to cause EIO to be recorded in the journal.
As for hardware vs. software failure, it is a bug in the firmware of the emmc chip, and this kernel patch enables a work-around to prevent the problem from happening.
Click to expand...
Click to collapse
Thanks again to Mr. Sumrall for this information. More soon.
Here's what I have - hope it helps. I would help test, but not until after the weekend. Thanks for all the work and info.
MAG4FA
0x0
0x0
0x000015
0x0100
10/2011
MMC
Related
Just did a little research on the Kindle touchscreen controller ILITEK 2107QS001K (posted my results here).
Because I'm curious I Looked at the source code provided by Amazon.
Link: http://www.amazon.com/gp/help/customer/display.html?nodeId=200203720
Filename: Kindle_src_6.2_user_3003020.tar.gz
Found this file: kernel\android-2.6.35\drivers\input\touchscreen\ilitek.c
Lines 1135-1144:
Code:
// read touch resolution
[B]i2c.max_tp = 2;[/B]
if(ilitek_i2c_read_info(i2c.client, ILITEK_TP_CMD_GET_RESOLUTION, buf, res_len) < 0){
return -1;
}
[B]if(i2c.protocol_ver >= 0x200)[/B]{
// maximum touch point
[B]i2c.max_tp = buf[6];[/B]
// maximum button number
[B]i2c.max_btn = buf[7];[/B]
}
Those lines smell like they are the ones responsible for the amount of touch points enabled.
max_tp is defined in a struct near the top of the file with a comment stating "maximum touch point".
Thís file is also the only one that has different permissions than all the other files in this directory.
It would be interesting to get the debug output of the whole function ilitek_i2c_read_tp_info which is where the above lines are contained in (there are lot's of printk's in there).
Also it would be good to know what the value of i2c.protocol_ver is and if the if-clause evaluates TRUE.
Basically everything that goes on in those lines seems interesting so me.
Is there anybody out there who can tell me if I'm headed in the right direction?
EDIT
I also found this: http://wenku.baidu.com/view/77869053ad02de80d4d840ca.html - an Ilitek touch driver development manual for Android kernels. May be helpful.
Found this tool on the Android Market: ILITEK Touch Utility
Installed it on my KF and this is the main menu of the app:
Calibration - Calibrate touch screen
Upgrade - Upgrade new firmware from Hex file
Utility - Debug touch screen (submenus seen in screenshots below)
Information - Show touch screen information
Version - version 1.4.8 2011/04/11
The output of Information is this:
Code:
Firmware version: 10.2.5.0
Protocol version: 1.2
Max. X: 3968
Max. Y: 2304
Unfortunately it doesn't output something like max_tp.
I also ran Calibration and now touches seem to be registered more accurately.
emelie said:
Found this tool on the Android Market: ILITEK Touch Utility
Installed it on my KF and this is the main menu of the app:
Calibration - Calibrate touch screen
Upgrade - Upgrade new firmware from Hex file
Utility - Debug touch screen (submenus seen in screenshots below)
Information - Show touch screen information
Version - version 1.4.8 2011/04/11
The output of Information is this:
Code:
Firmware version: 10.2.5.0
Protocol version: 1.2
Max. X: 3968
Max. Y: 2304
Unfortunately it doesn't output something like max_tp.
I also ran Calibration and now touches seem to be registered more accurately.
Click to expand...
Click to collapse
This utility does "seem" to make the touchscreen more accurate. I'll have to spend time with my Fire though to be sure. Nice finds by the way!
*Btw, I think the firmware is the one responsible for setting multitouch points. The 2 is more like a default for when the version can't request the supported maximum number through the firmware.
yups have tried such stuff on X10, ARC, other deivces...
it all depends on the TS firmware...
we can improve the driver but if the firmware doesnt support it we cant do much...
also do keep in mind that Amazon got this tablet to the market at < 200$, so all the components (internally & externally) are NOT of highest caliber... cost reduction strategies...
DooMLoRD said:
yups have tried such stuff on X10, ARC, other deivces...
it all depends on the TS firmware...
we can improve the driver but if the firmware doesnt support it we cant do much...
also do keep in mind that Amazon got this tablet to the market at < 200$, so all the components (internally & externally) are of highest caliber... cost reduction strategies...
Click to expand...
Click to collapse
dont you mean are not? lol
death2all110 said:
dont you mean are not? lol
Click to expand...
Click to collapse
ya got disturbed by a p.m. so i forgot wht i was writing
I see you fixed it lol
More hints in dmesg output:
Code:
<6>[ 1.615631] ilitek_init
<6>[ 1.661468] ilitek_i2c_probe, i2c new style format
<4>[ 1.666473] ilitek_i2c_probe, IRQ: 0xC3
<6>[ 1.670593] ilitek_i2c_register_device, add i2c device, success
<6>[ 1.676818] ilitek_i2c_register_device, client.addr: 0x41
<6>[ 1.682495] ilitek_i2c_register_device, client.adapter: 0xDC839448
<6>[ 1.688995] ilitek_i2c_register_device, client.driver: 0xC06571CC
<6>[ 1.716339] ilitek_i2c_read_tp_info, firmware version 10.2.4.0
<6>[ 1.739715] ilitek_i2c_read_tp_info, protocol version: 1.2
<6>[ 1.763305] ilitek_i2c_read_tp_info, max_x: 3968, max_y: 2304, ch_x: 30, ch_y: 18
<6>[ 1.771148] ilitek_i2c_read_tp_info, max_tp: 2, max_btn: 0
<6>[ 1.777099] input: ilitek_i2c as /devices/platform/i2c_omap.2/i2c-2/2-0041/input/input1
<1>[ 1.785675] ilitek_i2c_register_device, register input device, success
<1>[ 1.792785] ilitek_i2c_register_device, request irq, success
<6>[ 1.798736] ilitek_init, register chrdev(246, 0)
Some time ago I found a module for the milestone that enables more touch points, it even let's you edit a config file where you set how many points you want. It worked (kinda) for my old d1 and my d2. I haven't tried it on my fire tho. I'll look around and see if i can find it if anyone is interested.
foxdog66 said:
Some time ago I found a module for the milestone that enables more touch points, it even let's you edit a config file where you set how many points you want. It worked (kinda) for my old d1 and my d2. I haven't tried it on my fire tho. I'll look around and see if i can find it if anyone is interested.
Click to expand...
Click to collapse
Definitely, let us know what you find out.
Sent from my Kindle Fire using xda premium
// read touch resolution
i2c.max_tp = 10;
if(ilitek_i2c_read_info(i2c.client, ILITEK_TP_CMD_GET_RESOLUTION, buf, res_len) < 0){
return -1;
}
if(i2c.protocol_ver >= 0x200){
// maximum touch point
i2c.max_tp = buf[6];
// maximum button number
i2c.max_btn = buf[7];
}
The code above would be my long life goal in fruit ninja.
has anyone gotten anywhere with this?
pyrostic said:
has anyone gotten anywhere with this?
Click to expand...
Click to collapse
i'm interested too, how can we enable more than 2 touch points?
Looking at the driver writing guide, it seems like the controller can't handle more than two points of input, or at least the guide only covers getting input from two points.
Sent from my Kindle Fire using Tapatalk
I compared the two Kernel source tars (6.2 and 6.2.1). There are various file differences, also in ilitek.c - that's the file I mentioned in the OP.
Here is a diff report of ilitek.c 6.2 and ilitek.c 6.2.1: http://jsbin.com/emuyot
That has to be the fix that amazon introduced which makes the screen a bit more responsive.
Would be interesting to know if everybody update their Kernel source to include this patch.
EDIT: Attached the diff as an image in case the jsbin disappears.
emelie said:
I compared the two Kernel source tars (6.2 and 6.2.1). There are various file differences, also in ilitek.c - that's the file I mentioned in the OP.
Here is a diff report of ilitek.c 6.2 and ilitek.c 6.2.1: http://jsbin.com/emuyot
That has to be the fix that amazon introduced which makes the screen a bit more responsive.
Would be interesting to know if everybody update their Kernel source to include this patch.
Click to expand...
Click to collapse
Thanks for the heads-up! I was planning on integrating the changes before but it got pushed to the sidelines and eventually forgotten. There are other changes in 6.2.1 which I'll integrate in my next release.
Hello fellow XDAers!
I'm looking into something and need to kindly request some data from Nexus owners for comparison. We found a potential attempt to fix this and want to check Nexus eMMC cid data to see if it matches. (We are also doing similar requests on Note and Galaxy S2 forums as they all may be involved.)
Can you please run the following from adb shell?
(Thanks to sfhub for original steps, two additions to it.)
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
0x01234567
[email protected]:/sys/class/block/mmcblk0/device # cat cid
1501004d414734464119012345671f0f
Please copy and paste the results (examples in italics) and add here when possible. I need to expand the sample set as much as possible so those who can do it have my deepest thanks! The goal is to hopefully identify if there is a bug in the correction and suggest to Android/Samsung a solution.
And to follow the discussion on the Epic 4G Touch side (Sprint Galaxy S2):
http://forum.xda-developers.com/showthread.php?t=1644364
Thanks to all in advance for your help!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Update
Based on the sampling available only one eMMC model has had the right revision in the bugfix - the KYL00M model. I'm not certain which one the Nexus contains, which is why I'm asking anyone that can post the eMMC device information here to please do so. This will allow us to propose a correction to the bugfix if necessary.
Fix in question is being released in kernel versions 4.0.4_r1.1 and above. In the case of the Nexus it may be in there sooner as it was originally introduced into their source first. If you see build IMM76I, it should be there.
Thank you again for your help!
KYL00M is the Nexus GSM model eMMC. Verizon and Sprint contain a different model.
Edit: Derpage on my part. It is VYL00M.
adrynalyne said:
KYL00M is the Nexus GSM model eMMC. Verizon and Sprint contain a different model.
Click to expand...
Click to collapse
Thanks for the update (Sorry, out of thanks for the day). I'm hoping then it will be the same case that we found for the Note - KYL00M for GSM (AT&T for example), YVL00M for others. Still would be great if we can see the cid string to make sure the results match up with what we have so far... then I'll feel comfortable with our suggestion on how to fix it.
Anything that can help avoid the notorious eMMC corruption & hard brick will go a long way IMO. Hope this lets us keep moving forward.
Wait wait wait!
That was such a derp on my part. It is VYL00M for GSM Galaxy Nexus devices.
Sorry.
http://forum.xda-developers.com/showthread.php?t=1617710
Does anyone still have the 1.0 apk?
I upgraded to 1.1 now it will not find my sprint modem and problems here and there.
Here you go..... [removed]
taqulic said:
Here you go..... http://db.tt/jnAqmyXk
Click to expand...
Click to collapse
Thank you so much, to bad I can only give you one thanks :laugh: , now everything is working again. I dont know what the dev changed on the update but something did dealing with the sprint modem..etc. and it all went down hill.
Seems like someone else had that problem too.... thought I read it in the reviews..
taulic,
please be so kind and remove the public access to the APK file.
The original package is fixed now.
Note that the program itself is free of cost but not free to copy. If people run into trouble I will provide older versions when asked.
Regards,
Author of PPP Widget
JFDee said:
taulic,
please be so kind and remove the public access to the APK file.
The original package is fixed now.
Note that the program itself is free of cost but not free to copy. If people run into trouble I will provide older versions when asked.
Regards,
Author of PPP Widget
Click to expand...
Click to collapse
Done.
PPP works once, then ned to re-installed
taqulic said:
Done.
Click to expand...
Click to collapse
Hi There,
The app works fine when I install it first, my dongle i being recognized no problem. However if I disconnect, and unplug the dongle and try to connect again, the widget shows "no modem found".
I have tried forcing the app to stop, uninstall stickmount as I thought there was clash between both apps and still it doesn't work. the only work around I v found is to re-install the app, which is not very convenient when on the go and needing internet in the first place to be able to access it.
Would you be willing to provide me the APK installer as I am quite happy to install the app whenever I need it, or maybe suggest a workaround?
you have done a fantastic job by the way
G
file is no longer available
Will you please re-upload the file (PPP wedget 1.00 APK) in drop box since the hyperlink says (The file you are looking for has been deleted or moved). Thank you very much
You should first, email the author of the app and see if he can help you with your problem.
I'm not sure I still have the app in backup... as I only save them for so long. (But I'll check).
For those people having problems with this app, there is a forum and active discussion
Here, click forum link at bottom of page.
http://www.draisberghof.de/android/pppwidget.html
Will you please email this file; thanks
Unknown Zone said:
Thank you so much, to bad I can only give you one thanks :laugh: , now everything is working again. I dont know what the dev changed on the update but something did dealing with the sprint modem..etc. and it all went down hill.
Click to expand...
Click to collapse
Dear "Unkown Zone", will you please email this file (PPP Widget 1.00); thanks
Please email link
Unknown Zone said:
Does anyone still have the 1.0 apk?
I upgraded to 1.1 now it will not find my sprint modem and problems here and there.
Click to expand...
Click to collapse
If you have older version of PPP Widget 1.00 (apk file), please post a link. I have tried many changer.bat options since your last post; both uberoid v11 and 12.1. Nothing seems to work so far to make the ZTE-MF190 work again since upgrade from stock ROM. Tried 2 look for this file however no success. Thank you.
Deleted.
samsung note i717 no drivers found
PPP Widget version 1.3.3
USB_ModeSwitch log from Tue Sep 24 21:36:19 IST 2013
Raw args from udev: 1-1/1-1:1.0
Using top device dir /sys/bus/usb/devices/1-1
----------------
USB values from sysfs:
manufacturer ZTE, Incorporated
product USB Storage
serial 000000000002
----------------
bNumConfigurations is 1 - don't check for active configuration
SCSI attributes not needed, moving on
checking config: /data/data/de.draisberghof.pppwidget/app_tmp/19d2.fff5
! matched. Reading config data
devList 1:
config: TargetVendor set to 19d2
config: TargetProductList set to fff1,fffe,ffff
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
Command to be run:
usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 2 -v 19d2 -p fff5 -f $cB
Verbose debug output of usb_modeswitch and libusb follows
(Note that some USB errors are to be expected in the process)
--------------------------------
Reading long config from command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.7 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x19d2
DefaultProduct= 0xfff5
TargetVendor= 0x19d2
TargetProduct= not set
TargetClass= not set
TargetProductList="fff1,fffe,ffff"
DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
QuantaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
BlackberryMode=0
PantechMode=0
MessageEndpoint= not set
MessageContent="5553424312345678c00000008000069f030000000000000000000000000000"
NeedResponse=0
ResponseEndpoint= not set
InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled
Use given bus/device number: 001/002 ...
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 19d2:fff5
found matching vendor ID
found matching product ID
adding device
Found device in default mode, class or configuration (1)
Skipping the check for the current configuration
Using interface number 0
Using endpoints 0x0a (out) and 0x89 (in)
USB description data (for identification)
-------------------------
Manufacturer: ZTE, Incorporated
Product: USB Storage
Serial No.: 000000000002
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x0a for message sending ...
Trying to send message 1 to endpoint 0x0a ...
Sending the message returned error -6. Trying to continue
Resetting response endpoint 0x89
Could not reset endpoint (probably harmless): -6
Resetting message endpoint 0x0a
Could not reset endpoint (probably harmless): -6
Device is gone, skipping any further commands
Bus/dev search active, referring success check to wrapper. Bye.
ok:busdev
--------------------------------
(end of usb_modeswitch output)
Checking success of mode switch for max. 20 seconds ...
Waiting for device file system (1 sec.) ...
Reading attributes ...
Mode switch has completed
Mode switching was successful, found 19d2:fff1 (ZTE, Incorporated: ZTE CDMA Tech)
Device class of first interface is ff
Now checking for bound driver ...
No driver has bound to interface 0 yet
Module loader is /system/bin/insmod
Trying to find and install main driver module "option"
Checking for active driver path: /sys/bus/usb-serial/drivers/option1
Driver not active, try to find module "option"
Can't find module "option"
Existing path found:
No way to use driver "option"
- try falling back to "usbserial"
Module "usb_serial" not found, can't do more here
Driver binding did not work for this device
All done, exiting
QUOTE=taqulic;34223799]Here.
http://www.filesend.net/download.php?f=4c6891af31cb635623fac53e094def52[/QUOTE]
Sir,
Using samsung note i717with official jb rom 4.1.2, ppp app says driver not found, device log is as above. Request you to help in this regard.
Q&A for Smartwatch 2 firmware hacking
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for Smartwatch 2 firmware hacking. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
Hello everyone!
SW2 went into a state of brick.
issue:
The night was updated and hiking battery case has turned off, because the next morning found that the watch off when he saw the inscription included Sony, and the firmware version in the left corner.
Launched dfu-util flashed section of the Internal * .dfu
After that, the clock does not start, just a black screen.
After trying different dumps, bins from a sw2, extracted from custom * .apk files bl.bin and asw.bin
To update the internal address - 0x08000000 for eMMC - 0x00000000.
Everything goes well and without errors, shows a black screen continuously in DFU mode
The question is, do they really bring their condition brick, if you still so, how ???
Help who than can ... dumps, bins, address firmware =)
The conclusion of the process of the firmware:
C:\MinGW\bin>dfu-util -c 1 -i 0 -a 0 -D 1.dfu
dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]
Opening DFU capable USB device... ID 0fce:f0fa
Run-time device DFU version 011a
Found DFU: [0fce:f0fa] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash /
0x08000000/03*016Kg,01*016Kg,01*064Kg,07*128Kg,03*016Kg,01*016Kg,01*064Kg,07*128
Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuUPLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
Dfu suffix version 11a
DfuSe interface name: "Internal Flash "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (5 elements, total size = 858340)
parsing element 1, address = 0x0800c000, size = 24320
............
parsing element 2, address = 0x08020000, size = 111992
.......................................................
parsing element 3, address = 0x0803fffc, size = 392
.
parsing element 4, address = 0x08040200, size = 721592
................................................................................
................................................................................
................................................................................
................................................................................
.................................
parsing element 5, address = 0x080ffffc, size = 4
.
done parsing DfuSe file
*sorry for my English
Brick?
ok guys, i buy yesterday sw2 and i try update today by my xperia Z2. after this watch has stuck on update screen. i try reflash few times by dfu util but still nothing. someone on this forum attach the file original.dfu but dfu utili cant flash and give me error Only Dfsus file version 1.1a is supported. so at this moment ive got black screen but still computer see dfu usb when i plug watch to computer. can someone help me to reflash to stock or custom doesnt matter but i need to live this watch. im spend 60 Pound for this watch and now dead... Sorry for my bad english I am polish
Hello
I have a SIM unlocked Samsung Galaxy Note 3 Neo SM-N7505 here in Germany. I use Ubuntu OS and have installed Heimdall to do the root but unsure of how to repackage the data in the firmware .zip I got here
http://www.sammobile.com/firmwares/database/SM-N7505/DBT/
I extracted this but it seems that N7505XXUCNG5_N7505DBTCNG1_N7505XXUCNG2_HOME.tar.md5 is a Odin type of update.
Can someone point me to where I can find the Firmware below that I can use with Heimdall or help me convert the one I have?
UPDATE:
Read my reply below or above this one.
Firmware for GALAXY Note 3 Neo LTE SM-N7505
Model SM-N7505
Model name GALAXY Note 3 Neo LTE
Country Germany
Version Android 4.4.2
Product code DBT
PDA N7505XXUCNG5
CSC N7505DBTCNG1
Still await a helpful persons support...
I was able to Odin flash it , but I still am wanting a linux/unix way to admin my firmware or ROMs. Any help would be awsome.
Note 3 neo forum is here: https://forum.xda-developers.com/note-3-neo
Did you try flashing cfautoroot with Heimdall?
https://autoroot.chainfire.eu
Re: Still await a helpful persons support...
audit13 said:
Note 3 neo forum is here: https://forum.xda-developers.com/note-3-neo
Did you try flashing cfautoroot with Heimdall?
https://autoroot.chainfire.eu
Click to expand...
Click to collapse
I am not fully able to. Most of them will not work. I download it. I am able to hook up my phone all good ready to go. Can copy and make a PITT file of my phones drive layout. All systems go. As soon as I load the new ROM or Firmware to root the phone. I get a error that either the file is not compatable with Heimdall or I get this file is missing the Android Meta xml Heimdall needs for setting up the permissions and configurations.
It really gets me since I am pretty technical and write code i am at a loss why this file is always missing. Why fail to put a file in that is that important? Then you read on that and find 10,000 ways to write one. Alas not one are specific and if they are so easy to whip up one yourself why dont any of the 10,000 simply write one and spend their time teaching how to write hard scripts and code. Also not B*ching just really tired of the same old various types of info sprinkled with vauge and unclear steps or actual files to use as guides.
When I write a tutorial or a walkthrough its very clear. When I read most of the rooting or dealing with Heimdall and phones its like trying to locate that ring Frodo sought-after for so long.
I really appreciated that you responded. If you can maybe help me it would be great if I located a way to root my phone without a computer at all. I really think since everyone pretty much can root or unlock the damn things the phone would just have a option with a popup that you agree voids the warranty and poof its rooted...
lol
Thanks for taking time to message me!
:good:
Scott
Unfortunately, I do not use Linux so I am not sure what else to suggest other than possibly loading a temporary Windows installation onto your computer to flash cfautoroot via Odin.
Hi ScottsDesk
In the end, did you reach to root your phone from Ubuntu ? This is exactly what I want to do : when I've understood which will be the first way I'll choose to use a free'd phone, I want to walk this path with Linux. I can't understand why all the guys here being fans of free devices can even think to use Windows to gain control over their android : it is a shame (I must admit I'm a 0-skilled dev, so I can even allow myself to find strange there is so much Java therein Android ).
But ATM, I don't even know if I'll use CF-auto-root or if there exists a custom ROM that is running bug-free our device after days and days parsing this forum. The sad thing is I don't feel skilled enough to dig in the most serious solution (ChainFire's abandonned Unofficial CM12.1 for SN-M7505) to see if NFC is still really KO (ATM I have to remember some reported bugs have easy workarounds : lockscreen lag : disable Aquarell &/| wavelets effect and lowen swappiness from 130 to something around 50 (I'd try even far less, like on SSDs), and a delay in video recording sound : disable the "Google OK" thing).
I hope you'll read this
PS : it seem heimdall has what what we need (--no-reboot argument to follow what the guys say at some point to not reboot, instead remove battery).
I just gave try, just to see, but it fails and don't know what yet :
Code:
sudo heimdall print-pit --verbose
[sudo] password for me:
Heimdall v1.4.0
Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
length: 18
device class: 2
S/N: 0
VID:PID: 04E8:685D
bcdDevice: 021B
iMan:iProd:iSer: 1:2:0
nb confs: 1
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 83
max packet size: 0010
polling interval: 09
interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 0A.00.00
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 02
max packet size: 0200
polling interval: 00
Claiming interface...
Setting up interface...
libusbx: error [op_set_interface] setintf failed error -1 errno 71
ERROR: Setting up interface failed!
Releasing device interface...
Also, did you understand this strange advice ? : some advise to make a backup (boot.img above all) before we do anything else : but I booted the phone in recovery mode and I can't see nandroid backup option...