Related
hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J
Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1
ETA
depending on problems and developers that will join
from 6 months to NEVER
This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus
I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.
All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?
CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.
Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse
FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page
diff is 5mb on proper tag
pushed on github
nice to see so many developers trying to help
FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes
In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements Tasssadar made, and I think it is pretty significant.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a,
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ATAGS_PROC=n # This one is turned on automatically, but it is not needed, so you can disable it.
All these options must be enabled.
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository. You can get statically built binary at https://github.com/Tasssadar/multirom/blob/master/install_zip/prebuilt-installer/multirom/kexec
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - he used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped him out with that, thanks.
For hammerhead, he has improved the patch a bit - only the host needs to be patched now and he has added support for DTB.
This thread was used as a template Credits to @Tasssadar for his Nexus 5 patch
Awesome people helping with our G2's development. Thank YOU!
patrik.KT said:
I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition.
Click to expand...
Click to collapse
What benefit would there be to non-MultiROM users? (Just curious.)
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Any. Just any.
Actually I can't think of anything. It's only to bring the device to a full reboot to load a new kernel.
Odoslané z môjho HTC Desire 601
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Not for common user, in epic4g kexec used by kernel devs to test a new kernel build without replace the existing kernel.
They just load a temporary kernel to test. Then that kernel will gone after a reboot.
Hope to see new kernels that support MultiRom! Great work man!
Would this allow a multiboot with AOSP and Stock roms?
AbdulrahmanAmir said:
it doesnt work while i have stock and the secondary is aosp (dU-dirty.unicorn) when i boot the secondary it works sound only but no display just black screen plzz help
Click to expand...
Click to collapse
The patch is not necessary at the moment, because of the locked bootloader. It's just for devs to be prepared with their kernel when we can unlock the bootloader, so that multirom will work as it should.
Odoslané z môjho HTC Desire 601
Thanks for your great thread. But there is no instruction about how we can add that patch to kernel source. Could you write more details about implanting this patch?
No response??
mohamaadhosein said:
No response??
Click to expand...
Click to collapse
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Hey, some changes need to be made to the patch.
On line 353, change the number from 22 to 21. Also, it has some errors when modifying head.S, which I had to fix manually..
But guys, my kernel is building with the latest multirom. This **** is going to maybe work soon!
I'll keep you all posted.
Thank you man
Guys, I think I've done it. Kexec hardboot patched kernel for 5.1.1 and thus multirom compliant, which I am preparing to build with twrp. this is very exciting.
When will it be ready?
Are you kidding me? No ETAs. I literally haven't even announce it yet and somebody asks for an ETA.... It will be ready once I test everything to boot well on my device.
patrik.KT said:
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Click to expand...
Click to collapse
It says the patch is corrupted on the line 375
Warning: Use this on you Own Risk
Features:
S2W D2W
Stereo Call Record
GPU Tweak
NO Write Protection for System Partition
AWB LCD Custom Color for .Rec 709 Profile
Few little Code Changes
How to:
Load boot.img into fastboot folder
run this command:
"fastboot boot thedreamer-Desire510-64bit.img"
When the Device Boot UP and is Stable
Flash the boot.img with:
"Fastboot flash boot thedreamer-Desire510-64bit.img
Download:
http://forum.xda-developers.com/devdb/project/?id=8179#downloads
Source:
GitHub
I Give no Support i make this Kernels Only for me and post it for other 64bit MSM8919 User to Use.
I Integrate only my Wishes
XDA:DevDB Information
TheDreamer, Kernel for the HTC Desire 510
Contributors
Thestealth2, thestealth2, RBHeromax
Source Code: https://github.com/thestealth131205/HTC_Desire_510_64bit
Kernel Special Features:
Version Information
Status: Stable
Stable Release Date: 2015-02-10
Created 2015-02-10
Last Updated 2015-02-10
I'd love to try it. Is there a link to download it please?
Burtrum57 said:
I'd love to try it. Is there a link to download it please?
Click to expand...
Click to collapse
thanks for the source it coould prove useful in compiling a custom rom for the 64bit i may have to re sync the cm11 repo and give it a shot..
could you also provide a link to the boot.img so we dont have compile the kernel lol.. cheers..
excuse me if i sound stupid,but what is "AWB LCD Custom Color for .Rec 709 Profile" actually? is it actual modified screen colors or is it just the custom kcal driver?
Kcal driver. For Rec. 709 Calibration. My display is calibrated with a Colorimeter.
Download is in First Post
Sent from my HTC Desire 510 using XDA Free mobile app
Thestealth2 said:
Kcal driver. For Rec. 709 Calibration. My display is calibrated with a Colorimeter.
Download is in First Post
Sent from my HTC Desire 510 using XDA Free mobile app
Click to expand...
Click to collapse
do you remember which file you modified for the calibration? i would like to apply it to my kernel,i dont wanna bug you :silly:
See source and merge with youre source
Thestealth2 said:
See source and merge with youre source
Click to expand...
Click to collapse
i build for the 32bit,i cant merge a 3.10 kernel with a 3.4 one :silly:
I write you next days a pn. Have no time at the moment.
You can push a 64 bit stock kernel to git an the push my source than can you see all changes. ?
Just a question...
Exactly which toolchain you use to compile??
I'm about ready to flash your kernel - thestealth131205 I'll update after i get my flash on.
Thestealth2 said:
Features:
NO Write Protection for System Partition
AWB LCD Custom Color for .Rec 709 Profile
Few little Code Changes
Download:
http://www.dhm-server.de/thedreamer-Desire510-64bit.img
Source:
GitHub
Click to expand...
Click to collapse
Thank you for your kernel, have been using it for a month (on my EU) and it works very well!
However, could you make some progress please...
As it is seen on this forum your work is the only one for 64bit. So, could you consider some suggestions?
Namely in their 32 verisons of modded kernels developpers write here about improving screen touch responsiveness and removing HTC's backdoor "debugging" access... How about it?
download link unavailable
See first Post
RE: THEDREAMER 64 bit
Thestealth2 said:
See first Post
Click to expand...
Click to collapse
Last I touched base/read with you and RBHEROMAX, if I understood correctly, you were going to be changing something so I've been trying to remain patient and wanted to inquire about this. I picked up a Samsung Galaxy S5 Sport (sprint) all stock to entertain myself with. LOL. I have the utmost respect for you and Rbheromax, I'd like to thank you again for your dedication and time put into this project and the respect and patience you give to everyone that asks you questions on any level. You are very special individuals giving the gift of knowledge to all that seek it.
All that came together to make the 64 bit HTC Desire 510 project. All that came to the rescue to make THEDREAMER possible. You are pioneers and not afraid of a challenge. I don't know if you have any sort of recognition for everyone that takes the time and puts fourth the effort to share the GIFT OF KNOWLEDGE. If not, I'd like to declare Tuesday, March 31, 2015 programmers appreciation day! And you both deserve the GOLDEN THUMBS UP AWARD just because I appreciate your patience, and you caring enough to share knowledge with individuals that otherwise wouldn't have the opportunity to delve into this field.
THANK YOU!
Hopefully I'm not breaking any rules by speaking up. But I. Believe it's time for some recognition with a simple shout out saying THANKS, YOU MADE A DIFFERENCE IN MY LIFE.
paying it forward....
:highfive:
Should the kernel name be "3.10.28-g36bd0f8-dirty (root @ speedstarlap)" after installing?
I'm trying to enable S2W and can't seem to get it working, was wondering if the kernel installed right, or if there were other versions - you said you have MSM8919, whereas my 510 shows up as MSM8916- a typo or actually different chips? (if possible, could you please tell me how to enable S2W if the kernel installed right?)
@edit - Managed to get it... "working" - if I lock the screen and swipe to right and left near the menu buttons within 2-3 seconds from locking, it works. otherwise it doesn't. D2W is fully dead though. I'll poke around it a bit more and see if I can get it to work properly...
Hi, which gcc are u using? and how to compile the dt.img?
I compiled a kernel for D820, only with stock dt.img could bootup. It boots into bootloader if I use the dt.img which I compiled from stock kernel source.
could u help me?
Kernel works great and great improvement in speeds! Thanks
I've a problem. Sometimes the touchscreen doesn't react after waking up my phone. But the volume up and down and the power button work.
Can this be because of the kernel? I don't know. Please help.
Lonely_Boz said:
I've a problem. Sometimes the touchscreen doesn't react after waking up my phone. But the volume up and down and the power button work.
Can this be because of the kernel? I don't know. Please help.
Click to expand...
Click to collapse
I have the exact same problem I have to restart my device for screen to be back in action
This has reached a point that those who don't depend BT calling may be able to use it as a daily driver. Just be sure to backup first!
The flashing on first boot during setup may cause issues for those with epilepsy. This is due to how to disable the second screen.
Working:
Camera! https://www.celsoazevedo.com/files/android/google-camera/f/GCam5.1.018-Arnova8G2-V1.7Beta2.apk is recommended with Nexus 6 HDR config in advanced settings.
Bluetooth (skips with wifi, and doesn't work in call)
NFC
Wifi -- two users have reported issues on their devices, while it works for others.
GPS
Sensors
Sound
Calls
Fingerprint
Data
WiFi tethering
Second screen disable hack
Not working and issues:
Screen glitches on first boot. Reboot and will be good after (part of hack to disable 2nd screen)
Tap to wake
Flashlight tile: install flashlight tile for kenzo in play store with root to workaround.
Slight animation glitch when switching activities due to second screen hack.
BT issues above, and doesn't work in call.
If you use camera immediately after turning on, it may not work. You must wait about a minute after powering for it to work (it will always work after).
Probably more.
TODO
BT fixes
Tap to wake
flashlight tile
get a proper 2nd screen fix like v20 working without additional issues. v20 dtsi hack doesn't work for us due to dual panel depending on partial update (most likely).
Repos (kernel is lineage-15.1 branch):
Kernel
v10-common
h901
blobs
Changes from AOSCP
Using Ruthless launcher instead of Luna
Two reverts to support substratum themes in addition to CypherOS' color manager.
Use opengapps for gapps, magisk for superuser (may have issues with modules).
Download
Buy me a beer with Bitcoin: 1h9o1Ei9thLd8JKRz3z7PUGhX6dtfnktY
Bugs with workarounds:
Wifi doesn't connect and MAC address is all zeroes (only some users):
This is a misc partition that has MAC address hardcoded to a randomly generated address. This should work permanently on any device with the issue so long as two aren't on the same network. If anyone would like instructions on how to modify with a new MAC address, let me know.
Image https://www.androidfilehost.com/?fid=818222786056033811
Instructions:
Place on /sdcard
Reboot to recovery (for advanced reboot in CypherOS hold reboot button for full menu)
From twrp terminal or adb shell, run: dd if=/sdcard/misc.img of=/dev/block/bootdevice/by-name/misc
Reboot and enjoy fixed wifi
No charging indicator (but still charges):
Boot device plugged into power or USB and the indicator will work the entire power cycle. Working on a fix but not as trivial as I'd hoped.
Bootloop bug:
I recently got hit by the infinite bootloop bug, with the only workaround of disabling the big cluster. Here's a modified TWRP that only uses the little cluster (used Eliminator74's image):
https://www.androidfilehost.com/?fid=818222786056035329
And here's a little cluster only boot image from the titan kernel (our CAF kernel has msm_thermal issues with booting with disabled big cores, needs modifications):
https://www.androidfilehost.com/?fid=674106145207491774
nvm, fixed in current build
Just uploaded a new build. Changes:
Tweaked touch offset
Synced CypherOS to 6.0.0 (fixes navbar on first boot and some others)
Fixed init script to set display res (part of the second screen disable hack)
Updated Ruthless Launcher
two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks
sun_is_shinning said:
two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks
Click to expand...
Click to collapse
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.
johngalt1 said:
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.
Click to expand...
Click to collapse
Will you add the other version? For H960, H960TR vs.
Kasimpasali1921 said:
Will you add the other version? For H960, H960TR vs.
Click to expand...
Click to collapse
It's planned.
Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.
TheEnekaign said:
Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.
Click to expand...
Click to collapse
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.
johngalt1 said:
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.
Click to expand...
Click to collapse
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)
TheEnekaign said:
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)
Click to expand...
Click to collapse
For building without the manifest, clone the device and vendor repos to their correct folders, check aoscp.dependencies to clone additional repos to their correct folders, then just run . build/envsetup.sh ; breakfast aoscp_h901-userdebug, and then you can make bacon ?
I based the device repos off the g4 repos for aoscp, which are just los 14.1 with Oreo and now v10 changes. The kernel is based on the los 14.1 lge msm8992 kernel with changes necessary for Oreo, CAF merged in, fast charging support, the second screen disable hack, a commit for building properly with a lge display flag, the dtsi for other v10 variants (thanks to ehem), and a defconfig for h901.
Edit: keep in mind RR may have the same display corruption issue with our second screen hack that LOS has for us.
New build uploaded. Changes:
- Fixed touchscreen alignment. Bottom of navbar now works.
- Synced with upstream CypherOS
- Testing navbar theme settings from gerrit.
New build uploaded. Changes:
- Possibly fixed occasional no sim on boot (ty kessaras/steadfasterx)
- Synced with CypherOS
- A few upstream ALSA kernel changes
- Ruthless launcher updated
- Two upstream reverts to fix substratum themes.
There's now also a local_manifest for users who would like to build themselves https://github.com/amillogical/local_manifest
Is this compatible to my lg v10 h962 (from taiwan)?
ViciousDiplomat said:
Is this compatible to my lg v10 h962 (from taiwan)?
Click to expand...
Click to collapse
No, but it can be. Is your device bootloader unlocked? If so, I'll do a build from h815 (g4 equiv) you can test. If not, I can help bootloader unlock it with USU.
I'm not sure how many know, but all v10 variants are now bootloader unlockable with USU. I just haven't had a chance to build for them or post details.
well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.
sun_is_shinning said:
well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.
Click to expand...
Click to collapse
Yes, it only needs a config for h960 at this point. Ehem imported the panels for all the other variants so we can use a unified kernel between all g4 and v10 variants.
Will done sir i'll buy you a bear on your bitcoin wallet for sure.. Gr8 job
An old user for v10 (p20 pro now) but still love this beast
New build uploaded. This won't fix wifi issues for those that have them. This build needs a dalvik-cache wipe after dirty flash due to memory override changes (last bullet). I've also started using AndroidFileHost for uploads.
Changes:
- Synced with upstream CypherOS (bumped to april security bulletin and a few new features).
- NFC should be fixed. This needs more testing, as I don't have anything to test the functionality but it turns on/off.
- Corrected STM laser permissions (autofocus seems to be like in stock rom now).
- Changed link to modified google camera in OP since the previous version didn't have functional HDR+.
- Dalvik heap and hwui memory overrides updated for our device's 4G ram and high res display.
And thank you @sherif2222222
New build up at sx.ix5.org, use version 2018-10-30.
Changelog here: https://sx.ix5.org/changelog.html
Install guide: Flashing AOSP on Xperia XZ
XDA:DevDB Information
AOSP Pie based on Sony Open Devices Project, ROM for the Sony Xperia XZ
Contributors
local__hero, fastbooking, oshmoun
Source Code: https://git.ix5.org/felix/local-manifests-ix5/src/branch/ix5-customizations
ROM OS Version: 9.x Pie
ROM Kernel: Linux 4.x
ROM Firmware Required: .184 / .192
Based On: AOSP
Version Information
Status: Nightly
Created 2018-11-09
Last Updated 2019-05-17
Reporting bugs
Important: Read the bug list before posting. Anyone can add bugs to the list, just follow the rules.
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
Don't make me ask you for logs every time!
I will repeat the rules again here:
Rules:
New bugs must include version where error popped up and which oem version you are using
Only reproducible errors
Should include adb logcat (linked in a pastebin service like https://del.dog)
Must include clear description what is wrong
If it is a visual/SystemUI bug, only report it here
If it is an internal bug(e.g. fingerprint crashes device), report it to the Sony bugtracker as well!
Always try to fix the bug yourself first! Then submit a pull request to Sony
Must search if error has already been reported (bug tracker, this document, dev buglist)
If you've reported the issue somewhere else already and just want to track it here as well, add a link
Before reporting a bug, always make sure to isolate it. That means, wipe everything, install only the ROM without GApps and Magisk and see if the problem still exists. Only then report the bug!
---
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
---
In 9.11
1. Everything still works
2. Charging with plugged at screen off works
3. On gcam portrait mode and night photo gives purple glitched image
And phone seems to be faster.
Bug: 9.11 with oem v2- Clean install
- Hotspot not working
- Phone call issue - Mic and speaker not working, cannot hear anything or say anything << Listed in the bug
- Top speaker not working
Still testing.
An update
Yes, we know calling is kinda broken right now on both oem versions. Yes, we know you have problems with dualsim devices because you didn't flash the dualsim patcher. Yes, battery life isn't very good because we are testing out some increased CPU frequencies so video doesn't stutter. (you can go back to the 11-05 build which has the old CPU freqs and compare).
We're aware of a lot of these issues, and they are all tracked in the current buglist (see post #2).
Development happens mostly in the Sony open devices program, with a few heroic volunteers contributing. Right now, a lot of work is being done to get the current flagships(think XZ2, XZ3) to a semi-stable state, but work for our device is done as well.
You can check progress in the sonyxperiadev repos. E.g. recently, some changes to the telephony HAL integration have been made, see the common device repo.
Why is it taking so long to fix all this?
Sony buys many of their processors from Qualcomm. Lots of stuff in phones is proprietary and covered in patents, and you can only get the source code if you sign an NDA. So even if Sony wanted to, they could not release the source for a lot of things.
See all the files with the name "qti" in them? That's Qualcomm Technologies, Inc. See all the repos named something like "qcom-something-something"? That's Qualcomm.
When there's a problem, we have to report it to Sony, who report it to Qualcomm. This takes time already. And don't forget Qualcomm has suppliers as well, and so on and so on. The same is true for other parts, e.g. the Wi-Fi chips are from Broadcom.
Then, support for hardware stuff is on many levels. A lot of low-level drivers that are driving the hardware are on the /odm partition(the one that the oemv1/v2 blobs get flashed to). Then there is work to be done tweaking the actual hardware abstraction layer(HAL) interfaces that work with these driver blobs. Then there are kernel drivers that can go wrong and mess up. Then it can be a problem somewhere higher up in the Android frameworks. Lots of detective work.
If new blobs from Qualcomm come out, Sony itself needs to do some testing, and then releases a new oem version. It won't just magically work, we need to tweak the SODP vendor side as well. It could be as easy as changing a version to a newer one, but it could also be a lot harder. The sonyxperiadev crew knows what's needed to integrate these new blobs, but it still takes time and testing.
Qualcomm provide the a lot of the source code to work with their hardware and blobs from the higher-level Android side in their CodeAurora forum (CAF) repositories. The relevant changes then get merged into the sonyxperiadev repos and we can test if it works(or if something new is broken...).
For more info, read the Android documentation on hardware etc.
The chip in our phone, the MSM8996, is quite old already(even the SDM845 in the XZ2/3 is already quite old in processor standards). We can be luck that Qualcomm still provides support. But it's not a priority to them, they want to sell new
ones of course. That is also a reason updates can take longer.
Regarding full forced-reboot crashes:
Sadly, as of now, for some people the "/sys/fs/pstore" folder does not get populated after a crash. This is important to diagnose what happened.
You can apply this patch to force a kernel panic on every reboot, but I would recommend that you do
so only if you know what you are doing.
Regarding battery life:
Please install BetterBatteryStats
and find out what is draining the battery.
This could really help us out! But first, make sure you are not running any GApps, because the Google Mobile Services are a massive pile of battery drain.
If you absolutely have to use GApps, please run only the "pico" GApps version!
---
About the posts here:
Like 90% of posts here and in the old thread are full of people who just plain refuse to read, asking how to install or demanding someone help them out with something that has already been answered time and time again. This makes it extremely annoying for the us who have to scroll through pages of useless stuff to find the genuine bug reports. You do realize this site is literally named "xda-developers", right? If you're unclear on the concept, please read this: https://forum.xda-developers.com/showpost.php?p=16682226&postcount=2441
"This doesn't work!" - "This thing crashes!" - That gives us almost no clue what is happening. We need logs, or we can't do anything about it. I have only one phone, and I only use the stock ROM. There are a lot of nice testers who send others and me helpful bug reports, with detailed explanations in what circumstances it occured, with proper logs.
With that info, the Sony open devices team and us can actually look into issues.
So please, if something doesn't work AND we are not aware of it yet, post it to the bug list (not here!) and attach a link to a log that you uploaded, e.g. to a service like hastebin.com.
nhicko95 said:
how is battery life?
Click to expand...
Click to collapse
Test it out, please. And don't forget to report the diagnosed battery stats.
DarkPrinciple said:
I should be able to get to 12 lunch with my battery being more than 50%
Click to expand...
Click to collapse
I've tweaked for more performance right now, but you can use 11-05 to get old CPU freqs. Also, please help hunt down what is draining the battery, it's most likely too many held wakelocks, but it could be any number of things.
bihslk said:
So what is the latest and best working version of this rom?
Click to expand...
Click to collapse
It's literally in the first post.
bihslk said:
Rom is pretty OK but really annoying top speaker bug. Only lower one works.
Click to expand...
Click to collapse
That is already in the bug list. Please read the bug list before posting.
Update 2018-11-16
Some new developments are happening.
Oem binaries version 3 are out. This should give improved power management. The SODP team has also worked on getting audio handling during calls to work. A big thanks to oshmoun for his work on the audio manager. This change was introduced on the 11-15 build. The issue of no call audio when a bluetooth headset is connected is still present as of now.
Changed IRQ handling (PR by Angelo/"kholk"). This should give better battery life and maybe faster wakeup from deep sleep. But could also lead to instabilities and crashes. Send logs & pstore, see post #2. This change was introduced on the 11-15 build.
Testing kernel 4.9.137 i in progress (we are currently on .103). This means stability and security enhancements from upstream linux. Thanks to Nathan Chance who opened this pull request..
But some of those upstream changes might be incompatible with our Sony kernel, so we have to test that. Send logs & pstore, see post #2. This change was introduced in the 11-16 build. If the 11-15 and 11-16 builds are unstable, revert to an older one. But please be brave and run them for at least a day to get us logs of potential crashes.
---
optixperiaa said:
I am always confused about "flash latest stock ftf" part about roms as a newbie.. if we flash sony's ftf how can we flash rom ? isnt it overwrite ?
Click to expand...
Click to collapse
Your phone software is made up of many layers. The ROMs like omni or this AOSP-based one only modify your /system and /boot partitions.
But when you update your stock firmware via flashtool, you also update your phone modem firmware, your qnovo charging controller firmware, your lower-level bootloaders etc. That is why we instruct you to update to the latest stock firmware. You could theoretically skip flashing /system in flashtool(because it will get overwritten anyway, as you've already discovered) and directly flash a custom ROM afterwards.
When you're coming from omni, there is no need to flash stock firmware again in between, because your other partitions stay the same. Just a new /oem is needed.
viori said:
flash omni_kagura-2018-11-20_UNOFFICIAL_TESTBUILD-2
Click to expand...
Click to collapse
Again, please keep this thread about development for AOSP. The omni builds are not meant for you.
If you have trouble installing then simply don't use it.
DO NOT POST HERE FOR HELP OR YOU WILL BE REPORTED. Read everything before posting.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
The OP has requested that you do not post questions in this thread, please use the thread he states in the OP to do that.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
Click to expand...
Click to collapse
Thanks
Thread cleaned
General update
Newer builds will have selinux set to "enforcing". Most denials should have been fixed or are irrelevant. If you encounter any problems, selinux-related or anything else, please report them to the Sony bugtracker or - even better - submit a pull request to the selinux-policy repo.
Update 1: vendor blobs aren't binderized correctly atm, so no network. You can set selinux back to permissive to fix most issues atm.
The Wi-Fi hotspot has been fixed thanks to oshmoun. In newer builds, it should be using less battery.
Next thing we're going to tackle is deep sleep and battery drain. Big pain point and one of the last blockers, apart from the camera and bluetooth in-call audio.
You might have noticed that the omnirom device trees have been updated to 9.0. Nightly testing builds work fine, but they have the same issues as the AOSP-based ones.
Work is also under way to get a Pie-based TWRP recovery stable, with support for FDE encryption(this means that you will be able to back up your encrypted installations). Mounting /userdata works, but the builds are not ready for public release yet.
Update
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
local__hero said:
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
Click to expand...
Click to collapse
Great job.
I already built a custom Pie kernel about a week ago to gain better performance but the charging bug was driving me insane :crying:
I guess now's the time to go back to the mighty Pie and try building a nice and hopefully stable Marrow Kernel.
Cheers
Finally a new build is out!
I can't pass safety net on latest build.
Any ideas what should I use ?
Since modules for spoofing fingerprint simply don't work.
I tried universal safety net fix but with no avail.
V 12.15
Charging working fine. But i have problem with camera, photos are very dark.
Sometimes touch screen not working and i need to switch the screen and on again.
ov2rey said:
Sometimes touch screen not working and i need to switch the screen and on again.
Click to expand...
Click to collapse
Disable Dt2w
oem v4 is out
DahakePL said:
Disable Dt2w
Click to expand...
Click to collapse
Thank you It's work!
Layns said:
oem v4 is out
Click to expand...
Click to collapse
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
ov2rey said:
Thank you It's work!
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
Click to expand...
Click to collapse
I tried it works fine but the camera sucks and the sound is bad, the screen opening with double tap is running slow, the charge is a little quick