[Kernel][OC][UV][3G][USB charging] GT8.9 7300/7310 (Dec 4, 2011)

Search This thread

mynewuser

Senior Member
Mar 7, 2011
205
15
Hello, if you are only talking about USB charging and not charging in general, then this is normal since you haven't enabled USB charging. If you want to enable USB charging, use the link in the first post and it will show you how to run a script at boot time that will allow the device to properly support USB charging. The FAQ in the second post also answers some questions others have had about USB charging. Hope this helps.

hi, thank for reply. actual I have two question. no 1 will be charging using standard charge not able to cope with the power drain. that why the battery not charge when i charging during browsing.

2nd will be can you inform me the link to enable USB charging script. I already read many time but cannot found the script.
 
Last edited:

jenne1980

Senior Member
Apr 10, 2011
113
9
Look at the first point under version v2b and you'll find the link ;)

I already tried it and it works.
 

mynewuser

Senior Member
Mar 7, 2011
205
15
Hi. Thank for the tips. Now my problem solve. My charging also working during using. Don't know this anything to do with the USB script?

Sent from my GT-P7310 using Tapatalk
 

_motley

Senior Member
Aug 17, 2010
858
2,360
Hi. Thank for the tips. Now my problem solve. My charging also working during using. Don't know this anything to do with the USB script?

Sent from my GT-P7310 using Tapatalk

Glad to hear it is working for you. I just checked and I am working fine charging from the AC Adapter when I don't run the USB charging script at boot. It works OK either way for me. When you are browsing, you are using 3 of the most power hungry options in the tablet (screen, wifi, and browser that taxes the CPU), so it won't charge as quick as when it is laying there at the lowest frequency with the screen off. If you also OC, then it will charge even slower during usage. You could setup a profile in SetCPU so that during charging you would only allow 1.0 or 1.2 GHz and that would help out a bit.
 

mynewuser

Senior Member
Mar 7, 2011
205
15
Just perform some experiment. Using battery monitor widget.

I connect the tab to computer USB port.
If not enable the USB script => Tab drawn 366mA
If enable the USB script => Tab drawn 1000mA

The standard charger will drawn 1700mA. Edit..
 
Last edited:
  • Like
Reactions: _motley

_motley

Senior Member
Aug 17, 2010
858
2,360
Just perform some experiment. Using battery monitor widget.

I connect the tab to computer USB port.
If not enable the USB script => Tab drawn 366mA
If enable the USB script => Tab drawn 1000mA

The standard charger will drawn 1366mA.

Great experiment, thanks for sharing. This shows why the tab charges faster than stock when the custom kernel feature is turned on.
 

nirogu325

Senior Member
Oct 15, 2010
3,795
1,973
Hi, i notice the market still at version 1. Any way to upgrade to latest market. 3.4.4?
You'd have to download it somewhere and install it by putting it in the "/system/app folder" with the name "Vending". Use Root Explorer or similar app for that. If the result after reboot is two Markets (the old one and the new one), simply delete or freeze the old Market using Titanium Backup.
 
  • Like
Reactions: mynewuser

_motley

Senior Member
Aug 17, 2010
858
2,360
Please have a look at the results of my standby battery consumption test: http://xdaforums.com/showpost.php?p=20463009&postcount=525

I identified your kernel to be responsible for the high battery consumption problem (only when WLAN is activated). With stock kernel everything is fine.

I have a few questions before I can start to look into this. I need more information and need to understand how consistent your tests were run. Please be honest with your answers. If you are not sure, please say that you are not sure. I can dig for some of this info in different threads, but it is best to have your confirm it all here.

Do you have a 3G model?

What version of the kernel was used (assuming version 2d).

Were you overclocked? Did you use undervolting? Was it the same for every test case?

Did you have WLAN set in Android to shutoff when the screen goes off in every test case, or was it setup to leave it on? I believe there are 3 settings to choose from. Please confirm what setting you used and whether it was the same for every case.

Did the Android battery usage stats (under Settings|Applications) also suggest that WiFi was using more resources during this time for the suspect test cases, thus suggesting that WiFi is the problem? It would be nice to see screen prints of these stats along with the graphs Android provides.

Were you flashing fresh for every case and running the tests without installing any extra apps? Or perhaps you are restoring some of the test case environments from CWM backups where you may have had different apps installed after a previous configuration? What I am getting at is whether the same stock options exact same apps running (or not running) for every test case?

Did you activate the USB charging script on boot for every test, or was it not activated? Since this is a power related mod, it would be interesting to see if it plays any role.


After we get some additional info, we can also check with others to see what they are seeing as well and I can run some tests with my WiFi-only version.

I am getting about what is expected from stock on my Wifi only model, while taking OC into consideration and I never turn Wifi off, even with the screen. I also have an Iconia and the GT8.9 does much better on battery as you suspect. Both are OC'ed at 1.5GHz.
 

jenne1980

Senior Member
Apr 10, 2011
113
9
I have a few questions before I can start to look into this. I need more information and need to understand how consistent your tests were run. Please be honest with your answers. If you are not sure, please say that you are not sure. I can dig for some of this info in different threads, but it is best to have your confirm it all here.
Yes, no problem. I'll answer your questions as I can.
Do you have a 3G model?

Yes, it's the 7300 with 3G.
What version of the kernel was used (assuming version 2d).
Jep, I downloaded your file motley_v2d_3G.zip.
Were you overclocked? Did you use undervolting? Was it the same for every test case?
Yes, I installed SetCPU because I had terrible speed lags without setting the governour to "interactive". With the interactive setting the speed problem was solved. Then I changed the max CPU speed to 1200 MHz. But I think that doesn't effect the test because I only tested in standby where the CPU clocks down to min. I always used this setting when your kernel was installed.
Did you have WLAN set in Android to shutoff when the screen goes off in every test case, or was it setup to leave it on? I believe there are 3 settings to choose from. Please confirm what setting you used and whether it was the same for every case.
Of course I always selected the option "never" for every test to be sure that WLAN is always activated (except the 2nd test with your kernel where I disabled WLAN completely).
Did the Android battery usage stats (under Settings|Applications) also suggest that WiFi was using more resources during this time for the suspect test cases, thus suggesting that WiFi is the problem? It would be nice to see screen prints of these stats along with the graphs Android provides.
When I noticed the battery consumption problem the first time, I posted my values in the forum, these were my values in the battery usage menu: 53% Android OS, 20% WLAN, 14% Display, rest wasn't mentionable. But I don't have any screenshots or exact values for all the tests because I didn't look to that menu again. For me it was clear that the activated WLAN is causing the problem because without WLAN the battery consumption was ok (2nd test).
Were you flashing fresh for every case and running the tests without installing any extra apps? Or perhaps you are restoring some of the test case environments from CWM backups where you may have had different apps installed after a previous configuration? What I am getting at is whether the same stock options exact same apps running (or not running) for every test case?
Yes, I always made a fresh installation with CWM Recovery. The installed apps were always the same besides SetCPU which I had only installed when I used your kernel. Rest of the apps was 100% identically. Before the first test (Overcome rom + your Kernel) I made a installation with data wipe. Also for the stock 3.1 test. For the last 2 tests (Android 3.2 stock) I didn't make a data wipe. All the settings and apps from the previous Android 3.1 test were there and everything was working fine. Also the battery consumption. Then I installed your kernel in CWM Recovery for the last test, and again I had nearly 2% per hour consumption, as in the first test.
Did you activate the USB charging script on boot for every test, or was it not activated? Since this is a power related mod, it would be interesting to see if it plays any role.
Yes, I run the USB charging script for both tests with your kernel. I activated it, because the USB charging is (besides overclocking) the main reason for me to use this kernel and I wanted to make the tablet run with this setting. Of course it could also play a role for that problem.
After we get some additional info, we can also check with others to see what they are seeing as well and I can run some tests with my WiFi-only version.

I am getting about what is expected from stock on my Wifi only model, while taking OC into consideration and I never turn Wifi off, even with the screen. I also have an Iconia and the GT8.9 does much better on battery as you suspect. Both are OC'ed at 1.5GHz.
Hope my answers help. Let me know if I can test anything else and I can do it.
 
Last edited:
  • Like
Reactions: _motley

mynewuser

Senior Member
Mar 7, 2011
205
15
For me, I using

- Stock ROM
- motley kernel Latest Version.
- No OC
- UV
- 7310 Model (WIFI Only)
- WIFI on.
- During testing, I install a lot of app.
- Activate USB charging.

On for 7 hour. Battery % almost no drop.
 
  • Like
Reactions: _motley

ki1120

Senior Member
Jul 7, 2008
94
3
Is there a problem you are looking for a fix for? Now would be a good time to report anything as the next version is underway and will include some Nvidia patches, an optional SIO i/o scheduler, and will be compiled against a newer compiler along with some optimization.

Thanks. But as far as I have mentioned, the data loss problem still exists, and have so far been happening for at least 4-5 times, usually a few day interval each time of occurance. Each time I restored my /data from my clockwordmod backup, I tried changing every settings in setcpu, including lowering the frequencies and voltages, but it does no help. Every after I flashed Overcome ROM and then your kernel does the problem exist.
 

jenne1980

Senior Member
Apr 10, 2011
113
9
For me, I using

- Stock ROM
- motley kernel Latest Version.
- No OC
- UV
- 7310 Model (WIFI Only)
- WIFI on.
- During testing, I install a lot of app.
- Activate USB charging.

On for 7 hour. Battery % almost no drop.
So with stock rom you mean Android 3.2, I guess? Same kernel version (v2d)? Maybe it's only a problem of the 3G version when you have no problems with the Wifi-only version.

I've installed my CWM backup of the stock 3.2 rom and everything is fine again. After 7,5 hours the battery dropped from 100% to 98% -> normal.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 29
    DEVELOPMENT DISCONTINUED

    Disclaimer:
    You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!


    _motley kernel:
    Current version features:
    • OC support (overclock) - frequencies: 1.200, 1.400, 1.504, or 1.600Ghz (recommend 1.4 or 1.5GHz). Default clock speed is stock@1.0GHz
    • UV support (under-volting)
    • I/O schedulers: optimized deadline (default) and noop
    • Governors: optimized interactive, on demand, conservative, and performance
    • vfp, vfp3, vfpv3d16, thumb, thumbee, swp, fastmult, edsp, half
    • USB charging enabled
    • JRCU implemented - RCU for SMP with a single CPU garbage collector
    • Auto-group scheduling
    • Built in cifs, NTFS, Xbox controller, tun, PS3, joystick, mouse support
    • Encryption features CONFIG_DM_CRYPT, CONFIG_BLK_DEV_CRYPTOLOOP, and CONFIG_KEYS
    • Stock hardware/software is all working with no known issues (Camera, GPS, WiFi, sound, headphones, sensors, market, video/youtube etc.)

    Prerequisites:
    • ROM must be based on the stock Galaxy Tab 8.9 with TouchWiz (stock and Overcome ROMs have been tested)
    • ROM must be rooted and have CWM installed.
    • Make sure you backup your boot.img so you can flash your stock kernel back. You should have a full CWM backup anyhow.
    • An app like SetCPU if you want to overclock(OC) or under volt (UV). I recommend only overclocking up to 1.4 or 1.5 GHz. Try 1.4 GHz first and see if it works for your tab.
    • Make sure you download the correct version for WiFi or 3G (3G only supported on Android 3.2).
    • Make sure you download the correct version for Android 3.1 or 3.2.

    Android Honeycomb 3.2

    Version v2d for Android HC 3.2
    • Add "autogroup" scheduling (for some background see: http://www.linuxfordevices.com)
    • Add support for LUKS and other file encryption utilities (CONFIG_BLK_DEV_CRYPTOLOOP=y and CONFIG_KEYS=y). Ext2 formatted loop devices should work now, but still no luck FAT12 8.3 volumes. Let me know how it works! (thanks ZeroPDA)
    • Misc merges\bug fixes from Nvidia repo (tegra\video\hdmi fixes, ext4 memory leak fix, interactive gov div\0 fix etc.)
    v2d (7310 WiFi) View attachment motley_v2d.zip MD5 640af1d30eff11124f17b7fcb4c6201e
    v2d (7300 3G) View attachment motley_v2d_3G.zip MD5 640af1d30eff11124f17b7fcb4c6201e

    Version v2c for Android HC 3.2
    • WiFi only feature addition - added CONFIG_IP_ADVANCED_ROUTER=y to properly support Cisco VPN (VPNC Widget). This was not required for 3G as it already has this kernel feature. Thanks to questionmark for providing the info and testing the change for us.
    • UV bug fix - v2a introduced a UV issue where it was no longer subtracting the UV values even though they were set properly in sysfs by SetCPU etc. Thanks to Crashdown12 for reporting.
    • Important - I recommend removing the option to set UV on boot before installing this new version, just in case you were down to unstable voltages.
    v2c (7310 WiFi) View attachment motley_v2c.zip MD5 cbfdee00b5ce514bef88e4230f7d0694
    v2c (7300 3G) View attachment motley_v2c_3G.zip MD5 bce4881b2716f410b2903f96fe347271

    Version v2b for Android HC 3.2
    • USB charging is now enabled like the GT10.1 (thanks pershoot, stefansaraev). See the following for usage: how-to (thanks dpakrr)
    • Performance: implemented JRCU, an RCU for SMP with a single CPU garbage collector so that each and every CPU doesn't periodically participate in RCU garbage collection. This is popular in the Android kernel space since dual CPUs have come about (thanks Joe Korty).
    • Performance: added optimized deadline i/o scheduler which is now the default since it is great for SSD (thanks morfic)
    • Added switch to turn off TouchWiz at the kernel level (not really relevant until someone tries to build a vanilla ROM)(thanks pershoot)
    v2b (7310 WiFi) View attachment motley_v2b.zip MD5 3446574b2024897e41bad69f7c699aca
    v2b (7300 3G) View attachment motley_v2b_3G.zip MD5 d299579a1de0d1469bfcb99ed6afc1d4

    Version v2a for Android HC 3.2
    • Same features as v1i kernel, but now works for HC 3.2
    • Now a version for P7300 3G
    v2a (7310 WiFi) View attachment motley_2a.zip MD5 59bfb8b8f213517676e06b6d69f35080
    v2a (7300 3G) View attachment motley_2a_3G.zip- MD5 b5b6ab4f3dffe29dce5a83f32dd7eba6


    Android Honeycomb 3.1

    Version 1.0i changes (current for Android 3.1):
    • Governor default changed to OnDemand, but only so we can properly set back to the preferred interactive governor on boot using SetCPU and other tools (let me know!).
    • I/O schedulers: NOOP now the default (minor read/write improvements), CFQ still available, Deadline removed for now.
    • Starting voltages increased for 1.504 GHz and above due to some instability issues reported. I recommend you UV 25mV or so if you already achieved stability as it was increased by 50mV. Higher than 1.5GHz is still experimental and not recommended. I have been able to run at 1.6GHz for the first time in this build.
    v1i - View attachment motley_v1i.zip - MD5 ea77e46967aa4c917e8dd8c429dca724 (current for Android 3.1)

    Version 1.0h changes (beta 1):
    • Touchscreen lag fixed. Firmware downgrades prevented within Melfas touchscreen driver.
    • UV bug fix, no known issues.
    • Governor fixes, SetCPU seems to set properly on boot now (edit: still some issues setting on boot depending on SetCPU configuration)

    Version 1.0g changes (alpha 2):
    • Overclock to 1.504GHz+ (only 1.5 is stable, over is experimental only)
    • UV (undervolt) support (experimental, still in testing)
    • NTFS and Xbox now built-in. No longer need to mess with loading modules.
    • Applied some upstream kernel patches.

    Version 1.0c (alpha 1/first release):
    • Based on Samsung open source kernel from opensource.samsung.com
    • Overclock to 1.2GHz or 1.4GHz (a future version will likely be able to clock to 1.504Ghz)

    Installation Instructions

    1. Backup with CWM
    2. Put the zip on your sdcard
    3. Flash zip file from CWM
    4. Install SetCPU and use to set governor to "interactive" and desired OC frequency (recommend 1.4 to start). The default governor has been set to On Demand on purpose even though it is not the recommended governor to use in SetCPU. Setting the recommended interactive governor will help SetCPU trigger the instructions to sysfs causing it to take hold. Sometimes it is finicky and a reboot can help once you have the interactive governor set with your desired frequency.
    5. Optional: if you need or want to restore your original kernel, restore ONLY your boot.img from the CWM advanced recovery option.


    Thanks go to:
    • pershoot for all his hard work on the 10.1 kernel. I used his kernel as a working guide and used his delivery method (Anykernel)
    • alterbridge86\Overcome for CWM.
    • Koush for the Anykernel delivery method.
    • Samsung for releasing the source like they should
    • Tiamat team, RichardTrip\roggin and NVidia for their open source git repositories.
    • All the testers!
    • Let me know if I forgot somebody!

    Git repository:
    https://github.com/motley-git
    6
    FAQ

    Q: What is a kernel and why would I need it? How is it different from a ROM?
    A: The kernel is the lower level of the operating system, or the engine so to speak. It is a bridge between applications and the actual data processing done at the hardware level. The Android OS utilizes a custom Linux kernel. The stock kernel provided by Samsung limits the CPU clock speed (i.e. CPU frequency) and other functionality that the upper level operating system can request (like mounting NTFS hard disks, undervolting, encrption, using certain joystick controllers, mounting network shares etc.).

    A kernel is different from a custom ROM. A ROM is a customized version of the Android Honeycomb OS and will also come with a kernel. Most ROMs will come with the stock kernel, they should designate which kernel they use. In other words, most ROMs provide a customized version of the upper level of the operating system including base services and applications.

    Q: What do I have to wipe before I flash?
    A: For kernel only flashes, like this one, you don't have to wipe anything.

    Q: What does the zip file do when I flash?
    A: When the zip is applied in CWM, it does the following things using Koush's AnyKernel method:

    1. Unpacks your boot.img from into a temp folder (into ramdisk and zImage components)
    2. Replaces your zImage, i.e. the kernel binary
    3. Updates the ramdisk default.prop (sets ro.secure=0 for adb root shell and removes init.p3.rc lines that set frequencies and governor during boot)
    4. Repacks the new boot image and flashes back to /dev/block/mmcblk0p3
    5. Updates two kernel modules in the stock location /lib/modules

    Q: Will I lose any customizations to my ramdisk provided by a custom ROM?
    A: No, your should not due to the use of the AnyKernel method described above.

    Q: Will other overclocking apps besides SetCPU work OK?
    A: Yes, they should work, but just keep in mind that not all apps are able to under-volt. I will typically be using SetCPU for all my testing, so keep this in mind if you have problems.

    Q: Will overclocking use more battery?
    A: Yes, higher voltages equals more current draw (I=VR). It will depend upon your setup and individual usage scenarios to how much runtime you will lose.
    Using the interactive governor, your tablet will scale down to lower frequencies when the highest clock speed is not necessary. At the lower frequencies, the tablet will not use more power than it does stock.

    Q: What OC frequencies are safe?
    A: From research thus far, 1.5GHz is the top end for every day use stablity for most tablets. However, due factory tolerances 1.5GHz still may not be stable for everyone. You may need to use 1.4GHz or even 1.2GHz. Many choose to run 1.4GHz since it still gives a great performance bump over stock, but less heat is generated, and it will chew up a little less battery.

    Q: I set my OC frequency to X, but I don't think it is working. How do I test to know that it is working?
    A: For 1.4-1.5GHz using the interactive governor, you should be able to see a Linpack score between 70-87 depending on what else is running on the tablet.

    The ad-free version of Linpack is better because the ads can lower your scores unless you hit test at the right time when the ad is already loaded. If you keep hitting test at 1.5Ghz, your consistent higher scores should be around 78-85.
    Verify the clock speed by using Linpack scores
    Verify in SetCPU that the different clock speeds are being used periodically, most particularly the highest clock speed.

    It is kind of finicky sometimes until you get it set right and sometimes after a new version is installed it will get finicky. After you get it set right, then it stays put on reboot and you should have any issues from there. I am still wondering if there isn't something I can do about it to force it honor any changes SetCPU requests to sysfs no matter what. This is the reason why I eventually set the default governor to On Demand and then suggest that you configure it to be Interactive in SetCPU (the recommended governor). This seemed to help trigger the proper acceptance from SetCPU on boot. Pershoot (the 10.1 kernel guru) suggested that it might be falling to conservative at the default frequency like when it goes to sleep, but not coming back. However,when it goes to sleep and I turn it back on, it always goes back to my 1.5GHz just fine. And when it's set and happy, it never has this issue on boot either. Maybe a second boot is all that it takes, but I would sure like to pin it down and understand it better. Let me know if anyone has any ideas.

    If your Linpack scores suggest OC is not working, I recommend that you do the following:

    1. Uncheck the SetCPU setting to "set on boot" for OC and UV settings. Don't set this for boot until you are sure you are good to go with your clock speed and UV settings.
    2. Upgrade to the latest kernel version for your tablet if you haven't already (Choose, HC 3.1 or HC 3.2, then 7300 3G or 7310 WiFi)
    3. Boot up and use SetCPU to set your desired OC frequency AND then setp to use the "interactive" governor.
    4. Verify your linpack scores to make sure they are higher than stock (~50-55). See above reference scores and notes about ads slowing down the scores.

    Q: How do I setup under-volting (UV)? What values should I use for each frequency?
    A: Not all tablets are created equal at the factory. What works on anothers tablet may not work on yours.

    1. Uncheck the SetCPU setting to "set on boot" for UV settings. Don't set this for boot until you are sure you are good to go with your modified UV settings.
    2. Once the clock speed is verified (see previous question), run some bench marks (Linpack, AnTuTu, and Quadrant are good) and do some multiple-tab browsing sessions to make sure your tablet is stable. Watch some vids or whatever you like to do, this is the key.
    3. If you are stable, step down your voltage at the highest clock speed by -25mV. Repeat the benchmarks and usage scenarios. If it fails (locks the tab), hold down the power key until it reboots and step back up +10mV and repeat until it is stable.
    4. Repeat the UV calibration for the next lower clock speed and so forth. I don't typically mess with anything below GHz since those are stock values.

    Q: So, what OC and UV settings do you use?
    A: I typically run @1.5GHz -50mV and leave the rest of the frequencies as-is. For my usage, I don't find the CPU spending a lot of time anywhere else besides 216, 312, 1000, and 1504. Every other frequency is typically less than 1% of time in state. If folks can UV further and keep it stable, that is great. I don't worry about battery too much since I am mostly around the house and don't mind charging every 2-3 days.

    Q: I noticed that the stock tablet does charge using a normal PC USB port. The tab say discharging with a red x but it seems to be charging. So do I really need to use the usb charging script?
    A: I grabbed this fix from the 10.1 kernel base. I was wondering the same thing when I went forward with the code change.

    Here is what I know so far. The change in the kernel allows the tablet to properly report the charging state properly back to the OS. After the fix, the USB charging seems to be much faster, but it may just be the reporting mechanism. Before, it would take forever to trickle up 1%. Now it really seems be a viable charging source, but still slower than plugging in to the wall of course. I have not however done any tests to prove this, but I think the mod is definitely worthwhile. Samsung should have done it like this stock, but I think they did not want to deal with support calls to troubleshoot charging via USB as it is not as fast and reliable.

    That said, the option is there and folks have a choice on whether to activate it or not. Others, please report back on your experience on this topic.
    3
    Good news! I have a fix for the lock screen! Doing some testing now. It was the touchscreen driver like I thought. The Melfas driver automatically was downgrading the firmware on every boot with built-in firmware compiled into the kernel (not a .bin file on disk). I have now eliminated the firmware downgrade by toggling some available switches they had available and just allow the firmware to be whatever it is already on your tablet. The firmware seems to only stay resident until you reboot and then it reverts back to the firmware that was already on the tablet. This may explain the wacky differences between tablets if they were on different firmwares.

    Edit: new release see OP

    Version 1.0h changes (beta 1):
    -Touchscreen lag appears to be fixed! Let me know how it works for you.
    -UV bug fix (experimental, still in testing)
    -Governor fixes, SetCPU seems to set properly on boot now.
    2
    Great! Can't wait to try it. Any reason it might not work with the overcome ROM?

    EDIT: Just tried and it worked with Overcome 1.0.0. Noticeable improvement in landscape mode, buttery smooth in portrait.

    Thanks for the update, you may be the second person to run this kernel:)

    Any chance we can undervolt the kernel?

    Also, did you apply any optimizations (VFP3/FP/gcc-O etc.)

    Yes, voltage control is definitely high on the list after all hardware and annoying glitches are addressed.

    vfp and vfp3 are baked in already. I believe they were in the stock kernel already. As far as compiler optimization, I haven't done much playing with that. I tried to use the code sourcery toolchains, but I could never get the damn kernel to boot. I am currently using the Android NDK to compile. I even had to back off a version on these toolchains because it broke WiFi without any other coding changes. It's a very sensitive beast. If anyone has any known and proven compiler optimization for Tegra2 and ARM toolchains, I am happy to give it a try. I know that the toolchains are what do most of the magic for our CPU, so we would have to stick to whatever is supported in the toolchains.

    What is meant by "PS3" support?
    This is for supported the PlayStation 3 controller via USB (kernel option CONFIG_HID_SONY). Kernel option CONFIG_INPUT_JOYDEV is also built-in for supporting other generic joystick devices. I am not an avid gamer, so you guys will need to help out with the testing with this stuff.
    2
    Thanks everyone for the feedback and support. I have been working on the next version, but am trying to fix a couple issues and do some testing before release. I have added OC to higher speeds and UV control. Right now, at least for me, only up to 1.504GHz is stable. I just put it through some tests and scored a Quadrant 3107, Linpack ~80, and AnTuTu of 6780. On my Iconia tablet, 1.5GHz is bliss, so I am hoping for the same performance here. Honestly, I don't see a need to push it beyond this, but the features will be there if someone feels the need.

    For those asking about 3G support. I am sorry, but this is not my priority right now. This may change in the future, but no promises. This is a hobby for me when I am not working or with my family, so I don't have unlimited time to spend. For those willing and able, feel free to pull down the source from Samsung and use my git as a guide.

    I'll keep you posted :)