• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root OpenVitality ROM in the Works

Great news... I was sitting on Req's CM7 beta for the Admire but data doesn't work for that and he's supposedly fixing it for beta3... But no word when that will be out... So another rom option is excellent.

Thanks for your time! Looking forward to it.
 
Aye. No data for cricket users. *228 doesnt reprogram either (despite the voice msg saying the phones been programmed -- theres no NAM or PRL downloaded commited). And after *228 you lose cell signal all together.
Hopefully on the weekend I can find some time to reinstall cm7 and troubleshoot the issue.
 
I think I'll take Momojams up on his offer; I know a few folks are seeking the Vitality's stock ROM, and I'll help get it to them. What needs to be done in order to get that? Is it simply a matter of using the backup feature of Vitality's stock recovery mode?
 
charssun said:
I think I'll take Momojams up on his offer; I know a few folks are seeking the Vitality's stock ROM, and I'll help get it to them. What needs to be done in order to get that? Is it simply a matter of using the backup feature of Vitality's stock recovery mode?
Click to expand...

Not really.
You need to use dump_image and mkfs.yaffs2 to dump all the partitions to the sdcard in img format.

Heres the 2 utilities off my repo:

http://openzio.rtrnetwork.com/openzio/utils/mkfs.yaffs2

http://openzio.rtrnetwork.com/openzio/utils/dump_image

stick them in /data/misc/ and /system/bin/ respectively then chmod 0755 to both.

The boot and recovery partitions need to be dumped using adb shell as raw image files using dump_image.
The system, data and other partitions need to be dumped using adb shell using mkfs.yaffs2.

dump_image syntax:
Code: 
cd /system/bin
dump_image boot /sdcard/boot.img
dump_image recovery /sdcard/recovery.img

mkfs.yaffs2 syntax:
Code: 
cd /data/misc
./mkfs.yaffs2 /system /sdcard/system.img

Good luck, and post the recovery.img when u get it. I'd love to have a peek at it.

*edit: if you're curious of what partitions exist on the phone just cat /proc/partitions from shell.
 
I've been toying around with the Admires CM7. I've decided Im not going to use it for my OpenVitality ROM as its very much in its beta stage still -- data/MMS issues, 3g connectivity issues (need to toggle wifi periodically to reinitialize 3g connection) -- GPS is broken. Thats just from 2 days of playing.
Since req's kernel and cwm 3.0.2.8 are solid (havent tried the OC kernel yet) Im working on porting our stock ROM over to ext4. So far I have a fully deodexed ext4 pre-rooted ROM booted and working for the Vitality. Wifi and data is broken, everything else seems to be in working order. Im running out of weekend time to develop on this, so its not going to be finished for a while yet, but thought I'd keep y'all abreast of the goings on.

~cheers
 
charssun said:
Is this correct?

dump_image goes in /data/misc/

and

mkfs.yaffs2 goes in /system/bin/
Click to expand...

other way around. dump_image in /system/bin and mkfs in /data/misc

make sure you have at least a few hundred Mb of free space on your sdcard.
 
Spz0 said:
make sure you have at least a few hundred Mb of free space on your sdcard.
Click to expand...

Code: 
df -h sdcard
reports 445M used, 498M free out of 943M. (Dang Muve Music steals the other ~3GB!)

So I ran the commands you provided. I get the following:

Code: 
# /system/bin/dump_image boot /sdcard/boot.img
/system/bin/dump_image boot /sdcard/boot.img
error scanning partitions: No such file or directory

Code: 
# /system/bin/dump_image recovery /sdcard/recovery.im
/system/bin/dump_image recovery /sdcard/recovery.img
error scanning partitions: No such file or directory

Code: 
# /data/misc/mkfs.yaffs2 system /sdcard/system.img
/data/misc/mkfs.yaffs2 system /sdcard/system.img
mkfs.yaffs2: Android YAFFS2 Tool,Build by PowerGUI
            at http://www.openhandsetalliance.org.cn
Building...
Build Ok.

Do you have any idea what the dump_image errors could be caused by? By the way, I'm doing this on a Vitality that is running a custom ROM. Wanted to test this out on my own phone so that I'd know how to instruct the person from Cricket on how to do it on one of the stock Vitalitys.
 
I'm researching how dump_image works, and I'm thinking I'm getting the error because I'm using a custom ROM. I'm guessing that when I run the "dump_image boot...' command it's looking for a partition named "boot" and when I run the 'dump_image recovery...' command it's looking for a partition named "recovery" -- and the partitions are not discovered because they've been renamed by the custom ROM.

Again, this is simply a guess; I'm not positive the custom ROM has changed the partition names. Perhaps you can tell me -- below are the results from when I use the cat command to list partitions:

Code: 
# cat /proc/partitions
cat /proc/partitions
major minor  #blocks  name

   7        0      17703 loop0
   7        1       7308 loop1
   7        2       3150 loop2
   7        3       4190 loop3
   7        4       2111 loop4
   7        5       2111 loop5
 137        0     513024 bml0/c
 137        1       1536 bml1
 137        2        768 bml2
 137        3        768 bml3
 137        4      17920 bml4
 137        5      12800 bml5
 137        6        768 bml6
 137        7       6144 bml7
 137        8       2048 bml8
 137        9      10240 bml9
 137       10      10240 bml10
 137       11        768 bml11
 137       12     191488 bml12
 137       13     209920 bml13
 137       14      34304 bml14
 137       15      13312 bml15
 138       12     184832 stl12
 138       13     202752 stl13
 138       14      30464 stl14
 179        0     967424 mmcblk0
 179        1     966604 mmcblk0p1
 254        0      17703 dm-0
 254        1       7308 dm-1
 254        2       3150 dm-2
 254        3       4189 dm-3
 254        4       2110 dm-4
 254        5       2110 dm-5

Do these partition names look familiar? Or are they completely different from what you'd find in a stock ROM?
 
stl12 is system partition
stl13 is data
stl14 is cache

all the partitions should be symlinked to corresponding names. Odd that this is not working..
unfortunately Im not sure which is the boot or recovery partition.

The partitions may not respond to "boot" or "recovery".. I"ll have to look into it further.
 
Spz0 said:
stl12 is system partition
stl13 is data
stl14 is cache

all the partitions should be symlinked to corresponding names. Odd that this is not working..
unfortunately Im not sure which is the boot or recovery partition.

The partitions may not respond to "boot" or "recovery".. I"ll have to look into it further.
Click to expand...

Thanks for the info.

Look into it at your leisure, and I'll do the same; I'm not trying to put more work on your plate.

I just want to learn as much as I can about some of the processes involved in developing ROMs, and knowing how to obtain an image of an Android ROM might be something useful for me to know. At the least, I'll be able to show someone with a stock Vitality how to obtain that image so that they can revert back to an out-of-box experience if they need or desire to...
 
neither one of those tools are going to work

dump_image works with fastboot only devices.

and you guys dont have yaffs2, like i said its rfs :P
 
Shabbypenguin said:
neither one of those tools are going to work

dump_image works with fastboot only devices.

and you guys dont have yaffs2, like i said its rfs :P
Click to expand...

Thanks for the info., Shabby.

Do you know a method of imaging the stock ROM and the stock recovery image of the Vitality? I'd like to instruct the Cricket employee who posted here on how to get those images.
 
It would be nice to be able to put the stock recovery for the vitality back on and a stock (unrooted/ untouched) image to put the phone back to its original out of the box state. At the moment we only have a nandroid backup of an image that has had a little bit of bloatware removed.
This is located here:
Link: Custom recovery!
I will keep following this post.
 
Shabbypenguin said:
neither one of those tools are going to work

dump_image works with fastboot only devices.

and you guys dont have yaffs2, like i said its rfs :P
Click to expand...

This is not exactly true. You can indeed use dump_image from adb to dump any partition. I've done it myself all weekend. flash_image only works on in fasboot. (for some reason it is not recognizing "recovery" or "boot" but all other partitions in /dev/block/ pull fine)
as for yaffs2 util, I've used it to extract my system partition and data/cache to image files just fine. I then used and unyaffs tool to extract the image files.
In my WIP ROM, Im formatting system and data using yaffs2, and its booting just fine. ;)

On an unrelated note, My phone is borked. lol
I was using dd to extract partitions on my phone when my cat jumped up on my lap, spilling my phone to the ground (which was still dumping a bml partition). The battery flew out, and it powered off -- when I powered up, I found that I had ZERO cell service.. Tried reflashing, going back to stock,, everything. So I concluded that the partition I was dumping when the phone powered off unexpectedly must have had something to do with cell service programming. So I need to take the phone in, and possibly get an exchange (or refund/repurchase) before I can proceed more on this phone. ><
 
Spz0 said:
This is not exactly true. You can indeed use dump_image from adb to dump any partition. I've done it myself all weekend. flash_image only works on in fasboot. (for some reason it is not recognizing "recovery" or "boot" but all other partitions in /dev/block/ pull fine)
as for yaffs2 util, I've used it to extract my system partition and data/cache to image files just fine. I then used and unyaffs tool to extract the image files.
In my WIP ROM, Im formatting system and data using yaffs2, and its booting just fine. ;)

On an unrelated note, My phone is borked. lol
I was using dd to extract partitions on my phone when my cat jumped up on my lap, spilling my phone to the ground (which was still dumping a bml partition). The battery flew out, and it powered off -- when I powered up, I found that I had ZERO cell service.. Tried reflashing, going back to stock,, everything. So I concluded that the partition I was dumping when the phone powered off unexpectedly must have had something to do with cell service programming. So I need to take the phone in, and possibly get an exchange (or refund/repurchase) before I can proceed more on this phone. ><
Click to expand...


you absolutly can make the phone yaff2, just seems a bit... well backwards. rfs was ditched in favor of ext4 so for you to reformat your phone to yaffs2. im really doubting you can use unyaffs to extract rfs since the only way ive found ever is by mounting it as a loop device. (thats how all the new fancy ext4 phones get extracted files too)

using dd to dump stuff would not affect your cell service.

that link i posted earlier was a tar for your device
 
Shabbypenguin said:
you absolutly can make the phone yaff2, just seems a bit... well backwards. rfs was ditched in favor of ext4 so for you to reformat your phone to yaffs2. im really doubting you can use unyaffs to extract rfs since the only way ive found ever is by mounting it as a loop device. (thats how all the new fancy ext4 phones get extracted files too)

using dd to dump stuff would not affect your cell service.
Click to expand...

Feel free to doubt, but it certainly works.
(adb shell)
./mkfs.yaffs2 system /system.img
then (in cmd)
unyaffs2.exe system.img
voila

I'll provide the unyaffs executable if would like to try.

As for my phone issues regarding dd, Im almost positive this was the culprit. not dd itself, but dd'ing a partition when the phone fell.
I have no msl, no meid any longer, I cannot go to "about phone" without crashing com.android.telephone. Deductive reasoning tells me this was the culprit. Still a hypothesis, but seems logical. Any way you look at it, I'll be taking it in tomorrow -- since its still under the 30 day return policy.
 
oh yes, when you dump that partition and make it into a yaffs2 img then certainly... the way you made it sound is that you dumped the image as it should be and used unyaffs.

and no unless you were using dd to write then nothing would have happened. dd reading is completely harmless and on this device all those smaller partitions are extremely small (hell system is only 160MB).

and providing the binary would mean nothing to me.
 
Shabbypenguin said:
oh yes, when you dump that partition and make it into a yaffs2 img then certainly... the way you made it sound is that you dumped the image as it should be and used unyaffs.

and no unless you were using dd to write then nothing would have happened. dd reading is completely harmless and on this device all those smaller partitions are extremely small (hell system is only 160MB).

and providing the binary would mean nothing to me.
Click to expand...

Ahh. I see. :)
I know dd is harmless completely (or should be) - I've been a linux user for over a decade - yet, something borked up completely. o.0 I _guess_ it could have broke the radio transmitter when I dropped it? But that wouldnt account for the blank MEID and PRL numbers I was seeing, or the crashing of com.android.telephone when trying to enter "about phone" settings -- that led me to deduce that it was something in the dump process combined with the drop and battery pull that screwed it. Meh.. All is well.
Went to the corporate store today and swapped out for a new phone, so Im back in business.
Im not going to overwrite the recovery til I find a way to pull it, so Im stalling out on my ROM work til then.
Thank the gods for the 30 day return policy :)
 
Albeit some messed up filenames, I've found a script to extract the images from the smd file located within the tar SP linked to us. Gonna work on getting them mounted to see whats what, but Im mainly concerned with the recovery image.
One image is 3Mb (which is probably the boot image), another is 11Mb (recovery?), and the other is 230Mb (system img? -- seems a bit large).
I'll update once I've got some more time to play around with it.
 
You must log in or register to reply here.
Back
Top Bottom