Ergebnis 1 bis 20 von 100
-
Gesperrt
- 10.10.2012, 13:26
- #1
[FONT=Arial]Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.[/FONT]
Changelist 36.x:
- 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.
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).
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.
EA8061 Note 2 owners only: 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. This doesn't apply to users with S6EVER02 controllers.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
BEFORE FLASHING[FONT=Arial]:
[/FONT]- This isn't an AOSP kernel.
- This is for the Note 2 N7100 only.
-
- 10.10.2012, 19:58
- #2
Hab den Kernel mal installiert. Funktioniert alles gut soweit. Die CPU läuft testweise gerade mit bis zu 1800MHz plus UV auf das niveau von 1600MHz (1313V).Alles stabil bis jetzt.
-
Bin neu hier
- 11.10.2012, 17:38
- #3
es gibt ja bekanntlich keine blöden hier also meine.
womit steuere ich die kernelfunktion ? in den systemeinstellungen finde ich nichts unter "leistung" , es wurde kein progg mit dem kernel geflashed und mit xtweaker funktioniert es auch nicht.
grüße
shakrat
gesendet per Tapatalk via Samsung Galaxy Note 2 GT-N7100
-
Gesperrt
- 11.10.2012, 17:40
- #4
SetCPU
-
Gesperrt
- 12.10.2012, 08:46
- #5
Update 11/10 Perseus:
-
Gesperrt
- 14.10.2012, 10:55
- #6
Es gibt ne OC Version bis zu 2GHz. Jemand Interesse?
-
Gesperrt
- 15.10.2012, 14:34
- #7
Update 15/10 Perseus:
Download:
-
- 15.10.2012, 16:33
- #8
Wo ist denn das Changelog?
Kann hier:
http://forum.xda-developers.com/show....php?t=1927852
weder den Kernel noch ein Changelog finden.
-
Gesperrt
- 15.10.2012, 16:33
- #9
Ja eben ^^
-
- 15.10.2012, 16:50
- #10
Wie eben?
Bevor ich den Kernel nutze, wüsste ich schon gern was neu ist.
-
Gesperrt
- 15.10.2012, 17:08
- #11
Ja eben.. finde ich auch komisch das es nirgends steht aber keine Lust bei XDA zu fragen. Die Features sind ja in Ordnung.
-
- 15.10.2012, 18:11
- #12
Uh, ich habs, steht mitten im 9/10 Changelog
24.4 => Removed Touch Boost in exchange for the Flexrate mechanisms. See below in changelog for more information.
-
- 24.10.2012, 19:55
- #13
Neuer Kernel.
[Kernel][24/10][N7100 N7105] Perseus
Perseus.alpha25.3-N7100.tar
Perseus.alpha25.3-N7100-CWM.zip
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.
NOTE 2 USERS HAVE 533 AS MAX FREQ.
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.
-
- 15.11.2012, 07:49
- #14
Was neues vom Perseus Kernel:
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.
- Updated Sensorhub drivers from latest sources.
- Updated Wacom and E-pen drivers from latest sources.
- 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.
-
- 15.11.2012, 08:03
- #15
Kann jemand was sagen zum Unterschied zum RedPill-Kernel ? Insbesondere wie ist das Akku-Verhalten ? Weil, die Leistungssteigerung mit OC etc. sind m.E. beim Note II ohnehin völlig unnötig. Es geht also hauptsächlich um den Akku - wobei auch hier ist es ja ehrlich gesagt nur "Kosmetik" ...
-
Gesperrt
- 15.11.2012, 11:33
- #16
Bei mir ist RedPill besser als Stock also hält etwas länger. OC und UV sind unnötig
-
Fühle mich heimisch
- 17.11.2012, 23:50
- #17
Hab ihn drauf und Akku hält richtig gut hatte auch redpill drauf, aber der hier ist erste sahne
Send with Note 2
Wanam 1.5
Motomoto00 by Raubkatze
-
- 18.11.2012, 06:59
- #18
Hilfe !! Die o.g. Download-Links sind alle tot. Hat jemand eine Alternative oder kann auf DB hochladen ?
-
- 18.11.2012, 08:06
- #19
Beitrag 14 !
Gesendet von meinem GT-N7100 mit Tapatalk 2
-
- 18.11.2012, 08:46
- #20
Ähnliche Themen
-
CWM RECOVERY 6.0.1.5 for N7100 (16.10.2012)
Von spline im Forum Samsung Galaxy Note 2 Root und ROMAntworten: 82Letzter Beitrag: 24.08.2013, 19:42 -
Rooten Galaxy Note 2 N7100 - CF Autoroot
Von spline im Forum Samsung Galaxy Note 2 Root und ROMAntworten: 51Letzter Beitrag: 12.04.2013, 23:16 -
[Verkaufe] Samsung Galaxy Note 2 N7100 16GB grau
Von fly im Forum MarktplatzAntworten: 4Letzter Beitrag: 15.11.2012, 18:48 -
[Kernel] Perseus (04.09.2012)
Von spline im Forum Samsung Galaxy S3 Root und ROMAntworten: 22Letzter Beitrag: 05.09.2012, 15:45 -
Galaxy Note 2 ,,GT-N7100''
Von DakiX im Forum Samsung Galaxy Note 2Antworten: 11Letzter Beitrag: 27.07.2012, 18:06
Pixel 10 Serie mit Problemen:...