Related
oh my god!
http://developer.htc.com/
ps: sorry if it is already posted!
pps: it's kernel source of htc brand phone or not?
So, what now?
So what's the real benefit of that. Sorry for the noob-ish question...
nk02 said:
oh my god!
http://developer.htc.com/
ps: sorry if it is already posted!
pps: it's kernel source of htc brand phone or not?
Click to expand...
Click to collapse
WTF! Man this is fantastic, thanks!
You could always cook it your self!
This is only the binaries for the device. As cc said, the kernel you make yourself. What we need is the source for the proprietary parts to make things like bluetooth work on hero among other things
Quick, someone alert cyanogen!
*edit* **** ^
jubeh said:
This is only the binaries for the device. As cc said, the kernel you make yourself. What we need is the source for the proprietary parts to make things like bluetooth work on hero among other things
Click to expand...
Click to collapse
Damn I spoke before I checked the link. Ya it's just the plain old HTC kernel source and useless proprietary binaries. I thought it was going to be their entire source for their Android build. Crap, move along people. Nothing to see here
You can extract all of the proprietary binaries from Hero using the extract script included in dream-open when you repo sync!
shafty023 said:
Damn I spoke before I checked the link. Ya it's just the plain old HTC kernel source and useless proprietary binaries. I thought it was going to be their entire source for their Android build. Crap, move along people. Nothing to see here
Click to expand...
Click to collapse
On the contrary, it has the source for their previously-proprietary kernel bits required for the canadian dream and magic devices, which means it should now be possible to build custom kernels for those devices for true and proper root/customization without the need for the death-spl. This is something that we've been fighting them for.
Just gave the source a quick look through. All of the default kernel settings/commits you would pull down from git are absent, that is, nothing is really set. I'm gonna cook it really quick without any fussing around with it to see what happens.
Man to bad they dont have the hero source as well but thats great.
The kernel is in the oven right now. I literally only changed two things for better performance, other than that this thing is stock.
Implemented CFQ and SLUB.
lbcoder said:
On the contrary, it has the source for their previously-proprietary kernel bits required for the canadian dream and magic devices, which means it should now be possible to build custom kernels for those devices for true and proper root/customization without the need for the death-spl. This is something that we've been fighting them for.
Click to expand...
Click to collapse
As CC stated previously, these can be extracted using the htc script from those devices. I didn't see anything that we couldn't already grab (IE libhtc_ril.so)
ccyrowski said:
The kernel is in the oven right now. I literally only changed two things for better performance, other than that this thing is stock.
Implemented CFQ and SLUB.
Click to expand...
Click to collapse
Hmmm should be interesting to see what results you find.
I cooked the kernel, wlan.ko, and modules. Those are all the files you should need. I'm at work right now, but when I'm home ill throw in a ramdisk to make the boot.img.
Does anyone here know how to mkbootimg boot.img so I don't have to make a million of them for every ROM out there? Or at least I'll make one for a cupcake ROM and one for a HERO ROM
Sorry for the total noobness but does this mean we can have .odex in builds now?
shafty023 said:
As CC stated previously, these can be extracted using the htc script from those devices. I didn't see anything that we couldn't already grab (IE libhtc_ril.so)
Click to expand...
Click to collapse
You might want to read some of the retardedly long root-rogers-dream threads. There is indeed a bunch of kernel code that we can't extract/reverse engineer without a huge effort. Those files pulled by the extract scripts are NOT RELATED. The difference is in the actual kernel.
I TAKE ABSOLUTELY NO RESPONSIBILITY FOR WHAT THIS DOES TO YOU PHONE.
I HAVE NOT TESTED IT.
I WHIPED IT UP ASAP SO YALL COULD FUX WITH IT.
I imagine you'll get partially through the boot process then it will loop. The again, maybe it will work. Who knows. Please provide me with a logcat if you try this.
You cannot flash the zip file. You cannot fastboot flash the boot.img-kernel. You must mkbootimg boot.img-kernel and ramdisk.cpio.gz to make boot.img.
wlan.ko is for wifi and goes in /system/lib/modules
modules.sqf go in /system/modules
Enjoy.
http://demarcatedmedia.com/rom/stockkernel.zip
no brave souls eh?
I'd test it if I knew what you were talking about Don't have ubuntu up and running, creating a VM right now using virtualbox. I have no idea how to compile mkbootimg though.
Hi guys,
I'm trying to build a Cyanogen's kernel source (eclair branch) for JAC's xROM.
This ROM has all the bits and pieces necessary for NCommander's camera fix to work, and on my 32B Dream, the camera works just fine with the 32B rom from JAC.
However, I want to use the rom on my 32A Sapphire, so I'm building my own 32A kernel, mashing that with JAC's ramdisk, and hoping to get a working device.
Here's where I'm up to. My build environment is all set up, I've sync'ed Cyanogen's kernel sources from his GIT, and pulled a working kernel config so that I can (theoretically) compile a kernel with the same options etc.
The build works just fine, and spits out a zImage which I can (with mkbootimage) combine with a ramdisk to make a boot.img, which I can flash to my boot partition on teh Sapphire and it works just fine.
Except the camera doesn't work. The screen just goes black and nothing happens.
I found a working 2.1 AOSP kernel ported to 32A, and by coincidence, it happened to be a Cyanogen build - 2.6.29.6-cm42. Using that kernel, and JAC's ramdisk, the device boots, and the camera works. It's this kernel that I extracted the kernel config from to build my own kernel.
I figured same config, same source tree, should result in same (or similar enough) kernel so the camera would work on my build too. But it doesn't.
Does anyone have any advice on how to build Cyanogen's eclair kernel so that Ncommander's camera fix will work?
Desperately seeking advice - this is really annoying me!
reply here, twitter me, or IM me - I'm on gtalk too if you're available for a quick chat there. just let me know and i'll PM you my gtalk address.
So, 94 people have viewed this and no one has any ideas?
Come on folks. There are devs out there using Cyanogen's kernel on Eclair builds, and the camera is working. Surely someone can spare me a minute or two to offer some advice on where my kernel build might be going wrong.
If anyone has downloaded the kernel source from Cyanogen's git hub (the eclair branch, in particular) and successfully used a kernel they've build on an eclair rom with working camera, I'd be really grateful if you could share the process you've followed, just so I can work out where I've gone wrong.
This is, after all, a development forum. Surely someone knows how to do this ...
patience young skywalker
apacheo said:
So, 94 people have viewed this and no one has any ideas?
This is, after all, a development forum. Surely someone knows how to do this ...
Click to expand...
Click to collapse
Well thats been an issue for a long time now, there are peolple who know and they might have even seen this thread. Unfortunately they dont care enough to help, even if this is development. I was one of those 94 views, wish I could help. Nobody is willing to help teach people make their own software.
bubonik said:
Unfortunately they dont care enough to help, even if this is development. I was one of those 94 views, wish I could help. Nobody is willing to help teach people make their own software.
Click to expand...
Click to collapse
You know, it really does seem that way.
I've asked respected devs on twitter, and not ONE OF THEM has bothered to respond.
The only advice I've had was from bcrook88, and to his credit, he didn't have much experience in building eclair kernels. At least he took the time to have a bit of a chat to see if he could help.
That's more than anyone else has offered.
It's really sad.
Even the iPhoney community is more accepting.
apacheo said:
It's really sad.
Even the iPhoney community is more accepting.
Click to expand...
Click to collapse
Yup you'll get better help and support than in a open-source community which is terrible. Asking for things from some devs is like trying to walk on water.
I dont know but maybe this can help you:
http://forum.xda-developers.com/showthread.php?t=566235
dawg, just don't worry about it.
Asswipe44 said:
dawg, just don't worry about it.
Click to expand...
Click to collapse
Easy to say - but I want a working camera, damnit
fetch AOSP from android.git. checkout eclair. fetch vendor/htc/dream-open, vendor/htc/sapphire-open, and hardware/msm7k from ncommander's gitorious. checkout origin/eclair. copy recursive libaudio* from AOSP hardware/msm7k to the new hardware/msm7k directory, replacing what is there. your fetching ncommander's source so you have a reference point for future use.
(assuming your using an x86 host and bash/ksh)
export CCOMPILER=PATH_TO_AOSP_SOURCE/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-
fetch 2.6.29.6 'donut' kernel source.
copy your boot.img to the root of the kernel source dir.
scripts/extract-ikconfig boot.img >.config
make ARCH=arm CROSS_COMPILE=$CCOMPILER oldconfig
make clean; make ARCH=arm CROSS_COMPILE=$CCOMPILER
make ARCH=arm CROSS_COMPILE=$CCOMPILER INSTALL_MOD_PATH=./out/modules/ modules_install
(get squashfs-tools package)
cd out/modules
mksquashfs . ../modules.sqf -noappend
cd ../../
fetch this and unpack it:
http://android-dls.com/files/linux/split_bootimg.zip
./split_bootimg.pl boot.img
cp arch/arm/boot/zImage ./
(this util and more are found after you build AOSP, within out/host/linux-x86/bin)
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot-new.img
you can flash boot-new.img to boot and push modules.sqf to system/modules
your camera should work now with the hacked in drivers.
-pershoot
pershoot said:
fetch 2.6.29.6 'donut' kernel source.
...
your camera should work now with the hacked in drivers.
Click to expand...
Click to collapse
the donut branch, and not eclair? I've been trying with eclair, with no luck.
i'll try following these instructions and see how i go - i've been doing 90% of this, so i'll see how i go.
thanks so much for explaining it all. even if I have worked out most of this, seeing it black and white at least gives me a reference!
apacheo said:
the donut branch, and not eclair? I've been trying with eclair, with no luck.
i'll try following these instructions and see how i go - i've been doing 90% of this, so i'll see how i go.
thanks so much for explaining it all. even if I have worked out most of this, seeing it black and white at least gives me a reference!
Click to expand...
Click to collapse
ncommander's reverse engineered magic is based off of the donut kernel, 2.6.29.6 revision. they will not work if you use eclair (the msm_camera bits also will not build when using cm-kernel eclair branch, and need to be commented out), and or will not work out of the box with 2.6.32 (as an example).
pershoot said:
ncommander's reverse engineered magic is based off of the donut kernel, 2.6.29.6 revision.
Click to expand...
Click to collapse
well fsck.
i probably should have figured that out
my kernel's finished building now - i'll squishing up the modules etc. fingers crossed!
Alright its booted...
Here goes the Camera test...
OOO YEAH
pershoot, you rock.
Alright its booted...
Here goes the Camera test...
OOO YEAH
pershoot, you rock.
enjoy
-pershoot.
apacheo said:
the donut branch, and not eclair? I've been trying with eclair, with no luck.
i'll try following these instructions and see how i go - i've been doing 90% of this, so i'll see how i go.
thanks so much for explaining it all. even if I have worked out most of this, seeing it black and white at least gives me a reference!
Click to expand...
Click to collapse
haha yes, eclair branch still doesnt have its own camera persay
the camera we have on eclair is "hacked" like people said, from my understanding (please correct me if I am wrong) its source is mainly donut, if not all donut essentially
So after much debugging I figured this out today. And then I find this thread...
Anyways, the diff between donuts's msm_camera.c and the eclair one is quite big: some structure member names have changed, more logging, flash handling, some queuing code has changed. Still, it shouldn't be too hard to update NCommander's drivers, anyone wants to have a go? We might get official drivers soon, but having open source drivers is better.
The trouble with using a donut kernel is that the 3D Gallery doesn't work, still haven't quite figured why. Any ideas?
kapitan_petko said:
The trouble with using a donut kernel is that the 3D Gallery doesn't work, still haven't quite figured why. Any ideas?
Click to expand...
Click to collapse
Apparently the eclair kernel uses a different device for 3D acceleration (/dev/hw3dc). So it's either camera or 3D gallery...
pershoot said:
your camera should work now with the hacked in drivers.
-pershoot
Click to expand...
Click to collapse
Hey pershoot, thanks for taking the time to explain and walk through this. Very nice work, I would have been scratching my head for a very long time.
Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos). (Edit: I'm starting to consider doing things a bit differently in order to allow this to stay as a relevant reference - After all there are certain "core" features like Voodoo Lagfix/Sound that have no known detrimental effects and are basically expected from any kernel used by the community.)
One thing is that most of the other ref repos are on a github "team" account - mine is on a personal account. I'm going to look into whether I can change this without breaking the fork relationships.
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r
Initramfs from Wednesday's dump is at https://github.com/Entropy512/initramfs_sgh-i997r
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Update: Merged a pull request from LinuxBozo that has a bunch of .gitignore fixes and Makefile fixes.
Good work! Looking now.
Entropy512 said:
Inspired by supercurio creating a master git repo for SGH-I997R development, I'm in the process of uploading today's source release from Samsung of the Gingerbread kernel for the Rogers Infuse 4G. (I'm surprised none of the other kernel hackers here have already done it... )
See supercurio's post http://forum.xda-developers.com/showthread.php?t=1054738 for more info on why git is good, and superior to kernel devs using tarballs directly from Samsung. This method is already unofficially how the kernel devs have been working - nearly every kernel here is forked from gtg465x's github repo.
I don't plan on directly doing development on this repo - It's just here as a starting point for everyone else to fork from. Some of us have slow upstream, so it's easier to pull a fork than it is to push a tarball import. However I might consider pulling in basic fixes to this repo (.gitignore, Makefile fixes - basically the same things supercurio has fixed in his unified git repos)
The repo is located at https://github.com/Entropy512/linux_kernel_sgh-i997r - There is nothing visible there yet as the push is still in progress. It should be done within 30 minutes or so.
I don't have an initramfs repo yet - we need an initramfs dump from a device first.
Note: If someone creates a better "master" repo for everyone to track, I'll happily edit this post to point there.
Click to expand...
Click to collapse
Absolutely awesome news :-D
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Oh blast, hadn't even seen that kernel code was available... thanks Entropy!
A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)
Entropy512 said:
A personal favor I'd like to ask of people forking - try to keep things to one feature per commit. An example being LinuxBozo's ext4 backport to the Froyo kernels - it was simple and easy to apply to other kernels. As opposed to someone had a massive supercommit that added a whole bunch of stuff at once, making it hard to either pick-and-choose or hard to apply if they had already applied a single-feature commit for one of the features. (One example being a commit that combined something like TinyRCU, jhash3, and BFQ all in one. I don't remember exactly what it was.)
Click to expand...
Click to collapse
Defuse kernel
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
nelomen said:
Is that all we needed for gb roms or is there still more needed?
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
Click to expand...
Click to collapse
Initramfs, radio firmware dump, proper /system dump. Ours is incomplete.
Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo
Entropy512 said:
Updates:
Merged LinuxBozo's pull request with build fixes
Merged LinuxBozo's pull request with the rainbow fix
Added initramfs repo
Click to expand...
Click to collapse
Nice!! Anything buildable yet?
ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
should be buildable since initramfs is available, tomorrow gtg's voodoo commit should be available too. this is all very exciting.
ookba said:
Nice!! Anything buildable yet?
Click to expand...
Click to collapse
A few more things got pulled in last night.
Kernel - not much
Initramfs - Working CWM - or at least it comes up, it hasn't been fully tested functionally yet
As of last night a few people have custom kernels running including myself, although some people still can't boot them. CWM wasn't working until past midnight...
Next up is voodoo - Not sure if I'll include that in the main initramfs repo or not. Maybe as a branch. It is a fairly standard mod, so it should be in a readily accessible repo
Bad news - as I said before CWM hadn't been fully tested.
Apparently, after further testing, it still does indeed have some pretty severe issues.
Sadface
10c
P1 Wookie said:
Sadface
10c
Click to expand...
Click to collapse
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.
trolls suck.
GL guys.
Entropy512 said:
We have what seems to be working CWM and Voodoo thanks to gtg - in testing now.
The trolls in IRC aren't helping. Not a good time for the ops to be AFK.
Click to expand...
Click to collapse
Gotta love the trolls.
Good luck guys. I know you all will figure it out
Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.
bedwa said:
Well, thanks to the blasted trolls and the unfortunate circumstance of my only internet being my phone, I'm borked from being able to participate in the main infuse4g room as webchat is banned (for a good reason) and I can't get past the SASL issue otherwise.... oh well.
Click to expand...
Click to collapse
why no use of a client?
drowningchild said:
why no use of a client?
Click to expand...
Click to collapse
Finally got it to work, had to hack a command line client.... urg.
More information is listed at the site below
http://androidforums.com/triumph-al...-files-7-09-2012-5-30-pm-mst.html#post4641932
Just love the fact that we're basically redoing this whole phone. Lol.
Yeah I am slowly getting there with the device files. I will be updating the post each time I push back up to github and what works and doesn't.
I am stopping work on this with the gingerbread branch and now going to use the new gb-branch-7.2 branch as it was finally released on June 16th I forgot to check back.
http://www.cyanogenmod.com/category/blog
I will be updating the WX435 github during the day.
Edit: Update is done!
I believe this is the best way to go about doing this! If we can get by on base cm7 code then staying updated with the latest from cm7 shouldn't be a problem. Also it in therory should make cm9/ aokp etc easier to iron out all the bugs!
Whenever I get my laptop set back up to build, I'm going to work on picking out the best suited branch to start with from Code Aurora and try to get a vanilla froyo kernel based off the code Aurora sources working. Then from there try and apply those changes to the newer kernels off code Aurora.
It maybe a good idea to try to contact Motorola and see if they wont give us the branch and possibly even commit tag where they forked there kernel from cause I'm pretty sure they started making cchanges to a code Aurora branch on there kernel source. Just which one and where they forked it from is the question. That way we can apply the Motorola source over top that and get the exact changes moto made to the kernel!
If anyone else has anything to add to this or any insights pleas let us know!!
Sent from my Triumph using Tapatalk
Hey g60 if you cab get some logcats on some of the stuff that ain't working right ill look at em and see what I can find!
Sent from my Triumph using Tapatalk
b_randon14 said:
Hey g60 if you cab get some logcats on some of the stuff that ain't working right ill look at em and see what I can find!
Sent from my Triumph using Tapatalk
Click to expand...
Click to collapse
The stuff that is not working has not been added into the device files yet. There is a lot of missing code and lib files. Once I implement more of the changes and stuff isn't working I will holler at you, I have been really focused on fixing the video drivers. I want them playing all formats as perfect as possible before I start adding more stuff. :good:
Hey on the default.xml under the github remote you just have .. so it causes problems when trying to repo sync. Didn't know if you knew it was like that or not!
It should work fine, I just did a repo sync. Make sure you are running the right branch as CM7 changed it from "gingerbread"
repo init -u git://github.com/WX435/android.git -b gb-release-7.2
I just went back in and deleted my folder, then ran repo init again, copying directly from here and it still did the same thing when I tried to run repo sync.
Hop on IRC
b_randon14 said:
I just went back in and deleted my folder, then ran repo init again, copying directly from here and it still did the same thing when I tried to run repo sync.
Click to expand...
Click to collapse
I just looked at it myself. Under remote it shows "..", shouldn't it be git://github.com/
dsmryder said:
I just looked at it myself. Under remote it shows "..", shouldn't it be git://github.com/
Click to expand...
Click to collapse
Nope this is correct it works fine. There are changes CM Team did.
https://github.com/CyanogenMod/android/blob/gb-release-7.2/default.xml
g60madman said:
Nope this is correct it works fine. There are changes CM Team did.
https://github.com/CyanogenMod/android/blob/gb-release-7.2/default.xml
Click to expand...
Click to collapse
So with that, would you have to setup all of your own remotes?
I thought that was to have a Pre-entry for "git remote"?
If you're having issues with the .. in the manifest, see the comments on this commit from cm/android/ where this was originally introduced. The solution is in there:
https://github.com/CyanogenMod/android/commit/89acec784fd50305cc55d05ecb3416fcd7c3eb0e
Yeah i fixed mine by deleting the .repo folder, curling the latest repo into myh ~/bin folder, then pulling the repo in again.
Man I was surprised. I finally got my cm7-bROM repo setup on my new Linux mint install and finally got everything updated from upstream and added some more open commits from gerrit and built it and to my surprise, it built fine with no errors a d I flashed it and it worked great! I figured it would blow up where it had been over a month or two since I had synced and built my ROM and with all the 7.2 release stuff I thought for sure it wouldn't build and add I was building on Linux mind that I had never built on!
Hey g60 you need any help with the device files? I noticed you ain't even got the triumph device repo in the manifest anymore. If you need me to help with anything my box is up and running great! I built my rom in like 47 minutes first time and I was using ccache so hopefully the next build will be faster!
I am digging into my stock code Aurora kernel nor booting. I thought it built fine but I noticed there were some warning spit out by the linker during the build and I tried with linaro and the included 4.4.3 with aosp and it did the sane thing so I'm gonna try to get the bottom of those warnings because I think that may have something to do with it!
Ill post the pastebin of the warning up in the kernel thread later!
Sent from my Triumph using Tapatalk
No updates for a while, still nothing works?
I have been really busy and have had maybe had 1-2 hours to work on the device files in the last 6 days. I should have some more time this week so will see what I can get out.
headset does not register on boot if plugged in
Click to expand...
Click to collapse
Pretty sure this bug was in all CM7 builds before. I also experiences the same thing with MIUI rom.
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