This thread is mostly for rom cookers and Kernel dev.
I just ran into a problem rebuilding a whole CM9.1 rom.
The defines that I had in my git for include/linux came from the FXP kernel.
But when trying to rebuild a whole rom, it fails because of missing definitions. I had changed/updated the includes because of one enum
enum {
MDP_RGB_565, /* RGB 565 planer */
MDP_XRGB_8888, /* RGB 888 padded */
MDP_Y_CBCR_H2V2, /* Y and CbCr, pseudo planer w/ Cb is in MSB */
MDP_ARGB_8888, /* ARGB 888 */
MDP_RGB_888, /* RGB 888 planer */
MDP_Y_CRCB_H2V2, /* Y and CrCb, pseudo planer w/ Cr is in MSB */
MDP_YCRYCB_H2V1, /* YCrYCb interleave */
MDP_Y_CRCB_H2V1, /* Y and CrCb, pseduo planer w/ Cr is in MSB */
MDP_Y_CBCR_H2V1, /* Y and CrCb, pseduo planer w/ Cr is in MSB */
MDP_RGBA_8888, /* ARGB 888 */
MDP_BGRA_8888, /* ABGR 888 */
MDP_RGBX_8888, /* RGBX 888 */
MDP_Y_CRCB_H2V2_TILE, /* Y and CrCb, pseudo planer tile */
MDP_Y_CBCR_H2V2_TILE, /* Y and CbCr, pseudo planer tile */
MDP_IMGTYPE_LIMIT,
MDP_BGR_565 = MDP_IMGTYPE2_START, /* BGR 565 planer */
MDP_FB_FORMAT, /* framebuffer format */
MDP_IMGTYPE_LIMIT2 /* Non valid image type after this enum */
};
When calling ioctl MSM_FB_BLIT the value (using the above enum) in the kernel and in the include were different and I had a WLOD.
Commit that causes my WLOD
This means that currently the includes used in the rom and the ones in the kernel are different. That's pretty bad.
I don't really know how to be sure that we fix this, update Kernel + Rom at the same time?? But since gralloc and some other stuff rely on those defines. Maybe some issues could be caused by this.
Fera and amin, have you made some changes in one of the following files?
android_pmem.h
ashmem.h
genlock.h
msm_kgsl.h
msm_mdp.h
msm_q6vdec.h
msm_q6venc.h
msm_rotator.h
scritch007 said:
Fera and amin, have you made some changes in one of the following files?
android_pmem.h
ashmem.h
genlock.h
msm_kgsl.h
msm_mdp.h
msm_q6vdec.h
msm_q6venc.h
msm_rotator.h
Click to expand...
Click to collapse
yes...and it worked partically. bud color bugs and vsync...amn many more bugs there...
+ i have slow build machine...so i cant build rom from sources..only kernel.
did you uncomment werror lines from makefile in kernel? this was causing build errors on clean sources..
++ you use arm none eabi gcc(last one) or linaro or what?
because (as cm team said) their sources are somehow incompable with linaro.respectivly rom sources..because building with linaro is already makes kind of speeding up (as i remember linaro team has made it...and shown the results of 60 fps..and..like double increase of performance) (they just modufy stock compiler)
now i'm a bit bz.. will look deeply later maybe.
FeraVolt said:
yes...and it worked partically. bud color bugs and vsync...amn many more bugs there...
+ i have slow build machine...so i cant build rom from sources..only kernel.
did you uncomment werror lines from makefile in kernel? this was causing build errors on clean sources..
++ you use arm none eabi gcc(last one) or linaro or what?
Click to expand...
Click to collapse
Ok so if you made some changes, maybe they weren't taken into account in the ROM. If you didn't update it the devices/semc/es209ra/include/linux folder.
I really don't know how to handle this issue. I've just committed new sources in my repo so that it keeps building the ROM. But I think we should backport those includes in the current kernels.
This would eventually fix some side effects issues.
I also have a really slow machine, since I work on Android only when I'm in the train (Core 2 Solo 1.4GHz) so I won't be able to rebuild roms. But I can still try to backport kernel defines after I'm done with camera changes.
I think I'll leave camcorder because I need to add some debug in various libs and I would take my journey to build one lib .
When I build the kernel I use arm-eabi-XXX provided by android system prebuilt/linux-x86/tooolchain/arm-eabi-4.4.3/bin/
For the rom I keep the default compiler used after . build/envsetup.sh && brunch es209ra
you can have a look at stock semc sources
FeraVolt said:
you can have a look at stock semc sources
Click to expand...
Click to collapse
SEMC and FXP kernel regarding this define (msm_mdp.h) are the same, but different in CM9.1 devices/semc/es209ra/include/linux.
FXP added define from msm7x30 Qualcomm definition kernel.
scritch007 said:
This thread is mostly for rom cookers and Kernel dev.
I just ran into a problem rebuilding a whole CM9.1 rom.
The defines that I had in my git for include/linux came from the FXP kernel.
But when trying to rebuild a whole rom, it fails because of missing definitions. I had changed/updated the includes because of one enum
enum {
MDP_RGB_565, /* RGB 565 planer */
MDP_XRGB_8888, /* RGB 888 padded */
MDP_Y_CBCR_H2V2, /* Y and CbCr, pseudo planer w/ Cb is in MSB */
MDP_ARGB_8888, /* ARGB 888 */
MDP_RGB_888, /* RGB 888 planer */
MDP_Y_CRCB_H2V2, /* Y and CrCb, pseudo planer w/ Cr is in MSB */
MDP_YCRYCB_H2V1, /* YCrYCb interleave */
MDP_Y_CRCB_H2V1, /* Y and CrCb, pseduo planer w/ Cr is in MSB */
MDP_Y_CBCR_H2V1, /* Y and CrCb, pseduo planer w/ Cr is in MSB */
MDP_RGBA_8888, /* ARGB 888 */
MDP_BGRA_8888, /* ABGR 888 */
MDP_RGBX_8888, /* RGBX 888 */
MDP_Y_CRCB_H2V2_TILE, /* Y and CrCb, pseudo planer tile */
MDP_Y_CBCR_H2V2_TILE, /* Y and CbCr, pseudo planer tile */
MDP_IMGTYPE_LIMIT,
MDP_BGR_565 = MDP_IMGTYPE2_START, /* BGR 565 planer */
MDP_FB_FORMAT, /* framebuffer format */
MDP_IMGTYPE_LIMIT2 /* Non valid image type after this enum */
};
When calling ioctl MSM_FB_BLIT the value (using the above enum) in the kernel and in the include were different and I had a WLOD.
Commit that causes my WLOD
This means that currently the includes used in the rom and the ones in the kernel are different. That's pretty bad.
I don't really know how to be sure that we fix this, update Kernel + Rom at the same time?? But since gralloc and some other stuff rely on those defines. Maybe some issues could be caused by this.
Fera and amin, have you made some changes in one of the following files?
android_pmem.h
ashmem.h
genlock.h
msm_kgsl.h
msm_mdp.h
msm_q6vdec.h
msm_q6venc.h
msm_rotator.h
Click to expand...
Click to collapse
what about champ's sources? the same?
you know , I kinda noticed this issue long time ago but I didn't know exact what to do about it...
I'v back ported pmem and can port others...but I suggest if we want to make a new device and kernel then let's do it based on. 32 kernel....it has many advantages if we do it...bravia engine...more performance...and the most advantage is that we can make sweat cm10 and cm11 in the further...
Amin` said:
what about champ's sources? the same?
you know , I kinda noticed this issue long time ago but I didn't know exact what to do about it...
I'v back ported pmem and can port others...but I suggest if we want to make a new device and kernel then let's do it based on. 32 kernel....it has many advantages if we do it...bravia engine...more performance...and the most advantage is that we can make sweat cm10 and cm11 in the further...
Click to expand...
Click to collapse
Champs kernel sources were pointing at Freexperia ones. I think he removed the fork.
Is it big to take the devices/semc/es209ra/include headers? or is it trivial? if it doesn't cost that much, maybe it would be good to synchronize both kernel and libcamera to build something working together. But that also means rebuild one FXP kernel (no tweaks) with new definitions.
I wouldn't mind porting kernel 2.6.32, but it's lot of work. That would have been my next challenge, but in the meantime I'll try to finish Camera properly. In know that KTG had started working on it, but no news for a while now.
@amin
Is there a github to find your sources?
scritch007 said:
Champs kernel sources were pointing at Freexperia ones. I think he removed the fork.
Is it big to take the devices/semc/es209ra/include headers? or is it trivial? if it doesn't cost that much, maybe it would be good to synchronize both kernel and libcamera to build something working together. But that also means rebuild one FXP kernel (no tweaks) with new definitions.
I wouldn't mind porting kernel 2.6.32, but it's lot of work. That would have been my next challenge, but in the meantime I'll try to finish Camera properly. In know that KTG had started working on it, but no news for a while now.
@amin
Is there a github to find your sources?
Click to expand...
Click to collapse
I'm sorry there is no github for my source...I would upload it but my laptop...I still don't have it...
about .32 kernel...it's just the camera that we need to work on...the rest is just easy but if you prefer that way so okay...no problem here...and yes it's also good to sync kernel and camera libs...I can do it if you want?
google talk?
[email protected]
scritch007 said:
Champs kernel sources were pointing at Freexperia ones. I think he removed the fork.
Is it big to take the devices/semc/es209ra/include headers? or is it trivial? if it doesn't cost that much, maybe it would be good to synchronize both kernel and libcamera to build something working together. But that also means rebuild one FXP kernel (no tweaks) with new definitions.
I wouldn't mind porting kernel 2.6.32, but it's lot of work. That would have been my next challenge, but in the meantime I'll try to finish Camera properly. In know that KTG had started working on it, but no news for a while now.
@amin
Is there a github to find your sources?
Click to expand...
Click to collapse
For many minor bugs(background color,data usage...) to get fixed you need to backport all kernel and userspace overlay releated parts,Its a good idea of porting KTG kernel even Amin tried to port it and i was busy with my college so i never worked on it.sorry Amin.
EDIT:- Without new kernel we would never have a fully working camera,camrecorder,wifi strength...etc
Amin` said:
I'm sorry there is no github for my source...I would upload it but my laptop...I still don't have it...
about .32 kernel...it's just the camera that we need to work on...the rest is just easy but if you prefer that way so okay...no problem here...and yes it's also good to sync kernel and camera libs...I can do it if you want?
google talk?
[email protected]
Click to expand...
Click to collapse
If it's not that hard let's go on 32 then .
ok for gtalk.
[email protected]
scritch007 said:
If it's not that hard let's go on 32 then .
ok for gtalk.
[email protected]
Click to expand...
Click to collapse
if you guys are going to port .32 kernel to ics.. and solve camera and kgsl issue.. then i'm in... from me comes fps uncap and many more kernel optimizations...especially...on 32 kernel there are maaany configs to play with
else..i think it's good to make common repo on git... icant upload whole sources cuz of my **** speed (30kbit/s maximum uploading speed)...but changing some files shoudnt be a problem..
anyway..
if you want...
i'm on skype
fera.volt
As I was saying to amin, I'll be finishing most of the camera feature, except camcorder. And then I'll try to work on .32. Don't know if we'll make it work. Amin will also try on his side.
But yes when we get something booting, sure we can make a common repo.
we can ask guys
spaarc , achotjan - for heilp in EGL area...
but its for now problem for me to make something without device
@all- we need more things on ics like -1) camera fix (fully wrkin)
2)hardware acceleration
3)fps uncap (fully wrkin)
4) tethering
5) freeing more ram from system
6)killing the existing bugs
Sent from my Xperia X10 using xda app-developers app
I think what we need first is that someone with the best Internet connection build a repository for X10 kernel sources and then, everyone will be able to work on it,
Scritch07 on camera, amin and fera on other parts and i think that we can build a kenel with almost all the tweaks already there as default values.
varshil said:
@all- we need more things on ics like -1) camera fix (fully wrkin)
2)hardware acceleration
3)fps uncap (fully wrkin)
4) tethering
5) freeing more ram from system
6)killing the existing bugs
Sent from my Xperia X10 using xda app-developers app
Click to expand...
Click to collapse
for some minor bugs like app's background color we need new 2d and 3d drivers that I'm almost finished Porting...
for tethering and wifi bugs we need new atheros , supplicant8 and updated wirless frimmware that I'll work on it when I finished the 2d-3d drivers...
for better ram we need new ashem and some other new stuff...
and I'm working on .32kernel too...:good:
cheers
Read all thess posts! im syoked for you guys! Idk if i could br of anyhelp... just started using linux.. but i have a good enough laptop to build roms... ! if i could help with any small **** my gtalk is [email protected]
Sent from my Xperia X10i using xda premium
Related
valexKernel
For SM-P600, AOSP/CM13-based 6.x ROMs ONLY!
Disclaimer: This kernel is for use with AOSP/CM13-based ROMs only and will not work on stock ROMs. If your device bricks, breaks or explodes as a result from flashing this kernel I am not to be held accountable for it. Flash this at your own risk.
About: This kernel focuses mainly on backports and improvements from more recent versions of Linux. As of now, major updates have been made to the scheduler, SMP, hotplug, memory management, random, the user namespace, and the ARM architecture in general. Compiled with Cortex-A15 optimized GCC 4.9.4. For full changelog, see my git repository here: https://bitbucket.org/sigma-1/valex_kernel_mm/commits/branch/valex_master
Features: My kernel contains no "gimmicky" features other than the ones that are already present in the CM13 kernel base for our device which includes voltage control, haptic intensity control and AndreiLux's sound control feature to mention a few. Again, my kernel focuses mainly on updates and backports from mainline so it can be said that those are its main features.
Known bugs: None so far. If you are encountering freezes and reboots with the S-Pen, audio crackling or lags then try this fix: http://forum.xda-developers.com/galaxy-note-10-2014/development/lt03wifi-temaseks-unofficial-build-t2980604/post65631142. If you encounter any bugs that you think may be kernel-related, please report them here along with logcat or dmesg.
Other issues: While it can't be said that this kernel should be considered "stable" that does not mean that it is necessarily "unstable" either. Some of the backports are experimental at best so if you run into any new issues please report them here along with a dmesg log or a logcat.
Support: Currently this kernel only supports the SM-P600. Support for the P601 will be added soon.
Licence: The Linux kernel is licenced under the GNU General Public Licence v2. What this means is that if you want to develop a custom kernel using mine (or anyone else's for that matter) as your base then you are free to do so without asking for my permission. That is the nature of the Linux kernel so go nuts.
Installation: Just flash the zip in recovery and reboot. The installation procedure does not replace your current boot.img but rather just decompresses it to swap out the kernel binary (zimage) itself. This should make it compatible across different CM13-based ROMs for the SM-P600.
Download the latest build here:
valexKernel MM v1.00 https://drive.google.com/open?id=0B7Ui4IHpV48JMXNsMV96T1ZuLWc
XDA:DevDB Information
valexKernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain, RaymanFX
Source Code: https://bitbucket.org/sigma-1/valex_kernel_mm
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 1.0
Created 2015-07-10
Last Updated 2015-07-11
Manual cherry-picking: If you are cherry-picking from my tree and a patch needs to be manually applied for whatever reason, I find it preferable to amend the original author to the commit in order to avoid confusion in regard to authorship. This is done using the following command before pushing the commit:
Code:
git commit --amend --author="Author Name <[email protected]>"
The commit editing screen should now pop up, where at the bottom you may then add:
Code:
Signed-off-by: Your Name <[email protected]>
This helps keeping track of the patch's original authorship along with any modifications made to the patch. While this is not strictly a mandatory rule, I would prefer that anyone who wishes to utilize my backports in the future would follow this procedure.
Mind if I include some of this in my feature rich kernel[emoji6]
Sent from my SM-P600 using Tapatalk
Orion116 said:
Mind if I include some of this in my feature rich kernel[emoji6]
Sent from my SM-P600 using Tapatalk
Click to expand...
Click to collapse
Do it! :good:
Andmoreagain said:
Do it! :good:
Click to expand...
Click to collapse
Cannot wait to see the result
The latest build has a bug that causes reboots when the screen is off. I'll fix it and upload a new build tonight.
v1.0 is good though, a bit battery-hungry but the performance is well above average.
Edit: fell asleep last night before I could finish this. I decided to start over with the gic backports and update the big.LITTLE switcher accordingly. The difficulties that I'm running into is that the stock bL_switcher code itself is a backport that skips the upstream MCPM dependencies and thus it looks a bit different than the upstream version.
I'm going to try to just add the MCPM patches with the upstream bL_switcher and see how it runs. I already know that it compiles but I don't know if it actually works because the kernel lacks the arm-cci driver. Then again, maybe the cci driver is only required for hmp support. Only one way to find out...
Edit 2:
:fingers-crossed: Just look at this: https://bitbucket.org/sigma-1/linux-android-3.4.y-exynos-lt03wifi/commits/branch/v2-test2
Multi-Cluster PM compiles now, but the big.LITTLE switcher is causing a different build error due to some missing dependencies. I can't wait to test this out as soon as these missing dependencies have been resolved. If MCPM works then it means that there's not much left to add for true octa core support.
Edit 3:
Bahh... gonna put this on hold for now. I'm getting some nonsensical "undefined reference" errors at the very end of the build. If anyone wishes to try and figure this one out, be my guest, because these are all defined as far as I can tell.
Code:
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/arm/common/built-in.o: In function `bL_switch_to':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:196: undefined reference to `gic_get_sgir_physaddr'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:212: undefined reference to `gic_send_sgi'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:230: undefined reference to `gic_migrate_target'
arch/arm/common/built-in.o: In function `bL_switcher_halve_cpus':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:513: undefined reference to `gic_get_cpu_id'
arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:875: undefined reference to `gic_init_bases'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:882: undefined reference to `gic_arch_extn'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:882: undefined reference to `gic_arch_extn'
arch/arm/mach-exynos/built-in.o: In function `gic_init':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/include/linux/irqchip/arm-gic.h:76: undefined reference to `gic_init_bases'
arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:915: undefined reference to `gic_arch_extn'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:915: undefined reference to `gic_arch_extn'
Makefile:882: recipe for target '.tmp_vmlinux1' failed
make: *** [.tmp_vmlinux1] Error 1
I'm just gonna get back on track, fix the screen-off-reboot bug and deal with this big.LITTLE stuff when I have the time and patience for it. Something good has come out of this though since now I have a bunch of commits that help preparing the kernel base for MCPM support. That's not to say that it will ever work with this kernel. Maybe it will, maybe it won't. The best chance for this to ever work would be a board file-to-device tree migration with linux 3.10 or higher. That requires some work on the device drivers though since a few of them are not in mainline or anywhere else for that matter, except our stock kernel (why Samsung haven't sent these to be supported upstream is beyond me).
Bump!
v2.0 release candidates have been added. Both tested and running good so far. RC2 is a bit more bleeding-edge since it contains some more preparatory backports for MCPM integration. I uploaded RC1 too in case anyone runs into a bug and wishes to fall back to a more stable version. See changelog for more info on both RCs. Enjoy!
Hi. Do you plan to add other govenors ?
Thank you!
So what is the different between this kernel and stock? better battery life? performance? both? I'm looking for the main shine feature of this kernel.. )
buhohitr said:
So what is the different between this kernel and stock? better battery life? performance? both? I'm looking for the main shine feature of this kernel.. )
Click to expand...
Click to collapse
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
DirkStorck said:
Hi. Do you plan to add other govenors ?
Click to expand...
Click to collapse
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Andmoreagain said:
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Click to expand...
Click to collapse
Ok, I understand. I am only asking because with another kernel I have used "weathley" and had a good balance between speed and battery!
DirkStorck said:
Hi. Do you plan to add other govenors ?
Thank you!
Click to expand...
Click to collapse
Governors is my job once I rebase BrokenNote kernel to use this as the base.
Andmoreagain said:
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Click to expand...
Click to collapse
Sent from my SCH-R530U using Tapatalk
Orion116 said:
Governors is my job once I rebase BrokenNote kernel to use this as the base.
Click to expand...
Click to collapse
Cool! I personally don't have any particular interest in custom governors so this sounds like a good solution for those who want more customizable options.
But anyway...
I added SCHED_HMP to see if the scheduler was ready for it. Two additional commits and one revert later, that turned out to be the case indeed.
I won't be adding it in to my distribution here until I've made sure everything else is in good shape. MCPM still needs to be pulled in. RaymanFX has it partially backported, but like I've said before I have no idea whether it will actually work with the current CCI implementation. I wonder if it would be possible to support the upstream CCI driver by parsing a minimal FDT to the kernel at boot, something like:
Code:
/ {
compatible = "samsung,exynos5420", "samsung,exynos5";
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu1: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu2: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu3: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu4: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu5: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu6: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu7: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
};
cci: [email protected] {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x10d20000 0x1000>;
ranges = <0x0 0x10d20000 0x6000>;
cci_control0: [email protected] {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x4000 0x1000>;
};
cci_control1: [email protected] {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x5000 0x1000>;
};
};
};
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
Very cool. Once I get my device files straight back out and have time I am going to rebase my kernel. I am just very short on time, lol.
Sent from my SM-P600 using Tapatalk
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
It's both sad and impressive that the community does what Samsung does not for her own devices.
Good luck good sir! A proper hmp implementation also helps with battery life which -I believe- is much needed for our device (no more big core switching for the simplest things)...
Stevethegreat said:
It's both sad and impressive that the community does what Samsung does not for her own devices.
Good luck good sir! A proper hmp implementation also helps with battery life which -I believe- is much needed for our device (no more big core switching for the simplest things)...
Click to expand...
Click to collapse
This is just the nature of the Linux Kernel. Samsung have done an excellent job at maintaining and developing the Exynos platform in mainline and even the max77802 PMIC got supported not too long ago. The rest is up to the community. The fact that our stock kernel is stuck at 3.4 is just as much Google's fault as it is Samsung's due to them relying on LTS releases instead of following Linus Torvalds' motto: "release early, release often".
Andmoreagain said:
This is just the nature of the Linux Kernel. Samsung have done an excellent job at maintaining and developing the Exynos platform in mainline and even the max77802 PMIC got supported not too long ago. The rest is up to the community. The fact that our stock kernel is stuck at 3.4 is just as much Google's fault as it is Samsung's due to them relying on LTS releases instead of following Linus Torvalds' motto: "release early, release often".
Click to expand...
Click to collapse
Yeah but Galaxy Notes are Samsung's flagships and most expensive devices. One can see why they can't support every last of their devices, I can't see why they don't do it for many of their most expensive devices neither. iPad 2 , a 4 and a half year old device which was cheaper at its release time than this Note, is still getting updates (it's going to get ios9!).
I know that the nature of Linux's mainline is to be often developed by the community, but Samsung could at least offer great documentation, update drivers, etc ... I think we paid that much (for it). "If you can't develop for your expensive devices anymore, at least make it easy for your community to do so". That's my understanding, at least when expensive hardware is involved in the equation...
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
How long does your tablet usually take to boot after flashing the kernel?
Sent from my SCH-R530U using Tapatalk
---------- Post added at 05:31 AM ---------- Previous post was at 05:28 AM ----------
Andmoreagain said:
valexKernel
For SM-P600, AOSP/CM-based 5.1.1 ROMs ONLY!
Hey, you may have seen my other thread where I'm researching the possibility of porting the entire upstream kernel to our device. Of course that will take time, especially with no other experienced developers by my side. In the meantime I wanted to give you guys a little treat, so I took RaymanFX's base and did some cherry-picking and backporting of upstream features. Not particularly flashy features like blahblahblah-governor or blehblehbleh-iosched; just lots of updates from upstream, backports, and some patches from CAF and Linaro.
The scheduler has mostly been updated to something between linux 3.10 and 3.16, sched_deadline has been added, updates to topology and SMP have been added-including the generic smpboot code, per-platform SMP operations and exynos support for SMP operations. Rbtree, cpuidle, mutex, futex, blahblablah has been updated, f2fs has been pulled in with its respective 'exynos patch' from oloendithas' tree, rwsem and zsmalloc have been updated to 3.10, arch_timer has been added, power-efficient workqueues, new hashtable implementation, and the list goes on.
I also backported the gic and vic changes from linux 3.9, so if anyone is wondering where they went then they're in the drivers/irqchip directrory. A word of warning: this might be affecting some bL_switcher functionality because the stock kernel relies on a hacky backport of the bL_switcher. I plan on removing that altogether and add an upstream-ish version instead with MCPM support. The gic changes make such backporting easier to implement so thank god I'm done with it lol.
Despite this potential issue it seems to run smoothly so far. If you hit any bugs, please let me know. Enjoy! :victory:
INSTALL INSTRUCTIONS:
1) Download
2) Flash in recovery + wipe chache/dalvik
3) ???
4) PROFIT!
Highlighted changes
Code:
[U]v2.0 - MCPM-testing[/U]
- Multi-cluster PM
* MCPM is now working, at least with the big.LITTLE switcher. Full
eight core support is still not active because of lacking device
tree- and CCI support.
- big.LITTLE switcher
* Replaced the existing implementation with the upstream patches.
- OF: a few updates to fix build breakage when FDT support is enabled.
* This is still broken since device tree support for ARM is still
incomplete in 3.4 overall. I'll see if I can make it work but no
promises.
- Config options
* Multi-core scheduler enabled
* MCPM enabled
* MobiCore disabled
- Misc changes
* cpumask: preparatory patches for the CCI driver
* lib/devres: same as above
* ARM/PMU: preparatory patches for the big.LITTLE MP patch set.
* ARM: use built-in byte swap function
* mm: remove compressed copy from zram in-memory
* ARM/nommu: prevent generation of kernel unaligned memory accesses
* panic: fix incomplete panic log in panic()
* ARM: SMP: remove redundant instances of __cpuinit
* GCC optimizations
See commit history for full changelog.
- Notes
* At the current stage it could be said that the kernel almost
supports HMP. The only thing standing in the way at the moment
is the ARM CCI-400 driver which relies on device tree support in
order to work, and the Exynos5420-specific MCPM implementations
which in turn rely on the CCI driver. The next step would therefore
be improving device tree support in the kernel.
WARNING: The MCPM-enabled kernel is still buggy. There are a few
instances of kernel panics such as random reboots and sleep of death
issues. It still boots and runs fine aside from these. I've seen worse.
I can't say for sure what exactly is causing these issues. It might
not even be the MCPM or the big.LITTLE switcher. I'll have to do more
testing to find out.
Go ahead and check it out, it's not going to blow up your tablet.
Just make sure to collect the logs ;)
[U]v2.0 - RC2[/U]
- GIC:
* Synced GIC with upstream.
* 3.4 compatibility stuff is no longer needed.
- More: see commit history
* Loads of updates to ARM, especially for PM,
sleep, suspend, cpuidle, etc. These are also
preparatory changes for MCPM integration.
- Reverted commits from v1.5
* Left out some non-critical commits that were
introduced in v1.5 and were causing buggy
behavior and kernel panics. Otherwise this
release contains everything found in v1.5.
- Notes on this release:
* I have tested the kernel and so far I have
not come across any bugs or kernel panics.
If you come across anything unusual, please
let me know, provide a description of the
issue and preferably accompany your report with
a dmesg or a logcat if possible.
[U]v2.0 - RC1[/U]
- BACKPORT v2: Move GIC and VIC to drivers/irqchip
* My previous version of this backport turned
out to be a bit bloated with commits that were
not part of this particular patch set. This
has now been fixed and these additional commits
have been applied separately.
* Fixed the placement of the gic_raise_softirq
function and made sure 3.4 compatibility was
properly in check.
* Fixed some missing includes in platform-
specific code.
- SMP: formalize an IPI for wakeup
* Reverted the old ping IPI patch in exchange
for the upstream wakeup IPI. This is one of
the minor dependencies for the GIC/VIC changes.
- More: see commit history
* WM5102 sound control by AndreiLux
* Whitelisted F2FS in SELinux
* Cortex-A15 optimizations for memcpy
* kexec_hardboot support
* Disabled some of Samsung's debug bloat
* Enabled KSM, Cacheflush, Loadable module support, and a few other options.
- Notes on this release:
* I have tested the kernel and so far I have
not come across any bugs or kernel panics.
If you come across anything unusual, please
let me know, provide a description of the
issue and preferably accompany your report with
a dmesg or a logcat if possible.
[U]v1.5 - testing - Build 20151307[/U]
[INDENT]* cacheflush: upstream updates
* exynos/hotplug: use v7_exit_coherency_flush macro for cache disabling
* smp/hotplug: more or less updated to upstream, very little left to add there
* arm/opcodes: updated to latest upstream version
* kexec: kexec hardboot support
* arm: generic timer broadcast support
* clockevents: generic timer broadcast receiver
* arm/virt: allow the kernel to be entered in HYP mode
* drivers: moved some samsung drivers to staging
- This does not affect the performance of the kernel,
it's more for my own convenience when dealing with
the source code.
* gic/vic: removed some redundant leftovers in arm/common
- We are now using the upstream GIC in drivers/irqchip.
No need to keep the old one.
* Sound: Wolfson WM5102 sound control by AndreiLux
* Enabled NTFS write support
* Cortex-A15 optimizations
* init.d support in ramdisk
* misc tweaks and fixes
[/INDENT]
[U]v1.0 - stable - Build 20150710[/U]
[INDENT]* sched: updated to a more upstream version, introducing SCHED_DEADLINE
* smp: updated to a more upstream version
* smp: backported per-platform SMP operations with Exynos support
* smpboot: added generic-idle patches from upstream
* arm: added arch_timer from upstream
* arm: NEON in kernel mode
* arm/crypto: NEON optimizations
* arm/gic: backported the 3.9 version of GIC and moved to drivers/irqchip
* workqueue: power-efficient workqueues
* fs: upstream updates
* fs: pulled in F2FS support
* rbtree: upstream updates
* mutex: upstream updates
* softirq: upstream updates
* cpuidle: upstream updates
* futex: upstream updates
* removed __cpuinit
* new hashtable implementation
* zsmalloc: updated to 3.10 version
* rwsem: updated to 3.10 version
* misc optimizations
* WIP: iov-iter (the patches from faux123 are not applicable to our tree, gonna do this manually)
* WIP: arch_timer (had to revert a bunch of patches due to leaving out the patch for DT-only support)
* TODO: big.LITTLE improvements
* TODO: dig up my backported patch of kexec_hardboot for universal5420 and add it to the mix
* TODO: fix Samsung's max77803 mfd driver[/INDENT]
Special thanks to: RaymanFX, SyntheticNightmar3, dorimanx, oloendithas, xluco, AndreiLux, halaszk, faux123, and everyone I might be forgetting.
Source
Changelog
DOWNLOADS:
Testing Releases:
v2.0-MCPM-TEST
WARNING: The "MCPM/bL-switcher" build is still buggy and is for testing purposes only. Don't complain if you encounter instances of random reboots, sleep of death, etc. Log or it didn't happen!
Stable Releases:
v2.0-RC2
v2.0-RC1
v1.0-Stable
XDA:DevDB Information
valexKernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain, RaymanFX
Source Code: https://bitbucket.org/sigma-1/linux...e2ef0312b2922a8c9a1cc4871bb79d4870e?at=master
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 1.0
Created 2015-07-10
Last Updated 2015-07-11
Click to expand...
Click to collapse
Orion116 said:
How long does your tablet usually take to boot after flashing the kernel?
Sent from my SCH-R530U using Tapatalk
Click to expand...
Click to collapse
I want to know so I can get a log in the morning.
Sent from my SCH-R530U using Tapatalk
Orion116 said:
How long does your tablet usually take to boot after flashing the kernel?
I want to know so I can get a log in the morning.
Sent from my SCH-R530U using Tapatalk
Click to expand...
Click to collapse
v2 RC2: About 4 minutes in total if we count "Optimizing apps" as part of the boot process. Up until that part it takes slightly over a minute.
MCPM build: Got a freeze/kernel panic during the boot animation now. I suspect it was due to a root app having been updated before I flashed the kernel and it was requesting to be granted root access again. I've seen this pattern before with some of my unstable kernels. Last time I tested it though it took slightly longer to boot than RC2.
Stevethegreat said:
I know that the nature of Linux's mainline is to be often developed by the community, but Samsung could at least offer great documentation, update drivers, etc ... I think we paid that much (for it). "If you can't develop for your expensive devices anymore, at least make it easy for your community to do so". That's my understanding, at least when expensive hardware is involved in the equation...
Click to expand...
Click to collapse
I totally agree. It's not exactly a smart move to release a kernel source without a slightest hint of documentation. At least if they'd provide a changelog of patches applied on top of the 3.4 base then it would be easier to track down the actual patches. The truth is that some of the patches they rely on are early and incomplete revisions, while others are custom hacks plain and simple.
One good example is the max77803 driver. The P600 uses it a bit differently than other devices so what they did was modifying the max77888 driver to be used as a secondary driver for the max77803, just so that it could be handled "correctly" on the P600. Sure, there are instances of combined drivers for the Maxim PMICs such as the 77686/802 driver but that's actually the opposite of what Sammy did. Instead of making the actual driver smarter they just duplicated it. I'm starting to think that one of the reasons why Samsung don't want to provide documentation with their kernels is because of instances like this one: bloat, poor coding and lazy hacks.
Thought I'd also say that I made some progress with my other kernel tree (Linaro Stable Kernel - Linux v3.13) yesterday. It now supports the max77802 pmic and I've just begun pulling in the base which I will use for porting over the max77803 drivers. Everything compiles so far. Also, I've decided to just hire someone to port over the LCD driver as soon as I can afford it. So far it's the only driver that's an actual hindrance since it can't be found in any of Samsung's 3.10 kernel trees and I haven't been able to find any similar drivers either. If all turns out well, then maybe Sammy could be convinced to push it into mainline lol.
back-to-n0t3; Bring the larger fun to the flagship
/* Introduction */
Galaxy Note 5 firmware port over to Galaxy S6.
If you're wondering what's up with that name, Google back-to-n00t.
I just named it after that.
/* Info */
Galaxy Note 5 firmware port over to Galaxy S6.
Why do this? Because optimizations and other finishing touches are very different from the Galaxy S6.
I'm already noticing way better memory managements and performance from this port.
You need Note 5 firmware ready custom kernel along side this ROM!
Latest arter97 kernel supports this kernel.
Tell your favorite custom kernel developer to rebase their kernel to Note 5 or S6 edge Plus sources.
Debloated
De-KNOXed
Odexed, zipaligned, uncompressed
/* Disclaimer */
Your warranty is now void.
I am not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired because the alarm app failed. Please
do some research if you have any concerns about features included in this ROM
before flashing it! YOU are choosing to make these modifications, and if
you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
/* More disclaimer */
Everyone is encouraged to fork this project and make his or her own ROM based on this project.
Please read https://github.com/arter97/back-to-n0t3/blob/master/README
/* Supported device */
SM-G920F
All other devices, you should apply your own fixes or port yourself.
/* What you need to know */
'Open' does not mean 'no-respect'
Leave credits to original developers
/* Contact */
Email : [email protected]
Twitter : @arter97_dev
/* etc */
BusyBox or Superuser is not included!
This is not stable at the moment.
Please check the post below for Known issues.
/* Downloads */
XDA DevDB - Deprecated
arter97.com
Sendspace
arter97 kernel
/* Opensource */
GitHub
/* Installation */
1. Install ClockworkMod(or PhilZ) recovery
2. Put ROM on your SD card
3. Enter recovery
4. Perform a full data wipe(except you're running previous versions of back-to-n0t3)
5. Flash ROM
6. Flash custom kernel that supports Note 5 firmware (mandatory)
7. Flash SuperSU (optional)
8. Disable 'Smart Stay' from Settings to gain extra more battery life
XDA:DevDB Information
back-to-n0t3; Bring the larger fun to the flagship, ROM for the Samsung Galaxy S6
Contributors
arter97
ROM OS Version: 5.1.x Lollipop
ROM Firmware Required: Custom kernel with Note 5 ROM support
Based On: Touchwiz
Version Information
Status: No Longer Updated
Created 2015-08-16
Last Updated 2016-01-06
/* Changelog */
V13.1
Fixed framework-res durp on Xposed_Edge version
Fixed version info durp on Xposed_Edge version
Fixed odex durp on regular version
V13
G920FXXS3COK5 merged
N920CXXU2AOK7 merged
XposedBridge updated from wanam's
V12
N920CXXU2AOK6 merged
Xposed updated to v78
V11
N920CXXU2AOJ5 merged
This is a major update - http://www.sammobile.com/2015/10/22/galaxy-note-5-gets-an-update-with-battery-other-improvements/
Clean flash(factory reset before installation) is highly recommended
Apps with SPenSdk dependencies crashing issues fixed(PhotoEditor included)
CSC updated
Xposed: updated
- dex2oat arguments integrated to source
- app_process updated
- Built with updated Linaro toolchain
- Changes by wanam merged
V10
G920FXXU3COJ1 merged
Xposed updated
- Updated to v75
- Built with updated Linaro toolchain
- Changes by wanam merged
V9_Xposed_Edge
First release of Edge features enabled version
V9
Image corruption on zoomed camera issue fixed
V8
Camera filters fixed
V7
SQLite 3.8.11.1 binary added for terminal freaks
Knox left-overs removed
Misc Camera issues fixed - I can no longer reproduce the video recording and 8.0x zoom error.
N920CXXU1AOI3 merged
G920FXXU2QOI7 merged
power_profile.xml fixed - This does nothing other than fixing incorrect battery usage indication in Settings app
Xposed framework updated to v74
Misc recovery flashing issues fixed - Maybe TWRP can work now, but haven't tested
V6
CSC reworked from G928F(Galaxy S6 edge Plus) United Kingdom's firmware
N920CXXU1AOI1 merged
V5
Fix potential battery drain due to radio issues
V4
N920CXXU1AOH6 merged
G920FXXU2COH8 merged
Xposed framework updated to v73
- Fixes some modules including Amplify
- Unnecessary, experimental bits removed
V3
Graphics drivers merged from Note 5
- This changes has made it essential to install Note 5(or S6 edge +) source based kernel! Ask your favorite custom kernel developer to merge it or use arter97 kernel 3.0+! -
N920CXXU1AOH4 merged
G920FXXU2COH2 merged - This changes has fixed the slow Wi-Fi handoff issue -
Xposed installer alpha 4 apk now included on deodex'ed version
V2
Libraries updated from G920S OH7 firmware and lists are reworked
All Camera issues are fixed
Fingerprint scanner fixed
Bluetooth Smart Lock fixed
f2fs support added - format /system to f2fs before installation
More language enabled
Camera shutter-sound control enabled
Call recording enabled
framework-res: smooth spinner applied
Deodex'ed firmware with Xposed built-in released as a separate version - Thanks to @wanam
V1
Initial release
/* Known issues */
- Camera : RAW capture & exposure time control & manual color temperature K control on Camera PRO mode is not working.
These features are added at Note 5 and something hardware related must have to do with it(such as image processing).
Our Galaxy S6 Camera libraries cannot understand such options, thus force-closes.
I'm not planning to fix this. If it force-closes repeatedly wipe Camera app's data.
- "Information stream" and "Night clock" is not working and I'm not planning to fix this as this requires me to mess around the kernel.
- "Advanced NFC settings" is not working and will force-close. The NFC itself is functional. This is due to using NfcNci.apk from the stock S6 firmware and I'm not planning to fix this as using the stock NfcNci.apk is necessary for the NFC to function correctly.
/* Xposed */
back-to-n0t3 has a separate version that is deodex'ed and has Xposed built-in.
Xposed framework to Galaxy S6 was ported by @wanam and some other developers including me.
So please consider donating to @wanam.
If you don't use Xposed, I highly recommend installing the regular version.
The Xposed version of back-to-n0t3 has source-built ART Runtime.
Here are some changes that were applied.
- Built with Linaro GCC 5.2
- Built with optimization options including -O3
- Optimize-everything enabled
/* Addons */
Hacked YouTube app to enable VP9 and 60fps playback
(by hard-coding model name recognition to return SM-G920F)
YouTube
Please place this to the /system/app, normal user install won't work.
/* Sendspace */
Thanks to Sendspace for sponsoring Pro+ account!
V13.1 - https://www.sendspace.com/pro/dl/sxfc9z
V13.1_Xposed_Edge - https://www.sendspace.com/pro/dl/t9xfdg
Reserved 6
Whaooooo!!!!Nice!!!!! @arter97 two questions mate,which kernel is inside the rom and are you planning to keep this rom updated?I mean,this will be your rom?Tnx a lot for your work!!!!
Go for it and keep a good work :good:
@arter97 great, about camera and fingerprint,is it not possible to use the camera/fingerprint from the S6?
Tapatalked from my GALAXY S6
[email protected] said:
@arter97 great, about camera and fingerprint,is it not possible to use the camera/fingerprint from the S6?
Tapatalked from my GALAXY S6
Click to expand...
Click to collapse
Duh, I wish it was easy just like dat.
arter97 said:
Duh, I wish it was easy just like dat.
Click to expand...
Click to collapse
just asking as someone would have done it sooner or later.
Tapatalked from my GALAXY S6
Stupid question.. Will this work on w8?
@arter97 Congrats on the port! Will check it out in a few minutes on my G920F.
But I've one question for you:
The OP says that it's uncompressed, what do you exactly mean by this? You mean that the ROM zip is uncompressed? Has this any benefits?
abbz123 said:
Stupid question.. Will this work on w8?
Click to expand...
Click to collapse
No idea.
edgarf28 said:
@arter97 Congrats on the port! Will check it out in a few minutes on my G920F.
But I've one question for you:
The OP says that it's uncompressed, what do you exactly mean by this? You mean that the ROM zip is uncompressed? Has this any benefits?
Click to expand...
Click to collapse
Yup. Huge memory benefits at the cost of bigger ROM size.
@edgarf28 maybe a Deo-Mod of this later when everything works?
arter97 said:
Yup. Huge memory benefits at the cost of bigger ROM size.
Click to expand...
Click to collapse
Okay thanks!
Will do this too with the next update of my ROM.
edgarf28 said:
Okay thanks!
Will do this too with the next update of my ROM.
Click to expand...
Click to collapse
Do it properly.
Doing it with standard zip tools such as p7zip will do more harm than goods.
@arter97 with this port are you able to convert in the N5 apks the QMGs to PNGs? Because S6 Roms doesn't support this new kind of QMGs that comes with Note 5.
[Kernel] [Upstream Android "N" Stock] [KernelCraft] 10/13/2016 [3.10.103]RLS2
Code:
#include <std_disclaimer.h>
#include <respect.h>
#include <courtesy.h>
/*
*
* We are not responsible for your device.
* You alone take the initial risk by flashing files to your device.
* I test all kernels on my development device before I release them.
* These kernels are made in my spare time, with that being said , Please respect that.
* Please treat others with respect in this thread.
* You were the new guy or girl at one time or another.
* Please help and instruct others.
*/
This is just a personal build i started this morning, with that being said it's a no frills kind of boring kernel for now It is patched from kernel.org incremental patches and all conflicts/errors resolved correctly.
I am new to 64 bit devices and took a break from android development for awhile and it feels great to be back in the community. so enjoy! the rest is up to you!
My goal with this kernel is to see how far upstream I can go.
Please ask all the questions you want but please try to stay on topic.
Code:
Changelog:
*Initial build for Angler patched to 3.10.85
*RLS2 patched to 3.10.103
Fixed media playback error
Source https://github.com/Qualcomm-msm/angler
Downloading. Could you give a brief synopsis of what upstream means when it comes to your kernel?
OmegaBlaze said:
Downloading. Could you give a brief synopsis of what upstream means when it comes to your kernel?
Click to expand...
Click to collapse
I explain everything in my own thread here: http://forum.xda-developers.com/nexus-6p/development/reference-stock-kernel-upstream-linux-t3474540
Hello!
This is a development thread for the project of upgrading of the Linux kernel for the U8500 platform.
Builds provided here (at the moment of writing this message) are not considered to be used as a daily driver, by any means, - these are rather a dev preview versions.
For now, there are a several LK builds (the highest currently supported kernel version is 3.10).
Because builds here are really not stable, I'll just leave a disclaimer here.
Code:
#include <std/disclaimer.h>
/*
* I am not responsible for bricked devices, dead SD cards, thermonuclear
* war, or the current economic crisis caused by you following these
* directions. YOU are choosing to make these modificiations, and
* if you point your finger at me for messing up your device, I will
* laugh at you.
*/
Working features
RIL
Camera (front & rear) - only works in <3.8
Video (playback & recording)
Audio (playback & recording)
Wifi
Bluetooth (broken in >=3.8, needs a workaround to manually startup)
USB, ADB
Tethering (not tested)
GPS (not tested)
Sensors
Known bugs
IRQs are mishandled by some device drivers (abb_btemp, abb_fg)
proximity sensor might not work (not tested, cause it's broken on my device)
deep sleep might not work at a times
MMC driver works unreliably in >=3.8 (contiguous usage might lead in a data corruption)
networking is not fully-functional (no mobile data)*
camera is broken in 3.8
*some other features of the android kernel might not present - it's because these kernels lacks android-specific patches.
Sources
LK 3.5
LK 3.6
LK 3.7
LK 3.8
LK 3.9
LK 3.10
Downloads
http://xda.mister-freeze.eu/XDA-files/ChronoMonochrome/misc/upgrading
Installation
install chrono kernel r5.2 or higher (this is needed to pick up the necessary scripts, incl. bootscripts, etc)
reboot to recovery
install build linked in "Downloads" section
Credits
Linux kernel development community
Google
ST-Ericcson
Samsung
Team Canjica
XDA:DevDB Information
U8500 Linux kernel upgrading project, Kernel for the Samsung Galaxy Ace II
Contributors
ChronoMonochrome
Kernel Special Features:
Version Information
Status: Alpha
Created 2017-05-09
Last Updated 2017-05-10
Reserved
Porting
The porting a higher kernel version tehnique I'll describe here is not intended to be a guide for dummies. I'll assume you've already built a kernel for your device, familiar with git versioning control usage and with some porting / coding tehniques.
Firstly, you need a cleaned source for your device. By "cleaned" I mean, there are no Linux incremental patches, android changes applied, manufacture-specific patches are avoided when possible and so on - you need sources as closest to a "pure" Linux kernel as possible. Otherwise you'll have later need to deal with conflicts resolution, you'll most likely be unable to resolve and the kernel won't boot.
So, without a further forewords, the tehnique is below:
1) As was previously mentioned, a clean kernel source is required, I'll assume we are starting from LK-3.4 ( https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/ea228ee0f5e9935841aff25c62fa163cd78dc01d ) and porting a higher kernel versions. A kernel base needs to be tested for any bugs just to distinguish, which bugs were intruduced during porting from those ones that already present in a kernel base.
2) The following steps will mostly use git bisect and git merge commands in order to merge all the changes from a higher kernel versions and help to find / resolve the bugs that were introduced. I suggest copying a git kernel repo that you use for building to a somewhere else, so you can use it , e.g. for grepping a different versions source, bisecting the revisions and so on, so don't need to bother messing up in your main repo that you use for build.
3) Firstly, lets just try to merge a higher kernel version, e.g. LK 3.5 by issuing a command git merge lk-3.5. You'll likely have a lot of merge conflicts, most of which you can resolve with resetting the paths to a some revision (either a kernel base - lk 3.4, or the version you do port, or just another suitable conflict resolution). So I suggest to write those paths to a text file, like so:
Code:
arch/arm/boot
arch/arm/mach-ux500
arch/arm/plat-nomadik
drivers/mmc
include/linux/mmc
drivers/usb
include/linux/usb
drivers/mfd
include/linux/mfd
...
Write all the paths you intend to reset to the kernel base, you most likely need to re-use them later. To actually perform a resetting source, you can issue
Code:
for path in $(cat file_with_a_paths.txt | xargs)
do
git checkout COMMIT $path
done
Be sure not to put to this file anything not the device-specific! Resetting to the kernel base should be avoided when possible (never ever try resetting archictecture-specific paths, e.g. arch/arm/kernel, arch/arm/mm and so on - unless you really know that kernel will boot thereafter, instead, you have to manually resolve such conflicts). Resolve any other conflicts by resetting paths to the porting source (e.g. LK 3.5).
Note. While resetting with a paths is probably not the most accurate tehnique, but people don't live that long to use more accurate approach, e.g. performing git cherry-pick for every upstream commit and then manually resolving all the conflicts, you'll just sooner or later get bothered and will abandon it.
4) When you're done with the previous steps you can try building kernel. You'll likely have a build errors - because some part of a source got not updated (e.g. the device-specific drivers), you need manually implement the necessary by a higher kernel version changes. Firstly check if an upstream kernel contains the necessary fixes (example: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/9fae8c449b710f502662da1cbcf26ece5a098af9 , https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/fe027c25d6db0d100937deb5248e249ec5b24ee7 ). If the driver you are porting doesn't exist in the upstream, you can also try to find a similar change and mimic it: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/5f2e7afbf2ac3284dc62b3d96a0627c7f99ed4e9 ( ported similarly to https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/526c597 ). In the worst case scenario you will need to examine the upstream changes and apply the changes so that the drivers complies to the upstream changes: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/ea6432d167 .
5) If everything is done properly and you're lucky enough, the compiled kernel might already bootup. If not, you'll need to find a culprint that doesn't let the device to boot up. Switch to a copy of your kernel sources, reset the source to the base kernel version (e.g. LK 3.4), issue git bisect good, then issue git bisect bad lk-3.5, git will reset to a somewhere in a middle between of LK 3.4 and LK 3.5.
6) Save your changes in the kernel repo, by assigning a some branch to it, switch to the source base, merge all the fixes you've already introduced, then merge the revision you have got in the previous step by bisecting the tree. Repeat these steps until you'll find a first bad commit.
7) If you are already on this step, the most trickiest part starts here - testing (hopefully) working kernel for bugs (if any). While logs can be useful sometimes (so you can google the failing messages and find something useful), there are also many bugs you can find only performing git bisect tehnique decribed above.
The decribed algorithm only possible thanks to having a clean kernel source. The usage of this guide is not limited only to the kernel porting, it can be used on other projects as well, this is just what I've come across to, when I've ever started porting Linux kernel versions higher than LK3.4.
Reserved
I wonder if any of this expertise couldn't look pretty cool here too.
Wooooowwwewe
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Seriously!
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Wow, that's incredible
Exynos4412 already got some mainline support, it would be very nice to have this one supported too.
Aaaaand it's done, kinda.
ST-Ericsson NovaThor U8500 - postmarketOS
wiki.postmarketos.org
device/testing/linux-postmarketos-stericsson · master · postmarketOS / pmaports · GitLab
postmarketOS package build recipes
gitlab.com
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Click to expand...
Click to collapse
What is this?K.W.A.G.A Kernel is a kernel to improve performance and battery life for Galaxy S8s running Android 13 with Ivan Meler's port of LineageOS.
Why does it exist?Well, I thought my phone felt a bit slow so I started developing this. It was never intended to be released to the public but as I started to find out more about what a kernel can do and implemented it into this project it felt almost mean keeping it away from everyone else.
How do I donate?As I am at the time of writing this 15, I currently do not accept monetary donations as they wont help the project at all, but feel free to send me your S8s. If you want to do that, please open an issue on my github, DM me here on XDA or contact me in another way that you feel is suitable.
How do i change kernel parameters?I have made a slightly modifyed @corsicanu s app for that. You can download apk from attached files. Source code here: https://github.com/opensourcefreak/KWAGA-kernel-manager
Source code:Here: https://github.com/opensourcefreak/K.W.A.G.A-kernel-dreamlte
Root?These images come pre-rooted. Using this kernel without root is not supported.
DownloadComing soon
Kernel features:* Adjustable Zram size with lz4 compression* MoroSound 2.2 sound mod* Up to 2.8 Ghz cpu overclock on big cores(Stock frequency is 2.3 Ghz)* Up to 2.0 Ghz cpu overclock on small cores(Stock frequency is 1.6 Ghz)* Up to 839000 Mhz gpu overclock on all cores(Stock frequency is 546000 Mhz)* Boeffla wakelock blocker
Coming soon:* lz4 ramdisk compression for faster boot time* a2n custom DVFS driver for voltage and temperature control* An app to change kernel parameters specific for this kernel* Support for S8+* Support for running without root* Support for suspend_max_freq* Support for enable_ocCredits:@ace2nutzer for cpu/gpu overclocking@bruh™ for inspiration and a few prototype builds@Ivan Meler for his fantastic ROM and kernel sources(Also implemented MoroSound, Boeffla waklock blocker, fixed zRam with lz4 compression)@morogoku for MoroSound@noxxius for device tree mods and MoroSound@andip71 for Boeffla wakelock blocker@flar2 for wake gestures@samsung for kernel sourcesLinus Torvalds for Linux
Changelog:V 0.1* Added wake and sleep gestures(Thanks @flar2)* Fixed incorrectly displayed MoroSound version
i'm looking forward to it
thank you but does it support evolution x or pixel experience
I have test-builds ready for the full 1.0 release. It will problaby be out next week or something like that.
elosanta said:
thank you but does it support evolution x or pixel experience
Click to expand...
Click to collapse
If it's android 13 so yes, otherwise probably no but there is only one way to find out.
opensourcefreak said:
If it's android 13 so yes, otherwise probably no but there is only one way to find out.
Click to expand...
Click to collapse
Okay!