Related
I'm trying to understand exactly how the various keylayout files work... http://source.android.com/tech/input/key-layout-files.html
But I can't understand some things:
1- Why, ie in andromadus, the softouch keys aren't flagged as virtual? this should prevent users from touching them while wanting to touch the screen.
2- How can I see which keylayout file I'm using? I've seen that this should work:
Code:
logcat -d | grep vision
but when I run it it doesn't do anything
Someone had this as output:
Code:
I/EventHub( 6163): New device: id=2, fd=110, path='/dev/input/event5', name='curcial-oj', classes=0x9, configuration='/system/usr/idc/curcial-oj.idc', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false
D/EventHub( 6163): No input device configuration file found for device 'lightsensor-level'.
D/EventHub( 6163): No input device configuration file found for device 'vision-keypad-sea'.
I/EventHub( 6163): New device: id=4, fd=117, path='/dev/input/event3', name='vision-keypad-sea', classes=0xc3, configuration='', keyLayout='/system/usr/keylayout/vision-keypad-sea.kl', keyCharacterMap='/system/usr/keychars/vision-keypad-sea.kcm', builtinKeyboard=true
D/EventHub( 6163): No input device configuration file found for device 'proximity'.
I can't understand why it uses generic at first and then passes to sea... And may it be enough for me to grep for I/EventHub to get these strings on mine?
3- Which is the order in which they are used? I mean if there's no x.kl y is used, if there's no y.kl, z is used. This because reading in the following link:
/system/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
/system/usr/keylayout/Vendor_XXXX_Product_XXXX.kl
/system/usr/keylayout/DEVICE_NAME.kl
/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
/data/system/devices/keylayout/Vendor_XXXX_Product_XXXX.kl
/data/system/devices/keylayout/DEVICE_NAME.kl
/system/usr/keylayout/Generic.kl
/data/system/devices/keylayout/Generic.kl
Click to expand...
Click to collapse
this should be the order, but I've never heard of anyone changing the first file, of many changing vision_keypad_lang.kl which isn't even mentioned there....
4- If I set a virtual key as a WAKE key will this make the whole file unreadable? so will the desire z pass over it and look for another file? If this is right, as I think and hop, I may have understand which is my problem... I've seen that this is done in andromadus, but I still can't understand how they can wake phone...
5- Which is effectively the difference between WAKE and WAKE_DROPPED, can't get a clear idea from the link
6- What is the purpose of the validatekeymaps tool? Does it verify if the sintax of the file is right?
Thank you
edit: you may have noticed that many of the things I ask can easily be verified with a phone in hands, but I don't have mine at the moment, so I can't do it and it will be like this for a week or so. I have time to develop my project now, so I ask anyway
Noone has worked on these files??
virtualflyer said:
Noone has worked on these files??
Click to expand...
Click to collapse
All your questions can be answered in the official google android documentation. Have a read
Sent from my HTC Vision using xda premium
blk_jack said:
All your questions can be answered in the official google android documentation. Have a read
Sent from my HTC Vision using xda premium
Click to expand...
Click to collapse
I assume you refer to the link I've posted... I've read it, but I still can't understand all points but 5-6 as said in the OP.
There's a VIRTUAL flag and documentation proposes it, so why don't we use it?
Why's everybody changing vision_keypad_lang instead of the one said in doc?
I can't find all these answers (1-4) in documentation... I may haven't seen it, but I read it pretty carefully...
virtualflyer said:
I'm trying to understand exactly how the various keylayout files work... http://source.android.com/tech/input/key-layout-files.html
But I can't understand some things:
1- Why, ie in andromadus, the softouch keys aren't flagged as virtual? this should prevent users from touching them while wanting to touch the screen.
2- How can I see which keylayout file I'm using? I've seen that this should work:
Code:
logcat -d | grep vision
but when I run it it doesn't do anything
Someone had this as output:
Code:
I/EventHub( 6163): New device: id=2, fd=110, path='/dev/input/event5', name='curcial-oj', classes=0x9, configuration='/system/usr/idc/curcial-oj.idc', keyLayout='/system/usr/keylayout/Generic.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false
D/EventHub( 6163): No input device configuration file found for device 'lightsensor-level'.
D/EventHub( 6163): No input device configuration file found for device 'vision-keypad-sea'.
I/EventHub( 6163): New device: id=4, fd=117, path='/dev/input/event3', name='vision-keypad-sea', classes=0xc3, configuration='', keyLayout='/system/usr/keylayout/vision-keypad-sea.kl', keyCharacterMap='/system/usr/keychars/vision-keypad-sea.kcm', builtinKeyboard=true
D/EventHub( 6163): No input device configuration file found for device 'proximity'.
I can't understand why it uses generic at first and then passes to sea... And may it be enough for me to grep for I/EventHub to get these strings on mine?
3- Which is the order in which they are used? I mean if there's no x.kl y is used, if there's no y.kl, z is used. This because reading in the following link:
this should be the order, but I've never heard of anyone changing the first file, of many changing vision_keypad_lang.kl which isn't even mentioned there....
4- If I set a virtual key as a WAKE key will this make the whole file unreadable? so will the desire z pass over it and look for another file? If this is right, as I think and hop, I may have understand which is my problem... I've seen that this is done in andromadus, but I still can't understand how they can wake phone...
5- Which is effectively the difference between WAKE and WAKE_DROPPED, can't get a clear idea from the link
6- What is the purpose of the validatekeymaps tool? Does it verify if the sintax of the file is right?
Thank you
edit: you may have noticed that many of the things I ask can easily be verified with a phone in hands, but I don't have mine at the moment, so I can't do it and it will be like this for a week or so. I have time to develop my project now, so I ask anyway
Click to expand...
Click to collapse
2. after a reboot filter the logcat output for "device".
D/EventHub( 6163): No input device configuration file found for device 'lightsensor-level'.
Click to expand...
Click to collapse
create the file "lightsensor-level.idc" inside /system/usr/idc
same for vision-keypad-sea.
for key layouts its the same as for idc, just insert/create the *.kl files into /system/usr/kl if they are missing
curcial-oj uses generic layout because there is no specific layout. just create "curcial-oj.kl" inside /system/usr/kl
4. I guess it's useless to set wake-flag for virtual keys
5. If I understand it correctly keys with WAKE-flag will wake up the phone and execute their function while WAKE_DROPPED will only wake up the phone and drop its function in case that phone's sleeping.
6. at least yes
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
hi all-
Can anyone tell me if there is a hardware difference in the radios of NA/EUR models of the LG G3 such as the D855/852/850? Is it possible to change radio band support by flashing a different radio or other mods? I recall that this was possible with the Nexus4, to enable LTE support when the stock phone had it disabled. Could you flash a different radio baseband package to enable AWS on a D850/852, or additional LTE bands on a D855? I have a Bell D852 that I'd like to be able to use effectively on Wind, or T-Mobile in the US but obviously it doesn't support all of their frequency bands.
[update 11-18-2014] I've changed the title to reflect that editing G3 radio bands appears to be possible, user JustLiveIt has done so with a D855, but we do not have full details yet. Much more testing with different models besides the D855 is required!
Hi,
I am interested to know the answer to this for the reason you just gave, as well as myself having issues with low signal area performance.
If you find out the answer, please share it.
Cheers,
Maybe a better or more precise question would be; do the G3 models have a baseband radio package that is flashable separate from the existing ROMs? Can someone familiar with the previous LGOG->N4 conversions and the process to turn on the N4 LTE radio define what is necessary in this phone?
Simply put: this sort of thing clearly has been possible before with older LG models like making the Optimus G (E970/973) compatible with Nexus4 ROMs due to having common components. And logistically/economically it's in a manufacturers interest to keep the highest commonality of components for economies of scale in manufacturing. So logically- the various G3 models should use as few different hardware parts as possible, and differences should be defined in software as much as possible.
Has anyone tried this Qualcomm SoC dev mode hack on the D850 or D852? JustLiveIt has done testing on a D855 only so far. This thread seems to indicate that any and all GSM bands could be enabled on any current Qualcomm SoC.
Any D850, D852. D851, F460, etc users who feel lucky.. please give this radio edit a try and let us know!
Does anyone have the specific instruction set for LG phones or the G3 in particular? I have tried sending PMs to the LG users in the Qualcomm unlock thread but still no reply.
D852 sitting idle, awaiting some LG-specific instructions. I'm willing to do some testing and provide feedback, I just need a guide on testing with the G3, everyone else in the Qualcomm thread is either Sony or HTC users it seems. And neither of the users working with LG phones in that thread have responded in a week..
I got a reply back from JustLiveIt on Wednesday, unfortunately he has been offline while moving from the US overseas, so he will try to provide his radio details to-date on the D855 as soon as he is able. :good:
It's easy on LG phone...I have tested on G2 CloudyG3 (I just bought new G2 so far )
1.Install LG United driver
2.Require root
3.Turn on USB Debugging and switch to MTP mode
4. Connect the phone to PC and open terminal
5. Type this
adb shell
su
echo 1> / sys / devices / platform / lg_diag_cmd / diag_enable
setprop sys.usb.config acm, diag, mtp, adb
Click to expand...
Click to collapse
6. After that check your Device manager, this will show up "Ports (LGE AndroidNet USB Serial Port (ComXX))" ComXX is any number
7. Now you can do anything, play with it....
BlackSoulxxx said:
It's easy on LG phone...I have tested on G2 CloudyG3 (I just bought new G2 so far )
1.Install LG United driver
2.Require root
3.Turn on USB Debugging and switch to MTP mode
4. Connect the phone to PC and open terminal
5. Type this
6. After that check your Device manager, this will show up "Ports (LGE AndroidNet USB Serial Port (ComXX))" ComXX is any number
7. Now you can do anything, play with it....
Click to expand...
Click to collapse
I tried that in my G3 and it does not work
adb shell
su
echo 1 > /sys/devices/platform/lg_diag_cmd/diag_enable
setprop sys.usb.config acm,diag,mtp,adb
And i get
tmp-mksh: Can´t create /sys/devices/platform/lg_diag_cmd/diag_enable: No such file or directory
---------- Post added at 05:41 AM ---------- Previous post was at 05:34 AM ----------
Moose21 said:
I got a reply back from JustLiveIt on Wednesday, unfortunately he has been offline while moving from the US overseas, so he will try to provide his radio details to-date on the D855 as soon as he is able. :good:
Click to expand...
Click to collapse
I am interested in enabling aws or umts IV 1700Mhz in my G3, in threadAdd all GSM and LTE bands to your phone JustLiveIt said he was able to do so, he might give us more directions about it
charlierocker said:
I tried that in my G3 and it does not work
adb shell
su
echo 1 > /sys/devices/platform/lg_diag_cmd/diag_enable
setprop sys.usb.config acm,diag,mtp,adb
And i get
tmp-mksh: Can´t create /sys/devices/platform/lg_diag_cmd/diag_enable: No such file or directory
---------- Post added at 05:41 AM ---------- Previous post was at 05:34 AM ----------
I am interested in enabling aws or umts IV 1700Mhz in my G3, in threadAdd all GSM and LTE bands to your phone JustLiveIt said he was able to do so, he might give us more directions about it
Click to expand...
Click to collapse
Can you check that in your rom there is /sys/devices/platform/lg_diag_cmd folder? Use any file manager apps to do this...
Also if you running custom ROM, maybe the ROM author remove it. Try to flash stock ROM and try again.....
BlackSoulxxx said:
Can you check that in your rom there is /sys/devices/platform/lg_diag_cmd folder?
Click to expand...
Click to collapse
Definitely not found in CM12 20141124 build for D852.
BlackSoulxxx said:
Can you check that in your rom there is /sys/devices/platform/lg_diag_cmd folder? Use any file manager apps to do this...
Also if you running custom ROM, maybe the ROM author remove it. Try to flash stock ROM and try again.....
Click to expand...
Click to collapse
I looked for that folder and it doesn't exist i got a custom room cloudy G3 1.2
BlackSoulxxx said:
Can you check that in your rom there is /sys/devices/platform/lg_diag_cmd folder? Use any file manager apps to do this...
Also if you running custom ROM, maybe the ROM author remove it. Try to flash stock ROM and try again.....
Click to expand...
Click to collapse
I checked and there is no such folder i was using a custom rom cloudy2.1, then I restored back to the original stock ROM and there is no such folder either
Regards
That's weird...No comment...
So what can we do to re-add or load the necessary files on a Lollipop ROM? OR do we need to flash back to a stock Kitkat build? Does anyone who actually knows anything ever read these threads??
---
I've only been looking and asking for help and information for FOUR MONTHS in the G3 forums and the Qualcomm chipset thread and noone has provided any tangible information for the G3 phones, ever. I said right from the start I was willing to use my D852 to test and provide feedback, noone could even be bothered to reply. I asked people who claimed they'd had success with other G3 models, they provided nothing. This is why people hate on XDA- because it's full of useless posers who can't do anything except rehash files written or edited by others and take their credit. LOL ROMz!1one!!wan But ask for something original and useful to edit the hardware? Complete silence. Guess I may as well just sell my 852 and go buy an 851 on eBay, at least it will have what I wanted out of the box, for only $500.
Enabling LTE bands on LG VS985
Moose21 said:
Hi Enigmafied-
can you follow up here, or preferably here with the details on how you have edited the G3 radio bands? I have been looking for a set of instructions for testing this with a D852 for months with no reply from anyone..
I wanted to test access to the AWS bands for HSPA and LTE with Wind and T-Mobile on a Bell-sourced D852.
Click to expand...
Click to collapse
I am quoting Moose21 from here: http://forum.xda-developers.com/showpost.php?p=58183824&postcount=918
I will respond the same in both threads as it may be benificial to readers in each thread. To enable the Verizon LG G3 VS985 bands was simple, I followed the instructions from this thread: http://forum.xda-developers.com/verizon-lg-g3/general/unlocked-lte-bands-vs985-t2909150
kroukes2000 said:
I unlocked some others LTE bands on VS985, I tried other tips from Sony Xperia forum with no success and now just with hiddenmenu it work, for that:
1. Download Shortcut Master (lite) from play store
2. Top right -> App Explorer ->Verizon Hidden Menu
3. go to -> LTEBandSelection tap and select Launch
4. Now choose all Bands and Save and reboot
Need ROOT
That's all
Click to expand...
Click to collapse
Not sure if you will have a hidden menu that is similar! Hope it helps!
Enigmafied said:
I am quoting Moose21 from here: http://forum.xda-developers.com/showpost.php?p=58183824&postcount=918
I will respond the same in both threads as it may be benificial to readers in each thread. To enable the Verizon LG G3 VS985 bands was simple, I followed the instructions from this thread: http://forum.xda-developers.com/verizon-lg-g3/general/unlocked-lte-bands-vs985-t2909150
Not sure if you will have a hidden menu that is similar! Hope it helps!
Click to expand...
Click to collapse
Sorry, this is actually just the LG service menu accessible on any stock ROM LG phone with the standard 3845# code.. It is not really unlocking or enabling anything that wasn't already available from your provider. In fact this is pretty clearly an LG service code testing hook as this works on the stock ROM, but does not work at all on a Lollipop ROM such as Candy5. 3845# doesn't work there either.
Has anyone gotten this to work?
I have a d851 on t-mobile in the us and want to try to enable band 12 for lte
Glad that this treat is revoked again and sorry that there still is no usefully info about some interesting questions, specifically about hardware ( also regardless to ^^^post#15), would like to provide some personal update and experience past couple mounts with mine d851 model that i don't want to give up, since where i am, accordingly to lte i need bands 3 and 20, which d851 officially doesn't have them.
I did try every info that was find on net, was do a every idea that i can thing of (lacky me phone survive after couple serious crashes ), what from i know fore sure in editing android or it was hit and miss, try and error, restrictions of free (read demo) softwares, pagans magic and voodoo zens, etc etc... all i can say that i didn't succeed in enabling 3 and 20 bands and still looking for answers.
Also have a question: is it possible to change some hardware part (radio, modem, soc, whatever) and from d851 to transform in d855/d850/bands 3,20, and supporting it with appropriate software (kernel, baseband, whatever)?
I got it working.
working with qxdm not in a band 12 area dont know if it worked but settings sticking from boot.
You need to set the selinux to permissive then run from a su adb prompt
echo 1 > /sys/devices/platform/lg_diag_cmd/diag_enable
setprop sys.usb.config acm,diag,mtp,adb
I followed this http://forum.xda-developers.com/galaxy-s5/general/how-to-add-rf-lte-frequency-bands-to-t2886059 but the only addition was using this to change selinux to permissive http://forum.xda-developers.com/showthread.php?t=2524485
I have a d851 using a stock rom based on the newest 5.0 for my device 20G Rom is rooted
I've been working on a custom ROM for the Lumia 1520.3 RM-938 32gb.
The variant info for the model I'm working with is below.
I wanted to know if there were any users out there US or non-US that would be wanting or willing to test a 1520.3 ROM with me.
-You need to be able to understand and be capable of using Windows Phone Internals to unlock your phone
-Your device must be a 32GB model with Samsung eMMC
-This ROM is for the 1520.3 (RM-938) only, and was not tested for the 1520 (RM-939) or 1520.1 (RM-937). However, I own a 32GB RM-940 (1520.2) and this ROM does successfully flash to that device and work.
-Like any altering of any device outside of stock or OEM specifications, there is a chance for something to go wrong. Even though most errors or issues can be reversed or fixed you could potentially render your device useless or damage it in other ways. You would be willing to do this at your own risk.
-It would be best/ideal to do this with a spare device and not your main daily phone
I currently use T-mobile US so one of the customizations I did was to alter the NVI settings and provisioning files to use t-mobile US HD voice and LTE bands. I also removed some of the apps, and made a couple of other changes just for testing. I'm limited in what I can verify works for cellular tweaks and changes since I only use T-Mobile US.
If anyone is interested, let me know here and I'll post up a link to the image files. If not no worries. I'll link what I come up with either way at some point.
Model info: Lumia 1520.3 RM-938 Product code: 059V6X0 with 29.1GB Samsung eMMC
ROM info: Version 1703 Build 10.0.15063.1446
UPDATE:
I've moved to another area of focus and so for now I ended troubleshooting and building this particular ROM further. However what I ended up with I have posted a link for as I said I would. The only real changes from what the original ROM was is I added my own NVI files under \Programs\CommonFiles\OEM\Public\Nokia\MultiVariant\MCC-310\ and replaced the default variant NVI files with the same. I replaced the ADC files under \Programs\CommonFiles\ADC with that of the T-Mobile 640 LTE variant. I also removed some xap files that I personally found annoying or had no use for. That is about it.
Flash this at your own risk of course LINK
Testing Lumia 1520.3 ROM
Hi, Sir !
I am ready to participate in new OS testing. I have Lumia 1520 RM-937, in Europe
RomanMel said:
Hi, Sir !
I am ready to participate in new OS testing. I have Lumia 1520 RM-937, in Europe
Click to expand...
Click to collapse
I added some bullets in RED. Please review them in the first post and let me know if you understand or if you have any questions.
Nate0, how you unbricked the phone?
augustinionut said:
Nate0, how you unbricked the phone?
Click to expand...
Click to collapse
My RM-939 is still bricked. I'm almost positive the uuid of the critical partitions are mismatched and maybe more...but going forward I did not work with that particular variant anymore since its modem nvi hard parameters (China Unicom) limited me for what I was originally trying to do anyway.
https://forum.xda-developers.com/wi...mer-unbrick-jtag-t3082592/page52#post68692677
https://forum.xda-developers.com/wi...ia-1320-hard-bricked-wpinternals-2-3-t3734020
https://forum.xda-developers.com/windows-10-mobile/lumia-emergency-files-including-models-t3748037
https://forum.xda-developers.com/windows-10-mobile/testing-debrand-lumia-1520-att-rm-940-t3656783
nate0 said:
UPDATE:
I've moved to another area of focus and so for now I ended troubleshooting and building this particular ROM further. However what I ended up with I have posted a link for as I said I would. The only real changes from what the original ROM was is I added my own NVI files under \Programs\CommonFiles\OEM\Public\Nokia\MultiVariant\MCC-310\ and replaced the default variant NVI files with the same. I replaced the ADC files under \Programs\CommonFiles\ADC with that of the T-Mobile 640 LTE variant. I also removed some xap files that I personally found annoying or had no use for. That is about it.
Flash this at your own risk of course LINK
Click to expand...
Click to collapse
What edits did you make here? Could I not access the files in Mass Storage mode on my phone to update the files and fix the issue. Even I am on T-Mobile US and want to be able to use the LTE bands they support + enable HD Voice which the phone and both T-Mobile technically support.
maverickrohan said:
What edits did you make here? Could I not access the files in Mass Storage mode on my phone to update the files and fix the issue. Even I am on T-Mobile US and want to be able to use the LTE bands they support + enable HD Voice which the phone and both T-Mobile technically support.
Click to expand...
Click to collapse
I added and changed enough nvi settings to get the LTE bands I wanted and HD voice to work. If you want to know which lines were changed just compare the updated nvi file to the RM-938 original nvi file for MCC-310.
The link is no longer valid.
cataclysms said:
The link is no longer valid.
Click to expand...
Click to collapse
Thanks for noticing. I was not aware of anyone still using it...went back the other day and did some clean up of all my shared access. Message me and I can share it for you.
nate0 said:
Thanks for noticing. I was not aware of anyone still using it...went back the other day and did some clean up of all my shared access. Message me and I can share it for you.
Click to expand...
Click to collapse
The message icon is grayed out. I think it is because I am a new member. It won't let me message you.
cataclysms said:
The message icon is grayed out. I think it is because I am a new member. It won't let me message you.
Click to expand...
Click to collapse
What model 1520 do you have?... I miss that phone in some ways.
Hi!
I've been lurking this forum for a while and am really eager to change my Galaxy Watch Active 2 CSC from Hungary to UK to make Samsung Pay work. I have a Curve card specially for this but I've been too afraid to do it because I'm afraid I will lose the 4G functionality of my Hungarian Telekom provider.
Right now my watch is set up with Telekom and has 4G set up as esim.
My big question is if I change my CSC to UK, will I lose the 4G functionality? Will I still be able to connect to my Hungarian esim account?
Please let me know, any information is greatly appreciated!!
TheKaasX said:
Hey man! I did it and Samsung Pay works thanks!!
Click to expand...
Click to collapse
I did it, Samsung Pay worked, but it doesn't connect to the Telekom network. Then I also made the mistake of wanting to re-register the eSIM, but it no longer allows me to try any available ROM. Now I should get the factory Telekom ROM, but I have no idea where it comes from. It sucks. Very big sucks.
Theory.
ESIM is activated and work. :good:
IMHO eSIM profile will not be erased.
So IMHO eSIM is lowest problem.
But SPay chance 50 / 50...
Maybe your plan will NOT work for Samsung Pay...
Best Regards
Hi Adfree,
First of all I want to thank you for your reply and all the work you are doing for this community. You are by far THE Galaxy watch expert. You're always commenting constructive feedback to people.
Everywhere I see your comments and helping out people. A big THANK YOU!
I will try to change the CSC, even though I'm a big newbie to this.
One last question: will I be able to revert the watch to its original state if it turns out it doesn't work? With that I mean original firmware that it came with?
One last question: will I be able to revert the watch to its original state if it turns out it doesn't work? With that I mean original firmware that it came with?
Click to expand...
Click to collapse
To increase your chance to get Original Status... my suggestion:
A
Check Firmware infos on your device to be 99,9 % sure what you need...
Type like you would call someone:
Code:
*#1234#
Then you see all relevant infos to find your Firmware...
B
For Orignal Settings... my suggestion with SDB Tool from here:
https://forum.xda-developers.com/showpost.php?p=74585286&postcount=330
B.1
Check Bootloader Version sboot.bin
Code:
cat /proc/cmdline
B.2
Check active CSC
Code:
cat /csa/csc/csc-active-customer.inf
B.3
Check Product Code
Code:
cat /csa/imei/prodcode.dat
You can save these infos with Screenshot or by Copy and Paste Text only... with right Mouse Button.
Best Regards
adfree said:
To increase your chance to get Original Status... my suggestion:
A
Check Firmware infos on your device to be 99,9 % sure what you need...
Type like you would call someone:
Code:
*#1234#
Then you see all relevant infos to find your Firmware...
B
For Orignal Settings... my suggestion with SDB Tool from here:
https://forum.xda-developers.com/showpost.php?p=74585286&postcount=330
B.1
Check Bootloader Version sboot.bin
Code:
cat /proc/cmdline
B.2
Check active CSC
Code:
cat /csa/csc/csc-active-customer.inf
B.3
Check Product Code
Code:
cat /csa/imei/prodcode.dat
You can save these infos with Screenshot or by Copy and Paste Text only... with right Mouse Button.
Best Regards
Click to expand...
Click to collapse
Hey man! I did it and Samsung Pay works thanks!!
TheKaasX said:
Hey man! I did it and Samsung Pay works thanks!!
Click to expand...
Click to collapse
Hello, did you lost your 4g connection? thank you