Reply
Thread Tools
Posts: 245 | Thanked: 915 times | Joined on Feb 2012
#81
Originally Posted by Creamy Goodness View Post
I thought about it and realized I have no idea how to pass a command to opensh to execute.
The module itself isn't even stable, I am trying to figure out why the phone crashes when switching back to 1ghz or other known safe frequencies. Until I finish all the required work on the module, I won't waste time to package this. It's really just proof of concept at this point.

Oh yeah, I should point out everything I know about linux was learned on a Nokia device or software. I don't know C either, I was just determined to get some app written in C working better on the n900. I never compiled a kernel before last week. My point is you don't have to be an expert to accomplish something. We seem to be low on experts here, so I'm hoping some of you guys can step up soon. I made this open source for a reason
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)
 

The Following 2 Users Say Thank You to itsnotabigtruck For This Useful Post:
Posts: 153 | Thanked: 81 times | Joined on Oct 2011 @ New Zealand
#82
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.
 
Posts: 1,463 | Thanked: 1,916 times | Joined on Feb 2008 @ Edmonton, AB
#83
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...
 
Posts: 313 | Thanked: 247 times | Joined on Jan 2010 @ USA
#84
Originally Posted by Creamy Goodness View Post
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...
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
 
Posts: 1,463 | Thanked: 1,916 times | Joined on Feb 2008 @ Edmonton, AB
#85
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.
 
Posts: 313 | Thanked: 247 times | Joined on Jan 2010 @ USA
#86
Originally Posted by Creamy Goodness View Post
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.
n9 table is omap36xx_vdd1_volt_data not 34xx
 
Posts: 1,463 | Thanked: 1,916 times | Joined on Feb 2008 @ Edmonton, AB
#87
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.
 
Posts: 1,463 | Thanked: 1,916 times | Joined on Feb 2008 @ Edmonton, AB
#88
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.
 

The Following 5 Users Say Thank You to Creamy Goodness For This Useful Post:
Posts: 110 | Thanked: 62 times | Joined on Mar 2012
#89
Originally Posted by Creamy Goodness View Post
I will try to improve stability of the module, and add more features. I was hoping someone else can start work on a script that we can install to init.d to load the module on boot.
Are you saying you would like to help write a QML & C++ interface to the /proc/opptimizer sysfs? Just please upload source to https://gitorious.org/ if you want help. I'm not sure how to install the modules automatically yet so I don't suggest to start with that.
I can do that for you
 

The Following User Says Thank You to pipould For This Useful Post:
Posts: 153 | Thanked: 81 times | Joined on Oct 2011 @ New Zealand
#90
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:
Code:
sh installOC.sh
sh activateOC.sh
setFreq1.1ghzSRoff.sh
or to just re-enable the overclock after a reboot you would do it like this:
Code:
sh activateOC.sh
sh setFreq1.1ghzSR.sh
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.

Last edited by HanzBlix; 2012-04-05 at 16:49.
 

The Following 2 Users Say Thank You to HanzBlix For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 21:11.