PIT file method to revive your phone from a MMC_CAP_ERASE brick

[nip123]

HI provide me information please

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 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:

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.

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:

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.

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:

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.

Hi im trying the pit method through cwm,
where emmc_find_brick_start.zip freezes came out to be BRICK_START 39MIB = 41MB
im still scanning for where emmc_find_brick_end.zip freezes -> BRICK_END ,
my question is since it starts with 41MB should i use one of the expert PIT files? or should i try the ADB method?

 

[hg42]

Hi im trying the pit method through cwm,
where emmc_find_brick_start.zip freezes came out to be BRICK_START 39MIB = 41MB
im still scanning for where emmc_find_brick_end.zip freezes -> BRICK_END ,
my question is since it starts with 41MB should i use one of the expert PIT files? or should i try the ADB method?

(note I usually don't read the thread any more, because I have a note3 now)

41 MB means starting the gap at the KERNEL partition beginning at 37MB.
This should work well, but the pit is in experimental because:
- I don't have any feedback if this works well and which problems may appear
- you have to format the CACHE partition to get it up and running

formatting CACHE shouldn't be a big problem, you only need a custom recovery for that.
So after applying the pit, you flash CACHE and UMS.

btw.
everything below 29MB should be nearly impossible to fix (boot loaders affected).
below 37MB could work but I don't know anything about the affected PARAM partition and how to restore it.
From what I remember there is not much data in it.
May be it's not critical, may be it's trivial to restore.
But at least *I* do *not* know.
There could be hidden data on it, or something like that.

 

[Stefan2142]

Is there a way to run this in download mode? Because I can't get into recovery on my i9100.

---------- Post added at 12:46 PM ---------- Previous post was at 12:35 PM ----------

I provided this already in the new i9100-jb4.1 package.
Along with increasing the size of FACTORYFS, they also reordered the partitions, so you will not find a direct replacement/equivalent to your successful pit.
Just choose a fitting file from the new package.

Notes:
The loss is always < 1/4 GB compared with an optimal (hand-made) pit (the end is moved in 1/4 GB steps).
The loss in front of the brick cannot be optimized, the value depends on the partition start.
The gap can only start at the beginning FACTORYFS, DATAFS, etc.

I think I will rename the package to something like SHW-M250K_jb4.1 according to the info in your post (thanks!), but I have no spare time currently.

Is there a way to use this in download mode? because I can't enter recovery mode nor I can flash it in odin or heimdall. I can't flash zImage, cache.img, factoryfs.img, hidden.img, modem.bin, sbl.bin. The only files I can flash via Heimdall are boot.bin and param.lfs.

 

[hg42]

Is there a way to run this in download mode? Because I can't get into recovery on my i9100.

---------- Post added at 12:46 PM ---------- Previous post was at 12:35 PM ----------


Is there a way to use this in download mode? because I can't enter recovery mode nor I can flash it in odin or heimdall. I can't flash zImage, cache.img, factoryfs.img, hidden.img, modem.bin, sbl.bin. The only files I can flash via Heimdall are boot.bin and param.lfs.

should be obvious, if you really read the first post...or think a little bit about how a pit file could be applied, right?

 

[Stefan2142]

I provided this already in the new i9100-jb4.1 package.
Along with increasing the size of FACTORYFS, they also reordered the partitions, so you will not find a direct replacement/equivalent to your successful pit.
Just choose a fitting file from the new package.

Notes:
The loss is always < 1/4 GB compared with an optimal (hand-made) pit (the end is moved in 1/4 GB steps).
The loss in front of the brick cannot be optimized, the value depends on the partition start.
The gap can only start at the beginning FACTORYFS, DATAFS, etc.

I think I will rename the package to something like SHW-M250K_jb4.1 according to the info in your post (thanks!), but I have no spare time currently.

should be obvious, if you really read the first post...or think a little bit about how a pit file could be applied, right?

Pardon me, I am up for 20+ hours here trying to find a solution. I know that what I meant is: Is there a way to find out do I realy have bad sectors with only download mode available?

 

[hg42]

Pardon me, I am up for 20+ hours here trying to find a solution. I know that what I meant is: Is there a way to find out do I realy have bad sectors with only download mode available?

ok...sorry
So, perhaps you should sleep some hours, because you need full concentration for this kind of procedures...

Generally, if you cannot use a recovery, you should try some pits with higher gap sizes to get your phone up and running (you may use one of the highest first to see if the phone boots), then install and use a custom recovery to scan.

Gap start should be below the start of the first partition that could not be flashed.

But...

I don't know much about sbl.
I think, this is a boot loader and will probably have a critical role in the boot process.

So it's a bit more difficult than the standard procedure (and I never tried this one).

The pits should allow you to move sbl out of the bricked zone.
But you have to restore the contents of sbl to be able to boot.
You said you tried to flash sbl so you seem to have the necessary file.

Remember: you have to restore all partitions, that are moved by the particular pit file.

 

[Stefan2142]

ok...sorry
So, perhaps you should sleep some hours, because you need full concentration for this kind of procedures...

Generally, if you cannot use a recovery, you should try some pits with higher gap sizes to get your phone up and running (you may use one of the highest first to see if the phone boots), then install and use a custom recovery to scan.

Gap start should be below the start of the first partition that could not be flashed.

But...

I don't know much about sbl.
I think, this is a boot loader and will probably have a critical role in the boot process.

So it's a bit more difficult than the standard procedure (and I never tried this one).

The pits should allow you to move sbl out of the bricked zone.
But you have to restore the contents of sbl to be able to boot.
You said you tried to flash sbl so you seem to have the necessary file.

Remember: you have to restore all partitions, that are moved by the particular pit file.

Yeah, I should probably get some sleep because I have made one more mistake. I said there that I can't flash sbl.bin file. Well I can, I made a mistake.
So, which one would you recommend me to try with..? Because there are 300+ files and I not too familiar with this method, so I don't know which file with the right gap should I use.
And one more thing. Should I try to flash only .pit file first or should I try to flash whole rom alltogether with .pit file in one command?

 

[Stefan2142]

ok...sorry
So, perhaps you should sleep some hours, because you need full concentration for this kind of procedures...

Generally, if you cannot use a recovery, you should try some pits with higher gap sizes to get your phone up and running (you may use one of the highest first to see if the phone boots), then install and use a custom recovery to scan.

Gap start should be below the start of the first partition that could not be flashed.

But...

I don't know much about sbl.
I think, this is a boot loader and will probably have a critical role in the boot process.

So it's a bit more difficult than the standard procedure (and I never tried this one).

The pits should allow you to move sbl out of the bricked zone.
But you have to restore the contents of sbl to be able to boot.
You said you tried to flash sbl so you seem to have the necessary file.

Remember: you have to restore all partitions, that are moved by the particular pit file.

Doesn't even matter Odin won't even flash .pit file

 

[hg42]

Doesn't even matter Odin won't even flash .pit file

oh, wow, I never heard of such a situation.

You first mentioned Heimdall and now Odin, so you really used Odin now?

I have mixed experiences with Heimdall, so I would recommend Odin.
Are you sure Odin works generally? you could eventually have driver problems.
There may be other reasons for a non working Odin.

As I said, you have to restore (at least the critical) partitions, before you reboot.
All that has to be done via Odin or Heimdall, if you don't have a working custom recovery.

You should definitely read (and understand) my thread starter before you try to flash a pit.
I generally assume you are familiar with these tools (Odin etc.). Otherwise read more in other threads.
There are definitely too many possible situations, which I cannot cover in this thread.

What is the history of your brick? Did you really use an ICS-kernel?
I'm asking because the emmc brick only occurs in some combinations of software.
Newer software shouldn't trigger this bug.
Without having used an ICS-kernel you would probably have a very different problem.

 

[Stefan2142]

ok...sorry
So, perhaps you should sleep some hours, because you need full concentration for this kind of procedures...

Generally, if you cannot use a recovery, you should try some pits with higher gap sizes to get your phone up and running (you may use one of the highest first to see if the phone boots), then install and use a custom recovery to scan.

Gap start should be below the start of the first partition that could not be flashed.

But...

I don't know much about sbl.
I think, this is a boot loader and will probably have a critical role in the boot process.

So it's a bit more difficult than the standard procedure (and I never tried this one).

The pits should allow you to move sbl out of the bricked zone.
But you have to restore the contents of sbl to be able to boot.
You said you tried to flash sbl so you seem to have the necessary file.

Remember: you have to restore all partitions, that are moved by the particular pit file.

oh, wow, I never heard of such a situation.

You first mentioned Heimdall and now Odin, so you really used Odin now?

I have mixed experiences with Heimdall, so I would recommend Odin.
Are you sure Odin works generally? you could eventually have driver problems.
There may be other reasons for a non working Odin.

As I said, you have to restore (at least the critical) partitions, before you reboot.
All that has to be done via Odin or Heimdall, if you don't have a working custom recovery.

You should definitely read (and understand) my thread starter before you try to flash a pit.
I generally assume you are familiar with these tools (Odin etc.). Otherwise read more in other threads.
There are definitely too many possible situations, which I cannot cover in this thread.

What is the history of your brick? Did you really use an ICS-kernel?
I'm asking because the emmc brick only occurs in some combinations of software.
Newer software shouldn't trigger this bug.
Without having used an ICS-kernel you would probably have a very different problem.

Okay, this is history of my problem. Four days ago everything started. Just to say all root apps I had were installed back in July when I installed CM11 M8 with cwm 6.0.5.0(previously coming from Siyah kernel and stock JB 4.1.2), so a root app couldn't trigger this problem. The most recent app I have installed was Checky and that was done nearly two weeks ago.
Ok, now to the problem. Four days ago I took my phone to check for new msgs/notifications and stuff like that and it wouldn't start. I realized that it was powerd off. No bih deal it happened before on thiis rom and even on official JB rom. I tried to turn it on but I faced a bootloop (6-7 months ago I think) so I knew what to do to get out of it. I went to recovery mode and tried to make backup of whole rom but that was the point everything started to go downhill. While doing backup cwm reported an error "couldn't backup /data" (maybe it said couldn't mount /data, I forgot but I can check if it seems important). I tried a couple of times without look. Then(this was a foolish move) I tried to reflash cwm recovery via Odin. Odin got stuck after doing "NAND write start" and after few minutes it showed "Complete(write) operation failed. I was shocked, because I have used Odin many times on this machine and with this phone and that never happened. I tried again-nothing. I rebooted the phone and tried to go into recovery but it was gone. Again, a shocking moment.
Then I tried falshing all kinds of roms/modem/csc/pit files via Odin but nothing. Every attempt resulted in the same error. I even tried flashing only .pit file(with repartition checked) but still, the same error occured.
I learned then about Heimdall and decided to give it a shot. I tried flashing file by file and I had some success. Some files could be flashed and some couldn't. This is the files that I managed to flash: boot.bin; param.lfs; sbl1.bin(taken from a stock GB and JB roms). All other couldn't. Heimdall would go to 100% of uploading the file and then it would write(depending on the file I am flashing):
ERROR: Failed to confirm end of file transfer sequence!
ERROR: KERNEL upload failed!

Ending session...
ERROR: Failed to send end session packet!
Releasing device inteface...

This is it. I think that some of the partitions got somehow corrupted and that is the reason why they can't be flashed. Bootloader is not the problem since I am able to flash some files. I really don't have any idea on what to do next.

 

[hg42]

Okay, this is history of my problem. Four days ago everything started. Just to say all root apps I had were installed back in July when I installed CM11 M8 with cwm 6.0.5.0(previously coming from Siyah kernel and stock JB 4.1.2)

so, you didn't answer my question: did you ever use a Samsung ICS kernel?
And additionally: did you use an old CWM recovery with, that is one from the times before the emmc problem was known to the community?
The emmc brick is only triggered by this software combination when using wipe functions.

The emmc brick is very unlikely nowadays. There is no current software that triggers the bug.
But may be you used some old files in the process (again: Samsung-ICS-kernel + old custom recovery + wipe).
Or may be you have triggered the bug in former times but it didn't affect your phone until now (because of the wear-level-algorithm).

I assume you don't have an emmc brick but some other kind of problem.
May be your hardware (memory chips etc.) has gotten problems.

Then I tried falshing all kinds of roms/modem/csc/pit files via Odin but nothing. Every attempt resulted in the same error. I even tried flashing only .pit file(with repartition checked) but still, the same error occured.
I learned then about Heimdall and decided to give it a shot. I tried flashing file by file and I had some success. Some files could be flashed and some couldn't. This is the files that I managed to flash: boot.bin; param.lfs; sbl1.bin(taken from a stock GB and JB roms). All other couldn't. Heimdall would go to 100% of uploading the file and then it would write(depending on the file I am flashing):
ERROR: Failed to confirm end of file transfer sequence!
ERROR: KERNEL upload failed!

Ending session...
ERROR: Failed to send end session packet!
Releasing device inteface...

This is it. I think that some of the partitions got somehow corrupted and that is the reason why they can't be flashed. Bootloader is not the problem since I am able to flash some files. I really don't have any idea on what to do next.

You generally have to separate some things:

* the contents of the partitions (file systems)

this is about file systems like ext4, fat32, or special flash file systems or read only file systems etc.
File systems are some logical structure written to the raw partitions.
If they get corrupted, the partition seems to be "damaged", which means they cannot be mounted and are therefore unusable (you have to mount a file system to use it).

But this is not a kind of hardware damage, it's just that some bytes were written incorrectly to the file system.
This can happen, when the phone turns off (really, that means power is suddenly lost, e.g. like pulling the battery) while writing the file system.
Then some structures are written incomplete and some file system are corrupted then.

There are journal based file systems like ext4 that prevent the file system from becoming corrupted. This is a kind of two phase write algorithm, where the data structures are always complete. Only some written data can be lost, but the file system is always in a correct state (or can be corrected automatically at mount time from the journal).

ext4 is journal based, but ext2 or ext3 are not. I think most flash file systems are not journal based and fat definitely isn't.
The flash file systems on android like boot loaders or recoveries will never be written, only on creation time. So that's no problem.

* the partition structure (pit, partition tables)

this is used to tell the os where which partition is located in the memory area. The memory is "partitioned".
If the partition table is changed, the os cannot access the file systems on the changed partitions because it is reading at the wrong place.
If you rewrite(restore) the partition table to the former values, the partitions will be accessible again.
But note that some OSes like msdos or windows will write some bytes to the partitions when changing the partition table, so the partitions will have damaged areas after restoring the partition table.

The two fomer points are generally reversible, because it's all about logical structures which may be recreated or restored from backups.
But reconstruction may be restricted to hardware methods like JTAG etc. because you can only write to memory by software, if the device at least runs a boot loader or something that does the real writes for you.
Software like Odin talks to a minimal software on the phone like the "download mode" which executes commands on the phone.
If this minimal software doesn't run, the PC-Software cannot do anything on the phone.

Another method is some software on the phone (e.g. recovery) that has some user interface to write some package (e.g. a special zip format) to the phone memory and runs scripts.

* hardware failures

in rare cases you may get a hardware failure, e.g. something like the emmc bug or the memory getting too hot or applying to high voltage to the hardware (e.g. voltage spikes induced by lightnings http://en.wikipedia.org/wiki/Voltage_spike).
Most of these failures are permanent (not reversible).
In some cases there are only some bytes changed and after restoring them everything would be ok.
But then you have to know where the bytes changed and you must have a backup etc.


Now, in your case it's very unclear what may have happened.
I doubt it is an emmc brick.

You said you cannot write a pit alone? That would be very bad, because the partition table (which is created by the download mode when "flashing" the pit) is the first part necessary to boot the phone. However, a correct table wouldn't make the phone unusable by itself.
But you cannot change the partition scheme and there must be a severe problem then.

Can you print the pit by using heimdall?


Btw. I finally repaired my N7000 by buying a cheap used N7000 with a broken display.
I simply swapped the mother board.

 

[Stefan2142]

oh, wow, I never heard of such a situation.

You first mentioned Heimdall and now Odin, so you really used Odin now?

I have mixed experiences with Heimdall, so I would recommend Odin.
Are you sure Odin works generally? you could eventually have driver problems.
There may be other reasons for a non working Odin.

As I said, you have to restore (at least the critical) partitions, before you reboot.
All that has to be done via Odin or Heimdall, if you don't have a working custom recovery.

You should definitely read (and understand) my thread starter before you try to flash a pit.
I generally assume you are familiar with these tools (Odin etc.). Otherwise read more in other threads.
There are definitely too many possible situations, which I cannot cover in this thread.

What is the history of your brick? Did you really use an ICS-kernel?
I'm asking because the emmc brick only occurs in some combinations of software.
Newer software shouldn't trigger this bug.
Without having used an ICS-kernel you would probably have a very different problem.

so, you didn't answer my question: did you ever use a Samsung ICS kernel?
And additionally: did you use an old CWM recovery with, that is one from the times before the emmc problem was known to the community?
The emmc brick is only triggered by this software combination when using wipe functions.

The emmc brick is very unlikely nowadays. There is no current software that triggers the bug.
But may be you used some old files in the process (again: Samsung-ICS-kernel + old custom recovery + wipe).
Or may be you have triggered the bug in former times but it didn't affect your phone until now (because of the wear-level-algorithm).

I assume you don't have an emmc brick but some other kind of problem.
May be your hardware (memory chips etc.) has gotten problems.



You generally have to separate some things:

* the contents of the partitions (file systems)

this is about file systems like ext4, fat32, or special flash file systems or read only file systems etc.
File systems are some logical structure written to the raw partitions.
If they get corrupted, the partition seems to be "damaged", which means they cannot be mounted and are therefore unusable (you have to mount a file system to use it).

But this is not a kind of hardware damage, it's just that some bytes were written incorrectly to the file system.
This can happen, when the phone turns off (really, that means power is suddenly lost, e.g. like pulling the battery) while writing the file system.
Then some structures are written incomplete and some file system are corrupted then.

There are journal based file systems like ext4 that prevent the file system from becoming corrupted. This is a kind of two phase write algorithm, where the data structures are always complete. Only some written data can be lost, but the file system is always in a correct state (or can be corrected automatically at mount time from the journal).

ext4 is journal based, but ext2 or ext3 are not. I think most flash file systems are not journal based and fat definitely isn't.
The flash file systems on android like boot loaders or recoveries will never be written, only on creation time. So that's no problem.

* the partition structure (pit, partition tables)

this is used to tell the os where which partition is located in the memory area. The memory is "partitioned".
If the partition table is changed, the os cannot access the file systems on the changed partitions because it is reading at the wrong place.
If you rewrite(restore) the partition table to the former values, the partitions will be accessible again.
But note that some OSes like msdos or windows will write some bytes to the partitions when changing the partition table, so the partitions will have damaged areas after restoring the partition table.

The two fomer points are generally reversible, because it's all about logical structures which may be recreated or restored from backups.
But reconstruction may be restricted to hardware methods like JTAG etc. because you can only write to memory by software, if the device at least runs a boot loader or something that does the real writes for you.
Software like Odin talks to a minimal software on the phone like the "download mode" which executes commands on the phone.
If this minimal software doesn't run, the PC-Software cannot do anything on the phone.

Another method is some software on the phone (e.g. recovery) that has some user interface to write some package (e.g. a special zip format) to the phone memory and runs scripts.

* hardware failures

in rare cases you may get a hardware failure, e.g. something like the emmc bug or the memory getting too hot or applying to high voltage to the hardware (e.g. voltage spikes induced by lightnings http://en.wikipedia.org/wiki/Voltage_spike).
Most of these failures are permanent (not reversible).
In some cases there are only some bytes changed and after restoring them everything would be ok.
But then you have to know where the bytes changed and you must have a backup etc.


Now, in your case it's very unclear what may have happened.
I doubt it is an emmc brick.

You said you cannot write a pit alone? That would be very bad, because the partition table (which is created by the download mode when "flashing" the pit) is the first part necessary to boot the phone. However, a correct table wouldn't make the phone unusable by itself.
But you cannot change the partition scheme and there must be a severe problem then.

Can you print the pit by using heimdall?


Btw. I finally repaired my N7000 by buying a cheap used N7000 with a broken display.
I simply swapped the mother board.

I was out of town yesterday hence the late reply.
This is the .pit file

C:\Users\stefan\Desktop\Heimdall Suite>heimdall print-pit
Heimdall v1.4.0

Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Entry Count: 15
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0


--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 0
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: GANG
Flash Filename: emmc.img
FOTA Filename:


--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.bin
FOTA Filename:


--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 8192
Partition Block Count: 40960
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename: efs.img
FOTA Filename:


--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 49152
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL1
Flash Filename: Sbl.bin
FOTA Filename:


--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 53248
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL2
Flash Filename:
FOTA Filename:


--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 5
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 57344
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash Filename: param.lfs
FOTA Filename:


--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 6
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 73728
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: KERNEL
Flash Filename: zImage
FOTA Filename:


--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 7
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 90112
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash Filename:
FOTA Filename:


--- Entry #8 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 106496
Partition Block Count: 204800
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash Filename: cache.img
FOTA Filename:


--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 311296
Partition Block Count: 32768
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEM
Flash Filename: modem.bin
FOTA Filename:


--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 10
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 344064
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FACTORYFS
Flash Filename: factoryfs.img
FOTA Filename:


--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 11
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 1392640
Partition Block Count: 4194304
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DATAFS
Flash Filename: data.img
FOTA Filename:


--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 12
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 5586944
Partition Block Count: 24133632
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: UMS
Flash Filename:
FOTA Filename:


--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 13
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 29720576
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: HIDDEN
Flash Filename: hidden.img
FOTA Filename:


--- Entry #14 ---
Binary Type: 1 (CP)
Device Type: 1 (File/FAT)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name:
Flash Filename:
FOTA Filename:

Ending session...
Rebooting device...
Releasing device interface...


C:\Users\stefan\Desktop\Heimdall Suite>

Thanks for clarifications of these two terms, I am still learning. Then, if you doubt it's an eMMC brick, what could be? And the biggest issue..how could it be fixed? From what I know, this .pit file seems fine.

 

[hg42]

I'm currently on vacation, so please be patient.

From a quick glance I would say the PIT seems to be ok, only the "Unknown" entries look a bit weird, but may be this is normal.
Perhaps someone else can post his heimdall PIT print log to compare both?
I probably don't have access to my N7000 for several weeks.

 

[aryaputraz]

many thanks for you !!! :good:
now my samsung gtab p6200 can be used again !!!!

But, my galaxy tab always freezing. i tried cyanogen 10 and stock rom 4.1.2, this problem cannot fixed. its possible to repair this "freezing" problems??

*sorry for my bad english

 

[Stefan2142]

I'm currently on vacation, so please be patient.

From a quick glance I would say the PIT seems to be ok, only the "Unknown" entries look a bit weird, but may be this is normal.
Perhaps someone else can post his heimdall PIT print log to compare both?
I probably don't have access to my N7000 for several weeks.

Okay, I have found the stock .pit file from this thread:
http://forum.xda-developers.com/galaxy-s2/help/help-i9100-partitions-pit-file-heimdall-t2250274

Entry Count: 15
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0


--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 0
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: GANG
Flash Filename: emmc.img
FOTA Filename: 


--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.bin
FOTA Filename: 


--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 8192
Partition Block Count: 40960
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename: efs.img
FOTA Filename: 


--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 49152
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL1
Flash Filename: Sbl.bin
FOTA Filename: 


--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 53248
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL2
Flash Filename: 
FOTA Filename: 


--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 5
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 57344
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash Filename: param.lfs
FOTA Filename: 


--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 6
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 73728
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: KERNEL
Flash Filename: zImage
FOTA Filename: 


--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 7
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 90112
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash Filename: 
FOTA Filename: 


--- Entry #8 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 106496
Partition Block Count: 204800
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash Filename: cache.img
FOTA Filename: 


--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 311296
Partition Block Count: 32768
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEM
Flash Filename: modem.bin
FOTA Filename: 


--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 10
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 344064
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FACTORYFS
Flash Filename: factoryfs.img
FOTA Filename: 


--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 11
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 1392640
Partition Block Count: 4194304
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DATAFS
Flash Filename: data.img
FOTA Filename: 


--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 12
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 5586944
Partition Block Count: 24133632
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: UMS
Flash Filename: 
FOTA Filename: 


--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 13
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 29720576
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: HIDDEN
Flash Filename: hidden.img
FOTA Filename: 


--- Entry #14 ---
Binary Type: 1 (CP)
Device Type: 1 (File/FAT)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: 
Flash Filename: 
FOTA Filename:

I have compared this pit file and mine and they are the same. So the unknown entries are, I think, good. Something else must be the problem then.

 

[sNiXx1]

Although I have (hopefully) read through most posts somehow related to my problem, I can't seem to find the best way forward. As I am not entirely sure that my problem is the brick bug, I created my own thread. As I cannot use recovery and have no idea what was running on the i9100 beforehand, I would very much appreciate your help.

After having retrieved the pit via heimdall, it seems to be the same as the one posted by Stefan2142, although his is from an N7000:

Entry Count: 15
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0


--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 0
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: GANG
Flash Filename: emmc.img
FOTA Filename: 


--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.bin
FOTA Filename: 


--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 8192
Partition Block Count: 40960
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename: efs.img
FOTA Filename: 


--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 49152
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL1
Flash Filename: Sbl.bin
FOTA Filename: 


--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 53248
Partition Block Count: 2560
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL2
Flash Filename: 
FOTA Filename: 


--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 5
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 57344
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash Filename: param.lfs
FOTA Filename: 


--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 6
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 73728
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: KERNEL
Flash Filename: zImage
FOTA Filename: 


--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 7
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 90112
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash Filename: 
FOTA Filename: 


--- Entry #8 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 106496
Partition Block Count: 204800
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash Filename: cache.img
FOTA Filename: 


--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 311296
Partition Block Count: 32768
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEM
Flash Filename: modem.bin
FOTA Filename: 


--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 10
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 344064
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FACTORYFS
Flash Filename: factoryfs.img
FOTA Filename: 


--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 11
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 1392640
Partition Block Count: 4194304
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DATAFS
Flash Filename: data.img
FOTA Filename: 


--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 12
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 5586944
Partition Block Count: 24133632
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: UMS
Flash Filename: 
FOTA Filename: 


--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 13
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 29720576
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: HIDDEN
Flash Filename: hidden.img
FOTA Filename: 


--- Entry #14 ---
Binary Type: 1 (CP)
Device Type: 1 (File/FAT)
Identifier: 9
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 0
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: 
Flash Filename: 
FOTA Filename: 

Ending session...
Releasing device interface...

I researched the backup of the EFS partition, but as I can only get into download mode, I have no idea how to deal with this. Also, it is unclear to me which pit-file I should try first, as moving any partition may potentially overwrite the information on the EFS, or did I misunderstand it? Is there any way to restore my EFS information after flashing a pit file and flashing a recovery?

Just a few moments ago, instead of getting stuck at "NAND Write Start!!", Odin stopped at "cache.img" when flashing firmware from sammobile. Could this be an indication that this partition is corrupted?

<ID:0/004> Added!!
<OSM> Enter CS for MD5..
<OSM> Check MD5.. Do not unplug the cable..
<OSM> Please wait..
<OSM> I9100XWLSS_I9100XXMS2_I9100SUNLS2_HOME.tar.md5 is valid.
<OSM> Checking MD5 finished Sucessfully..
<OSM> Leave CS..
<ID:0/004> Odin v.3 engine (ID:4)..
<ID:0/004> File analysis..
<ID:0/004> SetupConnection..
<ID:0/004> Initialzation..
<ID:0/004> Get PIT for mapping..
<ID:0/004> Firmware update start..
<ID:0/004> SingleDownload.
<ID:0/004> boot.bin
<ID:0/004> NAND Write Start!! 
<ID:0/004> cache.img
<ID:0/004> Complete(Write) operation failed.
<OSM> All threads completed. (succeed 0 / failed 1)

 

[hg42]

I researched the backup of the EFS partition, but as I can only get into download mode, I have no idea how to deal with this.

you should probably try a custom recovery first, to be able to scan to determine the brick area

Also, it is unclear to me which pit-file I should try first, as moving any partition may potentially overwrite the information on the EFS, or did I misunderstand it

efs is only affected if you move starting at a partition below or equal to efs. Luckily efs is one of the first small partitions. So most bricks are somewhere after efs.

Is there any way to restore my EFS information after flashing a pit file and flashing a recovery?

you need an efs backup and a way to restore it.
If you have an image of your efs you may flash it via recovery.
If you have a recovery with adb support, you may also restore tar backups created by some efs backup apps.

Just a few moments ago, instead of getting stuck at "NAND Write Start!!", Odin stopped at "cache.img" when flashing firmware from sammobile. Could this be an indication that this partition is corrupted?

probably yes

cache is higher than recovery, so you may be able to flash a custom recovery. Then use my scanner.

 

[sNiXx1]

probably yes

cache is higher than recovery, so you may be able to flash a custom recovery. Then use my scanner.

Thanks for the information, it seems a lot clearer now. However, I wasn't able to flash a recovery (I tried Siyah-s2-v5.0.1 and PhilZ-cwm6 v5.06.1), as it gets stuck at "NAND Write Start!!" again:

<ID:0/004> Odin v.3 engine (ID:4)..
<ID:0/004> File analysis..
<ID:0/004> SetupConnection..
<ID:0/004> Initialzation..
<ID:0/004> Get PIT for mapping..
<ID:0/004> Firmware update start..
<ID:0/004> SingleDownload.
<ID:0/004> zImage
<ID:0/004> NAND Write Start!!

Can I use one of your pit-files to move everything after PARAM? It seems to me that at least two partitions are faulty.

 

[samironearth]

IT WORKED ON MY Galaxy TAB plus P6200 .... thank you so much ... it was bricked for a month and i had lost all hope .. even the SAMSUNG guys had no clue and said that the motherboard had to be replaced ... thank you thank you thank you thank you soo much hg42 .. you are my god

 

[hg42]

sorry, I cannot follow xda very often nowadays, so this may be a little late...

Can I use one of your pit-files to move everything after PARAM? It seems to me that at least two partitions are faulty.

ok, like you already said, this looks like your KERNEL partition is damaged (the one after PARAM).

I can generate a package with more partitions for your device.

I currently have these i9100* devices in my script:

  "i9100_16GB"          => { start=>["FACTORYFS", "DATAFS", "UMS"],         big=>"UMS" },
  "i9100_32GB"          => { start=>["FACTORYFS", "DATAFS", "UMS"],         big=>"UMS" },
  "i9100g_16GB"         => { start=>["FACTORYFS", "DATAFS", "UMS"],         big=>"UMS" },
  "i9100_jb4.1_16GB"    => { start=>["DATAFS", "FACTORYFS", "UMS"],       big=>"UMS" },

which one do you need?
Additionally, which pit file is your stock pit?

The i9100_jb4.1_16GB uses this pit:

...partitions 1-5...
 6 PARAM               57344 +    16384 blocks      29 +     8 =    38 MB
 7 KERNEL              73728 +    16384 blocks      38 +     8 =    46 MB
 8 RECOVERY            90112 +    16384 blocks      46 +     8 =    55 MB
 9 CACHE              106496 +   204800 blocks      55 +   105 =   159 MB
10 MODEM              311296 +    32768 blocks     159 +    17 =   176 MB
11 HIDDEN             344064 +  1048576 blocks     176 +   537 =   713 MB
12 DATAFS            1392640 +  4194304 blocks     713 +  2147 =  2861 MB
13 FACTORYFS         5586944 +  2097152 blocks    2861 +  1074 =  3934 MB
14 UMS               7684096 + 23085056 blocks    3934 + 11820 = 15754 MB

If you start moving at KERNEL you probably won't have much problems restoring the partitions 7-14:

 7 KERNEL        no prob
 8 RECOVERY   no prob
 9 CACHE          wipe
10 MODEM        restore from backup or flash from modem file
11 HIDDEN         most critical because contents is unknown (to me)
12 DATAFS        wipe or restore from backup
13 FACTORYFS flash rom
14 UMS             wipe or restore from backup

(note: as usual, I don't have much spare time, so please be patient)