The question has been asked several times. Recently a senior member asked a similar question and was told to read post two of a thread. That post did not answer the question but created more doubt. So Im going to steal some information from various posts to hopefully clarify this. Please if I get anything wrong let me know so I can correct it. But most of this will be stripped from various posts.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
What does it mean for me as an end user?
As an End User, MTD is an opening to a new life for the Galaxy S 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we have that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.
Click to expand...
Click to collapse
Basically, the internal storage on your phone is a flash device.
BML and FSR (aka XSR) acts as a software-based FTL (Flash Translation Layer).
This allows you to put filesystems like fat or ext4 on a flash device.
Hardware FTLs are everywhere. Look at your memory stick for instance. There is an FTL between the usb device controller and the nand flash chips that actually store the data. You can format your memory stick with ext4, btrfs, ntfs, whatever...
Samsung decided to go further down the rabbit hole with RFS, which is basically a modified version of FAT(32?) with ACLs and Journalling. IMO, silly.
BUT, fsr/rfs are proprietary modules and are built with a kernel that has a set of symbols exposed. If I disabled debugging (like I did) and something in one of those fsr/rfs modules depended on it, then the fsr/rfs modules wouldn't load (unless you trick it).
Moving to controlling the flash on the phone (in which the flash type on this phone isn't nand, but OneNAND-Flex) with MTD gets us away from the proprietary modules, but introduces a new problem. Can't use ext4 for /system, /data, and /cache anymore. Instead you have to use a flash filesystem, like yaffs2 (which is what the CM supported Samsung phones use). I would like to see a test on this phone with UBI/UBIFS though. I think that might have better performance then yaffs2 or jffs2 (but almost everything, including my grandma is faster then jffs2... seriously).
Click to expand...
Click to collapse
Mtd is the open source partition system used by aosp. Doing so allows more flexibility in porting roms and building from source. The proprietary stuff can be removed and get away from having to keep things like VVM for voicemail **.
This also moves us more towards vanilla android experience. Getting rid of proprietary file systems and and apps and various things to work properly.
Stolen from this thread and this post.
**note Antonx has found a way to remove the requirement for VVM. But is still working out if removing the code will break VVM for those people that use it.
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
itzik2sh said:
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
BML -> MTD will be a non-issue now since as of the latest commits I made to the CM7 update system (and whatever MTD roms base themselves off of that) we will be able to flash using only the rom.zip. You no longer need to fiddle with the efs backup/restore since the rom.zip will take care of it for you. The basic procedure will be
Reboot to RED cwm
Flash rom.zip
You will be rebooted to BLUE cwm
Flash rom.zip again
I just tested this myself from a completely stock KJ6 install and got onto a working CM7 install using a build I just made (with working IMEI/network/data) using those exact steps.
EDIT
Going back to BML will require a one-click for the time being until we can find a better solution, preferably one that involves CWM
One thing I didn't understand - why do we need a separated one click flash just for bootloaders? Can't it be done on the same time?
2nd, do we really need the bootloaders flash if we move from GB MTD to GB BML?
I assume I can odin just the kj1 kernel after the stock one click, just to get root. Do we have an odin version of AntonX's 1.1.0 kernel?
Sent from my SGH-T959V using xda premium
Well the bootloaders aren't a problem if the person is already on gingerbread. I had been messing with flashing bootloaders via CWM a while back but that just got my phone bricked. Until someone with unbrickablemod helps me test this or I get my own phone ubm'd, we'll have to do it this way.
No, you don't need to flash bootloaders all the time. The only times you need bootloaders are from GB -> Froyo or Froyo -> GB.
You should look into making your own custom one click, it's as easy as opening the .jar file in a program like 7-zip and extracting the files within, then you can recompress them. You can customize exactly what gets installed. I say you start with bhundven's kj6 one click and replace the kernel with your favorite custom one.
The files that get flashed from a one click are these:
one-click.jar/com/AdamOutler/HeimdallOneClick/resources/ROMPackage/HeimdallPackage.tar.gz
If you open that, you'll see all the files that get flashed, particularly zImage and zImage-1.
zImage gets flashed into the KERNEL partition
zImage-1 gets flashed into the RECOVERY partition
As it stands now, both zImage and zImage-1 should be identical since we don't have any recovery images and we have to use a kernel image instead.
Related
Anybody know what file system the (untouched) Nexus S might be rocking? RFS?
no.........
demo23019 said:
no.........
Click to expand...
Click to collapse
Is that "no" as in "nobody knows," or is it "no" as in "it is not RFS"?
no its not sporting RFS
Its completely stock 2.3 samsung has no involvement in software
Aqua1ung said:
Is that "no" as in "nobody knows," or is it "no" as in "it is not RFS"?
Click to expand...
Click to collapse
A rep from Google already said, they are using ext4.
http://forum.xda-developers.com/showpost.php?p=9627089&postcount=49
If it's not RFS then I guess the dream of Gingerbread being easily ported to other Galaxy S phones is dead. At least I think that's the case.
Dougefresh91 said:
If it's not RFS then I guess the dream of Gingerbread being easily ported to other Galaxy S phones is dead. At least I think that's the case.
Click to expand...
Click to collapse
Why? We already have Voodoo, that does the same thing in Froyo. The way the Nexus S is set up in terms of filesystem is very similar to the way a Galaxy S running Voodoo is set up. There are some differences in how the partitions are set up and yaffs being used on /cache. But the overall differences very small, and minor changes in the init scripts on the ramdisk packed in the kernel will take care of all the mounting.
I have my Vibrant converted to ext4 with the Obsidian ROM, but that only changes a partition as far as I know, not the whole phones data. Not sure about VooDoo as it would never work on my device.
Some people have been speculating that it'd be easy to get a Nexus S ROM ported over since they're both on T-Mob. I was assuming that since the file systems are different that this isn't the case. Look at how much trouble they're having getting the Cyanogen Mod working on the Vibrant.
Believe me, I'd love it if it really is a simple process for devs, but I have a feeling that that's not going to be the case. Again, I'm just speculating, I'm no dev.
I don't think it will be that difficult, because file systems can be changed - indeed, there are already lagfix kernels for the Galaxy S which eliminate the use of RFS entirely. Provided the kernel has support for ext4, the partition can just be formatted that way and mounted appropriately.
I hope you're right. If so then there's no reason at all for me to trade in my Vibrant for the NS. Lord only knows when Samsung will get it's act together concerning updates, so I think this is my only hope of ever seeing Gingerbread on this phone.
rajendra82 said:
Why? We already have Voodoo, that does the same thing in Froyo. The way the Nexus S is set up in terms of filesystem is very similar to the way a Galaxy S running Voodoo is set up. There are some differences in how the partitions are set up and yaffs being used on /cache. But the overall differences very small, and minor changes in the init scripts on the ramdisk packed in the kernel will take care of all the mounting.
Click to expand...
Click to collapse
YAFFS/YAFFS2 and JFFS etc are flash file systems. Not file systems for operating systems. You still require ext/rfs/fat32 etc for the OS to work with. They mount on a yaffs/etc partition so ext/etc do not have to worry about the intricacies of flash.
Voodoo confused a lot of things for a lot of people.
SpeeDemon said:
YAFFS/YAFFS2 and JFFS etc are flash file systems. Not file systems for operating systems. You still require ext/rfs/fat32 etc for the OS to work with. They mount on a yaffs/etc partition so ext/etc do not have to worry about the intricacies of flash.
Voodoo confused a lot of things for a lot of people.
Click to expand...
Click to collapse
Not to offend you, but you only have little knowledge, and that is a dangerous thing. There is no such distinction as file system for operating system versus flash file system. Linux kernel supports a variety of file systems. Some file systems are optimized and written specifically for flash media (e.g., YAFFS2), some are written for hard drives but could work on flash media too (e.g., fat32, ext4, jfs), some are only suitable for disk based media. The operating system partition can be mounted on any partition with a file system that the kernel recognizes. Ext2/Ext3/Ext4 have been the native file systems of Linux, but there have been a lot of machines with no use of any of them. It is up to the root user to choose what the file system of any partition is. The init script in the ramdisk packed with kernel calls the commands to mount the file systems. All Voodoo lag fix did was to convert some of the partitions mounted as RFS out of the box to ext4, and then allowed them to be mounted natively at boot time. The end result is nearly the same approach being taken by Google in the Nexus S out of the box. One of the differences in how the Nexus S or a Galaxy S running the latest Voodoo is set up is the /cache partition, which is set up as ext4 by default on Voodoo+ Galaxy S, and yaffs2 on the Nexus S. Both partitions are on flash media, but since the chip used in Galaxy S does wear leveling in the firmware, we can't use yaffs2 on /cache. Voodoo might have confused some people, but it sounds like you were confused well before that came out.
rajendra82 said:
Not to offend you, but you only have little knowledge, and that is a dangerous thing. There is no such distinction as file system for operating system versus flash file system. Linux kernel supports a variety of file systems. Some file systems are optimized and written specifically for flash media (e.g., YAFFS2), some are written for hard drives but could work on flash media too (e.g., fat32, ext4, jfs), some are only suitable for disk based media. The operating system partition can be mounted on any partition with a file system that the kernel recognizes. Ext2/Ext3/Ext4 have been the native file systems of Linux, but there have been a lot of machines with no use of any of them. It is up to the root user to choose what the file system of any partition is. The init script in the ramdisk packed with kernel calls the commands to mount the file systems. All Voodoo lag fix did was to convert some of the partitions mounted as RFS out of the box to ext4, and then allowed them to be mounted natively at boot time. The end result is nearly the same approach being taken by Google in the Nexus S out of the box. One of the differences in how the Nexus S or a Galaxy S running the latest Voodoo is set up is the /cache partition, which is set up as ext4 by default on Voodoo+ Galaxy S, and yaffs2 on the Nexus S. Both partitions are on flash media, but since the chip used in Galaxy S does wear leveling in the firmware, we can't use yaffs2 on /cache. Voodoo might have confused some people, but it sounds like you were confused well before that came out.
Click to expand...
Click to collapse
Except that ext4 support didn't exist in the .29 kernel used in Android 2.1 - you seem to think it magically just works, because it works.
SpeeDemon said:
Except that ext4 support didn't exist in the .29 kernel used in Android 2.1 - you seem to think it magically just works, because it works.
Click to expand...
Click to collapse
I know that supercurio patched in native ext4 support in Eclair, and it didn't just magically appear. The Froyo kernels do support ext4 natively though, so a simple script injection enables Voodoo. Since Gingerbread kernels from Google will also suport it (as Nexus S will actually use it), why can't another script injection work again to enable a Gingerbread kernel to work with Galaxy S.
Am I right in thinking that supercurio is a dev?
bedalus said:
Am I right in thinking that supercurio is a dev?
Click to expand...
Click to collapse
You do know this thread is more than a couple of months old, right?
Anyway, to answer your question: yes, supercurio is a dev.
Sent from my Nexus S using Tapatalk
Dual Boot Support
DualBoot Helper APP is now on the market! (See bottom of this post for more info)
DISCLAIMER: I am not responsible for anything, ever. It is not my fault if you do not read. I do not explain things because I enjoy banging on the keyboard. If you do not read this entire post before jumping in then do not expect me or anyone else to be much help. By following this guide and any links YOU assume all responsibility for your device and anything that happens with it.
What is it?
Dual booting allows you to run two separate roms on your device at one time. It is done by intercepting the mount points during the startup of the device. This is accomplished by checking the sdcard for a specifically named file when the kernel first loads and uses the appropriate files to boot with the correct partitions. Reading from the sdcard is slower than reading from the internal memory of the phone so the speed of your sdcard will drastically determine the speed any rom runs. On the same note a rom flashed to the sdcard will take longer than usual on the first boot.
What does it do for me?
Running two separate roms has many uses for just about everyone. Users can use dual booting to try different roms, themes, apps, modifications, or anything while keeping their existing installation intact. The uses are just about endless. Besides testing different roms, this allows the user try these things and make sure they are compatible and stable before pushing the changes to their internal memory. Rom developers have all of the above options plus a few. Rom developers can additionally use dual booting to test builds of their roms without fear of soft bricking their device. For advanced users, you can mount the partitions of the other rom (be it sdcard or internal) and fix bad apk files or messed up files. The options really are limitless!
What do I need?
Sdcard 2GB or larger
Dual boot compatible kernel
Other things I should know...
*The kernel MUST support BOTH roms you flash. Unfortunately this means you can NOT mix froyo and gingerbread roms. Make sure you know what the kernel supports before you flash anything!
*If you compare roms, benchmarks will hold no value due to the sdcard being so much slower than internal memory.
*Faster sdcards will perform better than slower ones. Note: the stock 16GB sdcard is a class 2 which simply classifies it's minimum speed. A higher class sdcard will more than likely perform faster but the class rating is a minimum and not a maximum. It is entirely possible that a certain class 2 card can out perform a different class 6 card. Keep this in mind when researching to buy a new faster sdcard. More info in this post.
*First boot takes longer than usual. Up to 15 minutes! Please wait until the rom boots and the initial media scanner is done before you judge usability.
*Using a rom from the sdcard will cause the sdcard to wear faster. This is due to many more reads and writes of data than normal. The Epic simply does not have the internal capacity to run dual roms on the NAND. That being said the sdcard is our next option. While it may reduce the over all life of the sdcard keep in mind there are other android devices like the Nook Color and the other Galaxy S phones that have internal sdcards running the Android operating system. My personal opinion with is with other devices running off internal sdcards and with the price of sdcards getting cheaper and cheaper it was worth it to explore this option for the Epic.
Ok ok, so how do I get started?
I am going to break the steps down into sections. Please read everything to ensure you understand what all is involved in getting everything working. I recommend making a backup in Clockwork Mod and saving it to your PC before you even get started.
Section 1 - Setting up the environment
Step 1. Flash a compatible kernel (Kernel developers, PM me if you add my dual boot support to your kernel and I will update the list below) Remember you can NOT mix a eclair, froyo, or gingerbread roms and the kernel MUST support both roms!
Currently compatible kernels:
Genocide 2.0 Supported Roms: EC05, EB13, and DK28
Section 2 - Preparing sdcard
Important information!!!! This will destroy ALL data on your sdcard so if you lose pictures of your dog, cwm backups, nudies of your spouse, etc then you can't blame me. BACKUP YOUR SDCARD!
The easy way:
Reboot into recovery mode with a program like Rom Manager, Quick Boot, or type 'reboot recovery' from a terminal. (NOT 3-finger boot to recovery...this will NOT work)
The easy way WILL erase your sdcard with NO confirmation....you have been warned!
Choose one of the following flashable zips to automatically partition your sdcard
DualBoot_Partition_RFS.zip
DualBoot_Partition_EXT4.zip
The manual way:
Reboot into recovery mode with a program like Rom Manager, Quick Boot, or type 'adb reboot recovery' from a command line. (adb commands assume you have a working install of the Android SDK)
While in recovery issue the following commands:
Code:
adb shell
cd /sbin
./dbpart.sh --help
I put many hours into the partitioning script to make it as simple to use as possible. Simply follow program usage instructions.
Section 3 - Preparing a rom
Since we have blank partitions on the sdcard we need to populate them with data. There are multiple ways to accomplish this and you can choose which solution best suits your needs. I am not going to cover ALL methods here but enough to suffice any likely scenario needed.
The dd method will clone your current setup to the sdcard (these commands may take up to 15 minutes)
The easy way:
Flash this dd script: DualBoot_Clone_to_sdcard.zip
The manual way:
Code:
adb shell
dd if=/dev/block/stl9 of=/dev/block/mmcblk0p2
dd if=/dev/block/stl10 of=/dev/block/mmcblk0p3
dd if=/dev/block/stl11 of=/dev/block/mmcblk0p4
Preparation is complete. Please skip down to booting from sdcard.
The flash method is for flashing a new rom to the sdcard.
The easy way:
There is no sure fire easy way just yet. Stay tuned though.
The manual way:
This method is not that difficult so there is no need to be intimidated by it. It requires editing a few lines of the script that Clockwork Mod executes when flashing a rom or addon. For this example I am going to use a file named epicrom.zip but you can use any name you wish.
Step 1. On your PC, open epicrom.zip (I recommend using a program like 7zip)
Step 2. Navigate to the META_INF\com\google\android\ folder.
Step 3. Drag the file updater-script out of the zip to your desktop.
Step 4. Open the updater-script file with a text editor such as notepad (I recommend notepad++ or textpad)
Step 5. Change every instance of /dev/block/stl9 to /dev/block/mmcblk0p2
Step 6. Change every instance of /dev/block/stl10 to /dev/block/mmcblk0p3
Step 7. Change every instance of /dev/block/stl11 to /dev/block/mmcblk0p4
Step 8. Delete the entire line for any lines that contain /dev/block/bml7 or /dev/block/stl7 to disable flashing another kernel and breaking dual boot support.
Step 9. Save the file and drag and drop it back into epicrom.zip and let it replace the old one.
Note: If you get a status 6 or some other error when trying to flash it is likely you made a typo or your text editor did no save the updater-script file correctly. Recommended action is to correct the typo and/or use one of the recommended text editors note in Step 4.
Section 4 - Flashing to sdcard
Flashing a rom from this point is the same as you usually do. Put the modified rom on your sdcard and flash with Clockwork Mod like usual. I recommend doing a backup in Clockwork Mod BEFORE you flash in case you messed anything up by accident and end up flashing over internal memory when you meant to flash to the sdcard.
Section 5 - Booting sdcard
To boot from the sdcard place a file in the root of your sdcard called 'bootsdcard'. If you named it correctly upon reboot, the kernel will load the rom from the sdcard and not internal memory.
To boot back into internal memory simply remove this file from your sdcard and reboot.
You can switch back and forth using this method. If the file is there it boots sdcard, if the file is not there it boots normally. Pretty simple right?
Section 6 - Other flashables (not roms)
Themes, addons, and anything else that is flashable with Clockwork Mod must be modified in the same fashion as the rom. Use the same procedure documented in Section 3, The flash method.
Kernel Developers:
If you would like to add dual boot support to your kernel please refer to this commit: https://github.com/Rodderik/Genocide-Kernel/commit/a5dfd9f369ae4f2c90c1e7fc7d8995f88f72bd01
I will update this section if I push any specific changes to dual booting.
Now with an APP!
DualBoot Helper
VenumX coded up an APK to work with Clockwork Mod to run the scripts.
http://forum.xda-developers.com/showthread.php?p=15486144#post15486144
Questions, concerns, gripes, or complaints can be left in this thread. If you need to report any problems please be as detailed as possible.
woot
Thats my boy!!!! Make me proud!!!!!!!!!!
w00t! go man go!
Holy ****! This is huge! Thanks!
Sent from my SPH-D700 using Tapatalk
OMFG this is way amazing ;P
Thr genious once again with another first
Sent from my SPH-D700 using XDA Premium App
Edit
nevermind...
good work!!!!!!!!!!!!
davidrules7778 said:
I got a question...
Would i be able to run dual versions of android
Ex 2.1 and 2.2
or 2.2 and 2.3
if the kernal is compatible?
Click to expand...
Click to collapse
if the kernEl was compatible yes...but none of them are...and likely won't be
Good damn job bro.. Let's keep the dev community developing
Rodderik said:
if the kernEl was compatible yes...but none of them are...and likely won't be
Click to expand...
Click to collapse
what if u made one of the eclair kernal compatible or gingerbread whenever we get custom kernals for it?
Or is it not possible to make eclair kernals compatible?
i think i could make a GB kernel now.. but you wouldnt be able to mix gb with froyo or eclair, because a GB kernel wont boot those builds..
Awesome work bro! Amazing...simply amazing!
chris41g said:
i think i could make a GB kernel now.. but you wouldnt be able to mix gb with froyo or eclair, because a GB kernel wont boot those builds..
Click to expand...
Click to collapse
yup i'm going to help chris41g put together a gb kernel for you guys
as far as eclair...honestly who still uses eclair? and why?
Rodderik said:
as far as eclair...honestly who still uses eclair? and why?
Click to expand...
Click to collapse
Just what I was thinking.
Tested on EC05 just now. I uhh... likey? =)
to bad no multi android versions though =(
why cant the kernel read off the sdcard? do you need drivers from samsung once again?
Shoulon said:
Tested on EC05 just now. I uhh... likey? =)
to bad no multi android versions though =(
why cant the kernel read off the sdcard? do you need drivers from samsung once again?
Click to expand...
Click to collapse
well the kernel is stored in bml7 and called by sbl/param during boot so unless we can get a bootloader to intercept the initial loading of the kernel and pass it off we are stuck with one kernel at a time
Very Nice Work !!!
Hey rodd... I think you should work on an aosp gingerbread kernel ... this is a great advancement in devlopment man... right when it was slowing again
Sent from my SPH-D700 using XDA App
this is amazing, thanks for this!!
You cannot make a cross OS kernel. We cannot integrate this into GB yet because there is no GB source, no GB source, no custom kernel. This is Froyo only, and well, someone else can make an eclair only kernel, but that is stupid.
Hi everyone! I'm new to Android. I recently bought a T-Mobile G2X / LG-P999, flashed the recovery partition with NVFlash (ClockworkMod) and installed CyanogenMod 7 (nightly). It's working great so far. My question is this: is it possible to flash only the /system partition at a later time with a newer build of CM7? For example, there is a Netflix app available that allows non-approved devices to connect to Netflix. I've tried installing this, but am suffering from the "chipmunk" problem where both the video and audio play back too fast. I read somewhere that an update the the media layer may fix this. It would be convenient to update the entire system partition once newer releases / fixes come out to address problems like this, without wiping out my data.
Also, I've noticed that most of the partitions are listed as ext3 when running mount to view mounted partitions. This seems to be in conflict with what apparently should be the yaffs2 file system. Is CM7 using ext3 instead of yaffs2? I found some source code I compiled that allowed the extraction of the factory G2X ROM dumps, which seemed to be yaffs2 (I did this because I wanted to reinstall the NFS Shift game that ships with the G2X). I suppose it's possible that the original ROMs could be in yaffs2 format, while CyanogenMod defaults to ext3.
Sorry if these are easy questions, but I am really excited about learning more about this OS and doing a little development of my own!
No advice, eh? Well, I'll simplify the question.
If I'm flashing nightly CyanogenMod builds, I'd like to be able to update them every few days, weeks, etc. However, I don't want to have to erase my data so I'd like to only flash the /system partition without touching anything else.
The CyanogenMod zip file contains a system.img, which is what I need to replace /system on my device. However, Clockwork Mod Recovery only has options for flashing complete zip files. Is it possible, perhaps, to just take system.img and zip it? Will ClockworkMod Recovery then only flash the /system partition?
I figured it out, so I'll post my findings:
CyanogenMod nightly zip files contain only boot (kernel) and system files. So, by booting into ClockWorkMod Recovery and choosing "install zip from sdcard," you can update to a new nightly without affecting user data. I assume only the boot.img and /system files are updated. This is what I did, and it seemed to work fine. None of my data was affected!
conclusion first: it was possible.
i searched for custom mtd info for chacha on google, and i found some info in chinese suggested it was possible to apply custom mtd on chacha.
http://wenku.baidu.com/view/b029ab6027d3240c8447ef67.html
i don't speak chinese, but google translation helped. i used Mikevhl's recovery (http://forum.xda-developers.com/attachment.php?attachmentid=749943&d=1318622558), and also FR-Custom-MTD-v1.5.6-boot.zip (http://115.com/file/aqvgn30z#) and FR-Custom-MTD-v1.5.6-recovery.zip (http://115.com/file/aqvgnzmc#) as the chinese instruction said although i don't know where these files came from (maybe somewhere here?)
the procedure itself was the same as desire (bravo) or any other devices, and after the process, i got;
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 214004 32 213972 0% /dev
/dev/block/mtdblock4 5120 1624 3496 32% /cache
/dev/block/mtdblock3 153600 150292 3308 98% /system
/dev/block/mtdblock5 307200 2560 304640 1% /data
yay!!
unfortunately, adlx.xda's v5.0.2.8 didn't work with these patches... sorry, if this info is already around here.
p.s. as usual, this patch automatically mounts /cache to /sd-ext when /cache partition is smaller than 20mb. however, /cache/download won't be created automatically which means vending.apk (market) fails to start. when you set /cache less than 20mb, you'd need create sd-ext partition on your sd card and either add init.d script to create /cache/download ot do it manually.
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
adlx.xda said:
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
Click to expand...
Click to collapse
hi adlx.xda,
i don't read chinese, either;-)
it is sure easier for most people to use app2sd or data2sd, but i prefer to keep everything in the internal memory because it is possible if you change the partitions and don't install millions of apps. it is kinda a surprise to me that you didn't know about custom mtd...
anyway, the patches were originally created for htc desire, and adopted to other htc devices with low internal memory capacity like chacha/wildfire/etc.
http://forum.xda-developers.com/showthread.php?t=806321
there were two patches in the package; one for recovery partition and the other for boot partition. the recovery patch allows you to burn a custom rom according to the designated partition info. the boot patch allows you to change the boot image so that the device recognize the new partition info on boot.
when i use your recovery and the recovery patch together to burn a custom rom, chacha does not boot. i guess the patch does not modify something in your recovery correctly. on the other hand, this patch correctly modifies Mikevhl's old recovery. it is strange the patch can be used for the latest recovery for htc desire...
thx for your attention.
qt
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
bedwa said:
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
Click to expand...
Click to collapse
How do you try to unpack/repack? I wonder why it would fail.
I'll have to look at my setup on my netbook and get back to you. May be a few days. :-\ Kinda swamped ATM.
My Tab makes calls Yo! GT-P6800
i do read chinese, i saw this fews mths back but i dont have time for it... you will left with 24x~26xmb of free space.
I just wanted to update and say that I replied to this thread:
http://forum.xda-developers.com/showthread.php?p=35367602#post35367602
Basically, I'm wondering if the CustomMTD patches might be more compatible with a newer version of CWM compiled for our phone. I built a copy of 6.0.1.5, which mostly works, so if someone wants to give it a try, please do.
I managed to see custom partitions from CWM (not with the patches, but manually altering the recovery). 312MB /system and ~120MB /data (as an example just to try)
Apparently no problem with /system, but /data is not "working":
It appears as Read Only (it shouldn't actually event mount after moving/resizing it). Also not only it mounts, but it appears as 100%full, and won't allow me to do anything. I can't reformat it, remount rw,... I don't know why to be honest.
Now that I think about it, I should check dmesg.
dead links
it looks like all the links are dead.
here are the files you need.
qtotter said:
it looks like all the links are dead.
here are the files you need.
Click to expand...
Click to collapse
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
adlx.xda said:
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
Click to expand...
Click to collapse
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
IIRC I used no files/patch,... It was more a matter of doing the partition table right. I took some notes and made an excel spreadsheet to help me with the conversions.
I'm on holiday starting today, I probably won't be able to review my notes and write anything related to this this month. Ping me again in Septembre so I review my notes and write a post about it .
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
it came from this thread originally http://forum.xda-developers.com/showpost.php?p=8578368&postcount=1, and it is very common among HTC Desire users.
it is quite easy to change partition sizes, and all the files you need are the three files that i uploaded.
recovery_chacha.img: Mike's old recovery that is compatible with this method. Don't use other recoveries!!
FR-Custom-MTD-v1.5.6-recovery.zip: This will patch recovery so that it can handle new partition sizes.
FR-Custom-MTD-v1.5.6-boot.zip: This will patch boot (kernel) in NAND so that the system can handle new partition sizes.
Procedure for ChaCha:
Make sure your phone is S-OFFed
**Make a backup in recovery first**
Place FR-Custom-MTD-v1.5.6-recovery.zip & FR-Custom-MTD-v1.5.6-boot.zip on SD card
Create mtdpartmap.txt on SD card with size of system & cache like "mtd 125 5". For example, I wanted to use ajeevlal's cm10.1 with Japanese IME and other system apps built in /system, I needed 330MB on /system and only 5MB on /cache (because I didn't need large /cache to use int2ext+.) So, my mtdpartmap.txt was "mtd 330 5". if you want to do this by shell command, it's gonna be like: echo "mtd 330 5" > /sdcard/mtdpartmap.txt
Flash Mike's old recovery above in fastboot like "fastboot flash recovery recovery_chacha.img"
Reboot into recovery
Wipe system, data, and cache
Flash FR-Custom-MTD-v1.5.6-recovery.zip, this patches recovery to use the new partition sizes
Reboot into recovery
Wipe system, data, and cache again just in case
Flash ROM, or restore from backup, and it will be flashed to NAND based on new partition sizes
Prior to rebooting, flash FR-Custom-MTD-v1.5.6-boot.zip, this patches boot (kernel) in NAND to load with the new partition sizes.
Reboot
unless you change mtdpartmap.txt on SD card, you don't need to repeat 1 - 8 every time. once you have decided your favorite partition sizes, you can start from 9. also, if your backup includes a patched boot image already, you can even skip 12 as well.
if you do this with any other newer recoveries, your phone simply does NOT boot. Mike's old recovery cannot backup sd-ext partition, but you can always do it manually like "dd if=/dev/block/mmcblk0p2 of=/sdcard/ext-bkup.img bs=4096" or something anyway.
kronflux's recovery
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
qtotter said:
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
Click to expand...
Click to collapse
it's also too large to fit in the recovery partition properly I believe. would be great if we could come up with a partitioning table that has enough space for it, as well as a little more space for app/rom storage.
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Adlx was just saying above, he doesn't think he used any custom files or patches. naturally we'll see in september what he has to say about it.
I did it with my recovery, not Mike's, and it worked, but again, I did it manually.
Sent from my Galaxy S4 running CarbonRom "Adlx Edition"
kronflux said:
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Click to expand...
Click to collapse
basically, this process patches recovery and boot to rewrite the partition table. Only Mike's old recovery can do both correctly.
talking about other recoveries, the reason why the phone doesn't boot is either recovery patch failure or boot patch failure. because i know Mike's one works and am not a recovery dev, i didn't even try to find which part is not working.
however, you can easily check it by switching the recovery between patching recovery and patching boot. i guess the former part is not working correctly because the latter part is rather straight forward and simple.
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
qtotter said:
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
Click to expand...
Click to collapse
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
kronflux said:
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
Click to expand...
Click to collapse
i have already explained how to do it above... now, my /system is 330 MB, and /cache is 5MB to cooperate with ajeevlal's cm10.1, full gapps, additional system apps and int2ext+. i am quite happy with my chacha setting not worrying about free space of /data, and battery lasts almost forever during sleep.
well, it is such a simple procedure, but i don't need to promote it to other people myself. i simply wanted to share the info that i learned over one year ago with people who want to make /system smaller for stock rom or make /system larger for cm10 and above.
Hello Galaxy S users,
Specifically, in this forum, it's Galaxy S 4G.
I know you've been watching T.V., and know (maybe... well here in E-merica) a little about universal health care... well I have something totally unrelated to talk with you about. [word this sentence with Steven Colbert's voice]
Universal Recovery.
As it stands, our bootloaders know nothing about the silly recovery partition on our devices.
And on stock roms, it is a total waste of good space we could put to any other partition (mostly data).
When this topic first reared it's ugly head, I thought to myself about just incorporating the unused space to data. But no! I have seen the light. And it is good!
There are a few different recoveries out there that are mostly a preference thing.
Stock Android Recovery (think the "3e" thing...) (totally friggin stock. No modifications)
ClockworkMod Recovery (cwm)
ClockworkMod Touch Recovery (cwm-touch)
TeamWin Recovery Project (twrp)
manual partition magic (that really only devs know about... [Bryan Jedi waves his hand in your face] forget I said anything here.)
... to name a few. Granted I will not support/help you on the first or last versions of recovery mentioned above.
I would like to use the recovery partition to unify the storage of the recoveries.
As we have seen with the radio partition... On stock, it is a bml partition without rfs. The modem.bin is written (redbend_ua) directly to the bml12 partition and read back by /system/bin/rild
On (Gingerbread(mtd)/CM7/ICS(mtd)/CM9) MTD based roms, the radio partition is a yaffs2 formated partition in which modem.bin's are simply copied to. A symlink (/dev/block/bml12) to allow rild to work correclty... (well and a nasty hack on SGS4G to pad the modem.bin with zeros, because the rild reads more then the size of the modem.bin but less then the size of bml12)
Lets say we format the recovery partition as yaffs2 (or either vfat or ext4 on bml roms), and store ramdisk-recovery-<version>-<fstype>-<recovery-type>.img files there.
Examples:
ramdisk-recovery-gb-bml-cwm.img
ramdisk-recovery-ics-mtd-twrp.img
Then create a cwm update.zip that allows you to switch your recovery based on what is in the /recovery partition.
The title of this post is [RFC]... This is a Request For Comments.
As an amendment to this RFC, I would also like to have universal updater.sh and updater-script files to be created so that one could say, flash:
stock bml gb (cwm) -> ics mtd (cwm-touch)
ics mtd (twrp) -> stock bml gb (twrp)
ics mtd (cwm) -> gb mtd (cwm-touch)
gb mtd (twrp) -> stock bml gb (cwm-touch)
gb mtd (cwm-touch) -> ics mtd (cwm)
...without ever needing to go to download mode to run a oneclick or odin.
This thread should eventually turn into a development thread containing the results of this discussion.
...
A little while back, I started a poll.
The results of the poll, and comments lead me to believe that users are more interested in obtaining root and having the latest version then anything else.
All of these recovery methods should provide root access to install which ever rom you want (rooted or not rooted) and whatever recovery you want to use.
Goals (no particular order):
Run an updater.zip OR run an android app to change the current version of recovery.
Unify the updater.sh and updater-scripts for our roms, so you guaranty that you can flash from any rom to any rom (unless it has not been updated to use this new standard)
Do something with the lost 6-7M of unused space currently known as 'recovery'.
Let me know what you think. I already have a WIP, but it only supports cwm (at the time of this writing. cwm-touch and twrp coming soon...).
I am working on minimal environments (android manifests) to build each specific recovery nightly so that these will always stay up to date with what is in our repositories.
Being an RFC thread, please provide some helpful feedback.
ALSO, I leave this open to other Galaxy S phones as well!
You too have a device with this stupid recovery partition.
If all Galaxy S phones used the same codebase for updater.sh and updater-scripts and for setting the currently used recovery, it would be a win for everyone.
OK, Technical section:
--------------------------------------------------------------------------------------
On the latests CM10, a patch was applied by pawitp a little while back to allow a simpler packing of ramdisk and recovery.
Because of this, you can basically repack the initramfs with a different recovery.
If we changed our stock bml gb kernel, cm7 (and other mtd based kernels) to use a similar recovery method, we could unify the way we change between recoveries.
--------------------------------------------------------------------------------------
...Comments go here VVVVVVVVVVV
As we were discussing on #teamacid, I think I can help with figuring out the mtd -> bml portion of this since most of my previous work has been with installer scripts and the recovery environment.
Bryan was telling me that it should just be a matter of flashing the bml zImage and to reboot and continue the install.
I definitely think that storing the recovery.img files in /recovery would be a great solution. It'll keep the kernel/boot.img files leaner and allow us to update the recovery without messing with the kernel.
FBis251 said:
As we were discussing on #teamacid, I think I can help with figuring out the mtd -> bml portion of this since most of my previous work has been with installer scripts and the recovery environment.
Bryan was telling me that it should just be a matter of flashing the bml zImage and to reboot and continue the install.
I definitely think that storing the recovery.img files in /recovery would be a great solution. It'll keep the kernel/boot.img files leaner and allow us to update the recovery without messing with the kernel.
Click to expand...
Click to collapse
Essentially, yes. There are two "universal"s here.
Universal recovery selection
Universal updater.sh and updater-script usage
And, yes, kind of... the reservoir may also be apart of the big problem here.
There is much experimentation and discovery to happen before anything really results from this thread.
I definitely support the movement. What can I do to speed up the process or help with this development?
Sent from my SGH-T959V using Tapatalk 2
I'm interested in the implications this could have to the S devices with a flash counter.
Sent from my SGH-T959V using xda premium
GreyDark said:
I'm interested in the implications this could have to the S devices with a flash counter.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
I know that the sgs4g has a flash counter, but it never increments.
I think it was something they were thinking about, but never got working for the release.
VillaCastana321 said:
I definitely support the movement. What can I do to speed up the process or help with this development?
Sent from my SGH-T959V using Tapatalk 2
Click to expand...
Click to collapse
I just need to finish my WIP and let other devs at it so they can make changes to it.
The WIP is driven by what is in the OP of this thread. It is not written very well and not very detailed.
I hope that changes over time with feedback.
Having botched my share of kernel/recovery flashes, this would be very interesting if I could always access something that would let me flash a known-good kernel/recovery from microSD when I next mess up.
Admittedly, I could stop flashing unknown kernel/recovery when I'm not within reach of Heimdall, but...
So the SII can use triangle away for the flash counter while with the SIII it's still usable yet not recommended from what I saw. By using dd to get the recovery in, the SIII dodges the counter again, (first time by using Odin to get root) but there can always be people who might even do that wrong. I don't know about the other S devices, but if there was an easy way to get root and a custom recovery, definitely a plus for average users.
Sent from my SGH-T959V using xda premium
I think its a very good idea. It makes perfect sense, I don't see a downside and see its possible. It would be great actually
Sent from my SGH-T959V using xda app-developers app
This sounds awesome... would b willing to test.....
sent from my t959w running RemICS, Voodoo sound, Rom Toolbox pro.
Fun starts in a month or so.
Wait... For... it.
bhundven said:
Fun starts in a month or so.
Wait... For... it.
Click to expand...
Click to collapse
Patiently waiting... teeth clenched....staring at my screen,watching for that post up..... LOL
sent from my t959w running RemICS-UX, Voodoo sound, Rom Toolbox pro
abonides said:
Patiently waiting... teeth clenched....staring at my screen,watching for that post up..... LOL
sent from my t959w running RemICS-UX, Voodoo sound, Rom Toolbox pro
Click to expand...
Click to collapse
So you are told to wait about a month, and you are spazing after six days? Wow, really patient.
Cooptx said:
So you are told to wait about a month, and you are spazing after six days? Wow, really patient.
Click to expand...
Click to collapse
I think he was joking
pisherthefisher said:
I think he was joking
Click to expand...
Click to collapse
I hope so
SMH
Sent from [CONTET DELETED]
love the idea <3
Sorry,my sick twisted humour cannot b appreciated via text.
sent from my t959w running RemICS-UX, Voodoo sound