yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] prabhu1980:
Hi HG42,

I hope this might interest you. Not working for super brick but looks like a ray of light.

Resurrection using JTag is not possible at the moment but when someone posted a workaround like this, it gives a hope. People like Adam Outler shall help.

http://forum.gsmhosting.com/vbb/f63...amming-error-0x000000000000-solution-1508808/

This is what I believe about EMMC BUG.

a) It does not cause any physical damage.

b) The format command executed makes some addressing error while formatting and causes a data structure corruption ; which in a normal hard disc can be rewritten.

c) EMMC unfortunately has a protection mechanism to protect from bad sectors. This is interfering when we try doing accessing those bad blocks.

d) What has to be done is to switch off this feature.

WHAT TO SWITCH OFF??

Page 167.

Now I donot know How to change the bit.

May be the manual I have attached above may help..

All the best !!!
[Galaxy Note GT-N7000 General] hg42:
thanks for those links, especially the documentation.

According the jtag I also read several similar threads.

I think those jtag users are shocked, because they are not used to be unable to recover from bricks showing up like ours.

If the phone hasn't got damaged hardware, they should be able to repair it. But the emmc bug is different. They would need a method to jtag the emmc chip not the processor they are used to.

Yes, unfortunately, the posted solution is for a much smaller problem.

Adam's solutions often require soldering.

I agree to first part.

But the problem is not like for a hard disk. On hard disks most errors are in the file systems or the partition tables.

These areas are writable by super users.

Our emmc problem is more like bad sectors. On hard disks there is also a table for these, which is internal to the hard disk and can only be changed by driver level software.

Imagine the algorithm handling the table would have a bug and damage the internal bad sector tables in a way that accessing the mangled structures lead to an endless loop in the internal hard disk firmware.

Am emmc chip is a level more complex because of the wear leveler, which tries to assign different blocks to each write, so all blocks are accessed equally often. This is because the number of accesses per block is limited.

This means the internal tables change on every write.

I doubt this would help.

I think the protection mechanism is mandatory.

Switching it off would probably lead to changed data.

This might result in an unreliable phone, where you cannot trust phone numbers or anything.
[Galaxy Note GT-N7000 General] mbunal:
hi all

i have a n7000 jtagged. after 2 jtags, its avalable memory about 8 gb. i scanned via brick-scanner. but didnt do anything. sometimes its to slow. sometimes running. but brick scanner didnt find brick, didnt freeze. i want all mem, and no FC (sometimes happend).

what do u advice to me?

sorry bad english.

Barış.
[Galaxy Note GT-N7000 General] Ajsk:
So I guess nothing can be done at the moment. Everywhere I checked, there is no solution at the moment, the phone is too new and not supported by any program, and very hard to find the same. (((

Thanks allot for trying to help me, I’ll wait until some mobile soft that will first have a support for my device.
[Galaxy Note GT-N7000 General] hg42:
your device isn't much different to the i9000 in this respect.

Probably leaving a gap in the partition was not intended by Samsung for this "series" of devices.

I wonder why the i9100/N7000 "series" of phones (all I support in this thread) have a different PIT scheme.

It's generally the same format but one of the numbers for each partition is used in a different way.

Instead of defining the block size in bytes it describes the offset of the partition.

And indeed they defined several small gaps at the end of some partitions on these devices, but why?

When I get some spare time (I'm currently working hard in my full time job) I'll think about which possibilities exist to define such a "gap partition" and whether I can test it without loosing my phone or how you can test it without risking boot problems.

The latter seems to be easy on first sight, the "gap partition" has just to be created somewhere after the standard partitions (if this is possible).

Or after making a backup it could be placed before the internal sd.

The "gap partition" has to defined in a way, that it is not counted in the partition numbers but uses space.

I think the chance for this PIT "feature" is very small, because then they probably wouldn't have had a motivation to change the scheme for i9100/N7000/... series.
[Galaxy Note GT-N7000 General] limao74:
Hi,

I have a P6800 with this problem. I did resolved partially but lost almost 7 gb... Is there anyway to help with my problem, maybe a Patched PIT so that I have a minimal lost of storage?

Brick Start = 7443 mb

Brick End = 8559 mb

I used P6800_ATO_PIT--patched--brick-between-1153-and-8669-MB--DATAFS-moved-by-7168-MiB.pit

Thanks
[Galaxy Note GT-N7000 General] okrup:
this is what i got:

D:\tools>adb shell

~ # dd if=/dev/block/mmcblk0p4 of=/sdcard/PARAM.img

dd if=/dev/block/mmcblk0p4 of=/sdcard/PARAM.img

16384+0 records in

16384+0 records out

8388608 bytes (8.0MB) copied, 0.187858 seconds, 42.6MB/s

~ # tar cvf /sdcard/PARAM.tar /mnt/.lfs

tar cvf /sdcard/PARAM.tar /mnt/.lfs

tar: /mnt/.lfs: No such file or directory

tar: error exit delayed from previous errors

~ #
[Galaxy Note GT-N7000 General] jangix:
I have a P6200 16GB with this problem. I did RESOLVED, THANKS!!! but lost almost 14GB (1,92GB NOW AVAILABLE!)... Is there anyway to help with my problem, maybe a Patched PIT so that I have a minimal lost of storage?

Brick Start = 10247 - 10745 mb

Brick End = 11258 - 11805 mb

I used P6200_tabplus--patched--brick-between-01086-and-13702-MB--DATAFS-moved-by-12032-MiB.pit

Thanks. :good::good::good:
[Galaxy Note GT-N7000 General] hg42:
looks like you don't have a brick in the PARAM partition, because dd worked.

Perhaps you have a moving brick, please use find brick scanner again to see if it's still equal to your latest results.

According to the tar problem: looks like you don't have /mnt/.lfs, did you do adb it in the recovery or in the ROM?

But this doesn't matter, dd was the stronger test and you have a backup now.
[Galaxy Note GT-N7000 General] okrup:
I did the adb from the recovery,

anyway, like you told me, i used the brick scanner again, and I got diffrent results! the brick start now at 1035 to 1086, the brick end 2048 to 2148,

isn't weired? last time i checkes and repartioned it stoped at 34-36 MB, and in the end scan it stopped at 3585-3590

1.I used the N7000_16GB_Q1_20110914--patched--brick-between-281-and-2696-MB--FACTORYFS-moved-by-2304-MiB pit file

2. flashed by odin custom kernel GL_HYDRACORE_v5-4_STD

3. run scan manual via dd commands in adb:

D:\tools>adb shell

~ # dd if=/dev/block/mmcblk0p1 of=/dev/null

dd if=/dev/block/mmcblk0p1 of=/dev/null

40960+0 records in

40960+0 records out

20971520 bytes (20.0MB) copied, 0.493138 seconds, 40.6MB/s

~ # dd if=/dev/block/mmcblk0p2 of=/dev/null

dd if=/dev/block/mmcblk0p2 of=/dev/null

2560+0 records in

2560+0 records out

1310720 bytes (1.3MB) copied, 0.037139 seconds, 33.7MB/s

~ # dd if=/dev/block/mmcblk0p3 of=/dev/null

dd if=/dev/block/mmcblk0p3 of=/dev/null

2560+0 records in

2560+0 records out

1310720 bytes (1.3MB) copied, 0.040632 seconds, 30.8MB/s

~ # dd if=/dev/block/mmcblk0p9 of=/dev/null

dd if=/dev/block/mmcblk0p9 of=/dev/null

1744896+0 records in

1744896+0 records out

893386752 bytes (852.0MB) copied, 23.831407 seconds, 35.8MB/s

~ # dd if=/dev/block/mmcblk0p10 of=/dev/null

dd if=/dev/block/mmcblk0p10 of=/dev/null

4194304+0 records in

4194304+0 records out

2147483648 bytes (2.0GB) copied, 55.116248 seconds, 37.2MB/s

~ # dd if=/dev/block/mmcblk0p11 of=/dev/null

dd if=/dev/block/mmcblk0p11 of=/dev/null

19562496+0 records in

19562496+0 records out

10015997952 bytes (9.3GB) copied, 255.679551 seconds, 37.4MB/s

~ #

4. format system

* format cache

* format data

* format SD - but got an eror - i didn't know what do do so i continued for flashing a rom

now, i still have the same problem - no lock screen, no power menu , still freezes.

i installed emmc chech, it said: brick bug? YES. Insane Chip.

what should i do?
[Galaxy Note GT-N7000 General] hg42:
Ok, so you currently have a moving brick, you may need some patience, hoping it will stabilize. But may be it keeps moving.

The emmc check app tells you, if your chip firmware has the firmware bug, which doesn't mean you have a brick!

For the latter you have to push the "scan" button (don't know the real name, it's near the bottom of the screen). Then it scans/reads the memory byte wise (like dd) and counts the position. If that stops or reboots, you have to note the counter, just like with my scanner but much slower and more thorough.

The error while formatting the sd would be useful.

Use the phone and from time to time scan again with my find-brick scanner and note the values in a table.

Lets see if it hops around randomly or it has lower and upper limits or stabilizes or perhaps toggles between several positions.
[Galaxy Note GT-N7000 General] hg42:
I think, you should wait and observe if the brick moves.

Scan from time to time (e.g. every 1.-3. day) and write down start and end values in a table.

Also note when you get freezes.

If your brick is stable for a while, then I can look how the amount can be reduced. Because the brick seems to be more at the end of your big partition (I think), the partition could be shortened from the end, so you would loose around 6gb
[Galaxy Note GT-N7000 General] hirurg:
I wrote one workshop in Belgrade about your problem, this is the answer:

Dear all,

When your phone has emerged as a problem in the installation of new software versions, and also to all problems should be rectified so that is we can go back to your old version of the software with which you will funkcionisati.Taj phone chip that you mention is actually itself MMC card I formatted it to . During the installation of the software is very little probability that it is to damage a chip or hardware phone so you tried to troubleshoot the problem only with the installation of the best versions of the software for that model.

I'm interested in how this story is correct and if the allegations are accurate. What would happen if he put rom 2.3.4 with appropriate pit file? whether the partitions ustabilile and whether the partition table has been entered correctly? if anybody has tried to do something like this? and what were the results?
[Galaxy Note GT-N7000 General] ttm1st:
thanx alot but ...

hi first of all i want to thank u for thi method ..

it worked for me but i am facing alot of freezes in the rom most of them when downloading app from market. what could the problem be ? may i still have some broken parts in the internal ums (part 11)?

first time i scanned the emmc with " emmc_find_brick_end.zip" i found that it started to slow alot when it reached 3950 mb so i used the "patched--brick-between-281-and-4039-MB" pit file and flashed till i reached the rom (paranoid android rom) as i said it freeze mostly when downloading apps.

so what can i do should i use "patched--brick-between-281-and-4307-MB" or what do u think ? may it be a rom problem or something?
[Galaxy Note GT-N7000 General] jijus:
here what i got on my T-869

C:\Temp>adb devices

List of devices attached

4XXXXXXXXXXX9ae recovery

C:\Temp>adb shell

~ # umount /cache

umount /cache

umount: can't umount /cache: No such file or directory

~ # umount /system

umount /system

umount: can't umount /system: Invalid argument

~ # umount /data

umount /data

umount: can't umount /data: Invalid argument

~ # 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

Error: /dev/block/mmcblk0: unrecognised disk label

(parted)
[Galaxy Note GT-N7000 General] hg42:
please read my last posts, same advice for you, seems like your brick isn't stable, yet.
[Galaxy Note GT-N7000 General] hg42:
Hmm, how did you do that?

The recovery still works, but no disk label? Didn't know this is possible...
[Galaxy Note GT-N7000 General] jijus:
I guess my disk was corrupted completely?

As when I try running your scan brick start, it did not finish even after overnight it was so slow. so had to quite, when I got up the next day.

Then after reading thru forest1971 and your posts. started with parted but to get it to print that error it took like 3hrs.

Ok while this is going on, to add insult to injury my Galaxy Nexus’s modem stopped working. Then because the phone was newer than Tab realized I am still under warranty on T-869 too: so I have shipped my Phone to service, and waiting to see what are they going to say...

Then i will send T-869 in. as of now i am able to kill it complertly. no boot, passed away just 15mins ago. :)
[Galaxy Note GT-N7000 General] ttm1st:
well i think i lost the phone now

i had a weard thing.. remember when i told u that i had allot of freezes . last time the phone was frozen then i restarted it and here is the surprise there is no signal !!! i restarted to recovery and it gave me this error :

E:failed to mount /efs (invalid argument)

E:check_selective_file:can't mount /efs

and here is the bad news i didnt backup the /efs as u told us before :S

so i think i h am i a bad situwation here but my warranty still active i may take it to service
[Galaxy Note GT-N7000 General] hg42:
May be, but how can you access the recovery, when the disk label is damaged? Perhaps the disk label worked partly or the error message didn't tell the whole truth.

When accessing a bricked block it either freezes or restarts or slows down. Note the first block, where you notice this behavior and restart the phone.

That's the better solution anyway if you have warranty.
[Galaxy Note GT-N7000 General] hg42:
As you see, a moving brick may occur everywhere.

Fortunately it usually stays away from the most important partitions, but it's not granted.

So efs backup is mandatory (for everyone!)
[Galaxy Note GT-N7000 General] hg42:
Do you really mean jtag? Or is it usb jig?

Usb jig (a small usb plug with some connection of pins that signals "go to download mode" to the hard/software). This often helps when the phone doesn't get into download mode otherwise.

Removing the battery for a minute often works, too.

On Tablets with a fixed battery, wait until the battery gets empty and the device goes off by itself, then attach a loader.

Jtag (attaching a jtag device like riff box etc.) should solve such boot problems.

Jtag only writes new data to all (or some) partitions, so it doesn't help with an emmc brick, where some parts cannot be written.

So, the brick may have damaged your boot partitions or even the partition table.

From what I read, some jtag software can use pits, too.

So it is possible to revive with the pit method via jtag.

If boot partitions are emmc bricked, this will not work, at least not with current pits.

I also do not know a way to describe how to move some boot partitions via pit.

Jtag software may theoretically be able to repartition by other means, but I don't know, I don't know much about jtag. If it would be possible, jtag could do more in this field.

Why are you sure you have an emmc brick?
[Galaxy Note GT-N7000 General] hg42:
N7000B

the PIT files for the N7000 and N7000B are completely identical (logical and also bytewise), so there's no need to generate one for the N7000B
[Galaxy Note GT-N7000 General] lunchbox201:
Ok Thanks.

Was not aware they were identical.
[Galaxy Note GT-N7000 General] goofey2012:
Plz help me for my Galaxy Tab P1000

Here the pit file that i want you to mod for me

my GTP1000 stuck on boot and i think the /data and /system was error

thanks
[Galaxy Note GT-N7000 General] hg42:
p1000_mr-stock.pit
num id name size offset end filename
1 0 IBL+PBL 0.5 kB 128 kB 128.5 kB boot.bin
2 1 PIT 0.5 kB 128 kB 128.5 kB gt-p1000.pit
3 20 EFS 20 kB 128 kB 148 kB efs.rfs
4 3 SBL 2.5 kB 128 kB 130.5 kB sbl.bin
5 4 SBL2 2.5 kB 128 kB 130.5 kB sbl.bin
6 21 PARAM 10 kB 128 kB 138 kB param.lfs
7 6 KERNEL 15 kB 128 kB 143 kB zImage
8 7 RECOVERY 15 kB 128 kB 143 kB zImage
9 22 FACTORYFS 660 kB 128 kB 788 kB factoryfs.rfs
10 23 DBDATAFS 174 kB 128 kB 302 kB dbdata.rfs
11 24 CACHE 70 kB 128 kB 198 kB cache.rfs
12 8 MODEM 32 kB 128 kB 160 kB modem.bin
- 0 MOVINAND 0 kB 0 kB 0 kB movinand.mst
- 3 HIDDEN 0 kB 0 kB 0 kB hidden.rfs
- 8 0 kB 0 kB 0 kB

as you see, your PIT also falls in the category "not supported", because the offset field doesn't contain an offset but the block size.

I can only redirect you to the forest1971's thread (link in first post) for manually editing your partition table.
[Galaxy Note GT-N7000 General] lunchbox201:
Hi HG,

Not sure if you can answer this but i'll ask anyway.

Since i first recovered my note i noticed it freezes at random times, so after about 2-3 weeks and reading multiple users issues, i decided to run your scanner files again.

This time the scans lock up at different locations in the partition. I know this is a known issue but mine seemed to lock up inside the space that was orinally marked as bricked.

Example: 2-3 weeks ago the brick occured between 1077 and 3600. This time it occured between 1085 and 3072.

Would this be the cause of the random freezing? I was understanding that the Patched PIT file stops the bricked area being used?

Or am i wrong in thinking this?

Thanks in Advance for your reply.
[Galaxy Note GT-N7000 General] hg42:
are these (281 - 3770) the numbers of the PIT you used?

If the PIT's gap covers 281-3770 both situations woukld be excluded from usage.

But, naturally, you cannot know, if the brick sometimes moves outside the PIT's gap, because you cannot scan continuously.

I would assume this could also happen just for a short time.

I got the feeling, that either your brick becomes stable after some stabilization time and you get happy with it, or the brick keeps moving and you don't know anything for certain and freezes will happen from time to time.

I don't have enough data to make any assumption how long the stabilization might take (will also be dependent on how much/often you wirte to the flash memory). For me it was a matter of weeks.

I think it's also possible to have a brick keeping moving around but in a limited range, so you may find a range which finally works.

I think it's all because it's a damage in structures which are used to assign free physical blocks when writing new logical blocks.

This assignment heavily depends on your usage pattern (e.g. how often you write new files and how often you delete files), so it should be different from user to user and also from time to time for the same user.

I also know that many bricks are completely stable like my own, which means the phone feels like nothing ever happened and it never freezes.

On the other hand I also see random freezes on phones without an emmc brick, so not all freezes have to do with the brick.

Especially in this case, you should be conservative and only use well known, good working software (e.g. CyanogenMod stable on N7000) and strictly keep away from experimental ROMS and apps etc. Otherwise you never know, if a freeze originates from software or from the brick.
[Galaxy Note GT-N7000 General] szukai:
Trying to fix a S2 I9100

Hi, I'm trying to fix my Samsung Galaxy S2 (32gb - I9100). I got it working, but some things are not going as expected (compared to theory) so I have some questions.

Running your test I get a start at 1023 Mbit = 1073 MB and end at 3378 Mbit = 3543 MB.

So I decided to flash the file in pit:

i9100_u1_02_20110310_emmc_EXT4--patched--brick-between-713-and-3665-MB--DATAFS-moved-by-2816-MiB.pit

I figure 713 < 1073 and 3543 < 3665 right? Fortunately it works, and I was able to install a fresh rom and get a working phone all again. Problem is now I notice that the phone only says it has 8.50gb left on internal SD. I am a little confused by how 32gb -> to 8gb.

I grabbed the program PIT Magic and am looking at the PIT files you patched and comparing it to the original right now to study and understand better what is going on. I noted that when you increase the "blank space" for the I9100 you increase the datafs block size, and also the UMD size as well. Why not just the datafs size only. I don't really understand that part so well, since you already shifted the block count.

Thanks,

KH
[Galaxy Note GT-N7000 General] hg42:
before I answer: please don't quote my whole first post, it is very long...I think everyone able to install custom ROMs should also be able cutting down the quote to a reasonable amount, right?

It is much easier to read if you quote only the sections, you are referring to.

unfortunately most users giving me PITs to patch don't tell me which exact model they have and which models exist.

So in this case I got a PIT for a 16GB S2 and nobody told me there are 32GB models, too, or perhaps your model is a newer one which has an increased memory size now?

So you used a 16GB PIT for your 32GB S2.

You should have looked in the corresponding .txt file, then you would have noticed that the memory ends at about 16GB.

Also the file name of the original PIT is part of the long patched PIT file name (i9100_u1_02_20110310_emmc_EXT4), so you can see from which PIT it is derived.

I assume your's has a different name?

Fortunately, this will probably not harm, because the UMS partition is only followed by the HIDDEN partition.

If you use a 32GB patched PIT, the hidden partition will be placed at the old position again, so you probably don't even need to format or restore it (because the content is still there).

Fazit: please attach your 32GB PIT and your exact model identification (something like i9100 32GB, but perhaps it's i9100b or similar).
[Galaxy Note GT-N7000 General] szukai:
I fixed the quote...

My phone model is like simply GT-I9100 (FCC: A3LGTI9100 SSN: -I9100GSMH). That's what is written both in about phone and also on the back under the battery.

It turns out it is as you said, I was looking at the original pit file which is only 16gb. I could not find a 32gb on xda or samfirmware. (Will keep trying).

But I found what I think may be a copy here:

http://chomikuj.pl/peron_2005/GSM/O.../u1_02_20110718_emmc_EXT4_32GB,2015394194.pit

Mirror (That I uploaded):

http://www.mediafire.com/?8325ce34j020wom

This file just looks the same as the 16 gb version, only difference is the ums and hidden

It is 61,464,576 instead of 29,720,576 for hidden.

Question: If it's 16 gb pit why does the block size for the hidden part say 29,720,576? Value seems to double?

edit: upon detail look I see the ums also has different values
[Galaxy Note GT-N7000 General] hg42:
Thanks

Anyone come up with those for a 16gb s2 for comparision?

PIT Magic uses the scheme several devices use (like the S1).

BlockSize contains the size of a block in bytes for these devices.

Our devices (S2, N7000 etc., which are supported by the pit method) (re-)use this field for the partition offset in blocks.

The block usually is 512 bytes for these devices (not sure if this is always true). So 29,720,576 means 29,720,576 x 512 which is about 16gb.

But, the UMS partition should also have a bigger block count for your 32gb s2?
[Galaxy Note GT-N7000 General] szukai:
yes

Yes, upon closer inspection the UMS count is also bigger.

edit: I need to read what I write
[Galaxy Note GT-N7000 General] hg42:
please look at the thread starter -> new zip for 32GB
[Galaxy Note GT-N7000 General] hg42:
I added

pits-N7000_16GB.zip

pits-N7000_32GB.zip

pits-P6200_tabplus.zip

pits-P6800.zip

which include additional PITs which only shorten the "big" partition (UMS etc.) at the end in 256MiB steps.

If they work for limao74 and jangix I will add them to the other devices.