forums.ps2dev.org

[aeolusc]

Here's some test result(Set bus clock to 50):
Function/Result
scePowerSetClockFrequency(in both scePower and scePower_driver)/Bus clock reset to about 95
scePowerSetBusClockFrequency(in both scePower and scePower_driver)/Bus clock's still 111
sctrlHENSetSpeed/Bus clock reset to about 95

It seems system or M33 driver locked bus clock minimum value to 95?

PS: the sceSysReg series function nids are changed without known alias so that i cannot test them

[J.F.]

It's worse... with the MediaEngine running, trying to change the clock freezes the Slim. I'm still trying to figure out how to turn the ME off to change the clock. I posted a request for the nid for disabling the clock to the ME, but no response yet. I tried getting the value myself, but I don't know if it was correct.

Anyway, the set clock function also ignores calls with paramters it doesn't like. For example, scePowerSetClockFrequency(333, 333, 167) is ignored completely, while scePowerSetClockFrequency(333, 333, 166) works fine. That's why the clock doesn't change on some homebrew - the values they send are no longer acceptable. One rule I found - round down when dividing by two.

[aeolusc]

scePowerSetClockFrequency rule:
pll>=cpu>=bus*2
so if you set bus to 167, cpu should be at least 334

PS: i heard that pll&cpu could be set to 366 on slim, xD

[J.F.]

I've seen code that rounded up instead of down, and those will all be ignored on the Slim. I hadn't really thought about it until I noticed that programs weren't changing speed and did some experimenting on my own.

[sakya]

Hi! :)

I'm having problems with scePowerSetBusClockFrequency (only in kernel 3.71)
I used the following code to test CPU/BUS combination.
In kernel 3.52 all the combination are valid, but in kernel 3.71 the bus is always at 111.
I thought the values that follows the rule pll>=cpu>=bus*2 should work.

[aeolusc]

if you import function in c++, please add

[sakya]

Hi! :)

[sakya]

Hi! :)

[J.F.]

[aeolusc]

disasm sctrlHenSetSpeed, translated to C codes:

[moonlight]

you have disassembled more than that function and you have gone through the slim usb charge code. Since the function is not called directly, but is done through a systimer, probably prxtool couldn't detect it as a function. (that's something tyranid has to look ;), and you thought it was part of same function.

Btw, those functions nids prior to 3.71 were:

0x733F973B -> scePowerBatteryEnableUsbCharging
0x90285886 -> scePowerBatteryDisableUsbCharging

I'm attacking power.prx with the nidcracker today, 7 results atm :D

[sakya]

Hi! :)

[J.F.]

Here's my test program. It shows that the bus clock does change, but has a very limited range on the Slim. If you always try to set the clock(s) using scePowerSetClockFrequency(cpu, cpu, cpu/2); the cpu clock will basically follow whatever value you're passing in. the bus clock will change as well, but not as widely as the cpu clock. The mimum value for the bus seems to be 95, and the maximum 166. The cpu clock will go down to 18 (with the bus staying at 95), and I've gone up to 333. I haven't tried going beyond 333, but I've heard the slim will go farther.

[sakya]

Hi! :)

[J.F.]

[jas0nuk]

Does the clock change properly, using a Slim under Pandora (you might need to use 2.71 power.prx)?

[Kreationz]

I have a quick question. I'm likely doing something stupid and not realizing it.

Like this I can hit Home and exit fine:

[Torch]

ExitDelete useless threads, don't sleep them.

[Kreationz]

Well, I don't plan on sleeping the thread in the final version. This is just a basic test.