Hey
This will not be a (much) maintained thread. This is the main thread: G5 forum
Kernel is for Lineage based roms. Works with Android 11
US996 = Officially unlocked
US996Dirty = Unlocked "the other way"
It was tested to give about 30% longer battery life, using youtube playback constantly, than stock lineage/lighthouse kernels.
Stock (original lg) rom was tested also, which lasted 7h in the test. The same as my kernel, but I dare say my kernel will be faster
in addition, but it's obviously difficult to compare stock vs lineage in that manner (stock being very old un-optimized userspace).
Keep in mind the number above is from G5 which has a 2800mAh battery. The tester's battery was also a bit worn.
-----------------------------
Downloads:
V0.8 - Androidfilehost
Beta builds - Androidfilehost
-----------------------------
UPDATE - feb 14 2022
Version 0.7 Beta2 uploaded. You'll find it in the link above.
UPDATE - april 26 2022
For H990 - version 0.7 beta4 - To solve crashing (obsolete with 0.7 stable build)
UPDATE - june 28 2022
Version 0.7 uploaded -- Built with gcc12.1, disabled kpti for better performance and enabled zram (with upstreamed lz4, zsmalloc, zram)
Removed the old builds from this post
UPDATE - feb 19 2023
Version 0.8 uploaded
Source
Thanks to @AShiningRay
I've put his undervolt, and tweak to schedutil in v0.7
I will try building the H990DS variant , Will send here.
Mysteriouslog6 said:
I will try building the H990DS variant , Will send here.
Click to expand...
Click to collapse
Don't bother, I'm building now. I forgot the 990 is also a very common device.
I will also upload the final/stable build for each device at some point.
Edit: Added to post #1
Hi, is the IR working with this kernel? Thanks
timba123 said:
App says so
Click to expand...
Click to collapse
Unfortunately this app only checks if the IR blobs have been implemented and can be accessed by the phone's OS, because it reports the same info on Lineage's stock kernel where the IR doesn't work properly after sending the first signal, so that app is not a reliable way to test it. I could be wrong tho, since i would really like to test this kernel's IR by myself, but it throws me right into fastboot when flashing it on top of either LOS 18.1 or Lighthouse.
IR is not working. I've looked into that and i understand now why nobody has ir working.
The main driver part is in userspace, so we need to implement a solution from a msm8996
LeEco device which has the same ir chip (maxq616), on the ROM side. This is in official Lineage
here: https://review.lineageos.org/c/LineageOS/android_device_leeco_msm8996-common/+/274548
GitHub - LineageOS/android_device_leeco_msm8996-common
Contribute to LineageOS/android_device_leeco_msm8996-common development by creating an account on GitHub.
github.com
People have been saying Gamma kernel works; that may be, but looking at his sources show
no changes in that regard. So then he either wrote his own driver based on NDA restricted
documents or he found something ready-made. In any case; not making it public would be
the right ting to honor the NDA and not get in trouble.
Just putting it out here for potentially interested devs. I have shown this to one of the Lighthouse
devs, and he is currently trying to port those changes.
AShiningRay said:
I could be wrong tho, since i would really like to test this kernel's IR by myself, but it throws me right into fastboot when flashing it on top of either LOS 18.1 or Lighthouse.
Click to expand...
Click to collapse
I see you have a H910 device. Anyone else have the same problem?
askermk2000 said:
I see you have a H910 device. Anyone else have the same problem?
Click to expand...
Click to collapse
As far as i tested some time ago, gamma kernel had the same behaviour after flashing, but i tested that one on LOS 17.1. It might be because my refurbished V20 is a bit weird in regards to the SoC. No matter where i check it, the phone reports a Snapdragon 821 (MSM8996Pro) with clock tables all the way up to 2.34Ghz and etc even on LG's stock rom, which i find really strange because the V20's are supposed to have a Snapdragon 820, so i'm not really sure if that is the reason behind the fastboot problem, since both LG stock and Lineage's kernel works just fine.
And as for gamma, even the IR on that seems a bit finicky at best due to some reports on V20 Reddit also saying it doesn't work, making it even less likely to ascertain exactly "how" or "why" it works there. I am also compiling a custom kernel for the V20 based on LOS 18.1 sources and from what i saw, gamma's source has basically identical IR files, be it LIRC or IRRC, and some logging about the IR has specifically shown me that the kernel is actually issuing the signal correctly, but something breaks between the kernel and the OS, making the ConsumerIRService return error -1 right after that., which eventually led me to this as well:
[REF] How Infrared is (not) working on LePro3 - some infos for IR devs
So, I was also interested why 3rd party infrared apps are not working on the LePro 3, and did some debugging. This thread somehow documents my findings step by step... Edit - Dec 1, 2016: As the postings below got a little bit technical, I'll...
forum.xda-developers.com
It might be something outside of the kernel, but i don't have the skills to mess around with ROMs yet and logging it is the best i can do on them.
AShiningRay said:
As far as i tested some time ago, gamma kernel had the same behaviour after flashing, but i tested that one on LOS 17.1. It might be because my refurbished V20 is a bit weird in regards to the SoC. No matter where i check it, the phone reports a Snapdragon 821 (MSM8996Pro) with clock tables all the way up to 2.34Ghz and etc even on LG's stock rom, which i find really strange because the V20's are supposed to have a Snapdragon 820, so i'm not really sure if that is the reason behind the fastboot problem, since both LG stock and Lineage's kernel works just fine.
Click to expand...
Click to collapse
Ah ok. I know why then.
You see, me and Omar removed some board definitions from our kernel to make it smaller. Those where definitions for sd821 V20s - which we gathered was for some prototype devices which would likely never be in circulation.
But here you are with one such device
Edit: see here: https://github.com/stendro/msm8996_...a80921570789d20375f0b62516be3c6973ccb3375552a
askermk2000 said:
Ah ok. I know why then.
You see, me and Omar removed some board definitions from our kernel to make it smaller. Those where definitions for sd821 V20s - which we gathered was for some prototype devices which would likely never be in circulation.
But here you are with one such device
Edit: see here: https://github.com/stendro/msm8996_...a80921570789d20375f0b62516be3c6973ccb3375552a
Click to expand...
Click to collapse
Welp, at least the phone is doing its job of being a device mainly for development, lol. It also means your kernel probably works fine on H910's running a snapdragon 820, and thanks for clearing that up, makes me feel a bit more comfortable knowing that the chance of my phone being some kind of Frankenstein is a bit smaller.
If you need any testing or logs in the future, i'll be happy to help.
timba123 said:
LG V20 Pro Coming soon to Japan - Trendy Techz
In this post we shared the complete details of upcoming smartphone LG V20 Pro which is coming soon to Japan store. Complete details are here in this post.
trendytechz.com
Click to expand...
Click to collapse
Mine doesn't look very similar to this Pro version, since my variant is actually a H910 and save for the SoC, everything else fits right in line with other standard V20's (the screen for example is clearly 5.7", since it is relatively bigger than my 5.5" Redmi Note 4 despite having smaller bezels, while the V20 Pro reportedly has a 5.2" screen plus a Snap 820, mine also has 64GB of internal storage versus the Pro's 32GB), if i flash a kernel or ROM of any other variant it either gives me a very glitched screen rendering right at boot (US996) or doesn't boot at all.
Edit: After finding some pictures of the Pro model's back, i can now affirm that the design is completely different from mine, even the camera layout that puts the flash and laser in the center and not on the sides, while the one i have is the opposite just like the default mode, so it definitely isn't the Japanese Pro version, but thanks for the heads-up.
AShiningRay said:
And as for gamma, even the IR on that seems a bit finicky at best due to some reports on V20 Reddit also saying it doesn't work, making it even less likely to ascertain exactly "how" or "why" it works there. I am also compiling a custom kernel for the V20 based on LOS 18.1 sources and from what i saw, gamma's source has basically identical IR files, be it LIRC or IRRC, and some logging about the IR has specifically shown me that the kernel is actually issuing the signal correctly, but something breaks between the kernel and the OS, making the ConsumerIRService return error -1 right after that., which eventually led me to this as well:
It might be something outside of the kernel, but i don't have the skills to mess around with ROMs yet and logging it is the best i can do on them.
Click to expand...
Click to collapse
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
askermk2000 said:
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
Click to expand...
Click to collapse
I guess the only reason the IR supposedly works in Gamma is due to proprietary code not released on Github, because i ran through a massive gitlog of its repository going all the way back to january 2016 and there is no relevant commit about LG's IR as well, only the CAF updates seem to change IR files, and those seem to be present on lineage's source as far as the files are concerned. I could also have missed something, but it is highly unlikely at this point. We could at least find someone that managed to make the Infrared work on Gamma and check if they are running the latest ROMs or if the older ones like LOS 16 are also part of the reason why it works there.
And about the Lighthouse dev's response: That's a bummer, LG could have gone with the SDK approach as LeEco did, now i can just hope he manages to port the proprietary IR blobs successfully, since the only alternative left would be to reverse engineer it.
AShiningRay said:
I guess the only reason the IR supposedly works in Gamma is due to proprietary code not released on Github, because i ran through a massive gitlog of its repository going all the way back to january 2016 and there is no relevant commit about LG's IR as well, only the CAF updates seem to change IR files, and those seem to be present on lineage's source as far as the files are concerned. I could also have missed something, but it is highly unlikely at this point. We could at least find someone that managed to make the Infrared work on Gamma and check if they are running the latest ROMs or if the older ones like LOS 16 are also part of the reason why it works there.
And about the Lighthouse dev's response: That's a bummer, LG could have gone with the SDK approach as LeEco did, now i can just hope he manages to port the proprietary IR blobs successfully, since the only alternative left would be to reverse engineer it.
Click to expand...
Click to collapse
Was my conclusion first as well.
I checkout to gamma-pie source and did a quick make, to create .config for H850. Then I compared to lineage h850 config.
There are two options that stand out that are enabled on gamma but not on lineage, those are:
CONFIG_DEVPORT
CONFIG_AUDITSYSCALL with accompanying (CONFIG_AUDIT_WATCH and CONFIG_AUDIT_TREE)
I did see this before but didn't pay much attention, but now that we know blobs are present, perhaps they make use of some of those facilities.
askermk2000 said:
Was my conclusion first as well.
I checkout to gamma-pie source and did a quick make, to create .config for H850. Then I compared to lineage h850 config.
There are two options that stand out that are enabled on gamma but not on lineage, those are:
CONFIG_DEVPORT
CONFIG_AUDITSYSCALL with accompanying (CONFIG_AUDIT_WATCH and CONFIG_AUDIT_TREE)
I did see this before but didn't pay much attention, but now that we know blobs are present, perhaps they make use of some of those facilities.
Click to expand...
Click to collapse
There's also a possibility that those configs are only needed on older android versions, as that gamma branch is for android 9 and we are currently on 11. But nonetheless i will add those configs into my kernel and see if it compiles, then check if the IR status changes, shouldn't be much of a problem. I'll report back in a few hours.
Edit: Managed to test it sooner than expected (thankfully no repo sync was needed on lineage sources), and there was no change whatsoever, the infrared still fails after the first transmit signal.
The audit configs themselves are mostly used to audit file changes in the kernel so it is more of a system admin feature, while the devport one was more promising, since there was a chance that the IR could be using /dev/port as a way to let the apps interact with it directly, and considering how hacky some proprietary code can be (LG messes up even the KDZ recovery files sometimes, like with my old LG Leon, essentially making it unrecoverable), so you never know.
Turns out the lineage kernel source code has all of those configs defined in the files and they were just disabled.
AShiningRay said:
There's also a possibility that those configs are only needed on older android versions, as that gamma branch is for android 9 and we are currently on 11. But nonetheless i will add those configs into my kernel and see if it compiles, then check if the IR status changes, shouldn't be much of a problem. I'll report back in a few hours.
Edit: Managed to test it sooner than expected (thankfully no repo sync was needed on lineage sources), and there was no change whatsoever, the infrared still fails after the first transmit signal.
The audit configs themselves are mostly used to audit file changes in the kernel so it is more of a system admin feature, while the devport one was more promising, since there was a chance that the IR could be using /dev/port as a way to let the apps interact with it directly, and considering how hacky some proprietary code can be (LG messes up even the KDZ recovery files sometimes, like with my old LG Leon, essentially making it unrecoverable), so you never know.
Turns out the lineage kernel source code has all of those configs defined in the files and they were just disabled.
Click to expand...
Click to collapse
Thanks for testing. I'm compiling gamma kernel now to see if it works, else there's no point in messing with that source.
Another interesting bit is module signature. Gamma has modules enabled and signature disabled. Then I though it might
be possible for blobs to be signed and verified in a similar manner as the *.ko modules in lib/modules.
I asked on irc with some knowledgeable folks, and the answer was: yes its possible. but I'll see at least if gamma works as is, if it does then that could be the cause.
askermk2000 said:
Thanks for testing. I'm compiling gamma kernel now to see if it works, else there's no point in messing with that source.
Another interesting bit is module signature. Gamma has modules enabled and signature disabled. Then I though it might
be possible for blobs to be signed and verified in a similar manner as the *.ko modules in lib/modules.
I asked on irc with some knowledgeable folks, and the answer was: yes its possible. but I'll see at least if gamma works as is, if it does then that could be the cause.
Click to expand...
Click to collapse
Understood. As it stands, all modules compiled by the lineage kernel are test modules for TCP, IO Blocks, optional TCP algorithms and other nonessential things, everything else is baked into the kernel itself. The general lack of warnings of any kind pertaining to them also means that everything that should be compiled is being completed without any problems, unless lineage's default GCC and Clang are implicitly omitting those errors. I'm almost releasing my custom kernel here on the V20 subforum as well, so it will be easier to find people to test it too.
Ok, so it seems it didn't work.
I haven't used the phone previously as a remote, but I got Asmart remote on there, and have a samsung tv in standby.
I tried to shuffle through all samsung models pressing the power button, but tv didn't react.
Then I tried looking at the ir led through a phone camera while pressing button and I could not see anything.
askermk2000 said:
Ok, so it seems it didn't work.
I haven't used the phone previously as a remote, but I got Asmart remote on there, and have a samsung tv in standby.
I tried to shuffle through all samsung models pressing the power button, but tv didn't react.
Then I tried looking at the ir led through a phone camera while pressing button and I could not see anything.
Click to expand...
Click to collapse
That's the worst part actually, i only managed to ascertain that it works on the first transmission because my IR app had a preset that worked on my LGTV right at the start. Mi Remote for example behaves just as your app is behaving, where my TV doesn't respond at all to it, so i guess the phone's IR hangs no matter if it sends the correct signal or not. The only difference there is that my H910 still flashes the IR light even after the first transmit while using Lean Remote, but with a massive delay between each cycle and even freezing the app for a while, but still, only the first command is issued.
askermk2000 said:
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
Click to expand...
Click to collapse
Issue is most likely kernel related OR consumerIR related. Reason it works on gamma is that it's using an older version of the linux kernel source compared to say los 18.1. After the kernel was upstreamed, Ir broke.
Related
I have no idea if this will be of any use to anyone or not, but I figured I'd share anyway. I came up with a seemingly functional replacement for the Fascinate Atlas [ED01] Broadcom BCM4329 wireless driver that is 100% certain not to have the "Hotspot Monitoring" feature, and should eliminate any issues with the /lib/modules/dhd.ko module as it's in-built as part of the kernel now.
Unlike what I did for EC10, which worked but took a lot longer to do, this is a pretty quick and easy source mod. It's stock i500 ED01 for everything but the hotspot (wlioctl.h/wl_iw.h/wl_iw.c) code, which is stock i9000-update2, sans a certain "roaming" feature. The end result seems to work. Support for the actual VZW 3G hotspot app is all but guaranteed to be dead and buried, but the latest android-wifi-tether 3.0pre12 in infrastructure mode worked great, so I think it's pretty close to good, if not actually there.
Application:
- Remove the insmod lib/module/hotspot_event_monitoring.ko from init.rc
- Remove the hotspot_event_monitor.ko from lib/modules in your INITRAMFS
- Remove the dhd.ko from lib/modules in your INITRAMFS
- In your xxxxx_defconfig, remove (or comment out) CONFIG_BROADCOM_WIFI_ATLAS=y and make sure CONFIG_BROADCOM_WIFI is set to "m"
- Replace drivers/net/wireless/Makefile and drivers/net/wireless/bcm4329 with the contents of the linked .TAR below
- This should generate a dhd.ko instead of hotspot_event_monitoring.ko in drivers/net/wireless/bcm4329. Put that in your INITRAMFS::lib/modules instead of whatever stock dhd.ko you have. [Having the dhd.ko to include with a build is quite nice compared with using some stock driver IMO]
- Let me know if it doesn't work ... and what you tried ... I can always go ahead and do another manual merge like I did for EC10
edit: You'll also want to strip the debug symbols from the dhd.ko that's generated, it's huge. I've been doing a make modules then copying out/stripping the .ko files for initramfs before finisihing with the regular make.
MOD Source Download (.TAR)
Link to my GitHub commit for this particular change (don't trust my GIT, look at jt1134's or imnuts' GIT for things that matter!)
Anyway, if this helps you out, awesome. If you apply it and your WiFi gets boned up, please let me know and I will try to recreate. If you apply it and your phone catches on fire and dies a slow and painfull death I have no idea who you are or what you're talking about
Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats
Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.
nemesis2all said:
Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats
Click to expand...
Click to collapse
I'd guess that whatever you extracted the archive with, also updated the files with what their modification time when they were archived. 1.8e+04 seems to be 5 hours, so it's likely due to you and djb having different timezones (or, one of you not knowing how to set your clock with NTP ).
Whatever you used should have an option to not preserve the timestamps, so you could just redo with that option... alternatively, you could wait 5 hours.
Syn Ack said:
Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.
Click to expand...
Click to collapse
He did, so you can be 'safe', but you still got parts of that monster in the wireless driver's code & the dummy monitor as well (no doubt that samsung's modifications to the wireless driver are quite low quality, like everything else they seem to do in the kernel).
I'm not sure what app you're using, but, using Wireless Tether or anything else not from Verizon should be safer (not to imply that using the 3G Hot Spot with the monitor removed is dangerous- but from what I've heard, take with a grain of salt, doing the hack to get free tethering with the verizon app puts some possible traces on your account that might suggest you're doing it).
I use a combo of that dummy monitor and the Wireless Tether app.
is this a full kernels or just a mod for which ever kernel you are using
evilclosetmonkeynate said:
is this a full kernels or just a mod for which ever kernel you are using
Click to expand...
Click to collapse
This is a mod for kernel developers.
Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone
djp952 said:
Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone
Click to expand...
Click to collapse
It is all good still appreciate your work. I have never seen anything like that. Just thought it included some bits needed for my DeLorean to go back to the future.
so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?
Thank you for your hard work hope to see this in future Kernels
Sent from my SCH-I500 using XDA App
godihatework said:
so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?
Click to expand...
Click to collapse
Anything is possible, as long as the hardware is actually the same (or close enough) on the i9000 and it doesn't need anything unique to the GB kernel. It certainly won't hurt to diff the code when it's available to see how close it is.
Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.
nemesis2all said:
Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.
Click to expand...
Click to collapse
Yes, as of android-wireless-tether 3.0pre14 I haven't had any issues at all with it. 3.0pre12 was throwing a fit every now and again, but apparently that was a common malady with that version. Note also that I have NOT tested the Verizon 3G hotspot app with this driver, my assumption is that it will not work. Which leads me to ...
I also have a less aggressive solution that may allow the VZW app to work you could have if you want, it's basically the same thing with the updated SOFTAP changes from the i500 applied to the i9000 driver as well. (This basically makes it amount to just carving out the hotspot and producing a new dhd.ko during a build so we don't have to use the pre-compiled one from the ramdisk)
You can find the alternate version of the driver on my github, in the src/wip directory of the sch-i500-kernel repo:
https://github.com/djp952/sch-i500-kernel.git
LMK if you run into problems
Hi there,
This is a development thread.
Don't ask for ETAs. Don't ask what's working. Don't ask how to use.
It is not yet in an usable state.
INFORMATION
Click to expand...
Click to collapse
This is an attempt to make a homemade 3.x kernel for our beloved Galaxy S II. I'm targetting the GT-I9100 only for now, if you wish to get it running on other variants (I9100G for instance), feel free to port it to your device and do a pull request.
I started it off Origenboard 3.0.4 kernel patched to 3.0.24, so that we get the most up-to-date opensource drivers, removing the need of porting Samsung drivers from 2.6 (gingerbread) kernel.
We'll be able to merge proprietary stuff from Samsung when they release it (audio and modem mainly), but thanks to what we'll already have we'll have a proper 3.x kernel without any Samsung crap (such as their MTP implementation that is borked it seems).
GIT REPOSITORY
Click to expand...
Click to collapse
http://github.com/xplodwild/android_kernel_samsung_galaxys2
WHAT'S WORKING
Click to expand...
Click to collapse
Keys GPIOs
Regulator and battery (it loads well but Android doesn't show it's charging)
Screen/framebuffer
Touchscreen
MFC (untested but should work from Origen)
RTC Clock
Touchkeys
MAJOR ISSUES
Click to expand...
Click to collapse
Phone never wakes from deep sleep (<== We definitely need experts on this one)
ADB works only after unplugging and replugging USB cable (issue almost located)
HOW TO HELP
Click to expand...
Click to collapse
Well, start forking, do stuff and make pull requests so I merge it and everyone enjoys. I'd need some help for the major issues above (especially the deepsleep issue).
If you're not a developer, well, buy me a coffee, there's a donation button on the left of this post
I'll keep you informed when it'll be ready for "public" use.
Phone never wakes from deep sleep
cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Entropy512 said:
[*]Phone never wakes from deep sleep
[*] cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I was just thinking that Iirc it puts the device into 800 when waking, or something like that...
Entropy512 said:
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I had the same issue when I haven't enabled the governors, so the CPU was stuck at 1200MHz but won't wake up either from a deep sleep.
I'll have a try with the voltage, but my guess is more that there's some steps missing (the default 2.6 kernel seems to have a "low power mode" in which the board gets before waking up, if I understood it correctly).
At the same time, I'm giving a try with the 3.3 branch at Linaro (check android-3.3 branch at my github). It's harder than 3.0 because there's no more s3c framebuffer, it seems to go directly to FIMD, and the LCD panel has to be setup through SPI.
Some update:
- Touchkeys, clock and various things added/fixed
- Patched to 3.0.24
Edit:
- Added sdcard mounting
Cool stuff should come very quickly
Good work...
---deleted some post----
Sorry u can delete this post as it making thread very ugly..
_____________________
Sent From My Phone
just buy u a expensive coffee! Work hard!
Yeah do you smell sources?
Sent from my GT-I9100 using XDA
boba23 said:
Does this mean you are smelling Samsung source code somewhere? ;-)
boba
Click to expand...
Click to collapse
We'll do our best without them.
True enough.
This kernel is the most exciting thing I'm watching lately.
Really excited about the outcome. Samsung Kernel is just not the way to go if you get an alternative like this, which is far more promising.
Here comes your coffee:
33P346290U8160844
Keep it up!
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
sam razzy said:
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
he already know it...pretty sure xplod and codeworkx will bring some state of art kernel to us
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Isn't 3.3 bleeding edge?
Sent from my GT-I9100 using XDA
awesome, man
despite not owning a sgs2 I like your work! Samsung should definitely review their way of development, way cook your. own soup, when it. Is. already done by someone else
they should just stay compatible and release the damn hardware drivers ;-)
Sent from my Nexus S using XDA Premium HD app
XpLoDWilD said:
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Click to expand...
Click to collapse
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase? https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Entropy512 said:
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
Click to expand...
Click to collapse
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Entropy512 said:
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase?
Click to expand...
Click to collapse
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Entropy512 said:
https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Click to expand...
Click to collapse
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
XpLoDWilD said:
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Click to expand...
Click to collapse
Makes sense, although unfortunately, some things are clearly backports of newer code, see below.
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Click to expand...
Click to collapse
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
Click to expand...
Click to collapse
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Entropy512 said:
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
Click to expand...
Click to collapse
My bad, after checking it must be codeworkx that merged it wrong (he put samsung on top of "stock" 3.0.15 to check the differences), I guess files weren't deleted.
Entropy512 said:
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Click to expand...
Click to collapse
I'm not talking specifically about mach-exynos implementation, but more all the other things that got touched around it.
Entropy512 said:
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Click to expand...
Click to collapse
If copyright header is right, Samsung's one is 2009-2010 whereas 3.3 is from 2011. One example is that the Samsung driver uses mutexes and locks, which are not needed anymore and are not present anymore in mainline. This causes deadlocks everywhere when trying to use them in a "clean" kernel.
Hello this thread is intended for development purpouses only. Do not post thank you posts, request posts or anything not related to the main purpose. You have a thanks button if you are thankful.
Well warching at what lg did with kitkat using bad jb blobs for gpu that resulted in abnormal cpu usage for rendering and in slowness and glitchness I decided to set up Team Neutron. This team will build a working cm10 that is smooth which is possible.
Well now anyone with abilities can join after i talk to them. Not here on topic but after they pm me.
Atm i would want to know if the following people will join me withoit egos secrets or drama. I will split iobs and watch over the project. I will work on it myself.
Kernel
@airidosas252
Rom dev from source
@weritos
Please confirm or infirm my invitation. This could be my last project for this device since it has almost no support. It will be a good one though.
I understand correctly
Going to collect СM10 ??
We are gonna get a super stable cm 10 if you want to work with me
Sent from my LG-P710 using XDA Free mobile app
christi9503 said:
We are gonna get a super stable cm 10 if you want to work with me
Sent from my LG-P710 using XDA Free mobile app
Click to expand...
Click to collapse
This is certainly good
But for the models 715 to gather a working network will be problematic, СM10 not support two SIM cards
That is right but we are never going to get a stable cm11 because of the gpu. We can make 1 sim work i think
Sent from my LG-P710 using XDA Free mobile app
Edit: @weritos
The best we can get is a JB based rom like CM10.2 at most. After we get the single sim working we can patch somehow for the P715 to use one sim (some ramdisk tweaking).
What I am thinking off:
let's pull the blobs only from our phone. See if we can get it running. We analyze the log and see what are we missing then add them 1 by 1 (this will give us maximum stability that can be attained).
let's remake that device tree with only the 100% necessary things and we can always add up on top of that. Let's not take TeamHackLG base. Of course we will use the 7x27a settings (SoC's are almost the same). Well, the best thing is to make some display things for our own 8225 socket. It will take a while but all we need is in our kernel. We can focus on this later to improve the stability even more.
Well. Our first goal is to make it boot using ONLY the blobs from our device + the GPU drivers I managed to obtain (they are optimized for JB). After we get that working we should worry about other things. Kernel should be modified just to boot (in the first stage). After we get a fully working device (RIL, WIFI etc) we can work on a better kernel, optimization, overclock, deep-sleep and everything we want. I also watched in the LG Ramdisk (from stock). It's a bunch of garbage half of it could be deleted. Well I am pulling the blobs tonight, download cm10.2 source and let's get to work my friend. Imo we should focuse on the boot first. Ofc if you have any opinion I am always to open it and if your idea turns to be a better one (since none is perfect) we will go for that.
EDIT2: There is a fetch error in cm10.2 let's try with branch jellybean.
christi9503 said:
That is right but we are never going to get a stable cm11 because of the gpu. We can make 1 sim work i think
Sent from my LG-P710 using XDA Free mobile app
Edit: @weritos
The best we can get is a JB based rom like CM10.2 at most. After we get the single sim working we can patch somehow for the P715 to use one sim (some ramdisk tweaking).
What I am thinking off:
let's pull the blobs only from our phone. See if we can get it running. We analyze the log and see what are we missing then add them 1 by 1 (this will give us maximum stability that can be attained).
let's remake that device tree with only the 100% necessary things and we can always add up on top of that. Let's not take TeamHackLG base. Of course we will use the 7x27a settings (SoC's are almost the same). Well, the best thing is to make some display things for our own 8225 socket. It will take a while but all we need is in our kernel. We can focus on this later to improve the stability even more.
Well. Our first goal is to make it boot using ONLY the blobs from our device + the GPU drivers I managed to obtain (they are optimized for JB). After we get that working we should worry about other things. Kernel should be modified just to boot (in the first stage). After we get a fully working device (RIL, WIFI etc) we can work on a better kernel, optimization, overclock, deep-sleep and everything we want. I also watched in the LG Ramdisk (from stock). It's a bunch of garbage half of it could be deleted. Well I am pulling the blobs tonight, download cm10.2 source and let's get to work my friend. Imo we should focuse on the boot first. Ofc if you have any opinion I am always to open it and if your idea turns to be a better one (since none is perfect) we will go for that.
EDIT2: There is a fetch error in cm10.2 let's try with branch jellybean.
Click to expand...
Click to collapse
That's a great idea, but first you should try CM10, 10.2 will be very slow on this device, since it is using hardware much more, and it is slower compared to CM10. But that's just my opinion.
True. @shiftyHungary: well after researching it seems cm10.2 is more optimized and from what I am seeing the most stable version of cm for 7x27 is cm10.2 we should work with that imo. There is a sync error because there was some fights over some source. will be fixed easy by replacing in repo with the path that it's used for cm11 or jsut delete that repo. Don't know which one yet. Researching.
Sent from my LG-P710 using XDA Free mobile app
Wow, it's a good new!! Thank you Chri.,
Sent from my Xperia M2 LTE using XDA Free mobile app
christi9503 said:
True. @shiftyHungary: well after researching it seems cm10.2 is more optimized and from what I am seeing the most stable version of cm for 7x27 is cm10.2 we should work with that imo. There is a sync error because there was some fights over some source. will be fixed easy by replacing in repo with the path that it's used for cm11 or jsut delete that repo. Don't know which one yet. Researching.
Sent from my LG-P710 using XDA Free mobile app
Click to expand...
Click to collapse
Okay, you know that better than me, I just shared my experience with my previous devices. Pm me if any help needed.
Well yeah. I really want CM also. I made my own version of CM11 it's smoother than the one we have but still mile away from what it should be even with hard-core optimization because CPU is too high because of the CPU. @weritos ->much respect to this guy, though I disliked some of the things were handled, I give props to him and I am thinking it's a good opportunity to work together and share idea with him (none has nothing to lose). Yeah cm11 will not be our deal and all the graphic glitches in games and stuff it's not because weritos CM11 it's because of LG being LG... With Cm 10.2 we have a way better chance (this came to my mind when actually trying to fix AOKP Ril problem which was based on CM10). I could feel the full powa!!!. Cm copiled GOOD from source will be butter (not in games and stuff ofc it's and Adreno 203 after all) smooth at least in UI and current day-by-day operations.
CM10.2 from the source code
christi9503, As soon as I pass all my exams
I redid the device tree under CM10.2, alter and drop provider (use LG)
But I tell immediately there will be problems with WiFi, Network
Well we can solve problems if we work rogether mosr likely. Best of luck with your exams. I am finishing blobs tonight and i made like half of the device tree. Tonight or tomorrow i will look in the ramdisk and will delete all that is useless
Sent from my LG-P710 using XDA Free mobile app
Well @weritos. Blobs are done (didn't pull the GPU ones since I will be using the ones I have found). Device tree is not fully done but it will be. I am building right now the first build. Using display CAF so it will take a while to get caf to work.
Edit: I will learn to use github and push repos there. Easier to work.
Cristi,
For now, use stock Kitkat kernel sources (just compile them using GCC 4.6 and you're good to go)
Because, once we modified stock kernel for certain things to work, like Wi-Fi, I can duplicate those and merge with my own customized kernel.
I'll work my ass off at my own kernel tonight, since I discovered certain problems.
Anyway, CM10.2 is a way better choice than CM11.
If Google didn't change whole lot of things in Kitkat, things would never have got that messy as it is now.
airidosas252 said:
Cristi,
For now, use stock Kitkat kernel sources (just compile them using GCC 4.6 and you're good to go)
Because, once we modified stock kernel for certain things to work, like Wi-Fi, I can duplicate those and merge with my own customized kernel.
I'll work my ass off at my own kernel tonight, since I discovered certain problems.
Anyway, CM10.2 is a way better choice than CM11.
If Google didn't change whole lot of things in Kitkat, things would never have got that messy as it is now.
Click to expand...
Click to collapse
Looking at the actual ramdisk kernel doesn't need modification for wi-fi to work. Same for RIL. Seeing as how it is handled we might be missing some bins or libs it'll be hard but it's possible to get ril with only our device files. This company called LG is just ****ing with us. Working on ramdisk for over 1 hours. There are A **** LOAD of duplicated files, obsoled, not used files. Working on it.
christi9503 said:
Looking at the actual ramdisk kernel doesn't need modification for wi-fi to work. Same for RIL. Seeing as how it is handled we might be missing some bins or libs it'll be hard but it's possible to get ril with only our device files. This company called LG is just ****ing with us. Working on ramdisk for over 1 hours. There are A **** LOAD of duplicated files, obsoled, not used files. Working on it.
Click to expand...
Click to collapse
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
airidosas252 said:
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
Click to expand...
Click to collapse
The mess they made. They just dirty patched mostly anything. My last LG device for sure.
Sometimes I am really thinking what big companies think. Another update. Sometime there is echo on what you are talking and stuff (like you hear your voice if you talk in the mic). It is because LG doubled some uevents or even tripled them. So they get inited like 3 times. This might solve the mic problem forever also.
airidosas252 said:
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
Click to expand...
Click to collapse
WiFi will not work immediately
Rild will not work
weritos said:
WiFi will not work immediately
Rild will not work
Click to expand...
Click to collapse
We will work that out my friend. Better if it takes 1 week or so to fix just 1 problem than making a messy fix and having instability and stuff. Quality over quantity. In the end that is the best combo.
Amyway, how everything is moving?
Wi-fi isn't a big deal breaker. We'll fix it, as well as RIL.
And we should avoid using modules.
Sent from my LG-P710 using XDA Free mobile app
[KERNEL] Starship-Kernel The Next Generation Stock/AOSP & CM-13 04/25/16 (Linaro 4.9)
Welcome to Starship Kernel The Next Generation (TNG) for the Nexus 6 Shamu. Not much else to say other than more than ever the Kernel is by design light wait, power efficient and moves at Warp Speed. There are no special features to play around with but instead designed to just be installed and just work. If looking for things to play around with may as well just move on as this is probably not the kernel for you.
Have shed some light on a few names below but really need to thank all the Nexus 6 Kernel Developers as could not have done much of anything without them. Before this project I had limited Kernel knowledge. Have been developing since I guess my first Rom had been CM6 based but never had much Kernel dealings. Have always worked joining up with a team to get CM or other AOSP like Roms up and running on TouchWiz,. Sense and other devices far from the Stock Android Experience. In working in groups and teams have for the most part always been the Device File & Vendor Blob guy. Everything I have learned about Kernels has honestly come from sifting through other Kernels and researching the hell out of out of commits until being able to stand on my own 2 feet and think so far have done a dam good job putting together a hell of a Kernel for the Nexus 6 that is extremely stable and performs well beyond expectation besides the big ol Jinx I just through out there.
This is now the new and improved Next Generation moving from say warp 6 to warp 9. Would say 10 but some funky stuff goes down at ten and if you dont know lets just say its not a place you wana go.
Definitely need to throw up thanks to Flair2, Imoseyon and Neoboddy89 as have used a decent amount of their commits in particular..
Features Worth Noting
Have placed features into either groups or single commits that make rather large improvements but are welcome to sift through the Kernels Commit History below as there are many individual changes to numerous to mention in a single post or even page . As mentioned most come from just sifting over and reading commits from every Kernel I could find. Most from Shamu but also some carefully selected from other devices with similar hardware
Kernel Version 3.10.101
Fast USB Charging
LZ4 Compression
Sio & Bfq i/o Schedulers - "bfq" used as default scheduler
ExFAT Support
Power Efficient Workqueues
KGSL Optimixations
Audio Codec Optimizations
Video Firmware Optimizations
CPU Idle Optimizations
GPU Power saving Optimizations
Adreno_Idler
Color Temperature Interface Using PCC
Frandom Support
LED Support (Rom must also Support)
MSM Vidc: Optimizations
Net: Wireless Bcmdhd, Various Optimizations
PM Enhancements.
F2FS 3.10
Starship Kernel, Nough Said!!
Source / Commit History aka change log
https://github.com/Chairshot215/starship_kernel_moto_shamu/commits/mm-mr1?page=1
Download Starship-Kernel_Class_SMTNG7_(Linaro-4.9) (04.16.2016)
Marshmallow 6.0.1 Stock/AOSP
https://www.androidfilehost.com/?fid=24499762636007231
CM-13.0
https://www.androidfilehost.com/?fid=24499762636007230
Again I am not responsible for any negative effects using any of the files on this thread or any post that has been linked in this thread so using is all at your own risk.
seems like nexus 6 development just blew up with new ROMs and kernels, thank you pal
Sent from my Nexus 6 using Tapatalk
Yup!
Does this kernel bypass force encryption?
Team Octos -Nexus 6
force encryption is disabled in the r_2 boot.img but so far is still showing that my N6 is Encrypted. With that said have not performed the recommended factory reset when going from a force encrypted boot.img to one that is not.
System UI Crash
Perhaps I've misinterpreted the OP, but I seem to have a major issue. Assuming this kernel is meant for 5.1.1 AOSP builds, upon flashing the kernel and wiping caches I get System UI crashes that do not allow me to actually start Android... am I at fault here?
That is odd I have flashed on AOSP many a time and have not had any issue. This is pure AOSP I compile without any modifications though. Is it a Rom on the forum, can maybe take a look see what might be the issue.
chairshot215 said:
That is odd I have flashed on AOSP many a time and have not had any issue. This is pure AOSP I compile without any modifications though. Is it a Rom on the forum, can maybe take a look see what might be the issue.
Click to expand...
Click to collapse
An issue like this is usually directed at the ramdisk. You may want to look into moving to an any kernel installer instead.
Sent from my Nexus 6 using Tapatalk
I was unencrypted, flashed the kernel and it booted up and told me encryption failed so I had to wipe and start over and decrypt again. If its disabled why did it encrypt again?
Sent from my Nexus 6 using Tapatalk
I like Starship ROM since my Nexus 5. :laugh::laugh::laugh:
ps000000 said:
I like Starship ROM since my Nexus 5. :laugh::laugh::laugh:
Click to expand...
Click to collapse
I hope you are referring to the Kit-Kat version and not the test flight Lollipop Rom I had up for a few days, lol.
Had pretty much put most of a year counting the L-Previews into that thing but was honestly not happy and did not think it measured up to what I had been releasing under Starship since Froyo so took it down and decided it was time for some off time. May pick it up again with M, Lollipop version had a few nice things could probably use. Think I had just about changed every hex color throughout the entire source. Took me for a loop when Google started using the Teal coloring I was using for a few versions.
calaeb08 said:
I was unencrypted, flashed the kernel and it booted up and told me encryption failed so I had to wipe and start over and decrypt again. If its disabled why did it encrypt again?
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Sorry had a hectic week, maybe you can save me some time. Honestly was trying to stay away from forums for a bit once got my N6. Was not till deciding to post something I looked around. Don't know how long I had only unlocked the bootloader so could fastboot the Kernel. Wanted over weekend to fix this and above mentioned any kernel so is more versatile than stock and pure AOSP. If could save me time and tell me what had done wrong would be a helpful thing. Am all about helpful and not so much smartest in the room syndrome so anyway committed the "fstab" had used if you see the issue at a glance. Otherwise think tomorrow is going to be a couch bound day so will read more into it.
https://github.com/Starship-Android...mmit/5f101827c8a0317d489134de756aacc534215d48
chairshot215 said:
I hope you are referring to the Kit-Kat version and not the test flight Lollipop Rom I had up for a few days, lol.
Had pretty much put most of a year counting the L-Previews into that thing but was honestly not happy and did not think it measured up to what I had been releasing under Starship since Froyo so took it down and decided it was time for some off time. May pick it up again with M, Lollipop version had a few nice things could probably use. Think I had just about changed every hex color throughout the entire source. Through me for a loop when Google started using the Teal coloring I was using for a few versions.
Sorry had a hectic week, maybe you can save me some time. Honestly was trying to stay away from forums for a bit once got my N6. Was not till deciding to post something I looked around. Don't know how long I had only unlocked the bootloader so could fastboot the Kernel. Wanted over weekend to fix this and above mentioned any kernel so is more versatile than stock and pure AOSP. If could save me time and tell me what had done wrong would be a helpful thing. Am all about helpful and not so much smartest in the room syndrome so anyway committed the "fstab" had used if you see the issue at a glance. Otherwise think tomorrow is going to be a couch bound day so will read more into it.
https://github.com/Starship-Android...mmit/5f101827c8a0317d489134de756aacc534215d48
Click to expand...
Click to collapse
I myself know nothing about developing roms or kernels, that's why I'm here to ride on the bus with the smart kids lol. I do know that you can just leave it the way it is, but you gotta let people know it's forced encryption so they don't have to start all over. They can flash that zip that disables it before booting up.
What's the point of a sig anyways?
Well Definitely it for Lollipop, Probably. One thing that bothered me moving from the N5 to N6 is my BT Headset sounded like a warped and scratched record. I had lucked out with that pair in that had been reasonable priced and sounded amazing previously. Have added a few choice commits, well almost 2 pages but the things work like a charm. Decided for that and a few other reasons for one last post until 6.0.
I remember you from the galaxy victory forums :3 thanks for trying with CM. We were SOL, but theres still development going on there!
Sent from my Nexus 6 using Tapatalk
NolenUmar said:
I remember you from the galaxy victory forums :3 thanks for trying with CM. We were SOL, but theres still development going on there!
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Yeah I actually am still receiving emails about the Victory. Not that I could ever return to either the screen size or Touchwiz but wish I still had the device. Still feel like that SOB defeated me. Had been I think the 3rd device I worked on developing from the CM source and was so dead set on doing everything crazy proper so it could be an officially supported device. Wish I still had the device as do not like the feeling of spending countless hours on something and then leave unfinished. Think in the end all but GPS, Camera and that dang reboot when switching from Wifi to LTE. Think I used the Apexq as a template for getting everything else going. Otherwise wish the community luck. The phone was nice for the Price just a shame it has been years and everyone is still stuck on Stock with last I checked a bunch of out dated Kernels. Anyhow thats my Victory, rather defeated Rant. Remember at one point had got so frustrated used some command I don't remember off the top of my head and a lib decompiler and made the below list of all the files and their dependencies when trying to put together a vendor blob list.
http://pastebin.com/SFyJ14kv
Whats crazy about just pulling up this list is that I see the creation date was todays date but in 2013. Just had to mention that SOB device. Now I’m all worked up, lol.
Updated the M Kernel to r1.2 as works fine with SuperSU 5.1
This is an Encrypted Kernel. Will probably change with next update but for now it is Encrypted.
Now 2.0 with a few optimizations. Forgot about encryption but again looking for next update,lol.
Eill give it a try when it doesnt force enycrption
Sent from my Nexus 6 using Tapatalk
calaeb08 said:
Eill give it a try when it doesnt force enycrption
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Yeah will need to look at that again. I use the same any-kernel installer for Lollipop-r_3.0-Kernel and M-6.0-r_2.0-Kernel.
With the L Kernel either flashing with an already un-encrypted Rom or flashing and performing a data wipe / factory reset with an encrypted Rom all works fine without encryption being forced.
Could be I just messed up the test with the M-6.0-r_2.0-Kernel and it actually does not enforce encryption as it uses the same fstab.shamu as the L version . Just did not feel like going through a data wipe to double check so am putting it off until the next release. Otherwise if you are not encrypted and remove the fstab.shamu file from the Ramdisk folder in the M-6.0-r_2.0-Kernel zip before flashing the Rom should still stay un-encrypted. I have at least not seen or read anything stating there is a difference between L&M when it comes to encryption.
Otherwise this is the anykernel installer used in both L&M. The only difference is the zImage-dtb I use.
https://github.com/Starship-Android/anykernel
chairshot215 said:
Yeah will need to look at that again. I use the same any-kernel installer for Lollipop-r_3.0-Kernel and M-6.0-r_2.0-Kernel.
With the L Kernel either flashing with an already un-encrypted Rom or flashing and performing a data wipe / factory reset with an encrypted Rom all works fine without encryption being forced.
Could be I just messed up the test with the M-6.0-r_2.0-Kernel and it actually does not enforce encryption as it uses the same fstab.shamu as the L version . Just did not feel like going through a data wipe to double check so am putting it off until the next release. Otherwise if you are not encrypted and remove the fstab.shamu file from the Ramdisk folder in the M-6.0-r_2.0-Kernel zip before flashing the Rom should still stay un-encrypted. I have at least not seen or read anything stating there is a difference between L&M when it comes to encryption.
Otherwise this is the anykernel installer used in both L&M. The only difference is the zImage-dtb I use.
https://github.com/Starship-Android/anykernel
Click to expand...
Click to collapse
You'd probably be better off using hellsgods anykernel scripts. Though, I'm not sure why yours isn't working to disable it. Theres also a fed patcher that should fix it. It kinda defeats the purpose of anykernel if your replacing files in the ramdisk instead of editing them.
Sent from my Nexus 6 using Tapatalk
Glassrom is here
Join the telegram group today! https://t.me/joinchat/DKbLAED4w6Dk-qd26SmDbw
For those who don't know glassrom is a small project run by me. It focuses on where lineage left off. There is a stronger focus on speed and security while not having too many features
Current features: removed a lot of debugging from lineageOS and optimised more aggressively
Odexed for faster boot time
Ran through stronger selinux checks by building in user mode (security)
Microg support
Full substratum support with optimisations for lineage. No more weird looking statusbar
Upstreamed kernel to linux-3.10.50
Archidroid optimizations
Pixel UI
All features seem to work. Please report bugs
Donate links: https://ko-fi.com/florian
Coffee helps me stay awake to code
Donations are appreciated but are not a requirement. Donations help support me and my work
XDA:DevDB Information
Glassrom-harpia, ROM for the Moto G4 Play
Contributors
anupritaisno1
Source Code: https://github.com/GlassROM-devices
ROM OS Version: 7.x Nougat
ROM Kernel: Linux 3.10.x
Based On: lineageOS
Version Information
Status: Beta
Created 2017-10-11
Last Updated 2017-10-11
Download here https://srv1.botstack.host:8001/moto/harpia/glassrom-harpia-alpha1-signed.zip
anupritaisno1 said:
Download here https://srv1.botstack.host:8001/moto/harpia/glassrom-harpia-alpha1-signed.zip
Click to expand...
Click to collapse
Thanks for bringing another rom for our device!
We really appreciate it.
NovaKenn said:
Thanks for bringing another rom for our device!
We really appreciate it.
Click to expand...
Click to collapse
Ditto on the thanks!
Two issues that I usually have with custom ROMs are:
1. Not using GLONASS in the satellite based position computation.
2. Broken USB audio streaming.
How does your Glassrom fair in these areas?
FWIW I've been using microG since it became available and its predecessor software before that. I am pretty sure that my GLONASS and USB issues are unrelated to that.
n76 said:
Ditto on the thanks!
Two issues that I usually have with custom ROMs are:
1. Not using GLONASS in the satellite based position computation.
2. Broken USB audio streaming.
How does your Glassrom fair in these areas?
FWIW I've been using microG since it became available and its predecessor software before that. I am pretty sure that my GLONASS and USB issues are unrelated to that.
Click to expand...
Click to collapse
I have been able to reproduce the first issue on every device I've ever had with a custom ROM running
I don't think anything other than the Google devices has that working and a fix could be only possible by a manufacturer
As of now this issue affects oneplus and many other devices too
Audio through USB; that's a complicated topic
I don't have anything that connects by USB to test this. So even if it was broken the fix wouldn't be possible
The second reason, audio through the usb uses digital gain instead of analog gain (which really sucks) so why even use it?
anupritaisno1 said:
I have been able to reproduce the first issue on every device I've ever had with a custom ROM running
I don't think anything other than the Google devices has that working and a fix could be only possible by a manufacturer
As of now this issue affects oneplus and many other devices too
Audio through USB; that's a complicated topic
I don't have anything that connects by USB to test this. So even if it was broken the fix wouldn't be possible
The second reason, audio through the usb uses digital gain instead of analog gain (which really sucks) so why even use it?
Click to expand...
Click to collapse
Thank you for the confirmation on the GLONASS situation.
With respect to USB audio streaming, it is the only way I have of listening to the music on my phone through my car's sound system. Not worth getting a newer car just to fix that.
Not a big deal about digital gain, just set the phone to full volume and use the car's analog volume control to reduce it to a reasonable level.
The site is down. I can't download the rom
Ctafolla2 said:
The site is down. I can't download the rom
Click to expand...
Click to collapse
It seems he deleted the ROM :/
Hi guys currently builds aren't booting so I've stopped builds
I'll let you know when a new build is up
NovaKenn said:
Thanks for bringing another rom for our device!
We really appreciate it.
Click to expand...
Click to collapse
True, our device also deserves this, not just flagship phones
Guys I solved the bootloop issue
I'm currently out somewhere but when I get time I'll do a build
Stoped?
Ok so guys I found a new maintainer
Here's what happened: so my moto suddenly stopped working. Like it won't detect my son card at all, won't connect to any WiFi networks, hard reboots randomly, etc
Currently I have exams and so I have no time to get my device in for service
I'm the meantime I found a person who's willing to maintain this until I am back. His username is infinite something... I forgot but basically a build is coming out very soon
Ok guys just give me about 4 hours I'll get a harpia build out
New build is up
Many people here claim they "upstream" their kernel and how secure it is
I've looked through all of those kernels
Here's the simple truth: no kernel for the Moto g4 play is secure or even up to date with security patches
In fact the entire msm8916 family for Moto devices has totally messed up security, at least when it comes to kernel
anupritaisno1 said:
Many people here claim they "upstream" their kernel and how secure it is
I've looked through all of those kernels
Here's the simple truth: no kernel for the Moto g4 play is secure or even up to date with security patches
In fact the entire msm8916 family for Moto devices has totally messed up security, at least when it comes to kernel
Click to expand...
Click to collapse
what about yours??
Where is the link?
@ki said:
what about yours??
Click to expand...
Click to collapse
Nope not secure
NovaKenn said:
Where is the link?
Click to expand...
Click to collapse
https://srv1.botstack.host:8001/moto/harpia/haruhirom-stable.zip