[RELEASE/UPDATE] CFW 3.55 - 4.66 Fan Control Utility v.3.0.5

Zitat

Übersetzung von STLcardsWS auf PSX-Scene.com

{Update #1} Fan Control Utility v1.0 (4.31 and 4.40 CFW CEX)

a little late, but I just uploaded version 1.0

- First, I found a bug in the payload, by a jump I deleted and without realizing what he was doing was that if he found the flag "IN_USE" post, deactivated when leaving (which can cause the console that hang when accessing the user RAM writing, is otherwise engaged not to write)

Between that and now I have slightly modified the "message" of the event to test, I have been working as eight hours, many of them in a game I petó a few minutes with version 0.3 (and that gave him more time for the event) and now looks perfect.

To try to reduce the impact of the temperature reading, I duplicated the time of the readings, since it is not anything to lengthen it happens a little more.

- On the other hand, I have taken the trouble to find the patches for 3.41, 3.55. 4.21 and 4.30 also. I hope I was not mistaken in some, there are many to seek [+risas]

- I have also changed the theme video, full screen setting, see if any of your TVs is pijotera with the signal, adjusting text coordinates to avoid as far as possible, that "I eat" part of the text according to television (on mine to 1:1 edge looks, but to 16:9, for example, the letters are stuck to the left, some video modes do they have: "eat" a piece of the screen to prevent those edges on devices that generate them). I've added a background color to have "consistency" as there are some devices that do not get along with the black backgrounds (eg tube)

- In mode 2, I have the possibility that if you press START, creates a file that remembers the last set speed, to keep them, to walk fixing it each time (now simply change mode)

And now let's go by parts:

- Let the peleitas, please: that each console refrigerate how he pleases.

- Mode 2 is not for tomároslo lightly and I will put an example: as temperatures have risen, I have the TV, the PS3 and PC, you do not exactly cool. yes that during the time I've been playing with the payload, have exceeded 70 ° several times and for a while. When that happens, between speed 0x70 and if you reach 72, the 0x78 until reaching 75 ° (and hence skip the last speed 0xA0 is not high, but it is more than enough to cool the console with a good noise )

Well, when I left I returned directly to the application and showed me 63 º C on the CPU and 55 ° C in the RSX, because when you stop working at top, the temperature drops rapidly and if the speed is not slow.

The problem is that reaching those temperatures, 0x60 and 0x68 indicates that not enough at that time to keep the temperature below 70 degrees, plain and simple.

So I repeat, Mode 2 is for situations where you really have no other choice, but it would be advisable that before, probarais in some extreme situations, such as responding to the temperatures the payload to the application.

Note that if I had thought to Mode 2 and a high average speed, enough, I would not have bothered to make a payload (or polish everything I can, as I am doing) in order to monitor temperatures and make adjustments based on them.

Oh and by the way: not a "bug" that the application does not let you out at a rate below the minimum safe I consider Mode 2 (if it is explained in the first post ). And by the way, do not think it's a "bug" the black screen when my never happened that : Will anything of your TVs, but good [+risas] (If indeed any has already said that with the SLIM had no problems, but the compiler bug that happened today one thing rarer than a green dog)

Let me know that you are such changes.

Regards

Alles anzeigen

Zitat

Original von DEFAULTDNB auf PS3Hax.net

[RELEASED] Estwald's Fan Control Utility v0.3

First of all, I open this thread here because it is a very specific firmware modification (working on CFW 4.40 and 4.31), intended primarily to work under the environment of the games. It is not a simple adjustment of the fan speed, if not a payload that does the job regulating the fan speed depending on the temperature of the system, to try to avoid excessive overheating possible. For that reason I open it here and not in Scene, which also could be accommodated ..

The thread will have two purposes: first, to expose the development, research and the contributions themselves or you do you and on the other hand, the practice for those who just want to use the utility.

Let us begin by the development (if someone is not interested, jump to "The Aaplicación Fan Control")

Development: Research and Description

How I said in another thread, there is a call sys_sm_set_fan_policy syscall () that lets you control the ventilation. Specifically, I found that has at least 3 modes of operation are summarized in:

sys_sm_set_fan_policy (0, 0, 0) / / fan on full (speed 0xff)

sys_sm_set_fan_policy (0, 1, x) / / fan controlled by the SYSCON (the x does not seem to be used directly or is ignored by that autotune, but may also be factors when restarting / shutting down the system)

sys_sm_set_fan_policy (0, 2, x) / / manually controlled fan.

This latter mode, the 2, which interests us: the x is moved in the range of 0x33 (lower values can be written, but is automatically corrected in the SYSCON) to 0xFF, it would be full power. This mode has its dangers, if not handled properly, since for example, if we adjust 0x33, speed is insufficient and the temperature will reach dangerous temperatures. So careful with this.

It appears that when you restart the system, the SYSCON changes to Mode 1 but the console off (red light) Mode 2 but still sets the value SYSCON 0x4D, how security measure, surely, because with this value Console cooling maintains acceptable levels.

In fact the SYSCON uses much lower values, usually. That I have seen, starting with the least 0x33, then up to 0x40, 0x44, 0x48 and rarely goes there, that the SYSCON operated in the range of 70 ° to 75 ° in the FAT (at least in mine), you seems acceptable and prefer less noise and higher temperatures, when we may want us otherwise.

All this can be seen by sys_sm_get_fan_policy syscall () which has five parameters that I have called like this:

- Id is 0

- St and mode: reflect the current mode

- Speed: as the name suggests, reflects the value x of speed that we or the SYSCON adjusted, depending on mode.

- Unknown: I've seen (and you through this application) is always 0: I do not know if you have a specific use.

This syscall use it solely for informational purposes in the utility, but the payload does not use it.

Once we can control the fan speed, the following, but not least, we want to know the temperature regularly.

To do this, we sys_game_get_temperature syscall () that receives as first parameter 0 if we want to measure the temperature of the CPU and 1 for the RSX, while the second parameter is a variable that will store the value of temperature.

Finally, while decoratively, we use the sys_set_leds syscall () which allows us to put the LEDs in the state we want.

The problem with these is that they require syscalls type of permit applications and especially our games do not usually have: some require flags PM how related fan and other ROOT permissions. So no choice but to disable these checks by "pokes" like this:

and that is the reason that the utility is limited to those CFW: missing required patches for the other XD.

Well, with everything said so far, you can mount an adjustment application modes at will, which can be fine if you only adapts the fan at a fixed speed and you're (in the style of those who do the mod potentiometer), but if we want something more "adjustable" then it gets tricky, because it requires that our code is running at system level and that required by the chosen route, make a payload and click some syscalls.

The Payload

And you should do the payload?. Well, in principle, be sampled for temperature, fan speed adjustment, if applicable, and then somehow notify us (via LED) if the temperature is within the parameters and such.

So that sounds easy, but how do we do this and how we find out that syscalls click?

Initially, I opted for the syscall click usleep () but that option was not being good at the end and I had to resort to another, which is what I will describe below (and prestadle attention, which is important XD)

First of all, you should know several things or at least, is what I was (if anyone knows other things that we tell)

- Applications run in user mode and when you call the syscalls, enter supervisor mode, kernel, LV2 or call it what you like.

- Applications use virtual memory, so we can not be sure if a particular memory block is mapped or worse, to allow scripts.

- Any attempt to pass LV2 memory of how variable will return with an error or simply ... not return

- Within LV2, just know that when a given syscall, use variables between their parameters. Which has its problems, if we need to use only receive values, but no usable memory address. So we need to acquire such information indirectly and that's a mess XD.

- Obviously, if we get a memory area that can "change" we need to ensure that the modification does not affect, or facing the application, data has not been modified (ie preserving the values)

- Well, our syscall to measure temperature, requires a varying ***** and that raises these difficulties.

- On the other hand, within LV2 can call certain syscalls or more specifically, the functions that handle these syscalls, but others can not (for example, block access to file system if, for example, do an open and then a read, without leaving to user mode)

With all these problems, we need a syscall above is called regularly in order to make our readings / settings and I had to discard usleep ().

The "salvation" came in the form of events: system events allow us, how its name suggests, receive events within the system, receiving a data series.

The sysEventQueueReceive syscall () is in charge of receiving and also provides a variable that can be used for temperature measurement. The syscall in its last parameter specifies the time in microseconds during which an event wait (0 means infinite).

One thing to keep in mind is that this syscall get ALL events that occur via applications and it is quite possible that while we are processing one event is received ANOTHER, if we delay in our work, so should be protected against them.

In fact, the required temperature takes between 7ms and 20ms and I ran into problems, because it exceeded the speed of response. at one point, causing a blockage.

So I changed my strategy and tried to figure out where the events were generated to whether to produce delay, was there and not in the receiver. To all this, I have to say I do not even know firsthand WHO, WHERE AND WHY generates events: simply, is that something generates events in cadence enough to allow me to do my reading and that the nature of these events occur in the XMB , in games, in the PSX emulator and the PSP. In PS2, at least in the hardware backwards my PS2 not, because the LV2 we know disappears and with it, my payload

There are several ways of producing events, but the most accessible, are the EventPort.

Prodding could see that indeed, is the origin of the calls. The sysEventPortSend syscall () sends in the records the following information

How we see, no variables, only data, which we still need the help of sysEventQueueReceive () for a variable that can be modified.

The problem is that changing the caller should do in and not in the call, which is the variable that receives the program. That is, we need the hen to lay an egg, but no goose egg until birth [smile]

To jump that hurdle, I resorted to PID: if we know the process ID, we can compare, if sending and reception are in the same process and can therefore spend the goose egg from the chicken itself [F]. Or for not rolling the matter, pass sysEventQueueReceive variable () for use by our procedures sysEventPortSend () (it is also necessary that in principle, we do not know if the recipient ESE EventPort how QueueReceive tended, because it relates to indirectly with the event!)

Perfect, done that, through safety checks of the respective PIDs, we can ensure that "mem_app" (in the payload) contains a script memory address we can use.

Once we close the circuit and see that it works, we are interested in discriminating try to find events that we find useful and discard others that are not and can only lead to problems. Doing several tests, it turns out that the reception is not lockable event (ie, it has a time limit) and that the event is generated and received, useful, has all the data to 0 (typically, an event data contains a number of useful and necessary information for programs. For example, device-related events, receive the kind of device in data2).

Now we need to do two things: if our events have a shelf life and short response capacity on the one hand, we need a time base to know how often read the temperature, etc., without ballast system and we also need to divide tasks perform to fulfill their duties without ballasting the system.

After successes and hardships, in the end, Timebase use a processor register (note: supposed to be one with that role, but no idea as used in CELL [F]) that counts the ticks from system boot (with that we can know how long it takes the console powered XD. Indeed, in the utility show that information as "PS3 Start Time")

The time base used, no idea [F]. What I did in the end, is to make a couple of loops combined with real time clock sync first and then take a reading for 60 seconds with which to get the ticks per second are generated. The figure: 79,799,997 0x4c1a6bd or as you please. Nor need ciborium accuracy, just something that has a reasonable time [F]

If anyone is curious to know how you get the ticks, this is the function:

Code: Select all

It is assumed that at one point may give zero and should be entering loop until a valid reading. In fact, in the payload is done:

In this case, I use a 12-bit offset from the right to obtain a number of ticks with which to compare in a "reasonable" from assembler

In the end, the routine works like this:

- Divide the tasks so that first one gives a temperature reading that alternates between CPU and RSX. This task is time consuming in terms of events which is important divide

- How second task is to look if you need to correct the temperature and adjust the LEDs (which most of the time, you do not need)

- The timer is set to answer every 1.5 seconds. That is, the process of measuring the temperature of the CPU and make adjustments, it takes three seconds and as many for the RSX, so the total is 6 seconds, which is a good number.

- This timer can be skipped if time expired but could not produce a temperature reading that do not match or mem_app PIDS is zero.

- The PIDs are set to zero at certain times after use to prevent problems (remember we talked about syscalls that are used by the system and we ALL cases where results in chicken egg and goose egg results and sometimes, the chicken and egg dies at birth, mother was wrong and mess up [F])

- A very important detail that I have not mentioned is that to avoid a number of problems, I am forced to send BEFORE the event (ie pass the syscall) the actions I'm doing so I can not be sure whether the system, remember that supports two hardware threads and such, can be recepcionando the event as one thinks that until the syscall exit nothing happens. These thoughts "single-tasking" which usually incur, can make us steal the wallet and did not even have noticed. So, I try to cover my flag "IN_USE" so also are ignored calls that may be problematic (in fact, many ignore and the use of counter ticks)

In the main, this is the operation, one encounters problems and how to solve them on the fly: does not have to be the right or wrong approach, but simply, is how I have solved the problem and interestingly, not based on what he knew, if not based on what is not and I discover on my own.

Use the Payload

A feature of the payload is allowed to be located in any part of the system has been chosen for LV2 0xF70 address (remember that we must add a 0x80 .... 000 to form the 64-bit address) but could stay in any other part (using the method write_htab () included in Iris Manager source, we enable execution of prohibited parties LV2) and is compatible with any CFW theoretically.

As I said before, the patches to enable the syscalls that require permits, are the reason that this occurs for CFW 4.31 and 4.40.

In fact, I've only tested on 4.40 so hope I have not messed with 4.31 parts

In the application, load_ps3_controlfan_payload function () loads the payload uniting the different syscalls (the loop and sleeps are to "ensure" that the payload is loaded fine)

The beginning of the ID payload contains 'PFAN' (0x5046414E) in the first 4 bytes. The following 4 bytes contain the offset into the payload (under this point of view, the payload starts at 0) where to find the data fan_control.

All data mentioned below are 32 bits:

In fan_control - 8 bytes can change the speed current comparator (this is only useful if you disable the payload, and you want to re-enable, causing it to update).

In fan_control - 4 can disable or enable the payload: 0 -> disabled, 1 - enabled without leds and 2 - with leds

In fan_control + 0 we can adjust the speed to be set if you call the sys_sm_shutdown syscall () to something other than a Reset or Normal shutdown (for example, when you turn the PS2 emulator on the console backward compatible, at least). 0x5F is assumed that the velocity is sufficient (in fact, high) to avoid problems, but of course, everything depends on the ambient temperature and what warms your PS3 [F]

This syscall is operated for otherwise, set the Mode 1, with the idea of dotaros of some extra protection if not re-activate the application (if in that case, is in Mode 2, lack of regulation and depend on enough that the speed 0x4D)

From fan_control + 4 (inclusive) is the speed table that relate to temperatures temp_control4 temp_control0

Temperatures (all in ° C) temp_control0 to temp_control1 make a range in which you consider if temperatures started below temp_control0 and going up or going down from temp_control1 (if is getting warmer, the speed is less than if seeing the need to cool)

temp_control2 is a gear change while temp_control3 represents the turning point. In the default case of 70 ° the LED will blink yellow / green if the temperature is greater than or equal to 70 °

temp_control4 represents temperature alarm: in this case, the LED will flash in "disco" (yellow, red and green) and the speed is set to 0xA0, which is pretty cool noises and [F]

An important detail every 11-12 seconds or so, the green LED illuminates for 1.5 seconds (unless you are in emergency room). It is the form that has the payload must say that is working (especially if it shows solid yellow LED)

And I do not think I miss anything important in this section (the source has enough payload comments)

Fan Control Application

The application is quite simple (if anyone wants to compile, you can use this build environment hilo_psdk3v2-windows-ps3-sdk-with-psl1ght-v2-tiny3d-and-ps3-soundilb_1867760) and displays in text form all information.

Just start mode is set to "# Payload" which is what we've been talking.

The information displayed is as follows:

CPU temperature / RSX temperature and elapsed time since the PS3 on

Parpedearán Temperatures in yellow when they reach 70 degrees and red when reaching 75 degrees

sys_sm_get_fan_policy here indicates the mode and speed that has set the SYSCON

Current Mode Indicates the current mode and set fan speed (mode 2 and payload)

Modes are summarized below. In Mode 2, with UP / UP speed climb and DOWN / DOWN bring it down. Remember that mode 2 is a mode with fixed speed and does not vary with temperature. Mode 1 is the normal system.

To switch modes using SQUARE / SQUARE and will change upstream (that allows for example, set a very low speed in Mode 2 for the hot console and then activate the Payload mode to see how it responds XD)

With the TRIANGLE button exits the application. I recommend to use this button to exit and not from PS

Application Protection

- From the Payload mode, anti-shutdown protection, to set the protection mode

- If you turn off the console in Mode 2, is retained when you turn it on, look at this, even in principle, set a speed SYSCON supposedly taken.

- The SYSCON corrects the values set below 0x33. Still, it has limited 0x30 Mode 2 to a minimum and how low speed when 0x4D flash blue Current Mode

- If you leave the application in Mode 2, the minimum speed is set to 0x5F, regardless of which had been fixed (by way of security and the Mode 2, it should not be fixed, unless it is intended the fan is working at high speed and in that case, the correct minimum is: p)

- Regardless of the mode, if the temperature is greater than or equal to 80 degrees, 0 mode is activated until the temperature falls below 60 degrees (when linking Payload Mode) or cambiéis yourself so when the temperature lower that limit.

How you see the application has a security system to prevent fried let the console, regardless of the protections you can have the system. Let me know what you think the issue (probably finished integrating it into Iris Manager, but for now, we're in beta)

Alles anzeigen

Zitat

Original von MO3
[b]psXtools CFU MOD v1.9.2