Database Users

4.0.3 LPY Bug Discussion (STOP POSTING eMMC CID data)

they say (in the PSA message of entropy) that the OTA update of ICS is affected with the "superbrick" bug that bricked a lot of users... and the idea scares me...
garwynn said:
Hello fellow XDAers!
I'm looking into something and need to kindly request some data from Note owners for comparison. We found a potential attempt to fix this and want to check Note eMMC cid data to see if it matches.
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
Click to expand...
Click to collapse
Please copy and paste the results (examples in italics) and either PM or add here when possible. I need to expand the sample set as much as possible so those who can do it it is much appreciated!
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
Please post your eMMC CID data to help mr. garwynn in his investigations.
As of now, the bug or effects of the bug is hard to pinpoint. and with your help, it could be solved.. thanks for cooperating.
NOTE: you can use Terminal Emulator and input the codes in bold above. then copy paste it here. thanks
To MODS: i edited the thread since a few users have posted their eMMC CID here and avoid split threads with the same posts. thank you.
Note: stop posting eMmc data. Mr. Garwynn got enough stuff already. Just post if you have different cid other than 0x19 (check his thread how to determine)
Latest Update from Android Team:
garwynn said:
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Originally Posted by Ken Sumrall
The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.
(On second inquiry)
fwrev is zero until the patch is applied.
Click to expand...
Click to collapse
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Originally Posted by Ken Sumrall
You probably have the bug, but rev 0x19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0x25. Yes, it is very annoying that 0x19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.
However, even though 0x19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can't use this patch on devices with firmware revision 0x19. This patch does a very specific hack to two bytes of code in the revision 0x25 firmware, and the patch most likely will not work on 0x19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.
I passed on our results a few days later mentioning that the file system didn't corrupt until the wipe. This is a response to that follow-up.
As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Why the /data partition?
Originally Posted by Ken Sumrall (Android SE)
Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Click to expand...
Click to collapse
Question: Why JTAG won't work?
Originally Posted by Ken Sumrall
As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Can a corrupted file system be repaired (on the eMMC)?
Originally Posted by Ken Sumrall
e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
Click to expand...
Click to collapse
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Originally Posted by Ken Sumrall
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Click to expand...
Click to collapse
Click to expand...
Click to collapse

musashiro said:
they say (in the PSA message of entropy) that the OTA update of ICS is affected with the "superbrick" bug that bricked a lot of users... and the idea scares me...
questions :
1. why is the bug present on an OTA update?
2. a lot of users say that they use wipe and their ICS is fixed. if LPY is affected with this "superbrick" bug, how come they are still using their phone after wiping?
3. how to safely go back to Stock GB??
Click to expand...
Click to collapse
1) I have no clue - I have lost a LOT of faith in Samsung as a result of this. For more detail, see chasmodo's post in the CM9 thread.
2) Maybe only 5-10% of people get hit by Superbrick - many can wipe with affected kernels and be safe, also in many cases you can wipe 3-4 times and die on the 5th attempt (see Epic 4G Touch forums)
3) Flash an unaffected kernel using Odin.

Entropy512 said:
1) I have no clue - I have lost a LOT of faith in Samsung as a result of this.
Click to expand...
Click to collapse
Yeah man. Last Samsung phone for me. Luckily I didn't "upgrade" to it yet.

I've tested:
Wipe everything with original recovery
Wipe Everything with CWM
Not a single issue.
My guess is that the "superbrick" is something related to the use of a kernel that's its not intended to this device. Maybe there's more diference between I9220 and N7000 that we know!
Just my 2c.

Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9

Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
thats what im thinking...
glad im not the only one who thinks that way....
we NEED confirmations with CF, but he is also thinking that LPY *does* have the I/O bug...

musashiro said:
thats what im thinking...
glad im not the only one who thinks that way....
we NEED confirmations with CF, but he is also thinking that LPY *does* have the I/O bug...
Click to expand...
Click to collapse
Time will tell. This was official OTA not a leak. So if thia creates a lot of problems I would not be surprised to see some sort of litigation against Sammy.

how dead is the emmc actually?
is it dead physically, or is there any security key got erased?
to my understanding, emmc is just a sd card(or mmc card), that is soldered onboard directly. it should handle all nand flash trouble internally and act like a block device. the driver should be fairly simple.
for nor flash there is a high voltage factory high speed programming mode that can only be used for 10 times or so.

first thing that bugs me is that, out of all the users who flashed the LPY rom and LPY cfroot, he is the only one complaining about brick...

Whenever I read about these bricked notes, CM9 always seems to be mentioned too... maybe that is just a coincidence.

Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
that's what i did, straight from cm9 v7 to lpy. may be i'm lucky

What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.

Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
The contents of /system are irrelevant to how recovery behaves when wiping.

Look, guys, it's extremely hard to tell what exactly caused my Note to brick up.
Maybe all my Repack Rom hopping made it wonky, and LPY was the proverbial
straw that broke the camel's back?
Maybe LPY contains some bug that affects one Note in a thousand? Ten thousand?
I certainly don't think CM9 is to blame. If the kernel is 100% pukka, not a single Rom
could cause a hard-brick.
Anyway, I wouldn't start a panicky retreat to GB if I were you.
Use your phones cautiously, though: don't start flashing custom Roms left, right
and center when they emerge. Also, don't use your CWMR if you don't have to,
just in case. And check the fora regularly to see if there are any more bricks.
Then decide what to do.
I sincerely hope I'm the first and the last victim of LPY.

robertberma said:
What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.
Click to expand...
Click to collapse
He wasn't on a chinese leaked kernel, he was on official CM9 kernel.

ykk_five said:
that's what i did, straight from cm9 v7 to lpy. may be i'm lucky
Click to expand...
Click to collapse
i think there's a difference in flashing.
chas was already on cm9 and decided just to flash the kernel only.
whereas your case you flashed the full lpy rom package from cm9 over cm9.
my case was similar to yours but i flashed the rom and cf lpy root kernel all at one go without wipe in mo, but could not get pass the boot screen after which a complete wipe in cwm solved the problem.
but i guess i won't be flashing anything in cwm yet until it is confirmed safe.

robertberma said:
What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.
Click to expand...
Click to collapse
I was on officiele™ CM9, Bobby, not Chinese...ahem...as you so eloquently put it.

We're really unlucky with this hardbricking and all crap i mean how long will this go on? This is getting ridiculous ...

I think the difference was: Most people wiped when flashing LPY, and when they wiped, they were still on an old "safe" kernel.
In Chas's case - he forgot to wipe initially, so went and wiped using the LPY kernel.
Wiping (and anything that incurs a wipe/format, which includes flashing full firmware packages and Nandroid restores) seems to be the most dangerous operation - it's the same deal over in the Epic 4G Touch forums - wipes are the killer.
And as stated in the sticky - this may only affect a small percentage of users - maybe 2%, maybe 5%, maybe 10%. That's why some people have been able to safely wipe with affected kernels in the past. It's the same over in the E4GT forums - some people wiped 10 times and problems showed up on the 11th.

i guess i will just use the phone normally, no flash, no wipes.. just a regular phone(the main reason for buying the phone) and wait till clarifications arise..
since Chainfire also uses the words "might", "appears" and others that certainly tell that he isn't sure as well...
lets wait for more clarifications....
for me if its an OTA update.. it means that its fully polished.. the main reason why i used it instead of custom roms and sh*tty leaks..

Samsung responds to Galaxy S II / Note eMMC bug problem

If you own a Samsung Galaxy S II or the Galaxy Note and are a regular member of the xda-developers forum, you may already be aware of a bug with some of these devices where erasing the eMMC could hard brick your phone.
This problem would surface if the user tried to flash a custom ROM or kernel that used MMC_CAP_ERASE. Thankfully, developer Chainfire came up with an app that would let you know if your device was shipped with a faulty eMMC.
Apparently, this issue has existed for a long time now and even though it was noticed a couple of months ago and was much talked about in the developer community Samsung did not respond to it, until now.
According to user Daniel Hillenbrand on Google+, Samsung has said that "Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time."
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
SOURCE

Atleast give source of info and links ?

anshmiester78900 said:
Atleast give source of info and links ?
Click to expand...
Click to collapse
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.

buzzboy said:
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.
Click to expand...
Click to collapse
Cheers mate and it is good to know that samsung is working hard on it

Stupid question but does that mean that we need to wait first Samsung to release something and then rom and kernel makers to implement it in their products? I just flashed slimics rom and now checked that I have brick bug, nice!
Sent from my GT-I9100

I don't really think it's Samsung fault. They have spend a lot of time working on those devices, and of course, bugs are all part of the development. I don't think that Samsung is a bad company, but they need at least to figure out the problem and fix in the next device or firmware, so that's enough to me.
edit: well, it's kindda samsung's fault, hehehe.

I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only. How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?

donalgodon said:
I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only.
Click to expand...
Click to collapse
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem

Azurren said:
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem
Click to expand...
Click to collapse
Does that list get updated?
How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?
I assume that since this is such a potentially serious issue, the MMC_CAP_ERASE issue is something that devs are well aware of. I wasn't aware of it until very recently.
IF I understand correctly, are you saying that the stock kernels no longer have this issue or do they still and can MMC_CAP_ERASE be removed from the kernel?

it will b great if the patches roll out soon

Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?

mzone1510 said:
Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?
Click to expand...
Click to collapse
this thing can destroy your mobile
MMC_CAP_ERASE is one of the big reason to hardbrick the sgs2 phone.

NOMIOMI said:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
Click to expand...
Click to collapse
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing

AvRS said:
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing
Click to expand...
Click to collapse
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!

superleeds27 said:
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!
Click to expand...
Click to collapse
Indeed and unfortunately it starts due to threads like these, sorry OP.
Here's some further reading for those who avoid using search so sit down, read and then forget:
Entropy512 said:
It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).
This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c
As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000, all GT-I9100 custom kernels I am aware of, and all SGH-I777 custom kernels I am aware of
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
The SGH-I777 UCLD3 leak is UNSAFE, as is most likely every other leak for that device. Fortunately nearly everyone is using I9100 Update4-based custom kernels.
SGH-I727 and SGH-T989 ICS leaks are UNSAFE - However as these two devices use separate recovery and operational kernels, if you have a Gingerbread recovery/kernel, you should be safe regardless of what you are booting for normal operation.
It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.
I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
UPDATE:
We have at least one confirmed report of this bug occurring with KYL00M fwrev 0x12 on a Samsung Skyrocket (SGH-I727) with their ICS leak kernels
In addition, Samsung Hercules (SGH-T989) has the same fwrev and I've been told that they have observed bricks of this type with their ICS leaks
UPDATE 2:
I've received an email from a contact at Samsung who has indicated they are working on some sort of fix to be deployed to devices with an "UNSAFE" configuration listed above. I have requested that I receive an explicit list of which binary builds contain this fix, as without that I cannot know for sure which builds are fixed and which are not. Fixes are not yet deployed to affected devices.
Click to expand...
Click to collapse

HELP!
I have bad news (for me, of course) my phone is bricked, I write here because I want my phone back and I find no solution so far for this model, only for the Note and Epic 4G. Anyone have any ideas to solve the problem of brick MMC_CAP_ERASE for i9100? I'm reading from 6am..
if the moderator feels that this post should not go here, is his right of disposal. I just want an answer and a possible solution. thanx

I got the emmc bug too..good thing nothing happened when I flashed my phone. using siyah 4.1.5 kernel

I got to emmc bug and o tried all stuff i have jtag-et device 4 times but nothing always same when instaling something my phone freazes. And i have byed new sgs2 and my old phone is just waiting bether times
Sent from my GT-I9100 using xda app-developers app

Help needed with moving to a Safe ICS Kernel From Stock 4.0.3

Hi, I have a galaxy note which is running the stock ICS out of the box. It is not rooted. Here are the details:
Model Number: GT-N7000
Android Version: 4.0.3
Baseband Version: N7000XXLPT
Kernel Version: 3.0.15-N7000JPLPD-CL643396
[email protected]#3
SMP PREEMPT Thu May 31...
Build Number: IM74K.JPLPD
I have installed chainfires Gotbrick app and the app says that my phone (Rev 0x19) has this eMMC brickbug. So if i do a factory reset/wipe on this phone my phone will get superbricked. Thus i want to move away from the unsafe stock ICS kernel to a safe and stable ICS kernel. From my research i have gotten to know that the following ICS kernels are safe:
SpeedMod v3
Franco r3
CM9 Nightlies
MIUI
(Correct me if im wrong on any of the above Kernels)
So basically i want a step by step instruction on how to move from the Stock ICS kernel to any of the above safe kernels. Please be generous to mention it step by step because causing a small mistake can lead to bricking my phone. Also it can help many users out there who have less skill level with android and want to move to safe ICS kernels. I will then make a youtube tutorial to help out the Galaxy Note users who have this eMMC bug problem on their phone.

download this https://dl.dropbox.com/u/69014495/speedmod-kernel-n7000-ics-k3-3-Odin.tar
once downloaded, Put your phone in download mode (take out battery, put back in, Press volume DOWN + Home button + Power button)
Open ODIN, Click PDA, find the speedmod kernel, connect phone, select start.
Job done

Agreed, speedmod is simply fantastic I would recommend it over any other kernel, particular Franco r6 as it has quite a few bugs.
Sent via carrier pigeon

azzledazzle said:
download this https://dl.dropbox.com/u/69014495/speedmod-kernel-n7000-ics-k3-3-Odin.tar
once downloaded, Put your phone in download mode (take out battery, put back in, Press volume DOWN + Home button + Power button)
Open ODIN, Click PDA, find the speedmod kernel, connect phone, select start.
Job done
Click to expand...
Click to collapse
Would it be ok to install with mobile odin? I have a stock rooted LPF ics rom.
Sent from my GT-N7000 using xda premium

Yes and won't raise the binary count and the yellow triangle
Sent from my GT-N7000 using xda app-developers app

azzledazzle said:
download this https://dl.dropbox.com/u/69014495/speedmod-kernel-n7000-ics-k3-3-Odin.tar
once downloaded, Put your phone in download mode (take out battery, put back in, Press volume DOWN + Home button + Power button)
Open ODIN, Click PDA, find the speedmod kernel, connect phone, select start.
Job done
Click to expand...
Click to collapse
glevitan said:
Yes and won't raise the binary count and the yellow triangle
Sent from my GT-N7000 using xda app-developers app
Click to expand...
Click to collapse
Thanks to all users who helped especially azaledazzle for providing the link and easy to understand instructions. So hopefully ill make a tutorial on youtube to help out members who wish to move to a safe kernel from stock ics! Cheers!
I had a few questions: Will installing the Speedmod Kernel as mentioned in the posts increase the binary count and show the yellow triangle? If it does is there anyway to reset it without bricking the phone?
Also does this kernel support CPU/GPU overclocking because the official speedmod thread does not mention it!

I flashed speedmod kernel with mobile odin, no yellow triangles or increased counts.
AFAIK speedmod does not allow overclocking.
Sent from my GT-N7000 using xda premium

No, Speedmod is all about performance and stability, Thats why they dont include OC'ing of the CPU. I dont feel my Note needs OC'ing anyway.
If you do get the binary count increase and yellow triangle, Use Chanfire's Triangle Away app, Its free on XDA and it works perfectly.

I firstly would like to thank all users who helped out especially azzledazzle. I have compiled all this information into a tutorial and posted it on youtube. If any users are running the official ICS and would like to flash a stable ICS kernel then here is a tutorial: http://www.youtube.com/watch?v=o5K5Wm_201Y&feature=youtu.be

I followed the instructions to a "T", and everything flashed great,
but my keyboard gives a "null" when I type
any ideas?

Reflash the csc. Download a rom for the region you need and unzip it down to expose the 3 files. You need the "cache" file. Reflash it.
Sent from my GT-N7000 using xda premium

DJTJ said:
I followed the instructions to a "T", and everything flashed great,
but my keyboard gives a "null" when I type
any ideas?
Click to expand...
Click to collapse
Hey man, im glad to hear that it worked out for you! But i could not really get what u meant by ur keyboard gives a null? Did u mean that the keyboard on the note stopped working??? If that is the case have u tried to install any other keyboard?

Thanks for posting the you tube video.
I want to first know what is this EMMc bug and what is meant by bricking the phone?
I can understand that upgrading the Kernal is something very important and thanks specially for The youtube video creator and azledazzle user for giving very valuable info.
Please bear with me since am new to this. Please explain me a little about this kernal, EMMc and Bricking.
I also have one more question, once i go to download mode and if i dont want to go ahead with the updation, can i go back to normal mode? If so how?
And will this flashing erase my data? If yes what all datas?

sweet_rascal said:
I want to first know what is this EMMc bug and what is meant by bricking the phone?
I can understand that upgrading the Kernal is something very important and thanks specially for The youtube video creator and azledazzle user for giving very valuable info.
Please bear with me since am new to this. Please explain me a little about this kernal, EMMc and Bricking.
I also have one more question, once i go to download mode and if i dont want to go ahead with the updation, can i go back to normal mode? If so how?
And will this flashing erase my data? If yes what all datas?
Click to expand...
Click to collapse
Hey man. I understand that android can be a bit complicated at times. So I thought ill help you out with this:
Kernel: To understand what a kernel is you have to know how android works. Think of Android as layers. The basic and insidemost layer of android is JVM or Java Virtual Machine which runs everything. On top of that there is a ROM (Read Only Memory) which is basically the OS containing all the commands. Lastly on top of the ROM layer is the Kerenel which allows the hardware to communicate with the ROM. Note: This definition may not be 100% correct but it will give you a rough idea of how android works.
Secondly about the eMMC bug: It is a bug which is found on Exynos 4210 based phones which are Galaxy S II i9100, Galaxy Note N7000, Epic Touch 4g and few others. So this bug causes your phone to get "Superbricked". Now in short by superbrick i mean that you will not be able to get back your device unless you physically change a hardware component of the Phone which is the motherboard.
So now that the consequences of the bricked device are covered, i will tell you how this bug is triggered. If you factory reset/wipe your phone using settings or Clockworkmod Recovery, your phone will get bricked. However you will get bricked only if:
1)You are currently on Icecream sandwitch and with the stock samsung kernel.
2)You are Running any Leaked ICS kernel
3)You are Running any ICS kernel which is based on the Stock Samsung Kernel
To make it more understandable, these kernels contain a certain function called the eMMC_Erase function which wipes the eMMC chip to wipe. Only once the chip is wiped will the device be bricked. So the kernels which are safe are those which have disabled this eMMC_erase function to prevent the eMMC Chip from wiping. IN SHORT IF YOU ARE ON ICS 4.0.3 THEN DO NOT WIPE/FACTORY RESET YOUR PHONE UNTILL YOU HAVE FLASHED A SAFE KERNEL. The following kernels are confirmed as safe:
1) Speedmod Kernel for N7000(Recommended)
2) Franco's Kernel for N7000
3) CM9 Knightlies Kernel for N7000
There might be more kernels that are safe but as of now these three kernels are what i know of and are 100% confirmed to be safe so i recommend that you flash Speedmod's Kernel for N7000 as it is safe and also has better Performance and Battery Life than than the stock ICS Kernel. You can find my tutorial here: http://www.youtube.com/watch?v=o5K5Wm_201Y&feature=plcp
Now coming to your second question on whether you can go back to normal mode after going into download mode. So to answer your question: Yes you can. Think of the download mode equal to going into your System BIOS on your PC/Laptop. You can return to Normal Windows after exiting from BIOS right? Similarly you can return to the normal OS after going into download mode. If you do not want to go ahead with the flash then just hold the power button in download mode untill it reboots and you should be just fine. Lastly flashing this Kernel will NOT erase your data. Only if you flash a custom ROM will your Data be erased. Just follow my steps in the tutorial and it should be fine.

You can also use cf-root 5.6. Its a stock kernel with root and will not trigger the superbrick bug.:good:

info solution for root
azzledazzle said:
download this dl.dropbox. com/u/69014495/speedmod-kernel-n7000-ics-k3-3-Odin.tar
once downloaded, Put your phone in download mode (take out battery, put back in, Press volume DOWN + Home button + Power button)
Open ODIN, Click PDA, find the speedmod kernel, connect phone, select start.
Click to expand...
Click to collapse
hi,
with this method(odin pc), the counter and triangle away is possible to be appear???
thanx good night!!!
---------- Post added at 04:12 AM ---------- Previous post was at 04:05 AM ----------
jonpaslim said:
You can also use cf-root 5.6. Its a stock kernel with root and will not trigger the superbrick bug.:good:
Click to expand...
Click to collapse
hi jonpaslim,
this procedure with odin pc (Odin3_v3.04), is possible to be appear any binary counter and triangle away??? thnx bye

Originally Posted by*jonpaslim**
You can also use cf-root 5.6. Its a stock kernel with root and will not trigger the superbrick bug.
hi jonpaslim,
this procedure with odin pc (Odin3_v3.04), is possible to be appear any binary counter and triangle away??? thnx bye
Just use mobilodin it will not produce yellow triangle.

xxxfirenzexxx said:
hi,
with this method(odin pc), the counter and triangle away is possible to be appear???
thanx good night!!!
---------- Post added at 04:12 AM ---------- Previous post was at 04:05 AM ----------
hi jonpaslim,
this procedure with odin pc (Odin3_v3.04), is possible to be appear any binary counter and triangle away??? thnx bye
Click to expand...
Click to collapse
Hi mate, if you use the ODIN method shown in the youtube tutorial, then the triangle will appear but in order to get rid of the triangle or reset the flash counter just follow my tutorial here: http://www.youtube.com/watch?v=O3t6nqUiZiw&feature=plcp

Or use mobile odij to flash a chain fire kernel to avoid counter.
Sent from my GT-N7000 using xda premium

endingcolt007 said:
Hey man. I understand that android can be a bit complicated at times. So I thought ill help you out with this:
Kernel: To understand what a kernel is you have to know how android works. Think of Android as layers. The basic and insidemost layer of android is JVM or Java Virtual Machine which runs everything. On top of that there is a ROM (Read Only Memory) which is basically the OS containing all the commands. Lastly on top of the ROM layer is the Kerenel which allows the hardware to communicate with the ROM. Note: This definition may not be 100% correct but it will give you a rough idea of how android works.
Secondly about the eMMC bug: It is a bug which is found on Exynos 4210 based phones which are Galaxy S II i9100, Galaxy Note N7000, Epic Touch 4g and few others. So this bug causes your phone to get "Superbricked". Now in short by superbrick i mean that you will not be able to get back your device unless you physically change a hardware component of the Phone which is the motherboard.
So now that the consequences of the bricked device are covered, i will tell you how this bug is triggered. If you factory reset/wipe your phone using settings or Clockworkmod Recovery, your phone will get bricked. However you will get bricked only if:
1)You are currently on Icecream sandwitch and with the stock samsung kernel.
2)You are Running any Leaked ICS kernel
3)You are Running any ICS kernel which is based on the Stock Samsung Kernel
To make it more understandable, these kernels contain a certain function called the eMMC_Erase function which wipes the eMMC chip to wipe. Only once the chip is wiped will the device be bricked. So the kernels which are safe are those which have disabled this eMMC_erase function to prevent the eMMC Chip from wiping. IN SHORT IF YOU ARE ON ICS 4.0.3 THEN DO NOT WIPE/FACTORY RESET YOUR PHONE UNTILL YOU HAVE FLASHED A SAFE KERNEL. The following kernels are confirmed as safe:
1) Speedmod Kernel for N7000(Recommended)
2) Franco's Kernel for N7000
3) CM9 Knightlies Kernel for N7000
There might be more kernels that are safe but as of now these three kernels are what i know of and are 100% confirmed to be safe so i recommend that you flash Speedmod's Kernel for N7000 as it is safe and also has better Performance and Battery Life than than the stock ICS Kernel. You can find my tutorial here: http://www.youtube.com/watch?v=o5K5Wm_201Y&feature=plcp
Now coming to your second question on whether you can go back to normal mode after going into download mode. So to answer your question: Yes you can. Think of the download mode equal to going into your System BIOS on your PC/Laptop. You can return to Normal Windows after exiting from BIOS right? Similarly you can return to the normal OS after going into download mode. If you do not want to go ahead with the flash then just hold the power button in download mode untill it reboots and you should be just fine. Lastly flashing this Kernel will NOT erase your data. Only if you flash a custom ROM will your Data be erased. Just follow my steps in the tutorial and it should be fine.
Click to expand...
Click to collapse
Many thanks for your useful update. I really appreciate your guide. Last couple of days i was looking for a safe kernal for my galaxy note which is running on stock ICS.
---------- Post added at 01:07 PM ---------- Previous post was at 12:26 PM ----------
mjrifath said:
Many thanks for your useful update. I really appreciate your guide. Last couple of days i was looking for a safe kernal for my galaxy note which is running on stock ICS.
Click to expand...
Click to collapse
Just to verify below thread is confirming that cm9 based kernal is known as safe..
http://forum.xda-developers.com/showthread.php?p=28093615#post28093615
please advise soon..

[Big Warning] for the leaked ICS 4.0.4 XXLQ5

Today sammobile.com said that a big warning for the leaked ICS 4.0.4 XXLQ5
you can see the warning in sammobile i9100 firmware page
The Warning:
Warning: If you flash this from custom rom or stock do not wipe/factory reset. But flash a stock Gingerbread Rom trough odin first before you flash this rom. In Gingerbread you can wipe/factory reset..
Please be carefule

There are a thread like this already.
"Search before posting"

http://forum.xda-developers.com/showthread.php?t=1756242
Sent from my GT-I9100 using xda premium

ok
but this is official warning from sammobile

And we have more than official warnings...

ok no problem
let the user get the benefits

Someone has any idea why Gingerbread ?

00raq00 said:
Someone has any idea why Gingerbread ?
Click to expand...
Click to collapse
No reason, its just to make users don't make any more booboo.
You can safely flash ICS if that what you want.

00raq00 said:
Someone has any idea why Gingerbread ?
Click to expand...
Click to collapse
It's all because of the faulty EMMC chip/firmware. Official gingerbread kernels were issuing the erase command in a way that it did not initiated the bug, but ics kernel changed a lot of things and ever since then there is a chance that you gonna hard brick your phone if you start an sd card format. It's a known problem and Samsung made an comment that they gonna release a fix later on in a form of a firmware update.

e-Tiggy said:
It's all because of the faulty EMMC chip/firmware. Official gingerbread kernels were issuing the erase command in a way that it did not initiated the bug, but ics kernel changed a lot of things and ever since then there is a chance that you gonna hard brick your phone if you start an sd card format. It's a known problem and Samsung made an comment that they gonna release a fix later on in a form of a firmware update.
Click to expand...
Click to collapse
Problem is people do not read, but act like a herd. Galaxy S2 kernels were safe from that bug, it never was issue with ICS kernels for S2, leaked or official.
Until Lq5 came and changed that.
So in short, doesn't matter you flash GB, ICS. Heck you can even flash cm9 resurrection Odin version and it will fix the issue.

I agree with you but I wanted check my knowledge.

XXLS1 JB leak and eMMC "brickbug" safety

I was going to put this in the JB thread, but that has apparently been locked due to flaming.
As mentioned in other threads on the eMMC "brickbug", Samsung's official patch for this issue is NOT to remove MMC_CAP_ERASE, but to only disable secure erase in the kernel.
See: https://patchwork.kernel.org/patch/1383661/
Now, we've been highly disappointed that Samsung hasn't included this patch in many updates for a variety of devices. However, on analyzing the kernel, it appears it *might* be safe due to having Samsung's official patch.
If you unpack the kernel, and then run "strings" on the unpacked image, you will see the following:
Code:
M8G2FA
MAG4FA
MBG8FA
MCGAFA
VAL00M
VYL00M
KYL00M
VZL00M
e.g. the exact list from the above patch, in the correct order.
So it looks like the XXLS1 JB leak is *probably* safe from the Brickbug - unless Samsung is wrong about nonsecure erase being safe.

+1
Good news for Note Community

I agree..... thanks for taking the time to share your findings with us.
:good:

Good to see some improvements from Samsung! Thanks a lot Entropy.. without your precious help this wouldn't be possible

Many thanks Entropy..
So now we can do full wipe without any fear...??
Sent from my GT-N7000 using xda app-developers app

Brilliant..thanks mate!
Sent from my GT-N7000 using xda premium

thanks for the update.
Its great to see people like you care for the rest

Entropy512 said:
I was going to put this in the JB thread, but that has apparently been locked due to flaming.
As mentioned in other threads on the eMMC "brickbug", Samsung's official patch for this issue is NOT to remove MMC_CAP_ERASE, but to only disable secure erase in the kernel.
See: https://patchwork.kernel.org/patch/1383661/
Now, we've been highly disappointed that Samsung hasn't included this patch in many updates for a variety of devices. However, on analyzing the kernel, it appears it *might* be safe due to having Samsung's official patch.
If you unpack the kernel, and then run "strings" on the unpacked image, you will see the following:
Code:
M8G2FA
MAG4FA
MBG8FA
MCGAFA
VAL00M
VYL00M
KYL00M
VZL00M
e.g. the exact list from the above patch, in the correct order.
So it looks like the XXLS1 JB leak is *probably* safe from the Brickbug - unless Samsung is wrong about nonsecure erase being safe.
Click to expand...
Click to collapse
Well, well.
Samsung finally at last!
Thanks Entropy for the good find.

Lets hope Samsung did a good job !
Now to download that leak.......

I am still wondering about the update. If we have the brick bug in ics how are we able to flash ota jelly bean?? Wont there be chances of bricking while updating our phone to jb.
Sent from my GT-N7000 using xda app-developers app

qazibasit said:
I am still wondering about the update. If we have the brick bug in ics how are we able to flash ota jelly bean?? Wont there be chances of bricking while updating our phone to jb.
Sent from my GT-N7000 using xda app-developers app
Click to expand...
Click to collapse
The usual applies... Flashing anything via Odin is safe. Flashing anything from a safe kernel is safe. Flashing something with a "safe" update-binary should be safe even on a dangerous kernel.
I'm not going to guarantee the safety of the XXLS1 kernel, as it's hard to guarantee that it is doing what we think it is, but it is PROBABLY safe as opposed to definitively dangerous like any previous official ICS kernel binary. We won't know unless people take risks unfortunately...

ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing fs image,finally got it working with the pit method and by updating bootloader and clear efs, this has kinda scared me as after a cple hrs trying that it would be sent to repair
be aware this worked for me it may not for anyone else

[/COLOR]
anubis1126 said:
ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing fs image,finally got it working with the pit method and by updating bootloader and clear efs, this has kinda scared me as after a cple hrs trying that it would be sent to repair
be aware this worked for me it may not for anyone else
Click to expand...
Click to collapse
I was going to write a sarcastic post but... that sucks
This means the Samsung work around did not work.
Either that or you might have repartitioned for no reason.
Did you try a nandroid restore first?

anubis1126 said:
ok using the jb rom i did indeed soft brick has taken 5 hrs to get my note working, i had a custom rooted 404 rom on with hydracore install the jb with cwm and that was it stuck on samsung logo ,so i then tried to flash stock 404 with pc odin and was stuck on flashing factoryfs....
Click to expand...
Click to collapse
So you bricked bricked flashing on Hydracore? I thought that was safe!

shoey63 said:
So you bricked bricked flashing on Hydracore? I thought that was safe!
Click to expand...
Click to collapse
He already flashed the jb leak, overwriting hc with its own kernel in the process. Flashing back to 4.0.4 on the leaked rom caused the soft brick, NOT hc.
Sent from my Asylumized shopping cart.

randomtext said:
He already flashed the jb leak, overwriting hc with its own kernel in the process. Flashing back to 4.0.4 on the leaked rom caused the soft brick, NOT hc.
Sent from my Asylumized shopping cart.
Click to expand...
Click to collapse
He used PC Odin to "flash back". I thought that was safe too!
Anyway odin stuck on factoryfs and needing PIT file method to revive Note is SUPERBRICK, not "softbrick"

Entropy512 said:
The usual applies... Flashing anything via Odin is safe. Flashing anything from a safe kernel is safe. Flashing something with a "safe" update-binary should be safe even on a dangerous kernel.
I'm not going to guarantee the safety of the XXLS1 kernel, as it's hard to guarantee that it is doing what we think it is, but it is PROBABLY safe as opposed to definitively dangerous like any previous official ICS kernel binary. We won't know unless people take risks unfortunately...
Click to expand...
Click to collapse
I've tried it a dozen times and seems to be ok
Ran the check and lost no memory at al
Thanks would be nice for my daring? Stupidity ? Did full wipes etc
Sent from my GT-N7000 using Tapatalk 2

howard bamber said:
I've tried it a dozen times and seems to be ok
Ran the check and lost no memory at al
Thanks would be nice for my daring? Stupidity ? Did full wipes etc
Sent from my GT-N7000 using Tapatalk 2
Click to expand...
Click to collapse
Actually it's the same as wiping on stock ICS recovery. Well done for trying to verify :thumbup:

what can i say i am a flashaholic flash at least once a week trying varied roms themes etc this time it just happened to me
redone pit file and gained a bit more space

anubis1126 said:
what can i say i am a flashaholic flash at least once a week trying varied roms themes etc this time it just happened to me
redone pit file and gained a bit more space
Click to expand...
Click to collapse
Happened to me too useing stupid Cwm.zip - accidentally hit factory reset and BANG! Superbrick! Thankfully grey retailer replaced it.:thumbup:
Sent from my GT-N7000 using xda app-developers app