[MOD][SOURCE][ED01][4.15.2011] I500/I9000 Hybrid BCM4329 Wireless Driver - Fascinate Android Development

I have no idea if this will be of any use to anyone or not, but I figured I'd share anyway. I came up with a seemingly functional replacement for the Fascinate Atlas [ED01] Broadcom BCM4329 wireless driver that is 100% certain not to have the "Hotspot Monitoring" feature, and should eliminate any issues with the /lib/modules/dhd.ko module as it's in-built as part of the kernel now.
Unlike what I did for EC10, which worked but took a lot longer to do, this is a pretty quick and easy source mod. It's stock i500 ED01 for everything but the hotspot (wlioctl.h/wl_iw.h/wl_iw.c) code, which is stock i9000-update2, sans a certain "roaming" feature. The end result seems to work. Support for the actual VZW 3G hotspot app is all but guaranteed to be dead and buried, but the latest android-wifi-tether 3.0pre12 in infrastructure mode worked great, so I think it's pretty close to good, if not actually there.
Application:
- Remove the insmod lib/module/hotspot_event_monitoring.ko from init.rc
- Remove the hotspot_event_monitor.ko from lib/modules in your INITRAMFS
- Remove the dhd.ko from lib/modules in your INITRAMFS
- In your xxxxx_defconfig, remove (or comment out) CONFIG_BROADCOM_WIFI_ATLAS=y and make sure CONFIG_BROADCOM_WIFI is set to "m"
- Replace drivers/net/wireless/Makefile and drivers/net/wireless/bcm4329 with the contents of the linked .TAR below
- This should generate a dhd.ko instead of hotspot_event_monitoring.ko in drivers/net/wireless/bcm4329. Put that in your INITRAMFS::lib/modules instead of whatever stock dhd.ko you have. [Having the dhd.ko to include with a build is quite nice compared with using some stock driver IMO]
- Let me know if it doesn't work ... and what you tried ... I can always go ahead and do another manual merge like I did for EC10
edit: You'll also want to strip the debug symbols from the dhd.ko that's generated, it's huge. I've been doing a make modules then copying out/stripping the .ko files for initramfs before finisihing with the regular make.
MOD Source Download (.TAR)
Link to my GitHub commit for this particular change (don't trust my GIT, look at jt1134's or imnuts' GIT for things that matter!)
Anyway, if this helps you out, awesome. If you apply it and your WiFi gets boned up, please let me know and I will try to recreate. If you apply it and your phone catches on fire and dies a slow and painfull death I have no idea who you are or what you're talking about

Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats

Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.

nemesis2all said:
Cannot seem to get this working for me.
make: Warning: File `drivers/net/wireless/bcm4329/Kconfig' has modification time 1.8e+04 s in the future
error repeats
Click to expand...
Click to collapse
I'd guess that whatever you extracted the archive with, also updated the files with what their modification time when they were archived. 1.8e+04 seems to be 5 hours, so it's likely due to you and djb having different timezones (or, one of you not knowing how to set your clock with NTP ).
Whatever you used should have an option to not preserve the timestamps, so you could just redo with that option... alternatively, you could wait 5 hours.
Syn Ack said:
Didn't Adryn or someone else fabricate a fake version of the 3G Hotspot event monitoring file that basically is still there but doesn't actually monitor our hotspot or tethering usage?
I've been using that and been wireless tethering using that recent app in the Themes section. Hopefully im pretty safe because ive been using that app a decent bit and its been working perfect.
Click to expand...
Click to collapse
He did, so you can be 'safe', but you still got parts of that monster in the wireless driver's code & the dummy monitor as well (no doubt that samsung's modifications to the wireless driver are quite low quality, like everything else they seem to do in the kernel).
I'm not sure what app you're using, but, using Wireless Tether or anything else not from Verizon should be safer (not to imply that using the 3G Hot Spot with the monitor removed is dangerous- but from what I've heard, take with a grain of salt, doing the hack to get free tethering with the verizon app puts some possible traces on your account that might suggest you're doing it).

I use a combo of that dummy monitor and the Wireless Tether app.

is this a full kernels or just a mod for which ever kernel you are using

evilclosetmonkeynate said:
is this a full kernels or just a mod for which ever kernel you are using
Click to expand...
Click to collapse
This is a mod for kernel developers.

Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone

djp952 said:
Yeah, just a modification to the existing code base for developers. Looking at everyone else's stuff it seemed that the norm was to remove the nasty bits from the existing driver. I tried using the i9000 wireless driver as-is and it worked fine, so my concept was just to replace the access point stuff completely but keep any changes made to the core driver code.
Sorry about the timestamp thing nemesis! My Linux experience is extremely limited (you should see me struggle with Git, it's almost laughable the bad things I've done to myself)
While I am "working on" a full kernel, it's primarily just for my own education. If I want to be able to contribute to these efforts I have a LOT of catching up to do. My personal goal is a "Stock+" kernel that works but doesn't include all the little tweaks and modifications available from the main developer's kernels. I'll put it this way -- at the end of the day I flash somebody else's kernel back onto my phone
Click to expand...
Click to collapse
It is all good still appreciate your work. I have never seen anything like that. Just thought it included some bits needed for my DeLorean to go back to the future.

so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?

Thank you for your hard work hope to see this in future Kernels
Sent from my SCH-I500 using XDA App

godihatework said:
so, i am just speculating here, but does this imply that bluetooth (and other) drivers could be pulled from i9000 sources as well (say that GB drop that just hit) and backported to i500 kernels?
or is this simply wishful thinking?
Click to expand...
Click to collapse
Anything is possible, as long as the hardware is actually the same (or close enough) on the i9000 and it doesn't need anything unique to the GB kernel. It certainly won't hurt to diff the code when it's available to see how close it is.

Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.

nemesis2all said:
Have you been doing any more testing on this. I am interested in putting it in my kernels just want to make sure it won't cause any issues.
Click to expand...
Click to collapse
Yes, as of android-wireless-tether 3.0pre14 I haven't had any issues at all with it. 3.0pre12 was throwing a fit every now and again, but apparently that was a common malady with that version. Note also that I have NOT tested the Verizon 3G hotspot app with this driver, my assumption is that it will not work. Which leads me to ...
I also have a less aggressive solution that may allow the VZW app to work you could have if you want, it's basically the same thing with the updated SOFTAP changes from the i500 applied to the i9000 driver as well. (This basically makes it amount to just carving out the hotspot and producing a new dhd.ko during a build so we don't have to use the pre-compiled one from the ramdisk)
You can find the alternate version of the driver on my github, in the src/wip directory of the sch-i500-kernel repo:
https://github.com/djp952/sch-i500-kernel.git
LMK if you run into problems

Related

camera flash on low battery mod

is there a way to mod the camera flash so it lets me use it even if the battery is really really low...I want to set the threshhold at 0 percent...sometimes...I just need to take a pic...and 20 percent is more than enough for one quick flash for a pic.
seansk said:
is there a way to mod the camera flash so it lets me use it even if the battery is really really low...I want to set the threshhold at 0 percent...sometimes...I just need to take a pic...and 20 percent is more than enough for one quick flash for a pic.
Click to expand...
Click to collapse
anyone? please???
seansk said:
anyone? please???
Click to expand...
Click to collapse
When does it prevent you from using the flash? I've used mine at less than 20% but have had wifi, gps and data connection turned off. I wonder if unchecking the power saver and efficiency boxes would help?
EDIT: Okay, I see what you mean. I finally got it to say the flash couldn't be used because the battery level is too low. I turned off power saving and it still didn't work. I tried ProCapture which I like a lot because it doesn't compress the images thus better quality. It has a "torch" option on its flash menu so I tried that. The flash stays on continuously in that mode, even with a low battery. I took a shot in total darkness and it didn't seem to work. the flash was on but no picture? Maybe with some light it would work? ProCapture is free to try so you might want to try it to see if that would work under normal night conditions. I guess it won't work in total darkness like the auto flash will.
Another edit: I noticed that the flash was disabled right at 15% so I did some searching and found this: With root explorer (or any rooted file explorer), go to sys/camera_led_status/low_cap_limit. There you will find the number 15 for 15%. I tried to change this to 5 but the file is locked and I don't know enough to unlock it, rename it and then change it through adb. I think I read that you can't do this through root explorer. Maybe someone with knowledge of how to do this will know how to do it. I'm sure it is relatively simple and a zip file could even be written to change it. At least we now know where the setting is!
frodoboy said:
When does it prevent you from using the flash? I've used mine at less than 20% but have had wifi, gps and data connection turned off. I wonder if unchecking the power saver and efficiency boxes would help?
EDIT: Okay, I see what you mean. I finally got it to say the flash couldn't be used because the battery level is too low. I turned off power saving and it still didn't work. I tried ProCapture which I like a lot because it doesn't compress the images thus better quality. It has a "torch" option on its flash menu so I tried that. The flash stays on continuously in that mode, even with a low battery. I took a shot in total darkness and it didn't seem to work. the flash was on but no picture? Maybe with some light it would work? ProCapture is free to try so you might want to try it to see if that would work under normal night conditions. I guess it won't work in total darkness like the auto flash will.
Another edit: I noticed that the flash was disabled right at 15% so I did some searching and found this: With root explorer (or any rooted file explorer), go to sys/camera_led_status/low_cap_limit. There you will find the number 15 for 15%. I tried to change this to 5 but the file is locked and I don't know enough to unlock it, rename it and then change it through adb. I think I read that you can't do this through root explorer. Maybe someone with knowledge of how to do this will know how to do it. I'm sure it is relatively simple and a zip file could even be written to change it. At least we now know where the setting is!
Click to expand...
Click to collapse
Yes thats exactly what I did in root explorer in sys/camera_led_status/low_cap_limit, I set it to 5, 1, 0, did not make any difference. Also Its retarded that you cannot use flash while you're in a call....if you talking to someone and trying to take a picture it says you cannot use flash since you're in a call....wtf does that have to do with the flash!!! There should be a file somewhere in the sense UI system to change these settings, If anyone has found anything please share...or if you can think of something please share as well...
I actually like the dialer and contact aspect of sense UI and how it integerates and automatically finds linked friends, how it updates friends status in facebook and twitter, (although they still need to integrate google plus)...all the other stuff of sense I do not like...I've changed to ADW ex...and widget locker...
I doubt there's a way to get that stuff with a senseless rom since its so integerated into the system...If there is I would flash another rom in a sec and just install that aspect of sense....
so apparently I can't use flash under 20% battery...under a certain temperature and when I'm in a call...So basically don't use flash....lol....I messed around with files under sys/camera_led_status which I believe controls temperature and battery limitations and also /sys/android_camera_awb_cal which I believe limits flash while you're in a call...I backed up deleted the directories and rebooted but they came right back...is this part of the kernel...I believe this requires S-off because I am unable to change this part of the system...or perhaps someone can do a quick kernel mod and take off all those limitations...
I got a better one for you.
Turn on the wireless access point feature, activate the camera and try to use the flash.
Binary100100 said:
I got a better one for you.
Turn on the wireless access point feature, activate the camera and try to use the flash.
Click to expand...
Click to collapse
you gotta be kidding me!!!!
question 1. Are the other roms the same?? I"m unlocked and rooted but on stock rom. do senceless, beastmod or revolution have the same problem...I'm guessing they would since they use the same camera apk...or maybe not, If not i'm flashing to something else RIGHT NOW.
questions 2. are we ever going to see CM9 on the amaze....screw sense I want ICS AOSP asap...
seansk said:
so apparently I can't use flash under 20% battery...under a certain temperature and when I'm in a call...So basically don't use flash....lol....I messed around with files under sys/camera_led_status which I believe controls temperature and battery limitations and also /sys/android_camera_awb_cal which I believe limits flash while you're in a call...I backed up deleted the directories and rebooted but they came right back...is this part of the kernel...I believe this requires S-off because I am unable to change this part of the system...or perhaps someone can do a quick kernel mod and take off all those limitations...
Click to expand...
Click to collapse
As I understand it, you tried to change the value to 0, 1, 5 and it still didn't work. If you looked at the file, it was still set to 15 right? I think you have to unmount the system, then pull it from your phone to your computer, alter the file and then push it back to the phone and remount the system. I have no idea how to do that. Binary is pretty good at writing little zips to do that sort of thing. I don't know if permanently changing that value will do anything though. I do know that root explorer says it changes the file but it doesn't.
frodoboy said:
As I understand it, you tried to change the value to 0, 1, 5 and it still didn't work. If you looked at the file, it was still set to 15 right? I think you have to unmount the system, then pull it from your phone to your computer, alter the file and then push it back to the phone and remount the system. I have no idea how to do that. Binary is pretty good at writing little zips to do that sort of thing. I don't know if permanently changing that value will do anything though. I do know that root explorer says it changes the file but it doesn't.
Click to expand...
Click to collapse
I tried changing this by root explorer as well. The directory already says that it's R/W so I tried changing these values. As a result I was unable to force the changes either. I'm curious if something else changes the values back. Perhaps the camera app itself? I have no idea why the directory is set to r/w. However if you check any custom rom you will not see a /sys directory in there which makes me believe that it is in fact kernel related. That being said you would have to decompile the kernel itself, edit those values and reflash the kernel again. I might be able to do this for you however since everyone seems to have a different kernel and suffer from ORD (obsessive rom flashing disorder) I would find the work as pointless. My suggestion is to request it from your favorite developer for future kernels.
Binary100100 said:
I tried changing this by root explorer as well. The directory already says that it's R/W so I tried changing these values. As a result I was unable to force the changes either. I'm curious if something else changes the values back. Perhaps the camera app itself? I have no idea why the directory is set to r/w. However if you check any custom rom you will not see a /sys directory in there which makes me believe that it is in fact kernel related. That being said you would have to decompile the kernel itself, edit those values and reflash the kernel again. I might be able to do this for you however since everyone seems to have a different kernel and suffer from ORD (obsessive rom flashing disorder) I would find the work as pointless. My suggestion is to request it from your favorite developer for future kernels.
Click to expand...
Click to collapse
crap I wish I was a developer!!! instead I had to go and fix teeth and become a dentist!!! but I'm very much into electronics. Is there a book I can read to start developing?
btw where do I post the request? in development or general?
seansk said:
crap I wish I was a developer!!! instead I had to go and fix teeth and become a dentist!!! but I'm very much into electronics. Is there a book I can read to start developing?
btw where do I post the request? in development or general?
Click to expand...
Click to collapse
I would suggest in the forum that consists of the kernel that you are using.
Example:
If you have QuikSense then post the request in the QuikSense forum or PM the developer (in this case xboarder56) directly.
If you use Faux's kernel then post it in that thread.
No need to start a new thread for a request. However if you feel that it is absolutely necessary do it in General because the Development section is not really a section mod requests.
Binary100100 said:
I tried changing this by root explorer as well. The directory already says that it's R/W so I tried changing these values. As a result I was unable to force the changes either. I'm curious if something else changes the values back. Perhaps the camera app itself? I have no idea why the directory is set to r/w. However if you check any custom rom you will not see a /sys directory in there which makes me believe that it is in fact kernel related. That being said you would have to decompile the kernel itself, edit those values and reflash the kernel again. I might be able to do this for you however since everyone seems to have a different kernel and suffer from ORD (obsessive rom flashing disorder) I would find the work as pointless. My suggestion is to request it from your favorite developer for future kernels.
Click to expand...
Click to collapse
Thanks Binary. You are sooooo smart!!
Flash limitation is controlled by kernel... Not sure why HTC decided to do that, but I can easily change this value in my next release from 20% to 10% or 5%.....
Of course if you decide to use the stock kernel, there's nothing much you can do about it... It is hardcoded in the kernel code.
Happy New Year!
faux123 said:
Flash limitation is controlled by kernel... Not sure why HTC decided to do that, but I can easily change this value in my next release from 20% to 10% or 5%.....
Of course if you decide to use the stock kernel, there's nothing much you can do about it... It is hardcoded in the kernel code.
Happy New Year!
Click to expand...
Click to collapse
Thanks
I think 5 percent is reasonable...also can you change the limitations for temperatureand also take off limitations when making a call and using wifi hotspot...the phone does not allow to take flash while its in low temp, when making a call or when using wifi tethering/hotspot.....thanks faux
seansk said:
Thanks
I think 5 percent is reasonable...also can you change the limitations for temperatureand also take off limitations when making a call and using wifi hotspot...the phone does not allow to take flash while its in low temp, when making a call or when using wifi tethering/hotspot.....thanks faux
Click to expand...
Click to collapse
Yeah that's HTC for you. Always thinking ahead. You never know when your phone might be damaged by taking a picture with the flash activated while using it as a hotspot. In regards to the cold... I live in Detroit, work at night and I've used it a couple of times without issue. How cold does it have to be? I kinda wanna see this! LOL! It's gotten down to about 19F here... can't remember if I had used the camera though.
But I can understand why you wouldn't want to use the flash in cold weather. Might cause an avalanche or wake a bear or something. Yikes! Smart thinking HTC!
Binary100100 said:
Yeah that's HTC for you. Always thinking ahead. You never know when your phone might be damaged by taking a picture with the flash activated while using it as a hotspot. In regards to the cold... I live in Detroit, work at night and I've used it a couple of times without issue. How cold does it have to be? I kinda wanna see this! LOL! It's gotten down to about 19F here... can't remember if I had used the camera though.
But I can understand why you wouldn't want to use the flash in cold weather. Might cause an avalanche or wake a bear or something. Yikes! Smart thinking HTC!
Click to expand...
Click to collapse
lmao....it bothers me that I'm talking to my gf and she wants a picture of something i have to hang up take the picture send then call back wtf!!!!! and don't even get me started on wifi hotspot...how does this make sense????????????????? sense ui should be called retarded ui cause it does not make "sense" no pun intended.
seansk said:
lmao....it bothers me that I'm talking to my gf and she wants a picture of something i have to hang up take the picture send then call back wtf!!!!! and don't even get me started on wifi hotspot...how does this make sense????????????????? sense ui should be called retarded ui cause it does not make "sense" no pun intended.
Click to expand...
Click to collapse
To HTC or to whomever it may concern,
I intend to propose a class action lawsuit pending on verification of an intentional design flaw that prevents the consumer to use the flash on the device while talking on the phone while also using the device as a wifi hotspot in subzero degree weather. I discovered this flaw while taking pictures of Bigfoot eating Santa's raindeer at the North pole just after Christmas. Unfortunately I was unable to take proof of evidence of the situation because of the mentioned designed flaw. While I was on the phone with animal control they demanded photographic evidence of the situation. Because I was not able to comply due to this design flaw the raindeer could not be saved thus there will be no more Christmas. Evidence of the intention for the mentioned limitations is the simple fact that the appropriate error messages are programed into the kernel source. However because you fail to include the wireless drivers, the kernel source cannot be utilized to compile a patch for this flaw.
Shame on you HTC.
I should be a prosecutor.
Binary100100 said:
To HTC or to whomever it may concern,
I intend to propose a class action lawsuit pending on verification of an intentional design flaw that prevents the consumer to use the flash on the device while talking on the phone while also using the device as a wifi hotspot in subzero degree weather. I discovered this flaw while taking pictures of Bigfoot eating Santa's raindeer at the North pole just after Christmas. Unfortunately I was unable to take proof of evidence of the situation because of the mentioned designed flaw. While I was on the phone with animal control they demanded photographic evidence of the situation. Because I was not able to comply due to this design flaw the raindeer could not be saved thus there will be no more Christmas. Evidence of the intention for the mentioned limitations is the simple fact that the appropriate error messages are programed into the kernel source. However because you fail to include the wireless drivers, the kernel source cannot be utilized to compile a patch for this flaw.
Shame on you HTC.
I should be a prosecutor.
Click to expand...
Click to collapse
omg rotflmao........so basically we really can't fix the hotspot issue or the call issue!!....I'm beginning to not like HTC...and I definitely don't like sgs2...I better start designing my own phone....the N1 never had this kind of BS problems....I used it as hotspot...called...took pictures alll the way down to 0 battery and it was made by HTC...what changed??? I still like my N1 better lol...hopefully next year we'll get
new years resolution dream phone:
720p super amoled PLUS "not pentile" screen
8 or more Mega pixel back side illuminated sensor with a f/2.2 or less and a wide lense camera lense with good optics and good audio quality while recording video.
able to use flash without limitations!!!!!!!!!!!!!!!!!!!!!!!!!
no flash bleed into camera sensor that requires 3 rounds of electrical tape
No screen bleed from the soft buttons
10 hour talk talk battery preferably over 2200 mAMp battery
STOCK ICS with custom amazing camera software like that amaze has now.
NO CARRIER BRANDING NO BLOATWARE. is this so much to ask
a phone that can drill and fill my patients teeth, do root canals and make crowns for them...ok maybe this last one is asking too much.
is this so much to ask???
seansk said:
...is this so much to ask
a phone that can drill and fill my patients teeth, do root canals and make crowns for them... is this so much to ask???
Click to expand...
Click to collapse
Ummm... yes. I believe the best you can do is create a phone with a jackhammer for a vibration mode, shove it in the patients mount and keep calling it. But of course some other people would use it for... inappropriate purposes.
Example from one of SassyBoB's reviews: https://market.android.com/details?...t=W251bGwsMSwyLDEsImNlbml4LmFuZHJvaWQudmJyIl0.

[KERNEL] XPLOD 3.0.24 opensource kernel

Hi there,
This is a development thread.
Don't ask for ETAs. Don't ask what's working. Don't ask how to use.
It is not yet in an usable state.​
INFORMATION
Click to expand...
Click to collapse
This is an attempt to make a homemade 3.x kernel for our beloved Galaxy S II. I'm targetting the GT-I9100 only for now, if you wish to get it running on other variants (I9100G for instance), feel free to port it to your device and do a pull request.
I started it off Origenboard 3.0.4 kernel patched to 3.0.24, so that we get the most up-to-date opensource drivers, removing the need of porting Samsung drivers from 2.6 (gingerbread) kernel.
We'll be able to merge proprietary stuff from Samsung when they release it (audio and modem mainly), but thanks to what we'll already have we'll have a proper 3.x kernel without any Samsung crap (such as their MTP implementation that is borked it seems).
GIT REPOSITORY
Click to expand...
Click to collapse
http://github.com/xplodwild/android_kernel_samsung_galaxys2
WHAT'S WORKING
Click to expand...
Click to collapse
Keys GPIOs
Regulator and battery (it loads well but Android doesn't show it's charging)
Screen/framebuffer
Touchscreen
MFC (untested but should work from Origen)
RTC Clock
Touchkeys
MAJOR ISSUES
Click to expand...
Click to collapse
Phone never wakes from deep sleep (<== We definitely need experts on this one)
ADB works only after unplugging and replugging USB cable (issue almost located)
HOW TO HELP
Click to expand...
Click to collapse
Well, start forking, do stuff and make pull requests so I merge it and everyone enjoys. I'd need some help for the major issues above (especially the deepsleep issue).
If you're not a developer, well, buy me a coffee, there's a donation button on the left of this post
I'll keep you informed when it'll be ready for "public" use.
Phone never wakes from deep sleep
cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Entropy512 said:
[*]Phone never wakes from deep sleep
[*] cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I was just thinking that Iirc it puts the device into 800 when waking, or something like that...
Entropy512 said:
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I had the same issue when I haven't enabled the governors, so the CPU was stuck at 1200MHz but won't wake up either from a deep sleep.
I'll have a try with the voltage, but my guess is more that there's some steps missing (the default 2.6 kernel seems to have a "low power mode" in which the board gets before waking up, if I understood it correctly).
At the same time, I'm giving a try with the 3.3 branch at Linaro (check android-3.3 branch at my github). It's harder than 3.0 because there's no more s3c framebuffer, it seems to go directly to FIMD, and the LCD panel has to be setup through SPI.
Some update:
- Touchkeys, clock and various things added/fixed
- Patched to 3.0.24
Edit:
- Added sdcard mounting
Cool stuff should come very quickly
Good work...
---deleted some post----
Sorry u can delete this post as it making thread very ugly..
_____________________
Sent From My Phone
just buy u a expensive coffee! Work hard!
Yeah do you smell sources?
Sent from my GT-I9100 using XDA
boba23 said:
Does this mean you are smelling Samsung source code somewhere? ;-)
boba
Click to expand...
Click to collapse
We'll do our best without them.
True enough.
This kernel is the most exciting thing I'm watching lately.
Really excited about the outcome. Samsung Kernel is just not the way to go if you get an alternative like this, which is far more promising.
Here comes your coffee:
33P346290U8160844
Keep it up!
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
sam razzy said:
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
he already know it...pretty sure xplod and codeworkx will bring some state of art kernel to us
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Isn't 3.3 bleeding edge?
Sent from my GT-I9100 using XDA
awesome, man
despite not owning a sgs2 I like your work! Samsung should definitely review their way of development, way cook your. own soup, when it. Is. already done by someone else
they should just stay compatible and release the damn hardware drivers ;-)
Sent from my Nexus S using XDA Premium HD app
XpLoDWilD said:
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Click to expand...
Click to collapse
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase? https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Entropy512 said:
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
Click to expand...
Click to collapse
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Entropy512 said:
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase?
Click to expand...
Click to collapse
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Entropy512 said:
https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Click to expand...
Click to collapse
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
XpLoDWilD said:
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Click to expand...
Click to collapse
Makes sense, although unfortunately, some things are clearly backports of newer code, see below.
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Click to expand...
Click to collapse
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
Click to expand...
Click to collapse
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Entropy512 said:
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
Click to expand...
Click to collapse
My bad, after checking it must be codeworkx that merged it wrong (he put samsung on top of "stock" 3.0.15 to check the differences), I guess files weren't deleted.
Entropy512 said:
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Click to expand...
Click to collapse
I'm not talking specifically about mach-exynos implementation, but more all the other things that got touched around it.
Entropy512 said:
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Click to expand...
Click to collapse
If copyright header is right, Samsung's one is 2009-2010 whereas 3.3 is from 2011. One example is that the Samsung driver uses mutexes and locks, which are not needed anymore and are not present anymore in mainline. This causes deadlocks everywhere when trying to use them in a "clean" kernel.

ICS DEVS UPDATE THREAD ONLY

All ICS kernel updates can go here. This is for Entropy, LipShitz, Task and any other who is actually working on the ICS kernel.
If you post here, it will be deleted on the spot so just fair warning...
First!
These are always my latest *unsupported* builds:
i9100 Touchwiz Based Roms: http://www.cheatersedge.org/android/i777/TWzImage.tar
AOSP Based Roms: http://www.cheatersedge.org/android/i777/AOKPzImage.tar
Red5 said:
If you post here, it will be deleted on the spot so just fair warning...
Click to expand...
Click to collapse
Come at me bro!
j/k..
Seriously guys.. No fooling around!
Fenny maybe I missed it but do you have a thread to discuss this tw kernel. So far so good. I had already converted OmegaRom 5.1 with everything and was just waiting on a kernel. So far so good. I am gonna look through my notes on how/where to fix the home haptic feedback but other than that all 4 buttons seem to working perfectly. I have sent a pm to the des of OmegaRom to see if they wanted it ported (help porting it to our phones) but i have heard back from them so far. Will continue playing with it with your kernel and test it out. I have run the OmegaRom for about three days already and have had any issues so testing with your kernel is now upon me. Thanks for your work on this. Rich
Fixed: All keys and home haptic working now, though home haptic seems lighter than the other keys.
Sent from my SGH-I777 using xda premium
Until things are cleaned up better, there aren't going to be threads. There's enough to be done and enough things are still not working right that new threads aren't justified yet.
https://github.com/Entropy512/initramfs_galaxys2_ics
https://github.com/Entropy512/kernel_galaxys2_ics
used to build the attached zImage. If you don't know what to do with a raw zImage, this isn't ready for you yet. Simple as that - there is a lot of things missing (like, don't set any profiles in SetCPU with reduced clock frequencies, bad things will happen) - I still haven't tested flashing zips in CWM. nandroid backup/restore seems to work but no guarantees.
You still need to disable Samsung Noise Reduction or use a hacked Phone.apk along with a hacked /system/usr/keylayout/sec_touchkey.kl (see Hellraiser on github) for it to work in a reasonable way. There's probably a large pile of **** still broken. Don't pester me with bug reports - there's a pile of stuff I KNOW I still need to address.
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Entropy, not stating a fact and you KNOW a heck a lot more than I so take this with a grain of salt. I have been playing with lots of different files on a ported/converted i9100 ICS Rom (Omega Rom 5.1) and used these for the usr files and have seen the screen wake issue. http://db.tt/DUe4afdh Maybe it has nothing to do with these though. I have changed many other things like csc folder, csc other files, many other things also. Also I am using the kernel posted by Fenny if that matters or is much different than yours a I have tested it out yet. I only replied here because one of the files I removed was the gpio file completely as other files inside seemed to have the same configurations. Maybe I am WAY off base here. If you want to try the Rom i converted already to see if anything helps let me know and I will send a link to you. Thanks for all your hard work.
Sent From My KickAss ATT SGS2 SPORTING my CobraRom
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Better off doing how its being done... if use another developers ... you just mirror same issues...if build yourself you know whats what.
Tap-Tap Talking
Entropy512 said:
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Click to expand...
Click to collapse
Isn't 4.0 a total new build from Sammy? Honestly.... from what I'm looking at...I don't see ginger GPIO being compatible..but should be if all they used was duct-tape and staples to parse another kernal together.I'm buying a laptop. You guys use sdk? Entropy..what program are you using for kernal popping? Give me area you want help....will do
Tap-Tap Talking
LipShitz said:
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
Click to expand...
Click to collapse
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Entropy512 said:
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Click to expand...
Click to collapse
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Fenny said:
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Click to expand...
Click to collapse
Ill make sure it stays at the top.
LipShitz said:
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Click to expand...
Click to collapse
I'll catch up on your PMs soon.
I think I've found the screen wake bug: I misread the #ifdefs in the Gingerbread kernel, and realized they unmap the HOME key GPIO.
There was no such unmapping in the ICS kernel - so the GPIO was left mapped to HOME but left floating, which explains both random wakes and spurious HOME presses. It's also why the patch I posted this morning caused guaranteed screen wakes on resume - GPX3(5) is the HOME GPIO and was set to pulldown by that patch - it's an active-low GPIO.
Attached is a test kernel zImage and two patches - if these solve screen wake for those experiencing it, I'll push the patches to github and probably release the first Daily Driver ICS tonight even though I still haven't fixed SetCPU hangs.
This kernel is for Touchwizz firmwares only - if it solves the problem for everyone I'll work with the CM9 maintainers on integrating the attached patches, which apply to the current state of my github repo.
Let me know when you get to test point. Shoot it over if you want.
I have started writing a new program that will enable you to do parcing of 2 total diff Kernals,full factory and custom ROMs., yank out APK's and cook me dinner. What It will prob be 2gig in size..will streamline it. But when done--- WE WILL RULE THE WORLD!.. yea ok.
Tap-Tap Talking
Here is a kernel I compiled to work with MIUIv4 for this weeks update 2.3.23:
http://www.mediafire.com/?5bm1l4t1bmbd8bm
All good... little laggy(prob CPU hang) 200-1200 CPU set? No wake issue yet. I'm on 1.5 hours.
Tap-Tap Talking
I restarted phone and stuck on startup logo(samsung bla bla bla) i need to hook it up to laptop and flash it. Will not go into cwm with power and both volume. Im on my infuse.
Sent from my SAMSUNG-SGH-I997 using Tapatalk
Sorry Double Post

[Q] What ROM?

Hi all,
So, I took the leap of rooting my HOX+ (international) about 2 months ago, and the ROM of choice was CM.
I loved it! Love everything about it. At the time, the "stable" channel hadn't been opened, so I was using the version in nightly - it's been moved to stable now - 10.1.
Since I was attached to the stable repo, Goo Manager notified me when 10.2 moved into nightly. After a couple of days of having it stick in my status bar, nagging for an update, I just clicked and let it do its thing.
Unfortunately, this broke my phone . I got an error something along the lines of "the process com.android.phone has stopped". When I tapped "okay" the notification would re-appear after <1 second. I've since found out via Google this is something to do with my kernel (why the auto-update didn't update the kernel too is beyond me =s ) - but at the time, I just wanted a functioning phone with minimal fuss, and thought it'd be best moving myself to stable anyway. This is what I did.
That was Tuesday of this week. Between then and now, the "signal"/reception on the phone (I use Vodafone, so coverage isn't spectacular anyway) has been awful - calls randomly dropping, and it just being unreliable and generally a pain. This is despite it being the supposedly "stable" channel, and the version being the same as the one I installed from nightly (previously). Maturing seemed to make the ROM more buggy, not less!
In the interests of having a working phone, I decided to leave CM. Atm, I'm going to try out an AOKP build - though officially unofficial, I'm hoping that minimalistic => less things to break. We'll see how it goes.
I've run various Google searches and the HOX+ finally seems to be getting (after nearly a year) a good developer community - with Lloir at the forefront of it, and Maxwen's blade kernel. Could anyone recommend a flexible, good looking, regularly updated ROM? I'm not a Sense fan (not long before rooting, Sense 5 came out, and it was "the straw that broke the camel's back" so to speak), but otherwise...I'm not really sure what I'm looking for. GPL would be good, and I'm a fan of minimalism (having as little clutter in the way of unused apps as possible). An active and engaged developer/dev community is a must - I don't want to install software that will become obsolete within a week, and have no prospect of a new release. Other than that, I'm more or less happy to try everything/anything!
Cheers,
AA.
PS - I should probably mention, although I'm in no way a dev, I am quite comfortable with tech, and don't mind spending a bit of time researching things to get stuff working. I'm a dedicated GNU/Linux user, and after a fair bit of distro-hopping I've come full circle to landing on Xubuntu. My view of my phone is basically a more awkward, more delicate version of my PC - the concept of "bricking" a computer is a joke, and I think until this possibility is 100% eliminated on phones, the developer community is always going to be slightly held back. I think the models used for developing Linux OSes could/should be applied to the ROM development process, too - as brilliant as the community is atm, it does have the "exclusive hacker culture" feel to it still.
The kernel didn't update because the device is s-on, also the call dropping bug, is you're problem no one else mentioned it. Just do research on the small amount of ROMs we got.
Sent from my Nexus 5 using Tapatalk
Lloir said:
The kernel didn't update because the device is s-on, also the call dropping bug, is you're problem no one else mentioned it. Just do research on the small amount of ROMs we got.
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Hi,
How come you can be so sure of the cause? The 'symptom' must be relatively common, I suppose a bit like the technological equivalent of a headache and nausea.
The device is S-ON, you're right. I've read a little but I've not found anything specific to the UK about potential risks. You've got the same phone as me, and you're in the UK too, would you recommend going S-OFF? Does it cause problems with your carrier (I read somewhere that the manufacturer wasn't so bothered, but the carrier was - as it allowed the user to change certain things to do with the way the phone received carrier signal)?
Last bit on ROMs - I've read/seen quite a lot, but the information just isn't out there (unless you personally badger the devs, perhaps). The most official most ROMs get is a thread here. Compare that to (for instance) a Linux distro - you can more or less guarantee that if a distro is linked to on Distrowatch, it'll have it's own site, you can read up about source, included packages, what distinguishing features that OS has, what DE/package manager, etc. There's virtually no equivalent for phones - the best I've seen is xda's ROM listings under the device...if you're lucky one or two of the bigger ones (e.g. CM) will have it's own site. So, in lieu of that, I'm wanting to get a feel of what other users are doing, and what they'd recommend
ArminasAnarchy said:
Hi,
How come you can be so sure of the cause? The 'symptom' must be relatively common, I suppose a bit like the technological equivalent of a headache and nausea.
The device is S-ON, you're right. I've read a little but I've not found anything specific to the UK about potential risks. You've got the same phone as me, and you're in the UK too, would you recommend going S-OFF? Does it cause problems with your carrier (I read somewhere that the manufacturer wasn't so bothered, but the carrier was - as it allowed the user to change certain things to do with the way the phone received carrier signal)?
Last bit on ROMs - I've read/seen quite a lot, but the information just isn't out there (unless you personally badger the devs, perhaps). The most official most ROMs get is a thread here. Compare that to (for instance) a Linux distro - you can more or less guarantee that if a distro is linked to on Distrowatch, it'll have it's own site, you can read up about source, included packages, what distinguishing features that OS has, what DE/package manager, etc. There's virtually no equivalent for phones - the best I've seen is xda's ROM listings under the device...if you're lucky one or two of the bigger ones (e.g. CM) will have it's own site. So, in lieu of that, I'm wanting to get a feel of what other users are doing, and what they'd recommend
Click to expand...
Click to collapse
you cannot S-OFF the X+ currently, so i'm not going into that. Also you stated you flashed from CM10.1 > 10.2, which i assume was a dirty flash (no full wipe etc)
it's like installing the Arch + xubuntu on the same hard drive, which is bound to cause issues. So a full wipe was needed, as you should know "nightlies" are well nightlies, UNSTABLE
the closest we have to distrowatch are the rom reviews and so on. there's my PureAosp, AOSP+ both based on 4.3
CM as well you know what that is.
AOKP no longer supported but stable.
as "best rom" and so on are fround upon, due to the flame and chest beating and so on. which mean's you won't get a good answer tbh, and i'am quite impartial when it comes to rom's as i won't recommend anyone's rom's nor my own.
Lloir said:
you cannot S-OFF the X+ currently, so i'm not going into that. Also you stated you flashed from CM10.1 > 10.2, which i assume was a dirty flash (no full wipe etc)
it's like installing the Arch + xubuntu on the same hard drive, which is bound to cause issues. So a full wipe was needed, as you should know "nightlies" are well nightlies, UNSTABLE
the closest we have to distrowatch are the rom reviews and so on. there's my PureAosp, AOSP+ both based on 4.3
CM as well you know what that is.
AOKP no longer supported but stable.
as "best rom" and so on are fround upon, due to the flame and chest beating and so on. which mean's you won't get a good answer tbh, and i'am quite impartial when it comes to rom's as i won't recommend anyone's rom's nor my own.
Click to expand...
Click to collapse
First thing first, cheers for this man! It's good to be able to have a "conversation" with a dev - although Linux distros have got more infrastructure in place, there is a lack of 1:1 as a result (of having so many devs, etc).
It wasn't a dirty flash at all - every time I've written a new ROM I've wiped everything (or at least, ticked all the boxes in TWRP), then after reformatted - you can see the output of the 'make ext4fs' in front of your eyes. So unless it's that there's some partition which is write-protected (I assume the kernel is - since every time I've had to flash a new kernel - regardless of the wiping in TWRP, the phone just boot-loops without the kernel being flashed)...it's been clean.
I flashed 10.1 BEFORE it was in stable - so my phone was still pointing at the nightly repo (I guess?). GooManager pestered me into updating, and when I did, I ran into issues (presumably, the auto-update isn't intelligent enough to write a new kernel, and/or its in this write-protected partition which can't be accessed from the OS?)
It'd been a while since I'd put 10.1 on, and thought it'd be worth checking to see if it was in stable yet (it was). Did full wipe - as above - and then hit that annoying bug with call dropping. So I'd gone from being working on nightly to broken on stable. Time for a new ROM, methinks...looked around, and decide to post here.
As things stand I'm using AOKP (just because it was another popular ROM I knew, not really for any other reason). It's doing my head in though - either I'm being thick, or there's no option to edit settings in ANY app. I'm missing some of the gloss CM has too, things like it coming with a File Manager installed (why the hell would you not have one?!). From what you say, flashing 10.1 might be worth trying again...I'll go through from ground 0 and hopefully it won't break this time.
I get the thing with not wanting to advertise...so instead can I ask what you yourself use on your HOX+? Do you use it as a main phone, or is it just something you use for developing?
ArminasAnarchy said:
(presumably, the auto-update isn't intelligent enough to write a new kernel, and/or its in this write-protected partition which can't be accessed from the OS?)
I get the thing with not wanting to advertise...so instead can I ask what you yourself use on your HOX+? Do you use it as a main phone, or is it just something you use for developing?
Click to expand...
Click to collapse
you are right on point 1, it's in the write protected partition, and 2nd point, i tend to use my own rom's....i'am in the mindset, if i don't use my own rom's why should other people?
Lloir said:
you are right on point 1, it's in the write protected partition, and 2nd point, i tend to use my own rom's....i'am in the mindset, if i don't use my own rom's why should other people?
Click to expand...
Click to collapse
Haha, I see the logic!
Okay: so we've narrowed it down to a kernel issue. With my AOKP flash, what I did (blade wasn't for the right Android version I think) was extracted the .img file from the ROM.zip and flashed that.
With CM 10,1 (i.e. stable channel) - in your opinion would it be better to do the same, or use the blade kernel?
ArminasAnarchy said:
Haha, I see the logic!
Okay: so we've narrowed it down to a kernel issue. With my AOKP flash, what I did (blade wasn't for the right Android version I think) was extracted the .img file from the ROM.zip and flashed that.
With CM 10,1 (i.e. stable channel) - in your opinion would it be better to do the same, or use the blade kernel?
Click to expand...
Click to collapse
ALL my rom's are extract kernel from zip, i'am not sure what max did with his AOKP.....but 100% all mine you pull from zip and flash that
you can try the CM10.2 btw M1 not long ago released....just an idea..
Lloir said:
ALL my rom's are extract kernel from zip, i'am not sure what max did with his AOKP.....but 100% all mine you pull from zip and flash that
you can try the CM10.2 btw M1 not long ago released....just an idea..
Click to expand...
Click to collapse
Re-installed 10.1 (stable) again. Same issue, even though I've only had it running for 24 hours, it's dropped the call and didn't seem able to get 3G data (it was stuck at "E" for some reason, which makes doing anything impossible) despite being in the middle of the city and not near anything obvious that should block it like a huge block of flats etc.
I installed 10.2, we'll see how it goes.

[DEV ONLY][CM] Team Neutron CM10 L7II

Hello this thread is intended for development purpouses only. Do not post thank you posts, request posts or anything not related to the main purpose. You have a thanks button if you are thankful.
Well warching at what lg did with kitkat using bad jb blobs for gpu that resulted in abnormal cpu usage for rendering and in slowness and glitchness I decided to set up Team Neutron. This team will build a working cm10 that is smooth which is possible.
Well now anyone with abilities can join after i talk to them. Not here on topic but after they pm me.
Atm i would want to know if the following people will join me withoit egos secrets or drama. I will split iobs and watch over the project. I will work on it myself.
Kernel
 @airidosas252
Rom dev from source 
 @weritos
Please confirm or infirm my invitation. This could be my last project for this device since it has almost no support. It will be a good one though.
I understand correctly
Going to collect СM10 ??
We are gonna get a super stable cm 10 if you want to work with me
Sent from my LG-P710 using XDA Free mobile app
christi9503 said:
We are gonna get a super stable cm 10 if you want to work with me
Sent from my LG-P710 using XDA Free mobile app
Click to expand...
Click to collapse
This is certainly good
But for the models 715 to gather a working network will be problematic, СM10 not support two SIM cards
That is right but we are never going to get a stable cm11 because of the gpu. We can make 1 sim work i think
Sent from my LG-P710 using XDA Free mobile app
Edit: @weritos
The best we can get is a JB based rom like CM10.2 at most. After we get the single sim working we can patch somehow for the P715 to use one sim (some ramdisk tweaking).
What I am thinking off:
let's pull the blobs only from our phone. See if we can get it running. We analyze the log and see what are we missing then add them 1 by 1 (this will give us maximum stability that can be attained).
let's remake that device tree with only the 100% necessary things and we can always add up on top of that. Let's not take TeamHackLG base. Of course we will use the 7x27a settings (SoC's are almost the same). Well, the best thing is to make some display things for our own 8225 socket. It will take a while but all we need is in our kernel. We can focus on this later to improve the stability even more.
Well. Our first goal is to make it boot using ONLY the blobs from our device + the GPU drivers I managed to obtain (they are optimized for JB). After we get that working we should worry about other things. Kernel should be modified just to boot (in the first stage). After we get a fully working device (RIL, WIFI etc) we can work on a better kernel, optimization, overclock, deep-sleep and everything we want. I also watched in the LG Ramdisk (from stock). It's a bunch of garbage half of it could be deleted. Well I am pulling the blobs tonight, download cm10.2 source and let's get to work my friend. Imo we should focuse on the boot first. Ofc if you have any opinion I am always to open it and if your idea turns to be a better one (since none is perfect) we will go for that.
EDIT2: There is a fetch error in cm10.2 let's try with branch jellybean.
christi9503 said:
That is right but we are never going to get a stable cm11 because of the gpu. We can make 1 sim work i think
Sent from my LG-P710 using XDA Free mobile app
Edit: @weritos
The best we can get is a JB based rom like CM10.2 at most. After we get the single sim working we can patch somehow for the P715 to use one sim (some ramdisk tweaking).
What I am thinking off:
let's pull the blobs only from our phone. See if we can get it running. We analyze the log and see what are we missing then add them 1 by 1 (this will give us maximum stability that can be attained).
let's remake that device tree with only the 100% necessary things and we can always add up on top of that. Let's not take TeamHackLG base. Of course we will use the 7x27a settings (SoC's are almost the same). Well, the best thing is to make some display things for our own 8225 socket. It will take a while but all we need is in our kernel. We can focus on this later to improve the stability even more.
Well. Our first goal is to make it boot using ONLY the blobs from our device + the GPU drivers I managed to obtain (they are optimized for JB). After we get that working we should worry about other things. Kernel should be modified just to boot (in the first stage). After we get a fully working device (RIL, WIFI etc) we can work on a better kernel, optimization, overclock, deep-sleep and everything we want. I also watched in the LG Ramdisk (from stock). It's a bunch of garbage half of it could be deleted. Well I am pulling the blobs tonight, download cm10.2 source and let's get to work my friend. Imo we should focuse on the boot first. Ofc if you have any opinion I am always to open it and if your idea turns to be a better one (since none is perfect) we will go for that.
EDIT2: There is a fetch error in cm10.2 let's try with branch jellybean.
Click to expand...
Click to collapse
That's a great idea, but first you should try CM10, 10.2 will be very slow on this device, since it is using hardware much more, and it is slower compared to CM10. But that's just my opinion.
True. @shiftyHungary: well after researching it seems cm10.2 is more optimized and from what I am seeing the most stable version of cm for 7x27 is cm10.2 we should work with that imo. There is a sync error because there was some fights over some source. will be fixed easy by replacing in repo with the path that it's used for cm11 or jsut delete that repo. Don't know which one yet. Researching.
Sent from my LG-P710 using XDA Free mobile app
Wow, it's a good new!! Thank you Chri.,
Sent from my Xperia M2 LTE using XDA Free mobile app
christi9503 said:
True. @shiftyHungary: well after researching it seems cm10.2 is more optimized and from what I am seeing the most stable version of cm for 7x27 is cm10.2 we should work with that imo. There is a sync error because there was some fights over some source. will be fixed easy by replacing in repo with the path that it's used for cm11 or jsut delete that repo. Don't know which one yet. Researching.
Sent from my LG-P710 using XDA Free mobile app
Click to expand...
Click to collapse
Okay, you know that better than me, I just shared my experience with my previous devices. Pm me if any help needed.
Well yeah. I really want CM also. I made my own version of CM11 it's smoother than the one we have but still mile away from what it should be even with hard-core optimization because CPU is too high because of the CPU. @weritos ->much respect to this guy, though I disliked some of the things were handled, I give props to him and I am thinking it's a good opportunity to work together and share idea with him (none has nothing to lose). Yeah cm11 will not be our deal and all the graphic glitches in games and stuff it's not because weritos CM11 it's because of LG being LG... With Cm 10.2 we have a way better chance (this came to my mind when actually trying to fix AOKP Ril problem which was based on CM10). I could feel the full powa!!!. Cm copiled GOOD from source will be butter (not in games and stuff ofc it's and Adreno 203 after all) smooth at least in UI and current day-by-day operations.
CM10.2 from the source code
christi9503, As soon as I pass all my exams
I redid the device tree under CM10.2, alter and drop provider (use LG)
But I tell immediately there will be problems with WiFi, Network
Well we can solve problems if we work rogether mosr likely. Best of luck with your exams. I am finishing blobs tonight and i made like half of the device tree. Tonight or tomorrow i will look in the ramdisk and will delete all that is useless
Sent from my LG-P710 using XDA Free mobile app
Well @weritos. Blobs are done (didn't pull the GPU ones since I will be using the ones I have found). Device tree is not fully done but it will be. I am building right now the first build. Using display CAF so it will take a while to get caf to work.
Edit: I will learn to use github and push repos there. Easier to work.
Cristi,
For now, use stock Kitkat kernel sources (just compile them using GCC 4.6 and you're good to go)
Because, once we modified stock kernel for certain things to work, like Wi-Fi, I can duplicate those and merge with my own customized kernel.
I'll work my ass off at my own kernel tonight, since I discovered certain problems.
Anyway, CM10.2 is a way better choice than CM11.
If Google didn't change whole lot of things in Kitkat, things would never have got that messy as it is now.
airidosas252 said:
Cristi,
For now, use stock Kitkat kernel sources (just compile them using GCC 4.6 and you're good to go)
Because, once we modified stock kernel for certain things to work, like Wi-Fi, I can duplicate those and merge with my own customized kernel.
I'll work my ass off at my own kernel tonight, since I discovered certain problems.
Anyway, CM10.2 is a way better choice than CM11.
If Google didn't change whole lot of things in Kitkat, things would never have got that messy as it is now.
Click to expand...
Click to collapse
Looking at the actual ramdisk kernel doesn't need modification for wi-fi to work. Same for RIL. Seeing as how it is handled we might be missing some bins or libs it'll be hard but it's possible to get ril with only our device files. This company called LG is just ****ing with us. Working on ramdisk for over 1 hours. There are A **** LOAD of duplicated files, obsoled, not used files. Working on it.
christi9503 said:
Looking at the actual ramdisk kernel doesn't need modification for wi-fi to work. Same for RIL. Seeing as how it is handled we might be missing some bins or libs it'll be hard but it's possible to get ril with only our device files. This company called LG is just ****ing with us. Working on ramdisk for over 1 hours. There are A **** LOAD of duplicated files, obsoled, not used files. Working on it.
Click to expand...
Click to collapse
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
airidosas252 said:
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
Click to expand...
Click to collapse
The mess they made. They just dirty patched mostly anything. My last LG device for sure.
Sometimes I am really thinking what big companies think. Another update. Sometime there is echo on what you are talking and stuff (like you hear your voice if you talk in the mic). It is because LG doubled some uevents or even tripled them. So they get inited like 3 times. This might solve the mic problem forever also.
airidosas252 said:
And for those reasons I started to mistrust them as a company.
Good thing there are other devices, which really do the helping out.
Anyway, CM10.2 will be easier to get working on our device than CM11.
Click to expand...
Click to collapse
WiFi will not work immediately
Rild will not work
weritos said:
WiFi will not work immediately
Rild will not work
Click to expand...
Click to collapse
We will work that out my friend. Better if it takes 1 week or so to fix just 1 problem than making a messy fix and having instability and stuff. Quality over quantity. In the end that is the best combo.
Amyway, how everything is moving?
Wi-fi isn't a big deal breaker. We'll fix it, as well as RIL.
And we should avoid using modules.
Sent from my LG-P710 using XDA Free mobile app

Categories

Resources