[KERNEL][AOSP] ArchiKernel [20.06.14/v1.1]

  • 49 Antworten
  • Letztes Antwortdatum
Die V1.3 ist erschienen.

Changelog
ArchiKernel V1.3

- Enabled LED fading/blinking support
- Enabled haptic control on AOSP roms like CM/Omni
- Enabled voltage control of the CPU
- Enabled overclocking of the CPU to 1600Mhz
- Enabled GPU clock control and voltage interface
- Enabled touch LED control
- Updated ZZmoove to 0.9 beta3
- Enabled SELinux
- Enabled ext4 security labels # This fixes being unable to mount ext4 sd cards, reported by Senior_Limpio
- Enabled OC by default # This enables 1600 MHz by default, you can still go back to 1400 via sysfs
- Fixed CVE-2014-3153
- Fixed frequency slider in performance settings # Found i.e. in Omni
- Cleanup of ArchiKernel settings
 
Was ich aber nicht ganz verstehe, die erste Zeile des Changelogs:
- Enabled LED fading/blinking support @Moster2
Damit kann man dann also wohl auch in diesem Kernel die Geschwindigkeit und Härte des Blinken einstellen, aber wie mit welchen init.d Parametern oder, was natürlich besser wär, geht das auch mit Trickster MOD ?

Naja vielleicht probier ich es einfach mal aus in den nächsten Tagen.
 
Thread wird in den kommenden Tagen aktualisiert, bin gerade von meiner Matura-Reise heim gekommen :)
 
ArchiKernel V1.4 ist erschienen

Quelle

Download

Changelog:

ArchiKernel V1.4

- [!] ArchiKernel has been rebased on top of latest SEA2 kernel sources from Samsung.
# This means that it includes everything what Samsung included
- Added ArchiKernel-Init binary, verbose logging is now available under /data/ArchiKernel.log, mostly for me and Moster to see what's going on # Pro tip: It also shows used toolchain to compile the kernel
- ArchiKernel is now compiled using latest Linaro 4.9.1 arm-linux-gnueabihf 2014.07 toolchain -> https://github.com/JustArchi/Linaro/tree/4.9-gnueabihf
- ArchiKernel now supports and comes with STweaks # All credit to Moster2 for this
- Please note that LulzactiveQ governor is not included, so STweaks can't use it. I think that tweaking PegasusQ is more than enough to obtain what you want.
- ArchiPort version of AK is now the same as Samsung one.
- New variant of AK is now available: R4P0. This is AOSP variant which works on ROMs which include new experimental R4P0 MALI driver # All credit to Moster2
- Fixed broken root on Samsung ROMs # Thanks to Moster2
- PegasusQ is now stock governor, this is only because the fact that it's slower and consumes less battery than ZZmoove
- Deadline is now stock I/O governor
- Added dynamic fsync developed by faux123 (available to tune in STweaks)
- Added logcat and printk interfaces (available to tune in STweaks)
- Update Wi-Fi drivers to 1.141.44 (coming from N5100 kernel drop)
- More on github
- I forgot something for sure anyway
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: Urian
ArchiKernel V1.4.1 Test erschienen

Quelle und Download


Changelog:

* Version 0.9 beta4
*
* - removed 'freq_step' functionality as it never had any function in this governor! it was a left over from mialwes 'smoove' governor and also
* had no function in his governor back then!! so yeah all the 'feelings' about it's influence were placebo!
smile.gif

* - introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies
* in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end
* the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions
* - added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)
* this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export implementation
* included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling
* interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the
* tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered
* - if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu
* temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'
* so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach
* into exynos4 TMU driver trottling range)
* - if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable
* - added auto adjustment of all available frequency thresholds when scaling max limit has changed
* - improved sampling rate idle switching by making it scaling thresholds independent
* - again some code style and comment changes/fixes
*
* for this functions following new tuneables were introduced:
*
* scaling_proportional -> if enabled load-proportional frequencies will be calculated in parallel and will be used in decision for
* next freq step. after a comparison between normal system table step and proportional step the lowest of
* these two frequencies will be used for next freq step in both directions.
* (0 to disable, any value above 0 to enable)
* scaling_block_temp -> CPU temperature threshold from where governors freq 'holding' should start. if the given temperature
* (if CPU temp reading is enabled) is reached the frequency used in tuneable 'scaling_block_freq' will be forced targeted and scaling
* stays on this freq till the temperature is under the threshold again. at the same time hotplugging up
* work is blocked so in this throttling phase offline cores are staying offline even if the hotplug up
* thresholds are reached
* (0 to disable, values between 30 and 80 in °C)
* auto_adjust_freq_thresholds -> if enabled all freq thresholds used by the governor will be adjusted accordingly to the new scaling
* max policy. in particular the thresholds will be increased/decreased by the actual changed max freq step
* if that change will undercut/exceed the actual min/max freq policy it will stop at the max possible
* frequency step before undercutting/exceeding min/max freq policy
* (0 to disable, any value above 0 to enable)
 
1.5 raus
 
Guten Abend zusammen,

ich benutze den Archi-Kernel seit geraumer Zeit schon in Zusammenhang mit Slimkat 8.0.
Ich habe schon 2 Profile erstellt (eins Balanced, nahe dem Standart) und ein Battery. Jedoch "traue" ich mich nicht wirklich, in den fortgeschrittenen Einstellungen sehr viel runter zu takten, also für das Battery Profil (es soll wirklich sehr Akkusparend sein auf Kosten der Leistung, so dass das der Kernel wirklich nur noch das nötigste am laufen hält).
Hat jemand so ein ähnliches, sehr aggressives akkusparendes Profil erstellt und wäre so freundlich, mir seine Einstellungen und Werte hier zu nennen?

Besten Dank im Voraus und noch einen schönen Abend :)
 
Ist der kernel für namelessrom 5.0.2?
Wenn ja welcher kernel ist besser damit, stock oder der?
Und hat der undervolting? :D
 
Hast Du die richtige AOSP Kernel Version geflasht? CM11 benötigt aufgrund der älteren Mali blobs den AOSP-OLD Kernel, wenn Du jenen mit den neuen blobs geflasht hast, treten mit Sicherheit Grafikfehler auf oder das Display bleibt gleich schwarz.
 

Ähnliche Themen

Oebbler
Antworten
9
Aufrufe
5.707
SiggiP
S
Oebbler
Antworten
37
Aufrufe
14.637
Borkse
B
Zurück
Oben Unten