yashsingh1/xdaforums huggingface dataset:
[LG Optimus 2x] thewoZa:
Each phone is different due to the variations in manufacturing.

The only way to really optimise your phone is to try all of the various settings and combinations of voltage/speed.

Set the phone to a given speed, stress test and try decreasing the voltage until you get crashes / errors. Then raise the voltage one level (or 2 if you are a bit paranoid) and that is the stable voltage for that speed.

Rinse and repeat for all other speeds...

Then set profiles in setcpu / pimpmycpu accordingly.

Job done.

---------- Post added at 06:09 PM ---------- Previous post was at 06:08 PM ----------

I think you could lower your voltages quite a bit - eg Mine runs at 1.4GHz at 1.2V
[LG Optimus 2x] LarsPT:
Ok my friend... so... having designed a circuit for a mobile phone myself, I'll try to explain quickly what's the deal (tradeoff) between frequency and voltage.

A CPU/GPU basically is made out of MOSFET's (transistors). Lots of them! They act like capacitors. They have to be turned on and off. At a certain frequency. So, basically they are capacitors being filled and emptied at a certain frequency.

In practice, a capacitor being filled and emptied at a high enough frequency can be seen as a resistor. A variable resistor in fact, as you can see (more or less) here:

http://www.electronics-tutorials.ws/filter/filter_1.html

The thing is, the higher the frequency, the lower the equivalent resistance, because the amount of current keeps getting higher and higher. If the current value gets high enough the very tracks (you can think of them as wires) from the battery to the transistors start having a considerable drop in voltage (the resistance in these wires is supposed to be very low but it's not zero!). And if you have to much voltage drop on the wires the transistors don't get enough voltage to turn on/off.

So there you have it! That's the problem with overclocking. Voltage drop at the tracks (wires) because of increased current. You may also run into heat issues :)

Now, trying to answer your question, even at the same clock frequency a CPU that is processing stuff will use more energy than one that isn't "doing anything", because transistors aren't really changing state. But a CPU not doing anything at a lower clock frequency will waste less energy than another one not doing anything at a higher clock frequency, because energy is required to drive the clocking circuit itself. So it's very non-linear, you get the picture I hope :)
[LG Optimus 2x] silentmelodies:
This. This is the answer I was looking for. Thank you for the detailed explanation! :)
[LG Optimus 2x] LarsPT:
You're welcome!

Also, to complete the answer a bit more, lower voltage also helps with getting less energy consumption, because it takes more charge to "fill" a capacitor to, let's say, 1.3 V than to 1.1 V.
[Sony Ericsson XPERIA X10 Mini] sith.warrior:
Hi everybody. I have a silly problem using my X10 Mini (no brand, stock ROM, stock kernel, with root access) with data connection.

First of all, i have no data plan with my carrier (vodafone IT). When i turn on data traffic, something connects to the network immediately (i don't know what, maybe an app, but which one?)

I'm sure about this, because 3G Watchdog reports data traffic...and my phone credit goes down -_-°

I need only one app to connect to the network.

I already disabled background data and auto-sync. If necessary, i can post all my installed app and a list of running services

Forgive my bad english, but I hope you understand my problem. :o

Greetings from Italy
[Sony Ericsson XPERIA X10 Mini] ofert:
Try installing a firewall app.
[General Questions and Answers] Monzer_:
hi there im looking for locus pro latest version but i cant find it anywhere i need version 1.14 or higher plz if someone know where to find it link me thanks
[General Questions and Answers] killall:
Google is your friend!

http://www.bestapk.info/2011/12/locus-pro-v1146-1146-android-apk-app.html

link at bottom of page
[General Questions and Answers] Monzer_:
thanks a lot :)
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
Hi,

I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:

Tried two source trees:

1) Official from ASUS

2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)

Used .config from my current kernel which is running fine (Prime kernel) without any changes.

Compiled kernel.

So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.

I started with Prime Kernel from http://xdaforums.com/showthread.php?t=1251044

* Unziped the archive

* blobunpack blob

* created blob.LNX in several ways described bellow

* blobpack blob.HEADER blob LNX blob.LNX

* dd if=blob of=/dev/block/mmcblk0p4

* reboot

How I created blob.LNX

A) Use extracted blob.LNX and use abootimg to replace kernel

* abootimg -u blob.LNX -k zImage

B) Extracted all parts and recreated image using abootimg

* abootimg -x blob.LNX

* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img

C) Extracted all parts and recreated image using bootunpack and mkbootimg

* bootunpack blob.LNX

* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX

In addition I tried few modifications:

* enlarging bootsize in bootimg.cfg to make sure everything fits

* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both

All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.

If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
Here is what I've done. If you have successfully built a kernel with the resulting zImage, then you are part way there, I believe there is a kernel config option to enable kexec support but I haven't tried that. Next, you can take some other kernel's .zip file (CWM flashable) and unzip it. You may need to download a zip utility. You'll have 2 folders and a kernel blob. If you bootunpack this kernel blob, you'll end up with the kernel blob and a some *.LNX file. This *.LNX file is the same as a boot.img file. You can use dsixda's Android kitchen to split this into the initrd and the kernel (zImage) parts. Replace the zImage with your own and move any modules you may have also built if necessary into the initrd part, join them back together into a boot.img in the kitchen.

copy this boot.img back to where you unzipped the kernel.zip, delete the original *.LNX file, rename the boot.img to the same name as the previous *.LNX file and then bootpack it together and flash it through CWM. Zip the 2 folders and the kernel blob you just made back together with whatever name you want. You can edit the text in the updater script before you zip it all up, but whether you do or not it should boot.
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot :-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?

kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.

I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:

I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.

https://github.com/koush/AnyKernel

Good luck -
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
hmmm, checked that one, uses blobed image and 'dd if=/tmp/blob of=/dev/block/mmcblk0p4' as well. Maybe I'll try different crosscompiler anyway, that's the one thing I haven't altered yet :-/
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.

I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .

On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.

If they are working OK for you, could you tell me a couple things?

1) Your linux distro and architecture (x86/x86_64)

2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?

3) parameters? I don't think mine take any but the blob name.

4) Output suffixes. I only get .LNX from any of the above blobs which is useless.

EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
[Eee Pad Transformer Q&A, Help & Troubleshooting] lilstevie:
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
OK: Thanks lilstevie,

That takes care of that. Time for me to make peace with blobs.
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
After steve's reply, I just went to using blobs. I've got my own kernel running fine on the tf101 using that method.

For the best reference I've seen on using blobs and boottools , try this post:

http://xdaforums.com/showthread.php?t=1193737

---
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
Just got back from work, will ply with it some more, but I'll start with answering the questions...

Gentoo x86-64

Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.

These two comes together:

'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX

'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config

'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg

Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file

To repack:

'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'

or

'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'

and then

'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'

Unless I change kernel, everything works just fine :-D
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
Pretty similar, although the kernel zImage itself is always a mystery unless you've not changed anything, but even then, getting it built with the right toolchain, etc isn't guaranteed. So lets assume that just works for now since it'll become obvious as it goes along.

I guess I have not heard of 'abootimg' as a tool for this, so I've been using the more manual way of dissecting the initrd as follows:

gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i

If you need to change something , for example, in default.prop like ro.secure=0, then you'd do it there.

Then repack into a new ramdisk:

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

Finally I just had a somewhat heavily modified zImage from my build, so did this to make the blob (I'd copied zImage to blob.LNK-zImage.gz below):

./mkbootimg --kernel blob.LNX-zImage.gz --ramdisk newramdisk.cpio.gz -o boot.img

./blobpack blob.HEADER newblob LNX boot.img

zip -r imagename.zip blob MET* system // whatever the syntax was.

NOTE: I did this on a native 64 bit ubuntu LTS 10.04 box.

Unless I typo'd up there, that 'should' work. If it does boot, then first thing, take a look at settings, and kernel info so you can verify that you're running the kernel you desired (hopefully you renamed it in Makefile the first 4-5 lines).
[Eee Pad Transformer Q&A, Help & Troubleshooting] -miska-:
Solved

Ok, got it working!!! Problem was bad crosscompiler :-( Modules I crosscompiled worked fine, so I ruled crosscompiler out :-/ Looks like I was too quick in judgement :-( Now I have kernel recompiled with original settings and evne the modified one and it still works and boot. Now I'm going to play with new features I got! Thanks a lot for all help!!!

Just for the record, crosscompiler I was originally using was codesourcery 2011.03 and to make it work I switched to official crosscompiler from NDK. Rest of the commands was Ok, I was just suspecting wrong step as I was quite familiar with kernel building and quite unfamiliar with the blob stuff :-(
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
Congrats!

For some reason I avoid the codesourcery stuff and stick with either the prebuilt toolchains or else just build my own from gnu source.

Anyway, glad you figured it out.
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.

I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
The architecture really seems to make a big difference in some configurations.

I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.

Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.

If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.

Good luck
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
If by 'native' you mean a hard disk install as opposed to a VM install, then that's where I'm at. I have Ubuntu 11.10 x86_64 installed to a separate partition. I have the recommended stuff installed including the ia32 libs, but I never see a blob.HEADER file with either kernel.zips or ROM zips. I can unpack and repack kernels without the HEADER though and they boot just fine.

But, yes, if you don't mind posting a link with your files I'll give them a try sometime. Thanks.
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
Hi - I created a bzip2 tarball of the tools built on 10.04 and used on 11.10 that work fine. Now to find a place to put them..

They are here: http://gitarded.com/mickey/blob_boot_tools.tar.bz2 . There shouldn't be any permissions preventing you from getting them, but let me know if I somehow messed this up.

I hope they work for you.
[Eee Pad Transformer Q&A, Help & Troubleshooting] sidneyk:
Thanks for the tools

I wanted to say thanks for the effort of doing this. I downloaded it fine and will keep them around in case I need them. After I got home this morning I tried rebuilding the tools on my 64bit ArchLinux install and still no blob.HEADER. Then, I started poking around in my Ubuntu /home and realized that I had at some point downloaded the tools pre-compiled from somewhere, so I gave that a shot - and voilla! I can now see the blob.HEADER file. I appreciate your quick response though and willingness to help out. Now I'll see if having the blob.HEADER makes any appreciable difference in unpacking and repacking kernel pkgs. Thanks again. :)
[Eee Pad Transformer Q&A, Help & Troubleshooting] hachamacha:
Sure thing. Glad you got it working.
[Nexus S Q&A, Help & Troubleshooting] Casilan:
Having launch problem at the moment, any help?
[Nexus S Q&A, Help & Troubleshooting] Viber Team:
Hi,

This is a member of Viber's development team.

Can you please elaborate more on your issue?

What device you have?

Viber only partially supports MIUI but we might be able to help anyway.

Thanks,

Viber Team
[Nexus S Q&A, Help & Troubleshooting] mahanddeem:
When Viber will be supported in ICS ?
[Nexus S Q&A, Help & Troubleshooting] Casilan:
I'm currently running on an ICS MIUI.

I did launch the application and nothing is shown, but I believe the background service is still running as I could get viber contact list.
[Nexus S Q&A, Help & Troubleshooting] quiquegabriel:
it is viber supposed to work on ICS?? or not yet?
[Nexus S Q&A, Help & Troubleshooting] Viber Team:
Ahh... you're running MIUI on ICS.

We are aware of the problems with Viber on ICS, and working this very moment to fix it.

As you know, many fundamental changes were made on ICS (not only visual improvements). In order to adapt Viber to ICS the best way and make sure we don't release a half-baked app, we need some time for developing and testing.

We estimate that the release would take up to several weeks, but we wouldn't want to guarantee a specific release date at this stage.

Once we have any news we'll keep you posted - we apologize for the temporary inconvenience.
[Nexus S Q&A, Help & Troubleshooting] mahanddeem:
this makes me feel like reading a newspaper lol
[Nexus S Q&A, Help & Troubleshooting] Viber Team:
How so? ;)
[Nexus S Q&A, Help & Troubleshooting] mahanddeem:
We are aware

we don't release a half-baked app

some time for developing

We estimate

up to several weeks

wouldn't want to guarantee a specific release

we apologize

Are you a politician ?:D
[Nexus S Q&A, Help & Troubleshooting] Viber Team:
We're a company.

As much as we would have loved to develop everything as soon as possible and throw promises in the air, we also have to be realistic and a little restricted with guaranteeing things to our users, because we don't want them to be disappointed, nor do we want to not live up to our promises and estimates :)

It has nothing to do with being a politician... just credibility of a business ;)