PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

sandungas said:
You know... using vehicles as example... we have a car (the fan) with 2 drivers (CELL or RSX) and we need to find who is driving the car... and adjust the "tempU" values to dont allow the same driver to drive the car all the time
Click to expand...
Nice analogy hahaha. But this car actually has 3 drivers!
CPU, RSX and the often forgotten SouthBridge.
And the car is smart too. It will only change speed if certain rules are met:

All 3 drivers need to agree in order for the speed to go lower.
But to accelerate, a single driver is enough!
And also the smart car reserves the right to disregard nonsensical orders and avoid crash.

This seems simple but in practice makes the car very robust and safe!
Perhaps this belongs more in my thread about modifying SYSCON fan curves, but in general is OK to experiment I think.

https://www.psx-place.com/threads/modifying-syscon-fan-settings-better-than-webman.34626/

After all Sony didnt pay too much attention and reused the old settings haha, but the system allows for great customization!
 
9KoyvnR.png


So for example, at SYSCON eeprom offset 3300 00 the bit is 33 (0x33). That corresponds to 20% fan duty cycle. But 33 is 51 in hexadecimal. So it's not that simple.

What am I missing?

If I wanted to change the first stage from 20% to 25% I can see it's 0x40, but I have no idea wht it would be if I wanted 23%.

EDIT:
I just figured it out.

FF is 100%, but the hexidecimal system goes from 0-255. 20% of 255 is 51. So to get my example fan speed of 23% I'd just multiply 0.23 x 255 = 59, which in hexidecimal is 0x3b.

Just to check I'm right:
0.20 x 255 = 51 converts to 0x33
0.25 x 255 = 63.75 converts to 0x40 (when rounded up to 64)
0.28 x 255 = 71.4 converts to 0x48 (when rounded up to 72)
0.30 x 255 = 76.5 converts to 0x4d (when rounded up to 77)
0.35 x 255 = 89.25 converts to 0x5a (when rounded up to 90)
0.40 x 255 = 102 converts to 0x66
0.45 x 255 = 114.75 converts to 0x73 (when rounded up to 115)
0.50 x 255 = 127.5 converts to 0x80 (when rounded up to 128)
0.60 x 255 = 153 converts to 0x99
1.00 x 255 = 255 converts to 0xff

Looks like SONY is rounding up to the nearest integer by convention. They do not round down.

EDIT 2:
No, I was doing it backwards. I was looking at @sandungas's fan curve, but he was rounding the fan %. I was trying to convert 100 fan %'s into Hex, but the better way to do this is to convert the 256 division into a percentage. This gives you more graduations to choose from anyway.

Here is the corrected table...
Fan%PrefixHexadecimal
0.0%0x00
0.4%0x01
0.8%0x02
1.2%0x03
1.6%0x04
2.0%0x05
2.3%0x06
2.7%0x07
3.1%0x08
3.5%0x09
3.9%0x0A
4.3%0x0B
4.7%0x0C
5.1%0x0D
5.5%0x0E
5.9%0x0F
6.3%0x10
6.6%0x11
7.0%0x12
7.4%0x13
7.8%0x14
8.2%0x15
8.6%0x16
9.0%0x17
9.4%0x18
9.8%0x19
10.2%0x1A
10.5%0x1B
10.9%0x1C
11.3%0x1D
11.7%0x1E
12.1%0x1F
12.5%0x20
12.9%0x21
13.3%0x22
13.7%0x23
14.1%0x24
14.5%0x25
14.8%0x26
15.2%0x27
15.6%0x28
16.0%0x29
16.4%0x2A
16.8%0x2B
17.2%0x2C
17.6%0x2D
18.0%0x2E
18.4%0x2F
18.8%0x30
19.1%0x31
19.5%0x32
19.9%0x33
20.3%0x34
20.7%0x35
21.1%0x36
21.5%0x37
21.9%0x38
22.3%0x39
22.7%0x3A
23.0%0x3B
23.4%0x3C
23.8%0x3D
24.2%0x3E
24.6%0x3F
25.0%0x40
25.4%0x41
25.8%0x42
26.2%0x43
26.6%0x44
27.0%0x45
27.3%0x46
27.7%0x47
28.1%0x48
28.5%0x49
28.9%0x4A
29.3%0x4B
29.7%0x4C
30.1%0x4D
30.5%0x4E
30.9%0x4F
31.3%0x50
31.6%0x51
32.0%0x52
32.4%0x53
32.8%0x54
33.2%0x55
33.6%0x56
34.0%0x57
34.4%0x58
34.8%0x59
35.2%0x5A
35.5%0x5B
35.9%0x5C
36.3%0x5D
36.7%0x5E
37.1%0x5F
37.5%0x60
37.9%0x61
38.3%0x62
38.7%0x63
39.1%0x64
39.5%0x65
39.8%0x66
40.2%0x67
40.6%0x68
41.0%0x69
41.4%0x6A
41.8%0x6B
42.2%0x6C
42.6%0x6D
43.0%0x6E
43.4%0x6F
43.8%0x70
44.1%0x71
44.5%0x72
44.9%0x73
45.3%0x74
45.7%0x75
46.1%0x76
46.5%0x77
46.9%0x78
47.3%0x79
47.7%0x7A
48.0%0x7B
48.4%0x7C
48.8%0x7D
49.2%0x7E
49.6%0x7F
50.0%0x80
50.4%0x81
50.8%0x82
51.2%0x83
51.6%0x84
52.0%0x85
52.3%0x86
52.7%0x87
53.1%0x88
53.5%0x89
53.9%0x8A
54.3%0x8B
54.7%0x8C
55.1%0x8D
55.5%0x8E
55.9%0x8F
56.3%0x90
56.6%0x91
57.0%0x92
57.4%0x93
57.8%0x94
58.2%0x95
58.6%0x96
59.0%0x97
59.4%0x98
59.8%0x99
60.2%0x9A
60.5%0x9B
60.9%0x9C
61.3%0x9D
61.7%0x9E
62.1%0x9F
62.5%0xA0
62.9%0xA1
63.3%0xA2
63.7%0xA3
64.1%0xA4
64.5%0xA5
64.8%0xA6
65.2%0xA7
65.6%0xA8
66.0%0xA9
66.4%0xAA
66.8%0xAB
67.2%0xAC
67.6%0xAD
68.0%0xAE
68.4%0xAF
68.8%0xB0
69.1%0xB1
69.5%0xB2
69.9%0xB3
70.3%0xB4
70.7%0xB5
71.1%0xB6
71.5%0xB7
71.9%0xB8
72.3%0xB9
72.7%0xBA
73.0%0xBB
73.4%0xBC
73.8%0xBD
74.2%0xBE
74.6%0xBF
75.0%0xC0
75.4%0xC1
75.8%0xC2
76.2%0xC3
76.6%0xC4
77.0%0xC5
77.3%0xC6
77.7%0xC7
78.1%0xC8
78.5%0xC9
78.9%0xCA
79.3%0xCB
79.7%0xCC
80.1%0xCD
80.5%0xCE
80.9%0xCF
81.3%0xD0
81.6%0xD1
82.0%0xD2
82.4%0xD3
82.8%0xD4
83.2%0xD5
83.6%0xD6
84.0%0xD7
84.4%0xD8
84.8%0xD9
85.2%0xDA
85.5%0xDB
85.9%0xDC
86.3%0xDD
86.7%0xDE
87.1%0xDF
87.5%0xE0
87.9%0xE1
88.3%0xE2
88.7%0xE3
89.1%0xE4
89.5%0xE5
89.8%0xE6
90.2%0xE7
90.6%0xE8
91.0%0xE9
91.4%0xEA
91.8%0xEB
92.2%0xEC
92.6%0xED
93.0%0xEE
93.4%0xEF
93.8%0xF0
94.1%0xF1
94.5%0xF2
94.9%0xF3
95.3%0xF4
95.7%0xF5
96.1%0xF6
96.5%0xF7
96.9%0xF8
97.3%0xF9
97.7%0xFA
98.0%0xFB
98.4%0xFC
98.8%0xFD
99.2%0xFE
99.6%0xFF
 
Last edited:
You need to convert it to decimal, multiply by 100, divide by 256... and round it
0x40 = (64*100)/256 = 25%
0x80 = (128*100)/256 = 50%
0xC0 = (192*100)/256 = 75%
0xFF = (255*100)/256 = 100%

0x33 = (51*100)/256 = 20% <--- this value is used for the min_duty in all/most PS3 models
0x4D = (77*100)/256 = 30% <--- this value is used for the initial_fan_duty in most PS3 models



EDIT:
------------------
And here is other of that "sony engineers favourite rules" i was mentioning in other thread...
The value of "initial_fan_duty" should be a bit higher than the "min_duty"

Here we have a bit of freedom when considering if sticking to this rule because we know how it works
If you configure both with the same speed... then you are removing this initial fan boost that happens in the first 5 seconds inmediatly after booting the PS3
If you set "initial_fan_duty" lower than the "min_duty" is going to work as an additional speed, lower than any other speed
 
Last edited:
RIP-Felix said:
9KoyvnR.png


So for example, at SYSCON eeprom offset 3300 00 the bit is 33 (0x33). That corresponds to 20% fan duty cycle. But 33 is 51 in hexadecimal. So it's not that simple.

What am I missing?

If I wanted to change the first stage from 20% to 25% I can see it's 0x40, but I have no idea wht it would be if I wanted 23%.
Click to expand...
33 is 51 in hexadecimal but 51 is not 51 of 100 (not 51%)
It is 51 (0x33) of 255 (0xFF) (about 20% yeah)

For 23% would be something like 3A or 3B... As you can see it is not going to be exact. There are more hex steps in between...

However I would not be changing fan "speeds" just like that based on numbers. If you are going to use non-standard fan speeds on purpose, better have a good reason to do it. Use your ears to see which are actually comfortable or useful. Test them on the fly. For example I liked 0x47 and 0x54 so I added those steps to my fan curves

(Which by the way everyone is welcome to try, I didnt make them with frankenstein specifically in mind, but they should work well anyway since the CPU is still the main driver)

Edit: I see we all posted at once hehe
 
Last edited:
Haha...yes, I was forgetting to count 0. Nevermind, SONY rounded the result to the nearest interger, not up. I was the one who had to round up, cuz I was doing it wrong.

EDIT,
Actually no. If you go by 256 then the resulting rounded numbers are wrong. Because 256 in hex is 100. 100% fan is FF, which is 255 in decimal.

So the way I did it was to multiply by 255 then round up the result to the nearest integer. Then the hex of that decimal comes out correct over the entire table from 1-100%. See edited post above.

EDIT2:
Okay no I'm an idiot. I was just going about it all wrong. It's better to just start with 0 - 256 and convert to hex. Then devide each of the 255 divisions by 256 to obtain the fan%. I was doing it the opposie direction Fan precentage to hex when I should have been doing it from Hex to fan%.
 
Last edited:
Is there a way to manually set the fan% regardless of the temperature reading? I want to be able to test a bunch of fan% manually and hear the sound they make without the console automatically bumping it up.
 
To do the conversion in the opposite direction (decimal to hex) you need to revert the formula but you need to do the math operations in hex
hex = (decimal*100)/256
decimal = (hex*0xFF)/0x64

20ºC = (0x14*0xFF)/0x64 = 0x33
30ºC = (0x1E*0xFF)/0x64 = 0x4C


The roundings are weird... im not sure which rules are used by syscon for the roundings, sometimes it can be deduced by looking at the output of the uart commands because what we see in the uart interface related with temperatures and speeds is converted to "human readable format"... this includes this roundings
 
Last edited:
RIP-Felix said:
Is there a way to manually set the fan% regardless of the temperature reading? I want to be able to test a bunch of fan% manually and hear the sound they make without the console automatically bumping it up.
Click to expand...
With the command "fanconpolicy" but the sample in wiki about how to use it is not complete
https://www.psdevwiki.com/ps3/Syscon_Firmware#Internal_commands

fanconpolicy
get/set/getini/setini
0=Full, 1=Auto, 2=Manual

Usage: fanconpolicy get fanconNo
ex. fanconpolicy get 1
Click to expand...

In the sample is only needed to indicate the "fanconNo" because we are reading it
But if we need to change it we need to indicate the "fanconNo" and also the new "status" and the "duty" so it should be something like this, where 0=CELL, 2=manual, 80=duty
"fanconpolicy set 0 2 80"

Dunno, i never used it, btw im suggesting it do it with "set" because this way you are writing in syscon ram (not permanently)
 
This worths another post...
In wiki there is other command named "fanservo" reported as "does nothing" but im wondering if is needed to use in a special sequence and/or under special conditions, so i suggest to try this:
"fanconpolicy set 0 2"
"fanconpolicy set 1 2"
"fanconpolicy set 2 2"
"fanconpolicy set 3 2"
"fanconpolicy set 4 2"
"fanservo 80"

The fanconpolicy commands changes the status of all the fan tables to "manual" (in ram), from this point the fan speed is not dependant of them, i guess it will keep the current speed whatever is it when you run the commands
And the last command fanservo should change the fan speed... and you can repeat it as many times you want with different speeds to check the noise levels
After a reboot everything should return to normality the "policy" of the fantables returns to "auto" and the fan speed is dependant of them

*This post is speculative, i dont know if it works this way


---------------
EDIT:
Hmmm, or maybe is this way, pretty much what i was trying above, but using the fanconpolicy command in a different way (with only 1 value, and that value applyed to all the fantables)... yeah, i would say is this way :)

"fanconpolicy set 2"
"fanservo 80"
 
Last edited:
@sandungas
It doesn't have much to do with the current discussion, but I have to ask, is it possible to overwrite Syscon, as is done on the NAND/NOR chip? I ask because, when you change the PS3 processor, the NOR you can just rewrite it using the patch compatible with the new CPU, but what about Syscon, is it possible to do that or are we not there yet?
 
_XBrD4shDOE_808_ said:
@sandungas
It doesn't have much to do with the current discussion, but I have to ask, is it possible to overwrite Syscon, as is done on the NAND/NOR chip? I ask because, when you change the PS3 processor, the NOR you can just rewrite it using the patch compatible with the new CPU, but what about Syscon, is it possible to do that or are we not there yet?
Click to expand...
Depends of the memory type, the syscon is like a tiny computer with several memories inside, is better seen on this table
https://www.psdevwiki.com/ps3/Syscon_Hardware#PS3_Syscon_models

This needs to be explained starting with the retail mullion syscons (the CXR models without the "F") because are the most simples of all them
ROM is "read only", used to store the base syscon firmware so is unbrickable because is phisically imposible to write in it, a convenient consequence of this is we are using the syscon firmware identifyers to identify the syscon model (hardware) because every hardware revision have a unique syscon firmware, to read the ROM is used an exploit that allows to read it entirelly, for curiosity sake... if you take a look at some of the syscon dumps shared publically you are going to realize they have the exact same size mentioned in that table in wiki

The EEPROM is "read & write" access, is intended to store settings, and other stuff that requires to be updated frequently (like the error logs, or the bringup/shutdowns/runtime counters), most of the EEPROM is available to be readen/written when we do a standard auth access by UART, this can be seen in this other table, as you can see there are some areas marked with the tag "exploit" because are protected
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table
In the mullion syscons (all the ones soldered by BGA) there are a few BGA pads that are a direct SPI access to the EEPROM, this means we can read/write the EEPROM entirelly if we connect an external programmer to that EEPROM pads, this is usually made with a programmer named "bus pirate"

The RAM is like the RAM of a PC, when the syscon boots it loads parts of the ROM and EEPROM into RAM... then it uses the data from RAM (instead of the original). This feature is used in the official syscon patches, the patch is stored in EEPROM, but is applyed over the copy of the ROM data in RAM

----------
The FLASH of the "F" syscon is an special feature, as you can see in the first table, the size of FLASH is exactly the same than the ROM of the other mullion syscon models... because the FLASH is inteded to store the base firmware
In other words... you can take the ROM data from a different syscon model and write it in the "FLASH" area of the "F" syscon and the result would be like using the syscon that was a donor of the ROM data

---------
The sherwood syscons are trying to keep some "backward compatibility" with the previous syscons, but there is not an EEPROM anymore (and there are no pads/pins to access it externally)
The syscon base firmware is stored in FLASH, and the data that was stored in EEPROM from the previous versions is stored in FLASH too, all together
Is a more simple design because there is only 1 storage memory type, and technically is full read & write access... as far i know there is not a known way to write it entirelly, but we can read it entirelly with exploits

One of the features related with that "backward compatibility" i mentioned is, when the sherwoods boots they are "emulating" a "virtual" EEPROM that have the same exact size than the previous mullion syscons... but the way how the data is organized inside that virtual EEPROM is weird in many senses because if like it is created "on the fly" by joining together various pieces of data from different parts of the FLASH
The results is the contents of that virtual EEPROM is not exactly like in the previous mullion syscons, this sucks a bit for sherwood owners because most of the R&D work was made in mullions, obviouslly (specially with the help of the "F" syscon, extremelly convenient to do experiments)

-----------------
So long story short... yeah, in mullions we can read them entirelly, and write them entirelly except the syscon base firmware stored in ROM (but we can apply "on the fly" patches in the ROM)

Sherwoods have the potential of being able to read/write everything, included the syscon base firmware, but as far i know there is no known way to do it, we can read the FLASH entirelly, but we can only write in some specific areas of it :/
 
Last edited:
Has anyone had luck finding what MOSFET we should be using to do the VDDR mod? I know it's taken from a slim model that has a 40nm, but I want to know if anyone has been able to locate the model number so I can post a link to order them.

I only have the one MOSFET that I installed on my original frankenstein with a 40nm RSX (PS3#8). I have been searching the KTE donor board for another MOSFET that I can for PS3#12 (E model with a 40nm), and there are a few possable IC's but I don't know what it's supposed to be.

I have been able to tract the manufacturer down by their logo, but the numbers on the chip don't lead me to anything. It's an SOIC-8 package made by Microchip Technologies. That's all I've been able to find out!
 
I have received those rpga 989 sockets for my test but they cannot fit cut small parts after I test on reballed rsx. Original from factory is matching inside those holes . I'll look for another idea on this universal test socket. Such pain those rsx.
Original unit that made patches for rsx possible it just got special glod after been trying to change original flash with another flash nor ic. Well I'll leave it aside for now, need time and I'll search for other boards dia002/001 for my test.
They must work straight, not much time to be invested with them or at least time invested in small steps should give greater goals in the end.
 
Can someone please post a picture of the VDDR MOSFET from a Slim board that has a 40nm RSX?

I only had the one KTE-001 MB, and I installed that MOSFET on my first frankenstein. Here is a picture...
Voltage Mod MOSFETs on KTE-001.jpg

The mosfet on the left, next to the RSX is for VDDR. That's the one @botakompong says to use. However, there is another MOSFET to the right with a similar markings. They're Microchip Technologies "132" and the bottom number I assume is the lot number. I can't figure out what hese are in order to buy them separately, so we don't have to harvest them from a donor board. And I'm not completly sure the MOSFET on the right is the same.

The reason I need someone to pull the VDDR modfet off and post a pucture of both sides is because I don't remember there being a GND plane (for heat sinking to the MB) on the bottom of the VDDR mosfet. And there is one on the other one I'm thinking of using...
Voltage Mod no MOSFETs on KTE-001.jpg

Microchip 302_TOP(MOSFET).jpg
Microchip 302_ BTM (MOSFET).jpg


Can someone confirm that this GND pad is on the VDDR MOSFET too?

If it's not, then I can't use it and won't be able to do the voltage mod on my frankie until I can buy some 1800 ohms resistors for the official method.

EDIT: I just noticed the one on the right has "20F" in side the dot that indicates pin 1, and the VDDR MOSFET doesn't. so they are different. Dang! But what I don't know is if I can still use it.
 
Hmm...Thanks for the warning!

I guess that means I need some 1800 ohms resistors and can't finishe the VDDR voltage mods until then. Or I could just get some busted slims. and that way I can harvest the 40nm RSX too. I'll have to think about it.
 
RIP-Felix said:
Can someone please post a picture of the VDDR MOSFET from a Slim board that has a 40nm RSX?

I only had the one KTE-001 MB, and I installed that MOSFET on my first frankenstein. Here is a picture...
View attachment 36645
The mosfet on the left, next to the RSX is for VDDR. That's the one @botakompong says to use. However, there is another MOSFET to the right with a similar markings. They're Microchip Technologies "132" and the bottom number I assume is the lot number. I can't figure out what hese are in order to buy them separately, so we don't have to harvest them from a donor board. And I'm not completly sure the MOSFET on the right is the same.

The reason I need someone to pull the VDDR modfet off and post a pucture of both sides is because I don't remember there being a GND plane (for heat sinking to the MB) on the bottom of the VDDR mosfet. And there is one on the other one I'm thinking of using...
View attachment 36646
View attachment 36643 View attachment 36642

Can someone confirm that this GND pad is on the VDDR MOSFET too?

If it's not, then I can't use it and won't be able to do the voltage mod on my frankie until I can buy some 1800 ohms resistors for the official method.

EDIT: I just noticed the one on the right has "20F" in side the dot that indicates pin 1, and the VDDR MOSFET doesn't. so they are different. Dang! But what I don't know is if I can still use it.
Click to expand...
The logo of the "348A" looks like if it was made by microchip company, but is made by Mitsumi Electric
I published the pinout here
https://www.psdevwiki.com/ps3/Talk:Regulators#Mitsumi_348A_.28voltage_regulator.29
 
Yo, does this look a little small to anyone else?
i43oRRY.jpg

So....still don't know why I couldn't get those modchips working, but this fired right up with the syscon changes! Thanks to everyone that's been working on this so hard. @M4j0r @sandungas @RIP-Felix and anyone else I'm forgetting.

I'm still pretty much on a work sabbatical for a few months, I just couldn't help myself since I had a 40nm sitting on the shelf. Once I really get back to work, I can do a few boards for devs/longtime members here for free/cheap if you provide the parts. Anyone else, suck it, you're paying full price for a whole, finished system! Maybe I'll set a discount for forum folks that predate this post...
 
You must log in or register to reply here.

Similar threads

Back
Top