Database Info

Epic GB kernel sources! (11/22/11 EI22 keyfix kernel)

11/22/11 Update: Added "reboot bml8 recovery" patch for ROM Manager suppport.
11/8/11 Update: Updated keyfix kernel with the EI22 initramfs. Also, Samsung has placed the previous official (and now labeled EI22) source tarball on their opensource site.
10/24/11 Update: It appears that Samsung has removed the "official" Epic GB source tarball from their website. I've mirrored it for anyone interested in the original release. For anyone actually looking to build with the sources, you're probably better off using Rodderik's GitHub
10/19/11 Update: As everyone's found out by now, Samsung released official Epic GB sources last night. There's not that many changes to our device in the official source tree compared to the previous, but a few appear to be subtlely important (see abbreviated deltas). It still needs some work to get into a buildable state, but it does appear to work great on EH17!
I've updated most of my patches for GB, conveniently packaged together. I've also uploaded a new EH17 kernel that works on stock (rfs) EH17 ROMs and includes the keyboard fixes with optimized values, along with userdebug and kexec support. Feel free to give it a try.
Meanwhile Rodderik is updating his GitHub repo to include all these patches for folks to clone from, stay tuned.
Happy hacking!
So apparently when Samsung released the kernel sources to the Mesmerize's Gingerbread update a month-and-a-half ago, that source tree contained almost-buildable kernel sources for our device as well.
I've patched the sources (removed modemctl definition, added tfsr driver, compile right camera driver) to build for the Epic. I've also built a custom EH17 kernel combining these sources with the EH17 initramfs. It's essentially stock EH17 with ro.debugging=1, adbd always-spawning during recovery, and testkey signature verification. I'll get to porting over some other patches (like the dropped key fix) soon.
As for compatibility with EH17, the source tree itself appears to have been checked out on 8/30 and looks to include everything EH17 does. I ran "strings Image | sort -u" on both kernels to make sure there weren't any obvious strings/symbol differences between them. The ones that remain appear to be minor, but legitimate fixes.
Thanks to jt1134 & Rodderik for pointing out that the Mesmerize source released contained Epic code, and Tortel & ugothakd for testing.
GitHub repo, thanks Rodderik!
To build:
Grab SCH-I500_USCC_Opensource_Update3.zip SPH-D700_GB_Opensource.zip from opensource.samsung.com, extract.
Run "make mrproper" to get rid of atlas (Mesmerize) config junk.
Patch to complete Epic support.
Build with EH17 initramfs as usual, use victory_8G_defconfig for kernel configuration.
Mirror links:
Official GB sources: SPH-D700_GB_Opensource.zip (originally posted on opensource.samsung.com, since removed.)
Epic GB source patches: kernel-GB-3a-patches.tar.gz
Source-compiled, keyboard fix EI22 kernel: kernel-GB-3a.tar.md5
(URLs for Mesmerize tree patches removed, although they're still valid.)

Flashed this yesterday(11/13). Working good so far.
Edit: Oh, and first! Sorry iSaint
Sent from my SPH-D700 using Tapatalk

HAHAHAHA! Epic. I love you guys!

Yeah, um, I love you. <3 lol.

No. I was first. I tested it lol
[edit] actually, tortel was first. but that was before i got on board.

Hmmmm...who would of known part of our kernel source was right under our noses
Sent from my SPH-D700 using xda premium

It just occurred to me that, with this finding a lot of good can happen, as well as ICS tomorrow. Depending on timezone I should say.

Sweet. Hopefully this'll help cm7

Heart just stopped beating LOL!
What about stratosphere then?
Oh well nice work!
Sent from my SPH-D700

winning
bet samsung was just watching and waiting to see how long it took one of you/us to figure it out, lol.

this is wonderful news

Ceelos09 said:
Hmmmm...who would of known part of our kernel source was right under our noses
Click to expand...
Click to collapse
Ideally there would be one Samsung Android kernel source tree that would contain code for our device as well as all their others. However, I've been checking somewhat recently and code for Epic never appered in the GT-I9000 sources (which have been updated recently) nor in the Stratosphere ones.
It didn't occur to me to check the Mesmerize sources sooner, but as the only US device with an official GB release (still?) it shouldn't have been much of a surprise. It's also worth nothing that there appears to be GB sources for the Indulge in there as well. I'm not sure of their buildability though.

GREAT work mkasick.... everyone be SURE to thank him!

SWEET !!!

Exciting! Do the cm7 guys know about this, or is already used in the build we have?

Neckberg said:
Exciting! Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
I'm not sure, JT helped Decad3nce with CM 7 though and they both hacked the EH17 kernel to work for this. So hopefully it's something Decad3nce can use.
He said he was moving so he probably won't be back until tomorrow.

Neckberg said:
Exciting! Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
The main CM7 people are Decad3nce and jt and they haven't been on irc today.

this is exactly what we been needing...THANK YOU VERY MUCH mkasick!! You rock my friend!

Downloading now - going to see if I can compile a bootable kernel
Sent from my CyanogenMODed Epic

Neckberg said:
Do the cm7 guys know about this, or is already used in the build we have?
Click to expand...
Click to collapse
I believe JT was the one who discovered the Mesmerize sources were pertinent to us. He might've been able to compile something, but at least Rodderik was stuck on the missing tfsr driver without the right debugging bits.
I discovered this worked somewhat haphazardly when Rodderik mentioned the Mesmerize sources to me. They booted the first time with EH17 on SD, but wouldn't boot from flash. Since I was able to get it to boot off SD, debugging was a good deal easier.
In any event, it's a drop-in replacement for the current kernel used by the Epic CM7 build, so I'm sure they'll make good use of it sooner or later.
Actually what I'm curious about is if the reboot problems still persist with this. I haven't had one yet, but they haven't been a problem with stock EH17 on my device either.

[wip][aosp][port][dev] 2.6.35.7 AOSP Kernel Port [05/14/2012]

This is a development thread. If you want a conversation thread, please open one in the general forum!
I've released the source a little early of completion, so I can get others on teamacid to help out. So until we get on the android-samsung-2.6.35-gingerbread branch and changes added, tested, pushed, and tested by a more general audience, I would NOT SUGGEST FLASHING THIS. Don't expect any wiz-bang features added or anything like that. This is a port. After the port is done, we can do all sorts of stuff.
Milestones to complete:
Scrub existing code that does not relate to Galaxy S 4G (SGH-T959V/VibrantPlus) from arch/arm/...
Move architecture specific code to mach-herring.c (as it should be) and make the changes diff cleanly with the aosp samsung android-samsung-2.6.35-gingerbread branch
Scrub and import needed drivers to new android-samsung-2.6.35-galaxys4g branch with herring conversion stuff imported.
Try to get rid of dvfs stuff and move to stock cpufreq (for easier future porting to Linus's mainline, which is the goal of this kernel, amongst other modifications that will open up...)
Get all components working (wifi/bt/gps/etc. It may not be possible to use bml/fsr/rfs/ext4, because of the symbol table changing, but lets try to see if we can get it working before making the kernel compatible with cm/aosp)
investigate BML<->MTD rom conversion kernel
I have currently completed Milestone 1. I am currently running stability tests with unnamed rc2. The binary should be the same as the minimal changes to stock source to make it boot and work with a standard bml rom, but without the other board code for dempsy, kepler, vibrant, vibrantplustelus, flemming, aries ntt, and others. All code is cleaned up and specific for VibrantPlus/SGH-T959V.
I've put together a new initramfs/recovery based on v5.0.2.8 to work on BML. This does not contain the voodoo lagfix support.
You WILL have to use an updater-script that forces conversion to ext4.
GitHub:
Kernel - https://github.com/bhundven/android_kernel_samsung_galaxys4g
Initramfs - https://github.com/bhundven/android_initramfs_samsung_galaxys4g
Stay tuned... I will update with progress.

post for uploads

OP updated. Using new initramfs (gingerbread branch), some kernel and build.sh fixes.

Just a note, I've made a little progress on m2.
Looking at possibly having something releasable here in the next week or two.
I've been out of work now since may 1st and its been hard to motivate myself on anything phone related.
Much thanks to the members of teamacid and teamkickass for keeping this stuff going!
Sent from my SAMSUNG-SGH-I717 using xda premium

So these are BML kernels converted to MTD?
Sent from my SGH-T959V using XDA

smontero said:
So these are BML kernels converted to MTD?
Sent from my SGH-T959V using XDA
Click to expand...
Click to collapse
You missed the point entirely.
EDIT
Look under "Milestones to complete"

I see but I don't completely understand. I just found out the difference between BML and MTD but I was asking cause I'm using the miui MTD and i wanted to know if these kernels would work
Sent from my SGH-T959V using XDA

He hasn't posted download links to them yet.

FBis251 said:
He hasn't posted download links to them yet.
Click to expand...
Click to collapse
Right. If you know how to compile the kernel, you could. If you did, you would currently have a BML kernel. (note there is also no mtd support in the current initramfs either)
I'm not sure if Milestone 2 will be able to support RFS. I may pull in the FSR code from supercurio's repository so that we can still have BML+ext4, but that code was for a froyo kernel.
If I can't get that to work, then this kernel will be MTD only. I'm still having some problems where my current Milestone2 changes (not checked in) is not booting correctly.
As I said, I'll have an update soon.

port jelly bean

i read here:http://forum.xda-developers.com/showthread.php?t=1598713 and now i wanna try to port jelly bean,but s plus dont have same processor with nexus.need help....:laugh:

It won't work by simply porting. You need to edit boot.img. the init.rc and init.traces.rc inside boot.img need modification. also several other patches inside kernel is required. I believe that kernel 3.08 is required to port jb. the 2.6.35.14 won't do. So,first we need kernel. then someone experienced like oisis,arco,brood,etc. or,you can wait for the sources. they will be released by mid july.

Doomsday94 said:
It won't work by simply porting. You need to edit boot.img. the init.rc and init.traces.rc inside boot.img need modification. also several other patches inside kernel is required. I believe that kernel 3.08 is required to port jb. the 2.6.35.14 won't do. So,first we need kernel. then someone experienced like oisis,arco,brood,etc. or,you can wait for the sources. they will be released by mid july.
Click to expand...
Click to collapse
in weekend 3.0.8,i think will be finished.all can make this rom easy...

Doomsday94 said:
then someone experienced like oisis,arco,brood,etc. or,you can wait for the sources. they will be released by mid july.
Click to expand...
Click to collapse
Exactly. First Google needs to release the source code!
Trying to hack together some kind of SDK port now with the files from the Nexus is completely useless. Some people on XDA have tried it for other devices and it's buggy and you can't even get basic phone functionality such as calling.
EDIT: You can also read the official statement on the subject by the CyanogenMod team here: https://plus.google.com/117962666888533781522/posts/PNJutPNhixo

k....

Discussions about JB goes here... http://forum.xda-developers.com/showthread.php?t=1742827
Closing thread

defy cm10.1 alpha

this is just a demo of a kernel based on quarx 3.0.8 kernel sources,maybe later i'll try to merge several fixes or something but till then lets say i've reached a small milestone like finishing to compile this kernel,booting it up,take some screenshots from it.
known bugs,just like initial quarxs or blenchose commits.
Warning:flash at your own responsability,works only with cm 10.1 under boot options by ticking 2ndboot and ticking adb disable
link to kernel:http://www.mediafire.com/?vdjoj438tlvz2lw
NOTE:kernel sources are based on quarx repo on github:https://github.com/Quarx2k/jordan-kernel

What's this? A fix for CM10.1 23/01?

I think it's a 3.0 kernel... so not a fix.

i think , quarx2k also made many changes with his CM 10.1-3.0 branch which corresponds to the 3.0 kernel ..( eg - hwcomposer sources)
so it will be better if u can compile and upload both ROM + KERNEL package in order to have maximum working efficiency

Shubhamqweasd said:
i think , quarx2k also made many changes with his CM 10.1-3.0 branch which corresponds to the 3.0 kernel ..( eg - hwcomposer sources)
so it will be better if u can compile and upload both ROM + KERNEL package in order to have maximum working efficiency
Click to expand...
Click to collapse
you're right,because i could not boot this kernel on 4.1.2 so tried with 4.2.1 without adb manual boot,the difference is that i added forced module unloading and allow old eabi binaries to run with this kernel trying to get some backwards compatibility thus my conclusion is that either this kernel needs scratch bins in the os for propper functioning

rodrigoswz said:
What's this? A fix for CM10.1 23/01?
Click to expand...
Click to collapse
nope,my bad to mention that is an kernel build on quarx repo

You know opening a new thread was unnecessary as we already have a 3.0 kernel thread and CM10.1 also.... BTW the kernel and CM10.1 are both easily compiled if you know what you're doing
Let's Go ^_^

Kayant said:
You know opening a new thread was unnecessary as we already have a 3.0 kernel thread and CM10.1 also.... BTW the kernel and CM10.1 are both easily compiled if you know what you're doing
Let's Go ^_^
Click to expand...
Click to collapse
The thread is already reported
Sent from my MB526 using xda premium

nogoodusername said:
The thread is already reported
Sent from my MB526 using xda premium
Click to expand...
Click to collapse
thank you for your support nogood username,that helps alot and to what i can do for this comunity,for example my own kernel sources for linux kernel 3.7.5,as of this post was just an test to see if it works and 3.7.5 yup it likes the cpcap drivers and firmware,just some gpu issues to display under menuconfig

drunk_ryder24 said:
thank you for your support nogood username,that helps alot and to what i can do for this comunity,for example my own kernel sources for linux kernel 3.7.5,as of this post was just an test to see if it works and 3.7.5 yup it likes the cpcap drivers and firmware,just some gpu issues to display under menuconfig
Click to expand...
Click to collapse
I appreciate your work, and I'm not the one that reported (as far as I remember)
Sent from my MB526 using xda premium

nogoodusername said:
I appreciate your work, and I'm not the one that reported (as far as I remember)
Sent from my MB526 using xda premium
Click to expand...
Click to collapse
maybe i started wrong but my intention was to give some help for the comunity,as for my attempt on kernel 3.7.5:bump cant port sgx drivers,got cpcap to show up in menuconfig even mapphone but its like impossible to show up,tried a workaround with similar devices to get the gpu drivers but no chance

drunk_ryder24 said:
maybe i started wrong but my intention was to give some help for the comunity,as for my attempt on kernel 3.7.5:bump cant port sgx drivers,got cpcap to show up in menuconfig even mapphone but its like impossible to show up,tried a workaround with similar devices to get the gpu drivers but no chance
Click to expand...
Click to collapse
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.

Kayant said:
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.
Click to expand...
Click to collapse
thats the whole point,everithing gets trouc the cross compiler even battery and every hw aspect for defy,but cant seem to get sgx drivers on it it boots but only backlight flickers,also the importance of this is that one day we might bump in a problem like this(maybe future android versions will use kernel 3.7.5 as default)and my opinion is that we should have some widen experience about it in any way possible

Kayant said:
Thanks for your efforts I think I was the one that reported it can't remember now ..... The reason I did it was because like you said you're trying to port 3.7.5 which we already have thread for where you cab discuss about porting 3.0.0 kernels
Some advice and questions......
I was wondering why are you trying to port 3.7.5 which is not even on any other android device yet??
IMO I think a higher version of the 3.0 base kernel is not needed as am sure most of the new things in it would not benefit us as we probably couldn't use it anyway since we have old drivers, old cpu/gpu etc.....
Getting it to show up in defconfig is not the hard part you can activate anything you want from there they are just the configuring files the hard part is configuring the activated drivers for the defy which requires dev work and debugging just look Quark's commits
I think what we have is fine and I don't think anything much higher would be any benefit for us also we have older drivers and the things we need for 4.2 to work properly are in 3.0.8 like the new wifi drivers maybe Quarx will update it to a higher minor version later like he did with 2.6.32.9 to 2.6.32.60......
Don't worry yourself to much there are many other things you can do to help us in the defy community. This is not worth your time trust me from experience :cyclops:
Btw the menuconfig iust activates the stuff you want for your device and mapphone_defconfig is where all the options you picked from menuconfig is stored. Each defconfig is different as they are specify to one device.
Click to expand...
Click to collapse
and how is that a problem if someone wants to attempt a higher version kernel?
if there is no benefit then there is no loss either

I understand your point and even I know nothing is impossible.
BUT, there has to be a logic in things that you are doing, isn't it? Believe me, Nobody is discouraging him. Anyways, its a matter of understanding and not a debate.
FYI and to my knowledge, very few devices like xperia T/V has kernel 3.4

abhifx said:
and how is that a problem if someone wants to attempt a higher version kernel?
if there is no benefit then there is no loss either
Click to expand...
Click to collapse
Like brajesh.sharma87 said am not trying to discourage him anything am just giving him some advice. This is mainly just my opinion based on experiences I had trying to port the newer wifi drivers from 3.0 base to our 2.6 kernel..... he doesn't have to listen to what am saying.
Like brajesh.sharma87 said it's matter of knowledge because the Linux kernel changes so much between versions and the work Quarx has done on the 3.0.8 base may become outdated and needs to be changed to get it to work for the new base.
Am just trying to put things into prospective as I think it's not worth his time and effort trying to port a higher version kernel without good knowledge and experience on kernel porting. Again that's for him to decide.
Drunk_ryder24 if you still want to try here are is something you can do that may help -
If you haven't already tried this but try cherry-picking Quarx's commits from the p-android-omap3-3.0 branch since the code is related to the defy but keep in mind not all of Quarx's work may work on the new base.

Kayant said:
Like brajesh.sharma87 said am not trying to discourage him anything am just giving him some advice. This is mainly just my opinion based on experiences I had trying to port the newer wifi drivers from 3.0 base to our 2.6 kernel..... he doesn't have to listen to what am saying.
Like brajesh.sharma87 said it's matter of knowledge because the Linux kernel changes so much between versions and the work Quarx has done on the 3.0.8 base may become outdated and needs to be changed to get it to work for the new base.
Am just trying to put things into prospective as I think it's not worth his time and effort trying to port a higher version kernel without good knowledge and experience on kernel porting. Again that's for him to decide.
Drunk_ryder24 if you still want to try here are is something you can do that may help -
If you haven't already tried this but try cherry-picking Quarx's commits from the p-android-omap3-3.0 branch since the code is related to the defy but keep in mind not all of Quarx's work may work on the new base.
Click to expand...
Click to collapse
well ive done cherry picking from quarx repo and i must say that quarx done an excelent job compiling the modules since they are recognized and compiled by the toolchain with no major errors,just a few ignorable errors,boy quarx must have nerves of steel to bare so much time in developing from scratch,oh btw i will post this as a reply in 4.1.2 tread,ive mixed kernel zimage and ramdisk of quarx 2.6.32.60 after applying sevenrock's kernel 2.6.32.9-the whole point is that it might have been something changed in either ril or wifi module cause 2.6.32.60 seems just a little laggy but no ringtone bug or reboots by this method

drunk_ryder24 said:
well ive done cherry picking from quarx repo and i must say that quarx done an excelent job compiling the modules since they are recognized and compiled by the toolchain with no major errors,just a few ignorable errors,boy quarx must have nerves of steel to bare so much time in developing from scratch,oh btw i will post this as a reply in 4.1.2 tread,ive mixed kernel zimage and ramdisk of quarx 2.6.32.60 after applying sevenrock's kernel 2.6.32.9-the whole point is that it might have been something changed in either ril or wifi module cause 2.6.32.60 seems just a little laggy but no ringtone bug or reboots by this method
Click to expand...
Click to collapse
That sounds good am I bit surprised it worked so well with not that much errors but thats's good Yh I know Quarx is unstoppable and good luck with the project ..... If you need any more advice or help just shoot me up with a pm and I will see what I can do

kayant said:
that sounds good am i bit surprised it worked so well with not that much errors but thats's good yh i know quarx is unstoppable and good luck with the project :d..... If you need any more advice or help just shoot me up with a pm and i will see what i can do
Click to expand...
Click to collapse
thanks for your support,its wellcomed

Please advise on how to edit kernel

Hi guys
I'm really into Android 4.3.
I'm running CM10.2 (thanks Duy) and loving it.
So I want to make it work with GPS, to be able to make it a daily driver.
SGS i9000 is also working on CM10.2 with aries kernel and GPS is working there.
So I want to compare GPS threads of our and their kernel.
I understand I have to launch a Linux machine (I installed CygWin on my Win8 but couldn't find any proper documentation on what to do with it).
Please explain or direct me to how to extract our boot.img kernel so I will be able to make this comparison and maybe get it started.
Thanks.

Would love to help you, but sadly I don't know how. BUT, I will applaud your initiative. Go, go, go!!!!

Bump
sent from me

@Itzik: tbh I don't have faith for GPS on this phone lol (as for vibrant, GPS works sometimes but lame as hell afaik). Anw, for ur question , I think u should look at the source code tho, compare the two aries upstream at Cyanogen git and our phone aries kernel githubs. Then if u don't know where to start, try reviewing the commits for GPS of upstream aries for vibrant or so. But mayb it's not kernel bug tho, mayb it is device tree bug or vendor as well.
There is no way u can extract a Galaxy S (amd variants) boot.img coz of the kernel header as I read somewhere bout it.
Sent from my SGH-T959V using Tapatalk 2