PIT file method to revive your phone from a MMC_CAP_ERASE brick

Search This thread

hg42

Senior Member
Generally, please try simple configurations first. Experiments with ROMs, kernels, modems etc. should wait until the phone is proven to work well.

By reviving your phone you don't solve all other problems in the world.

So keep on a secure path until you are sure to have a working phone again.
To be really sure you can try proven ROMs first, e.g. stock GB.

But please avoid fancy ROMs and kernels for this first phase.
They often introduce new problems which you may account to the brick.

Solve one problem at a time. Then the next...

CM9 has it's problems, too, but if you don't use the latest nightlies you have a chance to know of them (e.g. via the xda discussion thread about this). CM9 prioritizes functionality over fancy features. Other ROMs are often very experimental. It's also a matter of how many users test the ROM.
 

hg42

Senior Member
There is no IMEI !!!!!!! .. I think I formatted the efs partition in one of my tries to get the phone back ..
What can I do now??

I checked the efs folder form root explorer and it was empty .. dialed *#06# and that shows nothing .. please help me .. I feel that I'm extremely stupid

Do you have a backup (e.g. any backup done with a thor kernel will include the efs, but not a cwm backup)?
Otherwise you have a big problem.
There are discussions about that, read there.
I think you can install a generic efs, but I don't know if you can restore your IMEI and which consequences a missing IMEI may have.
 
Last edited:

MohElShafei

Senior Member
Jul 2, 2011
112
12
Cairo
unfortunately I don't have a backup :crying::crying::crying::crying:
I searched a lot for generic efs .. but I didn't find anything .. do you know from where I can get these files?? ..
I know I cause a lot of problems and I burden you with my questions a lot ... I'm extremely sorry for that .. the only solution for me now is to recover this generic efs ... please help me getting these files ..
 

Morality

Member
Mar 23, 2011
29
0
Hämeenlinna
Your first bad block is in the system partition, so it's not the cache (what I guessed).

Your case is very difficult.
From current facts I can only guess the freezes may be unrelated to the brick.

There are other issues leading to freezes, e.g. restoring via Titanium Backup not always working well depending on how it's configured.

So at best I would make a clean start with pure cm9 rc1 and install only the minimum set of apps (try to use only cm9 internals and gapps if possible) and without any app data restored.
Try that several days. Then install some other apps known to work well (e.g. I would not install games).

Well hot Damn. Ill make sure that is my next Step :) will report back afterwards.

Sent from my GT-N7000 using XDA
 

hg42

Senior Member
unfortunately I don't have a backup :crying::crying::crying::crying:
I searched a lot for generic efs .. but I didn't find anything .. do you know from where I can get these files?? ..

Just from my memory, I am currently at work, so can't look in my archives.

I think the KL8 stock ROM from samfirmware is an unofficial multipart package including efs ums etc.
Don't install the complete package as it would erase things you may not want to (e.g. ums).
Take only the efs image... I think you can flash this from Odin (but don't know how).

Here is a link to a video (but for another phone) I found which includes some interesting links:

Samsung Galaxy S (IMEI Restoration Techniques) - YouTube

So the IMEI can probably be patched.

I could compare the generic efs with mine, to find the position of the IMEI.
I'll look into it this week end I think.

Perhaps we need another thread then...
 

theunborn

Member
May 21, 2009
35
0
ok thanks hg42,
yeah i know i will have to dump 3gb more so i chose to reset the counter and ask for a guarantee instead,.... anyway thanks for the guide, im still looking around to learn more just in case if it happens again.

Sent from my GT-N7000 using xda premium
 

hg42

Senior Member
I created new PITs
- regain in 256MB steps (instead 100MB before)
- one zip for each device

I also added Epic4GT files, which move DATAFS (on N7000 FACTORYFS and DATAFS are moved).

I can now easily add other devices, as long a this scheme fits:

* there is a big partition which can be shrinked (internal sd, UMS)
* the bricked partitions are located in front of the UMS partition
* I need to know the first bricked partition name (=start) and the UMS partition name (=big)

The algorithm is as follows:

Code:
* calculate the number of blocks the first partition has to be moved (=[b]offset[/b])
* from the [B]start[/B] partition to the [B]big[/B] partition
     * move partition start by [b]offset[/b] blocks
* reduce size of [b]big[/b] partition by [b]offset[/b] blocks

Note: I do not test any PITs, so I cannot guarantee for anything, especially for different devices
I am not a developer with many devices, I am a developer but not for phones, I have only one device, which I cannot use for experiments!
 
Last edited:
  • Like
Reactions: garwynn

Shanava

Member
Jun 22, 2012
11
1
I looked into this today.
Your PIT is very different.
Which partitions are usually damaged by the brick?
Where do you have bad blocks?
Generally I don't know anything about your phone.
Especially the partition sequence is much different, I have no clue how a patched PIT would affect other partitions.

Code:
PIT file partition-table-0915.pit

id	offset		size		name		filename
0	0 kB		0 kB		gang		emmc.img
1	0 kB		0 kB		gptder		partition-table.img
2	0 kB		0 kB		xloader		xloader.img
3	0 kB		0 kB		sbl		sbl.img
4	4096 kB		20480 kB	efsory		efs.imgimg
5	24576 kB	8192 kB		param	
6	32768 kB	4096 kB		misc	
7	36864 kB	4096 kB		dgs	
8	40960 kB	8192 kB		boot		boot.img
9	49152 kB	12224 kB	recovery	recovery.img
10	61440 kB	16384 kB	radio		radio.img
11	77824 kB	669696 kB	system		system.img
12	747520 kB	442368 kB	cache		cache.img
13	1189888 kB	15587328 kB	userdata	userdata.img
14	16777216 kB	0 kB		efs-cdma	efs-cdma.img
15	16777216 kB	0 kB		radio-cdma	radio-cdma.img
16	0 kB		0 kB		bootloader	bootloader.img
17	61376 kB	64 kB		metadata

I am especially puzzled by the partition-table.img and those partitions following userdata.

Sorry, I think, you should better use parted method (like user forest1971).
Or you find someone, who knows your phone and understands it's PIT.
I can help with what I know, though.

Hi Dear hg42
Phone hang on Flashing by Odin When Write "UserData.rfs"

----------------
This is the third my phone,Bricked eMMC
I Have Still I9000 and I9003....

So,if You Need More Info About That,Please Tell me...
Don't Worry About Hard Brick,Becuase i Have OmapFlasher For repair I9003 and I9250 Without JTAG,,,Only By USB....

Thanks
Best/Regards
 

MohElShafei

Senior Member
Jul 2, 2011
112
12
Cairo
Just from my memory, I am currently at work, so can't look in my archives.

I think the KL8 stock ROM from samfirmware is an unofficial multipart package including efs ums etc.
Don't install the complete package as it would erase things you may not want to (e.g. ums).
Take only the efs image... I think you can flash this from Odin (but don't know how).

Here is a link to a video (but for another phone) I found which includes some interesting links:

Samsung Galaxy S (IMEI Restoration Techniques) - YouTube

So the IMEI can probably be patched.

I could compare the generic efs with mine, to find the position of the IMEI.
I'll look into it this week end I think.

Perhaps we need another thread then...

Thank you a lot hg42 for your continuous support .. I will wait your response regarding to your IMEI .. but just a question, if I took any efs backup files from another Note.. is that will work for my phone? or it will not??

I searched and I found that I can use Z3X BOX Samsung Tool to re-flash my IMEI, but this require a cervices center having the box itself .. I think I can use it. I will see if there is any Mobile maintenance center with Z3X Box so I can use it restoring my IMEI .. meantime I will still wait your response regarding to your IMEI. Maybe the simplest solutions is the best.

Thanks a lot .. you are the best.

Mohamed
 
Last edited:

KnukLHead

Senior Member
Feb 24, 2012
415
176
Emmet Ar
I had resurrected a e4gt with the older pit file and eg30. When I connected it to wifi it tried to update via ota. After that it was screwed again and kept telling me the update failed and to connect it to kies. I then used your e4gt.pit and eg30 and it passed but now its bootlooping.

Sent from my SPH-D710 using xda premium
 

KnukLHead

Senior Member
Feb 24, 2012
415
176
Emmet Ar
Booted it into recovery and did a factory wipe. It booted right up. I know my situation was differ ant then the regular brick cause I had already brought it back once with the .pit from the note but its working fine now. Internal storage space is at 9.5gb. Device memory is 1.9gb

Sent from my SPH-D710 using xda premium
 

MohElShafei

Senior Member
Jul 2, 2011
112
12
Cairo
Dear hg42,

I can't find enough words to thank you for the amazing support you did to me .. I managed to bring my Mobile Network to life using the EFS.Image from the KL8 stock ROM you advised.

I downloaded the ROM, and I found the EFS.Image, flashed it with Odin, and the Network just come back to life :laugh::laugh::laugh:

I was really hopeless and I really was about to sell my mobile as spare parts for 80$ or less, but after your amazing answer I said to myself I should give the GNOTE a last chance .. and you was amazing :D, you made it work again.

I'm really happy and all thanks back to you and to your amazing support .. if I know your place I would send you a big big present :) :) :).

I will keep my situation as I'm right now till any news comes from SAMSUNG side about the bug fix .. I will NEVER NEVER NEVER try anything with the Mobile again .. and thanks to GOD that it is still work till now after all the things I did to it (the counter is almost 240) :cyclops:

Thank you again and again .. and wish you all the happiness in the word :)

Mohamed
 
Last edited:

hg42

Senior Member
@KnukLHead: the e4gt has different partition sizes than the n7000.
So flashing partition images can only work if the partitions are bigger than the images.
OTA might check some things before flashing.
So I guess you need correct partition sizes.
Please check all your partitions with dd, at least starting from system.
 
Last edited:
  • Like
Reactions: KnukLHead

hg42

Senior Member
I downloaded the ROM, and I found the EFS.Image, flashed it with Odin, and the Network just come back to life :laugh::laugh::laugh:

nice, but note that you now have a generic (developer?) IMEI.
So you should probably change it to your original number (but I currently don't know how, it's a secret, xda doesn't discuss this, most references are to xxx boxes).
I think you have your original IMEI on a sticker, right?
 
Last edited:
  • Like
Reactions: MohElShafei

hg42

Senior Member
donations...

I'm a bit sorry for doing that, but I now added a donation button to my profile.

Generally, I like the idea to help people to revive their phone or help them in other ways without asking for any kind of donation.

But -- since starting this thread it has taken all my weekends and many of my evenings. It was always a little difficult to justify this to my family etc. and we have reached a somewhat critical point now.

So if it is possible to get some money out of it, I can take some time out of my other business instead and my family members especially the children get their time, too.

Thanks...
 
Last edited:

hg42

Senior Member
I renamed the thread (until now, I didn't know I can).

I also added very experimental PITs for i9250 (especially for Shanava).
Please wait until proven to work well by Shanava.

Shanava, please make a backup of your efs first.
I think you can do via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
perhaps you have to mount your sdcard first.
Then you should copy it to your PC (the recovery should have the option to mount usb)
 
Last edited:
  • Like
Reactions: MohElShafei

hg42

Senior Member
@Shanava (or other i9250 owners):

can you confirm the partition numbers listed in the first column of this table:

attachment.php


or better post a partition table:

Code:
parted /dev/block/mmcblk0 print
 

Attachments

  • i9250_0915-stock-pit.png
    i9250_0915-stock-pit.png
    27.2 KB · Views: 594
  • Like
Reactions: MohElShafei

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?