[RFC] universal recovery [2012/09/16] - Samsung Galaxy S (4G Model)

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

Related

[CM RECOVERY] Sources released, Private alpha testing stage

Hi All!
I pushed my fork back to GITHUB
I compiled CM recovery for Galaxy 3, it was long journey
I need some help. My development speed is very low, I'm not dev at all and my C knowledge is very limited. Also I can't invest many time in porting CM recovery.
Thing that worked for my setup (/system - rfs /data ext2 /cache - ext2):
1. it compiled!
2. partitioning SD card
3. making backup
4. restoring data partition (other parts and boot/recovery not tested)
5. wipe cache paritions
6. running fix_permissions scripts
7. running keypress test
I want You to help me choose that to do next: make update.zip worked or try to do backup/restore fully working?
Also I need link for update.zip that surely worked for JPM to test it.
recovery is in pre-alpha stage, I don't want do public alphas, because it simply not tested, and really may brick phones
Now recovery in private alpha testing stage, PM me if you brave, want to test alpha and accept risk of bricking you device
good job.
I don"t know if I can help you much but I will try if you need to.
FS supported by builds:
Build # /system /data /cache
26 rfs ext2 ext2
27 ext2 ext2 ext2
30 ext2 ext4 ext2
Good job
You can give it to some testers though willing to test even at the risk of bricking so that devs like you are motivated and get feedback
Testing really helps
I can help too
if you are porting cwm recovery latest version it uses newer scripting language and thus old update.zip files wont work anyway.
finally! SG3 is becoming a good phone lol ! thanks!
subscribed...
i´d suggest to make nandroid backup work first, then the danger of having a softbrick is much smaller.
That's fantastic news !
Backup/recovery should be top priority I think. Flashing update.zip is not something we could do before, so we won't miss that.
Bubble-be said:
That's fantastic news !
Backup/recovery should be top priority I think. Flashing update.zip is not something we could do before, so we won't miss that.
Click to expand...
Click to collapse
we could do it with eclair...
FadeFx said:
if you are porting cwm recovery latest version it uses newer scripting language and thus old update.zip files wont work anyway.
Click to expand...
Click to collapse
My developing speed is really slow, I start porting it ~1.5 months ago
Version is ClockworkMod Recovery v2.5.1.8 is it old or new version for update.zip ?
making everything to work would be awesome... i believe in you ppl! you will make it work! you have to make it work! because no one else is even close to being capable of doing the magic that you are doing!
the new script version is out for 3 or month or 4 so already...
Nice work
Do you know when you release the 1st beta?
its done when its done... dont ask dont tell...
deskjeti said:
Nice work
Do you know when you release the 1st beta?
Click to expand...
Click to collapse
dude read>
recovery is in pre-alpha stage, I don't want do public alphas, because it simply not tested, and really may brick phones
mumbozver said:
Hi All!
I compiled CM recovery for Galaxy 3, it was long journey
Click to expand...
Click to collapse
Maybe the best news concerning the g3 in a long time. Keep it up man! I am not able to do much but I'm eager to beta test!
sent from my kirillos' v.3 fugumod 2.2 BE oc'd JIT enabled nokia 3210
can you gine me workin fix_permissions scripts to use it from internal use ?> thanks in advance
You can test the recovery by using terminal.But there's a problem that u can't return to normal system.I think it 's because the video driver return to basic mode etc.(Just guess it)I sugggest u don't compile all parts of the cwm but a little part.For we just need a little function now.Test it in terminal.While I have a computer.I will try to help,but I can't promise anything...Haha
Sent from my GT-I5800 using XDA Premium App
WHEN I USING ENGLISH IN COMUNNICATING WITH OTHERS. SOMEONE WILL TELL ME:U CAN PASS THE CET-4 EASILY....
nikkpap said:
can you gine me workin fix_permissions scripts to use it from internal use ?> thanks in advance
Click to expand...
Click to collapse
"worked" mean it runs fine from recovery menu, and do its job.
It's unmodified, and I'm not sure it fully correct for our phone.
You may find it here: https://github.com/CyanogenMod/android_bootable_recovery/blob/froyo-stable/utilities/fix_permissions
instead of making update.zip work, u can complete the nandroid and backup\restore
i flashed cm7 in my friend's X8
the update.zip did not work properly so i extracted the rom files and made them as a backup and restored the rom with that backup-worked like a charm
we can install roms if the dev's provided it as a backup file(which is safer than using update.zip)

[RECOVERY][GPL] ClockworkMod 3.1.0.1 PURPLE UPGRADE RFS/EXT4/USB CUSTOM FOR EPIC4G

CWM 3.1.0.1 PURPLE UPGRADE WITH RFS/EXT4/USB MASS STORAGE SUPPORT!
Some of you might be asking,
WHY DID I DO THIS?
Well, as soon as I released cwm 3.0.2.5, I got requests from all over the epic community, to make some changes to cwm, changes I couldn't incorporate, until I learned to compile the ClockworkMod binary itself. So, with some help from skeeterslint and Rodderik, I did just that...
So, the changes in CWM 3.1.0.1 purple are:
* USB Mass Storage working from the menu, and top text changed, to reflect safe removal of sdcard from PC *before* leaving USB Mass Storage menu
* Purple text and icon color, everyone seemed to hate the orange color
* Key Codes fixed, menu is now the select key, and top text changed to reflect this
* Only one "No" in confirmations, only need to click down once to get to "Yes"
* Built-in busybox is full Cyanogen busybox 1.16.2, with --install -s feature built in
* sd-ext ext4 partition listed in recovery.fstab, a direct change from koush
* Compatible with cwm 3.0.2.5, and has been tested by many in irc.fossnet.info #epic channel
These features are the direct results of feedback from both devs and users in the irc channel... so, if you want input on things like this in the future... it pays to be involved in the epic irc channel!
Please note: some people have had the samsung recovery appear after this flash, and in my testing, in some circumstances, the stock kernel can actually flash back the stock recovery. Due to this, I highly recommend that anyone flashing the new cwm with this flash, please also flash my clean kernel, located here: Clean Kernel EC05 thread Also note, that the one click version of this should not have this problem, since it takes away the ability of the stock kernel to flash the samsung recovery.
OK, there's been some confusion to what the recovery kernel is and does... even among developers at times... so let me explain, before you download:
This flashes the recovery partition of the phone. When I release a CWM upgrade, I am flashing bml8, which is the recovery partition. The recovery partition is only booted when the phone is powered off, and a 3 finger boot is performed, using vol down, camera, and power, held down until the menu appears.
Reboot recovery relies on the kernel (bml7), or a cwm redirector (from the stock kernel, is what the one click root does) to provide cwm, which is why you get an older cwm version with reboot recovery with most kernels. My Clean Kernel EC05 was made to provide a bassline for other kernels for cwm reboot recovery, so until other kernel devs incorporate the new recovery into their kernels, the Clean Kernel is the only one that does reboot recovery to cwm 3.1.0.1. I hope this clarifies things a bit.
I have been actively training other kernel devs on how to incorporate cwm reboot recovery into their kernels, so that koush himself can start pushing cwm updates officially through ROM Manager. This is how ROM Manager is intended to be used (and once was, before ext4 invaded the epic development scene)... but for this to happen, the new recovery needs to be standardized, and everyone on the same page, for this to happen. I know koush will be ready to push official cwm updates for the Epic through ROM Manager, as soon as we as a community are ready for it.
NEW!!! Thanks to qbking77 for making this video, showing both install methods in action, for those that just hate to read instructions:
http://www.youtube.com/watch?v=dsRA7q4JWPQ
DOWNLOADS
cwm3.1.0.1.purple.zip
Flash this with your current ClockworkMod to be upgraded!
NEW!!! If you have problems with the flashing the zip, or just wanna use Odin, here is an Odin flashable tar will get you all squared away, with a quickness, just load the file into the PDA slot of Odin
cwm3.1.0.1.tar.md5
NOTE: if you're phone won't boot after flashing the zip from cwm, just flash this, there is no need to flash a complete stock tar.
Notes:
* This flashes bml8 kernel only, this kernel is stripped of bloat, for minimal file size
* 3 finger boot required to enter the bml8 recovery from power off
* Key assignments: vol/keypad up/down= up/down, camera button/menu softkey/keypad enter= enter, back softkey/power/keypad delete= back
hehe: has mkasick keyboard patch, so thumbing is faster!!!
* Full restores of backups done from prior cwm versions may not be possible. Do backup and restore > advanced > {choose backup} > and selectively restore the partitions you need.
* Once new backups are performed, those backups can be restored to *either* rfs or ext4.
* Now backup and restore includes both the kernel and recovery too
* Use in conjunction with my Clean Kernel, for ROM Manager support, other kernels will soon follow suit:
Clean Kernel EC05 thread
credits:
THE COMMUNITY!!!! I HAVE FINALLY SEEN DEVS WORKING TOGETHER IN WAYS I DIDN'T THINK WERE POSSIBLE...
LET'S KEEP THIS UP, AND KNOW THAT COOPERATION BENEFITS EVERYONE!!!!
* kain203: donated the use of an 8 core linux machine for my use in compiling kernels and the cwm binary. This *greatly* increased my productivity, and allowed me to edit and compile everything for cwm and my kernel, *all* from my Epic 4G, believe it or not...
* Rodderik: without his initial kernel training, I never would have gotten this done at all, also, helping with installing packages necessary to get cwm to compile, he also generously provides the hosting for these files you're downloading.
* koush: the friggin man! The creator of ClockworkMod and ROM Manager! He gave me the advice I needed to finally get dual fs support!
* tanimn: for hosting of cwm koush files in this github, and sharing experience that was genuinely helpful
* vocaltreat: the cwm3.1.0.1 purple clockworkmod icon
* skeeterslint: help in getting cwm to compile, and pointing me to files to edit, from his prior expertise on cwm
* mkasick: for the keyboard sysfs patch, for faster key response
Notes for sources:
The Samsung kernel, ClockworkMod, and busybox, are *all* open source, and as such, mods to all, should have the sources included. Since I like to *practice* what I preach, here are all the sources for the CWM kernel, recovery, and busybox edits:
https://github.com/DRockstar/CWM-3.1.0.1-Kernel
https://github.com/CyanogenMod/android_device_samsung_epic4g
https://github.com/DRockstar/android_bootable_recovery
https://github.com/DRockstar/android_external_busybox
Nice work. You going to make this a one click method?
Nice thanks for this man flashing now.
Sent from my Epic S 4G using XDA Premium App
Sweet!!!!
Is this compatible with EE03? I see it flashes a kernel and assume that it isn't compatible with the gingerbread leak.
ebejoe said:
Is this compatible with EE03? I see it flashes a kernel and assume that it isn't compatible with the gingerbread leak.
Click to expand...
Click to collapse
Yes it is. Just flash it through your current clockwork.
Awesome work. Flashing from Yellowstone.
Sent from my SPH-D700 using XDA Premium App
qbking77 said:
Yes it is. Just flash it through your current clockwork.
Click to expand...
Click to collapse
Flashed and is working well. Nice work.
Now I need that initram for my kernel drock! Goodjob..
Sent from my SPH-D700 using XDA App
Awesome Job Pimpin'!!!!!
Sent from my SPH-D700 using Tapatalk
I almost forgot to post all of my sources for this, which is very important to me... sources for the cwm Kernel, recovery, and busybox, are all listed at the bottom of the post.
Worked perfect first try. I actually am using Genocide 1.1 kernel and had no problem. Thank you for the hard work. The purple looks sharp. I can see a purple and black theme in the future now
Sent from my SPH-D700 using XDA Premium App
Really like not having to scroll through so many "NO"'s just to flash something.
Excellent work
The busybox is awesome too.
Will this work correctly on gingerbread or will it mess up the kernel?
Sent from my SPH-D700 using XDA App
marcusant said:
Will this work correctly on gingerbread or will it mess up the kernel?
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Flashing this cwm kernel to bml8 won't affect the gingerbread leaks, just do not flash the Clean Kernel on the gingerbread leak, or the phone won't boot.
DRockstar said:
Flashing this cwm kernel to bml8 won't affect the gingerbread leaks, just do not flash the Clean Kernel on the gingerbread leak, or the phone won't boot.
Click to expand...
Click to collapse
I am aware about the 2nd part. Can I include this in my rom?
Sent from my SPH-D700 using XDA App
I've been using this with ee03 and it works fine.
Sent from my SPH-D700 using XDA Premium App
1. Can you make a version in red?
2. Can I use this in my rom?
Sent from my SPH-D700 using XDA App
marcusant said:
1. Can you make a version in red?
2. Can I use this in my rom?
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Sure, you can use the recovery in your ROM...
As for the red, it does entail a minor edit with a recompile of the binary, and repackage of the kernel... atm, my donated vm is down, but perhaps later I can do something for ya
Just did my first theme flash from the new recovery. Its so much better not having to scroll through the "NO's." I didn't think it was that big of a deal at first but it really is much better. Great job.
Sent from my SPH-D700 using XDA Premium App

[RECOVERY] ClockworkMod 5.0.2.7 BML Officially supported by ROM Manager for Epic 4G

OK guys, you have NO idea what it has taken to get to this point...
Welcome to the first officially supported ClockworkMod for the Epic 4G since cwm 2.5.1.0, I think it's been over a year now...
Changes since 3.1.0.1:
* Backups are tar files by default, with the filesystem type noted in the filename. Backups automatically reformat to the backup filesystem before restore. This will work to restore rfs and ext4 setups. So, for example, if you're currently on rfs, but your backup was done while on the ext4 filesystem, the restore will reformat back to ext4 before restoring. Older backups done by cwm 3.x and ACS Recovery can be restored by this ClockworkMod version, and will not reformat before restoring older backups.
* This cwm is not meant for mtd partition layout / yaffs2 filesystem, that is another matter entirely, and mtd will require it's own cwm build and kernel, that will most likely be in the official CM repo when it's done.
* One "No" in confirmations, for all but factory wipe: Make a blank file called .one_confirm (that is a period in the beginning of the name), and place it in /sdcard/clockworkmod directory. This works right now with 3 finger boot from power off, but will be added to the next Clockwork Recovery update in ROM Manager. When that happens, then it will also work from the option Reboot into Recovery, when called from ROM Manager. This is now official, so that in the future, anyone with ClockworkMod 5.0.27+ will be able to benefit from this. Thanks to chris41g for this edit and push to the official source.
* Keycodes were fixed to work with the gingerbread kernel... and menu was fixed up a bit.
up = vol up, keypad up, keypad left
down = vol down, keypad down, keypad right
back = back cap key, power button, keypad backspace key
select = home cap key, keypad enter key, camera button
toggle display = keypad d key
reboot = power button 5 times, no matter where you are in the cwm menu
NOTE ON KEYS:
If your current kernel is a froyo kernel, then the cap keys will be reversed... We will have some growing pains, until everyone is on board with gingerbread, and the kernel devs start implementing the kernel mod described below, to change the mode of reboot recovery to go to bml8 recovery partition. If you are running gingerbread, then you can flash this prerelease:
Clean_Kernel-2011-11-20-15.51.32.zip
md5:389f5b1745352326c9357c1252cd37b9
This isn't exactly finished yet, but it's stable, and has voodoo sound, root, busybox, etc.
* DO NOT REPARTITION YOUR SDCARD WITH CLOCKWORKMOD. There are problems associated with this that I will detail later.
* I highly recommend flashing both the new recovery kernel and the ROM Manager update... pretty soon, ROM Manager will be able to flash our favorite ROMs, by downloading and flashing from ROM Manager.
* FOR USERS OF ACS RECOVERY:
At this time, I recommend flashing the new cwm over ACS Recovery. Testing has shown that backups done when the ROM Manager fakeflash is called through ACS Recovery, is that the backups won't be in the proper format... they will probably work, but not in the way the CWM 5 intends it too, with fs saved tar backups.
I know that some of you are avid fans of ACS Recovery, and I have nothing against that. In fact, it should be pretty easy for chris41g to make a new version if he so desires... and, he did contribute to the official source, which is something I truly appreciate In fact, I have been working with koush, to get some other of the most requested features, into the official cwm sources, so they can benefit everyone in android. One of the first new features to be put into the next cwm update in ROM Manager, is the ability to have only one "No" in the confirmations, if the file /sdcard/clockworkmod/.one_confirm is present. chris41g authored this for the cwm sources. Also, we have been given the go ahead to implement the inclusion of reboot into download mode from the main cwm menu in the official sources as well
WHAT TO DO IN ROM MANAGER:
Firstly, flash the new recovery with odin/clockworkmod.
Also, I'd recommend a known working kernel for the new recovery:
Clean_Kernel-2011-11-20-15.51.32.zip
md5: 389f5b1745352326c9357c1252cd37b9
This isn't exactly finished yet, but it's stable, and has voodoo sound, root, busybox, etc.
Nubernel by nubecoder for gingerbread
other kernel devs feel free to link me to your posts!
Get ROM Manager from the market, and choose Flash ClockworkMod Recovery.
Choose the Samsung Epic4G.
It should then download, and you should see ClockworkMod version: 5.0.2.7
Now, whenever you use ROM Manager for anything, it will automatically load the latest supported ClockworkMod for the Epic.
DEVELOPERS: Please visit this forum thread, and learn all you need to know about getting your zips listed in ROM Manager, and the features available for you to use.
KERNEL DEVELOPERS: It is highly recommended at this time to use this commit, to change boot mode for reboot recovery to boot from bml8 recovery partition:
https://github.com/EpicCM/android_k...mmit/ea1dbf2c9be977aeb6f78d871e0b05d989bfad59
OK, here are the links:
cwm-5.0.2.7-epic4g.tar tar flash for odin
cwm-5.0.2.7-epic4g.tar mirror
md5: edd321a3aa2ba4c73f1d3612e9b19c05
cwm-5.0.2.7-epic4g.zip zip flash for cwm
md5: 869baf2d6a52b5604764f70556c9482e
TUTORIAL VIDEOS COURTESY OF QBKING77:
Flashing ClockworkMod Recovery Kernel:
http://www.youtube.com/watch?v=xuLWzeJ1lT4
Setting up ROM Manager for the Epic 4G:
http://www.youtube.com/watch?v=6KTZj3LOsxc
Thanks goes to:
koush - Creator of ClockworkMod, and very good guy for his patience and willingness to listen to the needs of the Epic community, and the android community at large.
mkasick - help with C code to support rfs formatting in the official cwm sources.
chris41g - inclusion of code in official sources to permit one "no" in confirmations, if file /sdcard/clockworkmod/.one_confirm is present
DEVELOPER NOTES:
Yes, this time there are developer notes! I will be adding more over the next couple of days.
SOURCES
ClockworkMod Binary:
https://github.com/CyanogenMod/android_bootable_recovery/tree/gingerbread
Epic4G device file sources:
https://github.com/koush/android_device_samsung_epic4g/tree/master
ClockworkMod Recovery kernel sources:
https://github.com/EpicCM/android_kernel_epic4g_gb_official/tree/cwm_5.0.2.7-rfs-ext4
I have put the branch trees in the URLs, since the masters could be subject to change in the future.
WHY CWM 5 WAS A CHALLENGE
ClockworkMod version 5 now stores the backup filesystem in the name of the tar backup files. When I first submitted my device files to koush for ROM Manager support, it became clear that now ClockworkMod would have to support the formatting of rfs volumes for the restores to work properly. This took me a while, but thankfully with the generous advice of mkasick, I wrote the function and pushed to the official source:
https://github.com/CyanogenMod/android_bootable_recovery/commit/a8f265dd6f764188d07ea2637d5638b8c64e4a6b
To experienced C programmers, this is easy stuff, but hey, admittedly, I'm a very new to C programming, and I wanted to learn... and I wanted to get it as correct as possible the first time... so this took me a while
RECOVERY KERNEL DETAILS
The important thing with a recovery kernel, is that it only needs to do one thing:
Load ClockworkMod, and anything ClockworkMod might need.
For this reason, there are minimal kernel modifications for the ClockworkMod Kernel. The following details, however, are worthy of note:
* This kernel supports kexec, as in the future, dual boot may become the norm.
* The boot mode for reboot recovery has been modified to reboot the bml8 recovery kernel, and not the boot kernel recovery.
* I left in the keypad timer patch by mkasick, since it really makes a difference in scrolling through the menus in ClockworkMod.
* The initramfs /sbin was modified to only have files needed for ClockworkMod, along with the following scripts and binaries that I often find useful:
bmlwrite - binary to flash kernels
bmlflash - script to flash boot or recovery kernels easily
bclean - script to clean all busybox files from /system
rclean - script to clean all busybox and root related files in /system
FOR BOOT KERNEL DEVELOPERS
It is highly recommended at this time to use this commit, to change boot mode for reboot recovery to boot from bml8 recovery partition:
https://github.com/EpicCM/android_ke...0b05d989bfad59
LESSONS FROM HAVING WORKED ON CLOCKWORKMOD RECOVERY
When I did ClockworkMod 3.1.0.1, I created a custom recovery, with some requested features. However, with time, it became apparent that having an official recovery with ROM Manager support was ultimately more favorable than having a custom one. Furthermore, with just a little effort and cooperation, the official source can be appended to include the most requested features. We're not the only ones asking for those features. I now believe that contributing to the official source benefits the entire community in the end, and not just one or two devices.
Along with my rfs formatting commit, I invited chris41g to contribute as well, and hence his following commit was also accepted, which allows only one "No" to appear in confirmations, when the blank file /sdcard/clockworkmod/.oneconfirm is detected:
https://github.com/CyanogenMod/andr...mmit/a8f265dd6f764188d07ea2637d5638b8c64e4a6b
Again, very simple here, but solves the most requested modification to ClockworkMod probably ever, and now, anyone with ClockworkMod 5.0.2.7+ can enjoy it too!
I really want to thank chris41g for taking the time to contribute. I respect and appreciate his work on the ACS Recovery, and I feel that his work will make even more of a difference in the end- to a lot more people than just the Epic 4G community.
I truly hope that my example can be an inspiration to others, to cooperate with other developers for the benefit of all. This may appear idealistic, but I believe the Epic 4G community has matured and has already started reaping the benefits of this cooperation. I also believe that in learning from others, you are also given the obligation to help others, who will, in turn, help others, and so on. I should hope that the benefits to all are obvious. And with that, I'll stop "preaching"... hehe.
Rockstar! Thanks are in order!
Sent from my SPH-D700 using Tapatalk
Great news!
Sent from my SPH-D700 using XDA Premium App
First page reserve. This recovery is great.
Sharing via any means i can. Gonna get Kevin to do something with our roms now
Great job! Thank you for all the hard work that you put into this!
Sent from my SPH-D700 using Tapatalk
All i can say is wow. Thanks.
Sent from my Legandary Epic or my Galaxy Tab rooted (feels naked without a ROM)
Sweeeeeet!!! Thanks Drockstar! And devs!
Could we get md5's
Sent from the Drivers Seat of my Suby txting and Driving doing 100MPH+ in a school zone! Ha.
hear the md5 from the cwm flash 869BAF2D6A52B5604764F70556C9482E
Thanks Drockstar!! Been testing it out and it works awesome!
Sent from my SPH-D700 using Tapatalk
Thanks!!! This rocks.
Sent from my SPH-D700 using XDA App
i know this is dumb but i gotta ask what color is it ?
Thank you for this. Since its official and no longer a port does this mean no more having to wipe 3x?
Sent from my SPH-D700 using Tapatalk
Digglez said:
i know this is dumb but i gotta ask what color is it ?
Click to expand...
Click to collapse
Basically Cyan/Ics blue
Sent from my Samsung Legendary 4G, a Universe UTES phone, running "two.three.five"
Digglez said:
i know this is dumb but i gotta ask what color is it ?
Click to expand...
Click to collapse
It is a cyan looking color...real easy to see/read. Me lovez it!
Sent from my SPH-D700 using xda premium
Digglez said:
i know this is dumb but i gotta ask what color is it ?
Click to expand...
Click to collapse
These are the official colors for cwm 5, pics are here:
http://forum.xda-developers.com/showthread.php?t=1354095
Eins7ein said:
Thank you for this. Since its official and no longer a port does this mean no more having to wipe 3x?
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
Well, honestly, wipe 3x hasn't been an issue for a while now... if you need to wipe, just do factory wipe from the main menu only once.
The version that flashes from ROM manager has one minor issue - the capacitive back button acts as a select button, but the menu key works as a back button... That's all I've noticed so far, other than the three finger salute going into my previously installed CWM 3.1...
Sent from my SPH-D700 using XDA App
styles420 said:
The version that flashes from ROM manager has one minor issue - the capacitive back button acts as a select button, but the menu key works as a back button... That's all I've noticed so far, other than the three finger salute going into my previously installed CWM 3.1...
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Well the the finger boot to cwm 3 is sure as hell not right...
sent from my always aosp epic
Got plenty of "no" choices again before getting to a "yes"...that's annoying. Otherwise, pretty cool.
DRockstar said:
Reserved for developer notes
Click to expand...
Click to collapse
DRockstar ... got a question ... R U gonna make us a GB version of CleanKernel that will work with this new CWM ?

Stability of these kernels and CWM5

Hello FB, will you help me.
I'm not sure which of these kernels is stable, except the v0.0.2d with CWM3.
From your post:
sms-T959V-KJ6-v0.1.1-rc2.zip
From bhundven post:
Subtly Modified Stock for T959V KJ6 v0.1.1-rc1+: sms-T959V-KJ6-v0.1.1-rc1-unsigned-update.zip
sms-T959V-KJ6-v0.1.1-rc1-unsigned-update.zip {same as #1 ? (above rc1+)}
sms-T959V-KJ6-v0.1.0-unsigned-update.zip
Besides the /system unmount issue, what is the advantage of CWM5 vs CWM3?
Thank you
Fb's latest kernel is the most stable kernel as off now.
i would say go for fb's kernel
fb modified or i should say upgraded bhudven kernel...
and it got team acid splash screen which is a very nice touch
bark777 said:
Hello FB, will you help me.
I'm not sure which of these kernels is stable, except the v0.0.2d with CWM3.
From your post:
sms-T959V-KJ6-v0.1.1-rc2.zip
From bhundven post:
Subtly Modified Stock for T959V KJ6 v0.1.1-rc1+: sms-T959V-KJ6-v0.1.1-rc1-unsigned-update.zip
sms-T959V-KJ6-v0.1.1-rc1-unsigned-update.zip {same as #1 ? (above rc1+)}
sms-T959V-KJ6-v0.1.0-unsigned-update.zip
Besides the /system unmount issue, what is the advantage of CWM5 vs CWM3?
Thank you
Click to expand...
Click to collapse
I got 66 hours with no reboots on RC2.
The main differences between CWM 3 and 5 are that CWM 5 doesn't have trouble making and restoring backups (made in CWM 5), the ability to have ADB in recovery and the option to reboot to download.
Additionally, it has most of the changes made after Dec 7, 2011:
https://github.com/teamacid/android_kernel_galaxys4g/commits/sgs4g-aosp
FBis251 said:
I got 66 hours with no reboots on RC2.
The main differences between CWM 3 and 5 are that CWM 5 doesn't have trouble making and restoring backups (made in CWM 5), the ability to have ADB in recovery and the option to reboot to download.
Additionally, it has most of the changes made after Dec 7, 2011:
Click to expand...
Click to collapse
Thank you JMW and FB.
Is this the normal message state?
CWM-based VooDoo LagFix Recovery v5.0.2.7
Voodoo lagfix is actually: disabled
......................next boot: enabled
Option:
/system lagfix conversion: yes
...................debug mode: no
I show this from a terminal session:
/system ext4 rw,
/cache ext4 rw
/data ext4 rw
I tried to disable VooDoo but it does not disable, do I need to start with VooDoo disabled from version 0.0.2d?
I went back to v0.0.2d and disabled VooDoo, then flashed v0.1.1 rc2. The conversion took place per the voice. But it still shows that it is disabled as above.
Bark, read the OP under Features
http://forum.xda-developers.com/showthread.php?t=1513287
The RC2 version of the kernel forces you onto ext4 (lagfix) since there's no real reason why you should stay on RFS (lagfix disabled).
Not sure why that was confusing to me, but I really appreciate your quick response. Thank you for straightening me out!
Whoops! I heard my phone rebooting as it sat on the table. I guess I'll go back to v0.0.2d.
I'm running stock GB with AS 14.1 and Tegrak UV/OC to 1.2.
I have been running this kernel without any problems whatsoever.
I would check your UV/OC values to see if that is causing the reboot.
FBis251 said:
The main differences between CWM 3 and 5 are that CWM 5 doesn't have trouble making and restoring backups (made in CWM 5), the ability to have ADB in recovery and the option to reboot to download.[/url]
Click to expand...
Click to collapse
jigglynuts said:
I have been running this kernel without any problems whatsoever.
I would check your UV/OC values to see if that is causing the reboot.
Click to expand...
Click to collapse
Hello JN,
I'm going to chose oc/uv over the latest version of this kernel. I checked my settings and they are as suggested. I guess if the v0.0.2d kernel can tolerate my OC/UV settings and not reboot then I would deem it a tad more stable.
Since I can use the CWM5 version at will, I will use it to do backups. But I will use the v0.0.2d version daily as the OC'ing does make this device snappier. I don't understand the "ADB in recovery" part of the explanation, got to do some reading.
Do you overclock your phone, I would be interested in the setting you use.
Thanks!
my phone rebooted once after flashing the latest kernel.
after half a month no problems yet
Sent from my SGH-T959V using xda premium
JuLes' MostWanted said:
my phone rebooted once after flashing the latest kernel.
after half a month no problems yet
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
Hello JMW,
That is interesting. I wonder if after some time the kernel adjusts something and then calls for a reboot.
I will go back and run the latest again and then give it some time based upon your input.
Thank you.
Common causes for phone to reboot is the voltage governor is too low or just something wrong with it
just for the record Bhudven and Fb nailed the values ;-)
JuLes' MostWanted said:
Common causes for phone to reboot is the voltage governor is too low or just something wrong with it
Click to expand...
Click to collapse
The voltage/cpuspeed 's have not changed between v0.0.2d and latest.
The thing is, I only know of a few people that have any problems and no one has given me or fb any kind of logs to prove there is a problem.
No logs, nothing to fix.
JuLes' MostWanted said:
just for the record Bhudven and Fb nailed the values ;-)
Click to expand...
Click to collapse
The values have always been nailed. The have not changed.
The only problems I have with this kernel is going from BML (fsr/rfs/ext4) to MTD then back to BML.
I try using heimdall and odin and the only way for me to revert back to bml is using the 'eraseall' command at the sbl prompt (which isn't easy to get to if you don't have the right tools or know what your doing) then one-click with bootloaders. Something wrong with the erase-block-size/page-size with mtd vs. bml. idk, still trying to figure that one out.
too bad i cannot provide logs.
as far as observe it always reboot once after i install the latest from fb....
note: before reboot, laggy
but all runs great after that reboot
i dunno why this happens but I think it a great thing
i just wanna make people aware of it.
damn this kernel diving must be mind boggling thats why I will stick to theme
bhundven said:
The voltage/cpuspeed 's have not changed between v0.0.2d and latest.
The thing is, I only know of a few people that have any problems and no one has given me or fb any kind of logs to prove there is a problem.
No logs, nothing to fix.
The values have always been nailed. The have not changed.
The only problems I have with this kernel is going from BML (fsr/rfs/ext4) to MTD then back to BML.
I try using heimdall and odin and the only way for me to revert back to bml is using the 'eraseall' command at the sbl prompt (which isn't easy to get to if you don't have the right tools or know what your doing) then one-click with bootloaders. Something wrong with the erase-block-size/page-size with mtd vs. bml. idk, still trying to figure that one out.
Click to expand...
Click to collapse
Thank you for your work, but can you please address why the kernels you released since you disabled Deep Idle and DMA Engines have random reboot issues. Many many people who have reverted back to the 2d kernel no longer have these issues.
I'm fairly sure it's because of init.d scripts messing with the CPU settings and other kernel settings.
I'm going to write a "stability" build of RC2 that just backs up your init.d on boot and wipes the directory. Bet you'll get rid of your reboots until you start messing with Tegrak and OC/UC/UV settings.
bhundven said:
No logs, nothing to fix.
Click to expand...
Click to collapse
I am so willing to submit logs, if I only knew how. I have read thousands of posts on this site and have learned a ton about my phone and how to upgrade it. But try as I may and I have tried, I cannot find a good reference document on collecting logs. I heard some people say I will run a logcat and I have downloaded log collector from the market.
I used to work in the field service arena and it was common that our customers would collect error data for us to use to find their problems, but they would always collect the wrong things until we gave them a list of what we needed and how to collect it. So I am sure that it is my noob searching that has made it difficult for me to throw a lasso around this issue, but if someone would direct me to a thread or give instructions I am sure it would help me and I think maybe some others too.
I would also like to thank the devs that replied in this thread. I'm sure there are better things to do then reply again to the reboot issues some are experiencing. I truly appreciate your time, offerings and effort.
Thx
FBis251 said:
I'm fairly sure it's because of init.d scripts messing with the CPU settings and other kernel settings.
Click to expand...
Click to collapse
I have no init scripts, no init.d directory, & do not oc/UV. I have the reboot issue. Bryan looked @ a logcat I took a while back but it held no clues. I'll see if I can find the time to install a kernel past 2d and troubleshoot.
Sent from my SGH-T959V using xda premium
Well if you DO wind up testing this, we needs these files:
hampsterblade said:
I'm currently looking through
/proc/last_kmsg
/data/tombstones/
/data/system/dropbox/
I just found something suspicious in system server wtf about the time the phone shut down
.
Here are the logs if anyone wants too look over.
Click to expand...
Click to collapse

Mtd vs Bml

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.

Categories

Resources