Samsung Galaxy S3 - Perseus Kernel

[The-Bad 3]

eine kannal frage wäre da noch, wozu die ganzen kannele, hab gelesen das mansche mehr energy einsparen sollen und was sollen die dannnoch könn, und wälscher wäre dann ideal für meine bedürfnise?

[chris264 5.155]

Das Problem ist das jeder Kernel bei jedem unterschiedlich läuft. Dh bei dir kann der Perseus super laufen und bei mir schlecht aber umgedreht genauso möglich.

Deswegen kann man bei den Kernels immer nur testen.

Deswegen kann ich dir jetzt nicht sagen, nimm den Kernel der verbraucht am wenigtens.

Lg

[The-Bad 3]

und wie würde ich denn orginalen kannal wieder bekommen wenn er garnicht gehn sollte?

[chris264 5.155]

Dann würde ich den Boeffla Kernel testen

Weil der läuft 1000% in einer Konfi auf deinem S3. Glaub mir.

Aber den originalen Kernel kriegst du zb durch flashen der Firmware, aber dann wäre Root erstmal wieder weg.

Lg

[The-Bad 3]

unter geräte info / kannel steht bei mir:

kannal version

3.0.31-566833

se.infra@SEP-64#1

SMP PREEMPT Mon Dce 10 17:04:26 KST

2012

dazu wofür steht das basisband version & buildnr.?

[rsspeed 45]

Update

• Master profile is correctly calibrated.

Perseus-alpha33.2-i9300.tar

Perseus-alpha33.2-i9300-CWM.zip

[chris264 5.155]

UPDATE

33.3:

- Fixed negative scenario

- Fixed colour temp control (base value was off and limited the slider to +-2000K)

Perseus-alpha33.3-i9300.tar

Perseus-alpha33.3-i9300-CWM.zip

[peetem 0]

Hallo Gemeinde

Gibts irgendwo eine Anleitung wie das mit dem Kernel flashen vonstatten geht?

War bis vor kurzen ein Apple User und nun eigentlich ein begeisterter Samsung Galaxy S3 Besitzer und möchte damit ich das Gerät nun auch mit meiner neuen Car Vehicle Mount laden kann, eden "Kernel flashen".

In den Apple Foren gab es immer die glasklaren Anleitungen diese vermisse ich hier einwenig.

Hir steht überall nur; Du musst den Kernel flashen etc. etc. aber wie es geht kann ich nigends finden .

Hat jemeand einen Link?

Gruss

Peter

[chris264 5.155]

Ja hier https://www.handy-faq.de/forum/showthread.php?t=250283 musst dann eben nur die Odin Version nehmen also die Tar Datei von den Kernel und nicht die CWM Variante.

Lg

Gesendet mit Jelly Bam Android 4.2.2 vom S3

[Armin_T 409]

Hiwr findest du auch genug Anleitungen

Am besten erstmal anschauen im s3 forum da stehen die meisten direkt zu anfang ujd bei fast jedem thread steht eine

Gesendet von meinem GT-I9300

[chris264 5.155]

UPDATE

[Kernel][22/03] Perseus

Features / changelist:

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

Enabled ZCache, XVmalloc, Cleancache, and ZRam for people who want to use it.

Applied a requested patch which allows PCs to be booted off from the phone storage.

Perseus-alpha34-i9300.tar

Perseus-alpha34-i9300-CWM.zip

DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.

[chris264 5.155]

Update

Version 34.3:

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.

Defaults are still unchanged at 200mB/90% until further notice.

Quelle

https://forum.xda-developers.com/showpost.php?p=39640679&postcount=5193

Downloadlink für die CWM.zip

https://forum.xda-developers.com/attachment.php?attachmentid=1838660&d=1364415258

Lg

Gesendet mit Jelly Bam Android 4.2.2 vom S3

[maddes1402 1.305]

Die neue Version ist spitze. Ich habe sie zur Zeit auf der maddes v30, zram ausgeschaltet, den Rest Standard und alles ist sehr smooth und akkusparend

Gesendet von meinem GT-I9300 mit Tapatalk 2

[chris264 5.155]

Morgen Maddes,

das hört man gerne wenn ein Kernel gut läuft, hast du mal mit den Farbeinstellungen rum gespielt?

Lg

[maddes1402 1.305]

Dazu habe ich leider noch keine Zeit gefunden. Persönlich stehe ich auf diese etwas unrealistischen, satten Farben der Amoled Displays. Standardmäßig ist die Farbeinstellung wohl eher etwas realistischer eingestellt bei dem Kernel. Ich habe in den normalen Displayeinstellungen den Bildschirmmodus einfach nur auf dynamisch gestellt.

Was mir auch noch gerade auffällt, ist, dass das Handy nun auch mit dem Standard Ladegerät viel schneller lädt. Mit dem Boeffla und dem Standardkabel brauchte es bei mir bis zu 8 Stunden und ladete nur mit durchschnittlich 200mA auf.

Gruß maddes

bearbeitet March 31, 2013 von maddes1402

[ogbartelt 40]

Dann hab ich mir das nicht eingebildet das das handy langsamer lädt mit dem boeffla kernel dachte schon ich werde alt oder blöde. Aber wenn du sagst er läuft geschmeidig und akku schonend dann muss ich ihn doch mal flashen. Danke für die Aussage maddes

Gesendet von meinem GT-I9300 mit Tapatalk 2

[chris264 5.155]

UPDATE!!!

[Kernel][06/04] Perseus

Features / changelist:

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.

Perseus-alpha35-i9300.tar

Perseus-alpha35-i9300-CWM.zip

[chris264 5.155]

UPDATE!!

[Kernel][22/04] Perseus

Features / changelist:

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 is 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 raising 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).

You can read out you 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.

Download Perseus Kernel 36 Cwm Variante

Download Perseus Kernel 36 Odin Variante

[chris264 5.155]

Update!!!

[Kernel][26/04] Perseus

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.3-i9300.tar

Perseus-alpha36.3-i9300-CWM.zip