Isn't that an unsafe kernel (stock ics)?
Don't get a brick again!
should be independent of brickEverything is back to stock, however GPS is no longer working. Takes forever and doesn't lock on!Any idea why?)
PIT file method to revive your phone from a MMC_CAP_ERASE brick
- Thread starter hg42
- Start date
Don't get a brick again!
Please can you do a pit for Samsung Vibrant T959, thanks
http://files.androidspin.com/downlo...in/samsung/vibrant/&file=s1_odin_20100512.rar
http://sourceforge.net/projects/stockodinjfd/files/s1_odin_20100512.pit/download
Vibrant comes standard with 16Gb MMC.
http://files.androidspin.com/downlo...in/samsung/vibrant/&file=s1_odin_20100512.rar
http://sourceforge.net/projects/stockodinjfd/files/s1_odin_20100512.pit/download
Vibrant comes standard with 16Gb MMC.
Last edited:
I can only create PITs, if you send me your stock PIT and say which partitions is bricked in your phone (first block is enough, use emmc check app from Play Store) and if you know which partitions are usually bricked.
I also need to know which PIT variants exist for this phone model (e.g. the Galaxy Note PITs exists in 16GB and 32GB).
I would prefer posting these PIT and information here.
Its same as I9000,Captivate,Vibrant. We all have /data 2gb 1.87GB left and /emmc 14gb 13.03gb left emmc bricked from ics defect erase bug
Last edited:
ok,
do I read this right, you have the exact same stock PIT for all these?
then please attach this stock PIT.
I already did 3 threads above
Can i ask, we dont have any access to dev/block/emmcblk0 and we can't use parted or e2fsck.
Is this fixable with this?
Yea definitely sending it in for warranty claim, minus all evidence of rooting and flashing of course! My Note is running again now as stock and unrooted. Flashing can only be checked through the yellow triangle or the "Custom Binary Download", right? Mine is stated as a "No".The "lost space" contains irrecoverable damaged sectors caused by brickbug, That's why partitions have been re-sized and moved in front of it. Only new MoBo can give all space back. You could try "regain" PIT files to reduce lost space, but why go thru the hassle? Just get new Mobo under warranty (after removing flashing and rooting evidence - if u have warranty) or get huge external SD card to compensate.
Only my opinion tho - hg42 will no doubt correct me if I'm wrong
---------- Post added at 06:07 PM ---------- Previous post was at 06:04 PM ----------
You mean to say this official stock ROM is unstable?
I don't know especially about this ROM (my variant is XXLPY etc.).
But if you think, you are safe with stock ics kernels, your thinking the wrong way.
Stock ics was the cause of the emmc brick, the custom kernels were the first to workaround this firmware bug in the flash chip.
I heard Samsung now starts delivering some safe kernels (ROMs) but I didn't check myself lately.
ok, did you edit your post? My xda app didn't show the links, when I read your post first.I already did 3 threads above
what exactly is "no access"?
The emmc brick normally freezes the flash chip if you access any of the bad blocks.
parted, e2fsck access some parts, so they can indeed freeze. It depends on which operations freeze.
E.g. if your first partition isn't bricked, you should be able to access it:
dd if=/dev/block/mmcblk0p1 of=/dev/null
My time is very limited...I hope I can create these PITs this evening or perhaps tomorrow.
No /dev/block/emmcblk0 means no emmcblkp01 or emmcblkp02 that are /data and /emmc respectively.
Emmc reports busy and nothing is mounted.
Emmc reports busy and nothing is mounted.
what about the second link? no PIT there?
Anyways, I have currently three different pits:
s1_odin_20100512.pit
s1_odin_20100513.pit
s1_odin_20100803.pit
which are a bit different.
Then assuming the same size for a block like for the N7000, I get sizes of around 750 kB for factoryfs and around 370 kB for dbdatafs, which looks strange to me. Either the block size is different or the table is very curious.
Also don't you have an UMS partition (internal sd), where you can store user data?
What is the size of your internal flash memory?
I need to relate the sizes of the PIT table to the real sizes.
If possible, can you give me a log of
Code:
parted /dev/block/mmcblk0 printThis is the pit file you must mod.
http://sourceforge.net/projects/stockodinjfd/files/s1_odin_20100512.pit/download
C:\adb>adb shell
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC MAG8DE (sd/mmc)
Disk /dev/block/mmcblk0: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 14.0GB 14.0GB primary fat32 lba
2 14.0GB 16.0GB 2013MB primary ext4 lba
~ #
This is what you have asked from a working phone, but with CM7 on it
http://sourceforge.net/projects/stockodinjfd/files/s1_odin_20100512.pit/download
C:\adb>adb shell
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC MAG8DE (sd/mmc)
Disk /dev/block/mmcblk0: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.8kB 14.0GB 14.0GB primary fat32 lba
2 14.0GB 16.0GB 2013MB primary ext4 lba
~ #
This is what you have asked from a working phone, but with CM7 on it
Last edited:
i9000: probably reviving without PIT necessary
which refers to s1_odin_20100512.pit
Now I understand what's irritating me.
The i9000 has two memory devices: a small /dev/block/stl and a big /dev/block/mmcblk0, whereas the N7000 and the other devices of this thread all have only one internal memory device /dev/block/mmcblk0.
Ok...now revisiting your question about fixing access to mmcblk0:
I assume mmcblk0 is an internal sd.
If so, the PIT looks to me like only partitioning the other internal memory (stl), can you confirm this?
But how is mmcblk0 partitioned? I assume it's done via factory reset, right?
This is where you got your brick, right?
Odin can probably only flash the partitions on the stl device, right?
Assuming all this, if your brick is on mmcblk0, you cannot work around it with a PIT, because it doesn't touch your mmcblk0 but only stl.
Then your only option would be to use parted on it.
First I assume you have no brick in /data (otherwise a different scheme is needed):
Start
adb shell
and enter
parted /dev/block/mmcblk0
(choose ignore, if you get questions about not all blocks used etc.)
print (to look if you are on the correct device and get the needed values for calculation)
note the values for Start and End for the first partition as OLDSTART and OLDEND.
rm 1 (remove /sdcard partition [btw. you said /emmc?])
mkpartfs primary fat32 START END (create partition at different place)
The aim is to leave the bricked blocks unused.
I assume they are somewhere at the beginning of the partition, say all bricked blocks are in the first X MB.
For this case simply use
START = X
END = OLDEND
I would start with X = 8000MB (about half of the memory).
You can leave this adb window open and open another one for checking.
Now check the partition with
dd if=/dev/block/mmcblk0p1 of=/dev/null
This needs some (longer) time depending on the speed of the memory. Give it at least 60 min for the first try, then you'll know how long it needs for a GB, so you can optimize this time.
If this command freezes, you still have a brick in this new partition, then reboot and start a new session with a bigger X (say +1000MB).
If the command succeeds and tells you how many bytes were read, then you can decrease the X (say -1000MB).
Btw.: fastest way would be to start with a chunk size (here I chose X=8000MB which is also the first chunk size) and in each cycle increase or decrease X by half of the chunk size and then also reduce the chunk size by half for the next cycle (this is called binary searching).
Hope that helps. Otherwise tell here, what's happening.
ok, I found this myself:
Code:
NAND disk */dev/block/stl1 - stl6 omitted
device name mount point size in MB remarks
/dev/block/stl7 n/a 7.5 known as KERNEL, for holding zImage
/dev/block/stl8 n/a 7.5 known as RECOVERY, for storing a copy of zImage
/dev/block/stl9 /system 286.5 known as FACTORYFS
/dev/block/stl10 /dbdata 134 known as DBDATA
/dev/block/stl11 /cache 35 known as CACHE
/dev/block/stl12 n/a 7.5 known as MODEM, for storing modem.bin
MMC disk
device name mount point size in MB remarks
/dev/block/mmcblk0p1 /mnt/sdcard (/sdcard) ~6200 (8G) / ~14200 (16G) none
/dev/block/mmcblk0p2 /data ~2000 noneNow I understand what's irritating me.
The i9000 has two memory devices: a small /dev/block/stl and a big /dev/block/mmcblk0, whereas the N7000 and the other devices of this thread all have only one internal memory device /dev/block/mmcblk0.
Ok...now revisiting your question about fixing access to mmcblk0:
I assume mmcblk0 is an internal sd.
If so, the PIT looks to me like only partitioning the other internal memory (stl), can you confirm this?
But how is mmcblk0 partitioned? I assume it's done via factory reset, right?
This is where you got your brick, right?
Odin can probably only flash the partitions on the stl device, right?
Assuming all this, if your brick is on mmcblk0, you cannot work around it with a PIT, because it doesn't touch your mmcblk0 but only stl.
Then your only option would be to use parted on it.
First I assume you have no brick in /data (otherwise a different scheme is needed):
Start
adb shell
and enter
parted /dev/block/mmcblk0
(choose ignore, if you get questions about not all blocks used etc.)
print (to look if you are on the correct device and get the needed values for calculation)
note the values for Start and End for the first partition as OLDSTART and OLDEND.
rm 1 (remove /sdcard partition [btw. you said /emmc?])
mkpartfs primary fat32 START END (create partition at different place)
The aim is to leave the bricked blocks unused.
I assume they are somewhere at the beginning of the partition, say all bricked blocks are in the first X MB.
For this case simply use
START = X
END = OLDEND
I would start with X = 8000MB (about half of the memory).
You can leave this adb window open and open another one for checking.
Now check the partition with
dd if=/dev/block/mmcblk0p1 of=/dev/null
This needs some (longer) time depending on the speed of the memory. Give it at least 60 min for the first try, then you'll know how long it needs for a GB, so you can optimize this time.
If this command freezes, you still have a brick in this new partition, then reboot and start a new session with a bigger X (say +1000MB).
If the command succeeds and tells you how many bytes were read, then you can decrease the X (say -1000MB).
Btw.: fastest way would be to start with a chunk size (here I chose X=8000MB which is also the first chunk size) and in each cycle increase or decrease X by half of the chunk size and then also reduce the chunk size by half for the next cycle (this is called binary searching).
Hope that helps. Otherwise tell here, what's happening.
Last edited:
what about the others? are they still used? in which cases?
but looks like this doesn't matter any more...
I have successfully revived my phone, thanks! one question, When one day i want to make some changes, do i need to check the re-partition option and place a pit file again to flash kernel or rom via odin?
the phone behaves like any other...
Mainly two things are different:
1. you have a smaller internal sd
2. you cannot flash a stock pit
A new stock pit will probably only become necessary if some rom is too big for current partition sizes.
The partition sizes of the sgn seem to be big enough, though.
If a new PIT would be needed, we would have to patch this one again.
Btw. I make changes to my phone all the time, meaning flashing roms, installing kernels etc. that's all working perfectly sibce reviving my sgn.
Last edited:
mr hg42, why my note keep on freezing when downloading (be it apps from market, or downloading email attachment? is it rom related, or else sir?
I've had similar issues and wondered whether it's related to having revived my phone through this method as well. Mine mostly freezes while downloading from Amazon App Market. I posted the issue on the forum for the ROM I use (AOKP), the replies I got suggest no one else is experiencing these issues.
I'm glad to have use of my phone due to this thread. But I am Curious if the download issue might be related.
cheers.
Hi everyone, I am having issue, with i9000. Each time i try to flash any kind of ROM via ODIN and getting errors, the ODIN part always successul but when phone starting to extract files, he says "cant mount E: \data (invalid argument)
Via CWM i can mount the internal SDCARD and i can see folders and files, but doesnt metter what i will do, format or delete or copy new files, after CWM restart all files remains, like i never touched them, if i scan memory with HDTUNE it gives me alot of bad blocks. Is there any way to install rom in to external sd card?, ive tryed to remove partitions with adb shell. but its just remain same x_x
Via CWM i can mount the internal SDCARD and i can see folders and files, but doesnt metter what i will do, format or delete or copy new files, after CWM restart all files remains, like i never touched them, if i scan memory with HDTUNE it gives me alot of bad blocks. Is there any way to install rom in to external sd card?, ive tryed to remove partitions with adb shell. but its just remain same x_x
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone