Related
Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.
I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.
The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.
Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)
The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), N7100 (Note 2) and N7105 (Note 2 LTE) and shares the same base-source.
Features / changelist:
Perseus alpha36.3 (26/04):
Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
Some kernel internal updates to speed up hotplugging and improve I/O latencies.
A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
Fixed led controls to behave correctly with user-space apps.
mDNIe digital brightness reduction:
You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.
You have three configurables:
A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.
Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.
Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
The register hook needs to be enabled to be able to use this function.
Increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
Perseus alpha35 (06/04):
Further rewrote the in-kernel audio controls:
Threw out the old detection methods for something more robust.
This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
mDNIe control changes:
Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.
Sources:
https://github.com/AndreiLux/Perseus-S3
Credit and thanks:
gokhanmoral, netarchy, and anybody credited in the commits.
TL;DR: before flashing aside from known issues in the second post.
This isn't an AOSP kernel. I won't work with CM and AOSP derivatives.
DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.
Known issues [Updated 02/12]
None
Older changelogs
Perseus alpha34 (22/03):
Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
Should fix all FM Radio issues.
Brings us saturation prevention for the equalizer.
Privacy mode.
Microphone level control
You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
I removed the equalizer pre-sets from STweaks, if you want, set them manually:
Bass-extreme: 12 8 3 -1 1
Bass and Treble: 10 7 0 2 5
Treble: -5 1 0 4 3
Classic: 0 0 0 -3 -5
Pleasant for ears: 4 3 2 3 1
Eargasm: 12 8 4 2 3
I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
Enabled ZRam by default with disk size of 200mB and swappiness of 90%.
The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
Applied a requested patch which allows PCs to be booted off from the phone storage.
Perseus alpha33.2 (27/02):
Master profile is correctly calibrated.
Detailed calibration report: Download
Advanced colour management report: Download
All thanks goes to Slimer777 for his excellent work.
Perseus alpha33 (26/02):
Revamped and hopefully final version of mDNIe controls:
The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; currently this version is released without calibration, however in the next minor version it will be updated with proper professional screen calibration. See the Note 2 thread to see what to expect here too. The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4.
The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done.
Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.
Leaving both these options will give you Samsung's default values, plus the black crush fix.
The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
Chroma saturation control - Same as in previous version but with fixed labels.
Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
Imagine the controls as manipulating the corners of the RGB cube:
(Credit to Wikipedia for the graphic)
By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.
STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.
There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.
Perseus alpha32 (29/01):
Charging control implemented. This is my own version.
Charging currents:
Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.
Charging logic:
Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.
The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.
Voltage control:
Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:
I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.
Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.
I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
Front buffer early suspend delay option for those who have issues with the CRT animation.
Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Harmonized some mif/int max voltages with the Note 2 limits.
Perseus alpha30 (06/01):
Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
Default OPP steps are: 400200, 267200, 267160, 160160, 133133, 100100. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 267200 means the memory interface is at 267MHz (533MHz DDR) and the internal frequency is 200MHz.
The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
Some minor source updates from Samsung regarding some new sensor drivers.
Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.
Perseus alpha29.2 (24/12):
Another minor (major) release due to security. Please update.
I screwed up something touchscreen related in v29 that disabled Flexrate requests, fixed now.
Changed Flexrate requests so that they don't scale down in their sub-samples anymore. This should improve fluidity.
Perseus alpha29 (18/12):
I'm doing a quick release because of the security fix, not very feature rich.
Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
Updated Wifi drivers.
Added GPU utilization control to sysfs and STweaks.
Changed default GPU thresholds to more relaxed values (75/17)
Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.
29.1: - Reverted the Wifi drivers back and did some CMA adjustments to see if that fixes some random reboots of people.
Perseus alpha28 (13/12):
28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
On your SD card showing up as damaged: it is not.
I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
[*]Updated the block system to Linux kernel 3.3.
Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;
FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.
Perseus alpha27 (02/12):
Sources updated with various updates from N8000u1 base. Included are following important changes;
CMA memory allocation has been altered and page handling in the kernel in regard to CMA affected pages has been dramatically improved, this should fix the high load of the "migration" process users have had since initial Jellybean kernels.
Updated wireless drivers.
Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
Other updates which are more transparent to the end-user.
New PegasusQ logic:
- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.
- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.
- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.
- CPU overclocking and voltages interface.
- Configurables for all CPU governor settings.
- GPU overclocking and voltage interface.
- Interface for audio enhancements.
Perseus alpha26 (14/11):
Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.
26.1
Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
Perseus alpha25 (23/10):
Raised and fixed USB, MISC charging rate to 900mA.
Enabled OTG car dock, smart dock and music dock charging. Alternatively this can be triggered if you short pins 4 and 5 of the USB connector with a 40.2kΩ, 64.9kΩ or 619kΩ resistor.
MTP fixed on OSX devices.
Fixed ROM power savings feature, this was originally broken because of the addition of overclocking, and the same interface that Samsung uses for limiting CPU speed in power savings mode also limits the max frequency to factory defaults. This is now fixed and powersavings mode will throttle to 1000MHz.
Fixed mis-configuration of the default audio settings to improve sound quality, sorry about that.
Ripped out the old GPU scaling mechanisms and scaling logic and replaced it by something new.
The old mechanism was getting overly complicated and was a remnant of the Galaxy S2 where we merely had 2 frequency steps originally; this was fine then, but isn't anymore today. The threshold fuçkery was confusing to a lot of people and people generally misconfigured their settings with inane values.
The new scaling logic follows a more CPU governor-like approach: Scaling up logic is basically the same as before: the GPU will scale up to the next frequency step when the load reaches a certain threshold. Up-scaling takes place step by step. The up-scaling threshold is now global and a single value applies for all frequency steps.
Scaling down in the new logic resembles more like the ondemand method; The scaling down takes place when the load goes under a certain threshold. This threshold is dictated by the up-threshold minus a down-differential. By default they are 90 and 10. Triggering this condition we scale down into a dynamic frequency target capable of accommodating and dictated by the load level. In plain words, we can scale from max frequency immediately down to the lowest one. This will improve power consumption.
Ripped out the old GPU control interfaces and rewrote it with something new to accommodate the new logic. Your old scripts won't work anymore.
We now have 10 frequency steps to the user's disposition; defaults are: 54 108 160 266 350 440 533 640 733 800.
The new system interface targets can be found in /sys/devices/system/gpu/ .
- freq_table outputs a list of the current frequency table. You can use this interface for configuring the frequencies themselves in two ways:
Pair-wise target setting: echo 533 500 > /sys/devices/system/gpu/freq_table will change the 533 step frequency to 500.
Whole-table echo: echo 54 108 160 266 350 440 500 640 733 800 > /sys/devices/system/gpu/freq_table
In the above example you end up with the same end-result over the stock settings.
Valid clock frequencies are as follows: 54, 108, 160, 200, 266, 275, 300, 350, 400, 440, 500, 533, 600, 640, 666, 700, 733, 750, 800.
- volt_table outputs the voltages to the corresponding frequencies.
Pair-wise target setting: echo 533 1025 > /sys/devices/system/gpu/volt_table will change's 533MHz's voltage to 1025mV.
Whole-table echo in the same format as freq_table. Valid voltages are 600mV => x <= 1200mV.
- thresholds sets the two global threshold settings. echo 90 10 > /sys/devices/system/gpu/thresholds . Remember that the first is the up-threshold and the second is the down-differential. The down differential may not be higher than (99 - up value).
- min_freq and max_freq set the limits of the current DVFS policy. By default we're scaling from 160MHz to 440MHz (Same as stock).
echo 533 > /sys/devices/system/gpu/max_freq will enable the top limit to 533MHz and basically overclock the device.
echo 108 > /sys/devices/system/gpu/min_freq in the same way sets the lower limit.
25.3:
- current_freq shows the current frequency. This is if somebody likes to make a monitoring app or something.
- time_in_state shows the time spent in µS on each frequency step. Echo 0 to it (by default disabled) to disable it, 1 to enable monitoring, and any other numerical value to reset the timekeeping back to 0.
Perseus alpha24 (09/10):
Galaxy Note 2 source and kernel merge. Various platform fixes included from patching up from update5.
Fixed Mali GPU interface bugs relating to staycount, and lowered undervolt-soft limit down to 600mV.
5 step GPU scaling, for now. Change your scripts.
Fixed black crush on the display. Vastly better black levels are now of order.
Perseus alpha23 (27/09):
Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
New feature: Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
Please provide feedback on fluidity and battery life.
Perseus alpha22 (22/09):
Update to update5 source code. Only compatible with Samsung Jellybean ROMs.
Stacks with my previous memory changes: total memory: 857mB for now.
Implemented timer slack controller.
Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.
Further reduced Mali sampling rate down to 50ms and changes the default thresholds to more aggressive power savings and clear-cut scaling. Removed 10ms regulator switching latency. I measured a 10% battery improvement in GLBenchmark 2.1 Egypt Battery - 50% Brightness 60 FPS.
config.gz support.
Alpha21 is the same as above but without update5 and for ICS. This is the last kernel for ICS, I'll not longer support it.
Perseus alpha20 (9/09):
Gökhan Moral's port of Voodoo Sound implemented. Currently no configuration interface is available, so if you wish to play with the settings, refer to the sysfs interfaces in /sys/class/misc/scoobydoo_sound/ . If you wish to change the device name, you must do echo 0 > /sys/class/misc/scoobydoo_sound_control/enable , followed by an echo output to the same file with the target device driver name. You can use this to change the device path to /sys/class/misc/voodoo_sound/ and sub-sequentially make a certain configuration application work. Please do not ask me for support on the latter. You can disable the sound modifications completely by the same method, by of course not re-enabling it afterwards.
Changed the Wifi packet filter to block out all but mDNS multi-cast packets.
Increased mmc timeout for bad quality SD cards.
Perseus alpha19 (1/09):
Updated Samsung source base up to update4, includes changes to the Wifi driver and various other small fixes
Added ARM topology support for the scheduler to be able to use sched_mc levels. This should increase cpu idle power consumption by decreasing idle wake-ups. For the moment disabled by default, and cpu_power doesn't seem to correctly work.
Swap support.
mDNIe sharpening improvement, courtesy of hardcore.
Decreased Mali utilization timeout to 100ms down from 1s which improves reaction time on instant GPU loads (Lock screen is best example).
New valid GPU frequencies : 54, 108, 160, 200, 266, 275, 300, 333, 350, 400, 440, 500, 533, 600, 640, 666, 700 Mhz
Increased user-space memory by 48mB to have a total of 825mB useable RAM; this comes from reduced DMA memory spaces on the part of:
- The Mulfi Function Codec a.k.a. the hardware decoding and encoding unit memory space from 50176kB to 28672kB
- The camera interface imaging subsystem from 12080kB to 10240kB
- The front-camera firmware block-space from 15360kB to 14336kB
- The ION heap size for the Video4Linux driver from 71680kB to 48128kB
In the case of the ION/V4L and MFC heap sizes I determined it by setting a benchmark for all the HD sample videos listed here to not have any detrimental effect before and after the changes. Below 41mB is the size for which the Planet Earth birds scene at 1080p high profile 4.1 40mbps video starts to lag. Keep in mind that there is no way this would be considered normal quality as this is basically un-recoded Blu-Ray quality and most videos are vastly under this bit-rate.
I note that I also haven't found any detriment in use of the cameras including the modded 30mbps camera quality.
Disabled the Kies daemon, I see no point in it and it uses up memory uselessly. Obviously Kies won't work any-more, if you want you can start the service yourselves manually.
Perseus alpha18 (11/07):
Updated Samsung source base up to update3, includes various fixes to fuelgauge battery reporting on full charge, MHL code, video media drivers, Wifi driver updates, gyroscope, MAX77686 battery charger changes, increased max display brightness, a buttload of LCD panel changes, and changes to the pixel refresh rate driver (This thing is controlled by the TwDVFSapp by the way and decreases screen power consumption at runtime).
ro.secure=1 again now but with an insecure adbd as root included.
LFB ramdisk.
Compiled with Linaro 4.6.2 and some higher level optimizations.
Keep in mind that running the new kernel on older ROMs can cause some funny behaviour, so update your ROM if so.
Perseus alpha17 (9/07):
Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.
Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.
Performance governor is now core-aware, previously as no other hot-plugging logic was available, the governor would start with whatever number of online cores were available at that time and stay like that. This made Performance useless for it's designed purpose, that being bringing maximum performance. It now brings up all available cores online upon start and turns all additional cores back offline on governor stop. It is now by far the best and consistent governor for benchmarking.
Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.
Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.
Updated the kernel from upstream to 3.0.36.
Memcopy and string function improvements, won't bring any noticeable differences.
Compilier optimizations (Roughly the same as Ninphetamine's) are now in. VFP uses the NEON libraries now. I couldn't measure any increase in any synthetic benchmarks with this though.
LFB exFat modules.
Perseus alpha16 (3/07):
Disabled touchscreen touch booster; this previously locked the CPU frequency at 800MHz, memory interface to 400MHz and bus frequency to 200MHz at any time the finger touched the screen.
Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.
Enabled quality of service requests in the touchscreen driver, this currently triggers a flexrate request at a sampling period of 15ms over the governor default of 50ms, and over 5 periods, giving 75ms of heightened reactivity. It also sends a direct memory access throughput quality of service request to the the linux power management quality of service interface to guarantee a 266MHz bus frequency for 142ms. Still need to check if that the last part works correctly.
Perseus alpha14 (21/06):
Only Mali platform changes.
Remove Samsung integrated checks on in the Pegasus platform that prevented the GPU control interfaces to work. Overclocking, undervolting, and the rest now properly work.
Removal of the CPU frequency lock to 1200MHz if the GPU is at 440MHz, this is excessive as 3D load heavy applications usually do not tax the CPU that far, and is an unnecessary power consumption burden.
The thermal control unit temperature throttling causes to fix the voltage to a fixed value when throttling is in place; this is useless considering frequency is not limited, making the whole thing senseless. Thus removed.
Perseus alpha13 (20/06):
Rebased sources on a Linux branch for commit completedness. All commits reapplied and cleaned. New repo.
CIFS included as module
Busybox removed. This should be part of the ROM.
Perseus alpha12 (14/06):
Added enhanced init.d support as per dk_zero-cool's implementation.
SHA-1 improvements
Added exception to the module loading logic for the exFat driver module thus making it work. (Credit to gokhanmoral)
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
Knowledge base
I'm going over time to update this post with some informations. It may be unsorted, unfinished or un-editorialized for the time being.
2) Hardware
The Galaxy Note 2 will be coming out with a new 4412 versioned Rev 2.0, where as the one currently in the S3 is versioned Rev 1.1. The new chip will be launched at 1.6GHz default clock. What is interesting is that they have increased the base clock from 800MHz to 880MHz, most of the SoC internals feed off this clock, meaning that we're going to have 10% clock boost in the internal bus and memory speeds.
Now as a side note: One thing that I haven't understood from the press releases back in May, is that there were this "internal 128bit bus" mentioned, with some idiotic websites taking that tidbit and claiming the chip was a 128bit architecture. Whatever. Anyway, the reason for this is that the way the Samsung SoCs internally function: they are separated in a "left bus" and a "right bus". The left bus is connected to the memory controllers and is also just called the MIF/Memory Interface. The right bus is called the "internal bus" and is connected to the ARM cores and everything else. The biggest difference here between the 4412 and the previous Samsung iterations was that both these were running at the same clock. In the 4412 the internal bus is running at half the memory interface bus, this corresponds to the increase to 128bit in the internal bus.
Now I got curious due to all this talk about the A6 and this tidbit:
"K3PE7E700F-XGC2" the last two characters refer to the clock speed. The iPhone 4S was [under]clocked at 800 Mhz. "K3PE4E400B-XGC1" was the A5's part number. E4 refers to 2 Gb LPDDR2 die and because A5 features a dual-channel LPDDR2 memory with two 32-bit die. 2 GB x 2 = 512 mb of RAM. C1 was the clock speed which was 2.5ns which indicates a 400MHz clock frequency. Two channels result in the A5 clock speed of 800MHz. So the A6 has C2 which is 1.9ns which indicates a 533 MHz clock frequency. 533 x 2 is ~1066 GHz.
Click to expand...
Click to collapse
Both the A6 and 4412 use the same memory, only difference being what seems to be a revision serial character. I was talking a few months ago how the 4412 showed a good 30% bandwidth improvement over the 4210, and credited this to it running 1066mbps memory instead of 800mbps; but in reality that is not the case.
I went over the source code of the busfrequency driver in the S3, and found that actually there is an entry for the internal frequency to run at 266MHz (128bit), but that entry is disabled in the driver; because the memory interfaces don't exceed 400MHz. The bus speed is defined in (MIF/INT) pairs and top speed available is 400200 (400MHz memory, 200 internal). Well this is interesting we can overclock our device's memory then if there's headroom! Well that idea quickly faded as I found that the C2C (Chip-to-chip) interface to the memory isn't capable of being clocked to 533MHz because simply the C2C clock divider register simply doesn't allow a divider value needed for that frequency, only being able to run 400MHz(and lower) and 800MHz. Basically we can't use the fast memory because it seems the clock dividers don't allow it. Anyway, coincidentally the i9305 sources were released two days ago and it included all the Note 2 sources and so on, so what Samsung did was simply increase the MPLL base clock from 800 to 880MHz, actually increasing the frequency of a load of things like the camera interface and who knows what at the same time.
What this also means is that Samsung increased effective bandwidth by 30% without increasing the memory speed. This indicates much improved memory controllers, and also why it easily beats the Tegra 3 and others in memory benchmarks.
Another new addition to the REV 2.0 chip is that we'll be running 533MHz for the Mali clock by default. We were already experimenting with this on the S3 and pretty much made the GPU run up to 700MHz, of course, it gets quite warm and battery hungry, but it's neat nonetheless.
3) Reserved memory spaces
There is the current reserved memory space breakdown, with red as Perseus changes over stock:
#Secure spaces on fixed memory addresses
Front-camera firmware & heap: fimc0: fmic1 =
0x65800000 - 0x66700000 => 15360K (0xF00000) => 14336K
Multi function codec B memory space: mfc-normal =
0x64000000 - 0x64400000 => 4096K
ION device memory allocator reserved space: ion =
0x5F200000 - 0x63800000 => 71680K (0x4600000) => 48128K
Multi function codec device reserved space: device_mfc =
0x5C800000 - 0x5CA80000 => 2560K (0x280000)
Multi function codec A memory space (Virtually contiguous to MFC, practically has a physical memory hole): mfc-secure =
0x5C100000 - 0x5C800000 => 7168K (0x700000)
0x5F000000 - 0x5F200000 => 2048K (0x200000)
Bootloader: sectbl =
0x5C000000 - 0x5C100000 => 1024K (0x100000)
# non secure
Camera imaging subsystem: fimc_is => 12080K (0xBCC000) => 10240K
Display interface and frame buffer: fimd => 8192K (0x800000)
Main-camera firmware & heap: fimc0 => 62464K (0x3D00000)
Audio buffer: srp => 1024K (0x100000)
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
simone201 said:
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
AndreiLux said:
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
Click to expand...
Click to collapse
Haha yeah i sold it to buy a GS3, i ordered the white one from amazon.it but it is taking ages -.-"
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Sent from my Desire HD using Tapatalk 2
Nice AndreiFlux let's test
Gesendet von meinem GT-I9300
simone201 said:
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Click to expand...
Click to collapse
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
AndreiLux said:
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
Click to expand...
Click to collapse
Yeah you're right, that's why i will stay with pegasusq by default
My mods are good to use the cores as you want, like it was with Tegrak's 2nd Core
Sent from my Desire HD using Tapatalk 2
Hi
is a bootanimation possible with this kernel or is it in a future version planed?
Bootanimations on the S3 are supposedly in a proprietary format now, so we'll have to see about it. As said, for now it's baby steps as long as I'm not able to molest the flash counter on the device myself.
Wifi is not working on this Kernel
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
Yes, me too...
+1
Same issue with wifi...
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Still no wifi with Alpha3.1
Mopral said:
Still no wifi with Alpha3.1
Click to expand...
Click to collapse
Same here
simone201 said:
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Hmmm. I'm reverting to fully untouched ramdisk now, alpha3.2 uploaded.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Click to expand...
Click to collapse
"This is your last chance.
After this, there is no turning back.
You take the blue pill -
the story ends, you wake up in your bed and
believe whatever you want to believe.
You take the red pill
- you stay in Wonderland and
I show you how deep the rabbit-hole goes."
- Morpheus, The Matrix
(Copyright belongs to the Wachowski Brothers... Larry and Andy)
Click to expand...
Click to collapse
Kernel Source: RedPill Source Based on N7100 Source Drop (until Rev1.00). Rev1.01 and beyond are currently based on N8000 sources. This Kernel is for the N7100 International Version Only!!!
MatrixPills Image by Corinne Wilger. Visit her site HERE.
What Some HyperDroid RedPill Users Have Said:
"so far this the only kernel which gives me the least wakelocks.. or hardly any.... good job..
i dont care about benchmarks which ppl are whining about.. i would say this kernel rockz" - xinfinityoO
Click to expand...
Click to collapse
"Batterywise the best kernel on my device - had not encountered just 2% loss in 7 hours at night for a very long time"- zikarus
Click to expand...
Click to collapse
"first impressions... blazing fast...smooth... hopefully no issues
(well never had one with previous releases anyways)...cheers pongster!"- jermitano
Click to expand...
Click to collapse
"I am stunned. The battery life looks great. Very smooth and stable and great response. Great work guys."- mariosraptor
Click to expand...
Click to collapse
"Awesome work! That's the least I could say. Real development and all that done during free time.
I've made donations but that won't be enough to show my gratitude. I know you don't do that for money but
that's the only way I can think of tell you all how grateful I am."- mbutandola
Click to expand...
Click to collapse
Click to expand...
Click to collapse
RedPill Features
Highlights
Exynos-Abuse Secured (Thanks to AndreiLux for the original low level patch & Samsung for the Official Fix)
SDS patch included
Ramfs from Stock Kernel + Busybox and its various functions in /sbin
Versions up to Rev1.00 were Based on Samsung Galaxy Note 2 N7100 Source Drop Release 1; Rev1.01 and up are based on N8000 Sources
Included patches for performance, stability and battery life
Init.d support
SetCPU, ROM Toolbox and Voltage Control Support
CPU Overclocking and Undervolting Support (Thanks to AndreiLux)
GPU Overclocking and Undervolting Support (Thanks to AndreiLux)
Enable or Disable File Syncing
(fsync disabled by default as I've tweaked the system for optimum latency designed for Flash Storage)
CFS Autogroup by Mike Galbraith Enabled
CPU Topology and Sched_MC enabled
AFTR and LPA enabled
A lot of tunables via sysfs included (Use ROM Toolbox or similar Utility to easily change it)
Git Implementation of SHA-1 for 12% faster boot time
CPU set at 1.6Ghz at Boot for faster boot time (Thanks to Imoseyon)
LZO compressed kernel using optimized values for the size of the kernel for faster boot time (Using faster lzo code from mainline)
CIFS Support (cifs.ko located in /lib/modules) | Tweaked Ext4 Filesystem
(Patches + Mount Options + Tweaked IO Schedulers leaning towards latency for Flash Storage)
sio | zen | row | noop | deadline (tweaked for better latency and balanced throughput for Mobile NAND based devices)
Tweaked the mount options for Ext4 to adapt to the current focus on latency
pegasusq CPU Governor (Thanks to AndreiLux for the some of the new governor specific logic he added)
WiFi Multicast Blocked (Thanks to Entropy512)
Using Google Toolchain 4.7 + compiler optimizations specific for that version (Thanks Google & Linaro)
Power Saving Features:
AFTR + LPA enabled
sched_mc enabled (set at 2 by default)
ARM CPU Topology enabled
No HZ enabled
Boot Time Features:
Used git Implem of SHA-1 for 12% Boot time improvement
Added [PATCH] arm: remove "optimized" SHA1 routines by Linus Torvalds
Added [PATCH] arm: remove stale export of 'sha_transform' Linus Torvalds
Set Clockspeed at 1.6Ghz at Boot time to ensure all critical tasks have enough power to perform them while
the governors/maxfreq isn't set yet. (Thanks to Imoseyon for this hack)
CPU Features
Supports CPU Overclocking and Undervolting (Thanks to AndreiLux)
Supports GPU Overclocking or Undervolting (Thanks to AndreiLux)
pegasusq CPU Governor pegasusq set as default (obviously)
Filesystem Features (Currently Supported)
ExFat (Using Proprietary Samsung Modules) *Stock based RedPill only
Fat32
Ext2/3/4
CIFS (cifs.ko is in /lib/modules)
Ext2Int for N7100 (Thanks to mattiadj for idea and base script that I used to get it fully working on N7100 and RedPill) (ExFAT and FAT32 only) *Stock based RedPill only
I/O Schedulers
SIO (2012 0.2 version) (tweaked for Flash) Set as Default
deadline (tweaked for Flash)
zen (Thanks to bbedward)
noop
row (Thanks to Tanya Brokhman)
Tweaked values in deadline and SIO I/O scheduler to give better than average throughput while attemting to improve latency (if not more aggressive). Based on our initial (indicative, not conclusive... yet) testing, having these in line with the vm dirty, expire, writeback values + ext4 mount options to "schedule" write outs as fast as the system can handle it works quite well to balance throughput with latency expected in a mobile device. We took the big picture view and tested our tweaks instead of copy pasting random "known" good values and challenged some assumptions even we had at the start. The result is a mobile device tuned for average throughput and balanced battery life with good latency (not the lowest latency out there, but given the benefits of better I/O throughput and potential battery savings + extending the lifetime of NAND Based storage I think it was a compromise worth taking) I could have tweaked it for extremely great throughput and battery savings but that wouldn't be fun to use. I hate micro-lags myself.
Our Test Data regarding I/O schedulers and Kernel Tweaks can be found HERE.
The blog post that describes what we are trying to do can be found on my blog post HERE. (Thanks to s2d4)
Memory Features
Custom minfree values tweaked for 2GB RAM
Tweaked vm values in sysctl that's optimized for latency
Display Features
Stock mdnie values for more vivid details on the current generation of AMOLED Displays
Performance Patches Enabled
Mike Galbraith's Ultimate CFS Performance Patch (CFS Autogroup)
*More info on this here: https://lkml.org/lkml/2010/11/20/91
Added the CGroup Patch:*Added [PATCH] cgroup: Provides a way of tasks grouping by timer slack value
by Kirill A. Shutemov Based on patch by Jacob Pan. Introduces per cgroup timer slack value
which will override the default timer slack value once a task is attached to a cgroup. It's useful in mobile devices where
certain background apps are attached to a cgroup and minimum wakeups are desired.
Experimental Latency Related Patches
Disabled "fsync disabled" by default
(can be enabled by doing an echo "0" > /sys/class/misc/fsynccontrol/fsync_enabled
in a terminal emulator or as a script for gscript or scriptmanager) (Or use STweaks to toggle it) (Thanks to Ezekeel)
Using the tweaked Ext4 filesystem + scheduler and mount options leaning towards latency + vm values in the kernel
makes the most of the speed of Flash Storage based devices. At the speed at which the data is written to and from the kernel
to the Fast Storage devices, you would only lose up to 1 second worth of data at most IF the kernel crashes.
I don't plan on that happening so I enabled the system to get the maximum possible performance in this area.
Tweaked Ext4 Filesystem (Patches + Mount Options + Tweaked IO Schedulers leaning towards latency)
Tweaked the mount options for Ext4 to adapt to the current focus on latency
3rd Party Kernel Apps Support
STweaks by gokhanmoral
ROM Toolbox by jrummy
SetCPU by michaelhuang
System Tuner
Voltage Control | ExTweaks by xan
Credits and Disclaimer
Credits: (Huge props to all the devs I've learned from by reading and studying their code)
faux123
Ezekeel
franciscofranco
supercurio
hardcore
Netarchy
Hacre/Ninpo
Chainfire
Erasmux
Imoseyon
gokhanmoral
Tegrak
Entropy512
AndreiLux
cattleprod
dvtonder
All the hardworking Kernel Devs at lkml.org
(Linus Torvalds, Jens Axboe, Mike Galbraith, etc.)
Special Mention to the following:
To my mates at the HyperDroid Dev Team: (who help me test and refine the features of our kernel for our ROM)
D.O.C. (formerly doctorcete) (for the friendship and being an example of diplomacy in
dealing with usual ****storm of questions from users who refuse to search and read)
kristofpetho (for his excellent work on the HyperNote and his patience with dealing with bugs that destroy the user experience)
Arighi (for the initial guidance on how to get the kernel booting and working & a lot of battery driven patches)
AF974 (for the Overcome based Recovery on S2 that's so bad ass I want to stay in recovery all the time.)
petsasj (for his great work on HyperDroidParts for S2 and all future Apps that are just pure awesomesauce!)
sicopat (for letting us use his server and helping us out with a lot of things smali)
s2d4 | phly-phantom | amerikian (for testing everything at the risk of the potentially time sucking Soft Brick...)
Disclaimer: I made this for my personal use and has been personally tested by me and my team (HyperDroid Dev Team).
While it may work for other N7100 International ROM's, we have not tested it personally.
You have the liberty to choose to use this Kernel and by flashing this Kernel you will have
surrendered your right to complain that you lost your Warranty. If you're smart enough to figure
out WHY you need a Custom Kernel, you SHOULD be smart enough to undo it if you need your
device serviced officially. If your device explodes, melts or otherwise disintegrates from its awesomeness
I shall NOT be held responsible.
Reposting the Kernel: Please don't repost this kernel anywhere else.
Keep the download links intact as I have taken the effort to provide fast links for everyone.
If you can't understand English well enough and feel the need to re-post this kernel on
a foreign language web site or forum, please let me know first and link to this page...
(Google Translate can make it easier to read in your Native Language)
RedPill Stable Change Log
Current and Future Changelogs can be found HERE.
Rev1.01
Completely Rebased on N8000 Source
Use newest and official Exynos-Abuse patch from Samsung (Thanks to AndreiLux for the additional patches re: static cma regions)
Fix Freezes for some Devices when transferring large files via USB
Fix SOD for some Devices
Change CPU Idle Settings back to stock
Remove Dynamic FSync (Ability to enable or disable FSync is still available)
Removed ROW I/O as sio/deadline/zen perform better in our tests
USB Charging Rate increased to 1700
Tweaked pegasusq for battery life (limit sampling rate in suspend)
Removed Conservative (as new tweaked pegasusq can save battery with the right settings)
Added Dynamic STweaks XML Implementation by AndreiLux (Thanks to AndreiLux)
Updated STweaks (Thanks to Gokhan Moral)
use get_random_int() to fix entropy depleting (Thanks to Jeff Liu)
Updated sensorhub driver, device sensors
SDS patch included (Thanks to AndreiLux)
Rev1.00
Exynos-Abuse Secured thru the low-level fix by AndreiLux (Thanks to AndreiLux)
Using Official Google Toolchain 4.6.x
Added the latest (v5.4) of the "faster crc32 algorithm" by Bob Pearson and Darrick Wong (Thanks to both of them)
Added faux123 Dynamic fsync (Thanks to faux123)
Enable Dynamic FSync and FSync Control to co-exist (Please read STweaks option to gain a better understanding)
Backported ROW I/O scheduling algorithm (Thanks to Tatyana Brokhman)
Revert to using original N7100 source bcmdhd drivers to fix WiFi for some users
Added ability to increase brightness to 255 (Thanks to nebkat)
Tick and workqueue updates from upstream kernel source (Please see commit log for details)
Remove ntfs auto mounting since people use ExFAT and FAT32 while NTFS can be loaded by 3rd party tools
Tweaked Ext2Int mount options
Tweaked System mount options
Rev0.10
Revert ExtSdCard mount points to default (To enable Ext2Int Tweak by mattiadj to work)
Added bbedward's zen i/o scheduler (Included in Stweaks options as well)
Added Option to OC to 1.8GHz after several weeks of testing for stability (Thanks to AndreiLux)
Added AndreiLux's STweaks Dynamic Config for CPU_UV, min/max freq and i/o scheduler (Thanks to AndreiLux)
Added updated pegasusq logic from newer Samsung sources (Thanks to AndreiLux for Original Port)
Added option in STweaks to swap internal and external sdcard (Thanks to mattiadj for original idea and script, which I then took and edited to ensure Full compatibility with N7100)
Added Proportional Rate Reduction for TCP (Thanks to faux123)
Tweaked deadline i/o scheduler
Rev0.9
Added Scoobydoo Sound (gokhanmoral's port of supercurio's Voodoo) (Thanks to gokhanmoral)
Added Scoobydoo specific Stweaks presets (Thanks to gokhanmoral)
Added sjkoon's Scoobydoo Sound fixes (Thanks to sjkoon)
Added android logging as a module (Use STweaks to toggle)
Rev0.8
Added STweaks support (Thanks to gokhanmoral)
Custom STweaks Entries specific to RedPill Features
Using Latest 201211 Linaro 4.7.3 Toolchain
Added NTFS Automounting support (for sdcard formatted as NTFS only, not OTG) Please Test if this works as I use FAT32
Added led blinking or fading choice from CM10 (Thanks to codeworkx and XpLoDWilD)
Rev0.7
Added UV Capability (arm voltages only) Implementation by AndreiLux (Thanks to AndreiLux)
Increase USB Charging rate by AndreiLux
Increased it even more to match AC charging rates (Experimental)
lowmemorykiller patches by Cyanogen Steve Kondik
Experimental optimizations to try and fix ZK camFW bug
Loads of Samsung OSRC updates c/o AndreiLux (Thanks to AndreiLux)
Wacom, Firmware, epen, sensorhub, camera firmware among others c/o AndreiLux (Thanks to AndreiLux)
Bug Fixes by AndreiLux on sound related source files
Rev0.6
Wakelock patch to save power (Thanks to Andrea Arcangeli)
Apply SCHED_FIFO to kthreadd (Thanks to Steve Muckle )
Testing latest Linaro 4.7 Toolchain
Camera Fix for ZKFI07 camFW (Thanks to nebkat)
Experimental Hotplug Awareness based on Load for Other Governors (Thanks to franciscofranco)
Updated lzop compression from current upstream version for a significant speed improvement (Thanks to Markus F.X.J. Oberhumer )
ARM: disable preemption in machine_shutdown (Thanks to Mike J. Chen)
Check source on github for detailed commit logs and messages
Rev0.5
Applied Vermagic patch to enable proper loading of proprietary modules (Thanks to jt1134)
Improved Latency of schedulers
Removed cfq and enabled sio as default io scheduler
Tweaked Pegasusq for smoother performance (Can be changed using SetCPU)
Ext4 patches from mainline for optimization and stability
Workqueue patches from mainline
Timer patch from mainline
Sched Race in Task Group Patch from mainline
Busfreq back to default voltages (for public release)
Fixed ExFat Loading Error (SLUB instead of SLQB)
LZO compressed kernel for more more speed
No Screen Sharpening (Only AndreiLux's Black crush fix which is in fact for the S3. Thanks for the Heads up AndreiLux)
Removed Auto EFS Backup to speedup boot process (You have an EFS Backup already, right?)
Rev0.4
Blocked multicast (Thanks to Entropy512)
Tweaked Pegasusq to start early in the boot process
CIFS built-in (no modules)
Tunneling built-in
Testing Out ezterry's 4.6.3 Toolchain
Fsync control by Ezekeel
Increased mmc timeout (Thanks to AndreiLux)
Added a few compiler optmizations for 4.6.3 Toolchain
Rev0.3
Sharpness Tweak by Hardcore (Thanks to hardcore)
Black Crush Fix by AndreiLux (Thanks to AndreiLux)
XZ Tweaked for faster boot and more efficient RAM
Enable 1.6Ghz at Boot time to speed it up just a bit more (Thanks to Imoseyon)
Various ARM topology patches
Enabled Timer Slack Controller
Rev0.2
Adjust tweaks in ramdisk
Tweaked CFQ
SMP fixes by Russel King
XZ compressed kernel (fast and small)
ARM topology
Sched_mc set at 2
Disabled Mali State Tracking
CIFS as a module
Rev0.1
Used N7100 source drop
Tweaked deadline and sio for throughput and better battery life
Tweaked conservative and pegasusq for slightly more aggressive performance
No UV
No OC
Using new SHA-1
Enabled Cleancache
Enabled Mike Galbraith's Sched Autogroup
Applied AndreiLux's sensor hub fix (Thanks to AndreiLux)
Using SLQB
CFQ by default
Using RWSEM Algorithm by Code Aurora
Tweaked kernel values using the redpill.sh in the ramdisk
Enabled init.d
Auto Backup of EFS
Using Toolchain 4.4.3
--------------------------------------------------------------------------------------
Naming convention:
x.y.z
"x and y" means they are stable releases tested by peers worldwide and have proven to be good enough to be a daily driver.
"z" is added to connote its an unstable release that is currenty being tested for new features introduced. Not for the faint hearted.
e.g. 0.2 is a stable release; 0.2.1 is an unstable test release
features in 0.2.1 that make the cut will make it 0.3 or the next stable release and so on...
RedPill Ultimate & AOSP Changelog
**AOSP (Will work with CM10 Based ROM's only)
Current and Future Changelogs can be found HERE.
Rev0.5
RedPill Stable PLUS:
AOSP specific Ramfs Tweaks
r3p0 mali
SLQB
jRCU instead of Tree Preempt RCU (Better for low latency and designed with small SMP systems like mobile devices in mind) (Thanks to Joe Korty)
mdnie, haptic, leds and touch leds patches by codeworkx and XpLoDWilD (Thanks to codeworkx and XpLoDWilD)
Added UV Capability (arm voltages only) Implementation by AndreiLux (Thanks to AndreiLux)
Increase USB Charging rate by AndreiLux (Thanks to AndreiLux)
Check source on github for detailed commit logs and messages
Rev0.6
Added gokhanmoral's additional bcmdhd-cm for CM10 (Thanks to gokhanmoral)
Experimental optimizations to try and fix ZK camFW bug
Rev0.7
Loads of Samsung OSRC updates c/o AndreiLux (Thanks to AndreiLux)
Wacom, Firmware, epen, sensorhub, camera firmware among others c/o AndreiLux (Thanks to AndreiLux)
Bug Fixes by AndreiLux on sound related source files (Thanks to AndreiLux)
Rev0.8
Added STweaks support (Thanks to gokhanmoral)
Custom STweaks Entries specific to RedPill Features
Using Latest 201211 Linaro 4.7.3 Toolchain
Added NTFS Automounting support for sdcard (Please test this as I use ExFAT)
Rev0.9
Added Scoobydoo Sound (gokhanmoral's port of supercurio's Voodoo)
Added Scoobydoo specific Stweaks presets (Thanks to gokhanmoral)
Added sjkoon's Scoobydoo Sound fixes
Remove Debugging but keep kallsyms for Scoobydoo
Rev0.10
Added bbedward's zen i/o scheduler (Included in Stweaks options as well)
Added Option to OC to 1.8GHz after several weeks of testing for stability (Thanks to AndreiLux)
Added AndreiLux's STweaks Dynamic Config for CPU_UV, min/max freq and i/o scheduler (Thanks to AndreiLux)
Added updated pegasusq logic from newer Samsung sources (Thanks to AndreiLux for Original Port)
Added option in STweaks to swap internal and external sdcard (Thanks to mattiadj for original idea and script, which I then took and edited to ensure Full compatibility with N7100)
Added Proportional Rate Reduction for TCP (Thanks to faux123)
Tweaked deadline i/o scheduler
Updated ramfs to 4.2.1
Rev0.11
Exynos-Abuse Secured thru low-level fix by AndreiLux (Thanks to AndreiLux)
Using Official Google Toolchain 4.6.x
Added Dynamic Writeback from 3.1 (Thanks to franciscofranco for the port)
Added the latest (v5.4) of the "faster crc32 algorithm" by Bob Pearson and Darrick Wong (Thanks to both of them)
Enable Dynamic FSync and FSync Control to co-exist
Backported ROW I/O scheduling algorithm (Thanks to Tatyana Brokhman)
Added ability to increase brightness to 255 (Thanks to nebkat)
Tick and workqueue updates from upstream kernel source (Please see commit log for details)
Remove ntfs auto mounting since people use ExFAT and FAT32 while NTFS can be loaded by 3rd party tools
Tweaked System mount options
Disable Ext2Int while I find a way to get around the new emulated mounts for multiuser support 4.2.1 brings (You can still use directory bind for some games and apps with large data requirements)
--------------------------------------------------------------------------------------
ULTIMATE VERSION HAS BEEN DISCONTINUED & DEPRECATED SINCE MOST FEATURES ARE FOUND ON STABLE
**Ultimate (Will not work with ExFat since I used SLQB)
Rev0.7
RedPill Stable PLUS: (New Features In Development will be on this Release)
SLQB
Busfreq Undervolting (less 100 mV)
LCD Undervolting
Touch LED Undervolting
jRCU instead of Tree Preempt RCU (Better for low latency and designed with small SMP systems like mobile devices in mind)
Added UV Capability (arm voltages only) Implementation by AndreiLux | gokhanmoral
lowmemorykiller patches by Cyanogen Steve Kondik
Check source on github for detailed commit logs and messages
Rev0.8
Experimental optimizations to try and fix ZK camFW bug
Loads of Samsung OSRC updates c/o AndreiLux (Thanks to AndreiLux)
Wacom, Firmware, epen, sensorhub, camera firmware among others c/o AndreiLux (Thanks to AndreiLux)
Bug Fixes by AndreiLux on sound related source files (Thanks to AndreiLux)
Remove all Debugging
Added STweaks support (Thanks to gokhanmoral)
Rev0.9
Using 201211 Linaro 4.7.3 Toolchain
Added led blinking or fading choice from CM10 (Thanks to codeworkx and XpLoDWilD)
Added NTFS Automounting support
Custom STweaks Entries specific to RedPill Features
Rev0.10
Added Scoobydoo Sound (gokhanmoral's port of supercurio's Voodoo) (Thanks to gokhanmoral)
Added Scoobydoo specific Stweaks presets (Thanks to gokhanmoral)
Added sjkoon's Scoobydoo Sound fixes (Thanks to sjkoon)
Added back android logging (Use STweaks to toggle)
ULTIMATE VERSION HAS BEEN DISCONTINUED & DEPRECATED SINCE MOST FEATURES ARE FOUND ON STABLE
--------------------------------------------------------------------------------------
FAAAQ's
Kernel Frequently Asked & Answered Questions (FAAAQ)
What exactly IS the RedPill?
The RedPill is a custom kernel for the Galaxy Note 2 (N7100) International version. It's aptly named to provide users a choice. This is how I would have built Samsung's stock kernel. So, I used the Samsung Source from their site as a base and added relevant patches that are built on the shoulders of giants... such as arighi, gokhanmoral, Entropy512, AndreiLux, codeworx, netarchy, hacre, franciscofranco, Ezekeel, imoseyon, Erasmux, cattleprod, hardcore, faux123, etc. and all the kernel hackers of the world that work on making this usable for all of us... I claim nothing to be original or created by myself... I simply put together features others have created that I personally would like to see and use in my own device and share it with the world because I can AND choose to do so... While I do bugfix the occasional compile error and test for near perfection, it's nothing compared to those who write most of the code for the Linux kernel. Major props to all of them!
Where is the source for building this Kernel?
You can find the source HERE. I love GPL and We should all support Open Source Software and its Developers. Please Note that Open Source doesn't mean all of this magically wrote and patched itself... it takes a lot of FREE time to do this and would appreciate if you let us know how you've improved the code.If you know what you're doing, you can easily build your own kernel too. *Please let me know if you have any improvements you feel should be included and send me a pull request. *If it tests okay, it may be included in the next release.
FYI, I'm not particularly fond of devs who release their source as tarballs. (I'm looking at 'ya Samsung!) I'm pretty sure you use a tool like git internally to manage all the changes and revisions. Why do you have to make it so hard for those that want to play with the source by releasing it in a tarball instead of publishing it on github or bitbucket? If you're a kernel dev that does this I consider you "open-forced" NOT "open source". If you don't want to use git and can't be bothered with it why not make a patch and upload that instead?
Does the RedPill support ROMs for N7105 and other N7100 variants?
As of the current Revision Released, I will not be working to making it work on a device I don't currently own. I only build kernels I can actually test myself. While "building blind" might work, I prefer to break my own device before someone else's as they probably paid good money and worked hard/smart to be able to afford the device. FYI, I'm also not in favor of devs who build blindly then ask for donations so they can support the device. I want to own my device, not let it be owned by those who donated their hard earned money to get you the device. I've seen too many "devs" build blindly then ask for a donation so they can support the device, only to find a newer, better and faster device comes out and then chooses to buy that instead of the device he built blindly for and actually got donations to buy it. Talk about Bait and Switch!
Why doesn’t the RedPill have high benchmarks?*
That’s done on purpose to keep YOU away. Seriously. The way the VM system is tweaked (dirty ratio’s, minfree values, etc.) + the focus on better latency in any type of load + a lot of other small tweaks all lead to good performance and battery drain in actual use (I like using my device and not keep it sleeping to bloat my battery stats, thank you). This may not give you the benchmark scores you want to be able to show off… which is good since it means YOU stay away from this kernel and continue to rely on benchmarks rather than actual usage.
Why should I even ROOT my device? Is a custom kernel more secure?
With the Exynos-Abuse Exploit out for ANYONE to use, you're probably better off rooting and installing a custom kernel that includes the fix of AndreiLux. (RedPill and Perseus as of this writing) Now I know it will void the warranty, as you all are aware of, but if the only way to secure your device and your personal data (You don't want anyone to see your google search terms and results as well as those "private" moments that you may have kept for yourself just like any normal person) is to root and install a secured kernel, what choice is Samsung giving you?
Can you imagine what a nefarious and talented malware developer could do with this? They could break your system and have a pop-up that says "Pay up to free your system from being one of my mobile drones"... OR "Donate to get the full features of your device" (This one actually happens a lot on XDA... some talented dev gives you partial features to lure you in... then WHAM, BAM, THANK YOU MA'AM... If you want the full features, please donate yada yada yada...) I digress, as always.
Now, would you rather wait till Samsung officially patches this exploit and run the risk of exposing yourself to the risks this exploit opens you up to? Don't assume malware devs aren't rushing their current code to try and pry their way into your system using this exploit. For all we know, they're busy trying to cover up a similar exploit and currently awaiting Play Store approval. Yes, even the Play Store Apps can compromise your system. Even if Samsung does act fast, (not as fast as AndreiLux since he fixed it in a jiffy) how sure are you that your system hasn't been compromised? You wouldn't even know it.
The best reason to root RIGHT NOW is to completely secure your system, now more than ever. If you need to claim a warranty, you can tell them:
a. I had no choice, you messed up, xda-devs cleaned it up.
b. Flash back stock kernel and remove any trace of root and your use of a custom binary.
c. Completely brick your phone and tell Samsung that the exynos-mem exploit was actually used by malware that zapped your system dead.
I'm not a fan of any of these choices since I believe warranties should be honored by the manufacturer, especially if the bug they created was the reason for the claim for warranty in the first place.
How do I know I'm secured from the Exynos-Abuse Exploit?
Don't rely on apps that tell you whether you're vulnerable or not as the low level kernel fix AndreiLux implemented doesn't need to change the permissions of the /dev/exynos-mem.
Try running Chainfires Exploit APK and try getting the exploit to say anything else but "FAILED"... or head over to the thread HERE and download the exynos-abuse binary and run it from a terminal.
$./exynos-abuse
Click to expand...
Click to collapse
If your shell changes from $ to # then the exploit was successful, if not then you're safe.
Can the RedPill be OC'd and UV'd?
It can be UV'd and OC'd.By default, I've decided to keep all voltages and clock speeds stock as experience has taught me that NOT ALL DEVICES ARE CREATED EQUAL. You can UV the CPU arm voltages and OC using 3rd party Apps that do that. (SetCPU, VoltageControl)
Can the RedPill GPU be OC'd and UV'd?
Yes. Thanks to AndreiLux. You'll need to use STweaks to fully configure this. YMMV as always.
Why a tweaked deadline and SIO I/O scheduler?
The deadline I/O scheduler by Jens Axboe has proven itself as a low overhead, high throughput and acceptable latency I/O scheduler. *When tweaked for NAND based Mobile devices, it does even better. *While it "starves" writes by default with a 2:1 Read:Write ratio, this can easily be tuned via sysfs.
Why is my favorite governor (whichever it is) not available?
Simplicity is the Ultimate Sophistication, as Leonardo Da Vinci eloquently said. *Based on extensive testing and user feedback, we gathered that these 2 governors included gave the best performance and battery life on our device. Simple choice to have only the best ones available based on actual testing and feedback. *I included only these governors so you all have a simple choice to make in finding your favorite one. *These are all tunable via sysfs so you can skew it towards battery or performance based on what is important for you. *Don't expect uber smoothness and 16 hours screen-on time though... *there will be compromises when leaning towards any of the two factors most users consider important in a kernel.
Why LZO Compression for the Kernel?
It decompresses much faster than any other, bar none. Since the kernel size and compression speed is not an issue when using LZO in the kernel. (You only decompress the zImage when booting. Compression is done when building the kernel) Don't believe me, believe the data right HERE.
Why ARM Topology and sched_mc?*(From linaro.org)
"The sched_mc function adds a power saving awareness to the Linux scheduler which is tuned for performance by default. When sched_mc is enabled, the scheduler tries to gather the running processes in a minimal number of cpus and clusters. This choice of the location of a process is done thanks to the cpu topology function which describes the affinity between cpus."
(more info HERE)
Why is my AndroidOS usage so high?
This is most likely a reporting error from Android itself. Use Better Battery Stats to closely watch what really eats your battery. That has shown to be more reliable. (If I were Android, I'd fold buy out BBS and fold its code in by default) If you still have doubts, do a real world battery test, as some have done, and they saw that their battery consumption actually remained the same or in some cases even improved. YMMV, of course. Let's not fall for "placebos" here and say that "hmmmm.... since AndroidOS must be high than my battery doesn't last as long!"
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ultimate Version FAAAQ DEPRECATED SINCE MOST FEATURES ARE FOUND ON STABLE
Why SLQB? (According to its author, Nick Piggin)* (Only for the Ultimate Revision)
”SLQB is a slab allocator that focuses on per-CPU scaling, and good performance with order-0 allocations. Fastpaths emphasis is placed on local allocaiton and freeing, but with a secondary goal of good remote freeing (freeing on another CPU from that which allocated).” Using this on the Stable version breaks ExFat from working properly. Thus, the Ultimate version is for those who don't need ExFat support.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HyperDroidDevs FAAAQ
Where do I report Issues or Get Community Support?
Use this thread to report issues, preferably with a last_kmsg, dmesg in a text file or a logcat. How do you do those? I'll let you use XDA's brilliant search function. And no, it's not broken, the search function that is. (I've heard that so many times... "Search isn't working so I posted a question here instead...")
Where are the HyperDroidDevs and their Team from?
We are an international team of crazy people who all have real life day jobs that are mostly not related in any way to Android Development. We're crazy enough to spend sleepless nights trying to make our devices (which we all personally own and have NOT been donated) better than how we received it. We come from all over. I am from the Philippines, where it's always FUN to be! We have Devs and Team members from Spain, Greece, France, Finland, Germany, Italy, Netherlands, Canada, USA, India, Poland, Philippines and even more countries.
How do I show my appreciation? Can I donate to you?
You can show your appreciation concretely in several ways:
Pressing the "Thanks" Button on XDA
Follow me on Twitter @sarcastillo and "Like" our Facebook Page
Report issues politely and completely
Donating any amount is completely up to you. *I look at donations as a "tip" for a job well done, rather than a "wage" or a "bounty" to get things done. *And Tipping is always up to you... the tipper. *I won't stop development if you don't donate, that's for sure, as I do this mainly for myself and my HyperDroid mates to begin with. I make more money running my own business than this hobby so “tips” are not a necessity… it just tells me how many people actually find the work useful enough to say thank you via a financial gesture.
This Kernel will ALWAYS be FREE to Download and USE, even if the time spent making it IS NOT FREE. *That's Open Source. (The time people spend on open source projects could have been used to spend more time with their families, for example. But the Devs commitment to get something done right is almost always tugging at him to Dev just a little bit more) *
*I've personally donated to Devs who've done things I would never have been able to figure out at the time they did figure stuff out. *Learning anything new takes time and time, in my book, is more important than money as I can't turn back time, while I can always earn money. SO I donate to Devs who spend their free time making Stuff better and easier for those of us who haven't figured out how to get it done.
Download Links
Download Links: (CWM/TWRP Version Only)
I've put the links down here to ensure you at least TRY to read the IMPORTANT info posted above.
Don't forget to enjoy the RedPill; it's Awesomeness Delivered!
RedPill
RedPill Stable Revision 1.42:
Click to download RedPill Rev1.42 (For Samsung Based ROM's for N7100) (DEPRECATED | NOT SUPPORTED)
RedPill Stable Revision 1.47:
Click to download RedPill Rev1.47 (For Samsung Based ROM's for N7100)
RedPill AOSP
RedPill AOSP Revision 1.47:
Click to download RedPill AOSP Rev1.47 (FOR CM10.1 and 4.2.2 based AOSP ROM's for N7100) (DEPRECATED | NOT SUPPORTED)
RedPill AOSP Revision 1.52:
Click to download RedPill AOSP Rev1.52 (FOR CM10.1 and 4.2.2 based AOSP ROM's for N7100)
One more for good measure
Really. One more.
Last one for me.
pongster said:
One more for testing
Click to expand...
Click to collapse
Mine again.
you had said that you would delete it in 5 minutes ,but what time is now?
Although my English is not good, I like xda forums very much, like the each friend! I hope you can point out my grammar mistakes to improve my English, thank you very much!
Thanks!!!
C-C-C-C-C-Combo breaker!
Edit: fail. Thanks guy above me -_- lol
Sent from my Galaxy Note II using Tapatalk 2
Y test thread??
Nice to see u here..looking 4ward to great themes now..
5 minutes over
Sent from my GT-N7100 using Tapatalk 2
Me
Sent from my GT-N7100 using xda premium
Woooooohhhhhooooo
Finally d kernel I was waiting for..
(Also waiting for siyah 2 b true)
Thank you so much pongster..
Used 2 loooove ur work on s2 and now on sn2..
Thank you very much..
Sent from my GT-N7100 using Tapatalk 2
Can use the kernel on hyper Rom? Thx
Sent from my GT-N7100 using xda premium
Obviously, this isn't really a test thread. I simply named it as such for the first 5 minutes so I could reserve the necessary posts I need to establish the HyperDroid RedPill Kernel thread.
DamBadz said:
Can use the kernel on hyper Rom? Thx
Sent from my GT-N7100 using xda premium
Click to expand...
Click to collapse
On HyperNote and other Samsung Based ROM's for the N7100
hiack said:
you had said that you would delete it in 5 minutes ,but what time is now?
Although my English is not good, I like xda forums very much, like the each friend! I hope you can point out my grammar mistakes to improve my English, thank you very much!
Thanks!!!
Click to expand...
Click to collapse
Please see my response in Post#18
I would never open Off-Topic threads anywhere. On any forum.
And for Gamma Controlling using init.d script or using terminal.
Examples to learn about it.
LG Preset Undercover
Code:
#!/system/bin/sh
# First we set colors
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
# Now Gamma, need to change values at place 6 and 7 only
# value at 6 is amp0 and at 7 is amp1
# kgamma_r is for red, g for green and b for blue
# values amp0 and amp1 are located below $$$$
# ---------------------$$$$$-----------
echo "208 114 21 118 0 [B][COLOR="Red"]20 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_r
echo "210 114 21 118 0 [B][COLOR="red"]19 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_g
echo "212 114 21 118 0 [B][COLOR="red"]19 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_b
# undercover's LG Preset values :D, thank you.
My kernel defaults, Google Preset
Code:
#!/system/bin/sh
# First we set colors
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
# Now Gamma, need to change values at place 6 and 7 only
# value at 6 is amp0 and at 7 is amp1
# kgamma_r is for red, g for green and b for blue
# values amp0 and amp1 are located below $$$$
# --------------------$$$$$-----------
echo "208 64 68 118 1 [COLOR="red"][B]04 02[/B][/COLOR] 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_r
echo "210 64 68 118 1 [B][COLOR="red"]00 00[/COLOR][/B] 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_g
echo "212 32 35 116 0 [B][COLOR="red"]26 16[/COLOR][/B] 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_b
# Harshkernel default settings
Values marked in RED color are only values you need to change while using this script.
and all these echo commands you can use it in terminal too, or you can run script from terminal.
I am providing scripts here, so you can directly download it to your mobile phone. Remove txt extention, and put it in /system/etc/init.d folder, and set permissions.
XDA:DevDB Information
[KERNEL][UV][Linux 3.4.48] Harsh Kernel build June-10, a Kernel for the Google Nexus 4
Contributors
Harsh
Kernel Special Features: Kernel for JB 4.2.2
Version Information
Status: Stable
Created 2013-08-22
Last Updated 2013-08-22
Hello guys n gals,
This is Kernel for Nexus 4 should work on all ROMs if having unmodified RAMDISK. For sources visit my github
It is CWM flashable zip file. So can be easily flashed.
Those having kernels with modified RAMDISK and other things, do flash RESET kernel(provided by other great devs in their kernel thread) before flashing this kernel.
harshkernel was made by me from google sources, and some extra tweaks for Personal USE.
I do not have time to support like other devs, I am just sharing what I have made for myself as my daily driver.
Well, our cpu are made at some quality standards. We have 4 different quality of cpu for apq8064 from Qualcomm. so depending on which one is on your phone it selects frequency table from slow, nominal, fast and faster.
Google kernel source have same frequency table for fast and faster. So those with faster are not getting their extra advantage :crying:
You can identify you CPU chip by below command in terminal.
adb shell dmesg | grep PVS
It will give you some output as given example below
Code:
adb shell dmesg | grep PVS
[ 0.873920] acpuclk-8064 acpuclk-8064: ACPU PVS: FAST
Click to expand...
Click to collapse
And faster binned CPU has lot to do with UV, when you look as frequency table of faster, it is already preconfigured to have lower voltages than fast, and lot lower than slow binned.
Phones with faster binned should have better battery than slower binned phone out of box without any other configuration.
And for UV its already hardcoded and can be adjusted by System Tuner app further. And OC I am not willing to add. Maybe will adjust frequency(underclock) later on but hardcoded and tested.
Click to expand...
Click to collapse
Features:
Added support for people who have CPU with FASTER binning.
So now cpu supports Slow, Nominal, Fast and Faster.
UV accordingly to have best stability. min UV is 100 so also not so less either
Updated OnDemand and Interactive governor
Raw ioscheduler
Gamma control faux, also enabled init.d
HSIC wakelock fixed
If you like it hit THANKS button.
Download file is in AnyKernel format from koush, should work on all ROMs with unmodified RAMDISK
harshkrnl build June-10 Linux 3.4.48 Link: DOWNLOAD
No update to boot.img from now on, cant upload stuff as fast as before. Slow internet
Boot Image Feb-20 (build with new 4.2.2 ramdisk): http://d-h.st/7vB
Google's 4.2.2 Stock kernel with UV, Gamma and faux's Sound. Nothing more nothing less.
Download Link: http://d-h.st/8z8
boot images will not be updated, as having very few downloads ... maybe those who use it are senior members and can pack by their own if required.
sourcecode
Changelog:
Build June-10
Linux 3.4.48
Build May-15
Linux 3.4.45
Faux's Sound 2.1
Don't break whats not broken
Build Mar-21
Linux 3.4.37
Build Mar-12
Linux 3.4.35
Faux's Sound Control
Build Mar-01
Linux 3.4.34
Disable few wifi debug
Build Feb-24
Linux 3.4.33
Upgrade to Graphics Driver from caf
More HSIC Patches from caf
Build Feb-20
Linux 3.4.32
Updated RAW to latest caf source
Build Feb-16
Linux 3.4.31
Sync with Google 4.2.2 sources
New video drivers from google
1st India Edition
Build Feb-05
Linux 3.4.29
Compiled from new setup of my Laptop
Build Feb-03
More changes to UV
Added latest fixes by Google
Build Feb-01: Safe UV
Safe UV by Skkip (UV accordingly so that stability is priority)
Build Jan-29: Gamma
Added Gamma control possibility using script or terminal
Step forward in CLEANER device (no kernel controlling apps)
Build Jan-28
Linux 3.4.28
Nothing much
Uploaded 2 builds (Normal and Lower UVed)
Build Jan-24 -fixed
Linux 3.4.27
Added westwood+ and set as default
Removed some of logging and debugs
And UV is now -100 mV across the board as per many requests.
Fixed TouchControl from my previous mess-up.
Build Jan-22
TouchControl Supported now.
Gamma control added, and also tweaked inside kernel
Removed some IO schedulers
Removed some unnecessary debugging
Build Jan-20
Updated to Linux 3.4.26
Camera driver tweak testing (not proven improvement but does not harm either)
Enabled CIFS suddenly I had need for this one
Build Jan-18
Interactive Governor is now fixed
OnDemand is set as default (use trickster app to select Interactive governor).
Build Jan-16
More changes to RAW io scheduler from caf
Update to Linux 3.4.25
And smoothness of Jan-15 continues
Build Jan-15
More tuning outside kernel code(compiler) for better smoothness.
Secret (its not kernel thing, so no GPL code)
Build Jan-11
RAW iosched patches from caf
Update interactive gov from google (plz dont use it yet)
Build with gcc46 again to test. (previous build was gcc47)
More caf patches
Build Jan-07
Showp-1984's suggested touchscreen fix
Everything same as below. Its just for touchscreen fix
Build Jan-05 L2
Updates to L2 table
Try2 on 3g data fix (no reverts on hsic wakelock fix, its still there)
Been testing this build since yesterday on 3g with sweep2wake enabled consumed my 1/3 of monthly data and had no problems. 23h 7m all on 3g - s2w enabled, with 1h 50m screen on. Battery currently at 23%
Build datatest
Lots of changes look for my github IPA branch for it.
Build Jan-03
Disabled sweep2wake by default (can be enabled by various apps)
Add support for krait cores retention (low power mode cpu core voltage handling changes)
Added Internet Protocol Accelerator (testing phase, data is working do not worry )
Build 0201
Added ROW iosched and set as default
Removed some governors (ondemand is default and preferred)
Qualcomm Secure Execution Environment Communicator fixes which were missed out before.
Build 3012
better 3g battery proven from last version
Better cpufrequency management
Changes in Omdemand for above :good:
last version for year 2012
Happy New Year.... Once again :laugh:
Build 2912
test for HSDPA battery consumption
Probably last version for year 2012 (going Paris tomorrow)
Happy New Year....
Build 2812
Fixed msm_hsic_host wakelock
Edit: 2nd Attempt to fix hsic wakelocks
Build 2712
Completely Cleaned all remaining Qualcomm InKernel mpdecision traces
Should be perfectly stable now.
Build 2512
Merry xmas
Reverted back to original mpdecision (thanks showp-1984 and Imperticus)
Added Sweep2Wake (thanks again showp-1984 genius :highfive
Warning: Sweep2Wake only active for bottom part of screen (navigation bar area)
Build 2212
Updated Latest OnDemand governor from codeaurora
Codeaurora mpdicision InKernel Solution (possible to set max frequency below project butter )
InKernel mpdicision is new approach from Codeaurora sources and not similar to show-p1984(s2w salute )
Build 2212
Merged kernel.org Linux 3.4.x upto latest current Linux 3.4.24
Updated prima wifi drivers "prima: release 3.2.1.13"
Build 1912
CPU Binning Names added back. No more numbers
Color can be set using Franco's Display Control or Trickster Kernel MOD
Build 1812
Build Using more msm CPU oriented flags
Enable Voltage control (using System Tuner app from market)
Thanks Faux and motley for that. :good:
Build 1612
Added UV for all 4 frequency table slow, nominal, fast and faster
UV added accordingly to maintain stability for all.
As I have NOMINAL CPU, its tested on that only
Build 1512
Add support for FASTER PVS bin
Support selecting different PVS tables
Lower VDD_DIG voltage vote for L2
Color calibrated to my own liking (reduced yellow screen effect)
If you like it hit THANKS button.
You finally released it. Should work with cm too?
Imperticus said:
You finally released it. Should work with cm too?
Click to expand...
Click to collapse
Yes had to release as I was using it.
Not this version as it is boot.img. For cm version I will have to put it up in anykernel script, as cm use different ramdisk
Sent from my Nexus 4
Harsh said:
Yes had to release as I was using it.
Not this version as it is boot.img. For cm version I will have to put it up in anykernel script, as cm use different ramdisk
Sent from my Nexus 4
Click to expand...
Click to collapse
I shall extract and try it on CM
EDIT: tried both AnyKernel, and building boot.img using ramdisk from franco's kernel. Stuck on Google screen.
Moved thread to Original Development
updated anykernel zip for flashing on other rooms.
http://d-h.st/2k4
weird it won't boot for me, fastboot or flash; sticks on the google screen
stock 4.2.1 8gb.. used stock version boot.img
edit, using the anykernel version worked.
thx
I've just added this kernel to the Nexus 4 Complete Index
Sent from my GT-I9100 using xda premium
what exactly is faster pvs anyways and how can one check if its in use?
MiG123 said:
what exactly is faster pvs anyways and how can one check if its in use?
Click to expand...
Click to collapse
dmesg > /sdcard/dmesg.txt in terminal or adb shell dmesg | grep acpuclk or adb shell dmesg | grep PVS
Should say Nominal, Slow, Fast, or Faster
Faster = higher binned and theoretically can uv lower
Hm, as far as I can see it, PVS= processor voltage settings. And for what I found this seems to be kind of preconfigured voltage settings not more and not less.
So faster IMHO has nothing to do with UV but OCing...
But never less this hole thing is irritating because if kernel don't supports UV and no OC what would bring PVS anyway ????
Gesendet von meinem Nexus 4 mit Tapatalk 2
Martin_Ro said:
Hm, as far as I can see it, PVS= processor voltage settings. And for what I found this seems to be kind of preconfigured voltage settings not more and not less.
So faster IMHO has nothing to do with UV but OCing...
But never less this hole thing is irritating because if kernel don't supports UV and no OC what would bring PVS anyway ????
Gesendet von meinem Nexus 4 mit Tapatalk 2
Click to expand...
Click to collapse
Well, our cpu are made at some quality standards. We have 4 different quality of cpu for apq8064 from Qualcomm. so depending on which one is on your phone it selects frequency table.
Google kernel source have same frequency table for fast and faster. So those with faster are not getting their extra advantage
And faster has lot to do with UV, when you look as frequency table of faster, it is already preconfigured to have lower voltages than fast, and lot lower than slow binned.
Phones with faster binned should have better battery than slower binned phone out of box without any other configuration.
And for uv I will add later on. Hardcoded in kernel itself, but end results is faster binned cpu = run on lower voltages.
Sent from my Nexus 4
Thx for your detailed answer I really appreciate this. Now it makes way more sense to me. Maybe you can add this background information to OP ?
Gesendet von meinem Nexus 4 mit Tapatalk 2
Martin_Ro said:
Thx for your detailed answer I really appreciate this. Now it makes way more sense to me. Maybe you can add this background information to OP ?
Gesendet von meinem Nexus 4 mit Tapatalk 2
Click to expand...
Click to collapse
Thanks for suggestion. Its now added in OP .
Added build 1612.
Changelog:
Added UV for all 4 frequency table slow, nominal, fast and faster
UV added accordingly to maintain stability for all.
As I have NOMINAL CPU, its tested on that only
http://d-h.st/qtL
How much is it undervolted for faster ?
Sent from my Nexus 4 using Tapatalk 2
Imppy said:
How much is it undervolted for faster ?
Sent from my Nexus 4 using Tapatalk 2
Click to expand...
Click to collapse
Undervolt in my kernel is not same at all frequencies. I adjusted as dynamic as table was created.
I can just say in short, my FASTER would be -100 mV at 384 MHz than fast frequency in Google stock and -125 mV at 1512 MHz.
So FASTER table starts at min 750 mV and ends at max 1025 mV.
And for FAST table starts at also 750 but ends bit higher at 1050'
Sent from my Nexus 4
hi harsh, nice to see you here again. following you in the P990 forum for a long time. so anything from you must be great that i shouldn't miss.
although i have read through your posts, dont really get it..so my noob question:
this kernel should bring me more power or more juice ?
Sent from my Nexus 4 using xda app-developers app
Page 1: Information
Page 2: Changelog and Downloads
Page 3: Additional info and FAQ
Instructions:
Make sure you are on the latest bootloader version before flashing this or any other custom kernel. Search for a flashable zip or use fastboot and the google factory images.
Download Kernel to internal SD card. Flash in recovery. Reboot. Congratulate yourself for wisely installing the best nexus 7 kernel.
A complete list of changes is available at my Github.
Source: https://github.com/Metallice/android_kernel_grouper
Recommended Settings:
The only app supported for changing any kernel parameters and settings is TricksterMod - https://play.google.com/store/apps/details?id=com.bigeyes0x0.trickstermod
CPU governor - TouchDemand with default parameters (default)
I/O Scheduler -
- ROW for pure read speed. Fast reads which are often the most important on mobile. Similar concerns like deadline.
- BFQ for more consistent performance. Slower than Deadline and ROW, but prevents stutters while downloading in background
Max Frequency - 1.2Ghz (Stock max for 2+ cores) (for lollipop it might be a good idea to use 1.3Ghz)
- Note: Tegra sets the max frequency to 1.5Ghz at boot, make sure to change it manually or have an app set it at boot to avoid battery loss. If you have a program such as
TricksterMod set it at boot make sure to include at least a 60 second "delay" in applying boot settings.
- Note 2: DO NOT USE THE APP "SYSTEM TUNER" TO SET FREQUENCIES. CONFLICTS WITH AUDIO PERFLOCK IN KERNEL. Do NOT use system tuner to set frequencies as it conflicts with audio performance lock in this kernel. Will prevent you from lowering your maximum frequency. Use Trickstermod.
GPU Max Freq - 446Mhz (maintains good battery life while smoothing out some games. Anything greater than 446Mhz is so heavily bottlenecked by RAM that it's essentially worthless. 600Mhz might give you 1 or 2 extra FPS for significantly worse heat, battery life, and stability)
- Possible frequencies - To be completed later
Fsync - On
Dynamic Fsync - On (be aware of data loss concerns, even if they actually are minimal.)
SmartDimmer/PRISM - On (off for a63 and lower)
zRAM - off/none (default) (For lollipop it may help with multitasking at the price of speed, although you really shouldn't be trying to heavily multitasking with a 2012 N7 anyway) (Not very useful on android 4.x with >=1GB RAM, for lollipop it's not really helpful >=3Gb)
Data remounting scripts - already included in ramdisk. Additional scripts not needed.
I DO NOT RECOMMEND, nor will I support, any kind of optimization/superdupercharge/placebo script. All settings are already optimized in kernel and ramdisk. Using these scripts or tweaks will only lead to problems and performance degradation.
__________________________________________
If you'd like to buy me some caffeine so I can continue to fit studying and kernel-ing in my busy schedule, feel free to donate below. Thanks so much for all of your support! Clicking the thanks button is always appreciated too
Alpha Changelog (stable feature list above):
a77 - remove CM12.1 specific stuff from ramdisk
a76 - Fix for 5.1
a75 - 5.1 Lollipop update and patches
Click to show complete changelog
a74 -
Fix for TricksterMod. Sync with cm12 ramdisk. Fake update dmcrypt to allow TRIM on encrypted devices (untested). Set ROW as default scheduler.a73 -
Lollipop! Updated toolchain. Removed touch2wake due to the wakeup issues it created for some. Other stuff.a69 -
Quick fix to allow overclocking on stock roms.
a68 -
Update to latest 4.4.3 kernel source
Sync with latest CM 4.4.3 ramdisk
Update to 4.8 toolchain
F2FS support
Zip installation supports all permutations of ext4/f2fs layouts
Based on work by frantisek.nesveda, but modified to support all layouts and be more flexible
Make sure to go to his thread -HERE- and click the thanks button!
Upgrade to BFQ v7r4
Adjust touchboost values
Enable Kernel Samepage Merging - I've gone back and forth on this. For now, enabled.
Probably some other changes I'm forgetting.
a67 - Update + sync ramdisk from cm11 to enable native USB OTG. Add thermal charging shut off. Some kconfig tweaks.
a66 - Only hold wakelock is touch/slide to wake is enabled. Tweak default BFQ values a bit.
a65 - Update BFQ from 5.1 to 6r2. Set BFQ as default for testing. Tweak Deadline and CFQ (Franco's CFQ values). If CFQ is still causing reboots for some, I will revert it to stock in next build. Cgroups timer slack controller. Enable RCU priority boosting for testing.
a64 - merge 4.4 kernel changes. Update ramdisk for 4.4
a63.1 - CM hotfix
a63 - Add Tegra 4 SmartDimmer (ported from TripNRaVeR's port for the One X). It either works much better or is completely broken. Either way, it's an improvement from the old SmartDimmer. Add necessary ramdisk change for PAC rom. Add dm9620 usb ethernet support. Switch back to linaro 4.7 toolchain from google 4.6 (used in mr2 for stability reasons).
a62 - Add double tap to wake thanks to flar2 and sgt. meow. Add configurable timer to keep double tap to wake active after screen shut off. Remove Fsync toggle. Pointless and confusing with Dynamic Fsync available now. Update Dynamic Fsync from faux123. Set backlight levels back to defaults and disable otf_scaling. Some random stuffs.
New sysfs:
/sys/android_touch/wake_timeout
Value is in seconds. Defaults to 60. Set to 0 to keep double tap to wake permanently active at the price of battery.
a61 - Enable compass driver. Add Dynamic Fsync by Faux123. Disable Fsync off at boot. Enable Dynamic Fsync at boot. Remove wifi pm fast/max toggle as it is now pointless and won't work since 4.3 kernel update. Add an older, but simpler, version of usb host mode by mehrvarz. Fixed and enabled many 4.3 config options relating to things like selinux.
a60 - More ramdisk fixes
a59 - Update cm10.2 ramdisk to fix storage issues. Fix 00su init.d.
a58 - Incorporate cm10.2 ramdisk.
a57 - Update to 4.3 kernel base. 4.3 stock only. Ramdisk base courtesy of Francisco Franco. Fsync off at boot since the internal storage is just so appallingly slow.
a56 - Add back some missing config options removed in a55 to support various features. No CIFS support. Couldn't get it to boot for some reason.
a55 - Add v2 of Tegra AHB patch set. Remove and revert USBHOST patches. Revert to almost stock kernel config for testing (will probably revert back later). Revert to stock PA ramdisk for testing. Tweak default TouchDemand parameters for bettter performance. Hard-code deadline and cfq tuneables thanks to the work by those in Franco's thread - details in commitlog on github. Set deadline as default I/O scheduler. Add core hotplugging lock during touch boost/input to interactive governor based on implementation in stock interactive governor (not fully tested). Other minor, inconsequential changes.
a54 - Remove AHB bus drivers and patches.
a53 - USBHOST support and patches. WiFi adhoc IBSS support.
a52 - revert voltage table changes
a51 - fix flickering at brightness level 13 when smartdimmer was enabled by setting SD min to 10. Re-enable a 3g modem reset assignment fix. It was disabled in a49/a50; let's see if re-enabling it causes 3g drops to return (Otherwise TCP proportional rate reduction was the cause). Re-enable wifi p2p patch that was disabled in a49 under the impression it wasn't included in the stock kernel when it actually is (whoops). Increase the some DVFS voltages so that that they are at least as high pre-a50 (according to DVFS debug showing actual running voltage) and not more than 25mV greater than pre-a50. Hard-code default pm_qos_max_cpus as 4 instead of ULONG_MAX. Fixes aesthetic bug where the default tegra hotplug max_cores was 2147483647 (For the curious - it is 2^31 − 1, the maximum value for a 32-bit signed integer in computing).
Oh, and change thread title to accord with new XDA requirements.
a50 - re-enable dynamic edp. Rework some edp limits. Rework DVFS voltage tables to better match frequencies, YMMV. Removed 1.7GHz max frequency option as it was pretty split whether your device could run it or not. If people were more responsible and wouldn't complain about issues when running 1.7 or higher I would leave it in, but unfortunately that's just not the case. So it saves me headaches in the future. Sorry. It's a minor increase from 1.6GHz and most can do 1.6 just fine.
a49 - add some rwsem patches. Revert TCP proportional patch. Revert a wifi p2p patch. Fully stock /net and drivers/net in source now. Add custom min/max backlight interface. I'll add more info when I'm not so busy. Removed zRam support.
Change your max backlight (min - 255) - /sys/module/board_grouper_panel/parameters/max_backlight
Change your min backlight (1 - max) - /sys/module/board_grouper_panel/parameters/min_backlight
Enable/Disable on-the-fly backlight level redistribution through available brightness slots based on new min/max using math below (0/1) - /sys/module/board_grouper_panel/parameters/otf_scaling
- brightness = min_backlight + DIV_ROUND_CLOSEST(((max_backlight - min_backlight) * max((brightness - 10),0)),245);
a48 - actually upload a kernel that is mr1 + row patches + flash fix
a47 - mr1 + row patches + flash fix accidentally uploaded old kernel version...
a46 - disable have_efficient_unaligned_access. Add USB Host mode charging patches.
a45 - Fix adobe flash corruption. Add ARM unaligned access and enable have efficient unaligned access. Make sure slider min brightness and auto-brightness min have the same backlight value.
a44 - Start over at mr1. Add ROW patches. Add LZ4 compression.
a43 - revert all network and wireless patches since mr1.
a42 - revert some config options. Fix fixed_mode on boot for multiboot. Sched_mc_power_savings set to 0 instead of 2 to see how it affects wakeup.
a41 - ARM cpu topology and relevant patches. Enable multi-core scheduling. Enable maximum multi-core scheduling power savings for testing. Switch back to LZ4 ramdisk compression as Multiboot supports it now. Increase touchdemand sampling down factor since sampling rate was decreased previously.
a40 - Revert SLQB. Add latest usb host mode charging from mehrvarz's repo. Force detect/report usb as ac, no apparent benefit. Enabled a config SVIPC or something... I forget. Enabled rndis support from CM.
a39 - SLQB allocator. Switch back to Gzip ramdisk compression for multirom.
a38 - Fix adobe flash playback. Super fast Lz4 compressed for ramdisk and kernel. Arm unaligned efficient memory access. Some misc. wifi and network patches. Many other changes. No guarantees.
__________________________________________________
Downloads:
Alphas 5.1 -
a77 - https://www.androidfilehost.com/?fid=23991606952601904
a76 (CM12.1) - https://www.androidfilehost.com/?fid=23991606952601166
Click to show downloads for older versions of Android
Alphas 5.1 -
a75 - https://www.androidfilehost.com/?fid=95916177934553111
Alphas 5.0 -
a74 - https://www.androidfilehost.com/?fid=95916177934528566
a73 - https://www.androidfilehost.com/?fid=95784891001616369
Alphas 4.4 -
a69 - http://d-h.st/kI7
a68 - http://d-h.st/gPV
a67 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a67.zip
a66 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a66.zip
a65 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a65.zip
a64 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a64.zip
Milestone 4.3.x Releases -
mr2 (4.3.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr2.zip
Alphas 4.3 (post mr2) -
a63.1 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.1.zip
a63 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.zip
a62 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a62.zip
Alphas 4.3 (pre mr2) -
a61 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a61.zip
a60 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a60.zip
a59 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a59.zip
a58 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a58.zip
a57 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a57.zip
Milestone 4.2.x Releases -
mr1 (4.2.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr1.zip
Alphas 4.2.x -
a56 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a56.zip
a55 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a55.zip
a54 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a54.zip
a53 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a53.zip
a52 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a52.zip
__________________________________________________
Legacy downloads available at http://goo.im/devs/Metallice/Nexus7
THIS POST/GLOSSARY NO LONGER UPDATED DUE TO TIME CONSTRAINTS
Glossary of terms:
(that one may not be as familiar with as things like CPU and GPU)
Hotplugging - the process of turning CPU cores on and off.
G core(s) - One of four ARM A9 CPU cores found in the Tegra 3 SoC
LP (core) - The ARM A9 "Low-Power" CPU core found in the Tegra 3 SoC in addition to the 4 G cores. The LP core, contrary to what many seem to believe, does not run in tandem with the 4 G cores.
Runnable Threads (hot plugging) - Limits turning on more cpu cores based on the average number of running threads
Touchdemand - A modified ondemand-based governor that I designed and configured to better suit the Tegra 3 and android based on my observations
Variant -
Scheduler -
Other things
FAQ:
What's the difference between the mr(#) version/download and the a(#) version/download? Which should i download? What do these acronyms mean/stand for?
The mr# (ex. mr1) stands for milestone release number #. The milestone builds are the stable, bug-free, and thoroughly, extensively, and expansively tested builds of m-kernel.
The a# (ex. a38) stands for alpha build number #. The alpha builds listed under downloads are all of the alpha builds after the latest milestone build listed in reverse chronological and "morphological" (? FIX) order. It is the continuation of the "alpha branch" of m-kernel, and is basically the latest milestone with a ton of patches, fixes, and changes that are completely UNTESTED by anyone but me. The number and substantiality of changes since the latest milestone obviously vary and also depends on the number of alpha builds since the latest milestone release. An alpha build isn't guaranteed to be stable, working, and bug-free. They are testing builds leading up to the next milestone
Do you recommend setting the maximum number of cores to 2?
I don't necessarily recommend everyone do this, for it really comes down to personal preference. However, limiting the maximum cores to two is a very simple change to make that will slightly improve battery, with little to no impact on performance. Android 4.x is highly optimized for dual-core processing. There is no part of the Android 4.x OS that needs more than 2 cores for a smooth experience, and likewise there are few to no android applications that need 2 cores.
For the most part, the 3rd and 4th g cores are only activated during time sensitive actions such as opening an app for the first time (i.e. not previously opened and cached in RAM) and during screen rotation. These are short lived operations meaning those 3rd and 4th g cores are quickly turned off afterwards. In essence a small hit to battery life for even smaller benefits.
Why won't my minimum frequency go below 340MHz?!?
As long as you don't use system tuner, the minimum frequency does go below 340MHz. The minimum frequency is temporarily raised to 340MHz during an audio event to prevent audio playback problems when using ondemand and similar governors. The minimum frequency returns to the previous value afterwards. Some apps may show the minimum frequency as 340MHz because clicking the app to open it created a sound causing the minimum to temporarily rise. The app does not change when the minimum frequency goes back to its previous value.
Why can't over clock the GPU as high as I can on other kernels!?!
You can. You have to raise the voltage for the top GPU slot. Other kernels do this automatically and to fixed values. The amount necessary depends on the GPU frequency you are trying to run and your device. No devices are alike and the voltage necessary at whatever frequency will vary considerably from device to devices. Be aware that having to overvolt to run a certain frequency may mean suggest that you shouldn't run that frequency anyway. Raising the GPU frequency and voltage has risks to consider
What is this tegra 3 "variant" or whatever? How do I find it? What does it meeeeaaaannnn??!!?
You can find this info in /sys/kernel/debug/t3_variant
In the stock kernel/source, each device sku is recognized and assigned four ID values. For the CPU there is a primary "cpu speedo id" and a secondary "cpu process id". For the SOC, or core (think LP core, RAM, GPU, etc), there is a primary "soc speedo id" and a secondary "soc process id."
Each "pair" of ids is used to choose the respective voltage tables for the components they represent. I'm going to ignore the soc/core ids as they aren't relevant to my point and are the same for all our devices.
The CPU voltage tables are represented by ( cpu_speedo_id # , cpu_process_id #). The voltage tables that share the same first number, the cpu_speedo_id, all end with the same MHz value. To make things simple, Tegra uses the maximum frequency in the voltage table to determine the maximum frequency. All of our Nexus 7 Tegra 3s share the same cpu_speed_id, corresponding to a maximum frequency of 1.3GHz.
The second number, the cpu_process_id, differs between all of our N7 T3's. Faux123 and everyone refers to value as our "variant." This value, cpu_process_id determines the voltages for each frequency in the table. For each increase in cpu_process_id, the RANGE of voltages for the voltage table is compressed by 25mV (i.e. the voltage for the top frequency is decreased by 25mV while the bottom stays at 800mV and the middle frequency voltages are adjusted accordingly).
Therefore, in a direct sense, the cpu_process_id, or "variant", HAS NOTHING TO DO WITH CPU FREQUENCY. I'll repeat this. YOUR CPU_PROCESS_ID OR VARIANT HAS NO DIRECT CONNECTION TO THE MAXIMUM FREQUENCY CAPABILITIES OF YOUR CHIP. Variant/cpu_process_id refers to the voltage tolerance of your cpu. While there may be correlation or secondary connection to the maximum frequency capabilities of your chip, there is not direct connection. Additionally, cpu_process_id HAS NOTHING TO DO WITH YOUR SOC/CORE AT ALL, WHICH INCLUDES YOUR GPU/LP/RAM. A high cpu_process_id tells you nothing about your core and how high you can clock your GPU.
TL;DR - Variant, or more accurately cpu_process_id, refers to voltage tolerance, and has no direct connection to the max frequency abilities of your chip, and definitely has absolutely no relationship to your core/GPU.
To do:
Core voltages quirks.
Max freq delay necessity.
Why doesn't the kernel come with recommended settings?
One more
Re: [Kernel[3G+Wifi] M-Kernel - mr1
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Re: [Kernel[3G+Wifi] M-Kernel - mr1
azoller1 said:
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
tdizzle404 said:
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
azoller1 said:
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
Says who? Me? Where?
No of course that's not true. GPU overclock can have benefits. Minimal due to RAM bottlenecking, but it will still marginally imrprove FPS in some cases.
I love your work metallica, we really appreciate it
I remember you made 5(+) different versions just because for 2 people having wifi issues...
You really spend a lot of time at this and this is a great kernel.
Thanks!
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Metallice said:
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Click to expand...
Click to collapse
No joke here ive had decent results with your kernel I'm just commenting on the update
Sent from my SGH-T999 using xda app-developers app
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Nothing to say at the moment but gotta post in it so I get subscribed. Keep up the good work!
I had just posted in the original M-kernel thread and couldnt edit my last post (probably cuz its being moved) . I was unable to set cpu max core to 4 w/o system freezing up. I just upgraded to mr1 and it shows 4 cores active and no freeze ups so far. I will leave everything to stock for now.
Cool you finally moved to "original" forum, makes it alot easier for me to navigate since I am usually in this forum anyways..
thxs
d
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Hi, you just need to increase the GPU voltage a little bit before you overclock it to 520mhz, hope that helps
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Maybe you should try reading the FAQ :/
Sent from my Nexus 7 using Tapatalk HD
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Congrats my friend. What a journey!
How,s it feel to be in the big leagues
Edit: mr1 flashed. Keeping it default for now. Seems very smooth. Another excellent kernel. Thank you for everything.
Cheers, FReaKRaNT
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
thanks for the hard work the kernel works great and the FAQ was very helpful.
Sent from my Nexus 7 using Tapatalk 2
Απ: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Guys does flash working for u without any problems?
Edit:I'm on Francos kernel now. I just flash this kernel without wipe cache and dalvkin?
Sent from my Nexus 7 using Tapatalk HD
Cool you're in Original Dev now. Congrats Metallice.
Downloading mr1 now. :good:
Hi Folks!
Here i present you Arsenic Kernel. Based on close to AOSP - Slim Kernel, Thanks to @Martinusbe for a perfect and stable base.
Started this project for unofficial builds of ROMS with keeping performance in mind without compromising on battery backup. It was supposed to be included in my personal builds of roms but some users requested to release it for other roms so here it is with anykernel method.
zip doesnt offer any module changes and doesnt mess with the ramdisk so you can feel free to dirty flash it over prebuilt kernel or Arsenic's previous versions(Dont forget to clear data of kernel adiutor or anyother kernel control app you're using before).
Keeping op short and simple and with keeping New users in mind, here is a brief description about kernel:
Features:
Supports all AOSP/CM based roms except OOS and OldDroid's AOSP.
Supports Sultanized roms.
Supports Both Android 6.0.x and 7.x.x
Built with Latest GCC 4.9 toolchain from Google.
Device and target flags enhancements and improvements, etc.
Kernel compressed with XZ.
Upstream CAF fixes and changes.
USB Fast Charge.
Switched to -O2 Optimization level.
Adreno idler.
Krait C-states customizations.
ExFat and F2FS support.
Disabled Lots of useless Debuggings and Redundant Code.
New Governors and I/O Schedulers.
Optimized sfck compression.
Various Upstream backports.
SOC Driver Tuneables.
Enabled Arch Power.
Optimized RWSEM Algorithm.
FiiO USB DAC driver for better input detection
Options to disable various wakelocks.(Use them wisely!)
TCP Congestion algos (like westwood,cubic etc).
CPU Input Boost.
Voltage Control.
Various under the hood Battery and performance improvement patches(Advance users can look at my git, each commit is there with proper explaination).
Stability and Battery backup at its Peak!
Available Govs: conservative, impulse, interactive, ondemand, performance, powersave, smartmax, userspace, wheatley, yankactive, zzmoove.
Available I/O Scheds: row, bfq, fiops, noop, cfq, ZEN and Tripndroid.
Keep an eye on the changelog for more/newly add features as this list wont be updated regularly so either have a look on Changelog or just flash Arsenic and explore yourself..!
FROM R24, ONLY NEW MM BOOTLOADER WILL BE SUPPORTED!
MAKE SURE YOU ARE RUNNING A ROM WITH NEW MM BOOTLOADER FOR R24+
if you are still running roms with old bootloader then flash R23..!
Follow THIS GUIDE to Upgrade Bootloader for future support.
From R46, Builds are divided according to the gesture implementation of the ROM. READ THIS before downloading/flashing the builds!
Download links: https://www.arsenic-kernel.download
Mirror (AFH) : https://www.androidfilehost.com/?w=files&flid=82234
(Flash correct build depending on the ROM you are using)
For OOS Compatible Build : Head over to THIS THREAD
Keep in mind:
You can dirty flash it over prebuilt kernel of your rom or any previous version of Arsenic but its always prefered to flash stock kernel or dirty flash your rom if you are already running a custom kernel to avoid any conflicts or problems.
Compatible with both AOSP(Except OldDroid's AOSP) and CM Roms BASED ON Android 6.0 and 7.X
Bugs and issues:
Report if you find any.
Special Thanks and Credits to (in NO specific order):
@Krustak
@Martinusbe
@hurtsky
@Joshwin Aranha
@sultanxda
@eng.stk
@Lord Boeffla
@franciscofranco
@ZaneZam
@Exodusche
@nikowfreak
XDA:DevDB Information
[AOSP/CM] Arsenic Kernel , Kernel for the OnePlus X
Contributors
Nitzz
Source Code: https://github.com/CheckYourScreen/Arsenic.Kernel
Kernel Special Features: Battery backup (at its best) | Performance (30-40% more than aosp/stock kernel "atleast") | Stability - (what else do you expect from a kernel...?)
Version Information
Status: Stable
Current Stable Version: R31
Stable Release Date: 2016-07-20
Created 2016-07-19
Last Updated 2017-05-07
Changelogs:
R46 (06/05/2017) - (Separate build for lineage available from this release)
Merged Security Patches (ranging from 2014-2017)
REDUCED BOOT TIME DRASTICALLY!!! (Boots hell lot faster than any old builds)
Disabled Kernel Panic - Device will simply reboot instead of throwing White LED of Death.
Fixed VPN / L2TP kernel panic issue
Reduced Load Avg.
Merged/Updated Wlan prima driver upto latest patches from CAF
Fixed and Switched to Non Debug build of Wlan driver
Reduced PowerHAL related Log Spam
Disabled Entropy contributions for non rotational devices
optimized input count calculations
Reduced kernel and zip size.
Reduced kmsg and demsg log spam
Increase the buffer-head per-CPU LRU size
Removed CC wrapper
Replaced EXT2 and EXT3 drivers with EXT4 in kernel to reduce size without funtionality loss
Stipped debugging leftovers from modules
Compiling Sensitive modules with -Os
Fixed Audio Leak Issues (Infamous Porn bug from OP3 forum)
Removed rejected files
Updated Busybox
Optimized deadline io sched.
disabled kernel audit logs
Fixed various Null Pointer Dereferences
Fixed null pointer dereference in Fast Charging Driver
Reduced Network latencies
disabled slice idle for BFQ and CFQ
Removed kernel panic from bam_dmux
Fixed various memory leaks
Fixed various spin lock-ups
limited rate buffer msgs in camera driver
Merged/Updated latest F2FS upstream patches
Fixed F2FS default idle interval
Enabled Diag support - Network Signal Guru App Support
Nuked unwanted driver modules
Enabled NTFS R/W
Removed Timer Stats config
Reduced thermal related log spam
Disabled unwanted SCSI support configs
Disabled register dumps
USB related fixes
Added Nightmare Governor
Tuned Impulse Governor
Video buffer fixes and improvements
Fixed entropy depletion issue - generated entropy faster now
/Proc related fd permission fixes
MErged/Updated EXT4 Upstream patches
Fixed password mount issus on cifs
Prevent futex attaching to kernel threads
Blocked Netlink wakelock
Disabled all wakelocks out of the box
updated revision check for newer EMMC
Optimized ZEN I/O sched - upstreamed to V2
ZEN: set fifo batch to 16 to reduce overload on EMMC and CPU
Resolved stack corruption issues
Lineage specific separate build - switched to new gesture implementation
And more stuff which i dont remember . . . :silly:
R32 (21/12/2016) -
Fixed Tethering issues on ROMS with latest CM(trees) changes.
Minor Code Cleanup and Fixes
Old releases:
R31 (06/12/2016)-
December security patches (partial,left over patches will be merged in next release. Critical ones are merged already)
Permissive out of the box. Works on all roms now including DU (didn't hardcoded permissive so can be changed to enforcing via Kernel Adiutor but make sure your rom supports SElinux Enforcing mode-DU doesn't)
Nuked non-working GPU Govs from userspace (wont reboot when you select any broken governor)
Improved Responsiveness (literally 0 delay/latency while providing input)
Fixed lots of code errors/warnings with better indentatioin.
Nuked LP11 state of DSI lanes
Removed unwanted debuggings
Reduced resource utilizations
Fixed CVE-2015-8966
20% increase in transactions per second on memory
Reject groups/events spanning multiple hardware PMUs
No more events which causes soft lockups to prevent device entering into sleep.
R29 (28/11/2016) -
* Optimized square root algorithm.
* Rowhammer vulnerability patch
* Security Patches
* CPU Boost interval improvements
* Fix off by one vulnerabilities
* l2tp: fix oops in l2tp_eth_create() error path
* Staging: android: binder: Allow using highmem for binder buffers
* Add and Enable Modified ElementalX Governor
* Enable DNS Resolver, NFS CIFS
* msm: vidc: add ion_handle checking before mapping buffers.
* Reverted Panic Prevention Measures (for now)-should fix black screen issues for some users who faced it.
* sdcardfs: Flag files as non-mappable
* lowmemorykiller: account for unevictable pages
* Fixed uninitialized variables
* Selinux fixes
* sched/loadavg: Fix loadavg artifacts on fully idle and fully loaded systems
* net: sch_generic: Allow devices to opt-out net watchdog
* msm_rmnet_bam: Actually disable watchdog for msm_rmnet
R26 (13/11/2016) -
* Merged November Patches (i might have missed some, will be included in next release if any)
* Backports of Extra Security Patches
* bam_dmux: increase wakeup timeout
* usb: mtp: increase RX transfer length to 1M (faster mtp transfer rate, yup for real!)
* usb: Avoid spammy warning due to misbehaving Apps
* Allow ignoring system restarts and prevent kernel panic when sub system restart isn't available
* Disable alot of unwanted debuggings
* Enabled L2TP Extensions
* Nuked TV Tuners and their redundant code
* Increased Stability!
* Prevent kernel from going for a panic for any abnormal condition and fill logs instead.
* Prevent kernel panic in case of abnormal ssr being issued by the system for a reboot/shutdown process.
* Decreased Boot Time!
R25 (30/10/2016) -
* Built with Latest GCC4.9 Upstream from Google.
* random: increase read and write entropy levels
* Add and Enable USB Fast Charge
* Add and Enable ZEN and Tripndroid I/O Scheduler
* vfs: Work around NULL pointer dereference in d_path()
* dts: Reduce panel wake/sleep delays
* mdss: move to a kthread for vsync_retire_work_handler (Backport from Pixel)
* kgsl: convert some workqueues to use kthreads (Backport from Pixel)
* drivers: vidc: Enable vidc debugging
* Fix Dirty CoW Vulnerability
R24 (11/10/2016) - ( FROM THIS RELEASE ONLY NEW MM BOOTLOADER WILL BE SUPPORTED!
MAKE SURE YOU ARE RUNNING A ROM WITH NEW MM BOOTLOADER FOR R24+
if you are still running roms with old bootloader then flash R23..! )
* Added support for new mm bootloader and roms.
R23 (10/10/2016) -
* Merged October Security Patches
* Removed alot of redundant code and unused drivers
* Disabled unecessary Debugging(s)
* PM / tracing: remove deprecated power trace API
* config: disable swap
* Update-binary: Remove scanning for deprecated libs
* soc: qcom: bam_dmux: Add and Enable fast-shutdown flag
* cpufreq: impulse: Do not consider min freq change as boost
* mm: set vm_swappiness to 0
* tcp_output: set initial TCP window size to 64K (speed improvement)
* wakeup: add toggle for msm_hsic_host wakelock
* Bluetooth: Remove unused hci_le_ltk_reply()
* Add full compatibility check and left over files for sultanized roms support
* Makefile: remove -g0 flag to decrease boot time.
R18 (17/09/2016) -
*Add support for SULTANIZED ROM's.
*Add support for Android 7.0 based roms.
*Add support for chinese and north american oneplus X
*Merge Driver specific September security patches!
*Add code for removal of deprecated binaries and libs (mm-pp-daemon, deprecated since jellybean known to be cause of heating and batery drain issues)
*Remove Deprecated code from kernel
*Switch to -O2 optimization level.
*GCC only builds from now on, farewell Uber.
Refer to THIS Post plz.
R12 (09/09/2016) -
*UPSTREAM: ppp: take reference on channels netns
*ASoC: check for null function pointer for dummy device read/write
*BACKPORT: Bluetooth: Fix potential NULL dereference in RFCOMM bind ..
*UPSTREAM: net: Fix use after free in the recvmmsg exit path
*UPSTREAM: ppp: defer netns reference release for ppp channel
*UPSTREAM: udp: fix behavior of wrong checksums
*Bump to R11..!
*fs: ext4: disable support for fallocate FALLOC_FL_PUNCH_HOLE
*UPSTREAM: ALSA: control: Fix replacing user controls
*msm: camera: Fix memory read by adding bounds check
*BACKPORT: netfilter: x_tables: validate e->target_offset early
*UPSTREAM: netfilter: x_tables: make sure e->next_offset covers remain�
*BACKPORT: KEYS: potential uninitialized variable
*msm8974-regulator.dtsi: further reduce CPU retention voltage
*Voltage Control: regulator: adjust values for have the full control
*Voltage Control: regulator: set retention-voltage to 600mV
*mmc: core: With great features come great spam
*diag: Reduce error message frequency
*mach-msm: disable smd debug
*audit: disable log spam msgs �
*Implement almighty compiler flags �
*Revert "PM / Wakeup: Use rcu callbacks for better performance" �
*block: disable add_random
*Bump to R9..!
*defconfig: Enable Voltage Control
*Voltage Control: added voltage control for DTS based kernels
*defconfig: Enable exfat support and refractor defconfig
*arm: irq: Tone down kernel logging
*msm: camera: suppress excessive logging - boot faster
*msm: vidc: disable debug logs
*audit: Imma let you finish, but shut up �
*usb: ks_bridge: disable debugging �
*msm: mpm: disable debugging �
*selinux: just shut up �
*msm_rmnet: Kill logspam �
*input: tri-state-key: Fix sometimes not working state switching �
*input: tri-state-key: Fix direct references to HZ �
*fs: updated to exFat support version 1.2.19 �
*fs: Add exFat support version 1.2.9 (kitkat source drop) �
*fs: Add exFat support version 1.2.7 (Samsung OSRC)
R8 (21/08/2016)-
*reverted rtmutex commits to fix heating issues while using heavy apps
*cfq-iosched: fix the setting of IOPS mode on SSDs
*Revert "mm: Add notifier framework for showing memory"
*devfreq: Fix simple_ondemand crashing on startup
R7 (19/08/2016)-
*cpufreq: cpuboost: Fix Unwanted Ramp ups
*msm: vidc: Initialize kernel space stack variables
*sched: Fix memory leakage in build_sched_groups()
*soc: qcom: smd: Fix SMD packet sync loss issue
*gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low
*gpio: sysfs: fix memory leak in gpiod_export_link
*ARM: DMA: ensure that old section mappings are flushed from the TLB
*dma-contiguous: Re-order the error handling sequence
*rtmutex: Confine deadlock logic to futex
*rtmutex: Simplify rtmutex_slowtrylock()
*locking/rtmutex: Drop usage of __HAVE_ARCH_CMPXCHG
*rtmutex: Plug slow unlock race
*rtmutex: Handle deadlock detection smarter
*rtmutex: Detect changes in the pi lock chain
*rtmutex: Fix deadlock detector for real
*splice: fix racy pipe->buffers uses
*genirq: Prevent proc race against freeing of irq descriptors
*genirq: Sanitize spurious interrupt detection of threaded irqs
*genirq: Remove racy waitqueue_active check
*genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ=n
*irq: Enable all irqs unconditionally in irq_resume
*genirq: Fix can_request_irq() for IRQs without an action
*genirq: Avoid deadlock in spurious handling
*percpu: free percpu allocation info for uniprocessor system
*vfs: fix bad hashing of dentries
*sched/rt: Reduce rq lock contention by eliminating locking
*block: Make CFQ default to IOPS mode on SSDs
*crypto: arm/aes update NEON AES module to latest OpenSSL version
*Enable "tune krait config with cortex-a15""
*Enable pipe flag
*Switch to latest GCC 4.9
*crypto: msm: qcrypto: Fix hash crash if not last issue
*crypto: msm: qcrypto: Fix spinlock deadlock issue
*crypto: msm: remove wakeup lock in qcrypto driver
*crypto: msm: fix qcrypto driver to improve IPSec performance
*crypto: msm: qcrypto: fix crash in _qcrypto_tfm_complet
*cpufreq: interactive:call __cpufreq_driver_target() for cur frequency
*cpufreq: interactive: Exercise hispeed settings at a policy level
*Input: Propagate hardware event timestamp to evdev.
*net: validate the range we feed to iov_iter_init() in sys_sendto/sys_�
*onyx_defconfig: Enable support for FiiO USB DAC
*Don't show empty tag stats for unprivileged uids
*mm, oom: make dump_tasks public
*mm: Add notifier framework for showing memory
*slub: fix incorrect return type of get_any_partial()
*hid: Add driver for FiiO USB DAC
*PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs
*qcom-cpufreq: Remove use of device_suspended in the hotplug path
*qcom-cpufreq: Fix hotplug blocking logic
*qcom-cpufreq: Block hotplug until cpufreq is ready
*msm: rq_stats: Calculate load based on current freq limit
*ASoC: msm: qdsp6v2: Silence some noise
*prima: Add TDLS config option
*cpufreq: Return directly in __cpufreq_get if policy is NULL
*msm: kgsl: Defer adding the mem entry to a process
R6(10/8/2016)-
*Disable CONFIG_PFT as it is unsupported
*sched: Fix race in idle_balance()
*sched/idle: Avoid spurious wakeup IPIs
*msm: camera: isp: Silence IRQ status log-spam
*sched: Limit setaffinity with CPU_HOTPLUG
*cpufreq: interactive: don't boost cpu if already boosted
*msm: clock: change to arch initcall
*sched: cpu_power: enable ARCH_POWER
*vfp: change to mfloat-abi=hard and mfpu=neon-vfpv4
*cpufreq: Always allow update of user policy
*mm/slub: don't wait for high-order page allocation
*Enable Prima driver( should fix wifi issue on oos(?) , needs testing.)
*USB: fix invalid memory access in hub_activate()
*USB: dwc3: debugfs: Add boundary check in dwc3_store_ep_num()
*msm: perf: Do not allocate new hw_event if event is duplicate.
*platform: msm: Fix compile when CONFIG_PFT is not set
*cpufreq: implement cpufreq_quick_get_util()
*ashmem: fix CVE-2016-5340
*cpufreq: Notify governors when cpus are hot-[un]plugged
*cpufreq: cpuboost: Fix Multiple assignments
*mm/vmscan.c: avoid possible deadlock caused by too_many_isolated()
*mm: vmscan: fix the page state calculation in too_many_isolated
*BACKPORT: perf tools: Document the perf sysctls
*FROMLIST: security,perf: Allow further restriction of perf_event_open
*onyx_defconfig: enable SECURITY_PERF_EVENTS_RESTRICT
*Revert "Enable "tune krait config with cortex-a15""
R4(29/7/2016)-
*cpufreq: Make sure target freq is within limits
*Add and Enable KCAL v2 support.
R3(28/7/2016)-
*cortex a15 optimizations
*Add add sensor_ind wakelock toggle
*ARM: smp: Wait just 1 second for other CPU to halt
*Optimize task_sched_runtime()
*tick: Upstream fixes
*Shift to GCC Toolchain from Linaro (Much smoother and Better Battery backup as compared to linaro builds)
R2(19/7/2016)-
*Touch boost will not exceed configured max cpu freq
*Updated Defconfig.
*Shifted to XZ compression from GZIP (zip size down to 6.7mb from 10mb)
*removed waves effect patch from oem by sultan.
*removed fast idling of cpus when system is partially loaded.
*Enabled TCP congestion modules, westwood set as default.
R1(18/7/16)-
*initial release
Suggestions and FAQs
Suggested profile/settings for kernel adiutor:
Recommended Profile:
CPU max freq : 1.7ghz
CPU min freq : 300mhz
Governor : Impulse / Interactive (Impulse is the best gov. whereas Interactive is the Smoothest!)
Fast Charge : Enabled
Multicore Power Saving : Aggressive
Sync Threshold : 729mhz
Input Boost Freq : 652mhz
Thermal : Core Control enabled
Speaker Driver Leakage toggle(in soc driver tuneable): enabled
Krait C-States Settings toggles: enable all
Adreno Idler : Enabled
GPU Gov. : msm-adreno-tz
I/O scheduler : ROW with 512kb read ahead for int. and ZEN with 512kb for external
Wake locks toggles: DISABLE ALL (this will prevent wifi and bluetooth wakelocks if your device is suffering from any-check battery graph if you get wifi on usage even after being turned off) (turn them on if you face any issue, you wont actually )
TCP Cong Algo : Westwood
Battery oriented:
CPU max freq: 1.5ghz
CPU min freq: 300mhz
governor: Impulse
Multicore Power Saving: Aggressive
Sync Threshold: 729mhz
Input Boost Freq: 652mhz
Thermal: Core Control Enabled
Speaker Driver Leakage toggle(in soc driver tuneable): enabled
Krait C-States Settings toggles: enable all
Adreno Idler : Enabled
GPU Gov. : msm-adreno-tz
I/O sched: ROW with 512kb read ahead for int. and ROW with 384 kb for external
Wake locks toggles: DISABLE ALL (this will prevent wifi and bluetooth wakelocks if your device is suffering from any-check battery graph if you get wifi on usage even after being turned off) (turn them on if you face any issue, you wont though )
TCP Cong Algo- Westwood
Insane Battery Profile:
CPU max freq : 1ghz
CPU min freq : 300mhz
Governor : Impulse
Fast Charge : Enabled
Multicore Power Saving : Aggressive
Sync Threshold : 652mhz
Input Boost Freq : 422mhz
Thermal : Core Control enabled
CPU Voltage : -10 (Global Offset)
Speaker Driver Leakage toggle(in soc driver tuneable): enabled
Krait C-States Settings toggles: enable all
GPU Gov. : msm-adreno-tz
Min. Freq. : 200mhz
Max. Freq. : 330mhz
Adreno Idler : Enabled
I/O sched : FIOPS with 512kb read ahead for int. and ROW with 384 kb for external
Wake locks toggles: DISABLE ALL (this will prevent wifi and bluetooth wakelocks if your device is suffering from any-check battery graph if you get wifi on usage even after being turned off) (turn them on if you face any issue, you wont actually )
TCP Cong Algo : Westwood
---------------------------------------
Default profile for zzmoove gov. is set to 0 by default, change it to your desired profile, more info about profiles are HERE.
I prefer ybat (profile_number=2).
---------------------------------------
Since All of these settings are not visible in official Kernel Adiutor, kindly use Kernel Adiutor Mod from HERE
F.A.Q's :
Can you add [this] and [that] feature to arsenic?
Something I pride myself with this kernel is that it does not have a bunch of random, useless features or patches mashed into it. Everything put into this kernel is thought out well and tested. I see a lot of works being made popular because it has [this] and [that] feature when really, it's nothing revolutionary(atleast to me). As a matter of fact, most things added to any kernel will not make it 5x better than any other kernel. Most of the time, simple is better; and in this case it definitely is!
Any plans of upstreaming the linux version?
No, and i wont. Though i have test builds ready but they wont make up to the release version. Upstreaming linux version doesnt make much difference infact it does degrade Arsenic's performance. Reason why i'm against it is that I've removed almost all possible useless redundant code and debugging present in it to improve kernel in all aspects, upstreaming will not only add alot of redundant code but will also add debugging functions for those redundant code! Which will not only increase kernel's size but will heavily impact on kernel's performance, battery backup and stability. Currently 3.4.0 is "THE" most stable branch and i'd like to keep it.
Why MPDecision? Why not remove the hell outta it?
You want me to remove something which was developed by some of the finest engineers of this world and is currently being shipped on almost all android devices..? Dont you think there would have been a reason why Google chose MPDecision over anyother hotplug.
What most of the users arent aware of is that, MPDecision works best with the default thermal solution, all it needs is a little touch..
As far as adding an additional hotplug, m still thinking about it.
Why so rude?
Not rude, Determined. Everything i do has a reason behind it. And I do sometimes accept feature request if they seems to be worthy.
Actually proper credits for my version of AnyKernel belong to @Lord Boeffla
RJDTWO said:
Actually proper credits for my version of AnyKernel belong to @Lord Boeffla
---------- Post added at 09:33 PM ---------- Previous post was at 09:29 PM ----------
May I ask why you have disabled a few compilation optimizations? It seems counter intuitive LOL. I could have a look to see why (if) they produce errors when you compile
---------- Post added at 09:33 PM ---------- Previous post was at 09:33 PM ----------
May I ask why you have disabled a few compilation optimizations? It seems counter intuitive LOL. I could have a look to see why (if) they produce errors when you compile
Click to expand...
Click to collapse
sure, plz reply in pm or ping on telegram if you use it
Two new kernels in the past few days?? Cool! I will be trying this one out as well! I'll install tonight and it'll get a test run of my work day tomorrow.
Great job. I
Oh and in your profile recommendation, DO NOT use zzmoove with agressive power saving as it has conflicts with its got plug and generally isn't a good thing in general. Oh and for read ahead, use 128 for internal and 1024 for 16gb external, 2048 for 32 and up.
128 won't harm performance at all and should increase stability.
RJDTWO said:
Oh and in your profile recommendation, DO NOT use zzmoove with agressive power saving as it has conflicts with its got plug and generally isn't a good thing in general. Oh and for read ahead, use 128 for internal and 1024 for 16gb external, 2048 for 32 and up.
128 won't harm performance at all and should increase stability.
Click to expand...
Click to collapse
No conflicts so far with Mpdecision so aggressive is a go for me. Read ahead is higher for internal as its much faster than external memory cards, it depends on class/speed of memory card. Since internal is much faster so it can use upto 1024 and for ext 384 is recommended. Do shed a light if m wrong.
Most users doesnt use a class 10 ext. Memory card so read ahead for ext shouldnt exceed 384 imo.
Nitzz said:
No conflicts so far with Mpdecision so aggressive is a go for me. Read ahead is higher for internal as its much faster than external memory cards, it depends on class/speed of memory card. Since internal is much faster so it can use upto 1024 and for ext 384 is recommended. Do shed a light if m wrong.
Most users doesnt use a class 10 ext. Memory card so read ahead for ext shouldnt exceed 384 imo.
Click to expand...
Click to collapse
Aggressive power saving isn't referring to mpdecision. It overrides zzmooves hotplug driver. As for read ahead, its actually vice versa. You don't need a higher value for internal storage because as you mentioned, its much faster. For every 8gb of external data the rule of thumb is generally a 512 bump.
Sorry I haven't had time to take a look at TG again...
RJDTWO said:
Aggressive power saving isn't referring to mpdecision. It overrides zzmooves hotplug driver. As for read ahead, its actually vice versa. You don't need a higher value for internal storage because as you mentioned, its much faster. For every 8gb of external data the rule of thumb is generally a 512 bump.
Sorry I haven't had time to take a look at TG again...
Click to expand...
Click to collapse
Zzmoove's hotplug driver..? Shed some more light on it plz cz kernel isnt shipped with an option to change hotplug, mpdecision is working good so far with zzmoove and aggressive power saving mode.
RJDTWO said:
---------- Post added at 09:33 PM ---------- Previous post was at 09:29 PM ----------
[/COLOR]May I ask why you have disabled a few compilation optimizations? It seems counter intuitive LOL. I could have a look to see why (if) they produce errors when you compile
---------- Post added at 09:33 PM ---------- Previous post was at 09:33 PM ----------
May I ask why you have disabled a few compilation optimizations? It seems counter intuitive LOL. I could have a look to see why (if) they produce errors when you compile
Click to expand...
Click to collapse
Kindly remove this, this might be misleading some New users as pipe isnt supported on linaro 4.9 and i already enabled cortex a15 optz, and no errors in kernel so far
Thnx
Nitzz said:
Zzmoove's hotplug driver..? Shed some more light on it plz cz kernel isnt shipped with an option to change hotplug, mpdecision is working good so far with zzmoove and aggressive power saving mode.
Click to expand...
Click to collapse
Zzmoove has a hot plug driver. Look under Alpha 0.3:
http://forum.xda-developers.com/galaxy-s3/development/info-cpu-governor-zzmoove-t2326544
Aggressive power savings overrides its ability to manipulate cores, so beforehand you either have to disable it or forget about aggressive power saving to avoid conflicts. Yes, mpdecision is a hot plug, but governors can have their own solutions too. PegasusQ has hot plugging too
---------- Post added at 11:29 AM ---------- Previous post was at 11:25 AM ----------
Nitzz said:
Kindly remove this, this might be misleading some New users as pipe isnt supported on linaro 4.9 and i already enabled cortex a15 optz, and no errors in kernel so far
Thnx
Click to expand...
Click to collapse
.... Yeah, sure...
RJDTWO said:
Zzmoove has a hot plug driver. Look under Alpha 0.3:
http://forum.xda-developers.com/galaxy-s3/development/info-cpu-governor-zzmoove-t2326544
Aggressive power savings overrides its ability to manipulate cores, so beforehand you either have to disable it or forget about aggressive power saving to avoid conflicts. Yes, mpdecision is a hot plug, but governors can have their own solutions too. PegasusQ has hot plugging too
.
Click to expand...
Click to collapse
I agree with the hotplug part but as far as i remember i cant see any option to enable zzmoove's hotplug and unless and untill mpdecision is on it wont get activated. For reference you can see boeffla's config app, it has option to change hotplug from default one to zzmoove's but in kernel adiutor its not available and unless you turn off mpdecision(which i dont recommend at all with my kernel) using power saving mode wont affect your device. M using aggressive mode with zzmoove ybat profile with mpdecision enabled and i havent faced any issue! If you dont like using multi core power saving then dont use it, simple as a pie. Its working great for me so m using
Nitzz said:
I agree with the hotplug part but as far as i remember i cant see any option to enable zzmoove's hotplug and unless and untill mpdecision is on it wont get activated. For reference you can see boeffla's config app, it has option to change hotplug from default one to zzmoove's but in kernel adiutor its not available and unless you turn off mpdecision(which i dont recommend at all with my kernel) using power saving mode wont affect your device. M using aggressive mode with zzmoove ybat profile with mpdecision enabled and i havent faced any issue! If you dont like using multi core power saving then dont use it, simple as a pie. Its working great for me so m using
Click to expand...
Click to collapse
I simply stated that it would cause conflicts... If a tree falls in the woods and nobody is there to see it then does it still make a sound?
Love the kernel great work. So much optional tuning in kernel adiutor. Comes with many governors to choose from. The suggested settings are well balanced battery, performance and zero lag.
Well, the Kernel is Solid, no complaints at all. Great work Nimit !
Attached Battery Graph for 2nd cycle.
Updated to R3..!
Updated to R3
R3(28/7/2016)-
*cortex a15 optimizations
*Add add sensor_ind wakelock toggle
*ARM: smp: Wait just 1 second for other CPU to halt
*Optimize task_sched_runtime()
*tick: Upstream fixes
*Shift to GCC Toolchain from Linaro (Much smoother and Better Battery backup as compared to linaro builds)
Recommended update!
Note: if you face a glitch in kernel adiutor regarding min. freq then plz ignore it as its just a glitch, shows current freq (on which CPU is scaling) for a sec and then will come back to the set one (300 Mhz by default). Freq scaling is normal and kernel works just fine!
The kernel is running nothing but fantastic!
Just updated to R3. Reminds me of leankernel back in the days. Smooth and stable.