yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] nexusphone:
This thread for GB! not ICS

The thread for ICS http://xdaforums.com/showthread.php?t=1355980
[Nexus S Android Development] Ezekeel:
I will buy an USB OTG cable and hub and test it myself. This kind of remote-debugging when the dev does not have the hardware himself is just annoying for everyone involved.

SLQB is already included since the initial release (see feature list). And I do not see the benefit of dm-cache.
[Nexus S Android Development] nexusphone:
Sorry for my carelessness. Thanks :)
[Nexus S Android Development] djjonastybe:
a init.d script to check for reboots:

All it does is writing date with timestamp to a file. Nothing new actually but useful if you don't have a bootsound to wake you up or notify you during a reboot

last attempt on deep idle for me.
[Nexus S Android Development] djjonastybe:
my device froze 2 times today when turning on my screen. And then rebooted :/ first happened on franco's kernel. Now on this one.

Stock settings with deep idle.

My ROM is NSCollab
[Nexus S Android Development] Ezekeel:
So two days ago, you badmouth me in another dev's thread calling me arrogant. And today you come here acting like that never happened and apparently want my help.

You really think I am going to help you? That is not how life works. Actions have consequences, son!
[Nexus S Android Development] Mecid8:
please add ext4 tweaks and cfs version)
[Nexus S Android Development] thegtfusion:
The issue is fixed. thanks
[Nexus S Android Development] v3rk:
is there any reason to keep the min freq at 400000 as i've been doing with franco's kernels?
[Nexus S Android Development] info[]box1:
Please add cfs variant, my nexus doesn't dance well with bfs kernels. Thanks for the Energy
[Nexus S Android Development] Ezekeel:
When asking for a feature you would like to see implemented in GLaDOS please provide a link with information about this tweak and preferably also a link to the source code.

I know what CFS is, but what is this ext4 tweak you are speaking of?

Great. Thanks for the feedback.
[Nexus S Android Development] Mac Boy:
i9023 on latest nightly - my back lights don't light up again after the dimmer has kicked in. They light up again when I lock and unlock the screen.
[Nexus S Android Development] simms22:
whats the score at what clock? 1000 points doesnt mean anything.
[Nexus S Android Development] tehgeekguy:
Any chance on an md5? I'm getting bad zips from all the sources on multiupload. Downloading a ~2.6MB file with 55dda0d0204318f2435c9de9dfad6958.
[Nexus S Android Development] v3rk:
i'm consistently getting 3000-3500 at 110 liveoc, 1100mhz max 440mhz min. i've been running franco's kernels since they dropped, and ever since he implemented liveoc i'd score 2000-2500 on quadrant... sometimes less. and to clarify, i've always run with liveoc at 110

that said i don't notice too much of a difference between the two in real use. though i do miss the voodoo color gamma hacks which seem to be missing from this kernel
[Nexus S Android Development] Mecid8:
Ext4 remount tweak from netarchy kernel.

Thanks for your work!
[Nexus S Android Development] caliban2:
sweet kernel, stable so far and very, very fast. (i don't believe in benchmarks, i judge by using the thing ^^)

anyhoo, one bug:

data-conn gets lost after some time, 3g & wifi. only restart fixes it. so i take back what I've said earlier. and yes, I'm on a fresh installation from scratch.
[Nexus S Android Development] simms22:
francos kernel is getting between 2000-2500 :eek:

then there is something wrong with francos kernel then, 2000-2500 is way too low. i was testing one of francos kernels on irc the night before last, and was scoring consistantly between 3700-3940 at 1ghz.
[Nexus S Android Development] Borky_16:
It is from Supercurio, I will rsearch it ! Wait a bit and thanks for linking my thread ;)
[Nexus S Android Development] simms22:
i believe that he is referring to..

mount -o remount,noauto_da_alloc /data /data
[Nexus S Android Development] Serious_Beans:
:D awesome, I see you took my advice :P lol, will test tonight.
[Nexus S Android Development] Borky_16:
yeah here is the thread btw http://xdaforums.com/showthread.php?t=876069
[Nexus S Android Development] simms22:
judging by people saying that they are getting quadrant scores of 3500, it sounds like its already included.

---------- Post added at 05:17 PM ---------- Previous post was at 05:14 PM ----------

just checked, the "ext4" script is already in there. its in /system/etc/init.d/99nexusinit/
[Nexus S Android Development] shubu000:
Hey Ezekeel,

Just wondering is it possible to put all the voodoo colour options into the kernel? I miss the colour level tweaks, you only have the multiplier in your kernel. Otherwise it's been awesome :)

thanks
[Nexus S Android Development] Ezekeel:
Due to popular demand I have compiled a kernel with CFS (actually I just disabled BFS; I hope that works and I do not need yet another branch for CFS with different code). Since I currently use my Nexus for other things, I did not test this one.

Test kernel with CFS: http://www.multiupload.com/HZAMJ3N9Y9

Hmm. I thought I had everything regarding Voodoo Colors by merging with the branch nexus-s-voodoo-color from https://github.com/project-voodoo/linux_samsung.git. I might have to check that again.
[Nexus S Android Development] polobunny:
AFAIK it's just a recompile, no need for a different branch.
[Nexus S Android Development] nexusphone:
Everything is fair, one reap as one has sown. We have a lot to learn about life.
[Nexus S Android Development] suomaf:
Hey Ezkeel,

How is the otg looking? Can we help in anyway?
[Nexus S Android Development] Ezekeel:
I have ordered the hardware and it should arrive in a few days. Then I will look at it first hand.
[Nexus S Android Development] djjonastybe:
I PM'ed him I was sorry actually. And I told it was my mistake. What more can I do? He doesn't accept donations so I have heard. Right Ezekeel?

Deep Idle is working fine now on my own ROM. I made a script to check for reboots and I have no errors so far.
[Nexus S Android Development] suksit:
That's a pretty messed up logic. I believe most people will not call someone who contributes so much to the community and does not accept any money in return as "arrogant" ;)
[Nexus S Android Development] ChargingPaladin:
Ezeekel, I'm late to the game here on this usb-to-go discussion but (if you haven't already found it) this link helped me a lot. http://www.maxim-ic.com/app-notes/index.mvp/id/1822

Building your own cable, even a switching one, isn't terribly difficult but ordering the hardware is obviously easier :p

Either way, the software support hasn't exactly been robust so I'm stoked that you're tackling it!
[Nexus S Android Development] Ezekeel:
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.
[Nexus S Android Development] polobunny:
Loving the DRAM tweak/idea. OC to the max hell yeah! :D

Not gonna miss CFQ with an optimized deadline or noop anyway.

Have you got any before/after shots to show us? I'm just idling on franco's for 100 hours stable before I test another kernel, so I won't be flashing it soon.
[Nexus S Android Development] phone_user:
Wow!!!
[Nexus S Android Development] Icecoldmeat:
Running V1.10 now, works beautiful. Good job.

Greets from the Netherlands!
[Nexus S Android Development] franciscofranco:
Ezekeel can you share the DRAM liveoc diff so I can put it up a test on my device?
[Nexus S Android Development] Lazat:
Mine does not even wanna boot with this kernel, its just sitting at the Google logo bootscreen, and then restart over and over again. I tried both cfs and bfs and also tried redownloading the both :( any tips? I'm running Franco's latest fine atm. Kang cm7 from 07Dec, nexus 9023
[Nexus S Android Development] suksit:
Try wiping cache and dalvik-cache.
[Nexus S Android Development] uansari1:
I experienced this as well when I tried modifying the zip file and flashing it. I restored to my original set up and redownloaded and flashed the kernel without changing anything and it worked fine. Try downloading it again and make sure to wipe cache and dalvik cache prior to flashing.

Holy mother of God, this kernel is FAST! LiveOC to 110% and it's noticeably faster than 1.9 at the same setting and min/max clock speeds!
[Nexus S Android Development] suomaf:
Hey Ezkeel,

Good news on the donation button. Please let me buy you a otg cable for your testing. Paypal confirmation 6LK652800U3383648.

Suomaf
[Nexus S Android Development] polobunny:
Donated for beer/coffee fund. Or whatever device you need to buy. ;)
[Nexus S Android Development] vis80k:
i came from SG's latest and app startup is noticeably slower...even comparing this at liveoc 110 and SG at default...
[Nexus S Android Development] phone_user:
I strongly recommend GPA19 (the latest 2011-12-07) to you. Whatever kernel, everything is really works well with that rom. I've have no recent bad issue - data drop, reboot etc - on that. :)

Adding "/system/etc/init.d/" function to the latest GPA19 (07-12-11)
[Nexus S Android Development] Lazat:
Ofcourse I tried wiping cache and DV-cache, and also tried redownloading. This kernel refuses to boot on my phone. I'm just stuck at the Google logo :(

Edit: gonna try to wipe /system and reflash cm7kang 5Dec and then flash this kernel and see if it helps :) isn't this kernel supposed to clean everything kernel related? and if it helps then I would apprieciate if someone could explain why it worked ;) maybe the cleaning script isn't working?

Edit 2: it worked! so that must mean that the cleaning script in this version is broken somehow :)
[Nexus S Android Development] djjonastybe:
Ezekeel,

A nice addition to LiveOC would be that we can eliminate what we overclock in the liveOC.

or set a factor for each thing

Let's say if live OC = 101

CPU = 1

GPU = 2

DRAM 1

For GPU and DRAM I will use invented frequencies.

Doing some math =

CPU = 1000mhz + ( 1000 * 0.01 (liveOC) * 1 (CPU scaling) = 1010mhz

GPU = 300mhz + ( 300 * 0.01 (liveOC) * 2 (GPU scaling) = 306

If we had 1.01 without the multiplier for the GPU we would get 303.

DRAM = 666mhz + ( 666 * 0.01 * 1) = ...

This might allow us to overclock each thing separately. I don't know if this is possible. Well it's better to overclock each component separately if you find this interesting. If you happen to find my proposition interesting I suggest you set each multiplier at 1.

I am going to try 1.10 later today. Lazy works better than Conservative like you said Ezekeel. And it runs much smoother. I compared battery usage with watching a video and then some regular usage.
[Nexus S Android Development] FloHimself:
why not just seperated files in sysfs?

/sys/class/misc/liveoc/cpu_oc_value
/sys/class/misc/liveoc/gpu_oc_value
/sys/class/misc/liveoc/ram_oc_value
[Nexus S Android Development] -Nacho:
Working fine so far! Thank you so much!
[Nexus S Android Development] nexusphone:
What is Nexus S DRAM stock frequency?
[Nexus S Android Development] Ezekeel:
I did benchmark the flash I/O and the pure throughput has increased by about 10%. I also tested app startup times and they were reduced by about the same factor.

I knew I did forget something. Sorry. I have uploaded the changes to my git.

That is strange since it boots up with default settings.

Anyone else having this problem?

The GPU/bus and CPU frequencies are indirectly linked since they both are created by using different dividers on the same source clock. And that source clock is scaled with the OC value. So without changing the dividers the CPU and GPU clocks will always have the same ratio.

However it would be possible unlink the DRAM frequency from the CPU and GPU/bus and change it independently with an additional parameter. While this would introduce a greater flexibility, I am not sure this flexibility is actually needed since increasing the DRAM frequency without simultaneously increasing the bus connecting the DRAM will be of no benefit.

Good question. I dunno.

And I would like to thank all people that have donated.
[Nexus S Android Development] boostern:
Ezekeel, first of all thanks for all your mods!

I come from franco kernel, but I noticed that with GLADOS I cannot set blx parameter grater than 96%. Is it normal or is it me?
[Nexus S Android Development] boostern:
I've done a little research, and with the part numbers we have, the Nexus S could have either 166mhz or 200mhz LPDDR1 (we lack the last numbers to identify what of these two, but I bet it is 200mhz). Regarding the Dram frequency debate, I'm not 100% sure that the memory controller is connected to the CPU through the bus...if this is the case, raising only the ram frequency can bring some performance improvements.
[Nexus S Android Development] Arkaknio:
Thanks to god now you accept donations!!

Just sent to you a few coins to help in your developments (transaction 88554656YB852813D).

What do you think about develop for Kindle Fire?. Is cheap, Amazon deployed the source and will be a success in a near future.

Of course never forget our loved Nexus S!!
[Nexus S Android Development] Ezekeel:
Yes. I did not include the cosmetic 100% 'fix'.

Good work. Yeah, 200MHz sounds reasonable since that also is the frequency of the bus.

From the hardware manual:

I do not like touch screen devices larger than a smartphone. If I cannot put it into my pocket I can as well bring a small subnotebook and have a real keyboard.
[Nexus S Android Development] boostern:
Ok, all pass theough the bus :P

BTW, the ram part number is K4X2G323PB-XXX but we don't have the last 3 numbers needed to identify the speed. The PoP SoC part number is KB100D00WM-A453, it contains 512mb of rom and the 512mb of ram (K4X2G323PB) .
[Nexus S Android Development] djjonastybe:
Does anyone here know how I prevent my phone to change from GSM only to GSM/CDMA auto (PRL)

I have to set it back to GSM only every time

When my phone changes between GSM and CDMA, it is causing sudden screen wakes on my phone.
[Nexus S Android Development] boostern:
Ezekeel, I've found something regarding the AXI bus. In the A8 reference manual: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344c/Cacjeigj.html is written that the bus can be 64bit or 128bit wide: you know that single channel lpddr1 is 32bit wide, so if the bus is (worst case) 64 bit wide, we have some room to improve the memory badnwidth by increasing only the dram frequency alone. If you have some spare time I think it worth a try...do some test by your own and check if it really increase the bandwidth.
[Nexus S Android Development] djjonastybe:
Is anyone else having problems with the radio sometimes disconnecting so you lose your reception? I have 0 bars and a cross. This usually happens after my screen suddenly lights up in deep idle mode.
[Nexus S Android Development] caleb1783:
i had data drop w deep idle enabled. when turn off didle. things going smoothly for a day so far...

Sent from Divinus Nexus S...
[Nexus S Android Development] nexusphone:
By now Ezekeel is probably thinking about Deep Idle patch.
[Nexus S Android Development] caleb1783:
but i dont think ezekeel is having these data drops... since he cant replicate it, he cant test it... thus cant fix it.
[Nexus S Android Development] djjonastybe:
What is a data drop?

Isn't that what I am having?

I believe franco's fans are having those as well.

I specially having issues with deep idle when recharging my phone. It freezes all the time. I can't get my screen back turned on.
[Nexus S Android Development] franciscofranco:
Thats pretty interesting, good find.
[Nexus S Android Development] Ezekeel:
Exactly. Plus I am not convinced that the problems are caused by DEEP IDLE. Instead I suspect the problems be due to some bug in the GB ROMs since up until now I have not read a single complaint from those already using ICS.

Regarding the DRAM, I guess, that is the reason we have two 32-bit modules for a 64-bit bus.
[Nexus S Android Development] boostern:
No no Ezekeel the ram is single channel, so it is 32bit wide. There's another thing: sticking to the diagram you have posted, we have two MMCU (DMC0 and DMC1) but we know that our device is single channel. If you read what there's in the KB100D00WM-A453 you see that we have (leaving out the 8gbit nand) 2gbit dram module, 1gbit dram module and 1gbit dram module....it is strange, isn't it? This make me think that we have 2gbit+1gbit for the cpu (so, 384mb for the system) and 1gbit for the gpu (128mb), 2gbit+1gbit connected to the DMC0 and the 1gbit to DMC1. I also searched for the bus used in the A9, it's the same AXI bus so maybe it was designed 64bit or 128bit wide with future architectures in mind. Summarizing all, the bus isn't the bottleneck to the MMCUs because (if it is 64bit AXI) it is fully used only when cpu+gpu are 100% loaded.

By the way, these are only my suppositions beacuse I'm not able to find the datasheet for the S5PV210 and for the KB100D00WM-A453. Maybe in the kernel sources you are able to find the 384mb+128mb thing...
[Nexus S Android Development] djjonastybe:
Did you guys actually notice that we only have 330MB of RAM?

With my Galaxy 3 and Galaxy Gio they reported 278MB or 256MB. And this was correct when you did some testing...

Any idea why we only have like 330MB instead of the advertised 512MB?

It sounds like shared memory with the GPU.
[Nexus S Android Development] Ezekeel:
Yeah the RAM is single-channel, but we have 2 memory controllers each using 32-bit. I guess you are right and the only reason why that works is that one controller handles the system RAM and the other the video RAM. I will take a another look though.
[Nexus S Android Development] boostern:
Yes, I forgot to mention it...obviously 32bit for the system memory and 32bit for video memory.
[Nexus S Android Development] Ezekeel:
Btw if you want the manual: http://lmgtfy.com/?q=s5pv210+manual

Just remember that this is copyrighted material so distribution is officially not permitted (but I guess Samsung could not care less).
[Nexus S Android Development] boostern:
Lol, it was so simple! I've searched for the part number instead of simply search for s5pv210 :p
[Nexus S Android Development] Ezekeel:
:)

I checked and in /proc/meminfo the total amount of RAM is given as 353528kByte = 2.7Gbit. Also I found that 16MByte = 0.13Gbit are set aside for the modem. So I guess you are correct and one 2Gbit module and one 1Gbit are together used for the system RAM. And judging from comments in the code these are most likely wired to DMC0. So the other 1Gbit must be wired to DMC1 and used for the video RAM.

I guess it is worth a shot trying to increase the RAM frequency some more and take a look at the results.
[Nexus S Android Development] boostern:
It makes sense, otherwise why the hell had Samsung put two memory controllers inside?

Now we know why google called the nexus s "a phone designed for games". It's a good and a bad news, because we have "only" 384mb for the system...but with the bandwidth not shared with the video ram.
[Nexus S Android Development] EnemyOfGlaDOS:
Don't own a Nexus S, but you got a 'thanks' from me, just for having a sweet kernel name! .. great intro too! :D
[Nexus S Android Development] Ezekeel:
I looked deeper into the code and ran some tests and as it turns out the changes I made did not influence the frequency of the DRAM itself, but the refresh rate of the memory controller. The DRAM frequency is divided from the msys clock which already was increased with the previous version of Live OC.

This means two things. First, in spite of the misconception the patch still makes sense and should increase the stability for larger OC values since the refresh rate of the memory controller should be scaled with the DRAM frequency. Also the patch will ensure that the refresh rate of the controller does not become a bottleneck. And second, increasing the refresh rate without simultaneously increasing the DRAM frequency will be of no benefit (probably on the contrary), so linking the scaling of the refresh rate to the OC value makes sense.

Thanks. :)
[Nexus S Android Development] boostern:
Sorry, today i was busy at work...but yesterday night I started reading the s5pv210 manual, and I noticed what you have said. I have also seen that DMC0 has his own dividers (see page 3-31, 3-37 and 3-40 of the manual). Since I know almost nothing about kernel's stuff, is it possible to allocate all the camera memory, modem memory etc...in the video ram? 1Gbit is really too much for the video ram in a 800x480 device, I think that we can give up to some video ram without performance decrease in the video part.
[Nexus S Android Development] Ezekeel:
I looked into that and it seems like not the entire 128MB are used for the video RAM. This would kill our theory about one 1GBit module wired to DCM1 and only be used for video RAM.

RW gives out another Nexus Prime to a kernel dev and has decided to have a spamming contest for it (sigh). So if you like my kernel or some of my tweaks head over HERE and post a comment.

Do it NOW or I eat this bunny!

No seriously, this spam contest is the last chance for me to get my hand on a GN, so if I do not win this one the GN community will have to make due without my support. So invest these 2min of your time please. Every vote counts!