PIT file method to revive your phone from a MMC_CAP_ERASE brick

Search This thread

FARSHOOD

Senior Member
Jun 4, 2009
194
14
First let me say thank you for your work has helped me bring my note back to life i was wondering is there any way to reset the binary counter

Sent from my GT-N7000 using xda premium
dear sir would you say what was your problem and now is your sd16gb full capacity is available and finally please write down step by step what did you do(procedure for repairing). thanks
 
dear sir would you say what was your problem and now is your sd16gb full capacity is available and finally please write down step by step what did you do(procedure for repairing). thanks

To be honest i tried so many different things i tried the pit file with odin then used odin to load a stock rom and my note works again b4 this nothing would work i could get into download mode flash abyss but could not load a rom now it works i lost about 7gb of internal memory but im happy it works again

Sent from my GT-N7000 using xda premium
 
  • Like
Reactions: FARSHOOD

hg42

Senior Member
i did your pit file 1024000 and recovered 8.3 GB

hmm, from what do you read that number? Do you mean the size of your internal SD?

IF I TRY ALL OF YOUR PIT FILES IS IT POSSIBLE TO RECOVER ALL OF 16GB SD

no...

let me summarize it:

* you have a phone with 16GB internal flash memory
* roughly 5 GB are used for internal partitions like /system, /data, modem, recovery etc.
* the rest of it is made available to you as internal SD (about 11 GB?)

* you bricked your phone, which damaged some blocks somewhere from the 3. to the 5. GB
* my "standard" PIT simply skips these 3 GB in the partition scheme (by not placing a partition there), so the bad blocks are not used by android
* e.g. the 1024000 PIT skips only 2 GB, so 1 GB at the end of the former data partition will be regained.

POST 98 WOULD YOU MORE EXPLAIN WHAT DO YOU MEAN AND HOW CAN I REACH TO THAT SCHEME

this is the opposite direction...
you would loose for example 1GB more than the standard scheme. This is only for people whose bricked blocks are not skipped by the my standard PIT, because they also have bricked blocks in the former UMS partition.
So these people need a bigger hole in their partition table.
 
  • Like
Reactions: FARSHOOD

nuramohammed26

Senior Member
Sep 26, 2011
277
53
zaria
I appreciate the work of Hg42 more than he realizes.thanks alot. I have read all the posts twice some 4 or 5 times but still i have a bit of a problem,my SGN came back to life:D but each time i start downloading apps from the market, the phone will freeze,if i am transferring files from my PC to the USB storage it will start normally but it will freeze halfway especially when the files are large.when am using the browser after a while the phone will also freeze,i only use N7000DDLP8_N7000ODDLP5_N7000DDLP4_HOME.tar.md5 to flash.so please kindly tell me what am doing wrong because after flashing if i enter recovery mode i don't have the option of formatting /system or /data,and i always get 9.21GB.THANK YOU
 

hg42

Senior Member
i tried the pit file with odin then used odin to load a stock rom and my note works again
...
i lost about 7gb of internal memory

with my provided PIT files it should be max. 3GB (exact: the size of the former factoryfs and datafs together).

Most people seem to think they should have an internal SD of 16GB?
This is not true, they get the remaining size after subtracting all those other partitions.

Partition scheme before implementing the workaround:

Code:
    Model: MMC VYL00M (sd/mmc)
    Disk /dev/block/mmcblk0: 15.8GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt

    Number Start End Size File system Name Flags
...
    9 281MB 1174MB -->893MB<-- FACTORYFS
    10 1174MB 3322MB -->2147MB<-- ext4 DATAFS
    11 3322MB 15.2GB --->11.9GB<---- fat32 UMS
    12 15.2GB 15.8GB 537MB ext4 HIDDEN

so you will loose 893MB + 2147MB with my "standard" patched PIT (without a number), these will not be used afterwards, as they may contain damaged blocks.

Here the numbers from the PIT (stock and patched without a number):

Code:
16GB original (Q1_20110914_16GB.pit)

FACTORYFS         548864                1744896 ->Fs
DATAFS           2293760                4194304 ->Ds
UMS              6488064 ->Uo          23232512 ->Us
HIDDEN          29720576 ->Ho           1048576

16GB MMC_CAP_ERASE brick fixed

FACTORYFS        6488064 =Uo            1744896 =Fs
DATAFS           8232960 =Uo+Fs         4194304 =Ds
UMS             12427264 =Uo+Fs+Ds     17293312 = Ho-(Uo+Fs+Ds)

these numbers are in 512 Byte blocks:

Code:
UMS was   23232512 (Us)       = 11895046144 Bytes = 11.9 GB = 11 GiB
UMS after 17293312 (Us-Fs-Ds) =  8854175744 Bytes =  8.9 GB = 8.2 GiB

(with GB = 10^9 = 1000*1000*1000 and GiB = 2^30 = 1024*1024*1024)

so you loose exactly 11895046144 - 8854175744 = 3040870400 Bytes

or simple 11.9 GB - 8.9 GB = 3 GB
 
Last edited:

FARSHOOD

Senior Member
Jun 4, 2009
194
14
hmm, from what do you read that number? Do you mean the size of your internal sd?



No...

Let me summarize it:

* you have a phone with 16gb internal flash memory
* roughly 5 gb are used for internal partitions like /system, /data, modem, recovery etc.
* the rest of it is made available to you as internal sd (about 11 gb?)

* you bricked your phone, which damaged some blocks somewhere from the 3. To the 5. Gb
* my "standard" pit simply skips these 3 gb in the partition scheme (by not placing a partition there), so the bad blocks are not used by android
* e.g. The 1024000 pit skips only 2 gb, so 1 gb at the end of the former data partition will be regained.



This is the opposite direction...
You would loose for example 1gb more than the standard scheme. This is only for people whose bricked blocks are not skipped by the my standard pit, because they also have bricked blocks in the former ums partition.
So these people need a bigger hole in their partition table.

dear sir i am confused and i have some questions

1- is my note healthy now and will work healthy after now?

2-how much capacity i have lost?

3-why i could not to gain sd by your standard patch and succeed by 1024000 pit file is it any difference which pit file to select to reach better gain or selection of all pits included has the same and 1 constant result?

4- would you please describe how many memories are included in n7000 i think there is 3 memories: 842 mb for rom installation and another 2gb for system activities and 16gb sd for programs installation and storing medias like music videos photos?

5-before 16gb internal sd damage i always saw the amount of that before installing any program= 14.9gb but you say 11gb, there is a screen shot of my present sd capacity i did not installed any program would you say what is miscellaneous files on that picture and why when i delete that 1.5gb files after deletion why it returns back and show again the already amount why can not to delete it ?
Thanks so much
 

Attachments

  • Screenshot_2012-06-01-11-48-23.jpg
    Screenshot_2012-06-01-11-48-23.jpg
    23.7 KB · Views: 301

hg42

Senior Member
1- is my note healthy now and will work healthy after now?

depends on what you call healthy.

The damaged blocks are still unusable, but because with the workaround they are not used by anyone, the phones operation is healthy.

There are people saying they have faults of different operations after that, but I think this has other reasons.

My phone currently seems to work flawlessly, but you never know.

I think, the reasons for the brick are not completely understood (at least by me), so we generally cannot be sure about the consequences.

2-how much capacity i have lost?

3 GB for the my standard PIT
2 GB for the one with 1024000 in it's name.

you should use a ROM independent tool for determining those numbers.
Each ROM has a different concept of showing those numbers.

Usually you have these kinds of memory:

1. working memory

this is RAM (not a flash memory), this is where all data and programs are really executed. The OS loads programs from the other kinds of storage (here flash, mostly disks for a PC) into the RAM before executing them.

2. system storage (FACTORYFS mounted on /system)

this is where the OS is stored, that is configuration and system programs and also system apps (which are really user visible packages of programs and their environment).

3. user storage (DATAFS mounted on /data)

there you find all data which is created after installing the OS.
This includes all apps you have installed yourself from the market.
The data partition is normally leaved intact when installing a new OS version except for so called "wipe" updates.

4. internal SD (UMS mounted on different directories in each ROM: e.g. /sdcard, /emmc)

not all phones have such a internal SD, only those with big internal flash memory, where not all flash memory is used by the system. The spare part is provided to the user as a kind of sdcard (but it is not a card!).

5. external SD (mounted on different directories in each ROM: e.g. /sdcard/external_sd, /emmc, /sdcard)

this is the real sdcard, which you can replace.

As you see above, some mount the internal to /sdcard and the external to /emmc and some mount it the opposite way.
Samsung ROMS usually use /sdcard for internal SD and /sdcard/external_sd for the external SD.

Now what is called usb storage in your screen shot? I really don't know...
Assuming you have no USB OTG adapter in use, the most reasonable thing to be reported to the user as USB storage would be the external SD because it is removable like an USB stick and users may be used to this name. But "USB" is simply a wrong name here.
Or do they mean the storage you can see, when attaching the phone as USB storage to the PC?
As you can see your internal *and* your external SD, this could be the sum of both or only one of them, but which one?

Btw. which ROM did you install?
Do you have an external SD installed?

3-why i could not to gain sd by your standard patch and succeed by 1024000 pit file is it any difference which pit file to select to reach better gain or selection of all pits included has the same and 1 constant result?

the difference between the patched-1024000.pit and the patched.pit should be exactly 1024000 kB.
That's why it is called this way.

4- would you please describe how many memories are included in n7000 i think there is 3 memories: 842 mb for rom installation and another 2gb for system activities and 16gb sd for programs installation and storing medias like music videos photos?

here, 842 MB is the /system partition as you can see in the listings in my first post.
2 GB is the /data partition and 16 GB is all partitions counted together.
Companies like Samsung tend to always tell the bigger numbers.

Btw. the space available for installing apps by the user is the /data partition.

5-before 16gb internal sd damage i always saw the amount of that before installing any program= 14.9gb but you say 11gb, there is a screen shot of my present sd capacity i did not installed any program would you say what is miscellaneous files on that picture and why when i delete that 1.5gb files after deletion why it returns back and show again the already amount why can not to delete it ?

did you have the same OS installed before the brick?
I think, you had an ICS ROM installed when you got the brick and now you're hopefully back to a GB ROM, right?
(the screen shot doesn't look like CM9)
Then it might be a concept change in between.
 
  • Like
Reactions: jamir5 and FARSHOOD

hg42

Senior Member
but each time i start downloading apps from the market, the phone will freeze

this normally goes to a download folder on the UMS partition ( aka. internal "SD", or may be to your external sdcard depending on your browser configuration)

if i am transferring files from my PC to the USB storage it will start normally but it will freeze halfway especially when the files are large

this also uses the UMS partition or the external SD

when am using the browser after a while the phone will also freeze

the cache for the browser is usually placed on UMS, too.

Assuming it's the UMS in all three cases, I would conclude you have bad blocks in your UMS partition.

That's a little bit more complicated than having the bricked blocks only in /system and /data, because the UMS is much bigger and you have to determine which part(s) of the UMS can still be used.

In a worst case scenario, for a workaround by simply repartitioning, you would need at least enough space to place the /system and the /data partitions somewhere.

The general idea in repartitioning is to place all partitions in the correct sequence and correct sizes (except UMS, which gets a different size).
This way all standard procedures work like before.
e.g. /dev/block/mmcblk0p9 doesn't change it's partition number (as the sequence is retained) and flasching an image to it still works because the size is also retained.
The UMS partition's size doesn't matter, because nobody assumes a specific size for it. 1. UMS is user land. 2. UMS also differs between 16GB and 32GB SGNs.

i only use N7000DDLP8_N7000ODDLP5_N7000DDLP4_HOME.tar.md5 to flash

hmm, isn't that an ICS ROM? then please don't flash anything in recovery or wipe anything anywhere! You will probably get a second brick.

When still on ICS you could flash a current speedmod kernel via Odin(!) (this kernel has MMC_CAP_ERASE disabled, but it's not really sure if that's enough to be safe).
Use PC Odin, because other ways use the critical kernel.
 
Last edited:

hg42

Senior Member
I have a total space of 11.07 gb does this mean I have bad blocks sorry totally novice with this

no

you wouldn't see bad blocks in those capacity numbers.

the system thinks the blocks are ok until it tries to access them.
If it are "normal" bad blocks, like from switching off the phone a clean shutdown (e.g. by pulling the battery), accesses would be detected after a timeout and should be reported somehow (not sure if you get an error dialog?), at least in the logcat.
But with those bricked blocks, the program accessing them seems to lock up.
Also, flashing partition images writes every block in a partition, so it would lock up at the point where it comes to the bad blocks.
Writing files to a partition with bad blocks will work in general until the writing process gets to the bad blocks. This is a random process, so it might work some time and then something goes wrong (download stops etc.).
So, you don't really know, if you have some bad blocks until you scanned every block in the partition. For this we can use "e2fsck -c ..." e.g. in adb which looks at each block and tries to find bad ones which it writes to a bad blocks list (which fails at bricked blocks, because unfortunately e2fsck locks up).
 
  • Like
Reactions: brockyneo

FARSHOOD

Senior Member
Jun 4, 2009
194
14
did you have the same OS installed before the brick?
I think, you had an ICS ROM installed when you got the brick and now you're hopefully back to a GB ROM, right?
(the screen shot doesn't look like CM9)
Then it might be a concept change in between.
sir b4 brick & after that i have ics lpy. in addition after brick at first i installed GB then execute your file and got ics lpy again. but again why i cannot execute your standard patch and obliged to patch via 102400 also what is your opinion about better android GB or ICS or CM and why .thanks
 
Last edited:

thasadar

Member
Jun 13, 2010
13
0
Dresden
Restored...but

Hi again!
Here is my brick-story and how this thread helped me.

*installed custom ROM, flashed under LPY CWM ->BRICK*

After searching all the corners of the Internet, starting and ending with XDA :) I found this awesome Thread.

I got the 1024000-kB PIT-> flash via Odin

Used 4pda_kernel to get CWM -> recovery menu via CWM, formatted ALL PARTITIONS that were available for formatting

Got the stock LPY (German official unbranded ICS ROM )-> flash via Odin

I managed to buy a JIG device, used the JIG to reset the Custom binary counter (The yellow triangle has been deleted automatically just by installing the Stock Rom with the included stock kernel)

Now I got a functional Galaxy Note stock ICS BUT

I don't like the fact that the phone is defective , the flash storage IS BROKEN and limiting/repartitioning is a workaround that enables me to bring it for warranty and repair.

Now, my problem with achieving that is , in recovery mode, the following text appears.

# MANUAL MODE #
--Appling Multi-CSC...
Applied the CSC-code : KOR
Successfully applied multi-CSC.


I am aware that this is a positive response but it's a relic from a flash I did using a MULTI CSC , therefor EVIDENCE .

How can I get rid of it?
Reflashing other CSC DID NOT WORK!
 

evangelism

Senior Member
Jan 16, 2008
107
7
i got the Q1_20110914_16GB-patched.pit work

with stock N7000DXLP9_N7000OLBLP6_N7000DXLP5_HOME.tar (malaysia stock)

by Odin 1.83 (as some said 1.85 problem)

i manage to revive my phone, (1st boot stuck at samsung boot animation, 2nd stock at "update 3/17", third time boot up)

i checked my storage, internal storage 1.97GB, USB storage 8.24GB

correct?
 

alucard8888

Senior Member
May 13, 2012
233
64
Paris
i got the Q1_20110914_16GB-patched.pit work

with stock N7000DXLP9_N7000OLBLP6_N7000DXLP5_HOME.tar (malaysia stock)

by Odin 1.83 (as some said 1.85 problem)

i manage to revive my phone, (1st boot stuck at samsung boot animation, 2nd stock at "update 3/17", third time boot up)

i checked my storage, internal storage 1.97GB, USB storage 8.24GB

correct?

Same thing happen to me but after i have 8.34gb usb storage and 1.97gb internal storage.. im runnin XXLQ2 ICS..
 

anthony8655

Member
Jun 2, 2012
18
2
Here's how I unbricked mine so hopefully someone can benefit from it.

I flashed the DAFUQ to get rid of the yellow triangle. That worked great. Then I flashed the ABYSSKERNEL using the PC odin trying to go to the ics lite rom. It got stuck in the start screen on reboot.

From this thread, after loading different combinations of roms and pits, no luck.

Then I read the post by bezeq, and got it to work.

http://xdaforums.com/showthread.php?t=1515379&page=3

---------- Post added at 07:41 AM ---------- Previous post was at 07:21 AM ----------

Right now, I'm down 3 GB from running this procedure. I don't believe my problem was corrupted partition. Is there a way to get back to my original partition size?
 
Last edited:

thasadar

Member
Jun 13, 2010
13
0
Dresden
Right now, I'm down 3 GB from running this procedure. I don't believe my problem was corrupted partition. Is there a way to get back to my original partition size?

Anthony, I am afraid you can't get your Note to have ALL its flash memory available. Sectors are damaged and that can't be reversed so easily (you can just avoid the corrupt regions by using these PIT files).
 

hg42

Senior Member
Same thing happen to me but after i have 8.34gb usb storage and 1.97gb internal storage.. im runnin XXLQ2 ICS..

As I said before, some ROMS call the UMS=internal SD "usb storage" (while it has nothing to do with USB! (EDIT: perhaps, because it can be mounted via USB to the PC?)).
The so called internal storage is /data

Otherwise the numbers are correct, before the brick you had about 11.9GB.

Note: the numbers simply reflect the sizes you choose with the PIT.
There's nothing that could be done wrong, that would show up in those numbers.

You see, if the blocks inside each partition are working (=not bricked) when doing one of these things:
* flashing the partition image by Odin
* formatting the partition in recovery
* formatting the partition in adb (mkfs.ext2, mke2fs, mkfs.vfat etc.)
* checking the partition's file system with
e2fsck -c /dev/block/mmcblk0p9
(-c = check bad blocks)
* reading the partition with
dd if=/dev/block/mmcblk0p9 of=/dev/null
or simply
cat /dev/block/mmcblk0p9 >/dev/null
(/dev/block/mmcblk0p9 is /system, replace with appropriate number)

If there are bad blocks one of these operations would lock up.
 
Last edited:
  • Like
Reactions: thasadar

hg42

Senior Member
i want to flash a stock ICS via PC Odin.. should i flash the patched pit again then the stock ICS... thanks

Normally you need to flash the PIT only once.

Most ROM install/update procedures don't change the partition scheme.

If the procedure uses an own PIT, then this will not work.
Then we would have to create a new patched PIT for it.
This seems to be rare.

Theoretically an update via "install zip" in Recovery like cm9 could do anything including repartitioning, but they normally don't do it, because this would break all other ROMs which rely on the stock partition scheme.
I think this would be emphasized very bold in the installation procedure.
 
  • Like
Reactions: alucard8888

hg42

Senior Member
I flashed the DAFUQ to get rid of the yellow triangle. That worked great. Then I flashed the ABYSSKERNEL using the PC odin trying to go to the ics lite rom. It got stuck in the start screen on reboot.

so you never had ICS on your phone?
So you probably didn't make any wipe or CWM restore when on ICS, which means you cannot have the kind of brick which is topic in this thread.

From this thread, after loading different combinations of roms and pits, no luck.

ok, so you are on a patched partition scheme.

Then I read the post by bezeq, and got it to work.

which means, you asked Kies to troubleshoot the connection?

Right now, I'm down 3 GB from running this procedure. I don't believe my problem was corrupted partition. Is there a way to get back to my original partition size?

well...just
* make a complete backup of the affected three partitions
e.g. system + data via a nandorid backup
internal SD by copying all files to the PC
* flash a stock PIT (in my pits.zip you find two PITs without "patched" in their names, these are the stock PITs)
* restore your backup

The backup is needed because repartitioning doesn't move the data inside the partitions, it only sets some numbers in the partition table where each partition begins and how long it is etc. So the file systems insides are meaningless afterwards.

Additionally, I recommend to also make a backup of the external SD, because if you format the internal SD after repartitioning, this could eventually format the wrong SD (ROMs and Recoveries sometimes use different or wrong names for them, eg. the current cm9 recovery calls the external SD "internal SD").

Or, much easier, you could simply remove the external SD before formatting the internal SD.
 
  • Like
Reactions: anthony8655

Top Liked Posts

  • There are no posts matching your filters.
  • 222
    Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.

    Note: This thread is rather old now (2012).

    Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
    • an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
    • wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
    • most important: an older emmc chip (or firmware).
      All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
      Some insights here (as part of this thread)

    after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
    In case only one of the conditions is not true, the brick should not happen.

    So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.

    So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.

    Especially, all current roms or recoveries should be safe.

    If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.

    So in most cases, don't look here, unless you are using rather old devices and rather old software.




    Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
    Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.


    Note: You should generally post in the correct thread (please look in my signature)

    Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).


    It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
    Please, please, please:

    Read this multiple times and try to understand all aspects before using anything of this thread.

    If you have questions, read it again!
    If you have questions, read it again!
    ...
    If you have questions, read it again!
    If you have questions, read it again!

    If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).

    If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.


    If you have questions, read first post again and again and also read the whole thread!
    Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
    Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
    It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
    Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...


    Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...

    You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.


    -------------------- manual method and tools for using adb

    I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
    Along the way our threads started to be companions to each other.

    forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.

    But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
    It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
    However, the manual method can do more, especially if you have special cases.


    -------------------- find begin and end of bricked area

    You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
    You should write down two numbers:
    * where emmc_find_brick_start.zip freezes -> BRICK_START
    * where emmc_find_brick_end.zip freezes -> BRICK_END

    I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).


    -------------------- patched pit files

    I finally hacked a perl script, which generates a set of PIT files for me.

    But because I cannot test the PITs on my phone (because I need it):
    ==> NO GUARANTY <==

    Say you have a situation like this:

    Code:
    before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
                     ^        ^
                     |        |
           BRICK_START        BRICK_END
    (? = bad blocks)

    The repartitioning should leave a hole in the partition table around the bricked area.
    Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.

    Code:
    before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
    after:  ...-|    ?  ??   ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
                 \            /
                  ------+-----
                        |
                       HOLE
    (? = bad blocks)

    The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:

    Code:
    16GB original (Q1_20110914_16GB.pit)
    
    FACTORYFS         548864 ->Fo           1744896 ->Fs
    DATAFS           2293760 ->Do           4194304 ->Ds
    UMS              6488064 ->Uo          23232512 ->Us
    HIDDEN          29720576 ->Ho           1048576 ->Hs
    
    16GB MMC_CAP_ERASE patched
    
    FACTORYFS        FoX = Fo+X             unchanged
    DATAFS           DoX = Do+X             unchanged
    UMS              UoX = Uo+X             UsX = Us-X
    HIDDEN           unchanged              unchanged


    The PITs are named like that:

    N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB

    This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.

    Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.

    So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB

    Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
    So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB

    In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
    The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
    Therefore the following partitions (only HIDDEN in this case) remain unchanged.
    All partitions before the first moved partition (FACTORYFS) remain also unchanged.

    I recently added more starting partitions for the brick (XXX-moved-by-...).
    As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
    All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.

    Code:
    case FACTORYFS-moved-by-...
    
    before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
    after:  ...-|    ?  ??   ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
                 \            /
                  ------+-----
                        |
                       HOLE
    
    case DATAFS-moved-by-...
    
    before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
    after:  ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
                             \   /
                              -+-
                               |
                              HOLE
    (? = bad blocks)


    The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
    If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
    For all other partitions, you have to format those partitions, before you can use them.
    At least the data partition should be formatted

    The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
    You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).


    ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.

    I also had the following problem:
    I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
    This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
    So, you may want to create a backup of your external sdcard first.
    Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
    Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).



    -------------------- backup

    before messing with the partition table, everyone should make backups of all partitions that can be accessed.


    -------------------- efs backup

    The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.

    For most supported phones, you can do this via adb:
    Code:
    dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
    please look at forrest1971's thread for details about using adb.

    If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
    Perhaps you have to mount your sdcard first, to be able to save it there.
    Then you should copy the backup to your PC (the recovery should have the option to mount usb).


    -------------------- backup files from internal sd before repartitioning

    the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
    You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.

    * you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).

    For the following possibilities you should first ensure, you have a working recovery with working adb support.
    Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.

    * you can use QtAdb to copy files to your PC:

    * you can use adb pull to copy any files or directory tree to your PC, e.g.:
    adb pull /emmc/. emmc

    * you can use tar from adb to archive files to a file on sdcard:
    adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.

    * you can use a copy command in adb shell to copy files to a folder in sdcard:
    adb shell cp -ra /emmc/. /sdcard/emmc.backup
    Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
    This may matter for system and some app related files.


    -------------------- recommended procedures for "standard" cases

    "standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
    All other partitions need special considerations and are not handled in this section!

    Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
    Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
    So be "careful with that axe, Eugene!"

    Note, there are always multiple ways to reinstall the phone.


    phase "find brick"
    * reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
    * flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
    * flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END

    phase "flash pit and ROM"
    * (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
    * flash a patched PIT in Odin
    * flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)

    phase "check partitions"
    * reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
    * check the partitions (see section "checking all partitions" below)

    phase "restore partitions"
    * switch off the phone (something like "power off" in recovery)
    * remove external sdcard (to be sure not to format it afterwards)
    * boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
    * format cache
    * format data
    * format internal SD (if it fails read below)

    phase "start ROM"
    ...


    After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).

    You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
    I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
    Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).

    It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).

    A second method is via recovery using a custom kernel:

    phase "find brick" like above

    phase "flash pit and kernel"
    * (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
    * flash a patched PIT in Odin
    * flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)

    phase "check partitions" like above

    phase "restore partitions"
    * switch off the phone (something like "power off" in recovery)
    * remove external sdcard (to be sure not to format it afterwards)
    * boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
    * format system
    * format cache
    * format data
    * format internal SD

    phase "install ROM"
    * install the zip of the ROM

    phase "start ROM"
    ...


    So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
    This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
    For some partitions this can be done by a simple format (cache, data, internal sd).
    Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).

    In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
    EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
    I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).

    You may find other important information in the thread, please read it completely before asking the same things over and over again.

    There may also be useful information and experiences from users.
    I try to incorporate useful information in the thread starter, but my time is often very limited.
    Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.

    ...suggestions or corrections welcome!...


    -------------------- checking all partitions for bricked blocks

    After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).

    Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.

    So you should check all your partitions after repartitioning to be sure.

    With both methods below, you can check the partitions even before formatting any of them.

    You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).

    You can also do it manual via dd commands in adb, but this is much slower.
    Use commands like this, using the partition block device in the if=... argument:

    adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
    adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
    adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
    ...
    adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
    adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
    adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
    etc.

    If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.


    -------------------- pit.str for DataWorkshop

    For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
    The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
    Please ask (PM), if you are interested in this.


    -------------------- PITs for other devices

    Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
    Look at the attached files, which devices are currently available.
    If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
    I'll look what I can do...

    I will add comments for special cases below.


    -------------------- device i9250 - experimental PITs

    I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
    I added this especially for Shanava, who said to be able to recover even from a hard brick.
    His brick is in userdata.
    So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
    But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.


    -------------------- devices not supported/supportable

    i9000, i9300 (and similar):
    These devices have a different PIT structure.
    The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
    Inserting an unused partition changes the partition numbers after it, which shouldn't work.


    -------------------- FOR-EXPERTS-ONLY packages

    DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
    These packages contain files to be used by those who have special problems and want to take the risk to try them.
    They are only documented by the corresponding discussion (somewhere in this thread).





    note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
    Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.
    21
    Repartitioning around the bad blocks

    This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.

    -----------------------snip -------------------------------------
    Hi everyone, especially those with an ICS brick,

    last week I jumped straight into a MMC_CAP_ERASE brick.
    Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
    But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".

    Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.

    But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.

    So I got the BRICK!

    After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...

    (this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here :) sorry, my fault)
    ---- cut ----

    This is a rewrite in english of my report at a german forum:
    ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
    www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html

    My brick created bad blocks in the phone's flash memory.
    I got I/O-Errors when attempting to read or write those blocks.

    My SGN was still able to boot into recovery and all kinds of kernels/recovery.
    Odin was able to flash boot loaders, kernels, modems and CSCs.
    But flashing a factory_fs stopped at the very beginning.

    I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.

    For all of the following I needed access to some tools (mainly e2fsck and parted).
    As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
    The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
    I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
    You may use the tools from forrest1971, see below under "manual method".

    One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
    e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
    This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
    I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.

    At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:

    Code:
    before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
    after:  + ...-|    ?       ??      |-FACTORYFS-|-DATAFS-|-UMS---------------|...
    (? = bad blocks, + working, - = not working still bad blocks inside)

    In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
    So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).


    Here is a log of my steps (but see below in the blue sections for other probably easier procedures):

    Code:
    I managed to access the device via [I]adb shell[/I]...which is another story for itself...
    
    Then I started [I]parted[/I] with the flash device:
    
    ~ # parted /dev/block/mmcblk0
    parted /dev/block/mmcblk0
    GNU Parted 1.8.8.1.179-aef3
    Using /dev/block/mmcblk0
    Welcome to GNU Parted! Type 'help' to view a list of commands.
    (parted) print
    print
    print
    
    
    As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
    [QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
    This might mean that another operating system believes the disk is smaller.
    Fix, by moving the backup to the end (and removing the old backup)?
    Fix/Ignore/Cancel? f
    f
    f
    Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
    used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
    continue with the current setting?
    Fix/Ignore? f
    f
    f
    
    
    this was the partition scheme before implementing the workaround:
    
    Model: MMC VYL00M (sd/mmc)
    Disk /dev/block/mmcblk0: 15.8GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    
    Number Start End Size File system Name Flags
    1 4194kB 25.2MB 21.0MB ext4 EFS
    2 25.2MB 26.5MB 1311kB SBL1
    3 27.3MB 28.6MB 1311kB SBL2
    4 29.4MB 37.7MB 8389kB PARAM
    5 37.7MB 46.1MB 8389kB KERNEL
    6 46.1MB 54.5MB 8389kB RECOVERY
    7 54.5MB 264MB 210MB ext4 CACHE
    8 264MB 281MB 16.8MB MODEM
    9 281MB 1174MB 893MB FACTORYFS
    10 1174MB 3322MB 2147MB ext4 DATAFS
    11 3322MB 15.2GB 11.9GB fat32 UMS
    12 15.2GB 15.8GB 537MB ext4 HIDDEN
    
    
    then I deleted the partitions 9=FACTORYFS=/system,  10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
    
    (parted) rm 11
    (parted) rm 10
    (parted) rm 9
    (parted) mkpartfs primary ext2 3500 4400
    (parted) mkpartfs primary ext2 4400 7000
    (parted) mkpartfs primary fat32 7000 15.2G
    (parted) name 9 FACTORYFS
    (parted) name 10 DATAFS
    (parted) name 11 UMS
    
    now I upgraded both new ext2 partitions to ext4:
    
    ~ # tune2fs -j /dev/block/mmcblk0p9
    tune2fs -j /dev/block/mmcblk0p9
    tune2fs 1.41.11 (14-Mar-2010)
    Creating journal inode: done
    This filesystem will be automatically checked every 30 mounts or
    0 days, whichever comes first. Use tune2fs -c or -i to override.
    ~ # tune2fs -j /dev/block/mmcblk0p10
    tune2fs -j /dev/block/mmcblk0p10
    tune2fs 1.41.11 (14-Mar-2010)
    Creating journal inode: done
    This filesystem will be automatically checked every 30 mounts or
    0 days, whichever comes first. Use tune2fs -c or -i to override.
    ~ # e2fsck -fDp /dev/block/mmcblk0p9
    e2fsck -fDp /dev/block/mmcblk0p9
    /dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
    ~ # e2fsck -fDp /dev/block/mmcblk0p10
    e2fsck -fDp /dev/block/mmcblk0p10
    /dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
    
    
    and this is the final partition layout:
    
    ~ # parted /dev/block/mmcblk0 print
    parted /dev/block/mmcblk0 print
    Model: MMC VYL00M (sd/mmc)
    Disk /dev/block/mmcblk0: 15.8GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    
    Number Start End Size File system Name Flags
    1 4194kB 25.2MB 21.0MB ext4 EFS
    2 25.2MB 26.5MB 1311kB SBL1
    3 27.3MB 28.6MB 1311kB SBL2
    4 29.4MB 37.7MB 8389kB PARAM
    5 37.7MB 46.1MB 8389kB KERNEL
    6 46.1MB 54.5MB 8389kB RECOVERY
    7 54.5MB 264MB 210MB ext4 CACHE
    8 264MB 281MB 16.8MB MODEM
    9 3500MB 4400MB 900MB ext3 FACTORYFS
    10 4400MB 7000MB 2600MB ext3 DATAFS
    11 7000MB 15.2GB 8217MB fat32 UMS msftres
    12 15.2GB 15.8GB 537MB ext4 HIDDEN
    
    This configuration works so far (one complete day now).
    I can install firmwares and restore backups via recoveries.
    Also flashing via Odin should work (not tried yet).
    I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
    I think/hope this will not occur too often...
    9
    :) -- naturally, it's much faster to insert those short messages than rewriting a long german post in english.

    Next time I should write the main text prior to posting anything, I think...

    sorry...
    4
    Interesting...

    Most notes are bricked in the factoryfs and the datafs.
    Looking for a reason I noticed, that our factoryfs start in a range where you have datafs. My brick starts in the range 950MB-1GB.

    So there is a chance, the brick is always at certain addresses.

    But not all have the same ranges. For the note, there seem to be bricks in the ums, too. I guess a brick address could be calculated from an access address by some kind of alignment operation?

    Anyway, your pit is very similar to ours, so it should be easy to generate a patched one. I just have to think about how to generalize this. I think there will be more requests like this.
    4
    Flashed your pit.
    Flashed SGN_XX_OXA_KJ1_FACTORYFS.tar worked no stuck on NAND Write.
    Flashed CF-Root-SGN_XX_OXA_LA4-v5.0-CWM5.tar
    Installed XXLC1_CheckROM_NoteHD_V6.zip using CWM.

    now, at least, you should have wiped the data partition...which you catched up afterwards...

    Stucked at Wizard, retried a couple of times and passed wizard.
    Now everything Force Closed, after some minutes manages to go to Settings > Privacy > Factory Data Reset
    Check Format USB Storage

    Ok, thanks, so the wizard problem comes from having an unformatted data partition.

    But why formatting USB-storage?
    I heard there are ROMs which call the external sd "USB storage"?
    I think, probably Factory Reset (which should be more or less equal to "wipe /data" or "format /data") should be enough here.

    And now is working fine no more FC.

    nice

    i only have 8 Gb internal space.
    Is there a way i can revert my phone to original state, fix the bad blocks and have 12 gb internal space like before???

    Note: this is a work around, it's not a real fix.
    Your internal flash memory has bad blocks, and from what I know no one managed to repair them. So most people probably should ask Samsung for repair service (on guaranty).
    The fix works by moving the old /system and /data into the start of the UMS partition (internal sd) and therefore shrinking the internal sd by about 3GB.

    don't update youtube from play store, bcoz the update will FC
    a lil laggy.

    this should be unrelated to my workaround.

    May be your internal sd is still unformatted?
    Can you see files on it?