Samsung Galaxy Note II - [N7100 N7105] Perseus

[andreas02 1.338]

Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.

This is a direct port of my kernel on the Galaxy S3. I am using the same source base for both devices for the kernel, just with a different configuration file. The kernel images are not interoperable! I will continue development in parallel for both devices, with the Note 2 having maybe some delay due to third party testing.

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.

Advanced users are welcome to modify the scaling mechanisms of PegasusQ and I advise SetCPU 3 for this, most of the behaviour that one should configure is configurable via that application. CPU undervolting is compatible with most undervolting applications. For all other things, one should use scripts.

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), i9300 (S3) and N7105 (Note 2 LTE) and shares the same base-source. I solely own a I9300 Galaxy S3, but since all the phones derive from the same Midas platform, I merely adapt the differences without having the other devices.

Features / Aktuelle changelist:

Version: 36.3

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.

Version: 36.2:

- User-app notifications: Fixed colour scaling on the LED notifications, and also added brightness scaling. User apps will now also enter lowpower/high-power modes depending on outside brightness, just like the stock notification behaviour. Fixed the erroneous blinking behaviour for user-apps.

- Fixed digital brightness reduction for EA8061 users

- EA8061 Note 2 owners: 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.

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 lower 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 higher 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).

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.

Unaligned memory access throughout the kernel when applicable.

Switched over to GCC 4.7.3 Linaro toolchain for compiling.

Changelog der vorherigen Versionen findet man im

ORIGINALTHREAD

Credit and thanks:

gokhanmoral, netarchy, and anybody credited in the commits.

Thanks to sswagonman for the initial testing.

This isn't an AOSP kernel.

Please choose the right version between N7100 (International 3G) and N7105 (International LTE).

The kernels are labelled for their respective target device. You have no excuse in messing this up.

Download all Perseus Versionen 71xx

###########################################

Installation:

Download des Kernels (.zip) und speichern auf eurem Note II.

Root und CWM Recovery mit Odin wie hier beschrieben installieren.

Danach in den CWM Recovery booten (Volume up - Powerknopf - Homebutton gleichzeitig drücken).

Empfehlung: Ein Backup des aktuellen ROMs machen und dieses wenn möglich (zur Sicherheit) auf dem PC speichern.

Danach den Kernel von eurem Note II installieren.

Rebooten

Hinweis: Die xxx.tar lässt sich natürlich über PCOdin bzw. MobileOdin flashen.

ACHTUNG: Diese Anleitung soll euch lediglich als Hilfestellung dienen. Jeder Systemeingriff am Gerät, wie zB durch Flashen oder Rooten birgt Gefahren in sich. Es wird in diesem Zusammenhang ausdrücklich darauf hingewiesen, dass weder handy-faq noch ich Verantwortung für Schäden, die durch Flashen nach dieser Anleitung entstanden sind, übernehmen. Jeder muss selber wissen was er tut und sich zutraut. Weiters wird darauf hingewiesen, dass durch Flashen oder Rooten Garantieansprüche gegenüber dem Hersteller oder Anbieter erlöschen oder sich auch ein Vertragsbruch mit dem Provider ergeben könnte. Daher werden Systemeingriffe immer in eurer Eigenverantwortung durchgeführt.

LG

Andreas

bearbeitet April 29, 2013 von andreas02

[andreas02 1.338]

Update Perseus alpha27 (02/12):

Changelog:

Sources updated with various updates from N8000u1 base. Included are following important changes;

Wacom drivers, Sensorhub firmwares, touchscreen updated.

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.

Removed the sharpness modifications due to demand.

LTE devices only: Disabled CPU frequency clock while connected to a cable.

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.

Audio enhancements (Gokhan Moral's port of Voodoo sound) re-enabled. Call-detection is currently broken (Effects are applied during call while they shouldn't be), but this fixes the effects not being applied otherwise. (Thanks to sjkoon for finally debugging that)

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.

Just an explanation in regard how uci.sh (Script framework on which STweaks is built) works: The settings displayed in STweaks are the defaults with which the kernel boots the first time and are saved as a profile. The saved profile settings are applied before anything else on boot, including init.d. The values displayed in STweaks do not correspond to live kernel values, but the values saved in the profile. As such if there is another app or script setting something after STweaks, it will not represent those changes. Please be aware of that. I included labels with the default values for almost all values, they are dynamically generated.

*Note: Currently the labeled default GPU voltages do not correspond the real default ones as the ASV voltages get applied after I'm reading them out for the interface on early boot. I'll fix this later on.

Post 1 ergänzt.

LG

Andreas

[Smokey Skull 19]

download fürs 7100 nich verfügbar?

[andreas02 1.338]

Bitte einfach mal in den Originalthread gehen....hat mir die Links zerhauhen

Dort sind diese zu finden....

LG

Andreas

Gesendet von meinem GT-N8000 mit Tapatalk 2

[Smokey Skull 19]

wie kann ich stweaks reseten damit der kernel wieder mit seinen stoc einstellungen bootet wenn ich was zu viel verstellt hab und das handy ni mehr hoch fährt?

bearbeitet December 5, 2012 von Smokey Skull

[andreas02 1.338]

Links gefixt und das Update auf v27.5 eingepflegt.

LG

Andreas

[Smokey Skull 19]

changelog von 27.4 auf 27.5?

[andreas02 1.338]

Einen Changelog gibt es m.W. nur bei Änderung der Versionen von z.B. v26 auf v27. Es handelt sich somit um keine gravierenden Änderungen, die z.T. im Originalthread verzeichnet werden. Um den 1. Post nicht zu "sprengen", verzichte ich darauf.

Ich versuche jedoch täglich die Änderungen (sofern es welche gibt) hier in einem Update im Post 1 zu ergänzen.

LG

Andreas

[Smokey Skull 19]

lohnt sich denn ein wechsel von 27.4 auf 27.5? da ich ja nun nicht weiß was da geändert/angepasst wurde...

[andreas02 1.338]

Da es eigentlich immer um eine Verbesserung/Fehlerbehebung handelt, sollte dies sich schon lohnen.

Hier mal ein Beispiel für den "versteckten" Changelog von 27.4 auf 27.5.

Post XDA

Ich hoffe Du verstehst, dass ich nicht die Zeit habe jedes Post zu lesen Habe ja noch ein Privatleben

LG

Andreas

[skrApy 17]

Kann von dem Kernel nur abraten, mein WLAN-Download ging danach fast garnicht mehr :/ bin auf die aktuelle RedPill gewechselt (v10) und nun tuts das Wlan auch wieder mit FullSpeed

[andreas02 1.338]

@skrApy

Danke für deinen Beitrag und deine Beteiligung hier im Forum.

Jedoch eine große Bitte.

Um den anderen Usern zu helfen ist eine Aussage, wie

Kann von dem Kernel nur abraten...

mehr als ungeeignet.

Warum?

Auf welchen weiteren validen Aussagen, außer deiner Erkenntnis mit deiner geflashten ROM, beruht diese "Warnung"?

Effektiver wäre es...ich bin momentan auf der xxxx-ROM und habe die Erfahrung gemacht, dass der Kernel bei mir "DIES und DAS" verursacht. So ist eine Zuordnung des "Fehlers" ist einfacher, da nicht jeder die gleiche Konstellation wie Du hat. Zudem ist ein persönlicher "Flashfehler" ja auch nie auszuschließen.

Danke für dein Verständnis.

LG

Andreas

[skrApy 17]

Es handelte sich um die Version Perseus.alpha 27.5-n7100-CWM.zip / Nach der Installation ging mein WLAN nur noch im Schneckentempo nach dem neuen kernel ging wieder alles flott und beim flashen kann man nicht wirklich viel falsch machen daher vermute ich das es an dem Kernel liegt.

[andreas02 1.338]

Danke für die Info. Ich denke und das ist ganz wichtig, dass Du momentan auf der GOA (gem. deiner SIG) bist.

Denn wenn Du mal wechselst....weiß ja keiner den Zusammenhang zwischen ROM und Kernel

...und beim flashen kann man nicht wirklich viel falsch machen daher vermute ich das es an dem Kernel liegt.

....Du vielleicht nicht....aber ich habe schon zuviel erlebt

Zudem kann ja auch eine unsaubere Installation des ROM´s eine Rolle spielen...auch möglich

LG

Andreas

[skrApy 17]

Ja war vielleicht auch etwas unglücklich formuliert am Anfang werde es beim nächsten Mal beachten

[andreas02 1.338]

Kein Ding...so genau wie möglich hilft ja den anderen Usern. War ja auch nur ein Hinweis, verbunden mit einem Dank für dein Engagement.

LG

Andreas

Gesendet von meinem GT-N7100 mit Tapatalk 2

[Higgins12 0]

und beim flashen kann man nicht wirklich viel falsch machen

Ömmm naja das ist relativ

Wenn mal ein Kernel/ROM/irgendwas nicht so will, ist einfach nochmal flashen auch einen versuch wert.

Hatte ich erst gestern.

Kernel geflasht (nicht Perseus) und nur Probleme. Lags, abstürze, hoher CPU Load etc pp. Kernel nochmal geflasht mit Dalvik Wipe = keine Probleme mehr.

[andreas02 1.338]

Update

Perseus alpha28 (13/12):

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.

Post 1 ergänzt

LG

Andreas

[Smokey Skull 19]

gleich mal testen. für mich der derzeit beste kernel fürs note 2 in verbindung mit der stoc-rom

[Smokey Skull 19]

in verbindung mit den profilen und tweaks ausm orginal-thread wirklich sehr nice! wenns jetz noch dualboot geben würde wie beim siyah wärs quasi perfekt. aber auch jetzt schon nah dran