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.
Related
What this kernel does is provide slightly less voltage to the processor. This should not be dangerous for anyone to try, however it may be unstable or just result in general weirdness on a few phones. If it does, all you have to do is revert back to the kernel you had before.
The upsides to less voltage are less heat as well as less power consumption. That means battery life
Remember, this one is running at stock speeds.
Get it on Koush's RomManager (download RomManager from the market) I'll post changelogs in this thread from now on, but keep the kernel on RomManager.
Changelog 8/29:
Lots of stuff.. I dunno.. Look at the CM6 kernel changelog (I've been working on that).
Biggest thing IMO is the usleep stuff which lowers CPU usage and therefore increases battery life.
Note: only tested on CM6. Let me know if you try it on any other roms.
Link: http://kanged.net/up/files/5/kernels/signed-August26-UV950.zip
Changelog 6/20:
Ermm.. I've been releasing my kernels on twitter.. but I'm finally happy with this one.
-Latest Cyan commits
-Minor voltage tweaking
-erm... yeah I dunno.
Get it here http://kanged.net/kmobs/signed-619UV-34.zip or from RomManager.
Changelog 5/14:
-Reinstated those commits reverted earlier.
-Updated to .33.4
-Only doing a 925mV kernel due to the results from the blind study
Changelog 5/1:
-Reverted the following commits thanks to intersectRaven. I think they were the reason for the excessive battery drain.
27dd25f80402a13f9d5c381eda07b560e5545fcc
1490683fb851b992722cbd175d3df087df833656
f2513498e961966d3209aacfffc43de4f41f2ece
-Updated to latest CM source (minus those commits)
Changelog 4/21:
Fixed the board-mahimahi.c in the 850mV kernel.
OLD updates and changelog:
http://iq0.org/story/yet-another-nexus-one-kernel-now-battery-saving
Note: Now offering a universal update.zip method for flashing the kernel (big thanks to Koush for this one)
Thank you www.tdrevolution.com for hosting my work.
Does it still have the highmem?
GEtting an access denied message, Seems the post doesnt exist
Great job. Will get you a logcat if I get any random weirdness.
Maybe now my battery can last longer then my G1 battery did when I am at work.
Anyone care to make an update.zip for those of us without computers nearby to check this out?
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Running this new kernel at 576/245 mHz, wifi off, 3G connection, brightness set to automatic. will report back with battery life as soon as it runs out. lol
Off of charger: 11:34AM , Wednesday, February 17, 2010
Battery completely drained: TBA
DocRambone said:
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Click to expand...
Click to collapse
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
mgear356 said:
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
Click to expand...
Click to collapse
I will, phone seem ok so far, BenchmarkPi at 2670
No slowdowns or reboots during benchmarks or gameplay. Phone feel cooler tho
I'll give this a shot.
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
just flashed it. yes it does. my phone hasnt exploded yet either...
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
What voltages is it for different MHz?
great job, really need something like this... im trying it out! thanks
DocRambone said:
What voltages is it for different MHz?
Click to expand...
Click to collapse
Its not across the board, and I'm not home right now to tell you, but 245 is at 1.0 vs 1.05 and 998 is at 1.250 instead of 1.275
persiansown said:
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
Click to expand...
Click to collapse
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
FettsVett said:
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
Click to expand...
Click to collapse
Oh I understand where you're coming from, and I would make you a private one, but I'm not home at the moment. However, for the general user, if they can't use fastboot, I don't want them anywhere near this. I hope someone makes you an update.zip!
I await the PM's!
Dear lord what am I going to do with this should I get my 2800mah battery? my phone will never die! lol
-Charlie
FettsVett said:
I await the PM's!
Click to expand...
Click to collapse
you can make one yourself.
grab boot.img from cyanogen's rom.
grab split_bootimg.pl from http://android-dls.com/files/linux/split_bootimg.zip
grab persiansown's zImage.
(in linux)
put all three in a folder. let's call it kernel.
while in the kernel folder:
./split_bootimg.pl boot.img
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage-persiansown --ramdisk boot.img-ramdisk.gz -o boot-persiansown.img
(in windows)
download this: http://www.sendspace.com/file/kj2wi7
use winrar to open up that up, remove the boot.img in there and replace it with boot-persiansown.img (make sure it is named boot.img)
open up the update-script in META-INF folder (some levels down in there), and remove the format BOOT line (you'll be left with write_raw_image ... line), and save it.
grab this: http://www.relentlessaddictions.com/Androidstuff/signing.zip
unpack to your tools folder in your android-sdk folder distribution, and run autosign.bat. follow the prompts. once setup, you can right click on the .zip file with the boot.img in it to sign it, or you can execute from a cmd prompt: java testsign BOOT-IMG.zip
flash via custom recovery (which can flash .zip's signed with test keys).
you should be all set.
edit: mkbootimg can be found in prebuilt within AOSP distribution, or you can grab this precompiled one: http://forum.xda-developers.com/attachment.php?attachmentid=229872&d=1253485580
Lemme note here, I deserve no credit, all code and all work was done by Eugene_373 and anyone mentioned below, this is simply a share from the T-MOBILE GALAXY s2 section of XDA, I have fully tested this app and found it to be working wonderfully on my SGH-I777
I love eugene's deving hence the share I hope you all enjoy if this has some way helped you in anyway go over to eugene's profile donate/thank him
App Version:
CPU Sleeper
~Free to all XDA Memebers
~ Must Be Rooted to use App
What is it?
Its a fairly simple App that will put CPU 1/2/3 OFFLINE when the screen turns off. Once the screen comes back on, it will allow CPU 1/2/3 back ONLINE.
How does it work?
Since we have Dual & Quad core CPUs, we have a CPU 0 and a CPU 1/2/3, core 0/1/2/3, while the screen is off we really only need to have 1 core active "CPU0", this App will make sure CPU 1/2/3 shuts off while the screen is off, then resumes normal usage when the screen comes back on.
Compatibility?
Works with any Dual Core & Quad Core Devices!
~ICS
~Gingerbread
Battery Saving?
Battery savings all depends on Usage & idle times.
App Download: CPUSleep.apk
Version 1.5 Release Notes:
~ Battery Drain issues 100% Fixed
~ Screen on Lag 100% Fixed
~ SU issues 100% fixed
~ Auto-Start on reboot 100% Fixed
~ Fixed Auto-Start killing Cell Service
~ Su Request on Screen Wake Fixed
~ Debugging enabled for those wanting to check if it's working.
Credits:
Handlerexploit for co-creation of this wonderful App.
Script Version!
Code:
This time I present to you a script that will in theory (and so far for me, in reality) save us some battery without having to risk our hardware with undervolting! I present to you...
[B]CPU Sleeper[/B]
[U]What is it?[/U]
Its a fairly simple script that will put CPU 1 OFFLINE when the screen turns off. Once the screen comes back on, it will allow CPU 1 back ONLINE.
[U]How does it work?[/U]
Since we have dual core CPUs, we have a CPU 0 and a CPU 1, core 1 and core 2, while the screen is off we really only need to have 1 core active, this script will make sure CPU 1 shuts off while the screen is off, then resumes normal usage when the screen comes back on.
[B][COLOR="red"]WARNING! READ THIS![/COLOR][/B]
This script relies on init.d OR script manager! CM9, for some reason, tends to run this at the exact same time it runs some other script (I forget atm which) and it will clash, causing no boot! CM9 users MUST use the script manager version install! Flex Reaper appears to work fine with it as init.d. I strongly urge you to use the script manager version of this, NOT the flashable version. Always make a nandroid backup before modifying the system, including this!
[U][COLOR="Red"]Instructions[/COLOR][/U]
Available in 2 versions, script only version which you can place wherever you want and run however you want, or a CWM/TWRP flashable zip that will place the file for you in /system/etc/init.d and set permissions.
[I]Version 1: Flashable[/I]
Same as any of my flashable releases, I did most of the work for you!
Make a full backup
Download to external SD card
Install from SD card
Pick the cpu sleeper zip file
it'll be almost instant
reboot
Shouldn't be any need to clear caches or anything like that.
[I]Version 2: Script only[/I]
This can be run in 2 ways, via init.d support, or via script manager. Both are pretty similar, and can be done a number of ways, however this is the basis of how.
[U]Init.d supported kernel:[/U]
Make a backup!
Download the script file, making sure no extensions get added onto the file. Copy the file to /system/etc/init.d and set the permissions to the following:
XOX
XOX
XOX
Once done, reboot the system, and it will take effect when your system is finished rebooting.
[U]Script Manager[/U]
This method is probably the better method, and should work with any kernel/ROM. Download the script file, making sure no file extensions get added, and copy it to /system/etc. Set the file permissions to:
XOX
XOX
XOX
Once done, load up script manager, select browse as root (if it isn't already set from the crossix mod method in the guide) then browse to /system/etc and select the script file S98cpu_sleep, then select ROOT and BOOT options. After this is set, reboot system.
[U]What do I do if I can't boot after using this?[/U]
You made that backup, right? Ok, then here is what you do.
Hold the power button until the tablet powers off
Press and hold the volume down button, next to the screen lock switch
Press and hold Power (while holding volume down)
Once the recover kernel message comes up, release the buttons
In CWM go to advanced, mounts, mount system, then format system
In TWRP, go to wipe, then wipe system
In CWM go to restore, advanced restore, restore ONLY system
In TWRP select restore, then uncheck all so ONLY system is checked
After restoring system, wipe cache and dalvik cache, then reboot system.
System should boot normally.
[B]Downloads[/B]
Available in 2 versions, script only version which you can place wherever you want and run however you want, or a CWM/TWRP flashable zip that will place the file for you in /system/etc/init.d and set permissions.
Dual Core:
Download: [COLOR="Red"]Script Only - Recommend Install via Script Manager App[/COLOR]
[URL="http://d-h.st/N1N"]CPU Sleeper script only[/URL]
Quad Core:
Download: [COLOR="Red"]Script Only - Recommend Install via Script Manager App[/COLOR]
[url=http://www66.zippyshare.com/v/9249467/file.html]cpusleep[/url]
[COLOR="Red"]Download: ClockworkMod Recovery .zip for T989 / I727[/COLOR]
[url=http://www19.zippyshare.com/v/51836824/file.html]CPU_Sleeper.zip[/url]
Thanks to [COLOR="DarkGreen"]pio_masaki[/COLOR] for rewriting the OP
Used this for a day now. Seems to work. Will test some more. Using the app by the way.
Ported VK w/ bad ass Jkay.
Siyah synthetics and K-tuned for maximum performance.
hotplug, sched_mc
I'm running aokp + fluxxi also..is this app any different from hotplug settings or SCHED_MC level settings in xxTweaker?
Krysten17 said:
I'm running aokp + fluxxi also..is this app any different from hotplug settings or SCHED_MC level settings in xxTweaker?
Click to expand...
Click to collapse
Hotplugging and sched_mc are kind of synonymous. The difference is that sched_mc allows you to force a particular pattern of behavior (1 = fill 1 core first, 2 = activate both). This app attempts to force 1 core offline when the screen is off. It's kind of like an extreme version of sched_mc = 1 in that it doesn't allow both cores to be activated. However, I'm not sure if it is capable of preventing the second core from coming online. It may check periodically and subsequently turn it off. I don't think it would have much benefit on our devices; our hotplugging is competent and sufficient. I suppose anything is worth trying though.
looks interesting!
Every now and then i get cpusleep has been granted superuser permissions when the screen is on and im surfing the net or playing a game.
Ported VK w/ bad ass Jkay.
Siyah synthetics and K-tuned for maximum performance.
stevehkim said:
Every now and then i get cpusleep has been granted superuser permissions when the screen is on and im surfing the net or playing a game.
Ported VK w/ bad ass Jkay.
Siyah synthetics and K-tuned for maximum performance.
Click to expand...
Click to collapse
Oh I forgot to update the APK link its been updated download and install the latest version
Sent from my SGH-I777 using Tapatalk 2
Here's the original thread created by the app dev if anyone was wondering:
http://forum.xda-developers.com/showthread.php?t=1745132
Tried it for almost 3 days. Didnt help. No noticeable gains so I uninstalled
just uninstalled it too after seeing no real gain for two days.
Sent from my SGH-I777 using xda app-developers app
Thanks for all who posted. I'm running xxtweaker fluxii aokp . Any advice other than what's listed here for hot plug settings. Thanks
Sent from my SGH-I777 using xda premium
Does it work fine with setcpu ?
GEEWIZ MEDIA 3.4 SCH-I500 JZO54K JELLY BEAN 4.1.2 ROM/KERNEL
RETIRED -- GEEWIZ MEDIA 3.4 WAS THE FINAL RELEASE OF GEEWIZ MEDIA BASED ON ANDROID 4.1
OTHER AVAILABLE GEEWIZ MEDIA VERSIONS:
GeeWiz Media 4 - AOSP Jelly Bean 4.2: http://forum.xda-developers.com/showthread.php?t=2088139
GeeWiz Media 3.4 is a Wifi-only ROM for the Samsung Fascinate, based on AOSP Jelly Bean 4.1. The goal of GeeWiz Media is to allow the Samsung Fascinate device to continue to be used as a media player-like device after it has been disconnected from cellular service. There is no support for cellular voice/data communication present in this ROM. Like it's predecessor GeeWiz, GeeWiz Media doesn't aim to provide a lot of bells and whistles or incorporate all of the latest and greatest tweaks and enhancements developed by the community; the aim is to provide a basic, stable, functional device.
GeeWiz Media 3.4 uses a modified version of the GeeWiz 2.8 Gingerbread (Linux 2.6) kernel with a number of very specific tweaks/hacks in order to continue to support the proprietary Samsung RFS file system and other features I wanted to carry over. As a result, this ROM may not be used in conjunction with any other Kernel, and this Kernel cannot be used in conjunction with any other ROM. Please consider it a "matched set", and they will always be updated/distributed together.
Your device needs to be set up as stock or stock-like (e.g. GeeWiz 2.8) before installing this ROM/Kernel. If you are currently running with an MTD-based platform, the device must be reverted back to the original OEM volume format. Please refer to the forum/thread were you acquired your current ROM for guidance on how to revert the device as necessary.
Installing this ROM/Kernel or any other provided component(s) will void your device's warranty, and I cannot be held responsible for any damages of any kind (including data loss) that are incurred either directly or indirectly by these packages and components. What you do to your device is ultimately your problem!
FEATURES
Android Jelly Bean AOSP build JZO54K (android-4.1.2_r1)
Wifi-Only, no support for Voice/Mobile Data
Google Apps version JZO54K from the Galaxy Nexus
All devices (GPS, compass, orientation, camera, flash) are functional
Supports OEM DBDATA volume to keep performance reasonable
Supports both RFS and EXT4 formatting on all volumes
OEM USB modes (CD-ROM/Kies/MTP) replaced with standard Android Mass Storage
Advanced Battery Settings: Maximum Charge, Automatic Recharge Point
Advanced CPU Settings: Maximum/Minimum Clock Speed, Governor Selection
Backlight Notifications built into system, controlled by the OS
Supercurio Voodoo Sound 10
Fascinate Dock audio simulates a true USB audio device for seamless output path switching
Custom Dock options - Enable BLN, Stay Awake, Enable audio output, Maximize volume
Bluetooth Tethering support
CREDITS
While it would be impossible to remember/cite every possible reference that was used during development, I would like to specifically thank the following teams/individuals for making their work public so that others could learn from it and in more cases than not, shamelessly "borrow" it:
jt1134 - A primary source of knowledge for all things Samsung Fascinate
sgtkwol - Maintains a Linux 2.6 kernel for the Epic that provided a vast amount of reference material for the kernel updates
pawitp - Fixed my video driver changes to eliminate a 'microlag' issue (thank you!)
teamhacksung - Maintains a large repository for all Galaxy S devices, I can't count how many code compares I did against their material
Cyanogenmod - When all else fails, if you can figure out how they are doing it ... well, it's just gonna work right.
rxwookie - A long time friend of all things GeeWiz and always picks up my slack here on the forums. I think he probably knows more about GeeWiz than I do!
KNOWN ISSUES
USB Mass Storage / ADB may not work after device has been docked
After docking and removing the device from a Samsung Fascinate dock, USB Mass Storage and/or ADB may stop working. When this occurs, the only way to restore USB connectivity is to power off the device and power it back on. Rebooting is not sufficient and will not alleviate the problem.
FIRST-TIME INSTALLATION RECOMMENDATION
This ROM performs significantly better when the device uses the EXT4 file system. Unfortunately, using ODIN will always format the device with the RFS file system. As of GeeWiz Media 3.2, the "Full Wipe" ODIN package has been modified such that it will format the data volumes (DATA, DBDATA, CACHE) with the EXT4 file system. This is now the recommended installation method for first-time installation.
If the "Full Wipe" ODIN package is not used, please note that your data must be wiped manually if coming from another ROM to avoid problems, and I strongly recommend converting, at minimum, the data volumes of the device (DATA, DBDATA, CACHE) to the EXT4 file system.
UPGRADING FROM GEEWIZ MEDIA 3.2/3.3
GeeWiz Media 3.2.x/3.3.x Versions can be upgraded directly to GeeWiz Media 3.4 without a need to wipe the device data or revert the file system back to RFS. The EDIFY update-zip below is compatible with most, if not all, recoveries and will work regardless of if the device is formatted with RFS or EXT4.
Your Dalvik-cache will be automatically wiped, so the first reboot will take a long time
Due to problems with some Google services after a kernel change, the Google Services Framework package will have its data cleared during installation. You will be prompted to accept Google's location services again
DOWNLOADS
EDIFY Update-Zip (ClockworkMod / GeeWiz Recovery) Compatible Downloads
GeeWiz Media 3.4 ROM/Kernel (EDIFY Update-Zip)
http://www.mediafire.com/file/hqspl05qgbcfmkx/geewiz-media-3.4-syskernel-01122013.zip
MD5: 69f5fc67c0751bd8413f4f4c3319b12f
GeeWiz 2.8 Recovery (EDIFY Update-Zip)
http://www.mediafire.com/file/5fxee76vrxv28eq/geewiz-2.8-recovery-04162012.zip
MD5: 9869d3138279d99f1237a442f7573cad
ODIN Compatible Downloads
GeeWiz Media 3.4 ROM/Kernel/Modem/Recovery/Data Wipe Full Update (ODIN)
This will delete all user data from your device, replace your RECOVERY with GeeWiz Recovery as well as replace your modem with the EH03 revision. Your data volumes will be formatted with EXT4 on the first boot
http://www.mediafire.com/file/b8un78kf6gbp5jn/geewiz-media-3.4-fullwipe-01122013.tar.md5
MD5: 8fc027d5274aeb7b29035c9b67d68d78
GeeWiz Media 3.4 ROM/Kernel (ODIN)
http://www.mediafire.com/file/db2o2sytj65ur3v/geewiz-media-3.4-syskernel-01122013.tar.md5
MD5: b3e2bba3e6e06ee91766f2d0b6f75852
GeeWiz 2.8 Recovery (ODIN)
http://www.mediafire.com/file/h5gov2c1r8836tj/geewiz-2.8-recovery-04162012.tar.md5
MD5: b70d4063dffaa9cd89629f307d3beae5
SOURCE CODEThe entire baseline for GeeWiz Media is available on github: http://www.github.com/djp952.
Device repo: android-platform-device-samsung-atlas (branch android-4.1.2_r1)
Kernel repo: android-kernel-atlas (branch android-4.1.2_r1)
HOW TO BUILD THE GEEWIZ MEDIA 3 ROM AND KERNEL
A common request I've gotten is how to build the GeeWiz Media ROM and kernel from source. I think GeeWiz Media 3 is a little less intimidating as a first step for getting into AOSP builds since it doesn't stray too far from the Android baseline, and the kernel is based on Samsung's stock model for the device rather than the enhanced MTD model. Whatever the reason, I'm happy to try and describe how I build these components and generate the packages that I post for the community. Sometimes it's normal, sometimes it's a bit wonky, but as long as I don't miss anything important it should be a workable process for anyone that would like to get into building custom Android builds.
I think GeeWiz Media 3 would be a great learning tool, it works as-is but leaves enough room for additional customizations and enhancements that it may be a better place to start than jumping into something like Cyanogenmod or AOKP as your first project. It's up to date at the moment with the latest Android code as well, so that's a definite bonus as opposed to working with something like Gingerbread where tricks you learn may not apply to the next project you take on.
BUILD ENVIRONMENT
I use Ubuntu 12.04 Desktop x64 for my Android build environment, and even though Google states that this environment is "Experimental", I've not run into any issues with it. To get started, simply follow the directions Google has provided here:
http://source.android.com/source/initializing.html
If you are running on Windows x64, I can also recommend using a Virtual Machine as your build environment. I like Oracle VirtualBox the best, but the stock Fascinate code by Samsung has major USB problems with it, you won't be able to use ADB or Heimdall. For Fascinate-specific development I recommend VMWare Player since it can work with the stock USB. Note that you need an x64 OS and a CPU with Virtualization Support to host an x64 guest OS regardless of the software you choose. The best performance and compatibility will come from installing Linux natively on your system.
DOWNLOAD GEEWIZ SOURCE TREE
Once your environment is set up, you of course need some source code. I've opted to use Google's repo tool and AOSP manifests to control the source tree, so the first thing you need is the Google repo tool. Follow the first section of this document, entitled "Installing Repo":
http://source.android.com/source/downloading.html
I have two separate "builds", or in Android terms Manifests out there. One is called DEFAULT and includes just changes to AOSP necessary to support the Fascinate. The other is called CUSTOMBUILD and adds the light OS customizations I have done. Since I never use DEFAULT and I'm not sure t even builds at the moment, we're going to use CUSTOMBUILD, or as it's called here at XDA "GeeWiz".
Open a terminal window to your home directory (~/)
mkdir android
mkdir android/platform
cd android/platform
repo init -u https://github.com/djp952/android -m custombuild.xml -b android-4.1.2_r1
What we just did was initialize the repository for AOSP, but haven't downloaded anything yet. The -u argument to repo tells it where to find the manifest XML files. In this case, my github "android" repo. The -m tells it what manifest to use. The -b tells it what branch to pull. This is important because like most folks, I have multiple branches out there. I have been indicating at the very end of the first post what the current active branch is, android-4.1.2_r1 right now.
At this point, I suggest going into the ~/android/platform/.repo/manifests directory and having a look at the manifest file. (.repo is a hidden folder). Open up custombuild.xml in GEDIT and you can see that I've taken the AOSP manifest and simply replaced portions of it to point into my own github repos for things I've changed. I'll try to include details on how I manage this below so you could do something similar if you want to.
The most time-consuming part of building Android is downloading the code. Can't go much farther without it, so get yourself a cup of coffee and a good book ...
In the terminal, at the ~/android/platform directory
repo sync
The SYNC command uses the manifest to go get all the code. Most of it is going to come from Google, but all the bits I've altered will come from my github instead. It's going to take a very long time to download.
BUILD GEEWIZ MEDIA ROM
Once downloaded, we have to choose what device to build for. GeeWiz has two target devices, "atlas" and "atlas3g". Atlas is the Wifi-only target known here as "GeeWiz Media". Atlas3G adds to that changes required to include voice/data support (mostly courtesy of Cyanogenmod!). Let's assume if you're reading this, you're interested in the Wifi-only Atlas.
In the terminal, at the ~/android/platform directory
source build/envsetup.sh
lunch
The "Lunch Menu" (haha Google) will present you with a list of device builds to choose from. You can select by number, or you can type in anything not on the menu. As of this writing, the build we want is #9, full_atlas-userdebug. userdebug generates a generally release-quality build, but doesn't odex (pre-optimize) the APKs and has some additional debugging support you wouldn't ordinarily find. You could also type in full_atlas-eng for an "Engineering" build or full_atlas-user for a "Release" build. I think you'll prefer userdebug most of the time.
Select 9 - full_atlas-userdebug
make -j4 rompackage
This will kick off the build. It will take a long time the first time through. The rompackage argument is something I added to AOSP to support the Fascinate. This will build the EDIFY update-zip that I upload for everyone and use to generate the ODIN packages (more on that later). On typical Android devices, you would use otapackage (update-zip install) or updatepackage (fastboot install) instead. Fascinate is a special needs child, so it gets a special needs build process.
Once it's done, provided I didn't forget anything important here, you'll have a full ROM/Kernel package ready to be flashed via Clockworkmod or GeeWiz Recovery in the ~/android/platform/out/target/product/atlas folder. It will be named along the lines of full_atlas-rom-YYYYMMDD.HHMMSS.zip. Making a package for ODIN involves more steps, but I'll get to that. First I have to tell you how to build a modified Kernel ...
BUILDING THE GEEWIZ KERNEL
The Atlas and Atlas3G repos have a pre-compiled kernel in them that is packaged with the ROM build. This section will describe how to build and include customized versions of that kernel. First step is, of course, to get the source code. Both ROMs share a kernel but due to differences in the ramdisk (initramfs), they are built independently.
In a Terminal, at the ~/android directory
git clone https://github.com/djp952/android-kernel-atlas.git
cd android-kernel-atlas
git branch android-2.6 remotes/origin/android-2.6
git checkout android-2.6
Now the build environment needs to be set up. I use the compiler provided with AOSP to build the kernel as this is how Google does it. If you are using a different compiler, or have put your AOSP tree into a different location, you may have to modify these commands slightly.
In a Terminal, at the ~/android/android-kernel-atlas directory
export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=~/android/platform/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
NOTE: From this point forward, don't close that Terminal, otherwise you will have to execute the environment export commands again.
The kernel is built in three steps. This is necessary because the Fascinate doesn't conform to Android's models and we have to include the ramdisk (initramfs) in the kernel image. The first step is to select which device you are building the kernel for, which in this case will be "atlas_defconfig". (The other configuration for the GeeWiz 3G version is called "atlas3g_defconfig").
make atlas_defconfig
This initializes the kernel build for Atlas. Since we need to build the ramdisk as part of the kernel, the next step is to generate any loadable kernel module (.ko) files that need to be part of that ramdisk
make modules
The way I have the kernel set up, it will pull the necessary files for the ramdisk by looking at the device "initramfs.list" file, in the AOSP tree. The file that describes the atlas ramdisk, for example, is in ~/android/platform/device/samsung/atlas. If you examine this file you can see that it lists where all the files should come from, relative to the kernel source root directory. This explains why I went through how to build the AOSP tree before the kernel, the kernel depends on the AOSP build. Provided everything is in the right place, it's time to build the kernel
make
This executes the main kernel build. Should any ramdisk files be missing, it will error out early on and let you know what the problem is. Assuming everything goes well, your kernel will be in the ~/android/android-kernel-atlas/arch/arm/boot directory. It's named zImage and it's the combined kernel/ramdisk required for the Fascinate.
This zImage file can now be flashed directly to the device with Heimdall, packaged up for ODIN, etc. However in order to make it part of your AOSP build and corresponding EDIFY update-zip, we have to copy it into the AOSP tree and rebuild the ROM. It's a bit tedious, and other folks have different and more streamlined ways of accomplishing this, but this method has worked for me.
cp ~/android/android-kernel-atlas/arch/arm/boot/zImage ~/android/platform/device/samsung/atlas/kernel
cd ~/android/platform
source build/envsetup.sh
lunch full_atlas-userdebug
make installclean
make -j4 rompackage
This set of commands will clean out and rebuild your ROM package with the updated kernel.
CREATING ODIN PACKAGES
While not the most popular way for people to install your ROM, no guide would be complete without describing how to generate the ODIN-based installation packages. I like to provide a "Full Wipe" ODIN package that will take care of resetting the device while flashing the new ROM/Kernel, it's an easy way for people that are comfortable with ODIN to just completely replace the contents of their phone with your stuff. For this section, I'm going to assume that you are using GeeWiz Recovery, version 2.8 or later. Other recoveries will work, but as you may expect I'm most familiar with the one I made and I know for certain it has all the necessary features in place.
The ODIN factoryfs.rfs file must be generated by formatting the SYSTEM volume with RFS and then installing your ROM:
Copy your generated EDIFY update-zip to the SDCARD
Reboot into GeeWiz Recovery
Wipe the device data by selecting Wipe Device Data and then Wipe all User Data (Factory Reset)
Press the HOME key to return to the main menu
Format the SYSTEM volume with RFS by selecting Manage Volumes / Format Volumes / Format SYSTEM / Format SYSTEM [rfs]
Press the HOME key to return to the main menu
Select Install Update Package, and choose your EDIFY update-zip to install
After the installation is complete, reboot the phone by selecting Exit from the main menu. Not rebooting the device after the flash will result in a bad ODIN file more often than not. Trust me on this one.
After the device has fully booted, reboot it back into GeeWiz Recovery. The next step will be to generate a backup of the RFS-formatted SYSTEM volume to ultimately use with ODIN. GeeWiz Recovery can create these by choosing to execute a "raw dump" of the volume:
Select Manage Volumes / Backup Volumes / Backup SYSTEM / Backup SYSTEM [raw dump]
GeeWiz Recovery tries to keep volumes unmounted after it's done working, so the SDCARD must be mounted before the contents can be accessed with ADB:
Press the HOME key to return to the main menu
Select Manage Volumes / Mount Volumes / Mount SDCARD
GeeWiz Recovery will store the backup as /sdcard/backup/volume/SYSTEM-YYYYMMDD.img.gz, so as an example, I might pull it to my home folder with this command:
adb pull /sdcard/backup/volume/SYSTEM-20121022.img.gz ~/
The .gz file will contain a compressed copy of the backup, just open it up, extract the file, and then rename it to factoryfs.rfs. This is the SYSTEM volume for ODIN. There are also a number of other files you can include in your ODIN package to perform various other flash or wipe operations (I'll tell you where to get them, too)
boot.bin - Will replace the primary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
cache.rfs - Will wipe the CACHE volume; necessary if you want the device to boot into recovery automatically and run a command
dbdata.rfs - Will wipe the DBDATA volume
factoryfs.rfs - Will replace the SYSTEM volume
modem.bin - Will replace the CDMA modem
movinand.bin - Will wipe the DATA, PREINSTALL and FOTA volumes
param.lfs - Will replace the parameter block. Semi-dangerous to include, but required to ensure an initial boot into recovery mode
recovery.bin - Will replace the RECOVERY kernel and ramdisk
Sbl.bin - Will replace the secondary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
zImage - Will replace the BOOT kernel and ramdisk
To generate an ODIN-compatible tarball, gather the files you want to include and execute the following commands from a Terminal. Replace tarfilename.tar with the name you want to give the tarball, and replace file file file file with the names of the files from the table above you want to include:
tar --format=ustar -cf tarfilename.tar file file file file
md5sum -t tarfilename.tar >> tarfilename.tar
mv tarfilename.tar tarfilename.tar.md5
NOTE: If you rename the .TAR file, it will invalidate the MD5 checksum and you will have to md5sum it again.
OK, where to get the files. You can access a "full stock" ODIN package for the Fascinate, like the EH03 version that is available here on XDA to get copies of all the stock versions of these files. Or, you can use the ones from my ODIN "Full Wipe" package if you'd like as well. My ODIN tarball has a gimmick that you may find useful. If you include my copies of cache.rfs, param.lfs and recovery.bin, the device will initially reboot into recovery and automatically format the CACHE, DATA and DBDATA volumes with the EXT4 file system. It's a relatively simple trick, but an effective one to help improve the performance of your ROM. I also like to provide a "syskernel" tarball that includes only factoryfs.rfs and zImage. The benefit of this is that it will not wipe out any of your user's data. The downside is that the user may be responsible for going into Recovery on their own and executing any steps your EDIFY update-zip would have typically taken care of, like clearing the Dalvik-cache.
reserved 2
reserved 3
Good old me, always getting something wrong on a release Not usually fixed before any replies, but I didn't expect this ROM to be useful for than a precious few users anyway
Anyhow, it's rather important to apply the following patch, should anyone be trying this ROM out. This appears to resolve the problems with suspend/resume, including the ANR issue I mentioned above. I made customizations to the video subsystem to reduce CPU usage (by quite a bit), but didn't consider the ramifications of what happens when the screen is powered down properly. I've updated my method to be more like the original code behavior but still maintains the reduction in CPU load.
GeeWiz Media 3.0.1 PATCH (EDIFY Update-Zip)
- Resolves suspend/resume screen and device responsiveness issues caused by some poor coding on my part
http://www.mediafire.com/file/56287a1g1gr8iop/geewiz-media-3.0.1-patch-20120914.zip
MD5: 0ec6266f9c9acf3076c5638ccc8d52a9
Sorry for the oversight, folks.
I'm in a hotel room with no computer, and I want to flash this. Any way to do it just from a phone, and no Odin?
Sent from my SCH-I500 using Tapatalk 2
lolreconlol said:
I'm in a hotel room with no computer, and I want to flash this. Any way to do it just from a phone, and no Odin?
Sent from my SCH-I500 using Tapatalk 2
Click to expand...
Click to collapse
What ROM are you running now? If you're fully stock or running an MTD ROM like Cyanogenmod, I'm afraid that ODIN will be necessary. If you're running one of the community's older stock-based ROMs and have a recovery like Clockworkmod installed, shouldn't be a problem to download to the sd card, wipe data, and then install from recovery. You would just need to grab the big .zip file and the patch I just published.
Just to be sure, you saw that this ROM does not support cellular service, right? I'd hate for you to install it just to find out you have no phone!
To be honest, I would hold off until you are home and aren't going to run the risk of being without your device at all, but I'm flattered that you want to try it! Besides, my track record is always the same ... big release, big bug (check!), then a couple more bugs (hasn't happened yet, but they're there somewhere, I can feel it - LOL)
I have my old fascinate that I use as an mp3 so I'd be interested in continuing to test this for you. Maybe I'll find a way to get ISO working on the hardware so my wife can stop bugging me about hers.
Sent from my Galaxy Nexus using Tapatalk 2
I wanna test but my fassy is my dd
Fascinating PA2.12 Jelly Bean Sept 15 Devil 1.4.1...
Trying to flash with Odin...how long should it take to check the md5?
Edit: oop there we go
Sent from my Galaxy Nexus using Tapatalk 2
No luck. Boots straight into recovery.
Kaptinkrunk said:
I wanna test but my fassy is my dd
Fascinating PA2.12 Jelly Bean Sept 15 Devil 1.4.1...
Click to expand...
Click to collapse
I have started a full 3G version, but it will take some time and a lot of theft from Cyanogenmod to get it working. I can't promise that a full version will ever come to pass, but honestly I would prefer that than going back to update the old Gingerbread GeeWiz
kuronosan said:
No luck. Boots straight into recovery.
Click to expand...
Click to collapse
What ROM are you coming from?
Booting into Recovery once is expected when you use the "fullwipe" ODIN as it contains a sneaky automatic "wipe my data" command , but that should only happen once and then boot normally.
If you were running something that uses the "MTD" partitioning that the community has developed to try and make the Fascinate work more like a standard Android device, that has to be un-done first. I'm guessing this is the problem, but if you can give me more information as to what you were previously running, perhaps I can take a look and give you more appropriate advice? That's my best off-the-cuff guess ... if you have nonstandard partitions all kinds of weird stuff can happen if you flash something that's expecting the OEM layout
looks like am late to the parteh !!!
awesome as ever
Thankies and more thankies
djp952 said:
What ROM are you coming from?
Booting into Recovery once is expected when you use the "fullwipe" ODIN as it contains a sneaky automatic "wipe my data" command , but that should only happen once and then boot normally.
If you were running something that uses the "MTD" partitioning that the community has developed to try and make the Fascinate work more like a standard Android device, that has to be un-done first. I'm guessing this is the problem, but if you can give me more information as to what you were previously running, perhaps I can take a look and give you more appropriate advice? That's my best off-the-cuff guess ... if you have nonstandard partitions all kinds of weird stuff can happen if you flash something that's expecting the OEM layout
Click to expand...
Click to collapse
Yea, I thought just Odining the partition with your Rom from work would work but I had to go ahead and Odin eh03 first. Everything works great so far.
Sent from my Galaxy Nexus using Tapatalk 2
Does it matter which version of CWM is used?
Is ODIN'ing the 3.0 fullwipe the best way to come from CM10?
partaker said:
Does it matter which version of CWM is used?
Is ODIN'ing the 3.0 fullwipe the best way to come from CM10?
Click to expand...
Click to collapse
No matter what your current Rom is... I would recommend ODIN'ing the stock, bloated Verizon EH03 first, get it here...
http://forum.xda-developers.com/showthread.php?p=23171859
That will reset your recovery partition and file system back to stock. Note: This is REQUIRED if you are coming from CM10 our any other AOSP Rom. Otherwise, you'll get stuck in a Recovery bootloop or worse.
From there, you can ODIN the 3.0 full wipe GeeWiz Media edition... and finally you can then ODIN any recovery you want so you can easily flash up/out (ie. CWM or DJ's own GeeWiz Recovery).
Just to repeat the warning again... this Rom has no 3g connection and has no phone AT ALL. It is basically to turn your phone into a Galaxy S Player.
Hope this helps.
Sent from my SCH-I500 using xda app-developers app
Put it on my kids (my old one) runs great. jb runs slow on those old phones I think. Lag between opening apps. Other than that prefect for wifi only/ kid/game phone
Sent from my Galaxy Nexus using xda app-developers app
cuebask said:
Put it on my kids (my old one) runs great. jb runs slow on those old phones I think. Lag between opening apps. Other than that prefect for wifi only/ kid/game phone
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Yeah, I think we have to live with some lag here and there, especially with the way I chose to implement the OS (as close to how Samsung did it as I could). I've seen some data-heavy applications really slow down on me in daily use too. The Google version of the Browser seems especially annoying, I may ultimately opt to use the AOSP one, I've been very disappointed that they haven't fixed some issues that have been around since the first Jelly Bean builds. I also have trouble occasionally with my "Sonos Controller" application ... it just gets really slow on me, and takes the rest of the device with it. At least with the Browser I can say "hey -- my Galaxy Nexus does the same thing!" lol.
But hey -- thanks for the props! I'm really glad it's coming in handy for a couple other folks out here besides myself!!
GeeWiz Media has been updated to version 3.1 and removed from "Beta" status. Version 3.1 updates the core Android platform to version JRO03R (android-4.1.1_r6), and includes a small kernel change. The updated ROM/KERNEL can be applied to an existing GeeWiz Media 3.0/3.0.1 Beta installation without the need to wipe data. I would consider this to be an "optional" update, Jelly Bean R6 didn't appear to add much that this ROM benefits from at all, and the kernel update solves a problem that may or may not be something you've even noticed.
I need to add a changelog, but here's what's new in GeeWiz Media 3.1:
- No longer considered a Beta after a week of full daily testing
- Updated kernel with patch from pawitp that addresses a "microlag" issue in my video driver
- Updated core Android OS to version JRO03R (android-4.1.1_r6)
Check the first post for the links, and THANK YOU for trying out GeeWiz Media!
PS - There have actually been more than a hundred downloads of this ROM .. wow. It's about 8% of what GeeWiz 2.8 had in it's first week (and about 2% of what GeeWiz Froyo had in it's first week!), but this is a very niche/special implementation without much mass appeal and I wasn't expecting more than 20-30 people at most. I'm very glad that the ROM has some level of usefulness even without 3G support, and I hope to steal, er... borrow, er.. implement ... the necessary stuff to make a fully enabled 3G version soon. Not sure how that will go, and this Wifi-only setup is honestly my original intention as an endgame, but we'll see! Thanks everyone! :laugh:
[kernel][v3.5] leanKernel: minimalistic kernel (1/28/16)
leanKernel is not for everyone.
My philosophy is to keep the kernel footprint as small as possible by trimming as much fat as possible, and at the same time keeping it stable, power efficient, and fast. leanKernel is designed to be a drop in replacement for stock kernel, and so it tries not to deviate too far from stock.
You will find that it's lacking some of the bells and whistles of other custom kernels, so if you like features you came to the wrong thread.
Here's a longer post on what leanKernel is about.
Also folks, please read the FAQ before asking questions.
INSTRUCTIONS
If you like to stay as close to stock as possible: 1) Download and flash the normal leanKernel build here (find the latest zip file) in recovery. 2) Reboot and enjoy better performance and battery life (hopefully). That's it! There's no need to flash stock kernel first, or to wipe caches.
If you like to customize, read through the feature list below, the FAQ (post #2), the changelogs, and optionally the entire thread. Then you'll know what to do.
DOWNLOAD (flash in recovery)
v1.x is for Android 5.0, and v2.x is for Android 5.1
main download
mirror (may need to refresh browser to see latest)
PREREQUISITE
Unlocked bootloader, custom recovery installed
Push bullet channel: imoseyon
FEATURES
custom voltage control - use your favorite app
updated to latest 3.10 Linux
interactiveX - screen_off_maxfreq support (default 2.2Ghz)
sw crypto drivers updated (to use arm NEON instructions) for better encryption/decryption performance. Sequential 180MB/s reads, 60MB/s writes (using dd)
latest Linaro gcc 4.9 toolchain (optimized for a15 - thanks to Christopher83)
fat trimmed and various performance tweaks
f2fs support (updated to latest source from Samsung)
force encryption turned off (changed to encryptable)
overclocked to 2.9ghz (experimental - available as a separate build for now)
underclocked to 223mhz (experimental - available as a separate build for now)
Async Fsync
init.d support
cpu-boost control - enable/disable via lkconfig
lkconfig script for customizing leankernel (open terminal app, become superuser, then type "lkconfig" without quotes)
patched mpdecision to prevent changing min/max freq provided as flashable zip (in util directory)
color control (thanks to @savoca)
charging led support
a lot of unnecessary stuff removed from stock kernel
some components updated to Linux 3.18
random generation optimization including e/frandom support
pc/usb charging with boosted current ~300-400mA
some selinux fixes, selinux is enforced by default - staying true to stock (you can easily disable using lkconfig)
SLUB allocator updated to Linux 3.18
wake gesture control from flar2, modified for leankernel (also disabled in-call)
vibe strength control
much of the code is up to date with latest from CodeAurora
(mostly for devs) /sys/module/selinux/parameters/force_audit sysfs node to audit all/hidden selinux denies.
power aware cpu scheduling
faux sound enable/disable by sysfs (and lkconfig)
wakelock control (smb135x, wlan_rx, msm_hsic and sensor_ind)
leanKernel core control script
user option to prevent mpdecision/msm_thermal from changing min/max frequencies: frequency mitigation preventer
supports kexec for multirom
LKCONFIG
You can use lkconfig script to make custom changes to leanKernel (along with popular apps like Kernel Tweaker and Trickstermod). To run lkconfig, open terminal app, "su" (without quotes) to become superuser, enter, and then type "lkconfig" without quotes, then enter.
Code:
[email protected]:/ $ su
[email protected]:/ # lk
leanKernel configurator
---
0) display current settings
1) cpu frequency control
2) wake gesture control
3) wakelock control
4) charging led
5) rgb/picture control (advanced)
6) rgb/picture control (simple)
7) vibe strength
8) power saving mode for cpu scheduler
9) faux sound control
10) selinux mode
11) min/max freq change prevention
21) check top 10 wake locks (ie. wakeup sources)
please enter a number (or press enter to exit):
CHANGELOG
https://github.com/imoseyon/leanKernel-shamu/wiki/Marshmallow-ChangeLog
Thanks to @guitarshredder87, @Wera750, @akellar, and @grisha1 for testing test builds!
XDA:DevDB Information
Leankernel: Minimalistic Kernel, Kernel for the Nexus 6
Contributors
Imoseyon
Source Code: https://github.com/imoseyon/leanKernel-shamu
Kernel Special Features:
Version Information
Status: Stable
Created 2014-11-26
Last Updated 2016-01-31
FAQ
I'm having trouble waking the phone sometimes. Help!
We haven't really figured out exactly what's causing it - but there seems to be evidence that it's not limited just to leanKernel. One thing to try: if your ROM has a feature that prevents accidental wakeups, disable it!
I can't seem to get min and max freq to stick! What are these mpdecision zip files in the util directory?
* Read this post: http://forum.xda-developers.com/showpost.php?p=58135730&postcount=1474
* Short version: This is actually by design of mpdecision. If you want this behavior to change, I recommend that you 1) flash latest stable leankernel, 2) flash the custom no-freq mpdecision, and then 3) disable cpu-boost via lkconfig. Do not disable mpdecision if you go this route. Also, if you flash ROM, you must re-flash custom mpdecision. To go back to normal, flash the stock mpdecision file.. Launch lkconfig, choose core control, and choose one of the options in core control.
Will flashing leankernel decrypt my phone storage?
If you're already encrypted, then it will stay encrypted after flashing kernel, *until* you format data. Once you format you will stay decrypted until you decide to encrypt again (see below). If you're already decrypted, leanKernel will not force encrypt automatically.
What do I do to encrypt again?
There are several ways to do this. One way (easiest for me at least) is to adb in (or in terminal emulator):
Code:
[email protected]:/ # start encrypt
You will see the phone hot boot and once it comes up you will be encrypted again. Keep in mind that if you want to decrypt again you'll have to wipe.
How do I check the PVS BIN of my cpu?
Code:
[email protected]:/ # cat /proc/cpu/msm_acpu_pvs
The number you get should range between 0 and 15 (inclusive). If you ended up with 15 congratulations. If you ended up with 0, go get it exchanged! Stock frequency/voltage table: http://pastebin.com/ZyGA9Tec
Which kernel control app do you recommend?
When v1.0 gets released it should come with "lkconfig" for tweaking some of the options. Otherwise, I tried Trickster and KernelTweaker, and they both seem to work ok.
What are ondemandX and interactiveX?
ondemandX and interactiveX are very very close to "stock" ondemand and interactive governors, respectively. The only difference is screen_off_maxfreq sysfs support. This means that it gives you the ability to limit phone's max frequency when screen is off. This feature could be effective in reducing battery usage, especially if you have a misbehaving app (or two) that consume cpu cycles while screen is off. The default value is 2265600 - if you change the value to your top speed you're effectively disabling the feature and restoring stock behavior completely. You can use an app like Trickster or Kernel Tweaker to modify screen_off_maxfreq.
HELP! I messed up with lkconfig - how do I go back?
Do not fret. Flash lkconfig_cleaner.zip from the "util" directory.
(If you want to do this manually), reboot the phone into recovery, mount /data, and delete everything in /data/data/leankernel. Once things are back to normal, re-run lkconfig to re-do your settings.
What is cpu-boost?
Read this post: http://forum.xda-developers.com/showpost.php?p=57215289&postcount=535
What is the best RGB setting?
http://forum.xda-developers.com/showpost.php?p=57265483&postcount=620 (old)
http://forum.xda-developers.com/showpost.php?p=59092146&postcount=3017 (new)
What is power aware scheduling?
Read this post: http://forum.xda-developers.com/showpost.php?p=58313978&postcount=1651
I missed your kernel when I switched to N5. Glad to have you here
hmm.. a kernel. since its the first one posted here, im trying it out
Hell yeah. Ready to flash
Sent from my AOSP on Shamu using XDA Free mobile app
If I flash this it will decrypt right cool
digweed4me said:
If I flash this it will decrypt right cool
Click to expand...
Click to collapse
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Imoseyon said:
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Click to expand...
Click to collapse
What app should we use to control? I remember you used to have your app right
holy **** Imoseyon. you made my Thunderbolt usable way back when. so glad to see you developing for the N6 now
digweed4me said:
What app should we use to control? I remember you used to have your app right
Click to expand...
Click to collapse
Flashed it and yes decrypted thanks a lot
IMO!! Good to see ya again man. Can't wait to run your work again.
Appreciate it!
digweed4me said:
What app should we use to control? I remember you used to have your app right
Click to expand...
Click to collapse
You mean lkconfig? Yeah that's coming later (along with a whole lot more).. If you're talking about f2fs, you'd want to use custom recovery but TWRP for shamu doesn't support f2fs yet - i had to do everything manually.
Imoseyon said:
It should not decrypt if you're already encrypted, unless you re-format/wipe. But no guarantees.
Click to expand...
Click to collapse
i am still encrypted, and did not decrypt after flashing. so, all worked as it should.
Can we flash on stock ROM or is a custom ROM required?
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
nycdiplomat said:
Can we flash on stock ROM or is a custom ROM required?
Click to expand...
Click to collapse
I'm on a stock ROM.
pathtologos said:
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
Click to expand...
Click to collapse
wipe before flashing, youll be decrypted. if you dont wipe, you stay encrpted.
pathtologos said:
So let me see if I get this straight: I'm on stock, unlocked bootloader, rooted, and encrypted (as far as I know--I never decrypted), so if I flash this it won't decrypt my device? I was kinda hoping it would.
Secondly, I'm good to flash this with stock ROM? I'm hoping for a bit better battery life.
Thanks devs! I got a feeling development for our device is gonna be NUTS!!
You don't buy a Mustang for the gas mileage.
Click to expand...
Click to collapse
AFAIK, there's no way to decrypt without having to wipe unfortunately. Going the other way (unencrypted to encrypted) is super easy though, and no data loss.
nycdiplomat said:
Can we flash on stock ROM or is a custom ROM required?
Click to expand...
Click to collapse
im on rastapop, an aosp based custom rom.
simms22 said:
wipe before flashing, youll be decrypted. if you dont wipe, you stay encrpted.
Click to expand...
Click to collapse
Thanks for your quick response. Wipe what tho? Cache, dalvik, and what else? Hope you don't mean all my data.
You don't buy a Mustang for the gas mileage.
Mod edit: Thread closed on owner's request.
exNoShadez-EAS Kernel
Hey Pixel XL forum. I'm a Pixel/Sailfish owner, who also enjoys hacking on kernel code. I recently released a Kernel in the Google Pixel forum => but we are all using the same kernel, sooo.... I thought after pushing my second stable release, that I should probably post on the XL forum too.
My kernel is a bit different than most kernels available, you will quickly notice. Lots of interesting features and some unique ones too.
FEATURES
- Current LTS release -> Linux-3.18.114
- Energy Aware Scheduling
- Schedutil (default Cpu Governor)
- RCU infrastructure backport (with expert mode enabled)
- Cpu-Boost / Input Boosting (enabled by default)
- BINFMT_MISC support (NOT mounted on boot).
- Kernel Hardening/Protection (CopperheadOS/Grsec/Pax Marlin kernel hardening features)
- leds-qpnp: Notification LED control - V1.1c (Boeffla) - Adapted for Marlin
- Binder_rt = My own re-implementation of AOSP Binder that uses rt_mutexes; supporting priority inheritance
- Improved scheduling/determinism for high priority threads/tasks
- Backported Scheduling, Locking and Workqueue subsystem code from Newer Linux kernels.
- Audio Driver enhancements / backports (from Wahoo/Pixel 2)
- Sound/Audio driver Tweaks (bug fixes, scheduling improvements)
- forced Interrupt threading enabled
- Wifi Mac Address Randomization
- WireGuard (VPN) kernel module support
- KCal Advanced Colour control
- Improved ASLR (in kernel)
- USB Fast Charge
- Wake Gestures
- GCC 6/7+ Fixes
- Built with GCC-8.x-dev
- and more
Contains code from everywhere: Code Aurora, Flar2/Marlin, CopperheadOS, AOSP, Project-EAS, Freak7/Kirisakura, Linaro, Pixel 2 kernel sources, mainline linux and elsewhere. Modifications and backports by me, as well.
BACKGROUND
I wanted a kernel for My Pixel that had 'all of the things', it didn't exist... So I'm working on my own kernel. I try to balance Security/hardening, experimental features with high Performance and battery life. <- not an easy task! ... Some of the security features do come with overhead, but if you use apps that are CPU heavy / processing and/or require low latency - they will perform well (at the cost of chewing some battery life, of course).... Battery life and SOT are very reasonable though.
WARNING / VERY IMPORTANT: This kernel isn't compatible with installing TWRP ~> meaning; you must use the fastboot version of TWRP (used in RAM) , flash the kernel and NOT install TWRP to your system (the kernel is too big for TWRP to co-exist).... This may sound inconvenient, but there are a number of valid reasons to avoid reducing a kernel's size in order to support TWRP installation, in the boot partition.
***Fun facts on not supporting TWRP below => 2nd post: PLEASE READ: to understand my motivation***
TWRP REMOVAL
*To remove TWRP from your system; You need the stock boot.img from your running/current firmware (which is inside of the factory image zips) or use the Nov Stock boot.img provided here. Then it's as simple as flashing the boot.img to wipe TWRP;
fastboot flash boot_a /path/to/boot.img
fastboot flash boot_b /path/to/boot.img
Stock 8.1 July 2018 Boot.img => https://github.com/nine7nine/Apps/raw/master/MarlinStockJulyBoot.img
Now you can proceed with using the TWRP fastboot boot.img to flash my kernel, magisk/supersu or whatever else....
Fastboot twrp boot image => https://dl.twrp.me/marlin/twrp-3.2.2-0-marlin.img
WARNING: This shouldn't need to be said, but we did have someone on the Pixel forum who did this, so I'm adding a sticky/warning here; do NOT EVER re-lock your bootloader after flashing any kind of custom software, kernels, etc to your device - *it will brick your phone*. Meaning you are screwed would need an RMA / replacement device ... everyone in the XDA community should know better, but still; worth mentioning....
IMPORTANT:
Before asking questions; Please read through the thread (starting with the last few pages) - I shouldn't need to be repeatedly answering the same questions over and over again. It's good practice to get into the habit of reading through threads before asking questions in any thread on XDA, as more often then not; you're question has probably been answered. Thanks!
EXNS-EAS KERNEL DOWNLOAD:
JULY 2018 OREO 8.1 RELEASE exNoShades-eas Kernel Flashable zip
https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v2.8.2_f94351f.zip
It is stable, high performance and very responsive...
Important: You will need root; I don't support non-rooted devices && some features require it. I recommend using Magisk; https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589 ...
NOTE: Make sure to flash the latest Magisk beta *before* flashing the kernel zip ...
More Background / Important Notes:
Binder_RT:
My own port and re-implementation of the Binder Kernel Driver; a slightly modified version of The AOSP binder.
Binder_RT uses rt_mutexes as oppsed to mutexes for locking in Binder, ion, ashmem, etc... rt_mutexes support priority inheritance and should improve determinism in Binder, speed up IPC, Ion and Ashmem => Allowing applications that require low-latency, tight deadlines, low jitter and deterministic behaviour to perform better ~ This re-implementation is proving to be the great for those types of applications. The goal here is to help ensure that the Kernel and Binder's high priority && time critical threads and tasks are properly prioritized... Example; audio buffers arriving on time / no buffer underruns... *Further development work is planned to research, experiment with and improve Binder_RT.
rt_mutex documentation, for those interested;
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex.txt
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex-design.txt
CPU-Boost / Input Boosting:
Touch inputs boost CPU frequencies (thus improves performance and responsiveness).
# Cpu-boot / Input boost settings
write /sys/module/cpu_boost/parameters/input_boost_enabled 1
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1363200 1:0 2:1900800 3:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 100
IO/ CPU Governors:
This kernel doesn't include a thousand io/cpu governors. IO-wise; CFQ is the default, but we've got a few in there. chose your poison, but know that the majority of my testing is centered around cfq and deadline. CPU Governor-wise the common Linux CPU governors are there; along with Sched and Schedutil....
Stick with Schedutil - on idle, it draws very little power and in most 'peak performance situations, it should do very well..... I'm getting great battery life, sot and performance.
Managing Kernel Settings:
Get EX Kernel Manager - my original code on github was forked from EX kernel, before rebasing it - but EXKM will give you access to 99% of my kernel's settings.
My 8.1 Kernel Sources: https://github.com/nine7nine/Marlin_exns-eas
Donations via PayPal very much appreciated. I do put a significant amount of energy and time into researching, development, testing / QA and also providing support/help to end-users... It's definitely not mandatory to donate; but If you appreciate the effort, see value or benefits from using my kernel on your device and can afford to; Use the "Donate to me" button or the below link... It makes a big difference. thanks!
https://www.paypal.me/jrdnjhnstn
Why TWRP Installations are NOT supported:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
(and why I'm not using it!)
Most custom/android kernel devs are using the above configuration in kernel compilation, which is arguably very BAD... I understand that boot partitions are small and the desire to install TWRP to them, thus there is a need to reduce the kernel's size....and yes, this will achieve that - However;
1. SUSE, RedHat, etc (Enterprise linux) disable CONFIG_CC_OPTIMIZE_FOR_SIZE -> it's original use case has proven to be invalid. Even Google (in their own documentation) advise against using this; https://source.android.com/devices/tech/perf/boot-times ....
2. It suppresses useful compiler warnings....
3. As SOCs have become more powerful, google has come to the same conclusion that Enterprise Linux did back in 2012.
4. by turning off CONFIG_CC_OPTIMIZE_FOR_SIZE, we achieve better performance, boot time and better cache utilization.
Clark Williams / Redhat Bugzilla said:
* Cause: CONFIG_CC_OPTIMIZE_FOR_SIZE set with assumption that smaller code would yield hot cache lines and good performance
* Consequence: this config caused gcc to generate jump-to-jump code which causes cache line bouncing, hurting performance
* Fix: turn off CONFIG_CC_OPTIMIZE_FOR_SIZE
* Result:slightly larger kernel but better cache utilization
Click to expand...
Click to collapse
(The Above is quoted from Clark Williams, A Senior Software Architect @ RedHat -> https://bugzilla.redhat.com/show_bug.cgi?id=796297)
I know of no other way to significantly reduce kernel size. Disabling some debugging, unneeded features, etc helps - but not enough.... I am focusing on optimization, using newer builds of GCC/Linaro, performance enhancements, fixing compilation errors, etc, etc -> these things are more important than trying to support TWRP installation.
Therefore; I do NOT support installing TWRP....
This sounds incredible. All those features.. and then some. Hard for me to test as I rarely use my PC but I may have to go and give this a try.
Edit: would it be possible to create a build for those who do want to use TWRP? Would be great to do some benchmarks (real work using DiscoMark and synthetic using geekbench/AnTuTu/etc) to see differences between the two.
All those features are welcome in this poor Oreo pixel community! thanks for your work..
i'll try it as soon as possible!
spr33 said:
This sounds incredible. All those features.. and then some. Hard for me to test as I rarely use my PC but I may have to go and give this a try.
Edit: would it be possible to create a build for those who do want to use TWRP? Would be great to do some benchmarks (real work using DiscoMark and synthetic using geekbench/AnTuTu/etc) to see differences between the two.
Click to expand...
Click to collapse
No. like I said. I don't/won't support installing twrp. it would require reverting a bunch of patches/ work that I've already put in... and also not using linaro GCC 7.2.1 compiler, either...
the time invested would be a complete waste for me and I would have maintain another separate branch. test another build, etc, etc'... i'm not doing it. my current goal is to reduce my branches into one single branch/build;. ... which will end up hopefully being binder_rt... not create more.
feature wise, pretty much a 'best of' what any other custom kernel offers for Marlin, all of the hardening stuff (I think I'm the only Marlin kernel on XDA with that), etc... afaict, I'm the only one rolling in EASv1.4, cpu-boost, dynamic stune boost; all of which I've ported myself... some of the audio driver stuff I personally ported (more coming) and binder_rt is my baby; I ported aosp binder and researched / Inplemented all of the changes to Binder...
in my yet-to-be-released binder builds I also have backported a large chunk of the linux locking, workqueues and scheduling code and some other bits from newer mainline linux kernels (which allow me to pull in some new features and use them).
so I'd rather work on this kind of stuff, over caring about twrp, doubling my workload to support running synthetic benchmarks between gcc's -Os vs. -O2 optimization levels...
Thanks for the new kernel. Sounds very interesting. Can't try it atm because i am on dp1 from 8.1. Hope you gonna also support 8.1 when official sources are out. For me battery life is already great on dp1.
housepabldroid said:
All those features are welcome in this poor Oreo pixel community! thanks for your work..
i'll try it as soon as possible!
Click to expand...
Click to collapse
haha. pixel community isn't too bad. there's just not a lot of custom oreo ROMs.... myself, I wouldn't want to run any of those custom roms anyway. they usually are built without odexing or proper signiture key signing = less secure and way less optimized... Stock ROM is great, just needs root and a few apps to modify / customize it a bit.
for me, the kernel has always been the issue. lol... therefore, roll my own. lol....
ya, for sure give it a try... I honestly would say binder_rt is the best build... the 'stable build' is a bit of a misnomer - all of the builds are stable, just the binder ones are running more experimental code... binder_rt blows the socks off any other Marlin kernel for certain kinds of workloads... I'm aiming fir it to become my default build...
Donric13 said:
Thanks for the new kernel. Sounds very interesting. Can't try it atm because i am on dp1 from 8.1. Hope you gonna also support 8.1 when official sources are out. For me battery life is already great on dp1.
Click to expand...
Click to collapse
yup. I have to wait until kernel sources are released. you got it!. but when they are / 8.1 is released; I will be upgrading to 8.1, so no worries - there will be an 8.1 version...
I've heard heard that battery life is pretty good on 8.1, there's a thread in the pixel forum about it... but by what they were saying, it didn't seem that much better than what I see from my kernel.....
I'm more interested to see what performance improvements are in 8.1 kernel sources... I've found stock kernel to be a bit crappy for some stuff...
well, if at some point you are bored and want to test my kernel on 8.1, go for it. ya never know: maybe it will work. the reason I say that?
IIRC - it was tested with my old kernel / sources build... could've been a bug, not present in the new one.... or something else. IdK.. being as I'm on 8.0 I can't even look into why that might be or have been...
just make sure if u do ever try it, keep the stock boot.IMG for 8.1 around, in case it doesn't work..... and report back, if it does work. lol
Gotta say super smooth. Thanks for sharing. Maybe it's just a glitch in ex kernel manager but zram "stopping..." Or nothing to worry about.
JS.zip said:
Gotta say super smooth. Thanks for sharing. Maybe it's just a glitch in ex kernel manager but zram "stopping..." Or nothing to worry about.
Click to expand...
Click to collapse
Ah yes, I should've mentioned that ~ zram is working fine - but EXKM is being denied permission to read those files on the file system - I think it's due to a change in cgroups code (from merging in EASv1.4), but I haven't gotten to the bottom of it yet....
No worries though ~ I HAVE completely verified that zram is working, mounted swapon and behaving as it should... Honestly, the defaults for zram are fine ~ if they ever weren't; you would have bigger problems on your hands, that changing swapping wouldn't help. lol
Which build are you using? (just curious)
nine7nine said:
Ah yes, I should've mentioned that ~ zram is working fine - but EXKM is being denied permission to read those files on the file system - I think it's due to a change in cgroups code (from merging in EASv1.4), but I haven't gotten to the bottom of it yet....
No worries though ~ I HAVE completely verified that zram is working, mounted swapon and behaving as it should... Honestly, the defaults for zram are fine ~ if they ever weren't; you would have bigger problems on your hands, that changing swapping wouldn't help. lol
Which build are you using? (just curious)
Click to expand...
Click to collapse
Thanks that's what I thought. The bad boy "Binder RT" lol
JS.zip said:
Thanks that's what I thought. The bad boy "Binder RT" lol
Click to expand...
Click to collapse
bad boy eh? haha.
Ya, no worries - I check that sort of stuff, when it crops in... fixing that particular issue just hasn't been a huge priority, over other stuff that I'm working on. (and because I think it's pointless that EXKM even displays it to begin with - it just gives users the false impression that they are tweaking something, that in 99.99999% of cases - is absolutely pointless to touch).
Anyhoo, cool - let me know how things are working out with the binder_rt build, as you get some more use in ~ I really want it to become my main focus / implementation. (I personally won't be going back to using any other build day to day, anyway.)
nine7nine said:
bad boy eh? haha.
Ya, no worries - I check that sort of stuff, when it crops in... fixing that particular issue just hasn't been a huge priority, over other stuff that I'm working on. (and because I think it's pointless that EXKM even displays it to begin with - it just gives users the false impression that they are tweaking something, that in 99.99999% of cases - is absolutely pointless to touch).
Anyhoo, cool - let me know how things are working out with the binder_rt build, as you get some more use in ~ I really want it to become my main focus / implementation. (I personally won't be going back to using any other build day to day, anyway.)
Click to expand...
Click to collapse
I just wanted to point out that I grabbed your stock kernel from the OP and had planned to use that to flash my stock image. However, I happened to have the latest boot.img release decompressed on my drive so I compared it to the one I had on hand.
MD5 for your Stock Image: 7A2D92981FDE96E5D60D806019ACFA0C
MD5 for Google's Stock Image: BF9EDA2888C8C6A1FCD0A7DB6E37F739 (Latest November build)
Now I don't want to sound like the suspicious type, because in reality the stock kernel you provided is just to get TWRP off the device before flashing your kernel, but I'm forced to ask why your stock image is not identical with the main stock image? Unless your stock kernel isn't from the latest release but instead from a prior month or something of that nature (It would take me quite awhile to download the other month's releases just to check so I was hoping to ask you instead)
AlkaliV2 said:
I just wanted to point out that I grabbed your stock kernel from the OP and had planned to use that to flash my stock image. However, I happened to have the latest boot.img release decompressed on my drive so I compared it to the one I had on hand.
MD5 for your Stock Image: 7A2D92981FDE96E5D60D806019ACFA0C
MD5 for Google's Stock Image: BF9EDA2888C8C6A1FCD0A7DB6E37F739 (Latest November build)
Now I don't want to sound like the suspicious type, because in reality the stock kernel you provided is just to get TWRP off the device before flashing your kernel, but I'm forced to ask why your stock image is not identical with the main stock image? Unless your stock kernel isn't from the latest release but instead from a prior month or something of that nature (It would take me quite awhile to download the other month's releases just to check so I was hoping to ask you instead)
Click to expand...
Click to collapse
Easy explanation - I'm on Sailfish, you aren't; so the md5 wouldn't match...
I can do one of two things; you can post a upload/link to your boot.img and I will replace the link for Marlin's nov boot.img (adding it to my github) OR I will remove the link from the post and Marlin users will have to fend for themselves. (have to download 1.8GB firmware themselves for a boot.img... Obviously i'm NOT downloading your guys Nov Firmware images).
nothing suspicious at all here, dude.
EDIT: I've removed the link to the sailfish Nov boot.img, as a sign of good faith; I can replace it with the Marlin Nov boot.img - but that will require you to post a download/link to me, so I can add it in. thx
nine7nine said:
Easy explanation - I'm on Sailfish, you aren't; so the md5 wouldn't match...
I can do one of two things; you can post a upload/link to your boot.img and I will replace the link for Marlin's nov boot.img (adding it to my github) OR I will remove the link from the post and Marlin users will have to fend for themselves. (have to download 1.8GB firmware themselves for a boot.img... Obviously i'm NOT downloading your guys Nov Firmware images).
nothing suspicious at all here, dude.
EDIT: I've removed the link to the sailfish Nov boot.img, as a sign of good faith; I can replace it with the Marlin Nov boot.img - but that will require you to post a downlink to me, so I can add it in. thx
Click to expand...
Click to collapse
No problem, I download every Marlin release so I'll just update my AFH folder to include the monthly kernel release and users can download it from there. You can either link to my folder or download from it to add to your repository; either one is fine with me Thanks, and I do appreciate what you're doing but I have a 'verify first' stance since these devices are a big part of people's lives. I'm going to give your kernel a spin now, I appreciate you getting back to me so quickly. If only AFH was this fast, I just spent 25 minutes trying to get it to create an empty folder...
Link to Marlin Stock Images: https://www.androidfilehost.com/?w=files&flid=231142
Edit: I attempted to flash the "exNoShadez_eas-3.18.83_Binder_b0b66e0.zip" from the fastboot installed version of TWRP after flashing the stock boot to slot_a and slot_b, but it is failing with an error that states, "New image larger than boot partition. Aborting..." Then updater process Error 1. Any idea what would cause that?
AlkaliV2 said:
Edit: I attempted to flash the "exNoShadez_eas-3.18.83_Binder_b0b66e0.zip" from the fastboot installed version of TWRP after flashing the stock boot to slot_a and slot_b, but it is failing with an error that states, "New image larger than boot partition. Aborting..." Then updater process Error 1. Any idea what would cause that?
Click to expand...
Click to collapse
Hey, I added your nov boot.img to the OP. put it on github to save a few clicks for people.
The error you are seeing would suggest that TWRP is installed to the system. That is the only time anyone has ever bumped into that message. So, I'm not sure what's going on with your end but it would seem you have twrp actually installed...?!
the TWRP that you are supposed to use, is this one;
https://dl.twrp.me/marlin/twrp-3.1.1-1-fastboot-marlin.img
that loads and runs from RAM. twrp can't be "installed from fastboot" ~ it installs to the boot partition; leaving not enough room for the kernel.
nine7nine said:
Hey, I added your nov boot.img to the OP. put it on github to save a few clicks for people.
The error you are seeing would suggest that TWRP is installed to the system. That is the only time anyone has ever bumped into that message. So, I'm not sure what's going on with your end but it would seem you have twrp actually installed...?!
the TWRP that you are supposed to use, is this one;
https://dl.twrp.me/marlin/twrp-3.1.1-1-fastboot-marlin.img
that loads and runs from RAM. twrp can't be "installed from fastboot" ~ it installs to the boot partition; leaving not enough room for the kernel.
Click to expand...
Click to collapse
Yeah, that actually explains it. I was using a kernel with TWRP installed last go round and now it seems just flashing the factory boot.img is not getting rid of the installed TWRP. I'll figure out how to get TWRP removed for good this time; thank you for letting me know where to look.
AlkaliV2 said:
Yeah, that actually explains it. I was using a kernel with TWRP installed last go round and now it seems just flashing the factory boot.img is not getting rid of the installed TWRP. I'll figure out how to get TWRP removed for good this time; thank you for letting me know where to look.
Click to expand...
Click to collapse
Yup. TWRP can't be installed along side. Running it from RAM has to be used. ie: I don't support TWRP installations. lol
Flashing the factory boot.img DOES get rid of TWRP for good ~ you just have to make sure to use the TWRP fastboot boot.img for flashing my kernel after (since fastboot/twrp doesn't install to the boot partition)...
I've added a link to the OP to Marlin's twrp fastboot boot.img....
I also updated all of the download links and double-checked to make sure that all of the Marlin zips are packed properly with AnyKernel2 + relabelling every file on my github (by re-packing all of them all... This is mostly just paranoia on my part - but now that I'm supporting 2 devices, best to make sure that nothing gets tangled together.)
@everyone
just a few notes, since you guys are just getting exposure to my kernel, the way I do things; in regards to development, etc.
-> I post test builds (this usually happens when I make big changes.). reports are helpful on these builds.
-> Development happens fast; *I routinely add new features, bug fixes, etc and i'm almost always ahead on LTS updates over the Stock kernel.
examples;
=> lts -3.18.83 build available on the day of release
=> my Binder_rt branch is currently 140+ commits (code changes) ahead of the the other branches.
(changes since in the current downloads/releases)
=> There are a number of bug fixes, a few added features (mostly in-kernel stuff), some optimizations *and* there are massive upgrades to parts of the kernel's subsystems. (100+ commits are related to that)...
(changes since the current downloads/releases)
NOTE: The binder Branch (non-rt) will see the majority of the above changes code, but the Stable branch will only see a subset of these commits + bug fixes.
I probably won't roll out a test build for Binder_rt builds, until I've had the newest code running for a couple of days.... At that point, once things have proven to be stable good ~ i'll roll out a test build for anyone who wants to help out and dogfood test builds....
Then, I will push back changes back into the Binder builds, Stable, etc... I usually try and line up actual releases to LTS and/or => more importantly monthly android security / firmware updates....
**So the gist is; there will be frequent updates. Update as you see fit - anyone who wants to help out - run test builds and report back issues.
So pending a detail or two, I likely will be phasing out my other builds in favor of the Binder_rt build.
- I've had quite a lot of feedback via the Pixel forum, PMs and email (and a couple of friends using it too).
- The Binder_rt build seems to be very stable for everyone.... not too mention just all around better.
- there seem to be no drawbacks and quite a few benefits to that build over the others.
The one thing I'm waiting on is; I've joined the Android Kernel Developers Google Group and am currently waiting to see if I can't get some help with porting a missing Kernel function into Marlin's sources ~ this particular kernel function is what's stopping me from having Binder be sync'd with the AOSP binder implementation.... I'm hoping to resolve this sooner than later, at which point I will be able to merge in those commits (and test them).
In the meantime I'm working on a few backports to the audio driver and a few other bits (taken from Wahoo/Pixel 2 kernel sources). I've also pulled in a few fixes to binder from Wahoo, as well....
So I might post a test build for Binder_rt tomorrow - as it's accumulated a number of changes, bug fixes, etc.... I'm not sure If I will have any resolution to the missing kernel function - but that doesn't affect pushing a test build....