Edit: Delete me
The Player 5.0 uses RFS and not ext4?
yuck...
BTW, you should be able to identify a kernel zImage by looking at the first few hundred bytes of the partition. I forget the exact thing you should be looking for at the moment.
Kernel is confimed. So is pbl,sbl, and factoryfs.rfs.
I used a hex editor and found the copyright info for the pbl and sbl. The kernel and factoryfs are in a flash I created that has been confirmed to work.
Oh yes, pit confirmed as well. Opened with hex edit.
dbdata, cache, data, and efs are confimed too. Mounted in linux and contents confirmed.
param.lfs is just a guess. It contains images mostly. The images are ones that you would see before android boot such as warning symbols and samsung logo.
Any others are not confirmed.
Sent from my YP-G70 using Tapatalk
If you want, i have
dd if=/dev/block/mmcblk0p10
dd if=/dev/block/mmcblk0p11
dd if=/dev/block/mmcblk0p12
dd if=/dev/block/mmcblk0p13
dd if=/dev/block/mmcblk0p14
dd if=/dev/block/mmcblk0p15
dd if=/dev/block/mmcblk0p16
dd if=/dev/block/mmcblk0p17
dd if=/dev/block/mmcblk0p1
dumps, and I can post them to my ftp server. I believe that p17 is the /sdcard partition, but I may be wrong.
apapousek,
I appreciate the offer and I'll keep it in mind, but I don't see how anything could be gained by having your copies of the dumps. I also wanted to remind you that some of those partitions may have personal data in them. If you want to upload them and put up a link to them, it may help someone, so I would invite you to do so...
Also I believe that you are correct about p17 which I show to be 1.35gb
There is no personal data on them, at all. I used a completely wiped device. The only thing changed in it was the time zone, and that it was rooted. The images could be used for recovery purposes, and seeing the differences between the devices.
Oh I see, with this map and those files, a complete recovery( or very close to it) could be created. I would love to have these files! Is the model the same? YP-G70CWY/XAA?
Meticulus said:
Oh I see, with this map and those files, a complete recovery( or very close to it) could be created. I would love to have these files! Is the model the same? YP-G70CWY/XAA?
Click to expand...
Click to collapse
My device says it is a YP-G70, no numbers following it. The partition layout could be the same. If you have a copy of your pit file, I could use diff to see if there are any real differences. If you want, I'll allocate you some room on my server and give you an ftp account to work with.
Here is an easy way to check if you have XAA version (may need root). Browse to /efs and open the "buyer_code.dat" file as text. The only thing in there should be "XAA". You can also open "/system/build.prop" as text and find "ro.csc.sales_code" and it should = "XAA". It's important to know which one this is. The US version that I have has capacitive buttons on the botton while the international ones have a hardware button in the middle. So the firmwares are not interchangeable between these models. The partition tables may be the same but I suspect that the capacitive buttons driver is simply not included with the international ones.
I do have the pit file included in the firmware I created and posted at samfirmware.com . Last link in original post above. There are 3 links in the samfirmware.com thread. 2nd and 3rd both have pit.
Thank you for the ftp space. May I use this as a mirror for my files pertaining to the YP-G70? Can I count on this space to remain active within reason?
Meticulus said:
Here is an easy way to check if you have XAA version (may need root). Browse to /efs and open the "buyer_code.dat" file as text. The only in there should be "XAA". You can also open "/system/build.prop" as text and find "ro.csc.sales_code" and it should = "XAA". It's important to know which one this is. The US version that I have has capacitive buttons on the botton while the international ones have a hardware button in the middle. So the firmwares are not interchangeable between these models. The partition tables may be the same but I suspect that the capacitive buttons driver is simply not included with the international ones.
I do have the pit file included in the firmware I created and posted at samfirmware.com . Last link in original post above. There are 3 links in the thread. 2nd and 3rd both have pit.
Thank you for the ftp space. May I use this as a mirror for my files pertaining to the YP-G70? Can I count on this space to remain active within reason?
Click to expand...
Click to collapse
Yes, I'm running with the XAA model. I do have capacitive buttons. I'll PM you with your ftp credentials. You may use this as a mirror for the YP-G70, and for any Galaxy Player you feel like. It should stay active for a year or so, I'm renewing it today, actually.
apapousek said:
Yes, I'm running with the XAA model. I do have capacitive buttons. I'll PM you with your ftp credentials. You may use this as a mirror for the YP-G70, and for any Galaxy Player you feel like. It should stay active for a year or so, I'm renewing it today, actually.
Click to expand...
Click to collapse
Hey, I have the same model XAA, do you have some rom for this device…??? I can’t find anything…
If you have some, could you send me a PM with a link …???
Thanks…
Link to ROM file
The link to the ROM file doesn't work, is there any updated URL list?
Thanks
Related
So far I have tested redbend_ua for backup purposes, and got the bml7 and bml8 partitions backed up, and tested just restoring the bml8 partition with the clockwork recovery that is being tested on the epic. The utility did write the image / partition correctly (afaik) and rebooted the phone upon completion. The phone booted correctly to android, but then upon another reboot to test recovery, it just boot loops, even a normal boot and trying to get to the downloader mode.
This utility seems to work and do what it was meant to, but i would not use this tool without knowledge of what you are doing. On that note, i will not post a link to the tool, just as a safeguard, for now at least.
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
z4ziggy said:
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
Click to expand...
Click to collapse
Both cache and dbdata can largely be ignored; I actually had to nuke my /dbdata partition earlier due to something I did. It gets rebuilt on boot, it's just a SQLite store for the applications and on most Android phones resides within /data. No idea why Samsung felt it necessary to separate this partition.
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
z4ziggy said:
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
Click to expand...
Click to collapse
I did some more testing and can confirm that cache and dbdata can both be empty on boot.
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
z4ziggy said:
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
Click to expand...
Click to collapse
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
fallingup said:
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
Click to expand...
Click to collapse
Yeah.. I could've used that yesterday too.. I ended up swapping out my device this morning.
Sounds like some progress is being made. Very good to hear confirmation on cache and dbdata
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
fallingup said:
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
Click to expand...
Click to collapse
Glad to hear it.. I was getting seg-faults trying to mount /system .
Hello:
I'm attempting to create a custom rom for my Samsung Galaxy S Vibrant. I've downloaded a firmware for my phone (UGJK3), but I've run into a small problem: Samsung doesn't seem to use the default "system.img, boot.img, etc" file structure, and instead uses various factoryfs.rfs, zImage, etc files.
I'm unable to cook my rom using the HTC android kitchen due to this problem: I'm required to have the *.IMG files in order to cook it.
I've mounted the .RFS files in linux, but it has gotten me no closer.
This problem is probably quite easy to fix, I'm just unsure where to start.
Any help is appreciated,
thanks.
It seems like other folks are making flashable zips. I just grabbed one and it's setup very similar to ours, although it appears that the kernel is done differently.
http://forum.xda-developers.com/forumdisplay.php?f=711
Existence. said:
Hello:
I'm attempting to create a custom rom for my Samsung Galaxy S Vibrant. I've downloaded a firmware for my phone (UGJK3), but I've run into a small problem: Samsung doesn't seem to use the default "system.img, boot.img, etc" file structure, and instead uses various factoryfs.rfs, zImage, etc files.
I'm unable to cook my rom using the HTC android kitchen due to this problem: I'm required to have the *.IMG files in order to cook it.
I've mounted the .RFS files in linux, but it has gotten me no closer.
This problem is probably quite easy to fix, I'm just unsure where to start.
Any help is appreciated,
thanks.
Click to expand...
Click to collapse
gnarlyc said:
It seems like other folks are making flashable zips. I just grabbed one and it's setup very similar to ours, although it appears that the kernel is done differently.
http://forum.xda-developers.com/forumdisplay.php?f=711
Click to expand...
Click to collapse
Yeah, I've noticed that, however I'd prefer to work with a kernal and ROM that is stock; that is, hasn't been modified at all. I was able to import a custom ROM into the kitchen that has already been modified (namely Doc's rom), but I view this as a learning experience, and would ideally like to de-odex, zipalign, remove bloatware, etc etc myself.
I'd imagine there would be a veary easy way to change this .tar file to a flashable zip, however I'm at a loss on how to do this.
If someone created a flashable, stock, UGJK3 rom, that would be different, and I'd be able to work with that.
Existence. said:
Yeah, I've noticed that, however I'd prefer to work with a kernal and ROM that is stock; that is, hasn't been modified at all. I was able to import a custom ROM into the kitchen that has already been modified (namely Doc's rom), but I view this as a learning experience, and would ideally like to de-odex, zipalign, remove bloatware, etc etc myself.
I'd imagine there would be a veary easy way to change this .tar file to a flashable zip, however I'm at a loss on how to do this.
If someone created a flashable, stock, UGJK3 rom, that would be different, and I'd be able to work with that.
Click to expand...
Click to collapse
Sure. I like to start with as close to stock or source if possible too. I'm just wondering if there's a how-to in the Vibrant forum or if those folks might know better than those of us who don't have Vibrants. I recently tried helping a friend to root his Vibrant and it was different enough for me to get lost.. .
gnarlyc said:
Sure. I like to start with as close to stock or source if possible too. I'm just wondering if there's a how-to in the Vibrant forum or if those folks might know better than those of us who don't have Vibrants. I recently tried helping a friend to root his Vibrant and it was different enough for me to get lost.. .
Click to expand...
Click to collapse
Yeah, I've already posted a thread in the Galaxy I9000 Q&A section of the forum, but to no avail (not the Vibrant section, as the T-Mobile US-variant differs from my Bell-based Vibrant). I was thinking, what if I install the UGJK3 stock rom on my phone, take a nandroid backup, then use the .IMG files in that backup in the kitchen?
Eh, it's worth a try. I'll see how it goes.
Existence. said:
Yeah, I've already posted a thread in the Galaxy I9000 Q&A section of the forum, but to no avail (not the Vibrant section, as the T-Mobile US-variant differs from my Bell-based Vibrant). I was thinking, what if I install the UGJK3 stock rom on my phone, take a nandroid backup, then use the .IMG files in that backup in the kitchen?
Eh, it's worth a try. I'll see how it goes.
Click to expand...
Click to collapse
okay so was there anything to report because i am on this trek myself at the moment and am looking for any pockets of air as i feel i am drowning in the ocean of dead ends!
Okay, I'm feeling kind today, so here goes:
SAMSUNG ODIN ROMS – Applies to Galaxy S and all derivatives (Vibrant, Captivate, etc)
For anyone unaware, ODIN is the Samsung equivalent of HTC’s RUU. Both are full ROMs containing the images, and both can only be installed via Windows. The ODIN ROMs can be used to restore a semi-bricked phone, that won’t boot to recovery or into the full OS, as all that is needed is Download mode. Download mode is simply accessed by unplugging the phone from the USB cable, holding the volume buttons and plugging in!
BEFORE YOU START, YOU WILL NEED:
- Windows & Relevant ODIN drivers (note – if you’re on 64 bit, you will need to disable signature enforcement on boot before ODIN will work)
- A Linux installation (possibly OS-X, but I haven’t written this guide for that)
So... Working on ODIN roms is a little different to typical ROM ‘cooking’ (I hate that term by the way... cooking can be applied to winzip warriors.. what we're doing here is a tad more technical).
1. First, flash the base ROM using ODIN. Be sure it is a pre-rooted version, or at least root it yourself after.
2. Install an FTP server app to the phone, and connect to it via your computer. It can be done using file managers and shell commands, but will take you ages.
3. Mount system as read write:
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
4. Once you’ve found the issues/things you'd like to change, make the changes directly on the phone itself using FTP/filemanager/shell commands
Add custom boot, build.prop, sounds, fonts, whatever you want (SEE NOTES).
5. Once you’re happy with the build, it’s time to dump the necessary partitions to build the ODIN rom.
To do this, you will need to install a terminal emulator or use adb shell, and ensure the ROM has root access & SU. Let’s work on the assumption that if you’re reading this, you know roughly what you’re doing.
In terminal, type the following commands to dump the /system partition, cache (not necessary), zImage (kernel) and modem.bin (radio) to the INTERNAL SD Card:
su
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
dd if=/dev/block/bml12 of=/sdcard/modem.bin bs=4096
6. You’ll need to boot into your Linux machine/VM. The next step is to create the tarball of the dumped partitions. Do this by typing the following command into the Linux terminal:
tar -H ustar -c factoryfs.rfs cache.rfs modem.bin zImage > gals.tar
OPTIONAL:
7. Next, md5 it up, as ODIN can check the md5 before writing the image. Do this with the following command:
md5sum –t gals.tar >> gals.tar
mv gals.tar gals.tar.md5
8. Contratulations! That’s your ODIN flashable ROM.
9. You will need a PIT file in ODIN to flash this ROM. This can be obtained by Googling for it, or by asking me... or if you need to know how to make you’re own, it’s a piece of piss, just dump it in the same way as above.
su
dd if=/dev/block/bml2 of=/sdcard/FILENAME.pit bs=4096
More congratulations: you can now do the job of Samsung.
PS - please, oh please, can we stop calling it cooking?
You said:
nprussell said:
Add custom boot, build.prop, sounds, fonts, whatever you want (SEE NOTES).
Click to expand...
Click to collapse
Any chance you have a link to said notes? I would like to read further if they exist.
nprussel: How would you go about creating a CWM flashable version instead of Odin?
Edit: Found this guide, but it's geared towards creating an update.zip for specific purposes instead of for a full rom. Its there a way to automatically generate the update-script for a full stock rom? Maybe just by doing a nandroid backup like the OP suggested?
http://www.londatiga.net/it/how-to-create-android-update-zip-package
nprussell said:
Okay, I'm feeling kind today, so here goes:
SAMSUNG ODIN ROMS – Applies to Galaxy S and all derivatives (Vibrant, Captivate, etc)
For anyone unaware, ODIN is the Samsung equivalent of HTC’s RUU. Both are full ROMs containing the images, and both can only be installed via Windows. The ODIN ROMs can be used to restore a semi-bricked phone, that won’t boot to recovery or into the full OS, as all that is needed is Download mode. Download mode is simply accessed by unplugging the phone from the USB cable, holding the volume buttons and plugging in!
BEFORE YOU START, YOU WILL NEED:
- Windows & Relevant ODIN drivers (note – if you’re on 64 bit, you will need to disable signature enforcement on boot before ODIN will work)
- A Linux installation (possibly OS-X, but I haven’t written this guide for that)
So... Working on ODIN roms is a little different to typical ROM ‘cooking’ (I hate that term by the way... cooking can be applied to winzip warriors.. what we're doing here is a tad more technical).
1. First, flash the base ROM using ODIN. Be sure it is a pre-rooted version, or at least root it yourself after.
2. Install an FTP server app to the phone, and connect to it via your computer. It can be done using file managers and shell commands, but will take you ages.
3. Mount system as read write:
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
4. Once you’ve found the issues/things you'd like to change, make the changes directly on the phone itself using FTP/filemanager/shell commands
Add custom boot, build.prop, sounds, fonts, whatever you want (SEE NOTES).
5. Once you’re happy with the build, it’s time to dump the necessary partitions to build the ODIN rom.
To do this, you will need to install a terminal emulator or use adb shell, and ensure the ROM has root access & SU. Let’s work on the assumption that if you’re reading this, you know roughly what you’re doing.
In terminal, type the following commands to dump the /system partition, cache (not necessary), zImage (kernel) and modem.bin (radio) to the INTERNAL SD Card:
su
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
dd if=/dev/block/bml12 of=/sdcard/modem.bin bs=4096
6. You’ll need to boot into your Linux machine/VM. The next step is to create the tarball of the dumped partitions. Do this by typing the following command into the Linux terminal:
tar -H ustar -c factoryfs.rfs cache.rfs modem.bin zImage > gals.tar
OPTIONAL:
7. Next, md5 it up, as ODIN can check the md5 before writing the image. Do this with the following command:
md5sum –t gals.tar >> gals.tar
mv gals.tar gals.tar.md5
8. Contratulations! That’s your ODIN flashable ROM.
9. You will need a PIT file in ODIN to flash this ROM. This can be obtained by Googling for it, or by asking me... or if you need to know how to make you’re own, it’s a piece of piss, just dump it in the same way as above.
su
dd if=/dev/block/bml2 of=/sdcard/FILENAME.pit bs=4096
More congratulations: you can now do the job of Samsung.
PS - please, oh please, can we stop calling it cooking?
Click to expand...
Click to collapse
Ok, so I'm trying to create a Factory Odin Flash for the Samsung Galaxy S Showcase.. (brother of the fascinate and Mesmerize)...
I've followed your instructions (step 5-9) to a T, using a Rooted Showcase...
But it fails..
Here the start of the Thread
This is the post of the guy that tested it HERE
Guys ANY info you can help me with this would be GREATLY appreciated, because as of now we have no way to get back to stock!!!
I'm trying to create an Odin Flash now using MY files. I'm on a deodexed PicknPack Rom/Voodoo Kernel. There's several people that have messed up phones and are simply trying to get on our network, so I'm hoping I can atleast help them with that..
Thanks in advance,
elijahblake
nprussell said:
Okay, I'm feeling kind today, so here goes:
SAMSUNG ODIN ROMS – Applies to Galaxy S and all derivatives (Vibrant, Captivate, etc)
For anyone unaware, ODIN is the Samsung equivalent of HTC’s RUU. Both are full ROMs containing the images, and both can only be installed via Windows. The ODIN ROMs can be used to restore a semi-bricked phone, that won’t boot to recovery or into the full OS, as all that is needed is Download mode. Download mode is simply accessed by unplugging the phone from the USB cable, holding the volume buttons and plugging in!
BEFORE YOU START, YOU WILL NEED:
- Windows & Relevant ODIN drivers (note – if you’re on 64 bit, you will need to disable signature enforcement on boot before ODIN will work)
- A Linux installation (possibly OS-X, but I haven’t written this guide for that)
Click to expand...
Click to collapse
Windows is not needed to flash ODIN packages. You can use an alternate open-source software called Heimdall, which is considered by many to be more stable than ODIN. Heimdall is available for Linux, MacOS, and yes even Windows. There is also a GUI, compiled for those platforms (except Linux 32-bit, have to do it yourself or use command-line. 64bit Linux has a compiled version of GUI available)
I have only needed Heimdall once so, but it was easy to use the command-line text from the example given-- I guess maybe I'll learn more complex bits as I soft-brick more times ;-)
The main difference seems to be that you uncompress the ROM archive first, but maybe they will add support for opening the archives (tar files) within Heimdall.
William
Linux FTW! (the others parts could prob be done on Windows somehow, but as our phones run Linux, everything needed is there or easier to install)
Is there a way to port an HTC rom to the vibrant or say the Galaxy Tab (preferred)?
There is a flavour of the Android Kitchen made for the Galaxy S, if you're lazy and/or need some hand-holding: ;-)
It's by RMGeren but still in a beta stage:
https://github.com/dsixda/Android-Kitchen/tree/galaxy_s
Just click on the "Downloads" link on the top right part of the page.
@nprussel: Thanks for that detailed guide!
First off, all credit should go to imnuts for this. With his permission, I have copied his guide from the Droid Charge forums and tweaked it slightly to apply to the Fascinate and added some notes. Also, I'd like to thank vegitoss who helped me figure out partitions I was having trouble with.
This will allow you to backup your system and create custom Odin images for restore purposes. I would still recommend that you try to do a nandroid or titanium backup first. Don't bring out the big guns unless you need them.
The goal here is to produce a .tar.md5 file that is flashable in Odin based on your current ROM install. The .tar.md5 files are .tar files with the md5 checksum added to the end of the file. If you attempt to flash a .tar.md5 file, Odin will automatically check that the contents are what they should be before flashing and proceed with the flash if the md5 is valid, otherwise it will stop.
In Odin, you should use the PDA button for all flashing. The PIT button may be used as well, if we can get a valid .pit file for the device, but for now, PIT won't be used either. Other than PDA, Start/Reset are the only other buttons you need to worry about.
Now, on to creating the backup files. First, you will need your device to be rooted (perm or temp root will work), and you also need to have access to terminal on the phone, either via an emulator or adb shell access. To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package.
The following will output the files on the root of the SDCard, adjust the "of=" path if you want them somewhere else. It will also create the files for the proper filename for Odin as well. So to create the files, here are the commands you will use from root shell (#):
System:
Code:
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
Kernel:
Code:
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
Recovery:
Code:
dd if=/dev/block/bml8 of=/sdcard/recovery.bin bs=4096
DO NOT INCLUDE THE FOLLOWING IN ANYTHING BUT A PERSONAL BACKUP
Cache:
Code:
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096
DBData:
Code:
dd if=/dev/block/stl10 of=/sdcard/dbdata.rfs bs=4096
Data:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/movinand.bin bs=4096
The last three files (cache, dbdata, data) may contain personal information, so do not include these 3 files in anything but a personal backup/recovery package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
]If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
There are other files that may be in Odin packages, but they are protected by Samsung and cannot be dumped properly. The files are the bootloader, secondary bootloader, modems, and .lfs partitions. The files would be boot.bin, Sbl.bin, modem.bin , and param.lfs. It however isn't that big of an issue that these can't be dumped as the can't really be altered by normal flashing of the device, and are usually only altered via OTA updates.
Some additional notes:
* You can skip the process of making a .tar.md5 and just use heimdall for everything except your user data (if anyone knows how to do this please let me know and I will edit it in.)
* Be sure you have at least 2GB free on your SD card if you plan to include personal data.
* If you need help in using Odin/Heimdall, I'd recommend you read DaleV's great guide here. In fact, I recommend you read it regardless as it's a good refresher.
I was just going to post and ask for a guide to be adapted from the post in the charge forums ;-) except, don't we have a valid PIT file for the fascinate?
I definitely see myself using this, simply because with all the different versions of clockwork out there, and MTD vs BML, nandroids don't seem to be a one click solution.
Thanks for the guide!
I know we have a valid .pit file for certain Odin packages. I'm unsure if they can be used universally (across froyo builds) though. If we can get a concrete answer that they can, I would be more than happy to update the guide further.
ah, ok. Didn't think about that part. And does this matter if we have voodoo installed or no?
I'm voodoo'd. I tested it on my own device and didn't run into any issues.
Btw, P3 release an application that does EXACTLY the same thing as this. If you feel comfortable following instructions you can save yourself the $2 by following this guide.
bobloblaw1 said:
Btw, P3 release an application that does EXACTLY the same thing as this. If you feel comfortable following instructions you can save yourself the $2 by following this guide.
Click to expand...
Click to collapse
You could even make a shell script to do those commands to make it easier for people, and it would probably take some more people away from p3's app.
This is wonderfull ! Could i also back up my radio via this? Or is that part of samsungs protected stuff?
Thank you for this for sure.
Sent from my SCH-I500 using XDA App
Anyone here can tell me how do I do the same, but for ICS? Partitions look completely different there, I tried to make a package, but it doesn't work
Odin will only work with TouchWiz(BML) based roms
Hey guys.. Odin3 version3 and higher has gz support. I've been working with this for a bit and tonight I found that Odin will accept tar.md5.gz files. This is important for GNote2 users as the stock ROM is 1.2Gigs! You can get an extra 10-40% compression and 100% gaurantee that the files arrive to your users computer in the condition that you packaged them using this method. I have not found a guide on using the gz format so I thought I would write one up.
You will need:
A Linux computer
Your rom (we will call it MyROM)
How to package for Odin on Windows
I will cover packing into a single file, adding an MD5, and compressing the file down. For the purposes of this, we are working with "MyROM". You will want to call your ROM whatever you like. Just make sure to add version information to the file name so users don't get confused. Also note, the name MUST be consistent throughout the process. If you change the name, Odin can fail.
Another good tip is to put a model number in the name so there is no confusion as to what device your Odin package goes to. Several users, myself included, have 20+ Odin packages on their computer.
So first you want to turn the ROM into a single tar file and then make sure changes are written to the disk.
Code:
tar -H ustar -c boot.img hidden.img modem.bin param.bin recovery.img system.img tz.img sboot.bin>./MyROM.tar;sync;
Next we want to add an MD5 to the file so Odin can check its consistancy.
Code:
md5sum MyROM.tar >> MyROM.tar;
Now we will change it into a tar.md5 file so Odin knows it has an MD5 attached to it.
Code:
mv MyROM.tar MyROM.tar.md5; sync;
Finally we will compress it with GZip. GZip is the only compression method supported by Odin.
Code:
gzip MyROM.tar.md5 -c -v > MyROM.tar.md5.gz;
You will now have a file called MyROM.tar.md5.gz.
Conclusion
The first time the file is flashed, Odin will uncompress it into MyROM.tar.md5, then check its consistancy, then flash the file. Using this method you will be transferring the smallest file possible and adding integrity checks.
notes
Note to Verizon GNote2 users: Stay away from using Odin after IROM unlock as flashing a package intended for another device will perma-lock your device into another carrier's bootloaders. Especially stay away from GS3 as the displays are not compatible.
good ****! this is def useful
Awesome news! Any test results with the older versions? If not one click solutions may not benefit.. but servers and users will by cutting the downloads even more!
Sent from my SPH-L900 using Tapatalk 2
Windows OS
How can I do it on a Windows computer?
MAQ7 said:
How can I do it on a Windows computer?
Click to expand...
Click to collapse
Install Virtual Box and a Linux distribution. I haven't seen any tools for Windows that work properly to make tar archives that work with Odin.
cygwin.
Mine all work
imnuts said:
Install Virtual Box and a Linux distribution. I haven't seen any tools for Windows that work properly to make tar archives that work with Odin.
Click to expand...
Click to collapse
adrynalyne said:
cygwin.
Mine all work
Click to expand...
Click to collapse
I managed to make tar on Windows using cygwin :good:.
Thank you
Interesting adam, I always compressed the whole odin package into a rar file (same effect but one step extra). Also I made an article about odin a while ago:
http://broodplank.net/?p=496
Btw, did you know that you can put cwm backups (ext4.tar) inside an odin package? It's the first odin image I ever saw, filled with a CWM backup, and yes it works XD
But it's not an 1:1 copy of course, Also I wonder how nandroid backups actually store their permissions, I mean dd is a 1:1 dump, which is logical, cwm has the updater-script. but the nandroid backups which are actually just tar files packed with the contents, how do they store it?
Last thing, Odin packages can be a last resort fix, believe me, many users reported that flashing my rom broodROM_RC5.tar.md5 (which contains about 13 files, you can imagine how many partitions it includes) fixed their phone when nothing else worked.
So thank you Samsung for leaking your tool, A world with Samsung Kies only would be a very sad "softbricky" world
broodplank1337 said:
But it's not an 1:1 copy of course, Also I wonder how nandroid backups actually store their permissions, I mean dd is a 1:1 dump, which is logical, cwm has the updater-script. but the nandroid backups which are actually just tar files packed with the contents, how do they store it?
Click to expand...
Click to collapse
TAR files preserve file permissions.
I still like making a 7z out of the final .tar.md5 file.
The info in OP is great to know as it does save a step for the end user but I'd rather them take a couple steps to vet out the incompetent ones. Could prevent a brick
mrRobinson said:
I still like making a 7z out of the final .tar.md5 file.
The info in OP is great to know as it does save a step for the end user but I'd rather them take a couple steps to vet out the incompetent ones. Could prevent a brick
Click to expand...
Click to collapse
Only on the Verizon Galaxy Note. All others are IROM locked. The IROM lock prevents flashing of an improper SBOOT. An unlocked VZWGNote 2 can flash any SBOOT.
Other than this specific case, adding third party tools other than ZIP compression means your user must download special tools.
Extra files?
If I were to pack an extra README.txt file into the tar before prepping it for Odin, would Odin then ignore it during the flash? Obviously there's no entry for what to do with an extraneous text file in the pit, so hopefully Odin would just disregard it.
I happened to find out today that heimdall has support for "Heimdall Firmware Packages." You can read and write them from the heimdall frontend (the 1.3 FE binary is forward compatible with my source built 1.4 heimdall). What's interesting, is that the format is almost identical to odin's format. It is still packaged in a tar file, and it contains the same system.img, boot.bin, recovery.bin etc. files you'd find in the Odin tar. By default it's format is Package.tar.gz. The only significant difference is the addition of a firmware.xml file that identifies the proper partition for each image file, as well as the target platform, the author, and other details like that.
So I got curious. I took a Package.tar.gz file generated by heimdall, and repackaged it as a Package.tar.MD5.gz file. Heimdall has no problem reading this! So the upshot is, Odin now handles the .gz, so as long as Odin isn't bothered by an extra firmware.xml file inside the tar, the same format would be compatible with either tool.
PS> Don't flame me about flash counters or bricked phones. I do understand that Odin/Heimdall are only particularly relevant for returning a phone to stock, but that's still a very important functionality and it would be great to have a unified format.
Hi all, researcher and enthusiast,
I own a complete backup of all partition of the LG P990 with stock ICS, made it with nvflash with a command like this,
Code:
nvflash -r -read <-partition number-> my_partition.img
for all the partition listed in the partition table.
I guess that in someone of that raw image file, (outputted by nvflash), is located the entry system partition, (PartitionId=23 for the LG P990 ICS partition layout).
It's easy for every linux user to mount the raw image file, simply with 'mount' utility.
Browsing them we can find as already hypothesized the entrie android system partition!
If I copying in it the 'su' executable compiled for my platform, it could work?
Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.
louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.
Click to expand...
Click to collapse
Thanks! I'll have a close look to your work now, for others that consider this stuff interesting, louiscypherbr's work is here:
http://forum.xda-developers.com/showthread.php?t=2010671
Nice job!
louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
Click to expand...
Click to collapse
Ok louis, but the partition23 image file after adding su binary or other things is bigger than the previous that we had read with nvflash, right?
If I flash back it with
--bl fastboot.bin --download 23 image.img
how can this work..?
In the part table is write that have been reserved 536.870.912 bytes for the partiton 23, but we want flash an img file bigger than that size (because we added some stuff), this not causes problem?
And what do you mean for careful?
The extracted file is a dd partition image, meaning it's extracted byte by byte. So it includes the empty space, which you can see with "df" command after mounting it.
You can add files that fit in that position and it will be ok when flashed.
Do not say "thanks"; just press it under here.
Stupid thing! You're right!
And, what you mean for careful with perm?
The su binary should be have the setuid bit set in addition to the obvious x, is this enough?
Have you compiled su by yourself...?
louiscypherbr said:
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Click to expand...
Click to collapse
Where have you found the executable of su packed in your v28g louis...???
Hey, sorry for being far from this.
What I was talking about permissions is that you should keep su permissions/owner. I did this just copying the su from a rooted Rom zip to /system/xbin and pasting inside your loop mounted /system with file manager (I'm kde fan, so I used dolphin, the kde graphical file manager, but you can use any other as well).
Sent from my LG-P990 using xda app-developers app