Post Updated from Original
Cyanogen has posted a i9505 common device tree.
It is based on his working configurations for US T-mobile.
There are two ways to get this:
1) Clone these repos:
https://github.com/CyanogenMod/android_device_samsung_jf-common
https://github.com/CyanogenMod/android_kernel_samsung_jf
https://github.com/CyanogenMod/android_device_samsung_jfltetmo
2) Set up your CM environment and "breakfast jfltetmo" to pull the 3 repos above.
The first 2 are the common device and kernel. The third can be used as a base for your device.
(So fork it to your own repo and start making changes)
Hope this gets other variants up quickly! Thanks again to Cyanogen for the work to get it this far so quickly!
garwynn said:
Well, while waiting for the SPH-L720 (Sprint GS4) to come out this weekend I'm trying to do what prep work I can. I'm checking both here and #cyanogenmod-dev to see if anyone else has started this, but just in case I created jflte-common repos to start allowing collaborative efforts for GS4 work to get CM going ASAP. I'll be using these to get the jfltespr (SPH-L720) trees up and running.
Now fair warning, I'm doing this as my first port attempt but have several kernels and a few recoveries that I've done already. So please bear with the learning curve...
I9505 Common Repos:
https://github.com/garwynn/i9505_rec_ramdisk (Thanks to ewmno for posting the i9505 recovery.img!)
https://github.com/garwynn/device_samsung_jflte-common
https://github.com/garwynn/vendor_samsung_jflte-common
https://github.com/garwynn/kernel_samsung_jflte
I'm downloading the only i9505 source I saw so I can find out what linux build version they're using as a base. Figured that's a good starting point to figure out where we start for kernel dev.
Anyone interested in helping - would be most appreciated! I'll start working on the tree repos this morning (US CDT)
Click to expand...
Click to collapse
Since it's Qualcomm based - First thing you should do is fork https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
Then go to Qualcomm's CAF release list at https://www.codeaurora.org/xwiki/bin/QAEP/release and go through the tags for your SoC and Android version. Check each out one by one. I'm fairly certain you are APQ8064T. Whcih is odd, there are no tags for the T variant...
Code:
git checkout <TAG>
Drop the Samsung tarball on top of the checked out tree, and diff it.
Code:
git diff > ../<TAG>.patch
Keep going until you find the patch that is the smallest. This is likely the CAF base that Samsung started from.
Two other things:
Be warned, Samsung hacks the **** out of their bases
Also, try to coordinate with cyanogen himself, I believe he'll be working on either the AT&T or T-Mobile variants.
Entropy512 said:
Since it's Qualcomm based ................................Blah Blah
Click to expand...
Click to collapse
What if i need to make 1 for I9500
Entropy512 said:
Since it's Qualcomm based - First thing you should do is fork https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
Then go to Qualcomm's CAF release list at https://www.codeaurora.org/xwiki/bin/QAEP/release and go through the tags for your SoC and Android version. Check each out one by one. I'm fairly certain you are APQ8064T. Whcih is odd, there are no tags for the T variant...
Code:
git checkout <TAG>
Drop the Samsung tarball on top of the checked out tree, and diff it.
Code:
git diff > ../<TAG>.patch
Keep going until you find the patch that is the smallest. This is likely the CAF base that Samsung started from.
Two other things:
Be warned, Samsung hacks the **** out of their bases
Also, try to coordinate with cyanogen himself, I believe he'll be working on either the AT&T or T-Mobile variants.
Click to expand...
Click to collapse
Thanks for the starting point, Entropy! I'll start on that during my lunch break.
I'm keeping up IRC on the build box but just sent an alt contact in case anyone else you know is interested in collaborating.
I'm guessing that they're not differentiating (yet) between the APQ8064 variants.
So I'll start pulling standard APQ8064 and hopefully get lucky.
might want to look at cpu_is_apq8064ab related stuff in the jb_2.5 branch to get an idea of where stuff is - The APQ8064T may be referenced as APQ8064AB in kernel sources. Not sure.
Still doesn't answer which tag to follow.
We are lucky to have such a driven Dev. Thank you gawynn, for all you have done, and all that you will do.
Kudos from the E4GT community.
Entropy512 said:
might want to look at cpu_is_apq8064ab related stuff in the jb_2.5 branch to get an idea of where stuff is - The APQ8064T may be referenced as APQ8064AB in kernel sources. Not sure.
Still doesn't answer which tag to follow.
Click to expand...
Click to collapse
No but it does allow me to thin out the list.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Every build that I have seen so far is March so we should be able to rule out any April builds.
So once I get access to my build box again (TV died yet again...) I'll start at the bottom and work my way up.
(Edited post) So far the above (AFAIK) addresses kernels. Still haven't addressed device.
Thinking we can still use this for graphics base:
https://github.com/CyanogenMod/android_device_samsung_msm8960-common
I almost want to fork d2-common for the jflte common device and start replacing S3 with S4 details.
I have that 9505 system dump on my build box so I can start extracting stuff from there.
More as I keep reading and digging.
Looking forward to development for S4 , planning on getting it as soon as my renewal will allow .
Sent from my SPH-D710 using xda premium
Cyanogen found kernel already, head is jb_2.5, didn't get the branch point but says he knows what it is.
In the meantime I went ahead and stripped d2-common and used that as a shell for jflte-common device.
Future status updates on this will be placed here at Cyanogen's request:
https://jira.cyanogenmod.org/browse/QSDB-25
Feel free to take a look there for progress reports.
Will be requesting thread lock for now.
As far as graphics base you'll almost surely have the same flags as any other caf-display device.
Sound can get a bit more funky... I'd look at mako, Sonys, and Oppo Find5 for inspiration there as those are the current non-T APQ8064s.
Entropy512 said:
As far as graphics base you'll almost surely have the same flags as any other caf-display device.
Sound can get a bit more funky... I'd look at mako, Sonys, and Oppo Find5 for inspiration there as those are the current non-T APQ8064s.
Click to expand...
Click to collapse
i9505 Latin JB source has Alsa audio folder in the platform side - wouldn't be able to use that?
You know what? Seeing as OSRC pulled it (for now) I'll make a repo for both the kernel and platform side and add the links here in a sec.
Edited:
https://github.com/garwynn/i9505_latin_jb_platform
https://github.com/garwynn/i9505_latin_jb_kernel
Hopefully we get the L720 stuff here soon so I can compare ROMs and kernels against the ones I have already.
Should give a good idea as to what can be common vs. proprietary.
Had to change my search for the kernel based on a misunderstanding of where to start.
So I started with the jb2.5 head and pulled this list from it.
As you can see I've been trying a "divide and conquer" method to figure out where the branch point is.
Tried checkout method after cloning the repo but can't seem to get it to pull the branch source.
So for now I'm resorting to a rather tedious process of clone branch, diff, delete, repeat.
Also doesn't help that I lost the build box for a day but hopefully will be fixed by 7 pm.
So while I wait for the build box to come back I'm going to see if that AT&T dump is different from the i9505 one I have.
If so should shed some light on what in the ROM will be common and what won't be.
garwynn said:
No but it does allow me to thin out the list.
Every build that I have seen so far is March so we should be able to rule out any April builds.
So once I get access to my build box again (TV died yet again...) I'll start at the bottom and work my way up.
(Edited post) So far the above (AFAIK) addresses kernels. Still haven't addressed device.
Thinking we can still use this for graphics base:
https://github.com/CyanogenMod/android_device_samsung_msm8960-common
I almost want to fork d2-common for the jflte common device and start replacing S3 with S4 details.
I have that 9505 system dump on my build box so I can start extracting stuff from there.
More as I keep reading and digging.
Click to expand...
Click to collapse
I don't know much about porting and building CM but I noticed there was some confusion about the chipset model. I'm wondering if this might help you in any way:
http://www.anandtech.com/show/6914/samsung-galaxy-s-4-review/3
ilabs said:
I don't know much about porting and building CM but I noticed there was some confusion about the chipset model. I'm wondering if this might help you in any way:
http://www.anandtech.com/show/6914/samsung-galaxy-s-4-review/3
Click to expand...
Click to collapse
That isn't useful. We are fully aware of which chipset is in this device. What we're not entirely sure of is which release tags/branch in CAF it corresponds to (unlike most other qcom processors, there is not a direct match between the chip's identifier and any CAF tags. That said, it is starting to seem like CAF is using the apq8064 releases for both apq8064 and apq8064t)
As embarrassing as this may be for me, let my facepalm teach others...
Read advice from mentors well.
And if not sure, read it again. And if still not sure, read it again.
Bold and italics below are my emphasis.
Entropy512 said:
Since it's Qualcomm based - First thing you should do is fork https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
Code:
git checkout <TAG> [I][B](Notice no -b here like I was doing and thus causing my headaches)[/B][/I]
Drop the Samsung tarball on top of the checked out tree, and diff it. (Don't go erasing what's already there like I do with other projects.)
Code:
git diff > ../<TAG>.patch
Keep going until you find the patch that is the smallest. This is likely the CAF base that Samsung started from.
Click to expand...
Click to collapse
Why does this matter? My diffs went from 24MB to 4MB and is a lot easier to see what may be going on.
When we do get to find the branch point it will make a huge difference when I pull a more recent version and then want to apply that patch to the newer version.
Entropy, had another question... In stock kernels I would normally patch Linux before doing anything else.
I'm assuming I'll want to grab the latest jb_2.5, patch Samsung's mods in first and wait until we get stable before patching Linux versions?
Just because we add Samsung's mods in doesn't mean everything will work perfectly as-is... and that logically would need addressed before anything else.
And still waiting for my build box to come up - the host is having their ISP issues addressed. Thankfully the home dual boot works great for simple things like these kernel diffs.
garwynn said:
As embarrassing as this may be for me, let my facepalm teach others...
Read advice from mentors well.
And if not sure, read it again. And if still not sure, read it again.
Bold and italics below are my emphasis.
Why does this matter? My diffs went from 24MB to 4MB and is a lot easier to see what may be going on.
When we do get to find the branch point it will make a huge difference when I pull a more recent version and then want to apply that patch to the newer version.
Entropy, had another question... In stock kernels I would normally patch Linux before doing anything else.
I'm assuming I'll want to grab the latest jb_2.5, patch Samsung's mods in first and wait until we get stable before patching Linux versions?
Just because we add Samsung's mods in doesn't mean everything will work perfectly as-is... and that logically would need addressed before anything else.
And still waiting for my build box to come up - the host is having their ISP issues addressed. Thankfully the home dual boot works great for simple things like these kernel diffs.
Click to expand...
Click to collapse
You mean pull in patches from kernel.org? I personally don't do that any more - it usually causes more problems than it is worth. The only time I've done that was a situation when I had to match d2's wifi backport on 4412 devices.
So far, devices in CM are a mix of two approaches:
1) The old (and usually quick) approach of taking the manufacturer tarball and dropping a bulk update from mako onto it. Since this is a MUCH newer CAF base and is 4.2.2 - this may not be necessary. You may just be able to get the kernel running CM10.1 with not much modification.
2) Chunk up the manufacturer's diffs and rebase them onto the latest jb_2.5 - d2 has done this, HTCs are in the process of doing so, and Sonys are probably going to do so in the next month or two. Same for Oppo Find5 - we used approach 1 initially, but are switching to 2.
For your sanity, you probably want to chunk up the manufacturer's diffs into smaller parts if you can. The workflow I used was:
Check out the closest CAF tag once you determine it.
Check out a new branch at this point using
Code:
git checkout -b <branchname>
In my case, I named the branch for find5 find5_CAFTAGHERE so I would always remember the tag.
Drop the kernel tarball on top of the CAF tag
Commit the whole big mess
Now, here's the fun part:
Unstage some files out of the commit. For example, if you want to unstage drivers/media/video out, do:
Code:
git reset HEAD^ drivers/media/video
Then
Code:
git commit --amend
This will remove the changes from drivers/media/video from the megacommit
Then
Code:
git add drivers/media/video
git commit
Commit just those changes. Try to find associated headers if you can from include/
Now, if you just split out one commit:
Code:
git rebase -i HEAD~2
to switch the order so the megacommit is the last commit for further chunking.
It's time consuming but makes the chunks much easier to analyze.
When I get home, I'll post my bash alias 'gitshowfiles' which shows a list of all files changed by the last commit. It's hightly useful.
When you're done, you'll have a nice reference like:
https://github.com/Entropy512/kernel_find5_reference/commits/find5_A8064AAAAANLYA101034
With the build box back in business I finally got to the point Entropy was talking about.
For reference here is the commit:
https://www.codeaurora.org/gitweb/q...it;h=b5075e02c2ff1d959c589552c62329c4797b0535
And I've attached the diff file so those following along can keep doing so.
(I've posted the same stuff on CM's Jira as well)
So I'll start 2 repos next.
1) Fork current CAF jb_2.5 to a new repo.
https://github.com/garwynn/kernel_samsung_jflte
2) Fork above version to this repo:
https://github.com/garwynn/i9505_CAFDiff
...where I'll start the process of splitting the big diff into smaller ones, just in case they are needed.
Now it's possible that Sprint's kernel could have branched off differently but there's an easy way I can think of to check that. Take the i9505 kernel source I have now, drop Sprint's on top and run a diff to see how different they really are.
And just an update. Sprint's GS4 is making its way to folks today. One person already has and I'm trying to get what I need to really get going.
Update 1: Odin mode shows "Write Protect Enabled" - wondering if this means bootloader is locked.
Few updates while I get things moving.
A second look at that LA kernel had what seems to be everyone's defconfig. Added and pushed to common kernel.
You'll probably need to combine your specific additions still to jf_defconfig to get a full one.
At least the Sprint one identifies an Audience audio chip and binary that should be there.
Did an initial push of common device folder after confirming Sprint's fstab matches common i9505.... so I'm guessing they're all the same. It's very rough so wouldn't try using it yet... just want access to it in case I pull to my home box. Now working to get a device specific one up enough to try a CWM build. Going to have to hold testing anyhow until we get a full restore and figure out about that write protect.
OK, for those not following the SPH-L720 thread, I'm doing test builds of CM/CWM at the moment to see what I can get working before I move over to the kernel.
I tried including msm8960-common and it failed on kernel issues. Think I'm going to leave it out for now and try just getting the CAF jb_2.5 to build successfully first. I can leave in qcom-common and that seems to at least play nice.
CWM working for SPH-L720 but users reporting that moving up/down requires 2 key presses to get it to move. Alpha 5 was reported as losing External SD card functionality - not sure why as I didn't change the fstab. i9505 users reporting that it didn't work, suggesting there may be a difference. We better nail that down and if need to move something from common to variant, do so before others start building off of it.
I'm starting to read the Find 5 configs as it seems one of the only ones with the Adreno 320 config. But again, I've got to get the kernel to build before I start really getting into this stuff.
I'll push updates to repos tonight after I get another successful build.
Related
Well, now that it's up and running it's time to properly set this thread up.
The idea of this thread is to provide a kernel repo that most can use to build their own.
I'll be building and posting the builds from this without modification.
May 29, 2014 Update: I have added the NE2 Kitkat kernel and built but it will remain untested.
I'll try to see if someone can test but it doesn't look like much has changed from MK4.
Project Repositories:
NE2 (4.4) (Initial Setup Only)
https://github.com/garwynn/L900_NE2_Kernel
MK4 (4.3) (WIP):
https://github.com/sleshepic/l900_MK4_Kernel (Thanks to sleshepic for his work on this!)
MC2:
https://github.com/garwynn/L900_MC2_Kernel
Older Versions (Development has stopped)
MA7 | LJC
Project Status:
NE2:
I've used the same as MK4 to make a test kernel. Untested though without a N2.
MK4:
Still trying to get a full boot.img together, stay tuned.
MC2 Status:
Kernel patched to current Linux 3.0.x (.71 at time of update)
Stock governors enabled, 6 additional ones added.
Project Downloads (Built Kernels):
My kernels are currently housed by rwilco12's Android Stock Repo. (All versions)
To compile on your own you need:
1) Linux Box - I'm using Ubuntu 14.04 and all prerequisites for building AOSP.
2) Android SDK with toolchains - I used arm-eabi-4.4.3 all the way through NE2.
3) Cloned repo from above.
Just modify the toolchain location in ./build_n2.sh and execute ./build_n2.sh.
Rest should go on its own.
On some cases I had to also change the toolchain location in main makefile.
Releasing/Posting your Kernels:
Folks are encouraged to try building the kernel and posting it if they want to.
Any posts should refer to using the kernel as their base.
If you modify the code further outside of this you should include a link to your repo for others to see those changes.
Anyone interested in chipping into this is more than welcome!
Thank you in advance for your time!
I've been playing, digging, etc for about a year now. Ive been attempting my first rom build and I think im really close. Its a 4.2 rom, so its been a challenge.
But I would love to participate in this too if its open to everyone.
Sent from my SPH-L900 using Tapatalk 2
cbucz24 said:
I've been playing, digging, etc for about a year now. Ive been attempting my first rom build and I think im really close. Its a 4.2 rom, so its been a challenge.
But I would love to participate in this too if its open to everyone.
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
That's the goal! It slowed down on the E4GT but it's hopefully going to heat up again soon.
The more people that get involved, the better the kernel should end up - and the more that fellow XDAers learn and share knowledge!
Talk to sleshepic. He built a kernel for his rom.
Sent from my SPH-L900 using Tapatalk 2
Self-plug below. It should get you started on kernels.
http://forum.xda-developers.com/showthread.php?t=1748297
btbamzao said:
Talk to sleshepic. He built a kernel for his rom.
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
Agat63 showed him and also is willing to show me but catching him will be tough for the next 3 weeks.
So that's what I'll go with if we can't get something cobbled together before then.
garwynn said:
Agat63 showed him and also is willing to show me but catching him will be tough for the next 3 weeks.
So that's what I'll go with if we can't get something cobbled together before then.
Click to expand...
Click to collapse
Agat was def helpful as always. The way I ended up doing it was slightly dif than the way he does it on the S3, really similar though. im really busy for a couple days but when I get to my comp with some time ill type up what I do.
My git wouldn't be a good source to clone from just cus my first commit had a few changes already, but it def would be helpful to get a working repo together with the Cypress touch drivers already placed in source - did they forget them or what lol. Could try getting that together too.
sleshepic said:
Agat was def helpful as always. The way I ended up doing it was slightly dif than the way he does it on the S3, really similar though. im really busy for a couple days but when I get to my comp with some time ill type up what I do.
My git wouldn't be a good source to clone from just cus my first commit had a few changes already, but it def would be helpful to get a working repo together with the Cypress touch drivers already placed in source - did they forget them or what lol. Could try getting that together too.
Click to expand...
Click to collapse
Thanks for the assist!
I'll try to commit a fresh LJC repo over the weekend then and we can go from there.
Hope I don't mess that up. I'll ask if I have any ??s.
Well, I made a repo here:
https://github.com/garwynn/L900_LJC_Kernel
...and followed the kernel readme instructions. Looks like it's compiling.
*Edit* ...and failed. arm-eabi-nm missing in toolchain I'm using.
(Wait, it's right there!)
Code:
/root/Kernel/L900_LJC_Kernel/scripts/mksysmap: line 44: ~/Kernel/toolchain/prebuilt/arm-eabi-4.4.3/bin/arm-eabi-nm: No such file or directory
make: *** [vmlinux] Error 1
How about a Modem Repo? Like on the Epic Touch
Avatar said:
How about a Modem Repo? Like on the Epic Touch
Click to expand...
Click to collapse
Rwilco12 - when he has time - is going to set up a Kernel/ROM/Modem Repo... at least time I talked to him.
Cool.
garwynn said:
Well, I made a repo here:
https://github.com/garwynn/L900_LJC_Kernel
...and followed the kernel readme instructions. Looks like it's compiling.
*Edit* ...and failed. arm-eabi-nm missing in toolchain I'm using.
(Wait, it's right there!)
Code:
/root/Kernel/L900_LJC_Kernel/scripts/mksysmap: line 44: ~/Kernel/toolchain/prebuilt/arm-eabi-4.4.3/bin/arm-eabi-nm: No such file or directory
make: *** [vmlinux] Error 1
Click to expand...
Click to collapse
Here is what my build looks like, in general. I have my toolchain referenced in the first export (which could also be easily put in the makefile so its not needed each time)
$ export CROSS_COMPILE=/media/Android/Kernel/toolchain/prebuilt/arm-eabi-4.4.3/bin/arm-eabi-
$ make t0spr_04_defconfig
$ make menuconfig (this is not necessary, and possibly not recommended unless you know what your changing etc, or could be manually edited in the file)
$ make modules
$ make -j5 (the -j5 is optional, I have a quad core processor so this just speeds things up, if you believe your comp is capable of faster than standard builds put the number of cores plus 1 for the number after "-j" )
Then that will build the zImage into the /arch/arm/boot directory.
Which we then bundle with the ramdisk to create the boot.img.
On the Epic Touch all we needed was the zImage for the kernel since the initramfs were bundled differently, but it's dif on our Note 2's. you'll need the ramdisk and zimage to make your boot.img. I pulled the ramdisk from the stock kernel.
I use
$ ./unpack-bootimg.pl boot.img
to pull the "ramdisk-contents" from the stock kernel, I renamed that folder "initramfs" and threw it in a folder along with my mkbootimg binary, and my zImage I just compiled. you can put this anywhere, I just put it in my working kernel folder so it's easy to navigate to
I put the newly created modules from zImage build in my initramfs/libs/modules with
$ find -name '*.ko' -exec cp -av {} [path to desired folder] \;
I navigate to the initramfs folder and
$ find .|cpio -o -H newc > ../ramdisk
$ cd ..
$ gzip ramdisk
$ ./mkbootimg --kernel ./zImage --ramdisk ./ramdisk.gz --board smdk4x12 --base 0x10000000 --pagesize 2048 --ramdiskaddr 0x11000000 -o boot.img
That last part is what bundles the zimage and ramdisk into the boot,img. sorry I had to rush it, hope i didn't miss much, can fill in the blanks as needed, just I'd get up whatever I could when I found a moment, open to help in any way I can.
Edit: Also, checked out the repo put up, Nice work so quick! this is the folder I mentioned that needs to be added or else the capacative touch keys won't work, unbelievable that that was missed in the source drop. I mean, isn't it supposed to be a buildable working version for it to meet open source standards? guess not. anyway, this "cypress" folder needs to be added to the source prior to build for the two touch keys to work. first time I finally got mine booting and all I was so psyched only to find out my touch keys didnt work, so frustrating. Just have to pull it from other source, or you can grab it from mine
https://github.com/sleshepic/Note_2_l900/tree/master/drivers/input/keyboard/cypress
Big thanks to agat63 and Andreilux for help along the way
Nice stuff here, will be following this thread. Here is another repo with fresh LJC kernel source with cypress drivers included https://github.com/slickrick/L900_Kernel
thewadegeek said:
Self-plug below. It should get you started on kernels.
http://forum.xda-developers.com/showthread.php?t=1748297
Click to expand...
Click to collapse
Mind if include this in OP revision after Phase 1 is finished?
Also thanks for the quick responses... will try to get to it this weekend but will probably be Monday. Sucks but that's the way it will be a few more weeks.
Sent from my SPH-L900 using Tapatalk 2
garwynn said:
Rwilco12 - when he has time - is going to set up a Kernel/ROM/Modem Repo... at least time I talked to him.
Click to expand...
Click to collapse
Working on it as we speak! I was able to finish the week with only 10 hours of overtime and had some free time to work on some projects.
Got one or two little things to sort out in the PHP but here's a sneak peek of what I've got coming! It's a complete rework of my original Repo for the E4GT with more devices and more goodies!
If there are any PHP gurus (or web design in general) and you're willing to help hit me up and maybe I can get over this last hurdle and make the New Repo public!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
garwynn said:
Mind if include this in OP revision after Phase 1 is finished?
Also thanks for the quick responses... will try to get to it this weekend but will probably be Monday. Sucks but that's the way it will be a few more weeks.
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
Nope feel free.
Sent from my SCH-R950 using Tapatalk 2
Well.. work on this may be pushed back a day or two, new source for the E4GT. Gotta look at it first.
Hi everyone.
I'm here by invitation and will try to participate as much as I can.
Hopefully with combined knowledge and power we can make this
project move faster.
agat63 said:
Hi everyone.
I'm here by invitation and will try to participate as much as I can.
Hopefully with combined knowledge and power we can make this
project move faster.
Click to expand...
Click to collapse
Okay... here's where I still stand.
Added Cypress and pushed a commit to Github.
Make still is good up until VMLinux and fails.
Didn't know I can just skip to here so here's the command and output:
Code:
[email protected]:~/Kernel/L900_LJC_Kernel# make vmlinux
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
LD vmlinux
SYSMAP System.map
/root/Kernel/L900_LJC_Kernel/scripts/mksysmap: line 44: ~/Kernel/toolchain/prebuilt/arm-eabi-4.4.3/bin/arm-eabi-nm: No such file or directory
make: *** [vmlinux] Error 1
Where should the vmlinux object be? It's trying to create system.map so I suspect that vmlinux is not being created properly.
I dumped a debug output from this make but it's 115MB.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hi all!
After all the mess I had while testing MR2 on our Xperia S using the legacy video drivers, I decided it's time to get us a proper base on which all future Nozomi developments can be based. I want this to be a community project, so I'd like to encourage any available developer to contribute, and of course we also need testers to get proper bug reports, logcats, kernel logs. If these sound familiar to you, and you know what you're doing, you might be the person we are looking for!
Before you start reading the following, let me be very clear about one point here:
Never underestimate the power of open source.
The Xperia S (Codename Nozomi) is based on the Sony Fuji board which itself is based on the Qualcomm msm8660 (8260) platform, which features a Snapdragon S3 CPU chip and together with the Adreno 220 GPU and the integrated tavarua radio forms the SoC.
As of MR1/Android 4.2.X, the msm8660 chipset is officially abandoned by Qualcomm. This means: No official support from CAF for our chipset anymore, which, on a further note, means that we have to adapt >=msm8960 drivers to match the >=MR1 userspace grahpics drivers.
Related to the msm8660 ASoC, we are using MDP 4.1 compatible hardware, whereas recent CAF kernel branches focus on >=MDP 4.2 support for newer chipsets.
Paying attention at the driver merge in the kernel should be top priority, in combination with excessive debugging and hard work, we can achieve a better running system than some other 'officially' supported devices on MR1/MR2, like the Xperia T (msm8960).
Long story short, here is the current progress on my current CAF based kernel:
What is (basically) working:
msm_fb - framebuffer (upgraded to match MR2, sync point support)
msm_vidc - video encoding/decoding drivers (upgraded to match MR2, 1080p support)
msm_rotator - image rotator (upgraded to match MR2, sync point support, fast YUV not yet enabled for msm8660)
msm_kgsl - KGSL driver (upgraded to match MR2 (jb_2.5))
msm_gpu/adreno driver (upgraded to match MR2 (jb_2.5))
msm_iommu - page mapping (upgraded to match MR2 (jb_2.5))
msm_qdsp6v2 (upgraded to match MR2 (jb_2.5))
sound/soc (upgraded to match MR2 (jb_2.5))
What needs to be tested:
ION memory allocation (upgraded to match MR1 (mako) - unsure if it needs to be patched)
What definately needs to be worked on:
msm_fb fence syncing - causes massive lags
..? - Soft reboots when browsing Gallery
Now coming to the resources that I (preferably) use to upgrade our kernel, there are various kernel sources that don't quite match each other's APIs, so please pay special attention when contributing:
1) Samsung Galaxy SII (Skyrocket Board, msm8660): GitHub reference
2) Sony Xperia T (Blue board, msm8960): GitHub reference
3) More to come...
If you take a look at my kernel source, you can easily see the first thing I did was bringin up our kernel space video drivers to jb_mr1_chocolate. Despite being compatible to Android 4.2.X, (and the best branch to do the dirty bringup, because chocolate branches are meant for stabilization) there are a few crucial things to watch out for:
#1 - Do not mess with the ION allocation API unless you really want to change the API kernel-wide. By default, jb_mr1_chocolate uses a different ION api than our mako-based ION and IOMMU drivers. If you just blindly merge LK 3.0.y sources into our LK 3.4.y branches, be prepared to end up having various page mapping/allocation faults.
#2 - Watch out for mdp/rotator IOMMU split changes. In all our current kernels, we use IOMMU domain splitting to gain finer granularity which is needed for secure playback. A very good example on what to look out for is a commit I made recently to patch jb_mr1_chocolate video drivers to use the domain splitting technique again: https://github.com/OpenSEMC/android_kernel_sony_msm8x60/commit/4fed72fb2e12d16df1d137247c63b45477bad624https://github.com/OpenSEMC/android_kernel_sony_msm8x60/commit/4fed72fb2e12d16df1d137247c63b45477bad624
#3 - Watch out for buffer mapping changes (display_iova). As shown in the commit above, jb_mr1_chocolate by default uses diferent code to map framebuffer memory than our LK 3.4.y kernel does.
You can find my current kernel sources at OpenSEMC's GitHub repository:
ALPHA ---GitHub
BETA ---GitHub
I am actively contributing to and mainting this branch. The final goal is to have a kernel that matches the requirements of the latest Android iteration available. It'll be a long way until we reach that goal, but I am sure we can do it.
XDA:DevDB Information
CAF kernel for Fuji boards, a Kernel for the Sony Xperia S
Contributors
RaymanFX
Kernel Special Features:
Version Information
Status: Beta
Created 2013-09-27
Last Updated 2013-10-03
PROGRESS!
[09/28/2013] It boots! Graphic drivers are quite stable, no random reboots. Switching the project over to BETA stage.
[09/30/2013] Succesfully backported msm_vidc and KGSL/Adreno driver from jb_2.5!
[10/02/2013] Upgraded KGSL/Adreno driver to jb_2.6
[10/02/2013] Modified msm_rotator to improve the compability to our video drivers
[10/03/2013] Merged CAF's jb_2.5 sources into our kernel
[10/03/2013] Upgraded sound/soc and qdsp6v2 to jb_2.5
[10/03/2013] Upgraded msm_iommu to jb_2.5
[10/03/2013] Imported UHID driver from Linux 3.8
I'm not a dev,but i'm really happy about the caf, long live this project.
Sent from my LT26ii using XDA Premium 4 mobile app
Awesome! This could be a huge thing, I'll certainly keep an eye on it, sign me up for some testing!
More kernels are always good.
it must be a great job !
@RaymanFX Good Work! Bro.. Looking forward in your Sources.
---------- Post added at 09:37 AM ---------- Previous post was at 09:11 AM ----------
[/COLOR @RaymanFX recommended to add this At XDA News. Thanks.
TrinityHaxxorX said:
@RaymanFX Good Work! Bro.. Looking forward in your Sources.
---------- Post added at 09:37 AM ---------- Previous post was at 09:11 AM ----------
[/COLOR @RaymanFX recommended to add this At XDA News. Thanks.
Click to expand...
Click to collapse
Yeah.. Good work on the recommendation bro.. This is really worth it.. :good:
We reached BETA stage!
I managed to get a cm-10.2 rom with latest CAF display drivers booting!
There are some issues to be fixed, e.g. some minor animation stuttering (probably related to fence syncing) and broken video playback (easy), but this project advances way quicker than I expected it to.
I updated the source links and fixed all compilation errors. You can now build the project yourself
A public beta test version should be out soon!
RaymanFX said:
We reached BETA stage!
I managed to get a cm-10.2 rom with latest CAF display drivers booting!
There are some issues to be fixed, e.g. some minor animation stuttering (probably related to fence syncing) and broken video playback (easy), but this project advances way quicker than I expected it to.
I updated the source links and fixed all compilation errors. You can now build the project yourself
A public beta test version should be out soon!
Click to expand...
Click to collapse
Gooodjob! .
Sent from my LT26ii using xda app-developers app
OMG A GOOD 4.3 GOING TO BE OUT SOON!!!
Sent from my LT26ii using XDA Premium 4 mobile app
Great work, looking forward to it.
Sent from my Xperia SL
RaymanFX said:
We reached BETA stage!
I managed to get a cm-10.2 rom with latest CAF display drivers booting!
There are some issues to be fixed, e.g. some minor animation stuttering (probably related to fence syncing) and broken video playback (easy), but this project advances way quicker than I expected it to.
I updated the source links and fixed all compilation errors. You can now build the project yourself
A public beta test version should be out soon!
Click to expand...
Click to collapse
You are truely a ninja my friend.
Update from today:
* Backported VIDC, IOMMU, ION and KGSL from jb_2.5, so we're on par with recent high-end devices.
This will also save us the hassle of the untested ION/IOMMU stuff (which is on a MR1 level currently anyways.
Additionally, it will bring us proper graphics drivers (atleast I hope so, I did some early testing with GTA III, and it played just fine).
The new msm_vidc encoder/decoder drivers will also allow us to use CAF OMX libraries instead of mako ones which were patched to work with the CAF display drivers.
The next patches will also bring back Bluetooth keyboard support for Jellybean (UHID was needed).
Things are getting proper !
RaymanFX said:
I updated the source links and fixed all compilation errors. You can now build the project yourself
Click to expand...
Click to collapse
I tried and indeed the ROM builds without errors. I can flash it and recovery seems to be working.
But it will not boot. After the "OpenSEMC" boot splash there is no CM-bootlogo and a black screen forever.
I used "cm-10.2" manifest and changed kernel to "jb_mr2_chocolate_beta" prior on sync.
DeJe63 said:
I tried and indeed the ROM builds without errors. I can flash it and recovery seems to be working.
But it will not boot. After the "OpenSEMC" boot splash there is no CM-bootlogo and a black screen forever.
I used "cm-10.2" manifest and changed kernel to "jb_mr2_chocolate_beta" prior on sync.
Click to expand...
Click to collapse
It Just Mean it use dif.. Display drivers. that happens with me before.
TrinityHaxxorX said:
It Just Mean it use dif.. Display drivers. that happens with me before.
Click to expand...
Click to collapse
Well, what are these mysterious dif. display drivers? Do you have a solution or just say it isn't possible to build bootable ROM with current cm-10.2?
DeJe63 said:
Well, what are these mysterious dif. display drivers? Do you have a solution or just say it isn't possible to build bootable ROM with current cm-10.2?
Click to expand...
Click to collapse
Different display drivers?
To a man still learning, if it doesn't say exactly what is meant, then it doesn't mean that.
A lot of words start with dif...
And yes, it is possible to build a bootable ROM. Check the CM10.1 thread, somebody shared his build there.
DeJe63 said:
I tried and indeed the ROM builds without errors. I can flash it and recovery seems to be working.
But it will not boot. After the "OpenSEMC" boot splash there is no CM-bootlogo and a black screen forever.
I used "cm-10.2" manifest and changed kernel to "jb_mr2_chocolate_beta" prior on sync.
Click to expand...
Click to collapse
I havent checked myself but maybe use hardware/qcom/display-caf and audio-caf from cyanogenmod?
Sent from my LG-D802 using xda app-developers app
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Disclaimer: OctOs is a WIP. It has been evaluated as being stable, and is suitable for daily use in most cases. While it may be considered stable, there may be unknown bugs. The development team is not responsible for any damage to your device or your information.
Click to expand...
Click to collapse
Team OctOs presents Oct-M.
We maintain a current release record and change-log on our website: http://www.teamoctos.com
- Please Do Not Mirror our files without talking to us. We can do that ourselves should we desire to. -
Team OctOs would like to thank Team Blackout for the use of their Blacked Out Nexus Launcher & for saving eyes one app at a time!
You can get all the TBO goodies here as well as the TBO Updater http://teamblackedout.com/ #whiteuimustdie
TBO thread http://forum.xda-developers.com/showthread.php?p=41545802
Frequently Asked Questions
Q: Is this Android 6 (Marshmallow)?
A: Yes, this is Android 6.0.1
Q: What code is Oct-M based on?
A: Starting with Oct-L, we've rebased OctOs on the CyanogenMod 12 code. Oct-M is base on CyanogenMod 13.
Q: What happened to AOSP?
A: All Android code is based on the Android Open Source Project (AOSP). Under previous releases, we tried very hard to limit the number of "Not from Google directly" repositories that we used. Unfortunately, issues with devices, the need for Code Aurora Foundation (CAF) repositories for Qualcomm devices, and compatibility issues meant fighting code more often than not. We decided that since the code-base for many repositories were the same across most ROMs, picking a starting point to build the user experience on outweighed the desire to craft code from scratch, or fix broken code to make it work with other changes we already had.
Q: Why isn't there XXXXXXX feature.
A: Shoot us a Suggestion if you want to see something added. While we are not going to promise to implement, we will always look into it
Q: But XYZ and all the others have..
A: ROM developers, build something they want to use. The ROM developer that includes something they won't run implies less than 100% effort to ensure it does work. As a team, we have similar goals and objectives. If XYZ ROM has a feature you want, and we don't include (or don't want to include), feel free to use XYZ ROM, or build your own custom version of Oct-M.
Q: Superuser or SuperSU?
A: Team OctOs uses SuperSU and is installed automatically.
Bugs:
Bugs happen. Our testers are very good at breaking things, but no where near as good as the rest of the Android public. In order to investigate and fix issues, we need the help of the users who are going to report them. The Android OS has many nifty features to help us in this, but only if we can engage the user to assist us.
Logs, Logcat, and the Android Debugging Bridge (ADB)
Like any other OS, Android has multiple log files that are generated and record the goings-on of the system. As a user, you have two basic ways to view and pull these to send to us. Without the information in the logfiles, there simply is not a whole lot of information to go on.
Log file APKs
Team OctOs recommends SysLog from the Android Market. This application will allow you to selectively pick any (or all) of the system logs, compress them into a .ZIP file, and allow you to save, email, move to your Copy/DropBox/Cloud Storage account, etc.
ADB Logcat
The Android Debugging Bridge (ADB) is a powerful tool available from Google as part of the Android Software Development Kit (SDK). Used for many things, being able to selectively see, in real-time, what your device is doing cannot be downplayed. While there is more setup involved, if you are doing consistent ROM flashing, you really should invest the time to get setup properly to do it.
ADB Logcat tutorial here: How to create a logcat log
Basic Instructions:
Download ROM .zip file and MD5 file, and grab your favourite Opengapps package http://opengapps.org/
Reboot to Recovery (Note: Use Reboot to Recovery from Power Menu, Hardware-based boot to recovery, or adb reboot recovery - ROM Manager or similar software is NOT supported)
--- TWRP is the ONLY recovery Team OctOs uses - We do not support flashing on CWM ---
Factory Reset from TWRP
Flash ROM and GApps .ZIP files
Reboot
The Oct-M ROM installation script will automatically wipe /system, /cache, and /data/dalvik-cache. There is no need to do these before or after flashing the ROM unless you are instructed to by your GApps Provider
The foundation of the Android OS is the fact that is it open-source. We have all code we use internally in the creation of Oct-M available on our GitHub repositories.
Unless otherwise specified, all Oct-M builds use the device's stock CyanogenMod 13 kernel.
Kraken kernel source code can be found here: https://github.com/Oct-mm
Team OctOs GitHub - http://www.github.com/Team-OctOs
Team OctOs Gerrit Review - http://www.teamoctos.com:8080
Team OctOs GPLv2 License - http://www.teamoctos.com/license/
Team OctOs Patreon Campaign - https://www.patreon.com/TOctOs
Want To Build Your Own?
Check out the ReadMe on our GitHub for Instructions
Special thanks to
Our testers, without which, there would be no public releases for OctOs
We would also like to thank
OpenGapps
CyanogenMod
OmniROM
LiquidSmooth
Anyone else who has ever submitted Open-Source code
Click to expand...
Click to collapse
Follow Us at the various websites below!
XDA:DevDB Information
Oct-M, ROM for the T-Mobile Samsung Galaxy S III
Contributors
bthorne79, CjKacz, canodroid15, hedwig34
Source Code: http://www.github.com/Team-OctOs
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.4.x
Based On: CyanogenMod 13
Version Information
Status: Stable
Current Stable Version: OCT-M R2
Created 2015-02-17
Last Updated 2016-08-26
Reserved
Known Issues
A full list of Known Issues resides on our website. *In order to avoid confusion for people who skimmed the OP,
NONE REPORTED FROM TESTERS
Thanks OP
downloading now..
:good:
bthorne79 said:
Known Issues
A full list of Known Issues resides on our website. *In order to avoid confusion for people who skimmed the OP, the biggest Known Issue with the Galaxy S3 (d2lte) platform is the Camera. *It could cause Force Close issues. *This is an upstream issue, and we are working to correct it.
Click to expand...
Click to collapse
Please put this info and list other bugs in the OP so that people won't be misled. Not everyone reads past OP.
goldentequila said:
Please put this info and list other bugs in the OP so that people won't be misled. Not everyone reads past OP.
Click to expand...
Click to collapse
Sorry but the inability to read is the users issue. Half the time they don't even read the OP. Go right to the download link. I posted in the 2nd post and there is a link in op to site with bug list and change log
Sent from my SPH-L720 using XDA Free mobile app
Running nicely right now. Had a hard time getting WiFi to connect on first boot but its working now
We put the information on the website because its easier to keep track of across the multiple devices we develop for. We develop the ROM for the simple fact we want to run it, not for you, or anyone else. The ability to be cognizant on what you're doing is a primary requirement for flashing ROMs, and the inability for you to apparently read and comprehend the very simply formatted OP means you are not willing to rise to the level we seek in a user.
It would be better for everyone involved if you don't flash Oct-L. You have many ROMs to choose from, you shouldn't choose ours.
ROM Development is not a service or product industry. You are neither a customer, or a client. Your demands mean exactly nothing and we have better things to do than hold your hand.
Now, if you feel like running what we build, by all means, do so. However, your continued patronage to the thread is directly proportional to your ability to be civil and not condescending.
Enjoy, or not at your leisure, but unless you have something constructive to say, please wander to another ROM.
Toodles!
Running smooth. ^.^
lol bitter much? Don't ruin this for the rest of us who rely on devs like these guys to continue providing up to date software for our aging phones.
I'm definitely trying this ROM out.
From the Moderator
To all in this thread........
Please all remember, the Devs do this for free and out of their love for developing....
....So being rude and poor mannered...... gets you nothing but maybe one less Dev making Roms for your phone
Keep that in mind when you feel like you have some lame commentary or demand to make...
........To the trolls, rather than complaining...... show us your skills and make a ROM for us to critique.......
........oh yeah...... you have no skills other than running yer mouth and making personal demands in a thread.......
~~~ oka1
The strangest thing is him talking about the OP not listing a Buglist. The Rom that he his visiting the most does not either. With that said I'm done. Mod can in and slammed the hammer down on that issue.
Please any one using this rom if you do see anything and and are able to catch a log please report and send log to us.
Thanks for supporting Team OctOS
Sent from my SM-T217S using XDA Free mobile app
Is the nav bar included in this release? Working?
allendj81 said:
Is the nav bar included in this release? Working?
Click to expand...
Click to collapse
Sure! About the only thing that doesn't work is the camera!?
Installed this Rom and turned on wifi but after login to my account wifi stopped and grayed in off position
Rebooted device and wifi got on but every time failed to login
Again rebooted and it started working correctly
Reached office but again failed to connect to wifi
It is just an information as I read same thing happening with other cm12 build too so this may be with the cm12
anil2653 said:
Installed this Rom and turned on wifi but after login to my account wifi stopped and grayed in off position
Rebooted device and wifi got on but every time failed to login
Again rebooted and it started working correctly
Reached office but again failed to connect to wifi
It is just an information as I read same thing happening with other cm12 build too so this may be with the cm12
Click to expand...
Click to collapse
What firmware is your phone on I've noticed that the newest modems and firmware is needed for lollipop to work correctly. These builds have been in test for quite some time. Our testers have put this build through the ground with not one hick-up just camera which we have been working on getting fixed.
If you can get a log of the WiFi issue you are having we will look at it. My suggestions is to update to the latest modem firmware for d2tmo.
Sent from my SPH-L720 using XDA Free mobile app
allendj81 said:
Is the nav bar included in this release? Working?
Click to expand...
Click to collapse
canodroid15 said:
Sure! About the only thing that doesn't work is the camera!
Click to expand...
Click to collapse
The Navbar will cover the "Clear All Recents" button if you select the lower right or left position. This already has been corrected for the next release.
Thanks a lot for this amazing rom, i´ll install it as soon as it finish downloading, but one question, it´s the same instaling it in cwm? i mean, does it makes a diference like more bugs or things like that, i hope you understand Thanks a lot!
vick007 said:
Thanks a lot for this amazing rom, i´ll install it as soon as it finish downloading, but one question, it´s the same instaling it in cwm? i mean, does it makes a diference like more bugs or things like that, i hope you understand Thanks a lot!
Click to expand...
Click to collapse
Our d2tmo user still uses CWM as the team we suggest TWRP only cause CWM is almost a dead recovery and has been know to cause bad flashes..
Sent from my SPH-L720 using XDA Free mobile app
vick007 said:
Thanks a lot for this amazing rom, i´ll install it as soon as it finish downloading, but one question, it´s the same instaling it in cwm? i mean, does it makes a diference like more bugs or things like that, i hope you understand Thanks a lot!
Click to expand...
Click to collapse
Also, CWM has had historical issues with actually wiping the partitions effectively. The "Wipe system, data, cache, dalvik x3" was a reality in the past because of CWM. Those issues don't happen with TWRP.
I noticed a couple of things:
1) When flashing the ROM it takes a while. Compared to other lollipop rom's, this one takes about 3-4 minutes to flash, while others flash in like 15 seconds. Is that normal?
2) Installing apps from the play store are taking a long long time. Each app takes about 2 minutes to install, longer if it's a bigger one like youtube. I've noticed it takes long across all lollipop rom's, but one this one it seems to be longer.
3) Kernel Tweaker crashes when I try to view read-ahead and IO scheduler. This doesn't happen with any other ROM so I'm thinking there's something going on with oct os.
Any thoughts?
Who can build it ??
I could try to Boot it up. Not More. So it have enough bugs for daily use. *troll*
I've been wanting to take a jab at it for some time, but I've been so busy with school especially now with finals coming up. But once finals are over and I'm on break I'll see what I can do.
We got the official cm 12.1 that went to trash more than a year ago. I doubt you sew CM 13.
Sent from my LG-H811 using XDA-Developers mobile app
duongthinh441 said:
Who can build it ??
Click to expand...
Click to collapse
I just started. I am noob with ROM development. Even if I do this would be my first ROM. So dont get your hopes hight. Please let me know if you can help me out with pointers to guides. Just syncing the CM13 repo.
DroidSK said:
I just started. I am noob with ROM development. Even if I do this would be my first ROM. So dont get your hopes hight. Please let me know if you can help me out with pointers to guides. Just syncing the CM13 repo.
Click to expand...
Click to collapse
You can build cm 13???
Like i said ... Just started. Not sure what i will run into. Will definitely post if i am successful.
Sent from my FIND7 using Tapatalk
DroidSK said:
Like i said ... Just started. Not sure what i will run into. Will definitely post if i am successful.
Sent from my FIND7 using Tapatalk
Click to expand...
Click to collapse
Yes thanks bro . yeah i think it run on gpro device
DroidSK said:
Like i said ... Just started. Not sure what i will run into. Will definitely post if i am successful.
Sent from my FIND7 using Tapatalk
Click to expand...
Click to collapse
You have to work ?
Yes i have to work. Will work on this during the weekend.
Sent from my FIND7 using Tapatalk
this is one of the problems with 6.0 on GPRO provided by dev
"I'll be honest: I needed just few more weeks with working USB to get Marshmallow fully functional. I got it running on E988, but some important stuff was broken, thus, device was unusable.
I got it to boot without SELinux - device tree needs new set of rules/fixes on current ones, because some old QCOM rules are dropped from vendor repos since mako isn't officially supported for M. That was ~90% fixed.
There were other problems which made device useless: modem and sensors - main reasons I haven't finished what I started. I had issues with reboots by DSP subsystem on every damn build, and just before my USB died, while experimenting with kernel and init files, I got an idea to disable modem and sensors services (they were causing DSP subsystem reboots) and boom, Marshmallow booted. Managed even to login to my Google account, install apps, use it for a while but had to revert back to LP - main phone without working modem is a tablet, not a phone Unfortunately, some time after that my USB decided to become just a simple charging port, so job was left unfinished.
So whoever is willing to tackle this issue:
- GPU drivers need update, both ion and gpu/msm update (kernel) and libs (need newer libs from mako/flo)
- Modem and sensors HAL need some updating - possibly only libs should be updated, since there were no changes in msm8960/apq8064 3.4 kernels connected to drivers
- Some SELinux stuff needs to be fixed
- Our device is stuck with OpenSSL, Marshmallow uses BoringSSL which has crippled some OpenSSL symbols, so there are some compatibility modules with missing symbols which need to be written... at least, that had to be done back then. Not sure now, it's nearly 5 months later now. Missing symbols can be the reason why both current and Lollipop (kanged from F240) modem/sensors didn't work, I really haven't managed to get usable logs before device's total freeze and reboot with these two services on, so whoever fixes this, well, gets functional Marshmallow
- Camera HAL, our issue since last KitKat days "
But haven't cm13 source code from cyanogenmod
I got some news for you all:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Just booted it. No modem, no network, no GPS, no camera, no sensors. It just boots.
Wow!!!
This device is unbelievable... I've fixed most of selinux rules, fixed missing symbols for RIL - had it crashing only because it couldn't load dsps firmware, and same second I've fixed that, BOOM - kernel panic, reboot. Reason? DSPS subsystem crash... grrrrrrrrrrrr...
EDIT: Crash is caused by sensors; disabling sensors service in init removes that crash, gets firmwares loaded but... that doesn't help our RIL, not at all. And of course there are no error messages from RIL, absolutely none to be found - dmesg simply states "rild-service crashed", logcat is flooded with NFC crashes so I simply don't have nerves to go through all of that... Gah. I really love this device.
Also, I've spotted an interesting problem - I've fixed fstab, both storages are visible, but it seems like I don't have access to external SD - probably something missing somewhere. Also, I think that kernel needs some more commits (I've patched it enough to get SELinux and GPU going, picking anything other than that causes too much conflicts and build issues... and I'm not even using ShadyKernel as a base, started from clean CM12.1 kernel), so I'll try patching google's kernel_msm for E980 support (from KK source drop). possibly something else is broken... who knows? Better question is what isn't broken, lol.
I'll fix that once I get RIL and sensors working. Other than that, Marshmallow is really nicely working on E980, it just needs a lot of work, and a bit more knowledge than I have... well, time to learn.
Whoever is willing to join, kernel is available on my github (lge-kernel-gproj, branch cm-13.0). Device tree and vendor files aren't still uploaded (there are bunch of changes I haven't committed yet), so you may want to wait for them...
Try bro !!
ShadySquirrel said:
This device is unbelievable... I've fixed most of selinux rules, fixed missing symbols for RIL - had it crashing only because it couldn't load dsps firmware, and same second I've fixed that, BOOM - kernel panic, reboot. Reason? DSPS subsystem crash... grrrrrrrrrrrr...
Click to expand...
Click to collapse
Thx for still be trying!
Thanks---I'd love for this to work so I have a viable spare brought back from the dead!
ShadySquirrel said:
This device is unbelievable... I've fixed most of selinux rules, fixed missing symbols for RIL - had it crashing only because it couldn't load dsps firmware, and same second I've fixed that, BOOM - kernel panic, reboot. Reason? DSPS subsystem crash... grrrrrrrrrrrr...
EDIT: Crash is caused by sensors; disabling sensors service in init removes that crash, gets firmwares loaded but... that doesn't help our RIL, not at all. And of course there are no error messages from RIL, absolutely none to be found - dmesg simply states "rild-service crashed", logcat is flooded with NFC crashes so I simply don't have nerves to go through all of that... Gah. I really love this device.
Also, I've spotted an interesting problem - I've fixed fstab, both storages are visible, but it seems like I don't have access to external SD - probably something missing somewhere. Also, I think that kernel needs some more commits (I've patched it enough to get SELinux and GPU going, picking anything other than that causes too much conflicts and build issues... and I'm not even using ShadyKernel as a base, started from clean CM12.1 kernel), so I'll try patching google's kernel_msm for E980 support (from KK source drop). possibly something else is broken... who knows? Better question is what isn't broken, lol.
I'll fix that once I get RIL and sensors working. Other than that, Marshmallow is really nicely working on E980, it just needs a lot of work, and a bit more knowledge than I have... well, time to learn.
Whoever is willing to join, kernel is available on my github (lge-kernel-gproj, branch cm-13.0). Device tree and vendor files aren't still uploaded (there are bunch of changes I haven't committed yet), so you may want to wait for them...
Click to expand...
Click to collapse
LG got a lot of G/Gpro hacks in our current ~LP kernel. You'd probably have an easier time porting what ever changes you needed from the other kernel you're referencing, to our current kernel. Rather than starting fresh. However if sometimes starting fresh is a lil easier if another similar device has done it already, and you have something to hold onto. I wish I could actively help your efforts but apart from not having a booting computer rn lol, school ain't no joke. I'm a senior now and I'm still tryna master my ACT score and start applying for colleges soon
Emmanuel U said:
LG got a lot of G/Gpro hacks in our current ~LP kernel. You'd probably have an easier time porting what ever changes you needed from the other kernel you're referencing, to our current kernel. Rather than starting fresh. However if sometimes starting fresh is a lil easier if another similar device has done it already, and you have something to hold onto. I wish I could actively help your efforts but apart from not having a booting computer rn lol, school ain't no joke. I'm a senior now and I'm still tryna master my ACT score and start applying for colleges soon
Click to expand...
Click to collapse
I do have CAF based kernel (LA.AF.1.1_rb8 + LG patches from Lollipop sources - believe it or not, LG pushed sources for E98x together with F240x ones), ready and booting. It was easier working on that than patching existing one - I don't want to spend few weeks just patchibg things up, like I had for lollipop and gpu driver backport... That kernel is 5.0.2 ready, just have to figure out from where does CM patch those - stuff isn't only from kernel_common... so I'm thinking about similar thing now - google_msm (everything is already there) + kitkat drop patchup, just to get camera and board going.
Our device tree is also a mess, part mako, part Optimus G. Missing lots of things (have you ever unpacked stock boot.img? Damn those inits...) Started working on pure G Pro tree, but that will have to wait for a bit - there is bit too much work, and I have studies to finish, lol. Just lets hope that my USB won't die again, since "fix" I've applied is kind of temporary.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Code:
*** Typical Disclaimer
Not responsible... As is.. Bricked devices... You've read this thousand of times.
Hope everyone here is understanding what he does.
Introduction
This is Unlegacy-Android kernel with some extra features that I added/enabled for personal use and decided to share in case someone else like them too.
I've done all I wanted by this moment so probably I am not going to continuously develop and improve this kernel if there will not be such necessity.
If somebody wishes to co-work or continue, I am all for it. Sources are open.
Click to expand...
Click to collapse
Features
Any bugs/features are the same as on Unlegacy-Android stock kernel except those listed here.
Color control
Allows to adjust display colors (really?).
You need to use third party app like "Trickster MOD" (Requires root) to edit it.
Touch wake and Proximity wake
Old cool feature reworked and improved by me.
Allows to wake device by touching screen and/or proximity sensor.
It's implemented with interrupts and no one wakelocks at all, that means:
No lags. It will always work and will be as responsive as if you pressed power button instead.
(If it still got lag than you would got the same lag if pressed power button at that moment instead.)
Power consumption as minimal as possible. It doesn't keeps device awaken like apps from market, so it can go in deep sleep and not consume power.
The only power is needed is to power the touch screen and/or proximity. It still consumes power but that is neligible.
See proof screenshot below.
You may say that 1.2% per hour is a lot but take in mind that I have 4 years old battery that doesn't work long any longer.
It has no timeouts. Why need them if power consumption is so low?
I've always hated apps from market that works while you play with them and don't in an hour.
But they at least had reason of big power consumption due keeping device awaken.
How to enable and setup:
Again you need to use third party app like "Trickster MOD" (Requires root) to activate and edit it settings.
The property "Delay" sets mode, not delay (I used settings from old version).
Touch - wake device by touching screen
Proximity - wake device by proximity sensor
LongTouch - addition to Touch. If long press screen than device will sleep again after finger released.
Example: Touch and hold, device will wake up you will see what you want (e.g. time), release, device fall asleep again.
1 = Touch
2 = Proximity
3 = Touch and Proximity
5 = Touch and LongTouch
7 = Touch and LongTouch and Proximity
Manually setting from terminal
enabling
Code:
echo 1 > /sys/devices/virtual/misc/touchwake/enabled
setting mode. multiply desired mod on 1000. e.g. 7 = 7000
Code:
echo 7000 > /sys/devices/virtual/misc/touchwake/delay
Click to expand...
Click to collapse
Installation instructions
Code:
*** Disclaimer
This kernel only for [URL="https://forum.xda-developers.com/t/3334574/"]Unlegacy-Android[/URL].
Sure you can try your luck in booting it on another ROM, but that is probably wasting of time.
Prepare your current zimage or boot.img backup for case this kernell will not boot
Boot in bootloader manually or by adb command
Code:
adb reboot bootloader
Flash downloaded zimage with fastboot. Replace zimage-file with path to downloaded zimage.
Code:
fastboot flash zimage zimage-file
Reboot
Code:
fastboot reboot
Sorry for not providing flashable in recovery zip. I had some problems with it.
Click to expand...
Click to collapse
Download
VoronK-zimage-4.4-220117-107103e
For 4.4 builds of Unlegacy-Android
Confirmed working on:
aosp_tuna-ota-20161103 (aosp-4.4)
Confirmed NOT working on:
Probably on other more recent builds
ua_tuna-ota-20170111 (aosp-4.4)
Builded from commit 107103e
Unlegacy-Android base commit ed79e8c
Click to expand...
Click to collapse
VoronK-zimage-5.x-7.x-220117-f6cad32
For 5.x-6.x builds of Unlegacy-Android
Confirmed working on:
ua_tuna-ota-20170116 (aosp-6.0)
Confirmed NOT working on:
Probably on any 7.x build
aosp_7.1_tuna_2016-10-21
ua_tuna-ota-20170122 (aosp-7.1)
Builded from commit f6cad32
Unlegacy-Android base commit 9737080
Click to expand...
Click to collapse
VoronK-zimage-7.x-230117-83de8de
For 7.x builds of Unlegacy-Android
Confirmed working on:
aosp_7.1_tuna_2016-10-21
Confirmed NOT working on:
ua_tuna-ota-20170116 (aosp-6.0)
ua_tuna-ota-20170122 (aosp-7.1)
Builded from commit 83de8de
Unlegacy-Android base commit 5607891
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Changelog
Code:
Current changelog: -- 23.01.2017
[note] -- consider previous VoronK-zimage-5.x-7.x-220117-f6cad32 as not working on 7.x builds, uploaded separate version
[new] -- added [URL='https://forum.xda-developers.com/devdb/project/dl/?id=22814']VoronK-zimage-7.x-230117-83de8de[/URL]
Older changelogs:
Code:
Changelog: -- 22.01.2017
[note] -- First public build
[new] -- added [URL='https://forum.xda-developers.com/devdb/project/dl/?id=22791']VoronK-zimage-4.4-220117-107103e[/URL]
[new] -- added [URL='https://forum.xda-developers.com/devdb/project/dl/?id=22792']VoronK-zimage-5.x-7.x-220117-f6cad32[/URL]
Click to expand...
Click to collapse
XDA:DevDB Information
VoronK, Kernel for the Samsung Galaxy Nexus
Contributors
Voron.exe
Source Code: https://github.com/VoronFX/VoronK
Kernel Special Features: Color control, Touch wake, Proximity wake
Version Information
Status: Testing
Created 2017-01-22
Last Updated 2017-01-23
Reserved
Reserved
Thanks for your reply @Voron.exe
I build VoronK touch-wake from source but it still not boot on 7.1.1. so I applied your commits on the aosp-7.1 branch of UA tuna kernel and resulting kernel boots fine.
Let's me test how touchwake work (tomorrow).
thanks
yen
_yen_ said:
Thanks for your reply @Voron.exe
I build VoronK touch-wake from source but it still not boot on 7.1.1. so I applied your commits on the aosp-7.1 branch of UA tuna kernel and resulting kernel boots fine.
Let's me test how touchwake work (tomorrow).
thanks
yen
Click to expand...
Click to collapse
Cool! I was going to make the same today but you did it first. )
Going to publish that 7.x version a bit later.
UPDATE:
I've try ua_tuna-ota-20170122 (aosp-7.1) build and it doesn't boot even with stock kernel.
What build is the last working?
Ei Voron.exe, thanks for sharing your work.
I just want to point out a wrong link in the first post --> VoronK-zimage-5.x-7.x-220117-f6cad32 (link to 4.4 version).
Only for distracted people like me (I've flashed the 4.4 kernel on 6 build LoL)
Flashed the right version, and all is ok!
thanks!
Voron.exe said:
What build is the last working?
Click to expand...
Click to collapse
I don't know, but I remember @Ziyan saying that 7.1 isn't booting yet, and they're still working on it
Voron.exe said:
I've try ua_tuna-ota-20170122 (aosp-7.1) build and it doesn't boot even with stock kernel.
What build is the last working?
Click to expand...
Click to collapse
None of them, you need to rebuild a permissive kernel to be able to boot 7.1.1. ATM all nougat builds for tuna from unlegacy site bootloops due to some selinux denials.
Plus, to successfully build a tuna kernel from 7.1 ua branch you need to revert these two commits, which borked kernel build:
http://gerrit.unlegacy-android.org/1151
http://gerrit.unlegacy-android.org/1153
Hope it helps.
bye
yen
fiox said:
I just want to point out a wrong link in the first post --> VoronK-zimage-5.x-7.x-220117-f6cad32 (link to 4.4 version).
Click to expand...
Click to collapse
Thank's! My bad. Fixed.
_yen_ said:
None of them, you need to rebuild a permissive kernel to be able to boot 7.1.1. ATM all nougat builds for tuna from unlegacy site bootloops due to some selinux denials.
Plus, to successfully build a tuna kernel from 7.1 ua branch you need to revert these two commits, which borked kernel build:
http://gerrit.unlegacy-android.org/1151
http://gerrit.unlegacy-android.org/1153
Click to expand...
Click to collapse
Oh..
I've spent a day and finally got working version for aosp_7.1_tuna_2016-10-21.zip that I published.
For 7.1.1. no luck. You said that have successfully booted by own build?
I can add your version here if you don't mind, cause I get tired of these rebuilds and don't want to spent more time on version that I am not going to use.
Voron.exe said:
I can add your version here if you don't mind, cause I get tired of these rebuilds and don't want to spent more time on version that I am not going to use.
Click to expand...
Click to collapse
No problem, PM me a way to sent it... I've fresh built touch-wake-7.1 branch, works on today UA build.
Just a bug report: during a phone call proximity sensor is active and if you have enabled "power button end call" in Accessibility menu it hangs call. Thus even if you have enabled only touch or touch and long touch....
bye
yen
It's working flawlessly in ua_tuna-ota-20170116 (aosp-6.0) build, but I haven't tried phone calls. Could you consider to implement, if it's not to difficult, double tap to wake instead of only one tap?
oh my god...new kernel for old Gnex, it is excellent!!!:highfive:
fromfree said:
It's working flawlessly in ua_tuna-ota-20170116 (aosp-6.0) build, but I haven't tried phone calls. Could you consider to implement, if it's not to difficult, double tap to wake instead of only one tap?
Click to expand...
Click to collapse
I've already done workaround for phone calls and some more fixes but not yet published.
As for double tab I will see what can I do. Wait a bit for new versions soon, current is a bit buggy.
UPDATE THOUGHTS:
I am currently thinking on implementing all this in kernel module instead of rebuilding kernel.
The PGM/TouchControl guy did the same, sadly he didn't open sources and abandoned development for few income.
If I'll succeed than probably I'll turn this project into an app.
Okay. I've done some work and have some success with modules.
I am planing to make and app that will allow to add this features (touch wake and color control at least) to any tuna kernel and rom and possible in future to other devices too.
The app will (obviously)require root and will be shared for free without ads/trial/limitations but with optional donate.
Does anybody interested in such app? Is it worth to continue?
Cause I've reached all features I wanted and there will be no sense to continue develop if no one interested in results.
Please tell me what you think!
Voron.exe said:
Okay. I've done some work and have some success with modules.
I am planing to make and app that will allow to add this features (touch wake and color control at least) to any tuna kernel and rom and possible in future to other devices too.
The app will (obviously)require root and will be shared for free without ads/trial/limitations but with optional donate.
Does anybody interested in such app? Is it worth to continue?
Cause I've reached all features I wanted and there will be no sense to continue develop if no one interested in results.
Please tell me what you think!
Click to expand...
Click to collapse
I think that's a great idea. I think you could probably do it far more easily with AnyKernel2 also.
Voron.exe said:
I am planing to make and app that will allow to add this features (touch wake and color control at least) to any tuna kernel and rom...
Click to expand...
Click to collapse
Seems a very interesting project to me as i'm currently running VoronK on top of ua.
Thanks
yen
osm0sis said:
I think that's a great idea. I think you could probably do it far more easily with AnyKernel2 also.
Click to expand...
Click to collapse
As I understand AnyKernel2 is a script for flashing a kernel into ROM with any ramdisk (Am I wrong?).
If so I can't see any benefits of using it, cause there are much bigger ROM/Kernel incompatibility issues than just a ram disk.
What I do (and almost done) done now is a kernel modules that can be loaded in any kernel (almost) so I can no more care about building own kernel for each ROM version.
Instead I will care about compatibility with different kernels. On the other side users will be free to use kernels which they like.
_yen_ said:
Seems a very interesting project to me as i'm currently running VoronK on top of ua.
Thanks
yen
Click to expand...
Click to collapse
Thank you too! Your posts make's me to continue developing, although it's not easy, cause I have to study also.
I wonder how many Galaxy Nexus devices still in use?
I fill like there about 100 in the world and I am one of them!
Hope that isn't true =D
You can use AnyKernel2 to flash over any ramdisk as well as any zImage if you want, check out my GN Synapse Injector zip. So if you want to add modules, etc. to any kernel/ROM AK2 should be much easier than an app I would think!
I cannot comment on technical issues, but I do think color control is mandatory in a ROM. And in any computer system, in fact.
Voron.exe said:
I fill like there about 100 in the world and I am one of them!
Hope that isn't true =D
Click to expand...
Click to collapse
One big release of CM13 has 9000 downloads, and a big release of UA 7.1 has 10,000 downloads. Maybe half or less of all current users would ever download these. Personally I have not downloaded either. So I think your feeling is not true. There are more than 100 Galaxy Nexus users.
osm0sis said:
You can use AnyKernel2 to flash over any ramdisk as well as any zImage if you want, check out my GN Synapse Injector zip. So if you want to add modules, etc. to any kernel/ROM AK2 should be much easier than an app I would think!
Click to expand...
Click to collapse
With the app it's not hard too. It's like "insmod mymodule.ko". Only needs a root.
App can download anybody and no need to deal with recovery and manual flashing.
Anyway app will needed to control module settings. I think it's more user friendly..