PS3 Question: Using a PS3 clean with just cooling improvements

LoneWnderer

LoneWnderer

Forum Noob
Hi
I'm sure this was asked before but I'm unable to navigate through PSX-Place and find information regarding my situation.

So I have a Super Slim PS3 and my main goal with every game is getting trophies. Therefore I need my system clean cause I don't want to get banned when Im downloading my PSN games or syncing my trophies.
On the other hand I know that from the factory the fan's running at 25% and the software lets the system thermal throttle or die instead of getting louder.

Is there any way for me to have a clean system as well as having the fan go faster? I don't care about the noise. I know it gets loud above 30%.
 
Well, there are a couple of different ways, but both requires hardware

The radical solution (in the sense that you are solving the problem at his root) is to modify the "thermal config" (is a software config). Is an area of data located inside a motherboard chip named syscon, to modify it is needed to buy a UART 2 USB adapter (around 5$) and solder a couple of wires to the motherboard temporally to reprogram it, after reprogramming it you can remove the adapater and 100% of the hardware will remain standard
In this thread we was talking about it, but is not explained how to do it, is mostly intended to discuss and understand how the thermal confgs works
https://www.psx-place.com/threads/syscon-fan-settings-coordinate-graphs.31188/

The other solution is to buy a "PS3 fan accelerometer" (around 20$), this is a device connected in between syscon and the fan. It "boosts" the fan speeds in a percentage of your selection (usually +20% is fine for most PS3 models). As a result the other motherboard components doesnt knows what is happening
 
I thought that the solution will be a hardware mod. Dang it.
Well thanks for the reply, you helped a lot. I think I'll look into the accelerometer kind of workaround. Thanks again.
 
I wonder could @bguerville PS3 Toolset have options to force higher fan speeds on OFW using a web exploit alone. If it was easy to add it might be a useful feature for users like the OP who want to remain on OFW, or for example if someone had an overheating console they wanted to dump some data off quickly. Obviously it would only be temporary until the next reboot but that might suit some people.
 
DeViL303 said:
I wonder could @bguerville PS3 Toolset have options to force higher fan speeds on OFW using a web exploit alone. If it was easy to add it might be a useful feature for users like the OP who want to remain on OFW, or for example if someone had an overheating console they wanted to dump some data off quickly. Obviously it would only be temporary until the next reboot but that might suit some people.
Click to expand...
Unfortunately, I don't think it's feasible without lv2 peek/poke, iirc you can get the temperature ok but to set the fan speed you must change the fan policy and to get/set the fan policy with syscalls I think you must patch the syscall code.

@aldostools
Do you confirm?
 
bguerville said:
Unfortunately, I don't think it's feasible without lv2 peek/poke, iirc you can get the temperature ok but to set the fan speed you must change the fan policy and to get/set the fan policy with syscalls I think you must patch the syscall code.

@aldostools
Do you confirm?
Click to expand...

You're right, to change the fan speed it is required to change the fan policy.
If I recall correctly that is a protected memory area. HEN reimplement the syscalls 389 and 409.

Without that limitation, the code would be something like this:
Code: 
var unknown = 0;
var fan_mode = 2; // manual
var fan_speed = 0x80; // 50%
var SC_SET_FAN_POLICY = 389;
var SC_SET_FAN_POLICY = 409;

var set_fan_policy_offset = 0x800000000000A334; // sys 389 set_fan_policy
var restore_set_fan_policy = peekq(set_fan_policy_offset); // sys 389 get_fan_policy
var enable_set_fan_policy = 0x3860000100000000 | (restore_set_fan_policy & 0xffffffff);

lv2_poke(set_fan_policy_offset, enable_set_fan_policy);
syscall3(SC_SET_FAN_POLICY, unknown, fan_mode, fan_speed);
lv2_poke(set_fan_policy_offset, restore_set_fan_policy);

For that scenario it would be required to install HFW -> HEN -> then run webMAN or FAN control
 
Dang it, Sony and your restrictions!
This solution would be so great and simple(regarding using it, actually coding it could be painful I guess)
 
That's a shame, cos iirc there was a bug at one point where the custom fan speed would stick on HFW even after a hard reboot, I was thinking maybe this bug could be turned into a feature where a higher than normal manual fan speed would be remembered.
 
DeViL303 said:
That's a shame, cos iirc there was a bug at one point where the custom fan speed would stick on HFW even after a hard reboot, I was thinking maybe this bug could be turned into a feature where a higher than normal manual fan speed would be remembered.
Click to expand...

So if I understand, basically:
The setting can't stick because it isn't rewriting the SYSCON code. There's just custom code loaded into the memory when Hen is booting up.

Especially on the Super Slim, all the magic, devs can done is possible by rewriting what's in the memory after booting up everything.

Although... The Syscon is rewritable with touching into it's circuit(as the first reply said)
It somehow should be rewritable through the PS as well, right?
Isn't there a BIOS or a recovery place with that kind of power?
 
LoneWnderer said:
So if I understand, basically:
The setting can't stick because it isn't rewriting the SYSCON code. There's just custom code loaded into the memory when Hen is booting up.

Especially on the Super Slim, all the magic, devs can done is possible by rewriting what's in the memory after booting up everything.

Although... The Syscon is rewritable with touching into it's circuit(as the first reply said)
It somehow should be rewritable through the PS as well, right?
Isn't there a BIOS or a recovery place with that kind of power?
Click to expand...
Yes the syscon is writable from software but you must patch lv1 to get full write access to it and lv1 has not yet been exploited on non CFW compatibles.
 
bguerville said:
Yes the syscon is writable from software but you must patch lv1 to get full write access to it and lv1 has not yet been exploited on non CFW compatibles.
Click to expand...
Right, but it seems thats not enought, i was asking @M4j0r about it here
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-11#post-225275
And later we had another discussion related here
https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-3#post-313614

Then i tryed to represent the syscon EEPROM access "by services" and also indicating the real/virtual offsets of every area in this table, at bottom of this page (still a work in progress because there are many things i still dont understand)
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table

------------------------
The problem is... lv1 only gives access to a range of virtual offsets that doesnt includes the thermal config
Is a bit like the layers of an onion... to access the real thermal config (not the one inside syscon memory that is a volatile copy) is neeeded to patch more services, all this ones are involved with syscon access (im not sure how many of them needs to be patched)
https://www.psdevwiki.com/ps3/Dispatcher_Manager
https://www.psdevwiki.com/ps3/Update_Manager
https://www.psdevwiki.com/ps3/SC_Manager

There are nice descriptions about them, are somewhere related with each other

*As you can see in the table in wiki, the thermal config is located at (real) EEPROM offset 0x3300 for mullion syscons, or 0x250 for sherwood syscons... but there is no "virtual offset" assigned to it (the columns most at right in the table doesnt mentions any virtual offset for it)
 
sandungas said:
Right, but it seems thats not enought, i was asking @M4j0r about it here
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-11#post-225275
And later we had another discussion related here
https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-3#post-313614

Then i tryed to represent the syscon EEPROM access "by services" and also indicating the real/virtual offsets of every area in this table, at bottom of this page (still a work in progress because there are many things i still dont understand)
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table

------------------------
The problem is... lv1 only gives access to a range of virtual offsets that doesnt includes the thermal config
Is a bit like the layers of an onion... to access the real thermal config (not the one inside syscon memory that is a volatile copy) is neeeded to patch more services, all this ones are involved with syscon access (im not sure how many of them needs to be patched)
https://www.psdevwiki.com/ps3/Dispatcher_Manager
https://www.psdevwiki.com/ps3/Update_Manager
https://www.psdevwiki.com/ps3/SC_Manager

There are nice descriptions about them, are somewhere related with each other

*As you can see in the table in wiki, the thermal config is located at (real) EEPROM offset 0x3300 for mullion syscons, or 0x250 for sherwood syscons... but there is no "virtual offset" assigned to it (the columns most at right in the table doesnt mentions any virtual offset for it)
Click to expand...
Yes, you are totally right, there's that too, only part of the eeprom is accessible by lv1 as is anyway, I didn't mention it, I thought it was overkill as lv1 remains inaccessible anyway in the first place.
 
That's confusing for me. cos HEN allows fan control, but HEN does not have lv1 exploited.

I fairly sure I have seen a bug on HEN where the manual fan speed would stick after a reboot, this makes me think a permanent boosted fan speed might be possible on OFW somehow. Does anyone else remember that bug with early HEN versions?

Maybe something like a partial temporary HEN install that deletes itself after doing what it needs to do would be possible, Idk.
 
bguerville said:
Yes, you are totally right, there's that too, only part of the eeprom is accessible by lv1 as is anyway, I didn't mention it, I thought it was overkill as lv1 remains inaccessible anyway in the first place.
Click to expand...
I tryed to sumarize it but i dont understand it well anyway, one of the reasons why i was curious about it is because i was wondering how to design that table in wiki, in some way im representing the access as that concept of the layers of an onion
Lets say... the table have a horizontal row named "thermal config", if you read the content of that row from left to right you are going to find 3 "patch" labels (for "dispatcher manager", "syscon manager", and "update manager"). So visually it looks like is needed to patch the 3, but im not completly sure if this is right

Also, im not sure if there are other alternative ways to access syscon EEPROM (other managers/services) not mentioned in the table, in that case i could try to add them to the table too

This hacks to access protected areas of the syscon EEPROM is something generic anyway (not specifically related with the thermal config) because i guess all the related patches published by @M4j0r are "extending" the available range to cover the biggest EEPROM area posible
 
sandungas said:
I tryed to sumarize it but i dont understand it well anyway, one of the reasons why i was curious about it is because i was wondering how to design that table in wiki, in some way im representing the access as that concept of the layers of an onion
Lets say... the table have a horizontal row named "thermal config", if you read the content of that row from left to right you are going to find 3 "patch" labels (for "dispatcher manager", "syscon manager", and "update manager"). So visually it looks like is needed to patch the 3, but im not completly sure if this is right

Also, im not sure if there are other alternative ways to access syscon EEPROM (other managers/services) not mentioned in the table, in that case i could try to add them to the table too

This hacks to access protected areas of the syscon EEPROM is something generic anyway (not specifically related with the thermal config) because i guess all the related patches published by @M4j0r are "extending" the available range to cover the biggest EEPROM area posible
Click to expand...
I have never tried to read/write to that specific syscon eeprom area, I would assume that both the dispatch manager and the update manager patches will be needed, I am not sure about the other one, but it's likely it's needed too. It's quite easy to confirm that in tests, it would be good to document exactly what each patch enables.

Various other syscalls may read or write to syscon but the greatest majority (if not all) don't let you access it using offsets as arguments, I doubt any of them are really worth the trouble, it's not very likely that they can offer better access than the update manager sc, at the end of the day, at lv1 level they are probably using the same underlying services (DM), I haven't checked them to confirm it though, M4j0r must already know all this.
 
bguerville said:
You only need lv2 peek/poke to modify the fan policy, a lv1 exploit is not required for that part, so HEN can do it, even though there is still that unresolved issue with automatic fan control.
Click to expand...
With lv2 can you still read the CPU temperature and automatic fan control just in case it goes to a certain temp? I've heard that some places are getting hotter nowadays.
 
DeViL303 said:
That's confusing for me. cos HEN allows fan control, but HEN does not have lv1 exploited.

I fairly sure I have seen a bug on HEN where the manual fan speed would stick after a reboot, this makes me think a permanent boosted fan speed might be possible on OFW somehow. Does anyone else remember that bug with early HEN versions?

Maybe something like a partial temporary HEN install that deletes itself after doing what it needs to do would be possible, Idk.
Click to expand...

When all I had was my 3001 when HEN first came out not HAN my fan speeds would stick if I powered down. Now a reboot for some odd reason it would revert back. I know it was on 4.82 but I remember being shocked it would start up at 33% I had set.
 
atreyu187 said:
When all I had was my 3001 when HEN first came out not HAN my fan speeds would stick if I powered down. Now a reboot for some odd reason it would revert back. I know it was on 4.82 but I remember being shocked it would start up at 33% I had set.
Click to expand...

Well, I have HEN 3.1.1 and webMan mod 1.47.42 installed on 4.89 HFW and, the fan stays at 30% whenever I boot it.
Even without HEN being launched.
Of course if I pull it out of the wall it won't start up with 30%, rather the original Syscon setting.

Also thank you, all of you for thinking it through and detailing why it would and wouldn't be possible. I thought my thread will end with a, *you can't do that lol* then fades into oblivion. Although it seems impossible rn as well to fix the fans permanently through only software. Still there should be a way.
 
It's strange, seems kind of like the memory used to store the fan speed is not overwritten when shutting down the console, as long as the console left in standby.

Does anyone understand what is happening there? I wonder could this behavior be exploited somehow.
 
You must log in or register to reply here.

Similar threads

Back
Top