- Status
Not sure actually.
Just saw one of franco's post with this set-up, so I decided to test it like that. Kind of a newb with the nstools app and the things one can do with it, so I've been trying different configs to see which had the best combination of battery life and performance.Sorry, wish I had a better answer for you!
Added support for data usage limits (thanks Franco for sending me his .config).
Download: http://www.multiupload.com/DCIP6G25R6
Download: http://www.multiupload.com/DCIP6G25R6
Bln app say lib lights are not werking
Any can help me out
Sent from my Nexus S using xda premium
Any can help me out
Sent from my Nexus S using xda premium
I am currently working on getting USB On-The-Go (USB OTG) support to work on the Nexus S so one can connect USB flashdrives, external drives, mice and keyboards directly to the device. Unfortunately I do not have the necessary hardware (USB OTG cable and powered hub) to test it, so if you have these accessories please try the following test kernel.
Test kernel: http://www.multiupload.com/51FOQFYQC8
Test kernel: http://www.multiupload.com/51FOQFYQC8
Since most of the ICS builds do not support DEEP IDLE TOP=OFF ... is there anything to gain with DEEP IDLE?
However I do notice that I can obtain DEEP IDLE TOP=OFF on ICS but only when in Airplane Mode. Otherwise it's always TOP=ON.
However I do notice that I can obtain DEEP IDLE TOP=OFF on ICS but only when in Airplane Mode. Otherwise it's always TOP=ON.
I explained in the initial post, why only the DEEP IDLE state with TOP=ON is being used and how one can 'fix' this.
No.
And I do not see any benefit of using alpha 12 over alpha 11. If Google Wallet causes problems one can remove it manually. I also do not understand why they made changes to the WiFi driver since WiFi was not broken for alpha 11.
This update to alpha 12 including the changes for the kernel are a waste of time in my opinion. That ICS alpha version will be trashed once the official ICS version for the Nexus S will released which I expect to be soon, and all the work put into this alpha release will be useless by then.
If I knew this patch would also fix the problem with DEEP IDLE and BT I would make the effort of including it. But currently I see no benefits.
Ah I'll try that right away. Does that mean I have to perform that 'fix' everytime I get a reboot, crash, SOD, etc? (I mean it wouldn't be worth it otherwise considering the alpha stage of these builds.) I'm just wondering why people aren't too concerned with this fix if TOP=OFF is really that beneficial ...
And getting back to my first question what is the difference between TOP=ON and TOP=OFF? Does TOP=ON keep the bluebooth, GPS hardware on while powering off everything else?
Base on my experience the wifi improves a lot. Their are some place in my house that have very poor signal 1 bar signal to be precise but with the new wifi it improves the signal on my phone by 1 bar. Many people experience it too.
I can also report a noticeable stronger wifi signal on a12 and kangs, so far tested with the ROM's own kernel. Trying SG's kernel now.
Sent from my Nexus S using xda premium
Today a got a huge update for you.
First, I have made a significant improvement to Live OC. When the OC value is raised not only the bus/GPU speed is increased, but also the DRAM frequency. Since the GPU does not have its own dedicated RAM, but uses a chunk of the DRAM this should increase the stability for high OC values and also the performance of the framebuffer access by making sure that the DRAM does not become a bottleneck.
Furthermore I have improved the performance and responsiveness of the flash memory I/O by carefully tweaking several kernel parameters. This should significantly reduce the probability of pending I/O operations causing lags.
As the third major change I have added the Tiny Preemptive RCU which should further increase the overall responsiveness of the device.
I also updated the optimized CRC32 algorithm to the latest version and removed the CFQ I/O scheduler since deadline is the default and that should be used.
I get a lot requests from users if I could add this or that feature to my kernel and I think it is worthwhile that I tell you a little about my kernel design philosophy.
I come from a Linux background, did my share of kernel hacking before Android and in the Linux world before any patch is even considered to be added to the kernel the author has to prove that this new addition actually does bring an improvement. And believe me the other kernel devs can be quite critical. However it is that kind of peer-review that keeps the Linux kernel of being clogged by nonsense and thus acts as a quality control.
In the Android world pretty much every device has its own kernel and custom kernels are quite popular and every developer essentially is working on his own personal kernel tree. While this fragmentation offers a lot a freedom, it also means that there is no peer-review at all. And unfortunately from what I have seen so far, the general practise around Android kernel developers is to simply add every feature they can find. They do not test, they do not compare, they do not benchmark. The result is a whole parade of overblown and unstable kernels with more unnecessary feature than I can count.
With my GLaDOS kernel I follow a strict no-nonsense policy and try to stay as close to the stock kernel as possible without sacrificing too much performance. Or my '99 with 1' design paradigm as I like to call it - 99% of performance of a theoretical optimum kernel with all possible improvements included while only using only 1% of the necessary modifications to the source code. This does not only improve the maintainability, but in the end will result in a both lean and stable kernel with a great performance.
Since so many people were asking for it, I changed my mind and decided to accept donations. You have my word that the collected funds will only be used for buying additional hardware to continue my development and if possible to extend my work to another device preferably of course the Nexus Prime.
First, I have made a significant improvement to Live OC. When the OC value is raised not only the bus/GPU speed is increased, but also the DRAM frequency. Since the GPU does not have its own dedicated RAM, but uses a chunk of the DRAM this should increase the stability for high OC values and also the performance of the framebuffer access by making sure that the DRAM does not become a bottleneck.
Furthermore I have improved the performance and responsiveness of the flash memory I/O by carefully tweaking several kernel parameters. This should significantly reduce the probability of pending I/O operations causing lags.
As the third major change I have added the Tiny Preemptive RCU which should further increase the overall responsiveness of the device.
I also updated the optimized CRC32 algorithm to the latest version and removed the CFQ I/O scheduler since deadline is the default and that should be used.
I get a lot requests from users if I could add this or that feature to my kernel and I think it is worthwhile that I tell you a little about my kernel design philosophy.
I come from a Linux background, did my share of kernel hacking before Android and in the Linux world before any patch is even considered to be added to the kernel the author has to prove that this new addition actually does bring an improvement. And believe me the other kernel devs can be quite critical. However it is that kind of peer-review that keeps the Linux kernel of being clogged by nonsense and thus acts as a quality control.
In the Android world pretty much every device has its own kernel and custom kernels are quite popular and every developer essentially is working on his own personal kernel tree. While this fragmentation offers a lot a freedom, it also means that there is no peer-review at all. And unfortunately from what I have seen so far, the general practise around Android kernel developers is to simply add every feature they can find. They do not test, they do not compare, they do not benchmark. The result is a whole parade of overblown and unstable kernels with more unnecessary feature than I can count.
With my GLaDOS kernel I follow a strict no-nonsense policy and try to stay as close to the stock kernel as possible without sacrificing too much performance. Or my '99 with 1' design paradigm as I like to call it - 99% of performance of a theoretical optimum kernel with all possible improvements included while only using only 1% of the necessary modifications to the source code. This does not only improve the maintainability, but in the end will result in a both lean and stable kernel with a great performance.
Since so many people were asking for it, I changed my mind and decided to accept donations. You have my word that the collected funds will only be used for buying additional hardware to continue my development and if possible to extend my work to another device preferably of course the Nexus Prime.
Donate link? Please don't abandon us when you get the Prime. You deserve it either way with what you have done so far.
Sent from my Nexus S
You deserve it either way with what you have done so far.Sent from my Nexus S
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
56I put together a test version of GLaDOS which works with kwiboo's ICS port.
Download: http://www.multiupload.com/BA2GQ1VNMC
Sources: https://github.com/Ezekeel/GLaDOS-nexus-s/tree/glados + https://github.com/CyanogenMod/samsung-kernel-crespo/tree/ics
I tested it a bit and it seems something is keeping the DEEP IDLE state with TOP=OFF from being used; instead TOP=ON is used. So I guess this is a problem with GPS, BT or the vibrator. Will look into it tomorrow.
Update #1:
The problem is that BT is not properly disabled in the kernel when switched off. I have removed the check for BT in DEEP IDLE for now, so one can test the TOP=OFF state. If you need BT disabled DEEP IDLE or use the previous version.
Download: http://www.multiupload.com/FTH2DUN0M8
Update #2:
Since Koush's ICS ROM seems to be faster and more stable, his development is more transparent and he updates his kernel git in a timely fashion, I have decided to drop the official support for kwiboo's ROM and only support Koush's ROM in future updates. The kernel still might work with kwiboo's ROM though.
I have reenabled the check for BT in DEEP IDLE, so the TOP=ON will be used instead of the TOP=OFF state. I have informed Koush about the issue - maybe he can find the change in the ROM that causes this.
Download: http://www.multiupload.com/FUDAQY4AYT
Update #3:
Added OC frequency states 1.4GHz and 1.2GHz.
Download: http://www.multiupload.com/H5ARZNK691
Update #4:
Added latest kernel patches for ICS alpha 9. These seem to break adb.
If you do not need BT and want the DEEP IDLE state with TOP=OFF to be properly used, you can switch BT off manually with 'echo 1 > /sys/devices/platform/bt_rfkill/rfkill/rfkill0/soft'. This will break the BT switch and you will need to reboot if you want to use BT.
Download: http://www.multiupload.com/HDVWPGM43Q
Update #5:
Fixed adb and tethering (one needs to enable CONFIG_USB_G_ANDROID in .config). Mass storage is still not working though.
Also to get adb working, I had to edit my /etc/udev/rules.d/11-android.rules on my Linux machine from
toCode:SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e21", MODE="0666", OWNER="azrael" #Normal nexus s SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e22", MODE="0666", OWNER="azrael" #Debug & Recovery nexus s SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="4e20", MODE="0666", OWNER="azrael" #Fastboot nexus s
Code:SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", MODE="0666", OWNER="azrael" #Normal nexus s SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", MODE="0666", OWNER="azrael" #Debug & Recovery nexus s SUBSYSTEMS=="usb", ATTRS{idVendor}=="18d1", MODE="0666", OWNER="azrael" #Fastboot nexus s
My guess is the Nexus S reported with a wrong idProduct (that of the Nexus Prime?).
Download: http://www.multiupload.com/LIILVGO0XH
Update #6:
Updates for Koush's alpha 11.
Mass storage now works (under Windows 7, but not on my Linux machine; probably a problem with Linux).
Download: http://www.multiupload.com/VYK8J1LG20
Update #7:
Turns out I was an idiot and did upload the wrong zip file. Here is the correct one. Sorry.
Also I forgot to mention that the last update adds init.d support. Thanks to Flo for that.
Download: http://www.multiupload.com/5AHEB0DJQ5
Update #8:
Added support for data usage limits (thanks Franco for sending me his .config).
Download: http://www.multiupload.com/DCIP6G25R6
Update #9:
- Added DRAM scaling to Live OC.
- Flash memory I/O tweaks.
- Added Tiny Preemptive RCU.
- Updated the optimized CRC32 algorithm.
- Removed CFQ I/O scheduler.
Download: http://www.multiupload.com/9Z86UNGP4L
Update #10:
Added Bigmem option (increases RAM available for the system by 26MB).
Download: http://www.multiupload.com/2Z7D4WPXRP
Update #11:
Improved Bigmem option (increases available RAM by 27.5MB now).
Download: http://www.multiupload.com/5HOQB8LS3X10Today a got a huge update for you.
First, I have made a significant improvement to Live OC. When the OC value is raised not only the bus/GPU speed is increased, but also the DRAM frequency. Since the GPU does not have its own dedicated RAM, but uses a chunk of the DRAM this should increase the stability for high OC values and also the performance of the framebuffer access by making sure that the DRAM does not become a bottleneck.
Furthermore I have improved the performance and responsiveness of the flash memory I/O by carefully tweaking several kernel parameters. This should significantly reduce the probability of pending I/O operations causing lags.
As the third major change I have added the Tiny Preemptive RCU which should further increase the overall responsiveness of the device.
I also updated the optimized CRC32 algorithm to the latest version and removed the CFQ I/O scheduler since deadline is the default and that should be used.
I get a lot requests from users if I could add this or that feature to my kernel and I think it is worthwhile that I tell you a little about my kernel design philosophy.
I come from a Linux background, did my share of kernel hacking before Android and in the Linux world before any patch is even considered to be added to the kernel the author has to prove that this new addition actually does bring an improvement. And believe me the other kernel devs can be quite critical. However it is that kind of peer-review that keeps the Linux kernel of being clogged by nonsense and thus acts as a quality control.
In the Android world pretty much every device has its own kernel and custom kernels are quite popular and every developer essentially is working on his own personal kernel tree. While this fragmentation offers a lot a freedom, it also means that there is no peer-review at all. And unfortunately from what I have seen so far, the general practise around Android kernel developers is to simply add every feature they can find. They do not test, they do not compare, they do not benchmark. The result is a whole parade of overblown and unstable kernels with more unnecessary feature than I can count.
With my GLaDOS kernel I follow a strict no-nonsense policy and try to stay as close to the stock kernel as possible without sacrificing too much performance. Or my '99 with 1' design paradigm as I like to call it - 99% of performance of a theoretical optimum kernel with all possible improvements included while only using only 1% of the necessary modifications to the source code. This does not only improve the maintainability, but in the end will result in a both lean and stable kernel with a great performance.
Since so many people were asking for it, I changed my mind and decided to accept donations. You have my word that the collected funds will only be used for buying additional hardware to continue my development and if possible to extend my work to another device preferably of course the Nexus Prime.4
I spend the last two hours trying to put in the latest patches for alpha 12/13. I have no idea what kind of abomination that CM kernel has become, all I can say is that it has diverged that much from stock that it is pretty much hopeless to integrate any patches based on the CM kernel into a kernel forked from stock. I played the funny 'hunt the undefined symbols' game for over two hours now and I am sick of it. For every symbol I resolve by patching a file, two new undefined symbols pop up. That could go on for hours until I reach something that at least will at compile.
I am sorry to get your hopes up, but that is not worth my time considering that this kernel will be trashed once the official ICS kernel will get released. I rather spend my time fixing that problem with Bigmem on GB.3Donate link? Please don't abandon us when you get the Prime. You deserve it either way with what you have done so far.
Sent from my Nexus S
No worries. I love my Nexus S.
And the main reason for the donations fund is to get another device without having to sell the Nexus S which I am not willing to do (at least for the next year or so) since otherwise I would not be able to provide updates and proper support anymore.3