PIT file method to revive your phone from a MMC_CAP_ERASE brick

[hg42]

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?

 

[alucard8888]

@hg42

thank you.. my note is working fine now after wiping data/ factory reset and wiping cache partion in orig cwm.. but im still experiencing random rebooting,, i think once a day...but still im happy my note is working and stable enough to use everyday.. again thanks to you..

 

[hg42]

Any way of lowering the bad blocks gap?
I mean almost 4 Gb of space is bricked?
Can i use my phone like before, flashing ics, etc??

Thanks :X

with a different partition scheme you could probably shrink the unused area.

But that's a lot of work (trial and error, which means installing the OS multiple times) and it's a individual solution, because ever one has a different set of blocks bricked. So you have to try for yourself.

Eventually I could write a little perl script to allow creating different PITs for different schemes. But my spare time is very limited.

For myself I think it's not worth the hassle.
I just bought a 64GB sdcard, which should be enough for all my purposes.

And, after the brick, I tend to put important data on external storage.

Also read the whole thread...
I just explained what you can do and what you can not.
I get a little tired of repeating myself

 

[hg42]

Just when I lost all hope I found your post and the aforementioned guide.

well, that's because I wrote it...because I was in the same situation and didn't find anything useful. Everyone told me about repairing the motherboard.

It helped me understand the maneuver and I managed to save my gNOTE
...
Through this particular type of bricking, sectors from our flash memory are damaged and can't be recovered...right
Is that why the size of the UMS partition shrinks from the initial size of 11GB to 8?

I chose this way because I cannot know which blocks are damaged for all users together.
So I used a scheme which should work out of the box for all users having brickes their /system and or /data *anywhere*.
You can see the partition scheme in my first post (the ascii graphics).

If you want to try, you could start the three new partitions at any block inside the suspicious area.
To find the best starting point, I would first remove partitions 9, 10, 11.

Then I would create a partition in the second half of the suspicious area and run e2fsck -c /dev/block/... on it. After that remove the partition.
If that e2fsck worked (no bad blocks found, especially not stuck spomewhere),
I would create a partition in the second half of the first half...
otherwise,
I would create it in the second half of the second half...
etc. This should be the quickest method to find the working part of the suspicious area.
You can open two adb consoles, one to stay in parted and the second to run e2fsck.

Is it possible to recover the missing sectors?

From what I know: NO, but...
I am not on topic in all those xda threads (no spare time left), so read yourself.
And please tell me, if you find newer info.

Also is it now possible to RESTORE my GNOTE to the former stock rom?

I didn't test myself, but in this thread there seem to be success stories on this.

 

[hg42]

@hg42

thank you.. my note is working fine now after wiping data/ factory reset and wiping cache partion in orig cwm.. but im still experiencing random rebooting,, i think once a day...but still im happy my note is working and stable enough to use everyday.. again thanks to you..

again, I cannot imagine why random reboots should originate in the new partition scheme.

I think, either you had additionally bad blocks (from the brick) inside the UMS partition, which are not worked around by the new partition theme (which only addresses system and data bricks).
Or you might have some (soft) bad blocks in any of your partition (which would mean a slightly corrupted partition; I read somewhere, that zero data can also be written somewhere while bricking).
Or the problem is even totally unrelated to the brick...

I would start adb and run e2fsck -c /dev/block/... on all ext4 partitions.
There should also be a fsck for fat32 partitions in the ROM, sometimes called fsck.vfat or may be dosfsck etc., just look for command names containing "fsck" and "fat" or "dos" in /*bin, /system/*bin, as these commands depend on the recovery or the ROM (note: you can run adb in recovery mode or while the firmware is up and running in GUI).

 

[A.S._id]

HI hg42, and can you make a tool, for Linux, the script to run in the terminal, or bat file for windows command string, with perhaps change the parameter partition has been, and that creates a pit file? Thanks in advance!

 

[alexdumitru]

I flashed your PIT and SGN_XX_OXA_KJ1_FACTORYFS.tar and it works like new

Thanks !

UPDATE: Upgraded to ICS through recovery and it didn't recognize my SIM. I restored to an older backup ( which probably broke my partitions again ) and the phone is stuck at boot. Now I flashed your PIT and SGN_XX_OXA_KJ1_FACTORYFS.tar again, but it's still stuck at boot. Also it won't enter recovery mode. Any ideas ?

UPDATE 2: It didn't recognize the SIM because I lost the EFS partition. Which means the device is 100% bricked. So make sure you backup the EFS partition !!!

 

[pjotrek90]

The method you provided worked fine for me dude. Thanks a lot for your job

 

[hg42]

NEW: bunch of PIT files and also 32GB

Hi,

I hacked a little perl script, which generated a bunch of PIT files for me.

This at first addresses 32GB SGNs.

The second purpose is to regain more of the free space (again, please read the update at the end of first post).

Good luck everyone...and please also report success.

 

[Archangel919]

bad blocks fix ?

Hi hg42 , Is there any fix for bad blocks ? like we have defragmenting tool for windows , so any such thing in android so that i can recover back the bad blocks from the memory ? Can my phone ever have full 12 Gb as new one ?

 

[FARSHOOD]

Hi hg42 i have the same problem and used your patched pit file but no success would you recomend any other pit ,the pit list is too long to test.

 

[hg42]

Hi hg42 i have the same problem and used your patched pit file but no success would you recomend any other pit ,the pit list is too long to test.

Are you sure, it doesn't work for you?
Odin gets stuck somewhere (no movement of the bar in Odin and progress on your phone) and you waited at least 5 minutes to be sure?

The *-patched.pit files are the ones with the most chances.
If they really don't work, then you may also have bad blocks in your UMS partition.

I currently don't have a workaround for this.

However it would be possible to calculate a PIT to move the start of the three partitions somewhere inside of the former UMS partition if it is damaged at it's start.

 

[alexdumitru]

You should trying flashing a stock ROM along with it. I don't know why, but it doesn't always work for the first time. Try again and maybe with another ROM. I made a guide of repairing your device using hg4's PIT files: http://www.android.gs/easily-fix-bricked-samsung-galaxy-note-n7000/

 

[dark11b]

tried the new pit files and was able to recover about 1GB

 

[hg42]

Hi hg42 , Is there any fix for bad blocks ? like we have defragmenting tool for windows , so any such thing in android so that i can recover back the bad blocks from the memory ? Can my phone ever have full 12 Gb as new one ?

I was told a soft repair (JTAG on the flash chip or so) would require about 12 hours, so exchanging the motherboard is cheaper (which costs about 280EUR they say).

You could write a bad blocks file and feed it to mke2fs when formatting the partition. But then you can no more use standard procedures.

 

[FARSHOOD]

any difference between pit files i mean that is it any relation between various pit files and amount of capacity we can achieve.

 

[hg42]

any difference between pit files i mean that is it any relation between various pit files and amount of capacity we can achieve.

sorry, I don't completely understand what you are asking for...

But let try to answer anyway...

As I wrote in my first post:

"The number after "regain" describes how much kBytes are regained by this scheme compared against the original workaround."

My "standard" workaround leaves the complete former /system and /data partitions unused, because they can be bricked anywhere, so you loose about 3GB.
So, if you select the PIT with 1024000 in it's name, you loose 1GB less than that, 3GB - 1GB = 2GB.

We can do this, because in most cases the brick seems to "prefer" the beginning of the /data partition, so the end may be undamaged.

Note: there may be damages of other partitions, too.
So better check *all* partitions in adb with an appropriate file system check command (parted, e2fsck, fsck.vfat etc.).

 

[hg42]

is there anyone with a bricked UMS partition (internal SD)?
Where are the bad blocks? at the beginning?

should I also generate PITs with a scheme like this?:

before: ...-|-FAC*ORYFS-|**ATAFS-|-UMS------------------------------------|...
after:  ...-|     empty space          |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(* = bad blocks)

This scheme would start the three changed partitions at different offsets *inside* the former UMS partition, working around bricked blocks at the start of the UMS partition.

 

[FARSHOOD]

Originally Posted by FARSHOOD
any difference between pit files i mean that is it any relation between various pit files and amount of capacity we can achieve.
sorry, I don't completely understand what you are asking for...is there anyone with a bricked UMS partition (internal SD)?
Where are the bad blocks? at the beginning?

should I also generate PITs with a scheme like this?:

Code:
before: ...-|-FAC*ORYFS-|**ATAFS-|-UMS------------------------------------|...
after: ...-| empty space |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(* = bad blocks)
This scheme would start the three changed partitions at different offsets *inside* the former UMS partition, working around bricked blocks at the start of the UMS partition.

dear sir how are you today any way i did your pit file 1024000 and recovered 8.3 GB FIRST THANKS A LOT BUT MY QUESTION IS IF I TRY ALL OF YOUR PIT FILES IS IT POSSIBLE TO RECOVER ALL OF 16GB SD ,ALSO BY YOUR DEFAULT PIT=Q1_20110914_16GB-patched.pit I DID NOT GET ANY RESULT IS IT ANY WAY TO RECOVER WHOLE OF THE SD AND WITH REGARD POST 98 WOULD YOU MORE EXPLAIN WHAT DO YOU MEAN AND HOW CAN I REACH TO THAT SCHEME GUIDE ME TO FIND THE SCHEME ADDRESS. BEST REGARDS

 

[ahenderson223]

First let me say thank you for your work has helped me bring my note back to life i was wondering is there any way to reset the binary counter

Sent from my GT-N7000 using xda premium