Related
Believe this should be question for all newbee as well.
Downloaded new source code from opensource.samsung.com
get all source and whole environment setup from android.com
follow readme in samsumg's source code so I'd merge with android generic source
After make, the output system.img is only 50mb. Compared with samsung's system.img 250mb. After extract, there are significant differences.
apps, bin, frameworks, csc.. are much different.
Anyone had idea how to build correct samsung's image?
I created new launcher and lockscreen, it works on emulator, but cannot port to samsung Galaxy S because of environment setup, your help step by step will be very helpful, thanks!!
Hi buddy,
Do you know what’s the problem?
I meet the same problem about compiling.
The system.img only 58M. I cann’t run the image with emulator.
I don’t know how to solve it.
I guess your problem is that you don't get the drivers on the sgs.
Many are not open source.
So you can't build a firmware from scratch.
The open source from Samsung is only the kernel.
What you need is to import all missing stuff in the firmware you did compile, but you will face a bigger problem to change all places that using the missing stuff.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
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
General informations:
This thread's aim is only to represent a central meeting and discussion point for BCM21553 developers and, in particular, for the open Kernel/ROM sources development for the Samsung Galaxy Pocket GT-S5300 (codenamed Cori).
Information for common users:
As already described in the previous section, if you are not a developer, please restrict your posts to the general discussion thread so that developers can maintain good communication. Every post that is not strictly respecting these rules will be reported to the forum moderators. Thanks for your understanding.
For any other BCM21553 device related question or information, please, use this thread as a reference point, instead:
[DEVS ONLY][BCM21553 series] CyanogenMod 11 for BCM21553 Development Discussion
As someone already might know, I'm streambinder, from MoltenMotherBoard team.
I have already followed some projects for the GT-S5300, but especially kept in contact
with some of the events related to the porting of ROM and Kernel sources for BCM21553 chipset based devices.
In this precise moment, the sources in my possession allow you to be able to compile
a bugfree CWM 5.0.2.8 (based on CyanogenMod 7 code) with a kernel based on the Samsung stock one.
The only - fundamental - problem was due to the fact that unless I hadn't used the prebuilt INIT binary
token in the Samsung stock firmware boot.img, the phone would not work - or, better, boot up.
This means that until the situation - regarding this issue - doesn't change, our access to the porting of custom ROM
would be barred.
Recently, I decided to give Cori another chance and rework my sources, looking at the wonderful work brought
by the BroadcomCM team on CyanogenMod 9 (in particular, thanks to @bieltv.3 and @Alberto96) and @psyke83 on CyanogenMod 11.
They've not only been able to run these two ROMs in a more or less crude way, but this developer has been able to write
the necessary strings to make the INIT binary of some of these BCM21553 devices opensource.
Strong of this informations, I readjusted some of the sources of BroadcomCM's CyangenMod 9, which includes
all the progress carried out by both the team and psyke83, in order to make them work even on Cori,
and am now next to the first test of the CWM 6.X.X.X, based on IceCreamSandwich code.
At the same time, @akhbh is working on the KitKat code based CWM.
I hope I can give more information about any progress as soon as possible.
The General Discussion thread for non-development issues is here:
*.[DISCUSSION] CyanogenMod 11 For Galaxy Pocket GT-S5300 Discussion Thread
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
streambinder said:
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
Click to expand...
Click to collapse
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
akhbh said:
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
Click to expand...
Click to collapse
Perfect.
Which kernel have you based your build on?
streambinder said:
Perfect.
Which kernel have you based your build on?
Click to expand...
Click to collapse
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
akhbh said:
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
Click to expand...
Click to collapse
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
streambinder said:
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
Click to expand...
Click to collapse
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
akhbh said:
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
Click to expand...
Click to collapse
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
streambinder said:
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori | github.com
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
Click to expand...
Click to collapse
have u tried to build cwm v6 from cm9 source ??
cleverior.ipul said:
have u tried to build cwm v6 from cm9 source ??
Click to expand...
Click to collapse
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
akhbh said:
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
Click to expand...
Click to collapse
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
streambinder said:
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
Click to expand...
Click to collapse
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources coz as said earlier, his kernel is used. Well, we were working together to bring cm11 but weren't successful
akhbh said:
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources.
Click to expand...
Click to collapse
Ok, please send it to me, will compare it with my package.
streambinder said:
Ok, please send it to me, will compare it with my package.
Click to expand...
Click to collapse
Here it is:
http://www.4shared.com/zip/1nKFbOJ2ba/ccccGetux_CM11.html
streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
here the link source https://github.com/cleverior/android_kernel_samsung_cori
i've changed the board name. If your device can not boot after using the zImage from this source, then rename init.bcm21553.rc to init.gt-s5300.rc.
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
akhbh said:
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
Click to expand...
Click to collapse
Sincerely don't what are you talking about.
Anyway, have to try to understand where's the problem with the not-booting CWM.
Will try with your sources and let you know.
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?
Hi there,
I'm currently trying to build a custom kernel for my Xiaomi Redmi 4a.
As a starting point I chose following repo: Xiaomi Kernel, the branch I am using is the riva-n-oss.
I followed the tutorial from the same git repo, which worked fine, when I ignored the section about msm support.
As the phone has a Qualcomm MSM8917 Snapdragon 425 I thought I shouldn't ignore the notes about msm support.
So I downloaded the qualcomm toolchain and extracted it in my repo folder.
My problem is that I'm not even able to build (it seems to be independent of the defconfig I am using), it always crashes with the error
Code:
../include/linux/string.h:25:15: warning: incompatible redeclaration of library function 'strncpy' [-Wincompatible-library-redeclaration]
error, forbidden warning: string.h:25
You can find the whole build log here, as well as the script I use to build the kernel here.
I would be happy if you could tell me what potential problems could be!
Thanks in advance! :good:
If you need any more information, just tell me. I'm still really new to this.
(I hope this thread is not completely wrong here. I first assumed such a question shouldn't go here but instead into "ROMs, Kernels, Recoveries, & Other Development", but in the Message from Moderators it's written that no questions should go there.
I'm also not able to post there at the moment, because this is a new account.)