yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] nCoder:
Quick Question:

I noticed that Samsung has 3 different ICS source packages:

- GT-N7000_ICS_Opensource_Update3.zip (EUR)

- GT-N7000_MEA_ICS_Opensource_Update1.zip

- GT-N7000_SEA_ICS_Opensource_Update1.zip

- GT-N7000_SWA_ICS_Opensource_Update1.zip

http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=GT-N7000

Because there is no timestamp in the listing, is not possible to see what package is the most recent.

Is there a chance that the eMMC erase problem is mitigated in any of these versions, or nobody checked yet?

Cheers

(note to self: to download files from this repo, use the following qs: "GET opensource.samsung.com:80/reception/receptionSub.do?method=downLoad&attach_id=" + fileId + "&down_purpose=SCC&menu_item=mobile")
[Galaxy Note GT-N7000 General] Entropy512:
No, Samsung is still trying to weasel out by claiming there is no problem.

Yes - see my tests a page or two ago.

This has already been discussed in the thread in the E4GT forums. We know that a firmware update is technically possible, and we know that the firmware update process fully resets the chip, fixing the issue.

The problem is - Samsung will not release the documentation on how to update firmware for this chip, or the new firmware. Mr. Sumrall is attempting to get permission to release this but so far no luck. (Google has this capability in their possession, but it appears to be restricted from distribution by a Samsung NDA.)

In addition to this info, we would need a way to boot the device with dead eMMC. This means either a properly signed USB bootloader for use with AdamOutler's Unbrickable Mod (right now, UBM won't work on Exynos due to lack of a proper USB bootloader) or Samsung providing the info to the RIFFbox JTAG guys or similar JTAG recovery service providers.

Hmm, looks like a whole bunch of new packages. I've only reviewed Update3.

Best way to check - does MMC_CAP_ERASE appear in drivers/mmc/host/mshci.c? If yes, it's dangerous (unless Samsung puts a block in somewhere else.)

I won't have time to look until later this week.
[Galaxy Note GT-N7000 General] sangalaviral:
MMC_CAP_ERASE still present in the above mentioned file.

And this package is 22nd May and above mentioned file is dated way back in February.
[Galaxy Note GT-N7000 General] :
After i get my Note back i'll prove that the brick actually exists! I have warranty for it... Entropy did you test wiping with stock kernel? the 20 times?

If you want i can do it myself and brick my device on purpose and will get it to Samsung Service Center to replace the motherboard for free!

What do you say?

This actually pisses me off! The bug exists... we know it, they know it and we have seen a lot of bricks with LPF and LPY and the other Official ICS releases!

I did actually bricked my Note with the official ICS!

What the guys from the Samsung Service Center actually told me is that this was an error on Kies... has nothing to do with the firmware!!!! :mad:
[Galaxy Note GT-N7000 General] nCoder:
Hi Entropy

Just to clarify your post ;), so we don't get more heated troll comments, from others that unlike you and me are been in contact with Samsung Developers.

AFAIK Samsung never said there is no problem, in both channels I'm in contact with Samsung (Samsung Developers and Samsung Ireland), they escalated the problem, and sent all the technical details we provided to HQ and are willing to help us prove the problem, as long they are able to reproduce it - which, as you know, they were not able to, despite trying all test scenarios we gave them several times and in different devices.

Cheers
[Galaxy Note GT-N7000 General] nCoder:
Como diria o Abrunhosa: "E' preciso ter calma" :)

Hi

Could you clarify how did you brick your Note exactly?

Thanks

BTW: There is more than one way to brick a device. Yours could be a different case. Was that a hard-brick for sure?

_____Edit____

I see... ;)

Anyway - What happened for real?
[Galaxy Note GT-N7000 General] :
Grande abrunhosa :D

Anyway i noticed that it started to create bad blocks because when i was flashing roms thru CWM i couldn't get /system to mount as RW!

No matter what i do i couldn't get it to RW state!

I was on LPF all the time.. with cwm!

After i knew it wasn't safe to use cwm i changed to the stock kernel of LPF, without flashing the new bootloader of course and used the official rom LPF!

And after a couple of wipes in stock kernel i did get bad sectors all over the eMMC of my device and doing the revive tutorial i got to a point that i lost 4,9Gb in bad sectors!

So yes, i did brick my device with LPF stock kernel and not with cwm!

And using stock LPF rom! without root!

So i started thinking: Maybe i will get myself bricked the next time i try to flash a rom! Then i thought:" Hey i have warranty for my device... i will try Odin! "

After i started odin i noticed that factoryfs.img was stopping... i had my device bricked but could still flash kernels and enter cwm, so i went to this topic:

[Guide]How to revive your bricked Gnote

After i flashed the kernel on from 4pda forums (the one that contains parted and the other tools to repartition the eMMC)

I did notice that FACTORYFS, DATAFS and UMS were still in place!

When i started the tutorial from the topic above i got IO errors which confirmed my thoughts: I have successfully bricked my Note and i have bad sectors!!

But i can't get a full diagnose of the commands used by stock kernel like entropy did because i have already taken my device to Samsung Center to get a new MOBO!

Anyway after i receive it i can actually brick it again and get a third motherboard replacement for free if you guys need to prove what causes it!

The only con is that i will start working by next week and it would be kinda difficult to go to Oporto to deliver and pickup the phone but i can manage something!

To answer your question on how to take your device with its warranty to Samsung?

Since i was able to enter download mode and cwm i was able to flash kernels and more kernels but no roms!

I did sucessfully revive my device after the brick but living without 5Gb was a pain in the ass that's why i took it to Samsung!

To get rid of the binary counter and the triangle follow this tutorial:

[REF] How to remove yellow triangle on any firmware with JIG

And flash a stock kernel from:

[KERNEL] Stock Kernel for N7000

They did accept my warranty and there is no way to verify that the binary counter was reset :D

Doing the above works like a charm to take the phone to Samsung Center :D

Make sure you have a stock kernel because they will verify the recovery for sure to make sure the warranty wasn't violated!
[Galaxy Note GT-N7000 General] nCoder:
Thank you for your detailed explanation. We've seen a lot of similar cases like yours - definitelly looks like a problem in the eMMC shat should be repaired under warranty.

I wonder if there are a lot of defective eMMCs arround, and the hard-brick could be related with those - i.e. ERASING all nodes in a faulty eMMC would be a scenario that probably wasn't covered by Samsung QA.

Honestly I think Samsung should be already aware of the huge number of mobo replacements worldwide, and should be already working in some sort of workaround to avoid future bricks - but of course, if that's the case, admitting that their eMMCs are not so reliable is not good PR ;)
[Galaxy Note GT-N7000 General] Entropy512:
No - I did not wipe 20 times, that was a test only for the "true believers" who are faithful that Samsung provides a bug-free kernel and didn't screw up despite all of the evidence that says they did and Samsung's long track record of poor software quality control. (Another example - see the fuel_alerted wakelock bug - still in Samsung kernels even though it was fixed by community kernel developers at least as far back as October.)

I've personally confirmed each individual component of the problem in a separate and safe manner - The kernels themselves via code review and the reports of multiple users running stock binary kernels (showing that the binaries match the source, at least in THIS regard), the recovery using an instrumented kernel as described earlier in this thread, and the flash chip itself based on information from Mr. Sumrall indicating that Google encountered the same bug with the exact same symptoms during GNex prototype development with the exact same flash chip and fwrev we have.

I still need to email him to see if Google saw any device-to-device variation in the issue - e.g. were there some devices that seemed "unkillable" even with the defective firmware?
[Galaxy Note GT-N7000 General] jgaviota:
One thing that might be happening at Samsung is that they wipe, bork the emmc in a small way and then don't realize it.

After wiping they should try to flash a whole rom package using Odin, or with whatever method they use in Samsung's Service Center.

So for Samsung to try:

1) Install ICS OTA or through Kies

2) Factory Reset a couple of times

3) Install a full rom with Odin or anyway the Service Center does it

They might be missing the 3rd step and not realizing they have damaged the device, because in their case the damage would be on the /data or /cache partition and there maybe just a small portion.

Also nCoder, ask them if they can release the errata for the 0x19 firmware for the emmc in the Note
[Galaxy Note GT-N7000 General] beestee:
Could the code that calls the erase function be partial to sensitive data, or is it indiscriminatory?

I am still trying to understand why it happens to some and not others. If the flaw is truly in the firmware for the emmc, then the erase function should always result in a predictable pattern of damage.

Since *insert "r" word* can open unwritable sectors is it possible that the secure 'erase' is performed only on sectors open for user write access since those are typically the only areas that should contain a user's sensitive data. Then, if the user happened to 'unlock' a write restricted sector, the erase function could potentially erase itself or the processes on which it relies mid-process and screw things up big time...a.k.a. super brick.
[Galaxy Note GT-N7000 General] jetmarc:
Curing it?

Thanks to Entropy et al, we now know quite accurately where the bug is.

Wouldn't this be enough to fix it ourselves?

We could start with the latest official ICS kernel source code. We could then patch the MMC driver to block ERASE commands, emulating the erase behaviour without actually issuing an ERASE command to the eMMC. For example by issuing a WRITE with 0xFF data. For what the upper layers are concerned, the outcome is the same.

We could then take an official stock firmware file (with same kernel version), and replace the stock kernel with our modified kernel. This should provide 100% stock experience, and at the same time be 100% safe (once the flashing process itself is over).

It would be as good as an official bugfixed Samsung release - only we don't have to wait any longer for it.

What is keeping us from doing this?
[Galaxy Note GT-N7000 General] nCoder:
Not really - The bug seems to be in the eMMC firmware, which is not accessible to us. It must be Samsung releasing a fix - In normal circumstances, it should be almost impossible to hard-brick a device, not the case with the Note.

A perfect analogy would be your PC - if the hard disk firmware has a bug that makes it unaccessible in a specific circumstance, like a specific instruction - obviously he HDD firmware has a bug, We can tell the OS that this HDD instruction is not available for that HDD, but that is only a workaround...

Currently, most custom kernels for the Galaxy Note available in this forum, already have this workaround in place (removing the flag that indicates the capability to ERASE eMMC content).

We know (from the Android developer) that it is possible to fix this issue via a patch, which is good. Some components once flashed cannot be updated unless you open the device and interface directly with the hardware (jtag?).
[Galaxy Note GT-N7000 General] altae:
Have you got the knowledge, skills and time to do it? No? See that is what's keeping us from doing it :-)
[Galaxy Note GT-N7000 General] Entropy512:
When you say "fix" - do you mean "preventing damage in the first place" or "repairing damage already done"?

Preventing damage in the first place is already being done - all custom kernels released for this device (except for Franco r1 and r2 - r3 and later are fixed) have MMC_CAP_ERASE removed from drivers/mmc/host/mshci.c - which causes the kernel to report that it is unable to erase anything attached to the mshci port, which blocks anything attached to that port (our eMMC chip) from ever seeing an erase command. This is why I9100 Update4 and all kernels based on it was safe.

For a while, people weren't sure MMC_CAP_ERASE was the key kernel difference since it is enabled on Gingerbread kernels and those have been fine - after further discussion with Mr. Sumrall, he informed us that the recovery binaries changed between Gingerbread and ICS. That's why I stated above - you need all three components (recovery that erases, kernel that allows it to erase, and the defective eMMC chip fwrev) to be in danger.

Kernels fixed in this way don't have the full privacy benefits of MMC ERASE - but they're as good as Gingerbread in terms of privacy. If you're selling your device and are paranoid about nuking your data:

dd if=/dev/zero of=/dev/block/mmcblk0p10

etc. for /data, /cache, and /sdcard (I believe 10 is data - but I don't have my reference materials with me so I'm going from memory. p9 is /system which should never actually have private data.)

Repairing damage already done is currently not possible. A few people are pursuing various avenues with contacts they have at Samsung to try and get the information required to repair damaged chips, but so far no luck.
[Galaxy Note GT-N7000 General] Latoc:
@Entropy

Does doing this dd thing is a good way of knowing if my chip is fine ?

If I dd system/data/cache and the phone doesn't crash, does that mean I have zero bad sectors ?

Thanks.
[Galaxy Note GT-N7000 General] abhijit038:
Wiped 20 times through factory recovery

Finally, I managed to complete series of 20 wipes on ZSLPF Rom without any bricking. :D

I made sure that I had my all usual apps installed in each case(about 100+ apps).
[Galaxy Note GT-N7000 General] andreww88:
Have you ran the "GotBrickbug" app from Chainfire in Themes/Apps? Just out of curiousity.
[Galaxy Note GT-N7000 General] abhijit038:
Yes I have it installed on my phone; I am on 0x19.

I knew that I have 0x19 firmware version, yet I installed it to verify.
[Galaxy Note GT-N7000 General] nCoder:
Thank you very much for your tests. ;)

So, your test had the same result as Samsung Developers. :(

@Entropy: Since abhijit038 has been so helpful willing to test the bricking scenario, Would you please tell if there is any particular scenario you'd suggest to test?

Is it possible that LPF is "safe"? Is there any way to check if an MMC ERASE was performed?
[Galaxy Note GT-N7000 General] nCoder:
Anyone?
[Galaxy Note GT-N7000 General] abhijit038:
Lately browsing through the threads, I got to know about two incidents amenable for expeditious inspection :

I have come across a report where a person bricked his note using franco kernel which is regarded as safe. :http://xdaforums.com/showthread.php?p=27095985#post27095985

So people, what's your take on this ?

here is another one where a person on franco got bricked while making backup in CWM; he was also on franco r5 http://xdaforums.com/showthread.php?t=1696037

Perhaps these two incidents add credence to the fact that it's CWM and rooting which aren't safe yet on ICS, no matter what kernel you are on.
[Galaxy Note GT-N7000 General] syncopath:
What do you think about this?
[Galaxy Note GT-N7000 General] Entropy512:
One of those is definitively NOT the eMMC damage issue (just a small recovery bug regarding how it handles a damaged ext4 filesystem which is FULLY recoverable by formatting.)

The other one is so damn vague that it's impossible to tell what happened but it doesn't look like eMMC damage.

There are some issues with many CWM implementations here that are COMPLETELY unrelated to the eMMC damage issues. I've had the same issue as the first guy happen myself, that one is easy to recover from.

Partial filesystem/database damage that is fully recoverable with a wipe is something I would expect in Franco's kernels due to the extremely aggressive I/O tuning performed, which trades data integrity for performance. Fortunately, such tuning cannot do permanent damage to your device, but it can result in you wiping a lot more often. :)

People tried that in the E4GT forums months ago - it is not a viable workaround. Among other things, there's a possibility the corrupted data structures in the eMMC chip could cause the damage to spread.

Been a busy week, haven't had a chance to ask Mr. Sumrall if he saw any device-to-device variation.
[Galaxy Note GT-N7000 General] akenis:
I've seen another case several times (or maybe its the same guy in a different thread). I don't understand why attemmpting to flash CM9 from a safe ICS kernel ROM is problematic?

Of the two cases you reference, the first one talks about flashing Franco using DD? Not sure how he flashed it, or if he ever verified he was on a safe kernel.

The second case you reference.... he went from stock ICS to stock GB using PC odin. Is the phone actually using the stock ICS kernel while in download mode? If so, then the flashing of GB could invoking the wipe? I was in a similar situation and used pc odin to flash only a safe GB kernel, and then flashed paranoid.

This all seems so illusive!! The expertise here tends to make me think we have a safe work around of brick bug..... and yet new cases pop up every day. Are people just messing up somehow or are there other issues?

I really want to try some of the newer ICS Roms, but am a little scared... two possible reasons for that:

1. The fixes we have do not cover all bases

2. I too am fallable and could easily make a stupid mistake. I never blame others for being stupid, because what goes around comes around. All it takes is a brief momentary lapse of judgment ....

Lastly why isn't this guy able to brick with wiping 20 times???
[Galaxy Note GT-N7000 General] M3TALLICA:
Completely agree with this.

Here is my SuperStupidBrick.

http://xdaforums.com/showthread.php?t=1696080

CWM did not respond, so I thought it was SuperBrick but it was just softbrick due to partial filesystem/database damage.

People ghastly do something wrong to unbrick the phone (bootloaders, pit files etc) and actually brick their phone.
[Galaxy Note GT-N7000 General] nCoder:
Someone else trying to reproduce the super-brick:
[Galaxy Note GT-N7000 General] andreww88:
That's a weird situation. I read through that entire thread. He never had an eMMc bug brick. It was just a /system partition problem. He got a replacement phone, but I'm almost certain he didn't need to from what Entropy has been saying.

I asked him to get the mods to change the title (which I see he did) because it, in my opinion, was not a superbrick.
[Galaxy Note GT-N7000 General] nCoder:
Definitively was not a superbrick, but he's using a brand new phone to test the known scenario where is expected to superbrick a phone by factory-reset on recovery.

The point here is that noone was still able to reproduce the superbrick on a stock ICS rom - which is very strange due to all the technical details (theoretical evidence) of the probable cause of the hard-brick. :(
[Galaxy Note GT-N7000 General] andreww88:
Well, we haven't had ALL the previous super brick owners try to brick again. Just a one or two people try who never bricked yet. So, who knows?

Whatever the case, the brick bug is real. I don't care what Samsung does anymore. We have good devs here. We will work with what we got. Samsung is just being dumb (and I hope they are reading this :p)
[Galaxy Note GT-N7000 General] abhijit038:
Right now the scenario is such that many users are so paranoid that they wouldn't dare to wipe even on stock non rooted ICS. Unless we have handful of users to support the claim, we can't expect much tangible outcome to justify the verity of the issue.I suggest that we start a new thread about it- users who have actually wiped on stock non-rooted ICS Roms. It's only then we can persuade Samsung to address the issue if it ever exists on stock.
[Galaxy Note GT-N7000 General] :
Couldn't agree more :D
[Galaxy Note GT-N7000 General] prasad.adam:
@Entropy Slightly off topic, but any idea what are symptomatic differences between an eMMC super brick and a soft brick that you wrote about in a post above. Your contribution around this super brick bug is appreciated.
[Galaxy Note GT-N7000 General] paiseleht:
Without wanting to get banned or accused of trolling, I repeat, all the bricking evidence I have seen so far are related to having root and/or 3rd party kernels.

Please, any evidence about the full stock having bricked, please.

So if you want to keep going with the topic you must compare the file system with all of the hidden files/areas of stock system with rooted and 3rd party system.

From repairs I have the information that even after wipes there are areas that still contain old data.

OR - please clean 20 notes of any previous software and install custom ROM's that are made eMMC safe and see if your theory holds water.

Perhaps you should read the dr Ketans latest story about his recent cockup - over confidence is something that will cause trouble.
[Galaxy Note GT-N7000 General] prasad.adam:
Seems Sammy is finally working on it. Better late than never.

http://xdaforums.com/showthread.php?p=27137024
[Galaxy Note GT-N7000 General] :
Great news :D
[Galaxy Note GT-N7000 General] nCoder:
Nice!!!
[Galaxy Note GT-N7000 General] paiseleht:
It is good that Samsung is working on it.

But for those who really do not understand why stock firmware had fewer episodes of the brick, I present this:

http://xdaforums.com/showthread.php?t=1189544

As I understand, NAND memory will develop bad blocks during the usage. Perhaps the stock firmware without rooting caused less problems because those phones were less flashed and therefore their wear levelling was less used.

So it seems to me that the cause of the brick is indeed in the wear levelling algoritms of the eMMC firmware.
[Galaxy Note GT-N7000 General] joe2316:
I like your passion but you are way off base. I had a definite (total black) superbrick with a unit that had been flashed 6 times in it's entire lifespan. Brick caused by LP9 going back to GB via nandroid.
[Galaxy Note GT-N7000 General] PoisonWolf:
Even when Google has told Sammy of this problem and as such forced them to upgrade the nexus nand firmware.... You still post what you posted.

Do you also believe that the world is flat and that there is an edge?

Only reason why folks here at xda encounter the bug more often is because we are a homogenous group of users who wipe and flash probably 50 times much more than a regular user. For example, a family member of mine has the s2. In the entire year and a half (close to it) he has owned the phone, he has only done a factory reset ONCE. This is nothing by xda standards.

But yeah, keep preaching to the choir even when the facts have come from Google directly.
[Galaxy Note GT-N7000 General] Latoc:
I smoke but I don't have a cancer, so smoking is not dangerous.

All those people saying that smoking gives cancer are just plain stupid.

Oh wait, maybe I'll get a cancer later on because of smoking ?

Hhhhmmm......
[Galaxy Note GT-N7000 General] becosemsaida:
I think that there is a big thank you for all that pushed this issue to the max !!!

We all know that if it wasn't for the great devs we have here this just couldn't be possible.

Sometimes it's hard to understand what is going on and some have more knowledge then others. I've read and followed this thread as good as i could and learned some great things (Google helped me with some doubts). For me this is a great experience and once again the xda comunity came through !!

Untill the final solution is not out i think we will see more development about this.

Thanks,

becosemsaida