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
Hi.
I've had nothing but trouble trying to figure this one out. Information is quite lacking, and no amount of thread searching or google searching is helping me.
I've previously had my DU rom build working fine, until I had to reinstall Linux that is. Since that point, I can build the complete rom, but kernel gen always hangs on building the dt.img.
Mostly, and only, because the build doesn't seem to actually build the DTB files? Are these supposed to be generated by the build environment?
For now I've just pulled the DTBs from the Sony git, and copied them to the "out" dir in the relevant place. But it would be nice to figure what I've done wrong.
Cheers!
including this commit in my sources caused the same error while building SlimKat:
http://review.cyanogenmod.org/#/c/74677/
if you have it in your rhine-common tree, try to revert it then build.
Regards,
Omar.
OmarEinea said:
including this commit in my sources caused the same error while building SlimKat:
http://review.cyanogenmod.org/#/c/74677/
if you have it in your rhine-common tree, try to revert it then build.
Regards,
Omar.
Click to expand...
Click to collapse
I think that's got it. How in the world I missed that, I'll never know.
Thanks for your help, it's much appreciated.
Hi,
I get an increasing amount of pms asking me how to build for chagalllte. If I would answer all that questinons en detail I could stop developing, and just answer emails. So I decided to publish some of the most basic and detailed answers I gave here in this forum.
I also hope, that people trying to build for chagalllte can find each other and build up a team for the task of getting cm to chagalllte. TEAM: together everybody achieves more...
Hope, this helps:
Hello,
Devices are said to be equal... As t700 and t800 are being equal but screen size. That's NOT true. They differ verry subtile. (t700 vs. t800 i.e. differ in sound and touchscreen drivers...).
That being said I would start like this:
learn git - not github, but git on the command line
get both: most current sammy rom for t800 and t805 and put them both untared side by side to you disc
compare them thoroughly - learn the differences
from opensource.samsung.com get kernel sources for both devices: again - learn the differences
start from my gits (device, vendor, kernel) - fork them on github, clone locally
put the differences to the three gits: step by step - commit every change with long comments (wil save your as)
before flashing your first build take a look at /system/etc/wifi of running device with sammy rom, take a look at updater-script of flashable sammy-rom zip, take a look at my git repackrom.sh and use it on your flashable zip.
don't be frutrated, iron out my errors, sammy errors and your errors - build next time...
Good morning,
to get this straight: driver refers to kernel code (statically build in or build as module), blobs (or prorietary binaries) refers to already build binaries from sammy rom: these are libs (i.e. libGLES_mali.so), compiled executables (i.e. gpsd, sswap), loadable firmware for hardware (i.e. /system/etc/wifi/*), some ascii files (some keymaps if I remember right) and all that I forgot...
Of course the mali drive (kernel) interacts ditectly and closly with some of the blobs (in this case libGLES_mali.so, and some people refer to leb_GLES_mail.so as mali driver. This doesn't matter for most people - for you IT DOES MATTER to know of which part I'm speaking...
I recommend usimg the kernel sour8ce from opensource.samsung.com fot T805, but cherry-pick at least the commits from my git or crpalmers picassowifi to make it build inline cm (so if you haven't learned git you are lost here the first time).
For the versions: yeah, you make with sammy's 4.4.2 blobs a cm-11.0 (aka 4.4.4) build. We have to take what we we get - we have no 4.4.4 blobs and propably nver wil get... Sorry.
For cm-12.0 I build at the moment with a mix of sammy 4.4.2, widevine 5.0 (taken from manta) and a hexedit patched libGLRS_mali.so from picassowifi - thats fun, mage. But relax, for cm-11.0 you will come along with the blobs from sammy 4.4.2 rom. You have to find out which blobs you need in addition to the ones I have taken from 800 rom to get modem running.
For the build environment: there are several setup guides for cm. Use google. I use gentoo amd64 build from scratch - but I think you won't want that... *lol*
Add this
Code:
[alias]
lg1 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(bold white) %an%C(reset)%C(bold yellow)%d%C(reset)' --abbrev-commit --date=relative
lg2 = log --graph --all --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(bold white) %an%C(reset)' --abbrev-commit
lg = !"git lg1"
to the end of /etc/gitconfig, clone my three gits, cd to them (one after the other) and type each time "git lg1"... "git show [hash]" will show you a single commit. I know it must be boring and anoying for you, but: learn git.
May the source be with you, Nvertigo
thanks so much for posting this, i just hope someone with skills can pick this up
TheLoverMan said:
thanks so much for posting this, i just hope someone with skills can pick this up
Click to expand...
Click to collapse
Just did a quick count: got 27 pms from 8 different people regarding this subject. So if we calculate that only half of this are really interested in giving up their sparetime, partnerships and all other activities, there could be a team of 4 people...
Code long and prosper, Nvertigo
Im also going to try cm forums see if anyone has come up with something
I will try to build and see if i can use your help, if needed. Thanks for the tutorial though.
I would be so grateful for CM12 on LTE model. I don't have knowledge myself, but I thouht maybe we all users of T805 could donate for NVertigo to collect money for him to buy LTE variant? What do you guys think?
I'm working on CM14, after a lot of go through I finally zipped it.
but its not booting up.
I used following Resources
Device Tree - It needs a lot of modifications.
Kernel
Vendor Files
MSM 8996 HALs from CM14 are giving Errors, so I used HALs from OMNI
EngMod: Logcat
Bump!
No one?
WhyOrean said:
Bump!
No one?
Click to expand...
Click to collapse
Unfortunately i cant help but i bump this thread
Thanks for your effortand hope someone helps.
Try port rom 7.0 from one plus 3 with file of miui n leak
Update: Got it booting :highfive:
But it seems like its display needs to be calibrated.
It shuts down after a giving a quick glance.
This time I used Precompiled Binaries from TheMuppets
Also Hardware/qcom/display-caf and Hardware/qcom/media-caf throw errors.
So I used ones from CM13 Branch.
-> Syncing CM14.1, seems like CM14 is abandoned.
WhyOrean said:
Update: Got it booting :highfive:
But it seems like its display needs to be calibrated.
It shuts down after a giving a quick glance.
This time I used Precompiled Binaries from TheMuppets
Also Hardware/qcom/display-caf and Hardware/qcom/media-caf throw errors.
So I used ones from CM13 Branch.
-> Syncing CM14.1, seems like CM14 is abandoned.
Click to expand...
Click to collapse
good job man! :good:
Whoa, that would be great, please keep us informed!
This is the thread for the unofficial builds for CM 14.1.
I'm using Nightcore500's device/kernel trees he created for LineageOS 14.1 so of course massive thanks and kudos to Nightcore500 for getting those working!! It's much easier to use another set of trees than manually convert the M8 trees to fit this phone!
Anyway this is the first build and it built. I have no idea whether it works or not as am not sure whether to test it on my only phone (!) but I think I probably will anyway! :silly:
It's attached on this post and I'll add more detail later on.
Cheers!
CM14.1 08-05-2017
A question, can you please explain why you use the source code from nightcore and open a second thread in this you also provide CM / Lineage 14.1? That makes zero sense? oO
Finusfix said:
A question, can you please explain why you use the source code from nightcore and open a second thread in this you also provide CM / Lineage 14.1? That makes zero sense? oO
Click to expand...
Click to collapse
Ha! I haven't been reading the news...
May well be. Nevertheless, you can ask first if he is not already planning to publish the ROM if he already provides the source code for it.
I would not find it at least nice when i work hard on a project and then someone takes me away.
As long as nightcore is working on Cyanogenmod and / or Lineageos it should also be his work. This is one of the first code of honor of any xda developers. (Or generally any developers)
Please be so fair.
Any other type of ROM is open for you like Resurrection Remix, dirtyunicorns and so on.
This thread only creates confusion.
Tbf Soenetsi has done a lot of work for our phone so no need to be so harsh
How does this version perform?