Re: overclocking kernel modules for PR1.2
 

opensh is for interactive user use only! Never use it in order to execute privileged operations from a script. It'll be replaced with a better alternative soon that won't work for such applications, anyway.

Instead, use the Aegis manifest to assert tcb and CAP::sys_module credentials for your initscript. This will then make it possible to whitelist the kernel module and load it in order to perform the actual overclock.

If you need any advice, feel free to hit me up on IRC! (official INCEPTION channel: #inception on Freenode)

Re: overclocking kernel modules for PR1.2
 

Ha I wondered if that might be the case for opensh use with scripts, if distributed via .deb users wouldn't know that the app wasn't going to give the phone herpes lol.
On a separate note, pipould said he'd be happy to contribute a qml ui for these modules a while back, I'd also be happy to do the same and I have no doubt more people would be on the same page for this project, It'll definitely come in some form.
But yeah as its been mentioned before, it's a bit early for a ui, and using a boot script would almost certainly require a flash at some stage.
The less headaches for Creamy while he irons out the kinks of these modules the better.

Re: overclocking kernel modules for PR1.2
 

The n9 and n950 have different default voltages, I wonder why...
Anyways, by default smartreflex is allowed to lower the voltage of the 1000mhz by 50,000uv. Maybe it's designed to detect a different type of problem, but when I overclock it, it still lowers the voltage by the full 50k and the phone reboots as soon as you touch it (@ 1200mhz anyways). You would think disabling smartreflex is the obvious solution, but I prefer to leave it enabled. I am just patching something so it can do what it wants with the lower speeds, you will still get the same battery life when the device is idle or getting light usage that way. I raised the starting point of the 1000mhz voltage to 1375000 instead. This is the max allowed for the chip according to the data in our kernel. The defaults on the n9 and n950 is actually 1225000 and 1350000 respectively. Smartreflex usually is going to lower it by 50k uv but I'm just changing that 50,000 to 0 so it won't be able to change it. That only affects the 1000mhz profile though, so the others will still reduce by whatever it feels like. LATER I will allow you to change this 50k number yourself, so if you want 1150 mhz it won't force the high voltage. But for now, any mhz > 1100 will bump up the voltage to the max.
Now I'm just testing this, I will edit this post when the new version is online...

Re: overclocking kernel modules for PR1.2
 

Where are you getting the voltage value of 1225000 from ? This is what I can see is the default OPP table in the n9 kernel source (cpufreq34xx.c). 1GHz runs at 1.375V


300000000, 1012500
600000000, 1200000
800000000, 1325000
1000000000, 1375000

Re: overclocking kernel modules for PR1.2
 

It doesn't though, it actually runs at the nominal voltage which is the minimum voltage required to run the worst sample of silicon they manufactured.

There's also this in voltage.c:

/* VDD1 */
static struct omap_volt_data omap34xx_vdd1_volt_data[] = {
{.u_volt_nominal = 975000, .sr_errminlimit = 0xF4,
.vp_errorgain = 0x0C},
{.u_volt_nominal = 1075000, .sr_errminlimit = 0xF4,
.vp_errorgain = 0x0C},
{.u_volt_nominal = 1200000, .sr_errminlimit = 0xF9,
.vp_errorgain = 0x18},
{.u_volt_nominal = 1270000, .sr_errminlimit = 0xF9,
.vp_errorgain = 0x18},
{.u_volt_nominal = 1350000, .sr_errminlimit = 0xF9,
.vp_errorgain = 0x18},
};

I think I was wrong about the dyn_margin though. What it does it start at the nominal voltage and reduce it until it hits errminlimit, then raises it up 50k.
Anyways, on my phone, if i don't even touch anything and just read the data I get
1375000 <<max
1225000 <<nominal
50000 << margin
1175000 << optimized

I thought it's taking nominal - 50k to get optimized, but its actually taking optimized + 50k to get nominal.
I'll try changing the errlimit to like 1 and see what happens.

Re: overclocking kernel modules for PR1.2
 

n9 table is omap36xx_vdd1_volt_data not 34xx

Re: overclocking kernel modules for PR1.2
 

yeah sorry copied wrong one...

static struct omap_volt_data omap36xx_vdd1_volt_data[] = {
{.u_volt_nominal = 1012500, .sr_errminlimit = 0xF4,
.u_volt_dyn_margin = 50000, .vp_errorgain = 0x0C},
{.u_volt_nominal = 1200000, .sr_errminlimit = 0xF9,
.u_volt_dyn_margin = 50000, .vp_errorgain = 0x16},
{.u_volt_nominal = 1325000, .sr_errminlimit = 0xFA,
.u_volt_dyn_margin = 50000, .vp_errorgain = 0x23},
{.u_volt_nominal = 1375000, .sr_errminlimit = 0xFA,
.u_volt_dyn_margin = 50000, .vp_errorgain = 0x27, .abb = true},
};

matches better :)

anyways, I'm wrong again, I found another kernel that is better documented.

the dynamic nominal is just where it starts the calibration from, it really does run at the optimized voltage unless you disable smartreflex.
Probably we need more than 137500 to get 1200 stable then, but it should vary by device.

Re: overclocking kernel modules for PR1.2
 

okay i uploaded a new version, i tested it on both the n9 and n950 and it seems to work right. I can set 1200mhz now and it doesn't reset or anything YET. It's almost 2am here so I'm not going to test it any more. I played angry birds for 3 minutes... good enough, right? Anyways, like I mentioned earlier, it only boosts the voltage if you go over 1100mhz.

Re: overclocking kernel modules for PR1.2
 

I can do that for you :)

Re: overclocking kernel modules for PR1.2
 

Well I finally got around to making myself a few simple scripts last night, might as well share I suppose, do with them what you like.
I might add some disclaimers and prompts if I feel like it later.
I assume they aren't appropriate for boot scripts, were only intended for my own casual use anyway, and in fact I'm not even sure what if anything extra is involved with implementing scripts as boot scripts.

You can find them here:
ocScripts-0.01.zip

ocScripts-0.02.zip - what can I say, I got bored.

You can either have your opptimizer_n9.ko and symsearch.ko located in /home/user/MyDocs/Documents/ocmodules-pr1.2/ like mine, or you can edit install.sh to match your own directory structure, this only affects install.sh at this stage anyway.

A description of the individual scripts as follows:
installOC.sh - will copy symsearch.ko and opptimizer.ko to modules directory, ready to be loaded.
uninstallOC.sh - will delete symsearch.ko and opptimizer.ko from modules directory.
activateOC.sh - will load modules via insmod.
resetOC.sh - this was supposed to return frequency and smart reflex to defaults, note that at the time of writing this, the script is pretty much useless and will cause a reboot, it might work down the track, hence why I left it included, but you might prefer to delete this one for now. (removed in ocScripts0.02)

next four are self explanatory....
setFreq1.1ghzSRoff.sh - set frequency to 1.1ghz and disable smart reflex.
setFreq1.1ghzSRon.sh - set frequency to 1.1ghz and enable smart reflex.
setFreq1.1ghzSRoff.sh - set frequency to 1.2ghz and disable smart reflex.
setFreq1.2ghzSRon.sh - set frequency to 1.2ghz and enable smart reflex. (ocScripts 0.02 only)

To run a script via the terminal, simply cd to the directory where the script is located, and run a command like: sh installOC.sh

The correct order to run these scripts if the modules aren't installed would be like this example:
or to just re-enable the overclock after a reboot you would do it like this:
Extra notes of caution:
These scripts obviously use opensh, which itsnotabigtruck correctly opposes, use them at your own peril, anyone with a sense of caution should check for themselves to know there's nothing malicious in them, they're a temporary solution at best but they seem to work for now at least.
I recommend against running a second setFreq script without a reboot as it'll probably result in a reboot itself, just like reset.sh.
These scripts come with a warranty ONLY in HanzBlixLand, for you the warranties simply not valid, sorry.
And finally, any time that Creamy Goodness updates his modules, these scripts are liable to be broken, don't complain, he needs the freedom to adjust the modules however he deems appropriate.