yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] hg42:
Sorry, I'm not up to date on non n7000 devices

Looks like the omega rom uses the stock kernel.

The stock kernel for your device may eventually be save, ics+jb stock kernels for most samsung devices still are definitely unsafe.

But if your emmc chip is definitely without this firmware bug, you will not have an emmc brick. Did you use the button to scan the memory in the emmc bug check app?

Do I read your post correctly, assuming you cannot go to the recovery? Does the device completely freeze on boot?

If so, at which point?

You might need to pull the battery for 10min.

Or you might need an usb jig (very cheap hardware dongle, that forces the device to download mode in most cases, even if software can not get you there).

Or are you able to go to recovery, but cannot wipe?

If you manage to use the recovery, try my find_brick_start scanner (see signature) and see if it freezes or slows down (brick) or finishes the scan with a reasonably number (no brick).
[Galaxy Note GT-N7000 General] obioan:
My device is booting up to samsung image, at that point I see the animation but doesn't load further.

What I can do:

- I can boot to download mode, install ICS Roms with Odin (so far only files with 1 tar PDA archive). I tried a GB rom with 3 files, PDA, CSC and MODEM but freezes at filesys.

- I can boot to recovery mode and install CWM zips. I installed v4 (non-touch) and v5 (touch) CWM. Tried from there to install custom ROM or restore but with no success.

What I cannot do:

- I can't use wipe in recovery mode or CWM.

I will try your script to check if I have the emmc brick bug.

Thanks.
[Galaxy Note GT-N7000 General] BABAK236:
Hi

"Stock" pit in the zip file work and i have 4.33GB as mass storage.....But i have problem with "EFS" Partition....

I Think i need replace this chip with original 16gb

Any idea for repair or recreate efs partitiom???
[Galaxy Note GT-N7000 General] hg42:
I think 8gb would work, but you need to put meaningful content on your efs partition.

This is personsl information (imei, bluetooth mac, etc.) not contained in a rom package.

For n7000 there is a six part rom package (probably for developers) including a generic efs image on samfirmware, but I don't know if something like that exists for your device.

On n7000, some people seem to have had success with the generic imei, others failed, which seems to depend on the provider. Copying such a partition from another similar phone may help (there are apps for efs backup, 'nitrality' etc.), but then there are two phones with the same imei (which might also be a legal problem, imei is kind of global identifier for your phone often attached go your person, cell phone contracts etc., or at least some apps register via imei).
[Galaxy Note GT-N7000 General] Presko:
Is there a way this thing to be performed on a hard brick ? I am open for any ideas ...
[Galaxy Note GT-N7000 General] mmola:
After much happiness using my i9100 phone as if it was new (except with 3 less GB of memory) I am finding now that it has become very unstable. It will fail after timing out when trying to access mmc0 (you can see a kernel log in pastebin, code 3S0bJTBh (I cannot link URLs yet)). The phone freezes and only a hard restart makes it come back. Usually more than one restart will be necessary until it is stable for another few hours.

I don't know whether this is related to the MMC_CAP_ERASE brick in the first place. Reading the partitions I created back in the day works fine (for example using the old emmc_scan_all_partitions_once).

I suspect that the problem may be that the phone is trying to read the unpartitioned space due to a warped partition table. fdisk -l returns the following:

shell@android:/data # fdisk -l /dev/block/mmcblk0

Disk /dev/block/mmcblk0: 15.7 GB, 15758000128 bytes
1 heads, 16 sectors/track, 1923584 cylinders
Units = cylinders of 16 * 512 = 8192 bytes

Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1923584 15388671+ ee EFI GPT
Partition 1 does not end on cylinder boundary

However, if the partition table is indeed damaged I am don't understand how the phone works most of the time. A possible solution would be to manually reconstruct the partition table adjusting it to the existing partitions, but I don't know the cylinder limits. All I know is, I used an old PIT file (the patched-big-bricked one with the smallest gap).

The other option I can think of is, the phone is dying. I don't like this one. Any help or ideas would be very appreciated.
[Galaxy Note GT-N7000 General] paralog:
Is there a patched PIT file for samsung i777 (at&t galaxy s2)? Appreciate if anyone can share it with me, stuck with this emmc bug for past few days. Thanks.
[Galaxy Note GT-N7000 General] obioan:
Finnaly I managed to manually modify partitions and found out that partition number 10 had problems. I couldn't scan it with dd or e2fsck. So I lost 2.1 GB, repartitioned to avoid that damaged range and deleted HIDDEN partition (I hope there's no problem in deleting HIDDEN partition).

DATAFS has 1.5 GB

Couldn't get the UMS partition to the end 15800, it said something about non existing so I put it to 15600.

I installed stock rom, 4.0.3 of course. Now I can wipe from CWM or samsung's recovery 3de.

The question is why does all custom ROM's, OMEGA, RR, get stuck on install? I can install stock rom from Odin and the phone boots but I can't install custom ROM's. It gets stuck in the process.
[Galaxy Note GT-N7000 General] hg42:
What's a hard brick in your case?

Which "features"?

Generally, at least download mode must work for this method.

Hard bricks are often caused by other reasons, so you might not have an emmc brick.

This is because emmc bricks usually don't effect boot loaders etc. because they are usually not written to, except you do it explicitly at will.
[Galaxy Note GT-N7000 General] hg42:
Not my experience with my own brick, but I can imagine this behavior.

Anyone else with such observations?

Even if the phone doesn't still does not boot after the scan? or did you only scan after it works ok again?

What you see here is a fake msdos partition table, because the phone uses a gpt partition table.

fdisk doesn't handle this, instead you have to use parted.
[Galaxy Note GT-N7000 General] hg42:
You may give me your stock pit
[Galaxy Note GT-N7000 General] hg42:
If you repartitioned manually, did you use the correct sizes?

You need to clearly distinuish between MB and MiB and similar. Beware, not all software uses the correct unit names, so MB might also be MiB (at least old people like me tend to write MB instead of MiB, because they learnt them this way). If you see MiB in a software it should be aware of the difference.

My theory is, you used a size too small for the image, which means Odin cannot write the image to the partition. I am not sure if Odin needs exact partition sizes, but at least they must be big enough to hold the complete image.

Which error messages do you get?
[Galaxy Note GT-N7000 General] obioan:
When you say size too small for image do you mean the number 10 (DATAFS) image size? From what I understand, FACTORYFS (9) is used for ROM instalation.

I only deleted the partitions starting from 10 - 12 because number 10 was the one with the problems.

(parted) mkpart primary 2861 4361
(parted) mkpartfs primary fat32 4361 15600
(parted) name 10 DATAFS
(parted) name 11 UMS
[Galaxy Note GT-N7000 General] mmola:
I am unable to scan anything while the phone is not stable. It freezes soon after turning it on.

However, I have yet to experience a fail like this when in recovery (except when trying to read the bricked sectors, of course).

I have switched back to CM9.1 and have yet to confirm this, but it looks like the error is less frequent.

What I can confirm is that the I/O errors I am sporadically getting are not caused by trying to read the bricked region in the phone. What do you suspect is going on? (since you say you can imagine the phone doing these things).

Oh, and thanks for the partition table clarification. I thought about that, but didn't think the phone used a GPT.
[Galaxy Note GT-N7000 General] hg42:
No, I meant, the size of the partition (in bytes) must be equal or (may be) bigger than the image size (which Odin wants to write).

Should be clear, that otherwise the image would not fit into the partition.

So, end - start should be the same as before repartitioning (except for the UMS partition).

Can you post the output of parted print from a stock partition table of your device? (but not your current table)

With those numbers (without unit), you use parted's default unit.

May be it's not the unit you expect?

This only matters if you got the sizes from other sources than parted itself.

here is a list of parted's units.
[Galaxy Note GT-N7000 General] hg42:
so the wear leveler may get a wrong mapping when accessing blocks used by the boot process.

But I think the wear leveler is only used when writing to the memory. Otherwise the tables should stay as they are.

But perhaps a write can also change parts of the table, that are not directly related with the written block.

May be when the wear leveler tries to optimize the blocks or something like that.

The big question is, if the wear leveler is able to sort out bad structures or if the mapping tables will get worse each time.
[Galaxy Note GT-N7000 General] mmola:
I would be willing to investigate that issue. Is it possible to access the wear leveling information and debug storage state, changes in tables, etc? If yes and you can provide a link to read a bit about it, I will find my way from there.
[Galaxy Note GT-N7000 General] paralog:
Thanks for the response. I've attached the stock pit.

For me Odin gets stuck at data.img, so I guess things before that could be sane.

Also I had another question, can few of these partitions be moved to the external sd card to make this a more permanent fix?
[Galaxy Note GT-N7000 General] ourtech:
Originally Posted by mmola

The phone freezes and only a hard restart makes it come back. Usually more than one restart will be necessary until it is stable for another few hours.

Yes. This is exactly my problem. It will lock up randomly and it takes generally 3 hard resets to get it stable again. it will then be stable for a couple of days and then lock up again. I actually came back to this thread because I was going to post my problem. Note that all existing partitions pass every test that you have suggested. My personal guess/question has to do with the wear leveler and possible damage to cache. The applications that seem to lock up are those that write a great deal to cache (Chrome and News360). Cleaning the cache seems to extend the time between I have been wondering if moving the cache partition might help, but it passes repeated diagnostics as do all other partitions. Should I try a different PIT file, perhaps one that moves the cache or is the error hidden by wear leveling and there is no way to repair it? I have swapped my SD card and the Internal card and that has reduced the lockups quite a bit, but not completely. I assume though that it would reduce the partitions that are being written to down to just cache and data. Your thoughts and suggestions would be appreciated.
[Galaxy Note GT-N7000 General] mmola:
I can confirm that formatting the cache partition does indeed seem to help get the phone stable again.

Right now I am on the verge of sending the phone for servicing, but I would prefer to keep using it until the warranty is close to expiration. Might as well do some research that benefits someone while I don't give up on it.
[Galaxy Note GT-N7000 General] hg42:
One pointer to documentation might be in this post:

http://xdaforums.com/showpost.php?p=33703611&postcount=731

But I doubt you get access to the internal tables.

All those theories on xda about the emmc brick are very speculative. They are mostly derived from observations and putting the mosaic together.

We know the bug is in the wear leveler algorithm, which is in the emmc chip firmware.

Some facts and history of the bug can be found in this thread:

http://xdaforums.com/showthread.php?t=1644364
[Galaxy Note GT-N7000 General] hg42:
I don't have a clue, how such a pattern can come from the wear leveler. Especially why rebooting should help.

Perhaps next time, remove the battery and wait say 30 min.

Try, if it boots then, or still needs several resets.

Generally, if it's such a regular pattern, try to change some aspect of your behavior and see if this forces a change in the pattern.

The cache partition is not very big, I think these apps either write to /data or to the sdcard if the amount of data is big.

To find out, where the app cache is located, you may force the app to refresh it's data and then scan the partitions for the newest files, if you are able to use command line tools like 'find'.

This may help to divide the problem space.

I would assume, it's not the cache partition, but if you think so, you should try it. But you should keep your usage pattern.

I don't know...but I assume the wear leveler brings the bad structures up from time to time. I just don't get why they disappear after some reboots, because the amount of writes should be very low in the boot process.
[Galaxy Note GT-N7000 General] hg42:
Do you mean, you formatted in recovery after a freeze and then it worked without multiple resets?

This might have resulted from writing many blocks (e.g. the formatting).
[Galaxy Note GT-N7000 General] The Python™:
Good Job
[Galaxy Note GT-N7000 General] mmola:
Yes, exactly.

I also have yet to encounter the problem when cloning partitions around in recovery (e.g. using Siyah kernel to clone data from 1st to 2nd partition or vice versa). I find this very significant. I mean, if the phone is able to copy 2GB of data around with no problem at all, what's up with failing so much when in regular use, which is much less intensive.

Also, it is not common at all for the phone not to boot. Generally it boots, then fails right away when touching the screen. It is also very strange for the phone to fail while in deep sleep. I have yet to see it happen. However, turning the screen on and opening an application will trigger it most of the time. It's almost as if waking up the mmc0 controller was causing the issue. And that could be completely driver and unit-related.

I downgraded to CM9.1 a couple of days ago. The phone only failed when recovering an application from Titanium Backup. That was not so uncommon before I superbricked it. It failed again when trying to install said application from the Play Store. Then, it rebooted normally and the application was correctly installed (although the phone had frozen at 35% or so progress). After that, it has been working flawlessly for more than 48 hours now. Kernel logs show no mmc0 I/O errors as of yet.

So, from my point of view, there seems to be a software component here. Hell, it might even be that there's no hardware problem in the memory array at all (well, except for the 3GB which are obliterated). Or maybe that's what I want to see, we humans are biased pattern searching machines after all.
[Galaxy Note GT-N7000 General] BlackCl0udMY:
thanks alot of sharing your knowledge, for 20HRS i read and study your method! finally my N7000 came back to live! and yes i had only 9GB left out of 16GB.. its fun to learn as im not study in C++ (a bit hard) but finally it came to me! in my country, we said Jutaan Terima Kasih (thanks alot)..

thanks for sharing this method!

:fingers-crossed::fingers-crossed::good::good::good::good::good::good:
[Galaxy Note GT-N7000 General] ourtech:
I used your insight that it is most likely the /data partition and decided to grab the bull by the horns. Mind you, all of the partitions pass the DD test and I reran those tests before just to make sure. All pass. I then flashed a new ROM. During the process of flashing a ROM, I will generally see the installation process lock the phone up 2 or 3 times as apps are setup in the Dalvik cache (I do believe this is contained in the /data partition, which I did not previously know. Using the phone for a day it locked repeatedly, even when sitting with no apps open charging over night. I then used a new PIT file and moved the /data partition so that it is sitting in completely new space. The difference is striking. No locks while setting up apps. No locks sitting and although I have seen it lock twice, I can say that I may be able to account for the reasons for those. I can also see that there are times when I have tried operations that would have locked it in the past and it hasn't. So, am I saying that it is all fixed? Too soon. But I will say that it is definitely improved and for someone that has seriously considered sending the phone for repair, I can say that if it stays like this, I can live with it. My internal USB storage is down to 6 GB, but I couldn't really care. I have a 32GB class 10 SD card and I really don't miss the space.

If anyone cares, the ROM I used is the new JB leak from Samfirmware along with Philz safe kernel. Awesome and for me, very stable.
[Galaxy Note GT-N7000 General] mmola:
Quick question: were you using the same ROM before you changed the location of the data partition?
[Galaxy Note GT-N7000 General] ourtech:
Yes I did. for my test I originally was going to try an older GB ROM, but I deleted those some time ago, but I had the Samfirmware XXLSA ROM and I had downloaded the PhilZ XXLSA safe kernel so I thought that I would try it first. I was at the stock release of ICS XXLRT again using the PhilZ safe kernel and I used the same procedure each time. First, I wiped everything with CWM. Then I flashed the ROM and then using the default recovery I flashed the safe PhilZ kernel. After that I booted into the ROM and set it up. Lockups galore for that day and overnight while charging. Then, the following evening I booted into recovery, used ADB to get the current partition listing and then found a PIT file that moved the whole range up about 2.3 GB. Using that PIT file with the same ROM as the previous day I again flashed it. No hang ups then or even now. Perhaps one or two, but I am not sure that they are not legitimate app hangs as it did not take 3 reboots to get it up. Remarkably stable so far. . . (indicating caution here).

I was very temped to use one of the experimental PIT files that moved more up into the new range, but I wanted to try just moving the /data up. If it stays like this, I am done experimenting. I will keep you posted if anything changes. But right now I am so pleased that even when the release version of the JB ROM arrives, unless there are some very, very important improvements, I am not changing. It is that much better and the JB ROM is excellent. Seems release quality to me.

One side note. When repartitioning, partition 11, the UMS partition for the "Internal" SD card, was not created correctly and would not format. I had to go into ADB, write down the partition info, remove it and manually create it. All was good after that.
[Galaxy Note GT-N7000 General] mmola:
Yes, that has happened to me as well.

My case seems a bit different. I use two different data partitions --I have dualboot set up with Siyah. My phone locks up with mmc0 I//O errors regardless of which one I use. It has, however, stopped after downgrading to CM9.1 from CM10 nightly. I'm currently just checking how long will it go without failing, currently at 75 hours uptime. My worry is, if this is truly an issue with "degenerating" wear leveling tables, it will happen again, and soon enough. I will certainly send the phone for repairing before my warranty expires. I wouldn't do it just for the 3GB of internal SD, but I don't trust it not to get worse again.

I really don't get why Samsung doesn't just release an update for the MMC firmware and gets over this. It's just bad karma for them. As it stands now, I would avoid buying any of their cellphones, or recommending it to anyone. Unless they publicly came out and provided a repair for anyone with the superbrick, whether on warranty period or not.
[Galaxy Note GT-N7000 General] ourtech:
My understanding is that there is no easy fix for the firmware problem. I have heard that done wrong and the device is a total loss and nothing will bring it back except a main board replacement. However, I also do understand that the problem is fixable in the right hands with the correct tools. I would wish that Samsung would put the fix in the hands of repair services and let me send it it for repair. I bricked my phone while trying to root it. I took that risk and I am responsible and I am willing to pay something. But I love this phone and I don't plan on upgrading it any time soon. They ruined the form factor with the Note II and I won't sell a phone with a known defect. I may send mine in for repair if I can't resolve the lock ups, but I don't want to send it to England where I bought it. So I muddle along. I am hopeful of improvement and encourage you to try this. Please let me know if you try this. I may also wan to compare notes with you down the road to see what if any apps we may be using in common. I don't want to blame a lockup on this bug when it may just be a bad app.
[Galaxy Note GT-N7000 General] ourtech:
Well, I spoke too soon. Last night things locked up and in fact the phone would not come up stable even after 4 reboots. It may be coincidence, but I had to boot into recovery and format the cache partition to return the phone to stability. So I am back to where I started. My next effort will be to repartition using one of the experimental PIT files and try to move the cache partition. Sorry for any false hope, but now that I have moved the /data partition to a completely new area then if moving the cache partition doesn't solve anything then it is off to the repair facility as it will be apparent at that point that I will not be able to completely map out the flaws.
[Galaxy Note GT-N7000 General] mmola:
I had it fail just a while ago, after 4 days of uptime. Took the chance to verify some things:

Right after the fail, rebooted into recovery. Ran the reading tests. All OK.

Restarted phone. It froze again soon after unlocking SIM card, as usual (do you have SIM lock set up? I set that up soon before my problems started).

Rebooted into recovery, formatted cache.

Phone now running stable again.

I will PM you a list of my installed applications later in the day, see if there is any obvious culprit.
[Galaxy Note GT-N7000 General] hg42:
Nice to hear, hope it works...

(and please be so kind and shorten this big quote, or better remove it completely, the thread is already very long)
[Galaxy Note GT-N7000 General] kenny_chai_2071:
thanks very much the guide i success wake back up my note.
[Galaxy Note GT-N7000 General] hg42:
thanx for telling us.

btw. please remove this very long and unnecessary quote
[Galaxy Note GT-N7000 General] hg42:
With 'commands manual method' you mean scanning with dd?

That's why I also created the scanner recovery apps.

Also they can find the range of the brick, dd can't because it doesn't output numbers and additionally it cannot scan backwards.

Perhaps I should mention in the instruction, that dd is optional or as plan B if the others don't work.

You may see freezes from time to time, because the usual pits don't cover partitions lower than system, so your brick is not completely excluded.

You should wait, what happens, but be aware that your device may freeze (do more backups etc.).

After a while of using the device, you should scan for the brick again and note those numbers.

If it's still at 44mb and you have a n7000, you can try the 'experimental' package, but anything moving partitions lower than cache will need critical additional steps.

When moving cache, you only have to add a 'format cache' after repartitioning, I think this can be done from recovery.
[Galaxy Note GT-N7000 General] pinklips:
Super Bricked

hi

I flashed N7000_16GB_Q1_20110914--patched--brick-between-00281-and-02696-MB--FACTORYFS-moved-by-02304-MiB.pit

and start memory scan it held at 40 mb

what should I do now

thanks