Related
I was reading rotohammer's post about an easy on-device backup method (using dd) that can restore data at a bit more of a lower level (Odin) than a nandroid backup. (EFS partitions, etc.)
It's possible to get your EFS partition in such a state that the /dev/block/bml3 and /dev/block/stl3 devices are no longer exposed on the device at all. This results in such nice behavior as the Cellular portion of the device not functioning at all. Providing you made a dd backup of all bml and stl devices (i.e. you have a backup of stl3 specifically,) you can recover from this situation.
Odin can recognize any file defined in the .pit file, when they are flashed to the PDA slot in a .tar, and place them in their proper partitions. One benefit to this is that if you get the EFS partition to a place where the device nodes aren't exposed to the OS anymore, you can restore it to working functionality.
These are the possible filenames that Odin recognizes: (from 512.pit, other .pits may have differing partition schemes.)
Code:
ries.pit
efs.rfs (this is the file we are going to restore to fix a broken EFS with a dd backup)
sbl.bin
param.lfs
zImage (kernel and recovery)
factoryfs.rfs
dbdata.rfs
cache.rfs
modem.bin
Any of these files are flashable by Odin3 1.7 if you place them in a .tar and put in the PDA slot.
rotohammer's post details which device matches up with which filename, in this case what we want to do is name the /dev/block/stl3 backup efs.rfs, and add it to a tar file (efs.tar) then flash it.
Assuming you have adb installed, and the stl3.bin file in the current folder:
adb push stl3.bin /sdcard/efs.rfs
adb shell
$ su
#
# cd /sdcard
# tar -cf efs.tar efs.rfs
# exit
$ exit
adb pull /sdcard/efs.tar
Now, get into download mode, open odin, stick efs.tar in PDA slot, and press start. Bam! EFS fixed
Note that in normal conditions you won't need a backup this extreme (copies of the files inside will be ok) but i've seen a number of users who have gotten their phones into this state (and did it myself during testing!) - This works with all the partitions you back up with dd that have support in your .pit file.
I've also used this to make an odin backup of my ROM, and flash it back later. This way you can have a pre-lagfixed ROM, for example
Dedicated to cerjam
how to obtain stl3 and bml3
in adb
adb shell
su (allow the root access)
cat /dev/block/stl3 > /sdcard/stl3.bak
cat /dev/block/bml3 > /sdcard/bml3.bak
rename .bak by .bin
sorry for my english.
Da_G said:
I was reading rotohammer's post
I've also used this to make an odin backup of my ROM, and flash it back later. This way you can have a pre-lagfixed ROM, for example
Dedicated to cerjam
Click to expand...
Click to collapse
How can I make ODIN back of my ROM, a little guide would help. Thanks in advance for your response.
trip007in said:
How can I make ODIN back of my ROM, a little guide would help. Thanks in advance for your response.
Click to expand...
Click to collapse
hi please use the search button , you will easily find how to , this is a 5 month old thread ....
Gonna go out on a limb and assume they are using search, hence the 5 month old post bump.
whiteguypl said:
Gonna go out on a limb and assume they are using search, hence the 5 month old post bump.
Click to expand...
Click to collapse
I dunno how they used it but htere s a 2 weeks old post by darky in the i9000 section .
can someone upload efs.rfs?efs.tar?
i screwd mine and i dont have backup
Every device has there own efs folder (IMEI and stuf).
So if you don't have a backup I don't know what to tell you...
thats not nv_data.bin or imei and product code stuffi want efs partition structure
wich come from stl3.bin
This thread may be almost a year old, but it just saved my Infuse.
Once again it just proves that if you serach, read, try and search, read and try somemore, you can find the answers.
Truckerglenn said:
This thread may be almost a year old, but it just saved my Infuse.
Once again it just proves that if you serach, read, try and search, read and try somemore, you can find the answers.
Click to expand...
Click to collapse
Someone gets it lolz .
Sent from my SAMSUNG-SGH-I897 using xda premium
moeinf said:
thats not nv_data.bin or imei and product code stuffi want efs partition structure
wich come from stl3.bin
Click to expand...
Click to collapse
Sorry im late...but adamoutler was going to post a blank efs partition in another thread . Dont know what happenwd to it tho.
Sent from my SAMSUNG-SGH-I897 using xda premium
Da_G said:
I was reading rotohammer's post about an easy on-device backup method (using dd) that can restore data at a bit more of a lower level (Odin) than a nandroid backup. (EFS partitions, etc.)
It's possible to get your EFS partition in such a state that the /dev/block/bml3 and /dev/block/stl3 devices are no longer exposed on the device at all. This results in such nice behavior as the Cellular portion of the device not functioning at all. Providing you made a dd backup of all bml and stl devices (i.e. you have a backup of stl3 specifically,) you can recover from this situation.
Odin can recognize any file defined in the .pit file, when they are flashed to the PDA slot in a .tar, and place them in their proper partitions. One benefit to this is that if you get the EFS partition to a place where the device nodes aren't exposed to the OS anymore, you can restore it to working functionality.
These are the possible filenames that Odin recognizes: (from 512.pit, other .pits may have differing partition schemes.)
Code:
ries.pit
efs.rfs (this is the file we are going to restore to fix a broken EFS with a dd backup)
sbl.bin
param.lfs
zImage (kernel and recovery)
factoryfs.rfs
dbdata.rfs
cache.rfs
modem.bin
Any of these files are flashable by Odin3 1.7 if you place them in a .tar and put in the PDA slot.
rotohammer's post details which device matches up with which filename, in this case what we want to do is name the /dev/block/stl3 backup efs.rfs, and add it to a tar file (efs.tar) then flash it.
Assuming you have adb installed, and the stl3.bin file in the current folder:
adb push stl3.bin /sdcard/efs.rfs
adb shell
$ su
#
# cd /sdcard
# tar -cf efs.tar efs.rfs
# exit
$ exit
adb pull /sdcard/efs.tar
Now, get into download mode, open odin, stick efs.tar in PDA slot, and press start. Bam! EFS fixed
Note that in normal conditions you won't need a backup this extreme (copies of the files inside will be ok) but i've seen a number of users who have gotten their phones into this state (and did it myself during testing!) - This works with all the partitions you back up with dd that have support in your .pit file.
I've also used this to make an odin backup of my ROM, and flash it back later. This way you can have a pre-lagfixed ROM, for example
Dedicated to cerjam
Click to expand...
Click to collapse
If I could Ill kiss you! Thank you it really did the trick!
I know this is a pissed off issue by many of you but I want to use my archos as an industrial tablet.
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
br, sodjas
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Sad news modinfo shows:
alias: char-major-10-243
license: Proprietary
description: flashrw
author: Archos
depends:
vermagic: 2.6.10_mvl402 ARMv5 gcc-3.4
It is Proprietary
Hi sodjas,
you should do a little more research on this issue.
sodjas said:
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
Click to expand...
Click to collapse
As you started to point out, there are different bootlogos for the differnt stages on start-up.
1. bootloader logo
2. ramdisk bootlogo
3. Android logo (animated)
The logo inside Android could be easily removed or replaced (at least using Urukdroid).
Also the ramdisk logo could be modified with some technical skills (ramdisk needs to be rebuild and replaced).
Replacing the first hardcoded bootloader logo, is something for the freaks, but in fact it is possible.
First of all you'll need read/write access to the mtd block devices created by the kernel. This would require at least SDE or Urukdroid installation.
The Archos tablets use embedded MMC as persistant storage.
All partitions of this device are mounted as block devices and could be tweaked by directly accessing them (e.g. using dd for low level access).
One could start by reading some sectors of the first raw partition, examine the structure, do some disassembly and find the location where the bootloader logo is stored. Not sure if it could be deleted without changing some lines of code.
In fact this is an expert thing, if something goes wrong, you'll have a true brick .
There'd been some posts around covering this topic.
sodjas said:
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Click to expand...
Click to collapse
AFAIK, there's no need for this kernel module on gen8 devices.
The gen8 devices do not use any raw NOR flash or NAND devices.
All access to the eMMC is done with mtd kernel driver using the OMAP mmc interface.
BTW there might be some parts of storage used as hidden sectors, but this is a kernel thing only.
But back to topic:
In fact you'll need to find the bootlogo in raw data of the bootcode, determine the format and replace the raw blocks of memory.
Maybe you'll also need to tweak the security checks in bootcode as well, because checksum will change is the bootlogo is replaced.
Anyway it's slightly difficult to do so, but it's not impossible
Have fun,
scholbert
Lot of interesing information thank you, I'll check the hints out... The checksum thing sounds serious
Anyway, thank you very much for your answer it contains a lot interesting and useful things for me!
br, sodjas
Hi sodjas,
you're welcome!
This might be of interest to:
http://forum.xda-developers.com/showthread.php?t=1018260
This guy already made a disassembly of boot code.
http://forum.xda-developers.com/showthread.php?t=1214674
This guy wrote some tools for mmc low level access.
Maybe they might help you as well.
Keep on posting, this is an interesting topic
Regards,
scholbert
@sodjas:
Just being curious, why do you want the archos as an industrial PC?
I'M asking because we have bought a very cheap development board
http://embedded-computing.com/low-runs-main-line-linux-android
where you can install everything you want.
It is definately not as powerfull as the archos, but it costs less then half of it.
And if you search for OK6410 you will find others that even have the Android 2.3 for that.
@scholbert:
Thank you very much one more time , hope we can bring out something interesting
@fzelle:
The answer for this is the circumstance when you are at a software development deparment surrounded with high level software guys and have an interesting and impressing task to build an RFID enabled industrial terminal with WIFI capability and a platform where you can easly build fancy touch based UI-s in just 3 months then you made choices like these -> to have a proof of concept thing -> to prove that your software is unique and feasible to develop -> to be able to go to exhibitions to make this interesting to investors -> later it is more then possible that we will say somebody who has the experience in hw building: OK we have this HW build us a similar one from OEM parts bundled in an industrial box...
@both:
Thank you guys for replying, this is such a nice community!
br, sodjas
Hey Guys!
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Sorry for the lots of questions, I'm still very green on low level
br, sodjas
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
br, sodjas
Of course i understand that, i'm a sw dev for 25 years.
I was lucky to see that board before we had some similar needs as you have.
What do you use for the rfid part?
Hi sodjas,
it's late but i'll try to answer your questions
sodjas said:
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
Click to expand...
Click to collapse
So this is the firmware structure before it is installed on the device.
The update process is done by the bootcode and there's not that much information about it and not much we could actually do with these files.
So you'd better have a look at the installed partitions and the way to modify thoose.
sodjas said:
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Click to expand...
Click to collapse
No, the squashfs file is the final rootfs mounted as a loop device by the stock firmware.
It's possible to modify this file, but if you do the checksum won't match and you'll have to tweak bootcode to ignore security checking.
So in fact this is not very comfortable, but doable.
The ramdisk is the the cpio file archive also beeing updated and included in the update. Don't know the structure right now because it's on my linux laptop.
sodjas said:
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Click to expand...
Click to collapse
I don't know this tool and i guess it has been made for the older platforms.
sodjas said:
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
Click to expand...
Click to collapse
Yeah, as i pointed out:
By extracting the update file you got an "external view" of the system.
After the firmware is placed on the device these files are flashed to eMMC and got mounted as block devices.
So it's little different then.
sodjas said:
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
Click to expand...
Click to collapse
It's a bit complicated to explain... but quite easy in the end.
You'll have to read out the partitions as raw blocks.
All the low level stuff is mounted as /dev/block/mmcblk0p1
Please read out first using the dd command.
It will give a file at about 32MByte, ands it's all cryptic binary format (rawfs and below).
So if you like to enter this, there's not much information here and you'll have to digg out pieces.
Maybe it's better to modify the higher level parts...
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Attached you'll find the mounts of stock and Uruk firmware.
I know that this is little abstract right now, but i'll have to take some sleep
Have fun!
scholbert
@fzelle:
the rfid part is for workflow monitoring in glass houses. we would like to deploy N terminals in each house and the workers can check-in, define a task they are working on and after they've finished can check out... simple but all info is gathered on a central place and is in order to make easier planning/observing/and calculating financial/investment related things...
the only problem is the musb_hdrc.ko -> it is not picking the FTDI chip if its plugged-in with the OTG cable at the same time. It is a known issue but I still have a lots of problem here:
1. if a change musb_hdrc.ko to my instance musb_hdrc.ko in /lib/modules it is not working at all, if I check it with modinfo it is different than the one in the GPL release. I guess these files under /lib/modules are also proprietary
2. I degbugged around and saw that the state changes for musb only work well if you first attach the OTG micro which has a grounded 5th pin ->then the state goes to a_idle and then attach the FTDI chip -> this is a working scenario
3. If you attach the OTG with already connected FTDI then it stuck at b_idle mode...
I started a thread about this:
http://forum.xda-developers.com/showthread.php?t=1288522
but it seems the proprietary drivers will be the root of the problem here...
@scholbert:
a mininum thing I owe you is a beer a lot of useful infos here again I'll check around and come back if there are some updates.
thank you guys!
br, sodjas
Hi,
thanks for appreciating.
But stupid me, i forgot one thing...
Quoting myself:
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Click to expand...
Click to collapse
So there's a kernel driver for rawfs of course
The rawfs parts got mounted to /mnt/rawfs and present themselfs as files (avboot, banner,...).
No need to fiddle with the raw binaries to investigate the structure.
You'll have to be root to access this directory.
I'll do some research about the file format of the banner file
EDIT:
O.K., here we go... it is a gz compressed file representing raw pixel data.
So in fact this is the very first boot logo!
Should be possible to import this file to gimp or something.
Don't know if it breaks the avboot security check if it get's replaced. So please be careful!
EDIT2:
I got a Archos 101 so filesize will vary on other platforms.
The pixel data is put into 32bit format so each pixel requires a 4-byte value.
On A101 the resulting file size is of the uncompressed banner file is 2457600 bytes -> 1024x600x4
The simple framebuffer inside avboot uses only the lower 24bit of 32bit pixel data.
The most significant byte of each pixel is always set to 0xFF (0xFF000000 written as MSB first)
To completely blank screen (delete archos logo) you'll need to blank out all pixel.
Pixel data should look like this:
Code:
0xFF000000 x 1024 x 600 (for A101)
0xFF000000 x 800 x 480 (for A70)
You might create such a file with a hex-editor or use some scripting.
Good luck with your USB driver stuff!
Regards,
scholbert
Update
I modified both mmcblk0 and mmcblk0p1, my tab is still booting.
The modification of /mnt/rawfs/banner directly was my idea too, but I'm still afraid of some parts
I pulled the banner file and on ubuntu I can list the content, but can't extract it, and there are lots of questions like:
1. The file inside banner is named i240x400 -> this means that it is a 240x400 image but it would be more logical that it is 400x240 based on how "Entertaiment your way " looks...
2. Ubuntu's file roller can't extract it
3. When I open it in hex editor it has some meta info at the start of the file
and a question at the end:
How did you uncompress your banner file? I always get errors, maybe I used wrong syntax...
br, sodjas
Hi Sodjas,
Let me jump in on this to complement your study:
First, a BIG WARNING: touching any of this without patching signature check will result in bricking device.
Second BIG WARNING: Vitalif's mmc offsets for bootloader patches are valid for his device only. Mine has completely different values, I presume there are multiple bootloader versions out there. If patch is incorrect, or not done in the right order, instant brick.
7_MMC and 8_MMC are indeed interesting parts, these are the kernel+initrd images for android and recovery.
As stated by scholbert, to get a better understanding, you should take a look at /mnt/rawfs:
You'll see few files there:
avboot (second stage bootloader)
init (normal boot android, kernel+initrd)
recovery (recovery boot, kernel+initrd)
custom (sde boot, kernel+initrd)
banner (boot logo as it seems)
7_MMCF is flashed to init
8_MMCF is flashed to recovery
Splitting these files into zImage+initrd.gz is quite easy, I can give you some hints if you want. But I don't think it would serve you much for what you're trying to do: what you want is changing bootloader logo, so your goal is avboot+banner.
But again, don't modify anything on mmc0 until you're sure of what you do. First bootloader checks avboot signature and avboot checks init and recovery signature for sure. Without patch, you'll brick your device.
I don't know if avboot checks banner file though.
Hi Letama,
Thank you for joining.
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Two big questions still open for me:
1. How to modify banner in an efficient way?
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Update 2
In the meantime I uncompressed it on win with 7-zip I see the content I should modify to 0xFF000000 but I'm still not sure how flush this to all 0xFF000000 because there is some meta info at start. And as second, how to compress it, maybe the gzip -9 i240x400 will do its job as it was described at Gen5 boot logo tutorial...
br, sodjas
sodjas said:
because there is some meta info at start.
br, sodjas
Click to expand...
Click to collapse
Sorry AFAIK, no metainfo, just the pure 0xAABBCCDD 32bit values as scholbert told me before, sorry for that
br, sodjas
I realized again I'm a fool, or just archos guys wanted to make a joke
1. the banner file is named i240x400 BUT
2. when you extract it you got a 1 536 000 bytes sized file
3. I used my awsome maths skills and found out that: 1 536 000 / 4 <byte> = 384000 / 800 <pixels> = 480
So the raw image size is 800x480 and no 240x480 as the file name indicates...
I just need to flush 0xFF000000 384000 times in a file I think.
br, sodjas
sodjas said:
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
Click to expand...
Click to collapse
Yes, search pattern was the same for me too, only different offsets. Good thing that code didn't change.
sodjas said:
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Click to expand...
Click to collapse
I only modified init and recovery, but I guess they wouldn't implement a specific signature check for boot logo. I'm suspecting that there is no signature check at all on it but I never checked avboot for that.
sodjas said:
1. How to modify banner in an efficient way?
Click to expand...
Click to collapse
To modify init and recovery, I wrote a small app that directly open /dev/block/mmcblk0p1, seek for the right position (with some file signature check to be sure I'm doing it right) then write. I make sure that I don't write a bigger file than current ones and it works fine for init/recovery. I believe that archos flasher does the same as existing file sizes are bigger than the firmware dump file sizes.
For your needs, I don't know if you will have to adjust size in the rawfs directory entry and/or avboot. Rawfs is quite straightforward, you can take a look at linux driver if you need to adjust directory entry.
sodjas said:
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Click to expand...
Click to collapse
A dd of mmcblk0 (not mmcblk0p1, you need also first bootloader) should do the trick if the hardware doesn't change and doesn't need a different bootloader. I think that there is multiple revisions of hardware out there, improper bootloader for a specific hardware revision could not boot.
Safest bet would be to write a small patcher that would check pattern and stop if you don't have a known bootloader.
Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.
Note: This thread is rather old now (2012).
Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
most important: an older emmc chip (or firmware).
All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
Some insights here (as part of this thread)
after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
In case only one of the conditions is not true, the brick should not happen.
So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.
So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.
Especially, all current roms or recoveries should be safe.
If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.
So in most cases, don't look here, unless you are using rather old devices and rather old software.
Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.
Note: You should generally post in the correct thread (please look in my signature)
Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).
It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
Please, please, please:
Read this multiple times and try to understand all aspects before using anything of this thread.
If you have questions, read it again!
If you have questions, read it again!
...
If you have questions, read it again!
If you have questions, read it again!
If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).
If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.
If you have questions, read first post again and again and also read the whole thread!
Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...
Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...
You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.
-------------------- manual method and tools for using adb
I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
Along the way our threads started to be companions to each other.
forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.
But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
However, the manual method can do more, especially if you have special cases.
-------------------- find begin and end of bricked area
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You should write down two numbers:
* where emmc_find_brick_start.zip freezes -> BRICK_START
* where emmc_find_brick_end.zip freezes -> BRICK_END
I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).
-------------------- patched pit files
I finally hacked a perl script, which generates a set of PIT files for me.
But because I cannot test the PITs on my phone (because I need it):
==> NO GUARANTY <==
Say you have a situation like this:
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
^ ^
| |
BRICK_START BRICK_END
(? = bad blocks)
The repartitioning should leave a hole in the partition table around the bricked area.
Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
(? = bad blocks)
The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:
Code:
16GB original (Q1_20110914_16GB.pit)
FACTORYFS 548864 ->Fo 1744896 ->Fs
DATAFS 2293760 ->Do 4194304 ->Ds
UMS 6488064 ->Uo 23232512 ->Us
HIDDEN 29720576 ->Ho 1048576 ->Hs
16GB MMC_CAP_ERASE patched
FACTORYFS FoX = Fo+X unchanged
DATAFS DoX = Do+X unchanged
UMS UoX = Uo+X UsX = Us-X
HIDDEN unchanged unchanged
The PITs are named like that:
N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB
This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.
Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.
So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB
Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB
In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
Therefore the following partitions (only HIDDEN in this case) remain unchanged.
All partitions before the first moved partition (FACTORYFS) remain also unchanged.
I recently added more starting partitions for the brick (XXX-moved-by-...).
As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.
Code:
case FACTORYFS-moved-by-...
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
case DATAFS-moved-by-...
before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
after: ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
\ /
-+-
|
HOLE
(? = bad blocks)
The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
For all other partitions, you have to format those partitions, before you can use them.
At least the data partition should be formatted
The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).
ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.
I also had the following problem:
I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
So, you may want to create a backup of your external sdcard first.
Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).
-------------------- backup
before messing with the partition table, everyone should make backups of all partitions that can be accessed.
-------------------- efs backup
The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.
For most supported phones, you can do this via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
please look at forrest1971's thread for details about using adb.
If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
Perhaps you have to mount your sdcard first, to be able to save it there.
Then you should copy the backup to your PC (the recovery should have the option to mount usb).
-------------------- backup files from internal sd before repartitioning
the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.
* you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).
For the following possibilities you should first ensure, you have a working recovery with working adb support.
Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.
* you can use QtAdb to copy files to your PC:
* you can use adb pull to copy any files or directory tree to your PC, e.g.:
adb pull /emmc/. emmc
* you can use tar from adb to archive files to a file on sdcard:
adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.
* you can use a copy command in adb shell to copy files to a folder in sdcard:
adb shell cp -ra /emmc/. /sdcard/emmc.backup
Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
This may matter for system and some app related files.
-------------------- recommended procedures for "standard" cases
"standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
All other partitions need special considerations and are not handled in this section!
Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
So be "careful with that axe, Eugene!"
Note, there are always multiple ways to reinstall the phone.
phase "find brick"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
* flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END
phase "flash pit and ROM"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)
phase "check partitions"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* check the partitions (see section "checking all partitions" below)
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format cache
* format data
* format internal SD (if it fails read below)
phase "start ROM"
...
After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).
A second method is via recovery using a custom kernel:
phase "find brick" like above
phase "flash pit and kernel"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)
phase "check partitions" like above
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format system
* format cache
* format data
* format internal SD
phase "install ROM"
* install the zip of the ROM
phase "start ROM"
...
So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
For some partitions this can be done by a simple format (cache, data, internal sd).
Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).
In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).
You may find other important information in the thread, please read it completely before asking the same things over and over again.
There may also be useful information and experiences from users.
I try to incorporate useful information in the thread starter, but my time is often very limited.
Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.
...suggestions or corrections welcome!...
-------------------- checking all partitions for bricked blocks
After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).
Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.
So you should check all your partitions after repartitioning to be sure.
With both methods below, you can check the partitions even before formatting any of them.
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You can also do it manual via dd commands in adb, but this is much slower.
Use commands like this, using the partition block device in the if=... argument:
adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
...
adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
etc.
If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.
-------------------- pit.str for DataWorkshop
For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
Please ask (PM), if you are interested in this.
-------------------- PITs for other devices
Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
Look at the attached files, which devices are currently available.
If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
I'll look what I can do...
I will add comments for special cases below.
-------------------- device i9250 - experimental PITs
I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
I added this especially for Shanava, who said to be able to recover even from a hard brick.
His brick is in userdata.
So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.
-------------------- devices not supported/supportable
i9000, i9300 (and similar):
These devices have a different PIT structure.
The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
Inserting an unused partition changes the partition numbers after it, which shouldn't work.
-------------------- FOR-EXPERTS-ONLY packages
DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
These packages contain files to be used by those who have special problems and want to take the risk to try them.
They are only documented by the corresponding discussion (somewhere in this thread).
note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.
Let's hear it....
ok I wait. ..
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
RavenY2K3 said:
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
Click to expand...
Click to collapse
That's why I said "Let's hear it....". Like, I am very curious because I noticed the same thing you did. I hate doubting people, but sometimes you have to.
hg42 said:
go straight ahead to the final solution (see next post)...
Click to expand...
Click to collapse
andreww88 said:
Let's hear it....
Click to expand...
Click to collapse
errr
I very much doubt it. But lets hear your version of "The curious case of Benjamin eMMC bug"
panyan said:
errr
Click to expand...
Click to collapse
Why did you quote me?
Repartitioning around the bad blocks
This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.
-----------------------snip -------------------------------------
Hi everyone, especially those with an ICS brick,
last week I jumped straight into a MMC_CAP_ERASE brick.
Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".
Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.
But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.
So I got the BRICK!
After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...
(this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here sorry, my fault)
---- cut ----
This is a rewrite in english of my report at a german forum:
ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html
My brick created bad blocks in the phone's flash memory.
I got I/O-Errors when attempting to read or write those blocks.
My SGN was still able to boot into recovery and all kinds of kernels/recovery.
Odin was able to flash boot loaders, kernels, modems and CSCs.
But flashing a factory_fs stopped at the very beginning.
I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.
For all of the following I needed access to some tools (mainly e2fsck and parted).
As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
You may use the tools from forrest1971, see below under "manual method".
One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
Click to expand...
Click to collapse
This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.
At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:
Code:
before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
after: + ...-| ? ?? |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(? = bad blocks, + working, - = not working still bad blocks inside)
In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).
Here is a log of my steps (but see below in the blue sections for other probably easier procedures):
Code:
I managed to access the device via [I]adb shell[/I]...which is another story for itself...
Then I started [I]parted[/I] with the flash device:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
[QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? f
f
f
Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
continue with the current setting?
Fix/Ignore? f
f
f
this was the partition scheme before implementing the workaround:
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
then I deleted the partitions 9=FACTORYFS=/system, 10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
(parted) rm 11
(parted) rm 10
(parted) rm 9
(parted) mkpartfs primary ext2 3500 4400
(parted) mkpartfs primary ext2 4400 7000
(parted) mkpartfs primary fat32 7000 15.2G
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
now I upgraded both new ext2 partitions to ext4:
~ # tune2fs -j /dev/block/mmcblk0p9
tune2fs -j /dev/block/mmcblk0p9
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # tune2fs -j /dev/block/mmcblk0p10
tune2fs -j /dev/block/mmcblk0p10
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # e2fsck -fDp /dev/block/mmcblk0p9
e2fsck -fDp /dev/block/mmcblk0p9
/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
~ # e2fsck -fDp /dev/block/mmcblk0p10
e2fsck -fDp /dev/block/mmcblk0p10
/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
and this is the final partition layout:
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 3500MB 4400MB 900MB ext3 FACTORYFS
10 4400MB 7000MB 2600MB ext3 DATAFS
11 7000MB 15.2GB 8217MB fat32 UMS msftres
12 15.2GB 15.8GB 537MB ext4 HIDDEN
This configuration works so far (one complete day now).
I can install firmwares and restore backups via recoveries.
Also flashing via Odin should work (not tried yet).
I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
I think/hope this will not occur too often...
-- naturally, it's much faster to insert those short messages than rewriting a long german post in english.
Next time I should write the main text prior to posting anything, I think...
sorry...
WoooooooOOOOOOoooooooowwwww!!!!
YeeeeeeEEEEEEaaaaaAAAAAaaaahhhhhh!!!!!!
You are the man, bro.
man has a few posts but are worth a lot. .. thanks for share with us
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Is the damage so serious? Is it physical??
Interesting Read, this should be of a great help to those bricked without warranty.
straycat said:
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Click to expand...
Click to collapse
you *can* indeed try to recreate the standard partition scheme (I did it very early with a PIT file in Odin and also tried formatting those partions etc.), but this doesn't work because *accessing* those blocks in any way is the *real* problem.
Is the damage so serious? Is it physical??
Click to expand...
Click to collapse
yes, you can't even fix the bad blocks with the usual JTAG equipment.
I was told by a technician from a good repair center that a fix could eventually be possible by directly reprogramming the flash chip in some way (JTAG again), but no one tried yet, because this would cause several hours of work...
usually they swap the whole motherboard instead (which is >250EUR)
Thanks, hg42.
I really apreciate your efforts and to share with us.
I'm not a superbriked note owner but I follow with great interest those posts.
Again, thank you, man.
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Thanks anyway for your efforts!
Sent from my GT-N7000 using Tapatalk 2
Zamboney said:
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Click to expand...
Click to collapse
LOL, you're right, at the end I also thought, that's really simple
but, at least...I had several problems to solve before getting adb up and running properly with root permissions and having the necessary tools at hand (inside adb).
I think this was mainly because I wiped my /system before.
But, it's easy to be wise after the event.
hmm, I tried to export this partition scheme to a PIT file (using heimdall-frontend), but I got a file that is exactly equal to the one I flashed last via Odin, which was Q1_20110914_16GB.pit.
So I assume the PIT file is one way only?
A PIT file would probably allow even unexperienced users to unbrick their phones.
This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Although your post I found easier to read.
I've managed to patch to MF3 without flashing bootloaders, modems, rpm, and without losing TWRP. All without rooting the device. What this means is, I now have a 100% stock MF3 system partition that I would like to dump into an odin-flashable tarball. To do that, I need to dump my system (while in recovery) to a system.img.ext4, using whatever method is normally used to create an odin-flashable file.
I found this guide: http://forum.xda-developers.com/showthread.php?t=2277127
I wanted to get some feedback from Devs working on the I337, specifically. It appears that the command I want is this:
Code:
make_ext4fs -s -l 2760M -a system /sdcard/system.img.ext4 /system
But... where do I determine what size I need?
Many thanks.
Aou said:
I've managed to patch to MF3 without flashing bootloaders, modems, rpm, and without losing TWRP. All without rooting the device. What this means is, I now have a 100% stock MF3 system partition that I would like to dump into an odin-flashable tarball. To do that, I need to dump my system (while in recovery) to a system.img.ext4, using whatever method is normally used to create an odin-flashable file.
I found this guide: http://forum.xda-developers.com/showthread.php?t=2277127
I wanted to get some feedback from Devs working on the I337, specifically. It appears that the command I want is this:
Code:
make_ext4fs -s -l 2760M -a system /sdcard/system.img.ext4 /system
But... where do I determine what size I need?
Many thanks.
Click to expand...
Click to collapse
I might have found my own answer:
Code:
fdisk -l /dev/block/mmcblk0p16
Disk /dev/block/mmcblk0p16: 2894 MB, 2894069760 bytes
4 heads, 16 sectors/track, 88320 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk /dev/block/mmcblk0p16 doesn't contain a valid partition table
No go. Perhaps I'm packaging it wrong? Perhaps I'm not pulling the image correctly?
Here's Odin's log:
Code:
<ID:0/020> Added!!
<ID:0/020> Odin v.3 engine (ID:20)..
<ID:0/020> File analysis..
<ID:0/020> SetupConnection..
<ID:0/020> Initialzation..
<ID:0/020> Get PIT for mapping..
<ID:0/020> Firmware update start..
<ID:0/020> system.img.ext4
<ID:0/020> NAND Write Start!!
<ID:0/020> FAIL! (Auth)
<OSM> All threads completed. (succeed 0 / failed 1)
Here's what the screen said:
SECURE CHECK FAIL : system
Here's how I dumped the system (in adb shell while in recovery with /system and /cache mounted):
Code:
make_ext4fs -s -l 2894069760 -a system /sdcard/system.img.ext4 /system
make_ext4fs -s -l 2170552320 -a cache /sdcard/cache.img.ext4 /cache
(the above number of bytes were obtained using fdisk against the partitions)
And here's how I packed them into the Odin-flashable tarball:
Code:
tar -H ustar -c system.img.ext4 cache.img.ext4 > mf3.tar
md5sum -t mf3.tar >> mf3.tar
mv mf3.tar mf3.tar.md5
Does anyone see anything wrong with this method? Odin Mode currently shows:
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
- Root was never applied, kept the stock MF3 kernel, nothing's been touched in /system - everything 100% absolutely stock...
Check out this article:
http://androidforums.com/continuum-all-things-root/263953-how-make-custom-odin-images.html
Change the partition info to match that of i337
Craptain Krunch said:
Check out this article:
http://androidforums.com/continuum-all-things-root/263953-how-make-custom-odin-images.html
Change the partition info to match that of i337
Click to expand...
Click to collapse
That post is scary-old, though. Doesn't even mention ext4
Aou said:
That post is scary-old, though. Doesn't even mention ext4
Click to expand...
Click to collapse
I mainly linked it because the packaging commands are slightly different.
Craptain Krunch said:
I mainly linked it because the packaging commands are slightly different.
Click to expand...
Click to collapse
I see. I researched it a bit, and the "dd" method stopped working with the S3 and beyond. I tried it anyway, and Odin (on phone) failed, saying:
Unsupport dev_type
I am looking into this: https://github.com/Chainfire/sgs4ext4fs
But not sure if it applies.
Aou said:
I see. I researched it a bit, and the "dd" method stopped working with the S3 and beyond. I tried it anyway, and Odin (on phone) failed, saying:
Unsupport dev_type
I am looking into this: https://github.com/Chainfire/sgs4ext4fs
But not sure if it applies.
Click to expand...
Click to collapse
Check your PM sir.
I have never done this before, so I can't be of much help. The part I don't understand is why the size of the partition must be specified. My first question would be, does it need to specified accurately?
Even though this is for the Epic 4G, it may help
http://forum.xda-developers.com/showthread.php?t=2154762
It may allow you to do what you want without knowing the partition size since you would use a system dump as your source (see post #2).
upndwn4par said:
I have never done this before, so I can't be of much help. The part I don't understand is why the size of the partition must be specified. My first question would be, does it need to specified accurately?
Even though this is for the Epic 4G, it may help
http://forum.xda-developers.com/showthread.php?t=2154762
It may allow you to do what you want without knowing the partition size since you would use a system dump as your source (see post #2).
Click to expand...
Click to collapse
Thanks. Looking into this now.
By the way, the "sgs4ext4fs" program by chainfire seemed to do what it advertised, but still doesn't flash.
UPDATE/EDIT:
Code:
error: file_write: write: File too large
It seems that I can't use their method to create an ext4 file to add to the tarball... Still looking into it though...
Aou said:
Thanks. Looking into this now.
By the way, the "sgs4ext4fs" program by chainfire seemed to do what it advertised, but still doesn't flash.
UPDATE/EDIT:
Code:
error: file_write: write: File too large
It seems that I can't use their method to create an ext4 file to add to the tarball... Still looking into it though...
Click to expand...
Click to collapse
Sorry for lifting up an old thread, but did you eventually get it working? Thanks in advance.
Also would like to know
Sent from my ATT S4 MF3 using Tapatalk
jball said:
Also would like to know
Sent from my ATT S4 MF3 using Tapatalk
Click to expand...
Click to collapse
The best I can remember it did not work. It resulted in an ODIN flash-able TAR that wouldn't flash due to the bootloader not being signed. It really doesn't matter anymore because there is a ODIN flash-able MF3 file available now.
Sorry I thought you were trying to push a version of TWRP.of course I use Safestrap but I would love to be able to use a straight up custom recovery.thank you for a reply
Sent from my ATT S4 MF3 using Tapatalk
tys0n said:
Sorry for lifting up an old thread, but did you eventually get it working? Thanks in advance.
Click to expand...
Click to collapse
scott14719 said:
The best I can remember it did not work. It resulted in an ODIN flash-able TAR that wouldn't flash due to the bootloader not being signed. It really doesn't matter anymore because there is a ODIN flash-able MF3 file available now.
Click to expand...
Click to collapse
scott14719 is correct - the only images I was ever able to create were not accepted by the device due to signatures.
So there's an MF3 odin out there now? I haven't been paying attention. That's awesome.
Aou said:
scott14719 is correct - the only images I was ever able to create were not accepted by the device due to signatures.
So there's an MF3 odin out there now? I haven't been paying attention. That's awesome.
Click to expand...
Click to collapse
Ok, thanks. I was just asking because sm-g730a is also without official firmware. Trying to find a way to make one
tys0n said:
Ok, thanks. I was just asking because sm-g730a is also without official firmware. Trying to find a way to make one
Click to expand...
Click to collapse
Gotcha. Check out my other thread here: http://forum.xda-developers.com/showthread.php?t=2378946
Look at File #5 and File #6. Might guide you in the right direction. These "Odin-flashable" files don't actually work on the I337 because of the signature verification that's built-in the bootloader, but perhaps you might have better luck on the other device. As always, be careful doing any of this stuff.
Hello there, I've just discovered the insane amount of memory used by the system (like 2GB+). I've just discovered that the CM11 just uses 500+MB. And here popped the question: how can i shrink the partition and give the unused space to the sdcard0 partition? Is it possible to do it whitout loosing data?
I got S4 with the Snapdragon, CM11 Installer (i can always flash the snapshot if needed).
Then googling around i found few things not exactly easy to use (unfortunately I'm not a developer); while reading those things it popped in my mind "what if i flash another .zip from recovery? Will it broken the phone? What if I'll flash stock from Odin?"
So here am I, asking on to you guys Thank you for the patience
On the i9500 flashing the chinese pit file reduces the system size.
But again flashing pit files in itself is a big deal. It can lead to a hardbrick.
So basically its better to stay happy with what Samsung has given us
Sent from my GT-I9500 using XDA Free mobile app
DeepankarS said:
On the i9500 flashing the chinese pit file reduces the system size.
But again flashing pit files in itself is a big deal. It can lead to a hardbrick.
So basically its better to stay happy with what Samsung has given us
Sent from my GT-I9500 using XDA Free mobile app
Click to expand...
Click to collapse
Probably you're right but i want to dare
Lamba92 said:
Probably you're right but i want to dare
Click to expand...
Click to collapse
Haha unfortunately the chinese pit is for i9500.
Find a similar one for the i9505. I bet there would be none, or if there are @Lennyz1988 can help you
"If someone helps, never forget to hit thanks ? "
Weeks ago I wrote this in another thread:
I'm who discovered the way to repartition three STE devices (S Advance, Ace II and S3 Mini).
After any kind of test on my I9505 I can sadly say that it's IMPOSSIBLE to repartition.
-PIT files are signed, if we don't have that signature to sign the file we can't use custom PITs.
-Size of the partitions are specified by three text entries (six in HEX) in some offsets before partition's name.
-Signature is 48 blocks long (768 offsets) and it's at the very end of the untouched file. Modifying PIT through PIT Magic totally breaks signature (is no longer inside file) and simply copy-paste works only when you don't modify things of file. It's generated depending on file lenght in blocks, any character inside and partitions' size and names, modifying also a single value of an offset means that we require a new signature because previous one is no longer valid.
-Device has a PIT partition, flash filename is MSM8960.pit. Isn't showed in dev/block since it's protected and hidden, creating a Odin-flashable package and trying to flash doesn't work since flash ends fine but new PIT isn't sent to device.
-When you tick Repartition in Odin and choose a PIT file, rightly after you start to flash that file is compared to the one inside PIT partition, if aren't 1:1 Odin refuses to flash and Download Mode screen gives "Secure Check Fail: PIT"
-KNOX bootloaders (4.3-4.4) have eMMC write protection for partition table, there's also a GPT backup inside. If you try to repartition mmcblk0 using parted or fdisk in ADB, commands end fine but nothing changes. After this operation, partitions are no longer accessible by recovery but just restart your device and let the magic happen (partitions agian accessible, nothing changed).
-Theoretically repartition through parted is possible with a non-KNOX bootloader (4.2) since seems that doesn't have eMMC write protection for partition table and GPT backup. I can't confirm because I have last bootloader.
Click to expand...
Click to collapse
Inviato dal mio GT-I9505
@AntaresOne You're back eh? hopefully and finally. ?
"If someone helps, never forget to hit thanks ? "
DeepankarS said:
@AntaresOne You're back eh? hopefully and finally. ?
"If someone helps, never forget to hit thanks ? "
Click to expand...
Click to collapse
Not fully back but yes, lol
Inviato dal mio GT-I9505