[GPL]2.6.29.6 CFS Kernel V9 12/10/10
- Thread starter Conap
- Start date
Yeah that does look interesting...you should get right on that lol.....
Just thought I would throw this "decoder key" out here for historical purposes - the Decadenc3/Conap kernel made its way into lots of different ROMs...
...so, if you are not sure or have forgotten which kernel is in your ROM, do a "adb shell uname -a", and you should be able to match these:
BFS330: Linux version 2.6.29.6-DecaFuct-dirty-b81fce7a #12 PREEMPT Fri Sep 3 22:33:01 EDT 2010
CFSv4 : Linux version 2.6.29-DecaFuctCFS-dirty-2a66c604 #2 PREEMPT Mon Sep 6 16:49:41 EDT 2010
CFSv5 : Linux version 2.6.29-DecaFuctCFS-dirty-ea33d448 #5 PREEMPT Thu Sep 16 10:11:19 EDT 2010
BFSv6 : Linux version 2.6.29.6-DecaFuct-dirty-153d9e7a #19 PREEMPT Sun Oct 17 20:56:35 EDT 2010
CFSv6 : Linux version 2.6.29-DecaFuctCFS-dirty-cd76c7c1 #20 PREEMPT Sun Oct 17 20:58:39 EDT 2010
CFSv8 : Linux version 2.6.29-DecaFuctCFS-dirty-c6271491 #7 PREEMPT Mon Nov 8 20:13:33 EST 2010
CFSv9 : Linux version 2.6.29-DecaFuctCFS-dirty-c6271491 #2 PREEMPT Sat Dec 4 14:12:58 EST 2010
Note the similar strings for CFSv8 and CFSv9 - make sure to check the dates carefully.
...so, if you are not sure or have forgotten which kernel is in your ROM, do a "adb shell uname -a", and you should be able to match these:
BFS330: Linux version 2.6.29.6-DecaFuct-dirty-b81fce7a #12 PREEMPT Fri Sep 3 22:33:01 EDT 2010
CFSv4 : Linux version 2.6.29-DecaFuctCFS-dirty-2a66c604 #2 PREEMPT Mon Sep 6 16:49:41 EDT 2010
CFSv5 : Linux version 2.6.29-DecaFuctCFS-dirty-ea33d448 #5 PREEMPT Thu Sep 16 10:11:19 EDT 2010
BFSv6 : Linux version 2.6.29.6-DecaFuct-dirty-153d9e7a #19 PREEMPT Sun Oct 17 20:56:35 EDT 2010
CFSv6 : Linux version 2.6.29-DecaFuctCFS-dirty-cd76c7c1 #20 PREEMPT Sun Oct 17 20:58:39 EDT 2010
CFSv8 : Linux version 2.6.29-DecaFuctCFS-dirty-c6271491 #7 PREEMPT Mon Nov 8 20:13:33 EST 2010
CFSv9 : Linux version 2.6.29-DecaFuctCFS-dirty-c6271491 #2 PREEMPT Sat Dec 4 14:12:58 EST 2010
Note the similar strings for CFSv8 and CFSv9 - make sure to check the dates carefully.
Wow thanks so much i was just discussing in a pm with someone that I should have kept better track of that lmao. Now i have a reference to look at. Adding to op.
We were just talking about that, too funny. Thanks for doing that bf!
That one is still my fav... am I crazy?
Don't think that I installed them all to find that - I just did the following
Code:
hexdump -C zImage | grep '1f 8b 08' [ to find the offset of the gzip magic number ]
dd if=zImage bs=1 skip=14581 of=zImage.gz [ LOL, bs=1 :) ]
gunzip -c zImage.gz > uncompressed
strings uncompressed | grep -i 'deca.*conap'BTW, Is it reasonable to presume that when the kernel compilation dates coincide with the commit dates in your github repository, the commits from the same day made it into your build?
( LOL, decadenc3's typo in his Dec 4 commit comment gave me a scare - I think he meant "CIFS", not "CFS". )
yes the build dates do align with the commit dates in github. I always committed them before releasing the kernel.
I could probably get a 2.6.35 Droid Eris Kernel booting. It really didn't take much to port the hero cdma board files -> .35
After that though, getting everything functioning, would be all you guys
(I'd have to find time though)
After that though, getting everything functioning, would be all you guys
(I'd have to find time though)
Theoretically if you were to get that ported we could get the stock tether(wifi) working correct?I could probably get a 2.6.35 Droid Eris Kernel booting. It really didn't take much to port the hero cdma board files -> .35
After that though, getting everything functioning, would be all you guys
(I'd have to find time though)
Sent from my ERIS using XDA App
Yeah, tazz and I are both using one in our GB roms, unreleased version of Conap's CFS
Well I don't know that I would call it a GB kernel...it's the same kernel with ext4 enabled which really isn't even needed at this point for GB but may be needed in the future.Yeah, tazz and I are both using one in our GB roms, unreleased version of Conap's CFS
Hi Conap
FYI
Tonight I started looking at the differences between the new (2/23/2011) and the older (4/21/2010) 2.6.29 HTC kernel source trees for the Eris (well, there's obviously more stuff in those trees than just for the Eris, but anyway):
desirec-MR-2.6.29-bcb140a0 : Feb 23, 2011 Eris kernel Sources ("2.6.29")
desirec_2.6.29_8a03cb9a : Apr 21, 2010 Eris kernel Sources ("2.6.29")
This pastebin summarizes the file differences. (Not the content differences, just file add/drops and also which files changed between the two source trees). Other than add/drops of files, there are only 48 files shared in common between the two source releases which differ. The latter are listed at the end of that pastebin.
So, I started poking through a few differences, and also (additionally) had a few peeks at:
your kernel source repository
The Android (AOSP) 2.6.27 kernel (archive) head
The Android (AOSP) 2.6.29 kernel (archive) head
The Android (AOSP) 2.6.32 kernel (archive) head
That's when my head started to spin. Clearly HTC has some backports in their most recent "2.6.29" sources from 2.6.32 (at least) - e.g. have a look at mm/ashmem.c in their new (desirec-MR-2.6.29-bcb140a0) source release. I think that is from 2.6.32, no?
I am assuming that your repository head originated from desirec_2.6.29_8a03cb9a + zanfur's kernel patches, but by now I'm sure it has plenty of backports and other patches merged in, too.
What I'm wondering (out loud), is
(a) Is there anything useful/important in HTC's newer kernel sources? and
(b) is it a complete and utter mind-bender to propose somehow merging HTC's kernel mods into your sources? Seems like it would be a royal pain, as you would want some of your commits to be the surviving code, and some sources from the HTC code to be the surviving code. Does that mean that each separate commit would need to be reviewed one at a time?
Sorry for talking through my hat - I'm not familiar enough with git to know how much effort would be required to do something like this - or with the kernel build for that matter, to know whether any of those file differences in HTC's source trees are important to the Eris. (e.g. the wimax driver I suppose is irrelevant).
bftb0
FYI
Tonight I started looking at the differences between the new (2/23/2011) and the older (4/21/2010) 2.6.29 HTC kernel source trees for the Eris (well, there's obviously more stuff in those trees than just for the Eris, but anyway):
desirec-MR-2.6.29-bcb140a0 : Feb 23, 2011 Eris kernel Sources ("2.6.29")
desirec_2.6.29_8a03cb9a : Apr 21, 2010 Eris kernel Sources ("2.6.29")
This pastebin summarizes the file differences. (Not the content differences, just file add/drops and also which files changed between the two source trees). Other than add/drops of files, there are only 48 files shared in common between the two source releases which differ. The latter are listed at the end of that pastebin.
So, I started poking through a few differences, and also (additionally) had a few peeks at:
your kernel source repository
The Android (AOSP) 2.6.27 kernel (archive) head
The Android (AOSP) 2.6.29 kernel (archive) head
The Android (AOSP) 2.6.32 kernel (archive) head
That's when my head started to spin. Clearly HTC has some backports in their most recent "2.6.29" sources from 2.6.32 (at least) - e.g. have a look at mm/ashmem.c in their new (desirec-MR-2.6.29-bcb140a0) source release. I think that is from 2.6.32, no?
I am assuming that your repository head originated from desirec_2.6.29_8a03cb9a + zanfur's kernel patches, but by now I'm sure it has plenty of backports and other patches merged in, too.
What I'm wondering (out loud), is
(a) Is there anything useful/important in HTC's newer kernel sources? and
(b) is it a complete and utter mind-bender to propose somehow merging HTC's kernel mods into your sources? Seems like it would be a royal pain, as you would want some of your commits to be the surviving code, and some sources from the HTC code to be the surviving code. Does that mean that each separate commit would need to be reviewed one at a time?
Sorry for talking through my hat - I'm not familiar enough with git to know how much effort would be required to do something like this - or with the kernel build for that matter, to know whether any of those file differences in HTC's source trees are important to the Eris. (e.g. the wimax driver I suppose is irrelevant).
bftb0
I hadn't looked at htc's release so not really sure what's in it. Merging it would be slightly time consuming because your right I wouldn't want thier source to overwrite stuff that has been improved already. I would probably need to go line by line pretty much on each file. Thier backport code is probably from all the backports the hero dev's have done anyway lol. I suppose if I get time I could try to add it to my "when i get time" list. Or someone else could start with the new source and just pull all my commits and see what happens. Then again pulling commits from my github might overwrite good changes they have made. I'd be curious to know if anyone has reported any improvement from upgrading from the old stock kernel to the new stock kernel though.
I'll try and look at the HTC differences with a little more granularity; thanks for the response.
If that pastebin has anything in it that is useful to you, grab a copy of it - I think it is only good for 30 days.
bftb0
If that pastebin has anything in it that is useful to you, grab a copy of it - I think it is only good for 30 days.
bftb0
Links to V9 in post #1 no longer works. Does anyone have a working link to V9?
or anyone care to share the CFS kernel through a new link? I too am interested in trying this one out. CFS ive always enjoyed and have had the best battery life.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone