q AND a v1.45 -The noob questions answered/how-to guide!
I've created this thread in the interest that “noobs” will find it and hopefully find the answers to their most often asked questions and perhaps to dispel myths that seem to crop up from time to time. My goal is to reduce the number repeated thread posts and concentrate these Q&A questions in quick and easy format.
In the event your answer isn't in here somewhere and you need to start a thread, please include your current ROM, Radio (by RUU number of origination), and kernel if you've flashed one that didn't come in the ROM. Summing it up in your sig makes it easy for people to see in any of your posts. (See my sig at the bottom of this post for an example.)
NOTICES:On the evening of 8/31/11 a bug was found to be causing force closes of the camera and Gtalk. The issue has to do with the camera and a solution has been discovered. This LINK contains "camera.zip" and can be flashed via CWM to resolve this issue.
Credit: mpwt51 on the Android Central Forums and Snow02 on the BAMF Forums
The ClockworkMod issues have been resolved in newer releases so I've removed the link.
Index:
1: Rooting your device.
2: What ROM is best for you?
3: Flashing a ROM
4: What radio will work with your ROM?
5: Flashing a radio
6: Flashing an RUU
7: Flashing a kernel
8: Facts about your battery and charging.
9: Titanium Backup-your friend and enemy.
10: Setting S-on/unrooting
11: Troubleshooting!
Useful references
Second Post: OC'ing and leak news
1: Rooting your device.
Rooting your device is not something that should be attempted because your buddy did it and you want to be cool like him. Every rooting guide or tool SHOULD state clearly that you're going to void your warranty and may also destroy your device in the process (a.k.a, “brick” it). Rooting an Android device is to attain superuser permissions to perform various administration level functions which have been deliberately locked out by the manufacturer to prevent you from stealing carrier services, removing software, and damaging the device. I would like to emphasize “damaging the device”.
If you're not rooted already, and you're aiming to, you're life has become easier. We used to do it though ADB, but jcase is endorsing Revolution, so I must deffer to him. For those interested in the "old fashioned" way, you may still find it HERE.
The old ADB method will still work on all firmwares for the Thunderbolt, but different exploit files are needed. Revolutionary is currently the preferred method and will work on all known Thunderbolt firmwares. And by ALL, I mean from the first engineering leak to the latest 2.11.605.3 Gingerbread OTA. This will remain the case for all future leaks, and if this changes, I shall note it accordingly here and indicate what new rooting method will work.
Please direct questions pertaining to the Revolution method to the thread in the development section. I've never used this method, so I'm not a good source of advice.
To stock root users:
I highly advise NOT staying with the stock ROM after rooting. That is a VERY old RUU. Verizon is pushing updates automatically which WILL render your phone fairly useless until you remove the update files. To avoid this, use a custom ROM. Ideally, you SHOULD move to RUU 1.70 ASAP as it resolves many connectivity, power usage. and functionality issues.
If for some strange reason antique firmware lights your fire and you're device has auto-updated to OTA 1.70 and entered something of a boot loop, THIS LINK has fixes for you.
2: What ROM is best for you?
You will never get more answers for any question than this question. What ROM is best for you is HIGHLY subjective and largely hinges on what you expect from your device. I'm going to ask, on behalf of all XDA members, that you DO NOT start a thread like "What ROM is best for me?" filled with requirements, presumptuously expecting an influx of polite and informative answers. Instead, please DO investigate things for yourself. Here's some helpful info to get you started down that path:
Sense ROMs: Sense ROMs are built from RUUs, either officially released or leaked. An RUU is the complete update file for a handset; including the bootloader, radio, and ROM. Currently, all Gingerbread Sense ROMs are based on leaked RUUs. Each RUU has a version number, for example 2.10.605.0. The higher the number, the newer it is. Newer is generally better. Devs will usually include the base RUU version number in their OP. I like to think of custom ROMs developed on a common base as a family of sorts. They're going to generally have some similarities. They can have major differences as well. Some things about them won't ever change though.
Sense ROMs come in many flavors; 2.1, 2.1/3.0 hybrid, 3.0. It's really hard to tell what you like until you play with some and get to know them.
AOPS ROMs: AOSP ROMs are not built from leaked or released RUUs. They are built upon code obtained through the Android Open Source Project and are custom built for the devices. HTC, and manufactures in general, don't support AOSP being developed for their device. As a result, AOSP devs basically have to figure it out for themselves which makes the ROMs much more experimental. These ROMs typically come out in 1 or more versions, usually identified by date of release if it's a final release version, or an RC (release candidate) version if it's still in beta testing. Think of the version number and RC/beta number like the RUU number of a Sense ROM. For instance, CM7.0.3 may have several release versions that are only very slightly different. Then you may have several CM7.1.0 Beta or RC candidates that may less stable, but being offered for real world use and user feed back. That's basically the picture for the dInc currently, not the Tbolt, so don't quote me. CM releases are generally going to all look and feel the same and carry the same group of features. OMFGB is going to be making a name for itself with different features and characteristics. You won't know which you like until you try them.
3: Flashing a ROM
There are 2 ways to flash a ROM, however I'm only going to explain one of them because the second method is not prefered by any dev I'm aware of. The method I'm describing is through ClockworkMod Recovery.
There will be instances where you will not need to wipe anything to update your ROM. Examples would be ROMs called “nightlies” and ROMs that are an evolution, such as CM7. Some ROMs will have a command in the updater script to wipe and/or format directories or partitions, so unless unpacking the ROM and editing the updater script sounds like fun, accept the fact it WILL wipe your device. BE SURE TO READ THE OP BEFORE FLASHING so you know whether it will wipe your device or not, whether you must manually wipe it, or if flashing over your current ROM is acceptable. IF wiping isn't desired or required, skip step 3.
Step 1: Download the ROM of your choice.
Step 2: Reboot into recovery. If this is your first ROM flash, remove the battery and re-insert it, then hold Vol-down while powering the device on. Do not release Vol-down until you see the white HTC screen. When the bootloader comes up, select “recovery”.
Step 3: Wipe user data/factory restore. This will be an option on the main menu of ClockworkMod Recovery (CWM). Confirm the wipe. It's also wise to also format /system. This can be found under "mounts and storage". Select /system and confirm the format.
Step 4: Wipe the dalvik cache. This is done by selecting “Advanced”, then “wipe dalvik cache”. Again, confirm this action to complete it.
Step 5: Flashing your ROM. On the main menu you will be selecting “install zip from sdcard”, then “choose zip on /sdcard”. You'll then see a directory tree of your SD card. Assuming you haven't moved your downloaded ROM, you'll find it in “download”. Select the ROM's zip file, confirm the flash, then sit back and wait. First boots on a new ROM are slow so be patient. The more you do this, the more comfortable you'll get with the whole process.
4: What radio will work with your ROM?
That's a pretty short answer... with some twists. If you're using ANY gingerbread Sense ROM, ANY "MR2" radio will work for you. If you're using Froyo, the answer gets a bit murky. If you're using AOSP, it gets even murkier. Allow me to explain....
Some Froyo builds based on older "MR1" bases have been ported to use newer "MR2" radios. Examples would be Eaton ROM, and BAMF 1.8.6. Some still use "MR1" radios, but they're slowly going extinct. Certain AOSP ROMs come in 2 versions, one for "MR1" radios, one for "MR2" radios. The bottom line is you MUST read the OP. Gingerbread Sense ROMs are the no-brainer. ALWAYS use "MR2" radios.
A note about "MR" designations: "MR(fill in the blank)" really doesn't mean jack. They are numbers made up on the fly to make things easy to describe. A much better way to describe the radio version would be by the RUU it came from using the first 3 numbers of the RUU, such as "2.10" for the 2.10.605.1 RUU radio. I WISH this was the standard method of designation, but it's not.
The following is the most complete list of Tbolt radios I'm aware of. RADIOS
This link is the CDMA and LTE radio packaged together: Adrynalyne's list
These are described THE RIGHT WAY, by the RUU of origination. Adrynalyn's list takes it one step further and describes "MR" version and release details. You will notice that there are actually 2 radios for each RUU number. This is because the radios have been parsed into individual CDMA and LTE radios. The common reference to "the radio" usually refers to the pair of radios from an RUU, so, in order to flash the "MR2" radio, you'd need to flash both the CDMA radio and the LTE radio. The advantage of this is you can mix and match radios depend on what works best for you, your area, and your device. For those not interested in the mix-n-match game, Adrynalyn's list packages the pair nice and neat for simple flashing.
That still leaves us with this whole "MR1/MR2/MRwhatever" quagmire of "what's it mean???" Short answer: MR1 radios are everything from RUU 1.68.605.3 and older, MR2 radios are anything from RUU 1.70.605.0 and newer.
5: Flashing a radio.
Flashing a radio is done much differently than a ROM or a kernel. Instead of using CWM, you'll be doing this through the bootloader. The Tbolt bootloader only recognizes files named PG05IMG. Accordingly, any radio you flash will need to be named PG05IMG.zip. The radio you need will almost always be indicated on the thread for the ROM you're using. If you flash the ROM without the proper radio, you will NOT have any wireless functionality at all. DO NOT PANIC. Flashing back to a compatible ROM will restore functionality, as will updating the radio to the proper version.
Edit: If you're using the radios from the listing provided above, you'll need to do this operation TWICE, once with the CDMA, once with the LTE radio, to have a complete version of a radio. Adrynalyn's radios are complete pairs.
From here you have 2 options. 1) Follow the guide provided in the radio listing, or 2) follow this guide. Option 1 is done through ADB. Option 2 is done solely on the device.
1: Download the required radio(s).
2: Renaming it PG05IMG.zip and placing it on the root of your SD card.
3: CHECK THE MD5 SUM.*
4: Reboot into the bootloader
5: Select “bootloader”
6: The bootloader will automatically search for the update, then it will ask you if you wish to update. Vol-up approves the update, Vol-down declines it. You want to Vol-up to update it.
7: It will unpack and update the radios (or radio, if you're using the singles from the listing), then tell you to push “power” to reboot.
8: After rebooting, remember to remove or rename the radio so that if you need to hard boot into recovery, the bootloader won't find that file and attempt to update it instead of allowing you to move on to CWR.
*Flashing a bad radio can brick your device so it's important to check that MD5. I recommend only using radios from sources that provide MD5 sums for you to verify against. You can use an app from the market to check it, or you may do it through terminal emulator, assuming you have busybox. (Virtually all custom ROMs do, but stock/rooted ROMs don't.) The usual location of busybox is /system/xbin or /system/bin. Sometimes it's found at /local/data. Assuming it's at /system/xbin, your command will look like “/system/xbin/busybox md5sum /sdcard/pg05img.zip”. After a moment, the MD5 for the file will appear and you can compare it to the posted MD5. Assuming they match, happy flashing! If they don't match, delete the file and re-download.
Note about radio file management: It can be a major inconvenience to leave a pg05img.zip file on the root of your SDcard if you need to boot into recovery.... like, it won't be happening. This is what I, and many others, do to manage multiple radio files on our devices.
Rename them instead of deleting them. For instance, you just flashed the 2.10 CDMA radio, so now you've got this pg05img.zip file on your SDcard root. I would rename it something like "2.10_cdma_pg05img.zip" through a file browser as soon as the phone booted back up. Your hboot will ONLY look for files named "pg05img", not simply files with that in the name. What you'll eventually end up with is a quick and easy to understand listing of all your radios, pre-MD5 checked, ready to rename and flash at the drop of a hat. Renaming a file does NOT change it's MD5.
6: Flashing an RUU.
I put this right after flashing a radio because the process is exactly the same. So is the need to check the MD5. An RUU will replace your radio, bootloader, and ROM so don't flash an RUU unless you know exactly what you're doing. In general, you should never need to do this unless you want to return to a completely stock device with S-Off. RUU's are UNMODIFIED firmware that ROMs are built on.
7: Flashing a kernel
Flashing a kernel is done exactly the same as flashing a ROM. In short, you're flashing a new boot image; either provided or created on the fly. The kernel is the guts of Android that interfaces software with hardware and can bring many advantages or disadvantages to the table, depending upon the software and hardware in question. Kernels for HTC devices come in 3 basic flavors: AOSP, Gingerbread with Sense, and Froyo with Sense. These are pretty obvious characteristics of a ROM and determining the kernel you need should be easy. That information can be found on your phone and on the ROM OP. Not all kernels are presently represented on XDA and at this time I will not be providing links to other sources. Let Google be your friend!
8: Facts about your battery
Your HTC contains a variation of lithium-ion technology known as a lithium polymer battery. These are relatively long life batteries which are very resistant to “memory” effects and fluctuations in output voltage. They are the closest thing to ideal that technology provides at this point in time. There's much speculation and rumor floating about these interwebs concerning how they function and how they should be treated. Many of them are imaginative and WRONG. So, here's the real dirt.
First, the BAD things to do with a Li-on battery:
*Keeping it fully charged all the time or storing it longer than a week or so fully charged.
*Shorting it out.
*Storing it for extended periods in a completely discharged state.
*Getting it wet.
*Attempting to overcharge the battery.
*Attempting to overdischarge the battery
Here's why: These batteries can explode gloriously if contaminated with water. Shorting them out generates temperatures that can damage them and cause them to explode. Overcharging can do the same thing as shorting them out. Overdischarging them can permanently alter the components of the cells and render them garbage in very short order.
Next, the GOOD things to do with a Li-on battery:
*Charge the battery and use it.
*Keep it dry, just like the rest of the phone
*If you use multiple batteries, rotate through them so no particular battery is left stored fully charged for an extended period.
*Recharge completely dead batteries as soon as possible as this state my be the most destructive way to keep a battery in. Better yet, if you use multiple batteries, switch them out before it's completely dead.
*Allow the phone or charger to charge the battery as it's designed to. Don't use modified kernels that attempt to trickle charge it. Don't waste your time “bump charging” it.
*Avoid consistently running your battery flat dead.
*If storing your battery for extended periods, run it down to approximately 35% before storing. This is the IDEAL storage charge state.
Here's the why: Li-on batteries have do not exhibit “charging memory” like old Ni-Cad batteries did. The use in running full charge in discharge cycles occasionally is strictly for the benefit of the phone's battery stats. Charging a the battery excites lithium compounds which in turn retain electrons in the shells of the lithium atom. This is due to lithium's volatility and is why it will react violently to moisture and can melt your skin off. Left fully discharged, those compounds are keen to create bonds that fill the void of left by the electrons that powered your device. Left fully charged, the compounds that retain the electrons that power your device can break down under the electron load. Eventually, both of these conditions take place and what's what ultimately ends your battery's useful life, but that degradation can be avoided with proper use. A charge of roughly 35% for long term storage is the optimum to avoid either of those conditions, and a cell in that state can be stored for years without appreciable degradation.
The three most power-hungry devices in your Tbolt are the screen, LTE radio, and CDMA radio, generally in that order. Memory use, as some might suggest, is NOT a significant drain on your battery, and therefore should be used as fully as possible to reduce the use of your forth largest consumer of power, the CPU. Task killers are a waste of time, space, and resources on your phone and have no legitimate use. They are the life support system for poorly designed apps that should have been aborted before birth. Practice software eugenics; keep only the best and most useful apps, delete the apps that abuse your system resources and connectivity. (Your phone doesn't really make convincing fart sounds anyways...)
9: Titanuim Backup-your friend and enemy
Perhaps you've wondered how you might backup all your odds and ends between ROM flashes? Well, the app you're looking for is called Titanium Backup. It comes in two flavors; free and premium. Free is all you really need. What this app will let you do is make full backups of your user app and data, and system apps and data. Sounds pretty groovy, huh? Now you can pick up on your Angry Birds right where you left off, ROM after ROM (Don't lie... we all play it, but don't always admit it.) Hold it right there...
This app is probably more advanced than your average joe needs it to be, and that can get you into trouble. And it's not perfect either.
Generally, all user apps and data can be restored across OS's and platforms. When I moved from my dInc to my Tbolt, it was a breeze. Just had to shuffle a couple files from one SDcard to another and you're back in business. Where people run into issues with Titanium Backup is when they attempt to do a FULL restore. That includes system apps and data that are rarely the same and often not compatible from one ROM build to the next. If you're lucky you only end up with dead apps. If you're not lucky, you get to reflash your ROM and start from scratch. So, here's a few pointers to help avoid complications with Titanium Backup...
*Only use a batch restore operation on USER apps and data. NOT system data.
*Many say NEVER restore app or system data, however, they are wrong. Some system data is restorable, but I suggest manually going down the list and restoring rather than attempting a batch operation restore. The following is system data I KNOW to be stable..
-[User dict] and [user dict htc]. There are 2 keyboard/dictionary system data files that will snap back your dictionary as well as your keyboard settings.
-Bluetooth pairings. This USUALLY works, but not always.
-WiFi hotspots. This will help avoid having to re-enter secured hotspot keys and trusted hotspots to automatically log onto.
-Internet/bookmarks. This will snap your bookmarks back.
-Wallpaper/settings Gingerbread. This SHOULD work... I've never had problems with it.
*It's it's REAL important, make 2 backups of it. Titanium Backup is nice, but it lacks any kind of QoS and does junk out a backup from time to time.
*Backup your SDcard elsewhere from time to time. It's not exactly unheard of in these days of ultra-low voltage and clock settings to corrupt an SDcard. If that's the only place you're data exists, that will be the LAST place your data existed.
Generally, if it's in Red, don't mess with it. If it's white, it SHOULD work, but there's no promise. Some versions of Wireless Tether, for instance, don't restore well from one ROM to another. Green items are system settings and are mostly good to go, but some make assumptions concerning the ROM that might not be true, such as the nature of the framework. Restore with caution. There are many help threads in Q&A regarding Titanium Backup. Please search those before posting. The problems with Ti-Backup have been few and fully explored and explained.
10: Setting S-on/Unrooting
Since there are 2 methods for setting S-Off/rooting your device, there are 2 methods to set S-On and unrooting.
If you used Revolution, follow THIS link.
If you used the jcase ADB method, follow THIS link.
11: Troubleshooting!
As was pointed out to me, there are problems that crop up that seem unexplained to the noob, and even some senior members, so I've decided to add SECTION 10: Troubleshooting!.
1: "EEK! GADS!!! I flashed my first ROM and I have NO SERVICE!!!" Step one: remember the Hitchhiker's Guide to the Galaxy and "Don't panic". Your problem lies with the fact your stock radio doesn't work with your new ROM. Your fix will be to go up to Section 4, follow one of the links provided, then follow instructions provided in Section 5.
2: "My phone keeps trying to update every time I boot into the bootloader!!! This HAS TO be VERY BAD!!!" No... it's actually good because it means your phone is doing exactly what it's supposed to do. Computers have this uncanny will to do EXACTLY what they're told... And what you've told it, unwittingly, is that there's a new update for it. In other words, you've probably left a file on the root of your SDcard called "pg05img.zip". If you're phone still works, just go into your file explorer of choice and delete it or rename the file to ANYTHING except pg05img.zip. If your phone has gone kattywhampus (yes, that is MY technical term), then you'll be forced to remove the file be installing your SDcard in another device or SDcard adapter and deleting it using another device or computer.
3: "My phone boots, but there's NOTHING but a background and it doesn't respond to any hard or soft buttons! Did you just flash a kernel??? If so, what kind? Kernels come in 4 basic stripes and types; Froyo and Gingerbread, Sense and AOSP. Your fixes at this point are A) restore from your last nandroid backup, or B) find the correctly corresponding kernel type for your ROM and flash that just as you would any other kernel. Make sure to wipe dalvik when you do.
4: "I've flashed like 4 ROMs in a row and I'm still having Force Closes on the system process/reboots! Is it bricked?" No, my friend, you're phone is just fine. There's most likely just garbage left in /system which is usually not formatted in a "factory restore/wipe user data". The assumption is that the new ROM will completely overwrite /system, but that isn't always the case. Easy fix: do a manual /system format, then reflash the ROM. You may have heard some myth about wipe 3 times... I call it a myth because it IS a myth. Your phone and SDcard use NAND memory, not magnetic media like a platter or cassette tape. For an excellent explanation why multiple wipes is a waste of your time and useless, read THIS.
5: "help i'm a noob rooted with revoltion clockwork none apps need root won't work help!" This is NOT a question. It's not even a sentence. PLEASE form sentences and questions with words, not mindless run-ons that require the assistance of the Psychic Friends Network to decode. We want to help, so please do the following:
*Use complete sentences and terms. (You did NOT root with Revoltionary, it doesn't do that. It turns S-Off."
*Don't DEMAND answers or demand credentials of the answer giver.
*Provide basic info: ROM, radio, kernel, other software or hardware at play.
Doing this will get you answers much faster.
6: "Hells bells, Margret! I didn't know I shouldn't take an OTA while rooted!" Don't worry, you're not the first and won't be the last. The following are a few sets of instructions that will fix you right up.
Method 1: (thanks to sonicbuffalo for posting this method)
1) Once you are in ClockWorkMod Recovery, scroll down to "Wipe cache partition".
2) Select "Wipe cache partition" using the home key or power button.
3) Now, scroll down to "Yes - wipe cache".
4) Press the home key or power button to perform the wipe.
5) When done, restart your phone.
6) Your ThunderBolt will boot into the Android operating system and will say that the UPDATE FAILED.
7) Choose Cancel to stop the update.
8) Restart your phone one last time and you'll see that the "Powering Off" loop is gone.
Method 2: This will delete your data
1) Once you are in ClockworkMod Recovery, select "wipe data/factory reset" using volume keys.
2) Press home key or power button to select.
3) Answer Yes, by scrolling with vol keys and home or power key to select.
4) When phone reboots, the powering off loop should be gone.
Method 3: This only works if you have a Nandroid Backup from prior to accepting the update.
1) Once in clockwork select "backup and restore" using vol keys.
2) Select using the home key or power button
3) From next menu select "restore"
4) Choose your backup from list and select.
5) Answer yes to restore backup
6) When phone reboots the "powering off" loop is gone.
Method 4: This is a last ditch effort if all other methods fail.
1) Download the Leaked Rooted Update from HERE.
2) Following instructions in THIS post load the rooted leak.
3) When your phone reboots, the powering off loop should be gone and you should be running the latest software and still rooted.
Useful references:
The Official Thunderbolt ROM & kernel Listing v3.0
The Thunderbolt Root User's Dictionary v1.0.1
You're battery may be lying to you...
If by some miracle my mindless, ill-constructed ramblings have helped you, slap that thanks button! Feel free to PM me with any questions or for clarity on anything covered here.
Credits and thanks:
Gu1dry: for his itemized radio thread.
Adrynalyne: for his HIGHLY organized and descriptive radio thread
MattBeyers: for his Root User's Dictionary
DemoManMLS: for Official Thunderbolt ROMs and Kernels listing (retired)
MyComputerDoctor: for continuing to maintain the R&K listing in the stead of DemoManMLS
Byrong: for his spiffy battery info thread.
jcase: for his ADB rooting guide.
OC'ing (update 10/22/11)
For the slightly more advanced noob I present.....
Intro to overclocking!
What is overclocking?
Overclocking is making your CPU/system work at faster clock rates than it was designed/rated for.
How do I overclock?
Glad ya asked! But before I go into the how, I'd like to point out the dangers and why it's beneficial.
Dangers:
The risks involved in OC'ing are probably greater than rooting your device. The worst thing you can do is fry your phone. You might also render your ROM/kernel useless junk on your device that you might need to wipe and restore/reflash. You can also corrupt your SDcard. In the long term, it's possible to reduce your device's lifespan because of the extra heat, which, if high enough, can chemically alter the silicon the transistor gates are made of, thus destroying them. Higher voltages can also induce electron tunneling, a quantum mechanical effect where electrons "tunnel" through the silicon from one circuit trace to another. This can be highly damaging.
Benefits:
The benefits of OC'ing are a significantly faster device. I conjunction with an appropriate governor, you can actually save power while improving performance.
Now, the "how-to":
There are several valuable apps I recommend to add to your OC'ing arsenal. The most popular is SetCPU, which can be obtained for free by XDA members at THIS thread. Instructions for it's use are included in the app as well as the thread. This is a good app to start with for messing around with settings. It will also allow you to select governors and enter governor parameters.
Incredicontrol is another useful tool you'll be interested in. It allows you to alter voltage settings for each clock step.
CPUspy is a very nice little app that provide you with time-in-state readings for every clock step. This will become useful if you're adjusting your governor. It will make evaluating your adjustments fast and easy.
Finally, ScriptFusion by TwistedUmbrella is an excellent long term solution to implementing clock and voltage tweaks. It's a good idea to get that and use it once you know what settings will work.
I can't really give you a step 1, step 2, step 3 guide to this. It's just impossible because every device is different. Instead, I'll try to lay out some method, theory, and reason.
The theory is to push your CPU to run as close to it's limitations as possible before it becomes unstable. Due to the nature of SoC's (system on chip), there are several major components to consider. The core, which executes applications, as well as the GPU, are the most robust components. The least robust are memory, such as caches, and are the first to suffer the effects of overclocking. Be SURE to do a nandroid backup before tweaking settings!!!
The method I tend to use is to first feel out what the CPU is capable of handling at some conservative voltages. Generally, kernel devs set their voltages conservatively because they don't feel like dealing with the heat that comes from some nutjob frying their toy. SetCPU is a good tool for this because you can adjust settings and not have them implemented at boot so if you do crash your device, it will reboot back to stock clock limits. Most devices will be stable at 1.5 GHz at around 1325mv because the S2 Snapdragon is fabbed at the same 45nm scale as the MSM8660 dual-core S3 that powers the EVO 3D at 1.5GHz. If your device isn't stable at this speed, it's quite likely that your CPU isn't a good candidate for OC'ing and only modest increases should be expected.
So, at this point you should use SetCPU to push your clock frequency up until you're either happy with it or it becomes unstable. Don't be afraid of it becoming unstable, it's probably going to happen eventually. All it means is you've found your CPU's limits at that voltage. Your phone will reboot to stock, assuming you did NOT check "apply at boot", and you're back at square one. No harm, no foul.
At this point I recommend installing Incredicontrol or getting comfy with your terminal emulator or ADB shell. Through Incredicontrol, terminal, or ADB, take a look at your voltage table. Incredicontrol provides a nice GUI and is self-explanatory. To view your voltages through ADB shell or terminal, enter the following command:
cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
Memorize, screen capture, or write these settings down for reference. We KNOW these voltages to be stable up to a point and serve as a good baseline. Most kernels have a maximum voltage they will allow. Modern Ziggy kernels are 1400mv.
For sake of explanation, we'll say your device goes unstable at 1.49GHz at 1250mv on the stock voltage table. At this point, push the voltage up by 25mv for that frequency to 1275. Then, try your 1.49GHz setting again. You can either run a benchmark stress test, use the stress test in SetCPU, or use the device as normal to verify if the new voltage setting is stable. Hopefully it is. If so, increasing the voltages above that frequency by 25mv may make them stable as well. It doesn't sound like a lot, but 25mv does make a difference. Eventually, you'll find a point where too much voltage makes the device unstable, and too little is unstable as well. That's about the point where you're risking damage to your device and I suggest backing down the frequency by about 100MHz and calling that your safe maximum.
Now, for the other end of the frequency specturm...
You have a maximum AND a minimum. Most often, the frequency and voltages for the minimum are set for stability, not power saving. Some kernels will run as low as 22MHz. Some functions, such as playing media with the screen off, will not function well at such slow speeds. Usually 122MHz will perform well. After finding the lowest frequency that works for you, try to adjust the voltages down as low as possible. Since your phone spends most of it's time down around these frequencies, modest, but real power savings can be realized.
We've found the safe settings! Now what???
Well, you can do things the easy way and just set SetCPU and Incredicontrol to enforce your settings on boot, but now you've got 2 apps that are constantly running and taking up resources, especially SetCPU. There is a better way. That's where ScriptFusion comes into play. ScriptFusion is basically a script that creates a script in the /system/etc/init.d directory where boot executed scripts reside. This method doesn't use any system resources beyond those already used to establish these settings. ScriptFusion is easy to use, but it's settings execute at boot, therefore, any mistakes cannot be easy fixed if they make the system unstable. That's why I suggest using it as a method of implementing final changes, not feeling out where your points of stability are.
Still another way is to write your own script. Simple Linux commands in a properly formatted text file get the job done. Many resources can be found to show you how to write these kinds of scripts. It's also possible to copy a script already on your device, modify it, and push it back to the device using the "adb push" command.
Using a script:
The following is the actual script I use with the setup described in my signature. It began with a speedtweak.sh script that I pulled and edited over time to suite my desires.
Code:
#!/system/bin/sh
# Mode: extreme
#built for Imoseyon TEST kernels and branches. contact [email protected] with questions.
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
echo "184320 750" > $sysfile
echo "245760 825" > $sysfile
echo "368640 900" > $sysfile
echo "768000 1000" > $sysfile
echo "1024000 1100" > $sysfile
echo "1222400 1125" > $sysfile
echo "1408000 1175" > $sysfile
echo "1593600 1375" > $sysfile
echo "1766400 1375" > $sysfile
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1593600 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo smartassV2 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 60 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_ideal_freq
echo 184320 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_ideal_freq
echo 1593600 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq
#echo 610000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
echo 6 > sys/devices/system/cpu/cpu0/cpufreq/smartass/sample_rate_jiffies
echo 50 > /proc/sys/vm/swappiness
echo cfq > /sys/block/mmcblk0/queue/scheduler
echo 40 > /proc/sys/vm/vfs_cache_pressure
echo "100,200,352,640,2570,5120" > /sys/module/lowmemorykiller/parameters/minfree
echo "0,1,2,11,12,13" > /sys/module/lowmemorykiller/parameters/adj
echo 30 > /proc/sys/vm/dirty_ratio
echo 35 > /proc/sys/vm/dirty_background_ratio
echo 5000 > /proc/sys/vm/dirty_expire_centisecs
echo 1 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/oom_dump_tasks
echo 1 > /proc/sys/kernel/sched_compat_yield
echo 250 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 1200 > /sys/block/mmcblk0/queue/iosched/write_expire
echo 1024 > /sys/block/mmcblk0/queue/read_ahead_kb
#echo "100,200,20000,20000,20000,25000" > /sys/module/lowmemorykiller/parameters/minfree
Everything all the way down to [echo "1408000 1175" > $sysfile] as well as the freq_min and freq_max is generated by the script. Imoseyon's speedtweak.sh doesn't have a quick setting for running at 1.6GHz, so the settings for 1600000KHz were added by me. The parameters with "smartass" in them are there to modify the behavior of the governor. The echo lines going to /proc/sys/vm/* modify RAM and virtual memory use. The lines echoing commands to /sys/* modify memory use and other behaviors. The lines beginning with "#" are ignored.
You've got 2 options, write the script from scratch using an appropriate editor, or modify one already on the device. Why invent the wheel if you don't have to? Let's modify! Here's one method to do it:
1) Connect your Tbolt to your computer with debugging checked and in "charge only" mode.
2) Navigate to your ADB directory in a command prompt window as usual, then enter "adb pull /system/etc/init.d/01vdd_levels", without the quotes.
3) You'll notice a new file in your ADB directory called.... 01vdd_levels! Lets open it with a suitable editor. I use Vim because it's made for Linux and this purpose. Easier ways exist.
4) From here you can make the edits you want to. Change a voltage, set your min or max freq, or adjust one of the many parameters of the governor you've chosen. A list of parameters for the active governor can be found using the following command: "ls /sys/devices/system/cpu/cpu0/cpufreq/(name of governor)" This doesn't work on non-active governors. "echo" commands set a parameter, followed by the parameter value, followed by the parameter location.
5) Once you've edited or created the parameters you want to run in the script, save it.
6) Go back to ADB. Enter "adb remount" to make /system writable. Enter "adb push 01vdd_levels /system/etc/init.d" to push the new file. It will automatically copy over the old file.
7) Now we have to set it's permissions. Enter "adb shell". That will take you to the command shell. Then enter "chmod 777 /system/etc/init.d/01vdd_levels". This permission level is higher than what it needs to be, but it will get the job done.
8) Reboot by exiting out of adb shell. Enter "exit" in the shell until you're back at the DOS prompt. Then enter "adb reboot". Your device will reboot a moment later and all your script setting SHOULD be in place if you've done it right. You can check to see if that's the case using the "cat" command. An example would be:
cat /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
The result of that command should reflect the value you've entered in the script.
Another way of editing an already existent script: Our friend, Script Editor!
* You might need to modify file permissions to edit a stock file. In terminal: chmod 777 /system/etc/init.d/name_of_file
1: Go to the market and install Script Editor.
2: Navigate to /system/etc/init.d/01vdd_levels and select it.
3: You'll get a window with all kinds of spiffy options. We want to edit. If you have a text editor or a file manager with and editor, it will ask you to select one.
4: Edit your script. Double check your values. Then save it.
5: At the file menu you saw before, select "Run". You'll get a terminal screen as the script runs. Once it's finished, exit out with the button at the top left. You're all done!
The reason for editing the script the way I've done, by adding in parameters for the governor, is to better manage how the governor performs. Some simply cut the balls of their device by setting clock settings low to save power. No need for that if your chosen governor is behaving the way you want. I find the settings I have for smartass keep spikes up to full clock speed to a minimum and saves even more power than just castrating the device because it's CHOOSING to run at slower freqs, not artificially limited to them. Therefore, under more modest loads, it's going to use more modest settings, not the max possible, even if it's a low max. Properly tweaked, you're device may rarely exceed factory clock speeds, but if need be, summoning 1.6GHz is possible. Obviously this method is more efficient than castrating your device.
If you're prone to using different governors, or you like to change you freq_min or freq_max settings, you may add additional data to the script with no ill effects. For instance, if I change to the interactiveX governor, I can simply add in more lines to alter that governor without removing the lines for the smartass. The parameters for the smartass simply won't be implemented because the path becomes invalid.
This is the leanest method of implementing kernel settings, and the most powerful. This script by no means is the limit to what you can do. What a script is able to do depends on the kernel features you're applying it to. It's possible with some kernels to alternate between governors based on conditions of the device. For me, this script gets the job done and that's all I care about.
A valuable note on scripts: There's an app called Script Manager that does an excellent job helping to manage, edit, and create scripts. With this app, it's possible to edit a script, save it, and execute it. It will also allow you to execute scripts on boot that aren't in /system/etc/init.d. If you're attempting to edit a script in the /system directory and it warns you that it's read-only, back out of the file edit functions, hit "menu", then "more", then "advanced options", and select "mount /system as RW" If scripts are your thing, this is a very handy app to have.
"Geeze Loonatik! What's all that crap mean???"
Good question. There's a lot of numbers in there that don't seem to have an obvious value. It took me a while to look if up and get decent answers, and I still haven't figured it all about, but let me share what I know.
/lowmemorykiller values: These values are pages. There are 6 of them that dictate the minimum number of pages (4kb in size) allowed free before processes are killed in that catagory. More on this can be read HERE. Additional info can be found HERE.
/proc values: These values dictate virtual memory and RAM use and behavior. There's actually a lot of them, but most aren't going to do much, and some don't even apply to Android devices, but are there because it's Linux. THIS link does a very good job documenting them.
/smartass/sample_rate_jiffies: A "jiffy" is a time value based upon a number of clock cycles. The number of clock cycles is fixed, but not always the same for every implementation.
/sys/block/mmcblk0/queue: These parameters are pretty straight forward. Time is measured in milliseconds and size in kb. Before you look at these and say "Hell! I'll just set it to read a MB at a time ahead and IO reads and writes to expire in 150ms", consider the fact that will become the top priority of your device. It's entirely possible to create lag by setting IO operations to such high performance that will be pretty much all your phone wants to do. My settings are actually pretty extreme, but they work for how I generally use the phone.
I'll try to explain more as I have the time and learn more.
Credit: Androcheck, Pikachu01, Linuxinsight.com
I hope someone finds this useful. If anyone has any input or suggestions, feel free to toss them out there.
Very useful. Keep this updated please.
Stickied.
You may want to mention in OP that if using TitaniumBackup between roms that users shouldn't restore system apps or data (red in TiBu). While it may RARELY be compatible, it causes more problems than it is worth. It appears users don't understand that wiping data/cache and then restoring all your data back with TiBu is counter productive.
White=good
Green=generally ok but still easily causes problems in some circumstances
Red=NO
While this is not specific to Tbolt at all...It may still be useful at least to help with understanding.
Another scenario that happens TOO often (and usually gets a new thread started each time it's asked)...
User's leaving the PG05IMG.zip file on their sdcard, ROM bootloops from something they did, and the user subsequently freaking out because they have no idea how to get their phone to work again.
I know you made sure to mention removing the file in step 5 of Flashing a Radio but others may not flash according to your steps and/or flash something else other than a radio that didn't mention removing the file afterwards.
Absolute_Zero said:
Another scenario that happens TOO often (and usually gets a new thread started each time it's asked)...
User's leaving the PG05IMG.zip file on their sdcard, ROM bootloops from something they did, and the user subsequently freaking out because they have no idea how to get their phone to work again.
I know you made sure to mention removing the file in step 5 of Flashing a Radio but others may not flash according to your steps and/or flash something else other than a radio that didn't mention removing the file afterwards.
Click to expand...
Click to collapse
I hear ya.... I'm trying to figure out how I want to restructure some of the thread so information like that isn't repeated numerous times and isn't buried in a how-to.
market forse closes..
hey guys, i rooted my thunderbolt and now the app market is always randomly popping up and saying it needs to force close.... if i clear cache and data, uninstall updates its works for a minute and can get into it, but as soon as i switch to another app it wont let me back in, and then its starts randomly popping up again.... heres the vid i followed to root, if it helps..... http://www.youtube.com/watch?v=yQYoeFrJ1Jk&feature=related thanks!
RUU Question
First post! Somewhat of a noob here, but an enthusiast none the less. The leaked RUU posted yesterday is in .exe format, so should I zip it up and rename it? or just rename it to PG05IMG.zip? Don't want to brick this bad boy. Thanks in advance.
jc-cshmny said:
First post! Somewhat of a noob here, but an enthusiast none the less. The leaked RUU posted yesterday is in .exe format, so should I zip it up and rename it? or just rename it to PG05IMG.zip? Don't want to brick this bad boy. Thanks in advance.
Click to expand...
Click to collapse
hmmm.... Not sure. Let me look into that.
edit: It's already been done for you. Here you go! LINK
Thanks. Gonna give it a go now.
I have a couple questions and just a little background.
1) I was an Evo user until 3 days ago when my phone got stolen. So, it was cheaper for me to cancel my sprint contract and get a new phone vs. buying another evo outright (buying off ebay wasn't really an option because I didn't trust the ESN would truly be clean). Ended up going to verizon and hopped on my fam's plan, which got grandfathered in on the unlimited data.
2) Thunderbolt seems a bit different from the evo (rooting is so much easier on the evo). Anyways - the root thread says something about NOT to use the root method below (which seems to be the typical older, adb, etc way to do it). Which one is the way to go?
3) What's with all the talk of bricking the device? Is this something that happens on the Tb from trying to root it.....flash roms....etc? Very few if any actually truly bricked their evo. Bootloops and whatever - but that's just needing to change something usually
4) Voiding the warranty - not really - can't you just unroot?
MedSchool26 said:
I have a couple questions and just a little background.
1) I was an Evo user until 3 days ago when my phone got stolen. So, it was cheaper for me to cancel my sprint contract and get a new phone vs. buying another evo outright (buying off ebay wasn't really an option because I didn't trust the ESN would truly be clean). Ended up going to verizon and hopped on my fam's plan, which got grandfathered in on the unlimited data.
2) Thunderbolt seems a bit different from the evo (rooting is so much easier on the evo). Anyways - the root thread says something about NOT to use the root method below (which seems to be the typical older, adb, etc way to do it). Which one is the way to go?
3) What's with all the talk of bricking the device? Is this something that happens on the Tb from trying to root it.....flash roms....etc? Very few if any actually truly bricked their evo. Bootloops and whatever - but that's just needing to change something usually
4) Voiding the warranty - not really - can't you just unroot?
Click to expand...
Click to collapse
ok... let me go point by point.
1) Groovy on the unlimited data. I'd die without it!
2) jcase is THE man on this subject. If he says go Revolution/AphaRevX, that's how it should be done. If he didn't have full confidence in it, he wouldn't endorse it.
3) All that jazz about bricking devices has largely faded. The problem isn't so much with rooting, radios, roms, or bootloader, but rather suspect parts that were used in certain older Tbolts. If your Tbolt is remotely modern, it should be just fine.
4) Yes, you can unroot. The dev forum has a guide or two on how to go about doing that. But, if you ask me, and my rooted Tbolt just got bricked or smashed or abducted by greys.... I'm going the way of insurance, and I'm telling them the greys took it. But that's just me.
hey i have the CyanogenMod 7. Im having trouble with it! I just put the rom on there and dl gapps. Now im trying to work the radio because it wont let me log into my gmail account. Can you please tell me what radio i need for the cyan 7 rom please!! i would appreciated all the help and will give you a thanks for your meter!~
patelhj1 said:
hey i have the CyanogenMod 7. Im having trouble with it! I just put the rom on there and dl gapps. Now im trying to work the radio because it wont let me log into my gmail account. Can you please tell me what radio i need for the cyan 7 rom please!! i would appreciated all the help and will give you a thanks for your meter!~
Click to expand...
Click to collapse
The radio you need will depend on which version of CM7 you flashed.
The OP in the CM7 thread always indicates which radio to use for which build. They are mentioned as MR1 or MR2/MR2.5.
Starting with RC1.4 (iirc) it requires MR2/MR2.5.
For CM7RC1.4-present: MR2, MR2.5, OTA MR2, 2.01.605.0 leak, 2.07.605.0 leak, 2.10.605.1 leak, 2.11.605.0 leak, and some others in there somewhere (some prefer OTA MR2 and some prefer the newer GB leaks but which one will work the best for you is subjective).
Individual LTE and CDMA Radios: http://forum.xda-developers.com/showthread.php?t=1048128
OTA MR2: http://forum.xda-developers.com/showthread.php?t=1160346
Others: http://goo.gl/S8EKK
For more, do some looking in the dev sections here or @ rootzwiki. They're easy to find.
okay so i think i am understanding it better.. just to let u know what installed was from
RC1.6.1 FOR MR2/MR2.5 RADIOS Uploaded 8/15 1:20AM
md5sum 240a9eb48a5faad38003d328d10d5237
and Goo-inside Gapps
So what radio do i use? and where can i dl it? im sorry for these annoying amateur questions but we all need to start somwhere.. and i am doing a lot of research as well! just easier if i can get direct answer
patelhj1 said:
okay so i think i am understanding it better.. just to let u know what installed was from
RC1.6.1 FOR MR2/MR2.5 RADIOS Uploaded 8/15 1:20AM
md5sum 240a9eb48a5faad38003d328d10d5237
and Goo-inside Gapps
So what radio do i use? and where can i dl it? im sorry for these annoying amateur questions but we all need to start somwhere.. and i am doing a lot of research as well! just easier if i can get direct answer
Click to expand...
Click to collapse
See where it says rc 1.6.1 then mr2/2.5 it is telling you that you can use one of those radios just search forums and you will easily find them
Sent from my VS910 4G using xda premium
Beamer9408 said:
See where it says rc 1.6.1 then mr2/2.5 it is telling you that you can use one of those radios just search forums and you will easily find them
Sent from my VS910 4G using xda premium
Click to expand...
Click to collapse
Yep... MR2 Radios is what it's calling for. I have links to two good radio listings in my OP in Section 4. I'd suggest the Adynalyne thread. One file to flash for both radios.
You might want to cover about the VZW OTA update (options to stop it) since it looks like there are questions about it daily.
Absolute_Zero said:
You might want to cover about the VZW OTA update (options to stop it) since it looks like there are questions about it daily.
Click to expand...
Click to collapse
Yeah.... I think you're right. I'll have to look into it.
noob here- i have tried to plug my phone in my comp. its asking for the ADB drive to see my phone..... i have tried multiple downloads of diff suppose to be sites for the ADB wondering if you would have one for the HTC Thunderbolt
Well, the time has come that I think my kernel is ready for public consumption.
THIS IS ONLY FOR THE USA VERSION OF THE GALAXY PLAYER 5.0 (YP-G70). If you have a mechanical home button instead of capacitive buttons at the bottom, do not flash this (rumirand has a kernel for you)! If you have a 4.0, do not flash this (SteveS has a kernel for you)!
Read the first three posts of this thread COMPLETELY before asking questions - if you ask a question that is answered in the first three posts, you WILL be flamed.
I'm continuing my Daily Driver name, even though it isn't as good of a name as it used to be. It is my daily driver - but what kernel dev doesn't use their own kernel as a daily driver? It made more sense in the Infuse days when I was running my own unreleased kernel for months and a few people asked for it. Oh well, I'm lazy - same name for now.
This is going to be maintained in the same manner and spirit as my other Daily Driver releases for the Samsung Infuse and Samsung SGH-I777 (AT&T Galaxy S II) - http://forum.xda-developers.com/showthread.php?t=1212795 and http://forum.xda-developers.com/showthread.php?t=1289460
It is built from sources at https://github.com/Entropy512/linux_kernel_galaxyplayer and initramfs at https://github.com/Entropy512/initramfs_yp-g70
Current features:
coolbho3k's Samsung Sleep of Death patch - allows stable use of screen-off profiles with limits below 800 MHz in SetCPU
netarchy's conservative governor tuning patch - Reduces the polling interval, allowing conservative to ramp up/down faster. Over in I9100 land they're calling this "lionheart" and it's all the rage. (It makes me sad when people won't accept a governor until it's renamed and hyped up way beyond what it is...) As an example, a GSII would take 0.4 seconds to ramp from 200 to 1200 MHz with the default conservative governor, it can go all the way in 0.1 second with this patch.
conservative set to default governor - use SetCPU or a similar app to change it
jhash3
TinyRCU
CIFS and Tunneling modules included
ext4 partition mounting support in kernel and initramfs thanks to rumirand - ghetto Lagfix baby!
CWM 5.0.2.7 based recovery - Mostly tested, seems working, but may have a few bugs still to work out, rumirand helped a lot on this one
Insecure kernel - gives you automatic root in ADB shells
Per-file fsync() disable capability - see "dangerous features" documentation below
Standard bootanimation (/system/media/bootanimation.zip) support
Charginghacks - faster charging at low battery, slightly slower near the end, overall faster charging while trying to minimize battery stress
CPU core voltage control - use SetCPU or a similar app
CPU overclock to 1.2 GHz - use SetCPU or a similar app
Planned features, short-term:
Pull a few other bugfix commits from my other kernels
Clean up CWM implementation
Planned features, mid-term:
Proper Voodoo Lagfix support (Automatic partition conversion instead of manual)
Planned features, long-term:
Overclock beyond 1.2 if people prove they can handle 1.2 with maturity (Infuse community couldn't handle any OC in a responsible manner...)
Features not planned:
Anything that has a high risk of trading off stability for performance, unless it can be completely disabled by default
Alternative governors - They almost always cause wacky behavior in some cases, and they don't offer anything that can't be done with a combo of SetCPU profiles and tuning the conservative governor now that the minimum poll rate has been dropped.
How to flash .tar releases:
Linux/MacOS:
I forgot that Heimdall doesn't like this particular device - you will need to use a Windows virtual machine with USB passthrough support (like VirtualBox) and Odin, or root the device using the zergRush exploit and follow the "rooted device" instructions. (Ambrice has a fixed version of heimdall, but it must be compiled from source. If you know how to do that you don't need tips on how to use it. )
Windows:
Enter download mode - Power off your device completely, hold VolDn, and insert the USB cable
Use Odin - Google it or search these forums for details - try AdamOutler's resurrector thread in this Development forum
Any rooted device:
Extract the zImage from the .tar file of the release. On Linux, it can be the following (which should work in an ADB or Terminal Emulator shell on the Player itself.)
Code:
tar xvf <releasefile>.tar
From a shell with root access (ADB or Terminal Emulator), do the following:
Code:
dd if=zImage of=/dev/block/mmcblk0p11
How to flash .zip releases:
Put it on your sdcard, enter CWM, flash the .zip using CWM
If you do not have CWM, install an older .tar release then flash, or follow the "Any rooted device" instructions above, but extract the zImage from the .zip instead of a .tar
3/5/2012 Release:
Overclocking to 1.2 GHz (use SetCPU or a similar app to enable)
Support for running scripts in /system/etc/init.d
3/3/2012 Release:
Voltage control (no overclock yet, coming next)
1/29/2012 Release:
charginghacks from Infuse: Charging current on a wall adapter raised to 800 mA at lower battery, dropping to 700, then 600 (stock), then 550 (slightly below stock) as battery voltage reaches maximum. This gives overall lower charge times while trying to not stress the battery too much.
Also, final charge termination happens earlier - while this results in slightly less battery capacity per charge, it will help the battery retain capacity over time.
1/23/2012 Release:
Initramfs: Standard bootanimation support. Place a standard bootanimation in /system/media/bootanimation.zip - Note: The "stock" bootup sound still plays.
1/22/2012 Release:
A few bugfixes and power management improvements pulled in from other kernels
Ability to disable per-file fsync() - good for benchmark epeen, potentially dangerous for your data
1/14/2011 Release:
Initial release
FAQ
Q: Why does CWM default to my external SD card for backup/restore/flashing ZIPs?
A: This is the standard for Android devices going forward - internal on /emmc and external on /sdcard
Q: How do I enter CWM?
A: Until ROMs come out that have extended power menu mods: Power off your device, then:
Hold VolUp
Hold Power
Release Power when the SAMSUNG screen appears (continue holding VolUp)
Release VolUp when CWM appears
Q: I'm still not rooted?
As stated in the features, an insecure kernel only provides root in an ADB shell. Either use ADB to push /system/bin/su and /system/app/Superuser.apk and chmod them to the correct permissions, or take the easy way out and flash ChainsDD's Superuser package in CWM - http://androidsu.com/superuser/
Q: I used ROM Manager to do something, and something weird happened/went wrong. Why?
A: ROM Manager has not worked properly on any device I have ever owned. It softbricked any Infuse that had Voodoo Lagfix enabled, and never works properly on the SGH-I777. The only thing I've ever seen it do right was install gapps on CM7 on the I777.
Q: My battery will never charge past 80%, why?
A: The way Samsung estimates state of charge on our devices is extremely primitive and, in general, poor. Instead of a dedicated fuel gauge IC, they have tried to estimate battery directly from voltage with some funky compensation offsets depending on current operating state - the offset for wall charging is so high that it is impossible for the battery to read higher than 80% when on a wall charger unless you're putting the device under heavy load to activate some of the other compensation offsets. Sometimes it seems like the compensation code doesn't "kick in" when plugging in a charger, allowing you to see a higher number, other times it'll get "stuck on" even after removing the charger. The general thing, though, is that any percentage estimates of battery state are WILDLY inaccurate.
Q: Can you implement Voodoo Sound?
A: No - We have the same audio chip as the Galaxy S2 and Galaxy Note (Yamaha MC1N2) - Voodoo Sound requires a Wolfson WM8994.
Documentation on "dangerous" features:
Per-File fsync() disable:
This allows you to disable per-file write forced syncs. (e.g. if an app tries to force a write straight to disk, it'll just go to cache). This achieves the same goal as the modded sqlite hacks seen in tweaks such as USAS, however it can be disabled at runtime.
WARNING: THIS CAN CAUSE DATA LOSS OR CORRUPTION IN A CRASH
To enable, do the following in a terminal, or add it to an init.d script (look at my ondemand script as an example):
Code:
echo "1" > /sys/module/sync/parameters/fsync_disabled
And to disable (return to the default):
Code:
echo "0" > /sys/module/sync/parameters/fsync_disabled
Good for around 200 points of epeen in the database benchmarks in Antutu or 500-600 points of epeen in Quadrant. Real-world benefit: Probably not worth the data integrity risk, but you've got a choice now.
*reserved for whatever the heck I forgot above*
Thanks a ton Entropy512!! Been waiting for this.
Going to have to buy you a six pack via the Donate button!
Congrats Entropy512. I'm really thankful for your cooperation.
Its finally here!! Thanks so much entropy
Nice job entropy! Good to see that there is at least some development going on for these devices. This makes me wish I got a 5.0 instead..but I'm stuck with a 4.0.
Sent from my YP-G1 using Tapatalk
Thank You
I myself along with others appreciate you developing for the Galaxy Player 5.0 it is a great music player and it falls in the Galaxy family its a good device
Sent from my Galaxy Nexus using Xparent Blue Tapatalk
Says we can use Odin...do see put this in a phone or pda slot
Zei said:
Says we can use Odin...do see put this in a phone or pda slot
Click to expand...
Click to collapse
PDA - only modems go in phone I believe.
Just like flashing any other kernel in Odin.
Edit: CRAP I have Heimdall instructions but Heimdall won't work on the Player... I'm so habitually used to Heimdalling...
Would a factory stock image + root + this be good enough to post if done w/ the backup/restore feature?
Zei said:
Says we can use Odin...do see put this in a phone or pda slot
Click to expand...
Click to collapse
Yes when you use odin you will need to put the rom in PDA slot.If yiu use heimdall you will need to extract and flash the files separatly.
I hope this helps.
---------- Post added at 11:53 AM ---------- Previous post was at 11:53 AM ----------
Entropy512 said:
PDA - only modems go in phone I believe.
Just like flashing any other kernel in Odin.
Edit: CRAP I have Heimdall instructions but Heimdall won't work on the Player... I'm so habitually used to Heimdalling...
Click to expand...
Click to collapse
Heimdall does work on the player. I use it.
Hmm... odd, I tried to use it and it gave me some odd errors I've never seen before (I forget what at the moment) and then put me into forced download mode. I know a pit-dump has some rather odd looking results. Maybe if I just try and flash a kernel it will work.
I'll try again later today, and edit the instructions if it works.
I have my Player shut off for most of today - I've been having strange battery drain problems on my GSII for the past week or so, only when at home - and it seems like it started when I got the Player. So I'm shutting it off to see if it actually is affecting my phone.
Edit: Heimdall still isn't working for me
Code:
Heimdall v1.3.1, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
Handshaking with Loke...
Beginning session...
Session begun with device of type: 0
Downloading device's PIT file...
PIT file download sucessful
Uploading KERNEL
100%
ERROR: Failed to confirm end of file transfer sequence!
KERNEL upload failed!
Ending session...
Rebooting device...
Re-attaching kernel driver...
After I flashed your kernel it won't let me connect to the market, my Wi-Fi is turned on and I connect to the browser just fine but not the market, help?
That's strange - no problems with market connections here. (Edit: Just updated BetterBatteryStats...)
Try rebooting?
Or wait a bit - sometimes the Market just goes down.
Entropy512, I've been studying your github and how you enable ext4 support in the kernel. Could you explain how you did it? I know it has to do with editing "/ arch / arm / configs / yp_g70_usa_defconfig" but I can't find that file in samsung's source or on Steve'S github. And after you do that you just edit the mount points in init.rc, right? I'm asking because I'm gonna try to get ext4 (lagifx) for my 4.0!
Thanks.
P.S. sorry if I'm a noob
klin1344 said:
Entropy512, I've been studying your github and how you enable ext4 support in the kernel. Could you explain how you did it? I know it has to do with editing "/ arch / arm / configs / yp_g70_usa_defconfig" but I can't find that file in samsung's source or on Steve'S github. And after you do that you just edit the mount points in init.rc, right? I'm asking because I'm gonna try to get ext4 (lagifx) for my 4.0!
Thanks.
P.S. sorry if I'm a noob
Click to expand...
Click to collapse
yp_g70_usa_defconfig was copied from venturi_usa_defconfig prior to modifying it - I decided to start maintaining my own defconfig rather than overwriting the original one.
Galaxy Player 4.0 is palladio instead of venturi. SteveS also uses a renamed defconfig though - something like steves_blahblahblah_defconfig
To change things for a 4.0, it would be something like
Code:
make steves_blahblahblahwhateverthisis_defconfig
make menuconfig (enable ext4 support in the menus here)
cp .config arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git add arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git commit
Entropy512 said:
yp_g70_usa_defconfig was copied from venturi_usa_defconfig prior to modifying it - I decided to start maintaining my own defconfig rather than overwriting the original one.
Galaxy Player 4.0 is palladio instead of venturi. SteveS also uses a renamed defconfig though - something like steves_blahblahblah_defconfig
To change things for a 4.0, it would be something like
Code:
make steves_blahblahblahwhateverthisis_defconfig
make menuconfig (enable ext4 support in the menus here)
cp .config arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git add arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git commit
Click to expand...
Click to collapse
Cool thanks! Will definitely try it out.
Hey all - hopefuly this is the correct place for this question. I am developing a custom kernel for the Samsung Replenish baseod off of samsungs open source code. I have thus far gotten the kernel to compile and run just fine on the phone. I have also added the SmartassV2 and Interactive governors. No matter which one i set as default through the phonemodel_defconfig, each time I recompile and load the new kernel, it always default back to OnDemand governor.
I have no problem selecting either of the 2 new governors through SetCPU (and the setting does stick from boot to boot as long as I select "Set at Boot") so I know the governors are properly linked into the kernel. I thought that the kernel would start with the default one I selected, but it does not. Is this how thigs are supposed to operate, or am I missing something. I did update the cpufreq.h file in the include directory.
Any suggestions - is this even the correct place for a post that is this low level.
Thanks!
dmrlook said:
Hey all - hopefuly this is the correct place for this question. I am developing a custom kernel for the Samsung Replenish baseod off of samsungs open source code. I have thus far gotten the kernel to compile and run just fine on the phone. I have also added the SmartassV2 and Interactive governors. No matter which one i set as default through the phonemodel_defconfig, each time I recompile and load the new kernel, it always default back to OnDemand governor.
I have no problem selecting either of the 2 new governors through SetCPU (and the setting does stick from boot to boot as long as I select "Set at Boot") so I know the governors are properly linked into the kernel. I thought that the kernel would start with the default one I selected, but it does not. Is this how thigs are supposed to operate, or am I missing something. I did update the cpufreq.h file in the include directory.
Any suggestions - is this even the correct place for a post that is this low level.
Thanks!
Click to expand...
Click to collapse
As far as i know, cpu scaling governor can also be set by init script in ramdisk and /etc/init.d other than default setting in kernel config. You might need to check if there's any init script that contain a line like :
'write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand '
or
'echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'
Those lines will set the cpu scaling governor everytime the phone reboots.
In my device (xperia mini pro), that first line is in init.semc.rc in root folder of ramdisk. It should be different in your device
The second line is usually in a script in init.d folder, but stock rom usually doesn't support init.d, so afaik it only exists in custom rom.
greenAlgae said:
As far as i know, cpu scaling governor can also be set by init script in ramdisk and /etc/init.d other than default setting in kernel config. You might need to check if there's any init script that contain a line like :
'write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand '
or
'echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'
Those lines will set the cpu scaling governor everytime the phone reboots.
In my device (xperia mini pro), that first line is in init.semc.rc in root folder of ramdisk. It should be different in your device
The second line is usually in a script in init.d folder, but stock rom usually doesn't support init.d, so afaik it only exists in custom rom.
Click to expand...
Click to collapse
Thanks for the response. the kernel does support init.d (now, stock did not) but there are not scripts in there as of yet. I also went through all the other startup *.rc scriipts and found one that was echoing ondemand into the scaling_governor file. I tried both comment the line out and reflashing new ramdisk, and chaning it to echo smartassV2 and reflashing new ramdisk. In all cases, Ondemand still comes up.
I've also added a script to init.d that echos governors other than ondemand to scaling_givernors, and still, when the phone is booted, ondemand it is. Note that if I echo some other governor to the file at this point, it does change (I imagine this is what setcpu does in the background anyway).
Could the android system system itself be changing it to ondemand?
Thanks for the help!
dmrlook said:
Thanks for the response. the kernel does support init.d (now, stock did not) but there are not scripts in there as of yet. I also went through all the other startup *.rc scriipts and found one that was echoing ondemand into the scaling_governor file. I tried both comment the line out and reflashing new ramdisk, and chaning it to echo smartassV2 and reflashing new ramdisk. In all cases, Ondemand still comes up.
I've also added a script to init.d that echos governors other than ondemand to scaling_givernors, and still, when the phone is booted, ondemand it is. Note that if I echo some other governor to the file at this point, it does change (I imagine this is what setcpu does in the background anyway).
Could the android system system itself be changing it to ondemand?
Thanks for the help!
Click to expand...
Click to collapse
Well, actually I never try to change the default governor from ondemand before. Partly because I compiled my kernel using official/stock kernel source, so there's only those stock governor options and ondemand seems to be the best option. My phone is SE Xperia Mini Pro / sk17i and currently running Freexperia CM7 rom. The kernel provided has very good performance but seems to cause the battery draining too fast for me, so I compiled a 'stock' kernel to use with it.
After your post above, I tried to add more governor options from freexperia kernel source, recompiled the kernel, edit the init script in ramdisk, and flashed it to my phone.
Here's my result:
- the script in init.d doesn't seems to change the default governor. I don't know exactly why. Other script in init.d seems to run just fine, I can set scaling_min_freq and scaling_max_freq with it. I also check the permission, it's rwxr-x-r-x, but it doesn't seem to be executed at boot.
- in every startup, the rom executes the script in /data/local/userinit.sh too, but setting default governor from that script also doesn't succeed.
- only thing that can change the default governor is adding the line 'write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor smartassV2' in 'on boot' section of the init.semc.rc file.
I'm not a developer and i know every rom might be different. So you might need to ask in your rom specific thread, one of the devs might be able to help you there.
Otherwise, you can always set the default governor at boot using app like 'setcpu' or ' No-frills CPU Control'
dmrlook said:
Hey all - hopefuly this is the correct place for this question. I am developing a custom kernel for the Samsung Replenish baseod off of samsungs open source code. I have thus far gotten the kernel to compile and run just fine on the phone. I have also added the SmartassV2 and Interactive governors. No matter which one i set as default through the phonemodel_defconfig, each time I recompile and load the new kernel, it always default back to OnDemand governor.
I have no problem selecting either of the 2 new governors through SetCPU (and the setting does stick from boot to boot as long as I select "Set at Boot") so I know the governors are properly linked into the kernel. I thought that the kernel would start with the default one I selected, but it does not. Is this how thigs are supposed to operate, or am I missing something. I did update the cpufreq.h file in the include directory.
Any suggestions - is this even the correct place for a post that is this low level.
Thanks!
Click to expand...
Click to collapse
today i was looking for a solution like you and watched this post,finally i could solve the problem.Look at the scripts on /system/etc folder, in my case there was a script located there that changed the governor to ondemand,its name init.qcom.post_boot.sh maybe on your device it has other name.
old thread, i know, but im attempting to root a samsung replenish thats running 2.3.6. can anyone help? nothing is working.
EDIT: LOL. i was thinking "this phone is that old...? this is ridiculous that its running a higher form of gingerbread than my 4 month old phone is......" but i was looking at the join date not the post date, and i thought the thread was 3 years old. LOL