Database Info

Automated NVFlash backup for Linux

Inspired by http://forum.xda-developers.com/showthread.php?t=1010659
I set out to make a similar script for Linux. You still need nvflash installed and working. Nothing is changed on the tablet, but your mileage may vary, past performance is not an indicator of future results, and void where prohibited by law
Code:
#!/bin/bash
### Version 1.0 2 April 2011, wd5gnr
### Usage: dobackup
### Puts backup files $ROOT/backup/YYYYMMDDHHMM/
### by default
### Edit the variables below to set things up for your setup
###
### If you already have the bootloader running
### You can use dobackup -r
### To reconnect
# note: for some reason partition 6 and 11 on my device
# fail to read properly. 6 is the MSC partition on mine
# if I reformat it and reload it from stock, its ok. But
# something during running is blowing it again
# Partition 11 apparently is supposed to fail
# based on comments in the script
# from: http://forum.xda-developers.com/showthread.php?t=1010659
# because of that you may want to try the full PARTLIST
# and then edit to suit your situation
#PARTLIST=2 3 4 5 6 7 8 9 10 11
PARTLIST="2 3 4 5 7 8 9 10 11"
# Set the path for backups etc.
ROOT=~/android/nvflash
# Set the path for NVFLASH
NVFLASH=$ROOT/nvflash
# and bootloader
NVBOOT=$ROOT/bootloader.bin
# This gets the date in YYYYMMDDHHMM format
BSTAMP=`date +%Y%m%d%H%M`
# This picks the name of the backup (using the date)
BDIR=$ROOT/backup/$BSTAMP
# make directories
mkdir -p $BDIR
# I did not check to see that this succeeded
# we assume you have permission etc.
# if -r option we never have to load the bootloader
RESUME="--bl $NVBOOT"
if [ "$1" == '-r' ]
then RESUME=-r
fi
function donvf {
if $NVFLASH [email protected]
then true
else
echo NVFlash error 1>&2
rmdir $BDIR >/dev/null 2>&1 # delete an empty backup directory
exit 1
fi
}
# Get BCT first and prime the boot loader
donvf $RESUME --getbct --bct $BDIR/backup.bct --go
# get partition table
donvf -r --getpartitiontable $BDIR/parttable.txt
# for some reason #1 is not required or absent and #12 is the cache
# but you could add it if necessary (look at parttable.txt)
# Part 11 may give an error, but is ok
# If 11 gives error APX will be down and you'll have to reboot to
# do any more things
for I in $PARTLIST
do
if [ $I == 11 ]
then
echo You may safely ignore errors on partition 11 apparently 1>&2
fi
donvf -r --read $I $BDIR/part$I.img
done
exit 0 # because of partition 11, you won't get here unless you aren't doing 11
###
### Note BCT is hardware info (4080 bytes)
### Partition guesses
# 2 = BCT = ?
# 3 = PT = ?
# 4 = EBT = ?
# 5 = MBT = ?
# 6 = MSC = ? Some kind of recovery thing; 7 in stock
# 7 = BLO = Boot logo (6 in stock)
# 8 = OGO
# 9 = SOS = Recovery image (clockwork or stock)
# 10 = LNX = Linux?
# 11 = APP = Applications?
# 12 = CAC = Cache
Funny things are partition 6 (my MSC partition). I can reformat it and flash it with stock and it works. But later it will hang nvflash trying to read it. I can't find any info on what is in there anyway.
Also partition 11 gives an error, but apparently its not just me. See comments in the script.

Can you try running dmesg (e.g. via adb shell or using a terminal on the gtab), right after booting, then looking at the outout for bad block msgs?
I've been guessing that the reason is because of bad blocks...
Jim

MSC partition is actually the /misc folder, you can verify this by comparing content with the file inanop.log
inandop.sh create it, it is designed to make sure the partition is splited in 2 section 2/16 GB and run in init.rc
could be the reason people trying to partition 4GB/12 where having problem...
@ Jim, Seem like you are right, bad sector are really the source of read error in my unit...
I am not sure if we will encounter issue when writing from the OS since this is handled byt the actual file system but writing directly from nvflash seem to be bypassing any kinf of error/wear levelling provided by yaffs file system or even fat32
I would think that writing with the -v (Verify on) would be better to prevent write error but that's a feeling not based on fact (you need to disable this flag to restore a partition with bad block)
I also believe that bad block at the end of the partition 11 are not a concern, they are probably normal for this kind of inand memory... mine appear at 209.584Mb out of 209.715MB so the partition is still 209MB

Nothing in /misc looks exotic -- just a log file and a lost+found. Very strange that it hangs the nvflash read. I noticed it the other day and reformatted it from nvflash and rolled back the stock image and then I was able to read it back. But today it hangs my backup script again.
Oh yeah. And my dmesg log shows Falled Ddk Rd. Bad block error code=0xb0010 at chip=0 block=65. That repeats a few times. Not unique to me however: http://forum.xda-developers.com/showthread.php?t=933128

wd5gnr said:
Nothing in /misc looks exotic -- just a log file and a lost+found. Very strange that it hangs the nvflash read. I noticed it the other day and reformatted it from nvflash and rolled back the stock image and then I was able to read it back. But today it hangs my backup script again.
Oh yeah. And my dmesg log shows Falled Ddk Rd. Bad block error code=0xb0010 at chip=0 block=65. That repeats a few times. Not unique to me however: http://forum.xda-developers.com/showthread.php?t=933128
Click to expand...
Click to collapse
Hi,
Thanks for that info. If you look thru the dmesg, there'll be a listing of the partitions that the kernel is "creating" (I think, more like "assigning"), and I think that by looking at that, relative to the bad block msgs that will be interspersed, you can tell which partition (e.g., on my gtab, one of them is in /system) the bad block is occurring in.
Jim

P00r said:
MSC partition is actually the /misc folder, you can verify this by comparing content with the file inanop.log
inandop.sh create it, it is designed to make sure the partition is splited in 2 section 2/16 GB and run in init.rc
could be the reason people trying to partition 4GB/12 where having problem...
@ Jim, Seem like you are right, bad sector are really the source of read error in my unit...
I am not sure if we will encounter issue when writing from the OS since this is handled byt the actual file system but writing directly from nvflash seem to be bypassing any kinf of error/wear levelling provided by yaffs file system or even fat32
I would think that writing with the -v (Verify on) would be better to prevent write error but that's a feeling not based on fact (you need to disable this flag to restore a partition with bad block)
I also believe that bad block at the end of the partition 11 are not a concern, they are probably normal for this kind of inand memory... mine appear at 209.584Mb out of 209.715MB so the partition is still 209MB
Click to expand...
Click to collapse
Hi,
A couple of comments:
- The problem that I think may occur if you use the -v is that it may prevent the download of the partition to be completed. In other words, if you do --download with -v, and if nvflash hits a verify error in the middle of the partition, it may (I don't know) just stop at that point, then you end up with a half-populated partition, which could be pretty useless.
- Thanks for the info re. part 11, which I believe is "CAC", or "cache". I wonderinf if\ that partition really needs to be restored for a complete system restore?
BTW, what got me started with all of this was that way-back-when, when I first started working with my gtab, I wanted to find a way to do what I call a "complete bare-metal" backup/image of my gtab. That got me started working with nvflash, but then I ran into the --read problems.
As mentioned, one of the bad blocks on my gtab is in cache partition, which may or not needed for a full restore, but the worse thing is that the 2nd bad block that I have is apparently near the end of the system (/system) partition, so that prevents me from doing a successful read of the system partition to back it up.
I've tried a number of things, including doing repartitioning system using CWM, and also some messing with the system partition via adb while in CWM, i.e., I deleted the system partition completely, and the restored it. From what I've read, yaffs partitions don't need to be pre-formatted (don't need to be formatted before being used), so I was hoping (had seem some posts in some other forums) that that might eliminate the bad blocks if they were "soft", but it didn't.
So, I'm still stuck with 2 bad blocks on my gtab, and can't complete a full nvflash image of all the partitions on it ...
BTW, I just got a new gtab via woot, and I ran dmesg on it, and that too has 1 bad block, so it seems like probably all devices have some... Just some info...
Jim

wd5gnr,
So, I guess, at this point, is who is brave enough to try to do a full restore from the partition files that they pulled from their gtab (albeit with read errors)?
Have you tried that yet?
Just to be clear, I have NOT, mainly because of the read errors that I encountered when trying to backup, i.e., if I can't read the partitions, then I have doubts about the integrity of the files that I ended up with.
Jim

I have not. Partition 11 is the system partition, not the cache (at least on mine). On mine 12 is the cache.
If you look at the "inspired by" link above they mention that the image is still usable which implies there is slack space at the end maybe? But I don't know why/how they know that. And no, I have not reflashed my whole system from these backups although I have done a few on partition basis.

wd5gnr said:
I have not. Partition 11 is the system partition, not the cache (at least on mine). On mine 12 is the cache.
If you look at the "inspired by" link above they mention that the image is still usable which implies there is slack space at the end maybe? But I don't know why/how they know that. And no, I have not reflashed my whole system from these backups although I have done a few on partition basis.
Click to expand...
Click to collapse
I was in that thread you linked, and re-read it, and maybe I missed something, but I don't see where it says the image is still usable?
Jim

You have to open up the batch file and read the comments in the code.
Code:
REM If you get error in partition #11 keep it anyway it is still usable
REM this seem to be a normal "feature" of the nand chips used in the tablet...

Ok, I see where you found that comment, in the zip file.
Jim

Hi,
I've been doing some more detailed analysis of my dmesg.
First of all, here's snippets with info from dmesg, showing:
1) kernel boot parameters, with partition sizes
2) status of MTD partitions
mtdparts=tegra_nand:
[email protected](misc),
[email protected](recovery),
[email protected](boot),
[email protected](system),
[email protected](cache),
[email protected](bootbmp),
[email protected](logodata)
<5>[ 7.086731] 7 cmdlinepart partitions found on MTD device tegra_nand
<5>[ 7.092987] Creating 7 MTD partitions on "tegra_nand":
<5>[ 7.098130] 0x000000740000-0x000001740000 : "misc"
<5>[ 7.103663] 0x000003ce0000-0x000004ce0000 : "recovery"
<5>[ 7.109346] 0x000004d60000-0x000005d60000 : "boot"
<5>[ 7.114670] 0x000005de0000-0x0000125e0000 : "system"
<6>[ 7.119773] tegra_nand tegra_nand: Block 0x43b is bad [chip=0,offset=0x8760000]
<5>[ 7.127928] 0x000012680000-0x00001ff80000 : "cache"
<5>[ 7.133741] 0x0000017c0000-0x000001bc0000 : "bootbmp"
<5>[ 7.139340] 0x000001c40000-0x000003c40000 : "logodata"
<6>[ 7.144567] tegra_nand tegra_nand: Block 0x186 is bad [chip=0,offset=0x30c0000]
When I do nvflash --read on all the partitions, I get read errors on partition 8 and partition 11, so I tried to figure out which partition those are, from the dmesg msgs and the sizes shown:
Partition 8
Name=OGO
DeviceId=19
StartSector=12928
NumSectors=16384
BytesPerSector=2048
16834 x 2048 = 34476032 BYTES = 33,668 KBYTES ==>
ALSO:
0x000001c40000-0x000003c40000 = 2000000 = 33554432 BYTES = 32,768 KBYTES ==> THIS IS THE 'logodata' partition
[See: http://forum.xda-developers.com/archive/index.php/t-859884-p-2.html,
"Additionally, the boot animation is left over from another mod. To remove it and see the Vegan boot animation, go into /logodata and delete everything in it."]
So, it appears this bad block is occurring in the 'logodata' partition, which apparently has something to do with the boot animation.
Partition 11
Name=APP
DeviceId=19
StartSector=45696
NumSectors=102400
BytesPerSector=2048
102400 x 2048 = 209715200 BYTES = 204,800 KBYTES ==> THIS IS 'system' partition
ALSO:
0x000005de0000-0x0000125e0000 = C800000 = 209715200 ??
So, it appears this bad block is occurring in the 'system' partition, which I believe is /system.
I'm particularly concerned about the one in the 'system' partition, i.e., probably if I pull that partition using nvflash, and then later try to restore it, /system would be bad/corrupted?
Jim

[Q]How is Kernel Extracted?

@Devs: Plz answer this.
We know that the ROM is installed to the /system partition. Likewise the kernel ie boot.img is installed to the /boot partition of the device. I tried hard but could not find any reference to such a /boot partition(directory) in the root of the device. I would like know whether it is hidden or disguised as something else. The script that flashes the custom kernels has the following line
Code:
package_extract_file("boot.img", "/dev/block/mmcblk0p9");
(What is the block code for system and other partitions?)
Is mmcblk0p9 the /boot partition? Moreover /dev/block has no reference to boot or mmcblk0p9. So where exactly is the kernel being extracted? The boot.img comes packaged as zImage + ramdisk, if i'm not wrong. It would be really helpful if someone could explain how this extraction process is done. In other words where are zImage and ramdisk extracted to, in the root file system and in what form? Is the ramdisk responsible for the creation of the root files system(/dev, /proc, /data. /system, /sys, /sbin etc)?

Total 11 Partition are available and these are the partition i know and all the system related file will be extracted to this mmcblk0p2 partition, which we will be using in our day to day life...
Code:
mmcblk0p2 "system"
mmcblk0p3 "cache"
mmcblk0p6 "userdata"
mmcblk0p8 "recovery"
mmcblk0p9 "boot"
These are also available but i don't know exactly where they are used i guess like EFS etc etc.......
Code:
mmcblk0p1, mmcblk0p4, mmcblk0p5, mmcblk0p7, mmcblk0p10 & mmcblk0p11

Thnx MJ!:good:
So does this mean that in the updater-script, I can use /dev/block/mmcblk0p2 instead of /system? Will the end-result be the same?
Also AFAIK,
Code:
mmcblk0p2 "system" ===> /system |
mmcblk0p3 "cache" ===> /cache |
mmcblk0p6 "userdata" ===> /data |===> In the Root FS
mmcblk0p8 "recovery" ===> /res |
mmcblk0p9 "boot" ===> ? |

You can go through the linux file systems, and the ramdisk extracted in the root which contains the all *.rc files
Hope Adam or any linux specialist can explain it more...

The-Droidster said:
Thnx MJ!:good:
So does this mean that in the updater-script, I can use /dev/block/mmcblk0p2 instead of /system? Will the end-result be the same?
Click to expand...
Click to collapse
Yes buddy this is same .....
The-Droidster said:
Also AFAIK,
Code:
mmcblk0p2 "system" ===> /system |
mmcblk0p3 "cache" ===> /cache |
mmcblk0p6 "userdata" ===> /data |===> In the Root FS
mmcblk0p8 "recovery" ===> /res |
mmcblk0p9 "boot" ===> ? |
Click to expand...
Click to collapse
No idea may be experts can answer this question ....

The boot image is on a separate partition the device of which is '/dev/block/mmcblk0p9'. If you try, you see that you cannot change directory to that file, because it is not a folder, but a block device. It is like a link to the corresponding partition, like '/dev/sda', '/dev/sdb', etc. You have to mount these devices first. You have to use the 'mount' command. However, not all partitions are mountable. The only partitions being able for mount are those with a proper filesystem on them. There are partitions which are not formatted and filesystems are not created, these store data in a more generic form directly on the blocks.
You can find a list of our partitions here (Created by Epsy, thanks to him!).
The boot image partition for our device is '/dev/block/mmcblk0p9'. The update-binary writes the image directly to the flash memory. It's like you executed:
Code:
dd if=/path/to/boot.img of=/dev/block/mmcblk0p9
Regarding the extraction process: You can find detailed information of boot image structure here. After a successful low-level bootup process, the bootloader loads the boot image partition, loads the kernel, the ramdisk and the kernel command line into the memory, then passes memory address of the ramdisk and command line to the kernel's main method, thereby calling it and letting the execution begin.
You can see contents of a ramdisk here (Modified and uploaded by UnknownzD, thanks to him!). This is the ramdisk of the stock ICS rom, probably XXLQ7. The main directories are created upon init process as you can see in 'init.rc'. Sometimes the folders are already created (e.g. in ardatdat's kernel).
The-Droidster said:
Thnx MJ!:good:
So does this mean that in the updater-script, I can use /dev/block/mmcblk0p2 instead of /system? Will the end-result be the same?
Also AFAIK,
Code:
mmcblk0p2 "system" ===> /system |
mmcblk0p3 "cache" ===> /cache |
mmcblk0p6 "userdata" ===> /data |===> In the Root FS
mmcblk0p8 "recovery" ===> /res |
mmcblk0p9 "boot" ===> ? |
Click to expand...
Click to collapse
You cannot use '/dev/block/mmcblk0p2' instead of '/system', because you want to extract more files into it's filesystem. When you do the same with boot.img, it works because you extract it to the flash memory directly then.
'mmcblk0p5', 'mmcblk0p7', 'mmcblk0p8', 'mmcblk0p9' and 'mmcblk0p10' cannot be mounted in our case and thus cannot be linked to a specific directory. They don't have a filesystem on them.

Very lucid explanation. I was waiting for this. It's really surprising that despite the popularity of Android, there's dearth of such Android specific documentation. There's a lot of linux documentation but there's no straight Android analogy present in any of the material I found online. Thanx Adam!:good:

I think it is all device specific... So there can't be a generic document for it... But we have our master Adam who can explain us better...
Sent from my GT-I9103 using xda app-developers app

‎

FearTheBeard said:
Exuseme, can anyone please tell me are these mmcblk0p2 "system", mmcblk0p3 "cache", mmcblk0p6 "userdata", mmcblk0p8 "recovery", mmcblk0p9 "boot" are all the same for all devices?
Click to expand...
Click to collapse
Nope, they aren't in most cases. Similar devices may have the same though.

[Q] Partiion table

What partitions there are in out tablet?
"fastboot getvar all" gets this:
bootloader
recovery
boot
system
cache
userdata
Also i can find such list:
mmcblk0boot0
mmcblk0boot1
mmcblk0 ... 8
(and mmcblk1 is external uSD card)
What is tre partition table (and its sizes, for 32G model), and what is function (and content) of these partitions?

tijl-comdor said:
What partitions there are in out tablet?
"fastboot getvar all" gets this:
bootloader
recovery
boot
system
cache
userdata
Also i can find such list:
mmcblk0boot0
mmcblk0boot1
mmcblk0 ... 8
(and mmcblk1 is external uSD card)
What is tre partition table (and its sizes, for 32G model), and what is function (and content) of these partitions?
Click to expand...
Click to collapse
mmcblk0 layout
All dumps were done on Asus Eee Pad Transformer Infinity TF700T, 64GB version, firmware 9.4.5.26, locked
mmcblk0 off-partition section
Offset: 0 (0x0)
Size: 38273024 (0x2480000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0pre1.img bs=524288 count=73
Offset: 0 (0x0)
Size: 3670016 (0x380000)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s1.img bs=3670016 count=1
Process command: tr -d '\0' <mmcblk0pre1s1.img >mmcblk0pre1s1nz.img # mmcblk0pre1s1nz.img must be empty file
Offset: 3670016 (0x380000)
Contains: Recovery kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s2.img bs=524288 skip=7 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s2.img
mkdir mmcblk0pre1s2.img-ramdisk
cd mmcblk0pre1s2.img-ramdisk
zcat ../mmcblk0pre1s2.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 12058624 (0xb80000)
Contains: Regular boot kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s3.img bs=524288 skip=23 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s3.img
mkdir mmcblk0pre1s3.img-ramdisk
cd mmcblk0pre1s3.img-ramdisk
zcat ../mmcblk0pre1s3.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 20447232 (0x1380000)
Contains: Block of 16 bytes followed by 0x2de0 hexadecimal numbers followed by FF
Size: 12288 (0x3000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s4.img bs=524288 skip=39
Vital data:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss2.img bs=4096 skip=3
Binary part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch1.img bs=16 count=1
Hexadecimal part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch2.img bs=16 count=734 skip=1
Process command: unhex <mmcblk0pre1s4ss1ch2.img >mmcblk0pre1s4ss1ch2bin.img
FF part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch3.img bs=16 skip=735
Process command: tr -d '\377' <mmcblk0pre1s4ss1ch3.img >mmcblk0pre1s4ss1ch3nff.img # mmcblk0pre1s4ss1ch3nff.img must be empty file
Zeroes:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss1.img bs=4096 count=3
Process command: tr -d '\0' <mmcblk0pre1s4ss2.img >mmcblk0pre1s4ss2nz.img # mmcblk0pre1s4ss2nz.img must be empty file
Purpose: Probably encrypted bootloader
mmcblk0p1
Offset: 38273024 (0x2480000)
Size: 805306368 (0x30000000)
File system size: 196608 * 4096 = 805306368 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /system
Mount options: read only, extended attributes, ACL
Permissions: only root can manipulate
Contains: Base system and embedded applications
Purpose: Base system
mmcblk0p2
Offset: 843579392 (0x32480000)
Size: 448790528 (0x1ac00000)
File system size: 109568 * 4096 = 448790528 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /cache
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, UID system and GID cache can read and write
Contains: Cache
Purpose: Application cache
Note: The volume has the same UUID as mmcblk0p1
mmcblk0p3
Offset: 1292369920 (0x4d080000)
Size: 2097152 (0x200000)
File system size: 512 * 4096 = 2097152 (fully occupies partition)
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /misc
Referenced by: /system/lib/libandroid_runtime.so recovery ramdisk: /etc/recovery.fstab
Note: File system is referenced in recovery as emmc, not ext3!
mmcblk0p4
Offset: 1294467072 (0x4d280000)
Size: 855638016 (0x33000000)
File system size: 208896 * 4096 = 855638016
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /staging
Referenced by: recovery ramdisk: init.rc /etc/recovery.fstab
mmcblk0p5
Offset: 2150105088 (0x80280000)
Size: 5242880 (0x500000)
File system size: 5092 * 1024 = 5147488
Format: FAT32 file system, no partition table, MS-DOS "Non-system disk" boot block
Not mounted
Permissions: only root can manipulate
Contains: File system with files:
Serial numbers (ISN, PPID, SSN, UUID)
Calibration data (AL3010 light sensor, AMI304 magnetic sensor, KXTF9 motion sensor)
Purpose: Device specific unique system data, mounted as /btmac during Android boot
Referenced by: /system/bin/wifimacwriter /system/bin/brcm_patchram_plus /system/bin/sensors-config /system/bin/sixpair ramdisk: /init recovery ramdisk: /etc/recovery.fstab /init
mmcblk0p5 off file-system area
Offset in section: 5147488 (0x4e8b60)
Size: 28672 (0x7000)
Read command: busybox dd if=/dev/block/mmcblk0p5 of=/mnt/sdcard/mmcblk0p5s2.img bs=1024 skip=5092
Process command: tr -d '\0' <mmcblk0p5s2.img >mmcblk0p5s2nz.img # mmcblk0p5s2nz.img must be empty file
mmcblk0p6
Offset: 2155347968 (0x80780000)
Size: 524288 (0x80000)
Format: binary data
Permissions: UID drm can manipulate
Contains: 208 bytes of binary data, the rest are zeroes
Purpose: DRM, probably contains encrypted DRM key
Referenced by: /system/bin/wvdrmserver /system/vendor/lib/drm/libdrmwvmplugin.so
mmcblk0p7
Offset: 2155872256 (0x80800000)
Size: 5242880 (0x500000)
Format: empty
Contains: Zeroes
Purpose: Unknown
mmcblk0p8
Offset: 2161115136 (0x80d00000)
Size: 61415620608 (0xe4ca80000)
File system size: 14994040 * 4096 = 61415587840
Format: Linux ext4 filesystem
Mounted at: /data
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, read and write are directory specific
Contains: User applications, user data, and virtual internal SD card
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
mmcblk0p8 off file-system area
Offset in section: 61415587840 (0xe4ca78000)
Size: 32768 (0x8000)
Read command: busybox dd if=/dev/block/mmcblk0p8 of=/mnt/sdcard/mmcblk0p8s2.img bs=4096 skip=14994040
mmcblk0 off-partition section
Offset: 63576735744 (0xecd780000)
Size: 524288 (0x80000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0post8.img bs=524288 skip=121263
Process command: tr -d '\0' <mmcblk0p8s2.img >mmcblk0p8s2nz.img # mmcblk0p8s2nz.img must be empty file
Offset: 63576735744 (0xecd780000)
Offset in section: 0 (0x0)
Size: 507392 (0x7be00)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s1.img bs=507392 count=1
Process command: tr -d '\0' <mmcblk0post8s1.img >mmcblk0post8s1nz.img # mmcblk0post8s1nz.img must be empty file
Offset: 63577243136 (0xecd7fbe00)
Offset in section: 507392 (0x7be00)
Size: 16896 (0x4200)
Contains: EFI Partition table (partition names: APP, CAC, MSC, USP, PER, YTU, CRA, UDA)
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s2.img bs=512 skip=991
Purpose: Partition table
Total size of mmcblk0: 63577260032 (0xecd800000)
Notes:
can manipulate = can read, write partition vital data, only root can mount
can read, write = can read, write partition file system contents
Read commands are ran on the Transformer
Extract and process commands are run anywhere, with pre-read image file in the current directory.
You need dd with large files support. Vanilla dd on TF700T does not support large files. Busybox dd does.

CLOSE, please

All important information/ links will be moved to an INFO thread, since this is a question thread, we do not need it anymore.

Still looking.
Bump, can anyone help?
Saw this page:
forum.xda-developers .com/showthread.php?t=1959445
Was wondering if it's worth a shot.

Kernel released by Huawei.
For kernel/Rom Developers, Huawei has released the kernel for the Huawei Prism II online.
Attached is a notepad document with the links in them, since I am not allowed to post links. I apologize for the inconvenience.
ALSO
For anyone else with a Huawei device that has not released their kernel, I used the email format below:
Emal 1:
I would like the source code for my phone that is available to me. I am an android developer, and it would be useful to me if I have the
source code(that is offerred by Huawei).
The reply you will get:
Dear Customer,
Thank you for contacting Huawei device. The open source is under our technical department to make. Since the procedure is a little more complex, so please kindly be a little patient. We will keep you informed once available.Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.
Give them 2-3 days, then E-mail once again! Be persistent!
2nd email:
Any new information about the source code?
The reply I got:
Dear Customer,
Thank you for contacting Huawei device. Please kindly check the source code link for your reference:
(link given above)
Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.

Parted/FDisk Output on /dev/block/mmcblk0
streetdev22 said:
Bump, can anyone help?
Saw this page:
forum.xda-developers .com/showthread.php?t=1959445
Was wondering if it's worth a shot.
Click to expand...
Click to collapse
Tried the guide on my Prism II. Parted gave me an error. Possible reason for parted error is explained here: http://forum.xda-developers.com/showthread.php?t=2169709.
However, fdisk worked, but it doesn't clearly identify the partitons:
Edited to include gdisk output
parted:
Code:
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: Unable to satisfy all constraints on the partition.
fdisk:
Code:
[email protected]:/ # fdisk -l /dev/block/mmcblk0
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 3909 MB, 3909091328 bytes
1 heads, 16 sectors/track, 477184 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 3 20 4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 3 41 300 45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 41 16681 133120 c Win95 FAT32 (LBA)
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 16681 477184 3684031+ 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 16897 18432 12288 6a Unknown
/dev/block/mmcblk0p6 18433 18944 4096 46 Unknown
/dev/block/mmcblk0p7 18945 19456 4096 63 GNU HURD or SysV
/dev/block/mmcblk0p8 19457 19840 3072 58 Unknown
/dev/block/mmcblk0p9 19969 20352 3072 4a Unknown
/dev/block/mmcblk0p10 20481 20864 3072 4b Unknown
/dev/block/mmcblk0p11 20993 21504 4096 47 Unknown
/dev/block/mmcblk0p12 21505 22528 8192 48 Unknown
/dev/block/mmcblk0p13 22529 25088 20480 60 Unknown
/dev/block/mmcblk0p14 25089 25600 4096 6c Unknown
/dev/block/mmcblk0p15 25601 50176 196608 83 Linux
/dev/block/mmcblk0p16 50177 60416 81920 83 Linux
/dev/block/mmcblk0p17 60417 191488 1048576 83 Linux
/dev/block/mmcblk0p18 191489 338944 1179648 83 Linux
/dev/block/mmcblk0p19 338945 477184 1105920 6b Unknown
gdisk:
Code:
[email protected]:/ # gdisk -l /dev/block/mmcblk0
gdisk -l /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
***************************************************************
Exact type match not found for type code 4D00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4500; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6A00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4600; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6300; assigning type code for
'Linux filesystem'
Exact type match not found for type code 5800; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4A00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4B00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4700; assigning type code for
'Linux filesystem'
Exact type match not found for type code 4800; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6000; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6C00; assigning type code for
'Linux filesystem'
Exact type match not found for type code 6B00; assigning type code for
'Linux filesystem'
Warning! Main partition table overlaps the first partition by 33 blocks!
You will need to delete this partition or resize it in another utility.
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/block/mmcblk0: 7634944 sectors, 3.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E271C8D6-2001-435D-A466-BEFE7ED158CD
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7634910
Partitions will be aligned on 1-sector boundaries
Total free space is 9599 sectors (4.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 1 40 20.0 KiB 8300 Linux filesystem
2 41 640 300.0 KiB 8300 Linux filesystem
3 641 266880 130.0 MiB 0700 Microsoft basic data
5 270336 294911 12.0 MiB 8300 Linux filesystem
6 294912 303103 4.0 MiB 8300 Linux filesystem
7 303104 311295 4.0 MiB 8300 Linux filesystem
8 311296 317439 3.0 MiB 8300 Linux filesystem
9 319488 325631 3.0 MiB 8300 Linux filesystem
10 327680 333823 3.0 MiB 8300 Linux filesystem
11 335872 344063 4.0 MiB 8300 Linux filesystem
12 344064 360447 8.0 MiB 8300 Linux filesystem
13 360448 401407 20.0 MiB 8300 Linux filesystem
14 401408 409599 4.0 MiB 8300 Linux filesystem
15 409600 802815 192.0 MiB 8300 Linux filesystem
16 802816 966655 80.0 MiB 8300 Linux filesystem
17 966656 3063807 1024.0 MiB 8300 Linux filesystem
18 3063808 5423103 1.1 GiB 8300 Linux filesystem
19 5423104 7634943 1.1 GiB 8300 Linux filesystem
[email protected]:/ #

Partition Layout
streetdev22 said:
Recently rooted and unlocked the bootloader on my Huawei Prism II, but there is no custom recovery nor custom roms for this phone. I have tried determing the partition layout in order to dump the recovery, but I am unable to do so.
Tried earlier versions of romdump, but they returned with a segmentation failure.
Click to expand...
Click to collapse
I believe I've found the partition layout based on the /etc/recovery_mmc.fstab extracted from mmcblk0p13, but am not sure. The excerpt of my /etc/recovery_mmc.fstab file from mmcblk0p13 shows some partition names correlated to device names. Could someone verify this is a legitimate way to determine the partition layout? I've also attached the whole recovery_mmc.fstab file.
recovery_mmc.fstab excerpt:
Code:
/boot emmc /dev/block/mmcblk0p12
/cache ext4 /dev/block/mmcblk0p15
# /* < DTS2012062603367 lizhigang 20120626 begin */
/data ext4 /dev/block/mmcblk0p18 length=-16384
#/* < DTS2012062603367 lizhigang 20120626 end */
/recovery emmc /dev/block/mmcblk0p13
/misc emmc /dev/block/mmcblk0p7
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
/system ext4 /dev/block/mmcblk0p17
/sys_boot vfat /dev/block/mmcblk0p3
/fat vfat /dev/block/mmcblk0p3
/HWUserData vfat /dev/block/mmcblk0p19
#/*< DTS2012020804291 weizhonghui 20120208 begin */
/cust ext4 /dev/block/mmcblk0p16
#/* DTS2012020804291 weizhonghui 20120208 end >*/
#/* DTS2012011906026 chendeng 20120120 end > */
# /* DTS2012031506621 lishubin 20120321 end > */
Easier to read (joined fdisk and the recovery_mmc.fstab)
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 3 20 4d Unknown /sdcard
/dev/block/mmcblk0p2 3 41 300 45 Unknown
/dev/block/mmcblk0p3 41 16681 133120 c Win95 FAT32 (LBA) /sys_boot and /fat
/dev/block/mmcblk0p4 16681 477184 3684031+ 5 Extended
/dev/block/mmcblk0p5 16897 18432 12288 6a Unknown
/dev/block/mmcblk0p6 18433 18944 4096 46 Unknown
/dev/block/mmcblk0p7 18945 19456 4096 63 GNU HURD or SysV /misc
/dev/block/mmcblk0p8 19457 19840 3072 58 Unknown
/dev/block/mmcblk0p9 19969 20352 3072 4a Unknown
/dev/block/mmcblk0p10 20481 20864 3072 4b Unknown
/dev/block/mmcblk0p11 20993 21504 4096 47 Unknown
/dev/block/mmcblk0p12 21505 22528 8192 48 Unknown /boot
/dev/block/mmcblk0p13 22529 25088 20480 60 Unknown /recovery
/dev/block/mmcblk0p14 25089 25600 4096 6c Unknown
/dev/block/mmcblk0p15 25601 50176 196608 83 Linux /cache
/dev/block/mmcblk0p16 50177 60416 81920 83 Linux /cust
/dev/block/mmcblk0p17 60417 191488 1048576 83 Linux /system
/dev/block/mmcblk0p18 191489 338944 1179648 83 Linux /data
/dev/block/mmcblk0p19 338945 477184 1105920 6b Unknown /HWUserData

Very nice!
Correlates with the hints found in other files as seen above, so I think we have successfully found the partition layout! I will take a look when my device gets here(originally was working on my relative's phone, but now I purchased it for myself). If this method is confirmed,we can to port CWM, thank you all!! After CWM, we should be able to make custom ROMs freely.

streetdev22 said:
Correlates with the hints found in other files as seen above, so I think we have successfully found the partition layout! I will take a look when my device gets here(originally was working on my relative's phone, but now I purchased it for myself). If this method is confirmed,we can to port CWM, thank you all!! After CWM, we should be able to make custom ROMs freely.
Click to expand...
Click to collapse
Great. I'm glad that someone can verify part of the partition layout. Hopefully, this means that the new information is credible too.

Prism 2 said:
Great. I'm glad that someone can verify part of the partition layout. Hopefully, this means that the new information is credible too.
Click to expand...
Click to collapse
How exactly did you extract the file? Did you extract it from mmcblk0p13? Have the device on hand, so I am trying to verify the findings.
Thanks.

Unpacking Recovery Image
streetdev22 said:
How exactly did you extract the file? Did you extract it from mmcblk0p13? Have the device on hand, so I am trying to verify the findings.
Thanks.
Click to expand...
Click to collapse
First, I made a selective backup using a google store app called Online Nandroid Backup https://play.google.com/store/apps/details?id=com.h3r3t1c.onnandbup&hl=en to make a backup on the "recovery" partition. Even though the app does not specify which block it copies, I believe the app makes a backup of /dev/block/mmcblk0p13 because it uses /system/partlayout4nandroid to determine the partition layout. If you look at the "cat /system/partlayout4nandroid" output below, you'll see that mmcblk0p13 corresponds to recovery.
Then I transferred the recovery.img from the sdcard to my computer.
From there, I followed the directions in Step 1 and Step 2 of http://www.imajeenyus.com/computer/20130301_android_tablet/android/unpack_repack_recovery_image.html to unpack and extract recovery.img.
Online Nandroid Backup Partition Layout:
Code:
[email protected]:/ # cat /system/partlayout4nandroid
cat /system/partlayout4nandroid
dev: size erasesize name
mmcblk0p1: 010000 000000 "modem"
mmcblk0p2: 000008 000000 "ssd"
mmcblk0p3: 000080 000000 "sbl1"
mmcblk0p4: 000100 000000 "sbl2"
mmcblk0p5: 000200 000000 "sbl3"
mmcblk0p6: 000200 000000 "aboot"
mmcblk0p7: 000200 000000 "rpm"
mmcblk0p8: 000200 000000 "tz"
mmcblk0p9: 002800 000000 "pad"
mmcblk0p10: 000c00 000000 "fsg"
mmcblk0p11: 002000 000000 "persist"
mmcblk0p12: 002800 000000 "boot"
[B]mmcblk0p13: 002800 000000 "recovery"[/B]
mmcblk0p14: 0b8000 000000 "system"
mmcblk0p15: 0d0000 000000 "cache"
mmcblk0p16: 000c00 000000 "modemst1"
mmcblk0p17: 000c00 000000 "modemst2"
mmcblk0p18: 040000 000000 "tombstones"
mmcblk0p19: 000400 000000 "misc"
mmcblk0p20: 001000 000000 "logo"
mmcblk0p21: 001000 000000 "logo2"
mmcblk0p22: 54c000 000000 "userdata"
mmcblk0p23: 00ffef 000000 "grow"
[email protected]:/ #

Probably correct.
My father(the owner of the phone) has once again left on a trip, so I will have to wait until Monday/Tuesday, when I receive my phone, to confirm these results.
My only issue with this is is why nandroid shows a different partition layout then what is shown in other files.
If partition 13 is recovery, there is no coincidence that you would find that fstab file in the extracted recovery.
Do you mind dumping all the extracted files from the recovery and uploading them to 4shared, mediafire, or any other cloud service as a compressed file(zip, tar)? I think the file is not coincidental, and that we have indeed found the partition layout(or at least the important partitions for our purposes).
Also, try dumping the boot partition that is currently identified (block 12) without using online nandroid backup(I think via dd should still work) and see if you can find similar files to that explained in the guide(.png, ramdisk directory, etc). If these files match up to what would be typically found in a boot.img or recovery.img, then the layout is most likely correct.
If these files match up to typical boot.img or recovery.img files, we can test the layout by changing something simple like a background before working on serious stuff.
Also, thanks for helping! Once we conclusively identify that this partition layout is correct, we can start to port clockworkmod.

streetdev22 said:
My father(the owner of the phone) has once again left on a trip, so I will have to wait until Monday/Tuesday, when I receive my phone, to confirm these results.
My only issue with this is is why nandroid shows a different partition layout then what is shown in other files.
If partition 13 is recovery, there is no coincidence that you would find that fstab file in the extracted recovery.
Do you mind dumping all the extracted files from the recovery and uploading them to 4shared, mediafire, or any other cloud service as a compressed file(zip, tar)? I think the file is not coincidental, and that we have indeed found the partition layout(or at least the important partitions for our purposes).
Also, try dumping the boot partition that is currently identified (block 12) without using online nandroid backup(I think via dd should still work) and see if you can find similar files to that explained in the guide(.png, ramdisk directory, etc). If these files match up to what would be typically found in a boot.img or recovery.img, then the layout is most likely correct.
If these files match up to typical boot.img or recovery.img files, we can test the layout by changing something simple like a background before working on serious stuff.
Also, thanks for helping! Once we conclusively identify that this partition layout is correct, we can start to port clockworkmod.
Click to expand...
Click to collapse
The extracted files in partition 13 can be found in post #44 of http://forum.xda-developers.com/showthread.php?t=2546455&page=5 labeled as "ramdisk.tar.bz2". I will make a dump of the boot partition using dd and run the tests tomorrow.

Looks validated, Also more tools
There are other guides on the matter of porting cyanogenmod..for example
http://wiki.cyanogenmod.org/w/Doc:_porting_intro
which even mentions a recovery.fstab file in recovery.img! So, that means the partition layout in the fstab file you found is most likely correct.
Another guide:
http://xda-university.com/as-a-developer/porting-clockworkmod-recovery-to-a-new-device
Also, there is an automated tool to porting cyanogenmod for new devices..
http://builder.clockworkmod.com/ (I would recommend avoiding the touch recovery for now, simple is all we need and we don't need more complications)
I am really feeling pretty confident about the partition layout found in the recovery.fstab, because one guide mentions it to be found in the recovery.img!
I would recommend making the changes to a recovery.img instead, because boot.img is still kinda scary (possible bricking )
Also, I think there is a command to try booting from a recovery.img without flashing the .img to the actual partition.
I think the command is mentioned here: http://forum.xda-developers.com/showthread.php?t=2233477
fastboot boot recovery.img is the command and it will not overwrite your existing recovery.
By using this command, you can try booting the stock recovery you extracted(to validate that we have a stock recovery available if we need it), and then boot the recovery.img you make with small edits, and then boot the recovery.img made from the automated CWM porter.
Thank you for replying so fast! We have made real progress in the last few days.
Edit:In the ramdisk that was extracted, another fstab exists on the root of the directory that is named fstab.msm7627, which is the same name from the file I located in post 1! They are the same file! I think this is validated.

Testing Recovery Partition
streetdev22 said:
I would recommend making the changes to a recovery.img instead, because boot.img is still kinda scary (possible bricking )
Also, I think there is a command to try booting from a recovery.img without flashing the .img to the actual partition.
I think the command is mentioned here: http://forum.xda-developers.com/showthread.php?t=2233477
fastboot boot recovery.img is the command and it will not overwrite your existing recovery.
By using this command, you can try booting the stock recovery you extracted(to validate that we have a stock recovery available if we need it), and then boot the recovery.img you make with small edits, and then boot the recovery.img made from the automated CWM porter.
Click to expand...
Click to collapse
I've made
a regular recovery.img using "dd if=/dev/block/mmcblk0p13 of=/sdcard/recovery.img" to make a copy of the recovery partition
a test recovery.img that is the same in every way to the original recovery.img except that all the images under /res/images is rotated 90 degrees. You can see the difference yourself by looking in res.rar attached below.
a clockworkmod recovery image from the clockworkmod recovery builder website
These images can be found attached below:
recovery.rar = original Huawei recovery image
recovery-test.rar = edited recovery image
recovery.img = clockworkmod recovery automatic builder image from http://jenkins.cyanogenmod.com/job/recovery/52069/
Unfortunately, I cannot test this image myself, because I do not want to unlock my bootloader yet.
If anyone with a rooted, unlocked Huawei Prism 2 is interested in helping to further the development of recovery roms for the Prism 2, I have made 3 tests to see if
the recovery partition is located in /dev/block/mmcblk0p13
the command "fastboot boot recovery.img", which we will be using extensively, can be used to boot the specified image file
the Clockworkmod Recovery image made from automated CWM porter successfully boots
The files you will need are provided below. I've also given instructions to the best of my ability without actually having done this.
To test if the recovery partition is located in /dev/block/mmcblk0p13:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery.rar file below and extract it to get recovery.img.
Open up terminal
change directory to where you extracted recovery.img
type
Code:
fastboot boot recovery.img
See if phone boot into recovery
Next we test an edited recovery.img to see if "fastboot boot recovery.img" is truly letting us boot the image we've specified.
To find out, we're going to use the edited recovery.img and do pretty much the same thing except now with recovery-test.img:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery-test.rar file below and extract it to get recovery-test.img.
Open up terminal
change directory to where you extracted recovery-test.img
type
Code:
fastboot boot recovery-test.img
See if any pictures are upside down (the battery symbol, numbers, or the android robot)
After completing the 2 tasks above, and verifying that we have a valid original recovery.img and that we can use
Code:
fastboot boot recovery.img
to boot a specific image file, we can start testing a very, very, very EXPERIMENTAL Clockworkmod Recovery image using fastboot. I would not rely on this image to make backups and I honestly do not know what kind of damage it might inflict on the phone so make a backup of everything before starting.
output from CWM automatic recovery builder: http://jenkins.cyanogenmod.com/job/recovery/52069/
To test if this CWM recovery image will boot and have the right partition layout:
Go into fastboot mode (step 2f in post #1 of http://forum.xda-developers.com/showthread.php?t=2546455)
Download the recovery.img.
Open up terminal
change directory to where you downloaded recovery.img
type
Code:
fastboot boot recovery.img
If the cwm recovery image boots, type
Code:
mount
See if /sdcard is mounted to the right partition)
If you're feeling lucky, make a backup to /sdcard **this step can cause damage to phone if /sdcard is mounted to the wrong partition**
Thanks for volunteering and bringing the Huawei Prism 2 one step closer to custom roms.

Will test as soon as I get the phone.
I should be getting my phone in the mail Tuesday-Wednesday, but I will test as soon as I get it in the mail and I get my bootloader unlocked. I shouldn't have an issue booting it, since it will boot without effecting my current recovery partition. Hopefully the cwm recovery boots as well.

streetdev22 said:
I should be getting my phone in the mail Tuesday-Wednesday, but I will test as soon as I get it in the mail and I get my bootloader unlocked. I shouldn't have an issue booting it, since it will boot without effecting my current recovery partition. Hopefully the cwm recovery boots as well.
Click to expand...
Click to collapse
Great! I really hope it works. Let me know if I can help with anything in the meantime.

Getting my phone today
My phone is coming today! I will let you know the results either later today or tomorrow. Also, could you pull a build.prop using ADB from your phone? This guy needs it: http://forum.xda-developers.com/showthread.php?p=49494728

niceeeee
Prism 2 said:
Great! I really hope it works. Let me know if I can help with anything in the meantime.
Click to expand...
Click to collapse
I tried them today and they work fine siiiiir. both booted while i was stuck in a boot loop from deleting my settins apk

Cjantolak said:
I tried them today and they work fine siiiiir. both booted while i was stuck in a boot loop from deleting my settins apk
Click to expand...
Click to collapse
Thats good news! Could you state specifically which 2 of the 3 images booted though? I'm assuming the original (recovery.rar file) and the edited (recovery-test.rar file) recovery.images, but want to make sure
In other words, did you test the clockworkmod recovery image?

first two
Prism 2 said:
Thats good news! Could you state specifically which 2 of the 3 images booted though? I'm assuming the original (recovery.rar file) and the edited (recovery-test.rar file) recovery.images, but want to make sure
In other words, did you test the clockworkmod recovery image?
Click to expand...
Click to collapse
I did just boot the clockworkmod recovery and i just booted up fine. os is running as it should other than the whole missing settings app. im stuck without root, without wifi, and usb debugging.
adb not installing the app either so idk.

Thanks for straightening out the confusion. Can you check the mounted partitions are correct? Afterwards you can use update.zip to install your settings.apk
---------- Post added at 01:11 AM ---------- Previous post was at 01:04 AM ----------
Never mind about checking the partition layout. I just remembered you don't have adb. I will try to make a better recovery image.

[Q] ?? How to backup Firmware on stock device

Hello.
I have a Samsung Relay that is rebranded by Cellular One of North East AZ. They have a fancy super thin sticker over the Tmobile logo on the glass. lol... But the firmware in the device is branded by Cellular One.
I cannot find that firmware anywhere and want to know if anyone has any directions on how to back up the firmware so It could be loaded onto a t-mobile Relay to "brand" it for Cellular One.
Appreciate any help you can offer.
Thanks.
(I normally play in CDMA world, but I moved to po dunk nothing ville and VZW Sucks here, so had to go with Cell One. First real experience with GSM)

I've never done this before and I'm not 100% sure if it can be done. But there probably are ways if you're clever enough. So here's what I would try if I were in your position:
1. Check if there's a way to dump it with Odin. You can google around to see if it's possible but I'm pretty sure it's a feature in Odin (Whether our phone supports it is another story). You would have to boot into download mode, (vol down + home + power when powering on) and then follow whatever directions you find for dumping a rom. Just make sure you don't flash anything to your device. And make sure you know what you're doing with Odin because it can brick your phone if you push the wrong buttons.
2. The other way to do it is to dump your partition contents with the dd command (I would do it through an adb shell). This would require you to have root. I'm not sure of how to get root without modifying your ROM (kind of defeats the purpose of what you're trying to do if we have to change the ROM) but there are usually ways to get a temp root. Not sure how to do it on our phone but maybe someone else can help you with that part. Or maybe do some googling. The dd part I've at least done for the boot partition. Basically what you want to do is open an adb shell and run:
"ls -l /dev/block/platform/msm_sdcc.1/by-name/"
This will give you a list of all the partition name symlinks and show you the block devices they point to. For example, when I was getting boot.img I found that the "boot" symlink pointed to "/dev/block/mmcblk0p7". Find all the partitions you want to image in this list and figure out which block devices they point to.
The next part is to figure out how big each of the partitions is. You can find this in /proc/partitions. So from your adb shell you would run:
"cat /proc/partitions"
This will print out all of your flash block devices (look at the ones you were interested in from above). The 3rd column in this list will be the # of blocks in the partition. I believe the block size is 1k (1024 bytes). For example, my boot partition was 10240 blocks which comes out to 10 Megs, which sounds about right. The 1k assumption also agrees with the total device flash size, which is 7634944 blocks (mmcblk0) which is just under the 8GB they say the phone has. So I'm pretty confident about the block size.
So now we're at the part where things get a little hairy. I'm assuming you've found some way to get root in your adb shell. Be very careful with these dd commands and if you don't know what you're doing, don't do it. You would want to run something like the following:
"dd if=/dev/block/<partition name> of=/storage/sdCard/<name of image file> bs=1024 count=<# of blocks for partition you found in /proc/partions>"
You would do this for each partition you want dumped.
Again, be careful if you decide to try and do any of this stuff (especially with the dd commands, if you mix up the in file and out file you can brick your device). But like I said this worked for me to get boot.img and I was able to extract it and get the kernel and ramdisk. Hope this helps and sorry I don't know more about getting you a temp root without modifying your ROM.
Jeff

Can you send me a screenshot of your about phone screen?
Sent from my SGH-T699 using Tapatalk

hello everyone,
i resurrection this thread so bring some information to pepole who want to backup stock rom so they can flash it back with odin.
i constructed a list of partitions names/partition location nb./partition block size for a refreance of what to backup:
block size partition block location partition name
7634944 /dev/block/mmcblk0 Whole SSD on Device
2048 /dev/block/mmcblk0p5 aboot
6144 /dev/block/mmcblk0p20 backup
10240 /dev/block/mmcblk0p7 boot
860160 /dev/block/mmcblk0p17 cache
13952 /dev/block/mmcblk0p11 efs
10240 /dev/block/mmcblk0p19 fota
3072 /dev/block/mmcblk0p21 fsg
5120 /dev/block/mmcblk0p23 grow
61440 /dev/block/mmcblk0p1 modem
3072 /dev/block/mmcblk0p12 modemst1
3072 /dev/block/mmcblk0p13 modemst2
512 /dev/block/mmcblk0p9 pad
10240 /dev/block/mmcblk0p10 param
8192 /dev/block/mmcblk0p16 persist
10240 /dev/block/mmcblk0p18 recovery
512 /dev/block/mmcblk0p6 rpm
128 /dev/block/mmcblk0p2 sbl1
256 /dev/block/mmcblk0p3 sbl2
512 /dev/block/mmcblk0p4 sbl3
8 /dev/block/mmcblk0p22 ssd
1228800 /dev/block/mmcblk0p14 system
512 /dev/block/mmcblk0p8 tz
5386240 /dev/block/mmcblk0p15 userdata
so all you have to do is to use this command via terminal:
"dd if=/dev/block/<partition name> of=/storage/sdCard/<name of image file> bs=1024 count=<# of blocks for partition>"
you can cnange "sdCard" for "extSdCard" if you wish.
this will make you the raw imgae of all partitions and then you will need to use tar in linux to make a tar.md5 file for odin.
use the commands below in terimanl to do so:
"tar -H ustar -c image1 image2 image3 etc... > package_name.tar"
"md5sum -t package_name.tar >> package_name.tar"
"mv package_name.tar package_name.tar.md5"
remember you will need superuser on you phone to do this, also the commands are without the quotation mark.
the only thing left to know is what partitions you must backup to beable to restore fully to stock with/without data.
i know you should backup the boot/efs/recovery/system partitions for clean stock + userdata/cache if you want your data back.
does anybody know of other critical partitions to backup?