Database Users

[REQUEST] N8000 Kernel Source

I am about to build a kernel for N8000. But my problem is I can not download from samsung open source site (Very Slow Connection).
Can someone please mirror the update7(MD1) for me on a fast server like dev-host, android file host, mediafire or etc...?
Here's the Samsung open source site:
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=GT-N8000
Thanks in advance.

You may use my GitHub repository, which has a branch "merge-to-ss-jb" that is just the vanilla Samsung kernel, backed by the complete Linux tree.
Also, if you're interested in a complete, up-to-date tree (and what I'm running on my own GNote) you may browse my "kernel-forward" branch.

kcrudup said:
You may use my GitHub repository, which has a branch "merge-to-ss-jb" that is just the vanilla Samsung kernel, backed by the complete Linux tree.
Also, if you're interested in a complete, up-to-date tree (and what I'm running on my own GNote) you may browse my "kernel-forward" branch.
Click to expand...
Click to collapse
Thanks.
I have two questions if you don't mind.
1. Merge-to-ss-jb is the latest source (MD1)? Is it a good to go for a kernel to be based upon?
2. Is it alright with you that I base my kernel on your own kernel?
I appreciate it if you can help me with some kernel stuff as I am new to this.
Sent from my HTC One X using Tapatalk 4 Beta

csec said:
"merge-to-ss-jb" is the latest source (MD1)?
Click to expand...
Click to collapse
Yeah, it's essentially the official Linux kernel source up to version 3.0.31, overlaid with a cleaned-up version of the 1st Samsung JB kernel release, then each subsequent Samsung Open-Source Release (latest is "#7") is overlaid on top of that. If you build the HEAD of that branch, you'll have a vanilla Samsung kernel as of XXMCD1.
Is it alright with you that I base my kernel on your own kernel?
Click to expand...
Click to collapse
Of course! The entire Linux kernel is built upon Public collaboration; we all share from each other. My kernel has a few selected bits here and there from diverse places like CyanogenMod, Francisco Franco, Xstacy, the upstream kernel, Qualcomm, NVidia ...
I used to post my built kernel up in the ROM threads I used to use on my GNote, but someone complained and I don't really feel like being bothered with my own thread (don't have time for the inevitable newbie SPAM) so until if/when I do go "public" with it, the "kernel-forward" branch on GitHub is the best place to get what I'm running now.

kcrudup said:
Yeah, it's essentially the official Linux kernel source up to version 3.0.31, overlaid with a cleaned-up version of the 1st Samsung JB kernel release, then each subsequent Samsung Open-Source Release (latest is "#7") is overlaid on top of that. If you build the HEAD of that branch, you'll have a vanilla Samsung kernel as of XXMCD1.
Of course! The entire Linux kernel is built upon Public collaboration; we all share from each other. My kernel has a few selected bits here and there from diverse places like CyanogenMod, Francisco Franco, Xstacy, the upstream kernel, Qualcomm, NVidia ...
I used to post my built kernel up in the ROM threads I used to use on my GNote, but someone complained and I don't really feel like being bothered with my own thread (don't have time for the inevitable newbie SPAM) so until if/when I do go "public" with it, the "kernel-forward" branch on GitHub is the best place to get what I'm running now.
Click to expand...
Click to collapse
Great!
Thanks again.
Sent from my GT-N8000 using Tapatalk HD

csec said:
Great!
Thanks again.
Sent from my GT-N8000 using Tapatalk HD
Click to expand...
Click to collapse
Heard that the published sources have different wi-fi drivers than preinstalled stock kernel.
This is the main reason of allshare cast not working with custom kernels (on the contrary, some s3 custom kernels DO SUPPORT allshare cast), even if status=official and flash counter=0.
Anyone can confirm?
Anyone has the proper ones or know which one (i.e. from a different samsung device) to use?

gitHub link dead

CAF problems list

Hi!
So, recently, I've noticed that CyanogenMod (CM) has adopted CodeAuroraForum (CAF) code, which is causing incompatibilities with AndroidOpenSourceProject (AOSP) code.
Problem #1:
Also, one of the common problems due to this is that flashing custom kernels (AOSP based), leads to color-display problems.
To fix this, a colorfix.zip has been provided by someone in the AOKP thread.
Also, there is poll in the AOKP website, about a shift to CAF code.
Now, AFAIK, this overwrites "liboverlay.so", in /lib. If this is all that need to be done to fix it, then how is a code problem?
Does this file have to be updated? What exactly does this file do?
What are the other problems associated with CAF code adoption?
Please contribute your opinions and list any other problems.

not happy with CAF.. stop using cm. there are plenty of better roms out there for you to choose from.

Agrees cm has gone to the poop house now.
Sent from my Nexus 4 using XDA Premium 4 mobile app

arvindch said:
Hi!
So, recently, I've noticed that CyanogenMod (CM) has adopted CodeAuroraForum (CAF) code, which is causing incompatibilities with AndroidOpenSourceProject (AOSP) code.
Problem #1:
Also, one of the common problems due to this is that flashing custom kernels (AOSP based), leads to color-display problems.
To fix this, a colorfix.zip has been provided by someone in the AOKP thread.
Also, there is poll in the AOKP website, about a shift to CAF code.
Now, AFAIK, this overwrites "liboverlay.so", in /lib. If this is all that need to be done to fix it, then how is a code problem?
Does this file have to be updated? What exactly does this file do?
What are the other problems associated with CAF code adoption?
Please contribute your opinions and list any other problems.
Click to expand...
Click to collapse
The issue with liboverlay.so is code incompatibilty between the ASOP source (custom kernels) with CM ROM using the CAF driver blobs. It's like a Chinese person speaking Chinese to an English only speaker. The fix is replacing the liboverlay.so with the ASOP liboverlay.so and back out that portion of the CAF. It's not a long term solution because it may cause other problems down the road.
There are some advantages using CAF, but it cause a divergence in kernels for the custom ROMs which may not be a good idea and causes maintainance headaches for the open source dev. For now lets just see what CM does with CAF.
Sent from my Nexus 4 using xda app-developers app

simms22 said:
not happy with CAF.. stop using cm. there are plenty of better roms out there for you to choose from.
Click to expand...
Click to collapse
kthejoker20 said:
Agrees cm has gone to the poop house now.
Sent from my Nexus 4 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I agree that a solution is not using CM and CM-based ROMs. :|
However, I've started this thread to compile a list of problems that CAF code is causing and possible fixes, and to discuss the outcome of CAF code usage.

AtrixShan said:
The issue with liboverlay.so is code incompatibilty between the ASOP source (custom kernels) with CM ROM using the CAF driver blobs. It's like a Chinese person speaking Chinese to an English only speaker. The fix is replacing the liboverlay.so with the ASOP liboverlay.so and back out that portion of the CAF. It's not a long term solution because it may cause other problems down the road.
There are some advantages using CAF, but it cause a divergence in kernels for the custom ROMs which may not be a good idea and causes maintainance headaches for the open source dev. For now lets just see what CM does with CAF.
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
What are the advantages to CAF code usage?
I read somewhere that Qualcomm contributes better, optimized code to the CAF, and hence, performance/quality may be better than AOSP. I don't have the source link, though.
Any ideas?

arvindch said:
What are the advantages to CAF code usage?
I read somewhere that Qualcomm contributes better, optimized code to the CAF, and hence, performance/quality may be better than AOSP. I don't have the source link, though.
Any ideas?
Click to expand...
Click to collapse
That's what I read, too. It's hard to say for now because I don't think CM is done with their CAF implementation. Let wait and see. The bottom line for me is using what works well on my Nexus 4. The headaches for the open source community does suck though. I used faux kernel since my first smart phone (Atrix 4g)
Sent from my Nexus 4 using xda app-developers app

AtrixShan said:
That's what I read, too. It's hard to say for now because I don't think CM is done with their CAF implementation. Let wait and see. The bottom line for me is using what works well on my Nexus 4. The headaches for the open source community does suck though. I used faux kernel since my first smart phone (Atrix 4g)
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
Hmmm.
Same here - I've been using Franco.kernel since forever - I even bought the FKU pro app. It's giving me great performance and battery-life.
I don't want to stop using it! However, the features offered by SlimBean are too useful for me to ignore, as well.
Hence, if SB adopts the CAF code CM is using, since SB is based off CM, then I will have an extremely hard decision to make.

Not sure if anyone's noticed but you should check out your dmesg if reverting to an earlier liboverlay.so. I didn't notice any drastic changes in performance / battery life as a result, but that's not something I'm thrilled with.
For the time being, I've made some test builds with the two YCBYCR commits (from Oct 1)
It's based on Franco's r191.
The zips include the full OTG patch (kernel + ramdisk + ROM-side changes), but if you don't want the ramdisk/ROM-side features, just flash the boot.img or strip out the (non-)relevant parts from updater-script. It will still have the "otg code" in the kernel, but it shouldn't be something that'd affect usage at all.
4.3: 2013.10.13 0401ET r191: [JWR] [JSS/JLS]
Again, these have the two relevant commits cherry-picked and will require the recent liboverlay.so.
Just a temporary solution. I am curious though about how many other ROMs are affected by this-- CM forks. If say all new JLS/JSS ROMs require this, I might as well just keep on cherry-picking since that's the entire userbase practically. Obviously JWR will be a much tougher one.

ziddey said:
Not sure if anyone's noticed but you should check out your dmesg if reverting to an earlier liboverlay.so. I didn't notice any drastic changes in performance / battery life as a result, but that's not something I'm thrilled with.
For the time being, I've made some test builds with the two YCBYCR commits (from Oct 1)
It's based on Franco's r191.
The zips include the full OTG patch (kernel + ramdisk + ROM-side changes), but if you don't want the ramdisk/ROM-side features, just flash the boot.img or strip out the (non-)relevant parts from updater-script. It will still have the "otg code" in the kernel, but it shouldn't be something that'd affect usage at all.
4.3: 2013.10.13 0401ET r191: [JWR] [JSS/JLS]
Again, these have the two relevant commits cherry-picked and will require the recent liboverlay.so.
Just a temporary solution. I am curious though about how many other ROMs are affected by this-- CM forks. If say all new JLS/JSS ROMs require this, I might as well just keep on cherry-picking since that's the entire userbase practically. Obviously JWR will be a much tougher one.
Click to expand...
Click to collapse
This seems useful! :good:
Is this a patched franco kernel that works on CAF roms?
Could you clarify what this does? I'm sorta confused by all this.

from wat i know.. JSS faster than jwr but aosp jss has deadlock issues.. and caf solves deadlock issue..

Andre_Vitto said:
from wat i know.. JSS faster than jwr but aosp jss has deadlock issues.. and caf solves deadlock issue..
Click to expand...
Click to collapse
Really? I didn't know that. OK. One advantage then.

arvindch said:
Really? I didn't know that. OK. One advantage then.
Click to expand...
Click to collapse
JSS is a dev branch and has some GPU optimizations
== Sent from my CarbonMako ?? ==
---------- Post added at 11:35 PM ---------- Previous post was at 11:33 PM ----------
I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
== Sent from my CarbonMako ?? ==

MaxFTW said:
\
[/COLOR]I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
== Sent from my CarbonMako ?? ==
Click to expand...
Click to collapse
Hard to find stable roms on 4.3 these days.. PA is down the drain.. no update since a month.. too less features.. AOKP wont boot up for most ppl.. PAC is inherently unstable. I'm currently stock rooted.. seems like the most stable for me now..

AOKP nightly boot find for me, and I assume most other N4 have the same hardware as I do. "Official" AOKP don't put out nightlies that can't boot. People just need to not flash incompatible kernels and know what they're doing.

MaxFTW said:
JSS is a dev branch and has some GPU optimizations
---------- Post added at 11:35 PM ---------- Previous post was at 11:33 PM ----------
[/COLOR]I have decided to quit CM as well due to their dumb decision about CAF
Now using Carbon ROM and to be honest it is non-bull**** one, packed with useful features, with wide group of fans and still developing for loads of devices
Click to expand...
Click to collapse
Slimbean is also based off CM code and I love Slimbean's feature set.
Luckily they haven't merged CAF changes YET. :fingers-crossed:
I'm also testing crDroid, since I like Halo; however, they're based right off CM 10.2, so I need to flash colorfix.zip to get it working with Franco.kernel.
Andre_Vitto said:
Hard to find stable roms on 4.3 these days.. PA is down the drain.. no update since a month.. too less features.. AOKP wont boot up for most ppl.. PAC is inherently unstable. I'm currently stock rooted.. seems like the most stable for me now..
Click to expand...
Click to collapse
eksasol said:
AOKP nightly boot find for me, and I assume most other N4 have the same hardware as I do. "Official" AOKP don't put out nightlies that can't boot. People just need to not flash incompatible kernels and know what they're doing.
Click to expand...
Click to collapse
Hmm.
I've never tried 'pure AOKP'. I've use ROMs which kang stuff from AOKP sources though. Same goes for CM - I've never used pure CM. I love using hybrid ROMs - Best of all worlds!
I agree. Sadly, PA is stuck on an RC2 since a month.
I read that they're waiting for 4.4 to drop, but IMO, atleast they could release another RC in the meanwhile, to fix bugs.
Some ROMs have merged all the latest Halo commits and have fixed some bugs I encountered on PA 3.99RC2, so I'm using them (hybrid ROMs) instead.

[Q] Now Android MM is out for while, anybody working on any new ROMS?

Hey guys was just wondering if there any developers who are working on some new ROMS for our MXP as it seems very quiet in the development sections of the forums, couple of variations of stock rom and that's pretty much it.
Was expecting for development to pick up after the MM but its been VERY quiet.
Not a complaint just wondering if there are things going on behind the curtains like development being done or some CM13 or anything along those lines.

djsynth said:
Hey guys was just wondering if there any developers who are working on some new ROMS for our MXP as it seems very quiet in the development sections of the forums, couple of variations of stock rom and that's pretty much it.
Was expecting for development to pick up after the MM but its been VERY quiet.
Not a complaint just wondering if there are things going on behind the curtains like development being done or some CM13 or anything along those lines.
Click to expand...
Click to collapse
Having MM OTA out is not enough.
Not much can be done until Motorola will release the kernel source

nimrodsv said:
Having MM OTA out is not enough.
Not much can be done until Motorola will release the kernel source
Click to expand...
Click to collapse
Any idea if its going to get released and if yes then when ?
and out of self interest what does the kernel source enable developers to do ?

djsynth said:
Any idea if its going to get released and if yes then when ?
and out of self interest what does the kernel source enable developers to do ?
Click to expand...
Click to collapse
It's totally depended on Motorola.
The source enable developers to release AOSP roms and custom kernels.

nimrodsv said:
It's totally depended on Motorola.
The source enable developers to release AOSP roms and custom kernels.
Click to expand...
Click to collapse
Has Motorola been known to release kernel sources before for previous flagships ?

Would love for them to release the binaries and device tree for AOSP builds...

djsynth said:
Has Motorola been known to release kernel sources before for previous flagships ?
Click to expand...
Click to collapse
They are required to release any changes to the kernel they have made due to the GPL license that the linux kernel is protected by. so its not a matter of if but when.

MM and now kernel source released, and still, slow as hell. Sucks. I thought this phone would be one of the most active in development, was i wrong.
Sent from my XT1575 using Tapatalk

I'm on retail Asia variant which leaves me with 1 rom. And I can't even get mm for my variant let alone custom roms.

What happened to this phone?
Please go to http://forum.xda-developers.com/moto-x-style/help/happened-to-phone-t3283551
to continue this topic if possible, thank you

6.0.1 kernel

Is there any kernel for Android 6.0.1 on Nexus 7 2012?

Yes, every 6.x ROM provides a kernel, too, or what are you looking for? If you are looking for sources, you might want to have a look at my Github.

AndDiSa said:
Yes, every 6.x ROM provides a kernel, too, or what are you looking for? If you are looking for sources, you might want to have a look at my Github.
Click to expand...
Click to collapse
I am looking for kernel that enables overclocking. I searched forum but there are only kernels for Lollipop, not Marshmallow.

Probably you would like to have a look on Daniel_hk's kernel for Omni ROM. If I got it right, he implemented some overclocking into it, but I did not test it.

AndDiSa said:
Probably you would like to have a look on Daniel_hk's kernel for Omni ROM. If I got it right, he implemented some overclocking into it, but I did not test it.
Click to expand...
Click to collapse
So just flash OmniROM for 6.0.1? And the kernel is included? Or is there a separate file for kernel that must be flashed?

His Omni-build should include the OC-kernel directly.

Looking for a kernel on Nexus 7 2012 (3G) to fix baseband_XMM_power wakelock

@williamlaw: my kernel has the patch included. Most likely I'll upload a fastboot flashable zip today or tomorrow onto my Android 6 AOSP on Grouper thread.

AndDiSa said:
@williamlaw: my kernel has the patch included. Most likely I'll upload a fastboot flashable zip today or tomorrow onto my Android 6 AOSP on Grouper thread.
Click to expand...
Click to collapse
Thanks for your work but i am using 3G version.

Test build

Hello everyone.
http://download.jgcaap.xyz/files/bullhead/cm-13.0/
Would like to request if possible if someone could test this build
This build is based on CM device tree kernel and blobs, which shouldn't cause any issues on flashing.
As a test, please remember i'm not responsible to any damage which might occurr.
The worst thing might happen is not booting.
This rom is like flashing a CM nightly.
I'm interested on expanding my work between diferent devices. So please let me know how it goes.
Please list the bugs.
F2FS is compatible with this device?
source https://github.com/CyanogenMod/android_kernel_lge_bullhead
Thank you

jgcaap said:
Hello everyone.
http://download.jgcaap.xyz/files/bullhead/cm-13.0/
Would like to request if possible if someone could test this build
This build is based on CM device tree kernel and blobs, which shouldn't cause any issues on flashing.
As a test, please remember i'm not responsible to any damage which might occurr.
The worst thing might happen is not booting.
This rom is like flashing a CM nightly.
I'm interested on expanding my work between diferent devices. So please let me know how it goes.
Please list the bugs.
F2FS is compatible with this device?
Thank you
Click to expand...
Click to collapse
Please add a direct link to kernel source used as required by XDA and GPLv2...thanks. And thanks for your contribution.

KennyG123 said:
Please add a direct link to kernel source used as required by XDA and GPLv2...thanks. And thanks for your contribution.
Click to expand...
Click to collapse
It's stock from CM. I'll open a new post under development thread if everything goes well on tests and add all source links there. Is it ok? thanks

jgcaap said:
It's stock from CM. I'll open a new post under development thread if everything goes well on tests and add all source links there. Is it ok? thanks
Click to expand...
Click to collapse
The only thing considered stock is direct from the manufacturer, LG or Google. CM is not a stock OS, therefore if you are distributing the binary (boot.img) in your link then you must post a link to the kernel source compiled to make it. Otherwise you need to remove the boot.img and let people get their own kernel.
Thanks

KennyG123 said:
The only thing considered stock is direct from the manufacturer, LG or Google. CM is not a stock OS, therefore if you are distributing the binary (boot.img) in your link then you must post a link to the kernel source compiled to make it. Otherwise you need to remove the boot.img and let people get their own kernel.
Thanks
Click to expand...
Click to collapse
done Thanks for clarifying.

Hello @jgcaap
i will test and report back
thanks for supporting 5x and 6p (i have both)
edit: i'm using F2FS and un-encrypted. I've had to change the kernel to jolla's, to make it boot. It does not boot on stock kernel.
everything else seems to be working fine.