PS3 Syscon fan settings (Coordinate Graphs)

[vyktormvmpay25]

It may take me time to digest all info . Like was stated FW update on syscon will show that log but it seems if fail on some point it will block rest of commands, had to test to understend my options .To get out of this panic hard reset is necessary. Normal users must stay out of trouble .
I will try to get that fan area dumped .
For more test we will run over one Frankenstain mobo with mod chip if i get this days time to finish. This is going to be compared and will try to intercept spi in paralel with that mod ic.
As seen on port scan on sw will show different and not letters anymore.In parallel I work for a board jsd for the guy who broken that cpu.

 

[vyktormvmpay25]

Got time to read thermal area for this board .

>$ r 3300 200
r 3300 200
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
-----------------------------------------------
33 40 48 4D 5A 66 73 80 99 FF 00 4A 00 4B 00 4C
00 4D 00 4E 00 4F 00 50 00 51 00 52 00 55 00 00
00 3C 00 3D 00 43 00 44 00 47 80 47 00 48 80 48
00 49 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF 00 53 00 54 00 55
00 56 00 57 00 58 00 59 00 5A 00 5B 00 5F 00 00
00 30 00 47 00 4D 00 4E 00 50 80 50 00 51 80 51
00 52 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 33 FF 01 00 00 FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF 00 3C 00 3D 00 3E
00 3F 00 40 00 41 00 42 00 43 00 44 00 47 00 00
00 27 00 30 00 36 00 37 80 3A 00 3B 00 3C 80 3C
00 3D 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 33 FF 01 00 00 FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 00 4D 14 FF FF FF FF FF FF FF 00 FF 00 FF
54 00 55 00 02 00 5E 00 5F 00 02 00 FF FF FF FF
02 00 46 00 47 00 02 00 FF FF FF FF 02 00 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF 15 71
[mullion]$

 

[sandungas]

Got time to read thermal area for this board .

>$ r 3300 200
r 3300 200
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
-----------------------------------------------
33 40 48 4D 5A 66 73 80 99 FF 00 4A 00 4B 00 4C
00 4D 00 4E 00 4F 00 50 00 51 00 52 00 55 00 00
00 3C 00 3D 00 43 00 44 00 47 80 47 00 48 80 48
00 49 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF 00 53 00 54 00 55
00 56 00 57 00 58 00 59 00 5A 00 5B 00 5F 00 00
00 30 00 47 00 4D 00 4E 00 50 80 50 00 51 80 51
00 52 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 33 FF 01 00 00 FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF 00 3C 00 3D 00 3E
00 3F 00 40 00 41 00 42 00 43 00 44 00 47 00 00
00 27 00 30 00 36 00 37 80 3A 00 3B 00 3C 80 3C
00 3D 33 FF 01 00 FF FF FF FF FF FF FF FF FF FF
33 40 48 4D 5A 66 73 80 99 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 33 FF 01 00 00 FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF 00 4D 14 FF FF FF FF FF FF FF 00 FF 00 FF
54 00 55 00 02 00 5E 00 5F 00 02 00 FF FF FF FF
02 00 46 00 47 00 02 00 FF FF FF FF 02 00 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF 15 71
[mullion]$

Thx but we had that one already, by now we are identifying them by his checksum and that one is 7115 (it can be seen in the last 2 bytes you posted)
But if you have some time it would be helpful to run this commands in it:

>$ revision
>$ version
>$ fantbl get 0
>$ fantbl get 1
>$ fantbl get 2
>$ tshutdown get 0
>$ tshutdown get 1
>$ tshutdown get 2
>$ eepcsum

Btw, if someone is interested in helping check this wiki page to see if there is something missing https://www.psdevwiki.com/ps3/Syscon_Thermal_Config
Right now that wiki page is fully synced with my collection, with this i mean... i published all the thermal config files and info i been collecting since weeks ago in it

 

[vyktormvmpay25]

this was previous scrap board that I'm looking

>$ revision
revision
0C16
[mullion]$
>$ version
version
v1.1.3_k1
[mullion]$
>$ fantbl get 0
fantbl get 0
fancon No:00
P0: TempD:0.0(0x0000) - TempU:74.0(0x4a00) duty:20%(0x33)
P1: TempD:60.0(0x3c00) - TempU:75.0(0x4b00) duty:25%(0x40)
P2: TempD:61.0(0x3d00) - TempU:76.0(0x4c00) duty:28%(0x48)
P3: TempD:67.0(0x4300) - TempU:77.0(0x4d00) duty:30%(0x4d)
P4: TempD:68.0(0x4400) - TempU:78.0(0x4e00) duty:35%(0x5a)
P5: TempD:71.0(0x4700) - TempU:79.0(0x4f00) duty:40%(0x66)
P6: TempD:71.50(0x4780) - TempU:80.0(0x5000) duty:45%(0x73)
P7: TempD:72.0(0x4800) - TempU:81.0(0x5100) duty:50%(0x80)
P8: TempD:72.50(0x4880) - TempU:82.0(0x5200) duty:60%(0x99)
P9: TempD:73.0(0x4900) - TempU:85.0(0x5500) duty:100%(0xff)
[mullion]$
>$ fantbl get 1
fantbl get 1
fancon No:01
P0: TempD:0.0(0x0000) - TempU:83.0(0x5300) duty:20%(0x33)
P1: TempD:48.0(0x3000) - TempU:84.0(0x5400) duty:25%(0x40)
P2: TempD:71.0(0x4700) - TempU:85.0(0x5500) duty:28%(0x48)
P3: TempD:77.0(0x4d00) - TempU:86.0(0x5600) duty:30%(0x4d)
P4: TempD:78.0(0x4e00) - TempU:87.0(0x5700) duty:35%(0x5a)
P5: TempD:80.0(0x5000) - TempU:88.0(0x5800) duty:40%(0x66)
P6: TempD:80.50(0x5080) - TempU:89.0(0x5900) duty:45%(0x73)
P7: TempD:81.0(0x5100) - TempU:90.0(0x5a00) duty:50%(0x80)
P8: TempD:81.50(0x5180) - TempU:91.0(0x5b00) duty:60%(0x99)
P9: TempD:82.0(0x5200) - TempU:95.0(0x5f00) duty:100%(0xff)
[mullion]$
>$ fantbl get 2
fantbl get 2
fancon No:02
P0: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:20%(0x33)
P1: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:25%(0x40)
P2: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:28%(0x48)
P3: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:30%(0x4d)
P4: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:35%(0x5a)
P5: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:40%(0x66)
P6: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:45%(0x73)
P7: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:50%(0x80)
P8: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:60%(0x99)
P9: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:100%(0xff)
[mullion]$
>$ tshutdown get 0
tshutdown get 0
TZone No:00
1st BE Primary Temperature:85.0(0x5500)
[mullion]$
>$ tshutdown get 1
tshutdown get 1
TZone No:01
RSX Primary Temperature:95.0(0x5f00)
[mullion]$
>$ tshutdown get 2
tshutdown get 2
TZone No:02
*** Unknown Error11 ***
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x528c
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$


tshutdown get 2 is not showing ,error 11 not sure if shoul work or not as i dont have rsx on this board.

I can assume rx tx pins for SB should be here? Someone should confirm as looking on pdf is quite în mirror view from that PCI pinout but order seems to be exactly as pdf. Was quite confusing locked on pdf.
They are not tied on to port but can be done.

 

[sandungas]

Nice
And this ones ?

>$ fantbl get 4
>$ tshutdown get 4

Or...

>$ fantbl get 14
>$ tshutdown get 14

Or well... try other numbers... i can tell the tshutdown value is there (it should display a 0x4700)

The thermal configs from the first retail PS3 motherboards (COK-001, COK-002, SEM-001) are a bit different than the next motherboard models, this is still a bit confusing for me


---------------
About the PCI connector... check the pinout here https://www.psdevwiki.com/ps3/PCI
To me it looks the testpads you marked in your photo are not the southbridge UART... but im not sure

 

[vyktormvmpay25]

OMG stupid config!
[mullion]$
>$ tshutdown get 14
tshutdown get 14
TZone No:14
SB Temperature:71.0(0x4700)
[mullion]$
>$ fantbl get 14
fantbl get 14
*** Invalid Argument ***
[mullion]$
>$ fantbl get 13
fantbl get 13
*** Invalid Argument ***
[mullion]$
>$ fantbl get 12
fantbl get 12
*** Invalid Argument ***
[mullion]$
>$ fantbl get 11
fantbl get 11
*** Invalid Argument ***
[mullion]$
>$ fantbl get 0
fantbl get 0
fancon No:00
P0: TempD:0.0(0x0000) - TempU:74.0(0x4a00) duty:20%(0x33)
P1: TempD:60.0(0x3c00) - TempU:75.0(0x4b00) duty:25%(0x40)
P2: TempD:61.0(0x3d00) - TempU:76.0(0x4c00) duty:28%(0x48)
P3: TempD:67.0(0x4300) - TempU:77.0(0x4d00) duty:30%(0x4d)
P4: TempD:68.0(0x4400) - TempU:78.0(0x4e00) duty:35%(0x5a)
P5: TempD:71.0(0x4700) - TempU:79.0(0x4f00) duty:40%(0x66)
P6: TempD:71.50(0x4780) - TempU:80.0(0x5000) duty:45%(0x73)
P7: TempD:72.0(0x4800) - TempU:81.0(0x5100) duty:50%(0x80)
P8: TempD:72.50(0x4880) - TempU:82.0(0x5200) duty:60%(0x99)
P9: TempD:73.0(0x4900) - TempU:85.0(0x5500) duty:100%(0xff)
[mullion]$
>$ fantbl get 3
fantbl get 3
fancon No:03
P0: TempD:0.0(0x0000) - TempU:60.0(0x3c00) duty:20%(0x33)
P1: TempD:39.0(0x2700) - TempU:61.0(0x3d00) duty:25%(0x40)
P2: TempD:48.0(0x3000) - TempU:62.0(0x3e00) duty:28%(0x48)
P3: TempD:54.0(0x3600) - TempU:63.0(0x3f00) duty:30%(0x4d)
P4: TempD:55.0(0x3700) - TempU:64.0(0x4000) duty:35%(0x5a)
P5: TempD:58.50(0x3a80) - TempU:65.0(0x4100) duty:40%(0x66)
P6: TempD:59.0(0x3b00) - TempU:66.0(0x4200) duty:45%(0x73)
P7: TempD:60.0(0x3c00) - TempU:67.0(0x4300) duty:50%(0x80)
P8: TempD:60.50(0x3c80) - TempU:68.0(0x4400) duty:60%(0x99)
P9: TempD:61.0(0x3d00) - TempU:71.0(0x4700) duty:100%(0xff)
[mullion]$
>$ tshutdown get 14
tshutdown get 14
TZone No:14
SB Temperature:71.0(0x4700)
[mullion]$
>$ fantbl get 14
fantbl get 14
*** Invalid Argument ***
[mullion]$
>$ fantbl get 3
fantbl get 3
fancon No:03
P0: TempD:0.0(0x0000) - TempU:60.0(0x3c00) duty:20%(0x33)
P1: TempD:39.0(0x2700) - TempU:61.0(0x3d00) duty:25%(0x40)
P2: TempD:48.0(0x3000) - TempU:62.0(0x3e00) duty:28%(0x48)
P3: TempD:54.0(0x3600) - TempU:63.0(0x3f00) duty:30%(0x4d)
P4: TempD:55.0(0x3700) - TempU:64.0(0x4000) duty:35%(0x5a)
P5: TempD:58.50(0x3a80) - TempU:65.0(0x4100) duty:40%(0x66)
P6: TempD:59.0(0x3b00) - TempU:66.0(0x4200) duty:45%(0x73)
P7: TempD:60.0(0x3c00) - TempU:67.0(0x4300) duty:50%(0x80)
P8: TempD:60.50(0x3c80) - TempU:68.0(0x4400) duty:60%(0x99)
P9: TempD:61.0(0x3d00) - TempU:71.0(0x4700) duty:100%(0xff)
[mullion]$
>$
>$ fantbl get 4
fantbl get 4
fancon No:04
P0: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:20%(0x33)
P1: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:25%(0x40)
P2: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:28%(0x48)
P3: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:30%(0x4d)
P4: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:35%(0x5a)
P5: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:40%(0x66)
P6: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:45%(0x73)
P7: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:50%(0x80)
P8: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:60%(0x99)
P9: TempD:255.75(0xffff) - TempU:255.75(0xffff) duty:100%(0xff)
[mullion]$
>$ tshutdown get 13
tshutdown get 13
TZone No:13
*** Unknown Error11 ***
[mullion]$
>$

 

[vyktormvmpay25]

This is my assumption and I may be right

Looking to 3v3 point is only place with fuse, count gnd points. We must have confirmation from more people.

 

[sandungas]

Great, 2 new misteries solved take a look at that @M4j0r im going to copy the commands "cleaned up" (in the same format im going to post them in wiki for better readability)

>$ revision
revision
0C16

>$ version
version
v1.1.3_k1

>$ fantbl get 0
fantbl get 0
fancon No:00
P0: TempD:0.0(0x0000) - TempU:74.0(0x4a00) duty:20%(0x33)
P1: TempD:60.0(0x3c00) - TempU:75.0(0x4b00) duty:25%(0x40)
P2: TempD:61.0(0x3d00) - TempU:76.0(0x4c00) duty:28%(0x48)
P3: TempD:67.0(0x4300) - TempU:77.0(0x4d00) duty:30%(0x4d)
P4: TempD:68.0(0x4400) - TempU:78.0(0x4e00) duty:35%(0x5a)
P5: TempD:71.0(0x4700) - TempU:79.0(0x4f00) duty:40%(0x66)
P6: TempD:71.50(0x4780) - TempU:80.0(0x5000) duty:45%(0x73)
P7: TempD:72.0(0x4800) - TempU:81.0(0x5100) duty:50%(0x80)
P8: TempD:72.50(0x4880) - TempU:82.0(0x5200) duty:60%(0x99)
P9: TempD:73.0(0x4900) - TempU:85.0(0x5500) duty:100%(0xff)

>$ fantbl get 1
fantbl get 1
fancon No:01
P0: TempD:0.0(0x0000) - TempU:83.0(0x5300) duty:20%(0x33)
P1: TempD:48.0(0x3000) - TempU:84.0(0x5400) duty:25%(0x40)
P2: TempD:71.0(0x4700) - TempU:85.0(0x5500) duty:28%(0x48)
P3: TempD:77.0(0x4d00) - TempU:86.0(0x5600) duty:30%(0x4d)
P4: TempD:78.0(0x4e00) - TempU:87.0(0x5700) duty:35%(0x5a)
P5: TempD:80.0(0x5000) - TempU:88.0(0x5800) duty:40%(0x66)
P6: TempD:80.50(0x5080) - TempU:89.0(0x5900) duty:45%(0x73)
P7: TempD:81.0(0x5100) - TempU:90.0(0x5a00) duty:50%(0x80)
P8: TempD:81.50(0x5180) - TempU:91.0(0x5b00) duty:60%(0x99)
P9: TempD:82.0(0x5200) - TempU:95.0(0x5f00) duty:100%(0xff)

>$ fantbl get 3
fantbl get 3
fancon No:03
P0: TempD:0.0(0x0000) - TempU:60.0(0x3c00) duty:20%(0x33)
P1: TempD:39.0(0x2700) - TempU:61.0(0x3d00) duty:25%(0x40)
P2: TempD:48.0(0x3000) - TempU:62.0(0x3e00) duty:28%(0x48)
P3: TempD:54.0(0x3600) - TempU:63.0(0x3f00) duty:30%(0x4d)
P4: TempD:55.0(0x3700) - TempU:64.0(0x4000) duty:35%(0x5a)
P5: TempD:58.50(0x3a80) - TempU:65.0(0x4100) duty:40%(0x66)
P6: TempD:59.0(0x3b00) - TempU:66.0(0x4200) duty:45%(0x73)
P7: TempD:60.0(0x3c00) - TempU:67.0(0x4300) duty:50%(0x80)
P8: TempD:60.50(0x3c80) - TempU:68.0(0x4400) duty:60%(0x99)
P9: TempD:61.0(0x3d00) - TempU:71.0(0x4700) duty:100%(0xff)

>$ tshutdown get 0
tshutdown get 0
TZone No:00
1st BE Primary Temperature:85.0(0x5500)

>$ tshutdown get 1
tshutdown get 1
TZone No:01
RSX Primary Temperature:95.0(0x5f00)

>$ tshutdown get 14
tshutdown get 14
TZone No:14
SB Temperature:71.0(0x4700)

>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x528c
Addr:0x000034fe should be 0x7115
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

Long story short... the thermal config for the COK-001 motherboards is composed by 6 tables to store the settings for 6 components (or better said... for 6 thermal sensors) but only 3 tables contains valid values
If we count only the tables with valid values... we could say that the first table is for CELL, the second is for RSX, and the third was unknown

In the images i made (in first post of this thread) i was considering the third table was for BEVR because i was using as reference a code structure published by @M4j0r in this post

I documented the area in the tmp_ctrl struct: https://pastebin.com/Wtc7NcJ4

That structure was very useful, im not complaining but i always suspected the assignment to BEVR was wrong, as far i remember i mentioned it in the forum before but we could never find a real proof if my teory was right or wrong, but i think this command is a confirmation, in it can be seen that syscon is labeling it as SB Temperature

>$ tshutdown get 14
tshutdown get 14
TZone No:14
SB Temperature:71.0(0x4700)

The other mistery solved is his id=14
The reason why i suggested to use id=14 is because some days ago i realized there are some error codes related with the SB thermal sensor that have a "14" somewhere, i dont remember well, it was not a real proof but lets say... it was a detail that made me brainstorm a bit and lighted the spark

And yeah... this version of the syscon firmware is doing weird things, note when using the "fantbl" command the identifyers are: CELL=0, RSX=1, SB=3. And when using the comand "tshutdown" the identifyers are CELL=0, RSX=1, SB=14

 

[vyktormvmpay25]

There may be places for that ps2 ic that is missing. I haven't seen for a long time ago one cok001, but if you find it in pdf schematic as 4th sensor ic it could be that left space for it not sure what to say.

 

[sandungas]

There may be places for that ps2 ic that is missing. I haven't seen for a long time ago one cok001, but if you find it in pdf schematic as 4th sensor ic it could be that left space for it not sure what to say.

The real reason why the first retail motherboards have room for up to 6 thermal sensors is because the way how the data is organized inside the "thermal config" is inherited from the prototype and other non-retail PS3 models
We dont really know how it started and how many thermal sensors was active in the thermal configs of them
All we know is when they started the production of the retail PS3 models (COK-001 and nexts) they keept active only CELL, RSX, SB... and later CELL and RSX only (but there is room to add the SB in the thermal configs of all PS3 models, included superslims)

Im sure there is a good reason why m4j0r assigned some values to a theorethical BEVR in the code structure he published (probably because it was active in some prototype PS3 model)
In theory... the BEVR sensor should be located in the "power block" area of the motherboard because BEVR means "CELL BE Voltage Regulators"... in other words... it should be located inmediatly "before" the CELL tokins

Spoiler

And this is another reason why i prefer to consier the hardware identifyers inside the "thermal config" as sensors... because sometimes that sensors are not "inside" other component (e.g: the sensor for CELL is inside CELL)
But in this case the BEVR should be a simple thermal sensor soldered directly to the motherboard, and should be meassuring the temperature of the other components around it (but is not "inside" them)... actually is the sensor of the "CELL power block" area of the motherboard... that could be a concept a bit abstract for the newcomers to electronics

M4j0r made a complete list of all the thermal sensors that exists in preretail PS3 motherboards... for sure are some of that list
But if we use the logic there is no need to be an engineer to realize that the most important "hotspots" of the COK-001 are CELL, RSX, SB, EEGS, BEVR... because all them have a big contact to transfer the heat to either the main heatsinks... or have thermal pads to transfer it to the interference metal shields

The EEGS is the codename of the "Emotion engine + graphic synthesizer" responsible of the PS2 emulation by hardware... as far i remember appears with that exact codename in the image published/leaked with the COK-001 error codes
The prototype and non-retail PS3 models was not doing any emulation thought... so incase it was added at some point to the "thermal config" area probably is at the last positions (id=6 or id=16)

Anyway... i guess if we fill the "thermal config" area with valid values for all them... this is not going to be enought to enable them
Having valid info in the thermal config area is a thing.... and configuring syscon to use that info we are adding is a different thing
Probably there is some setting somewhere inside the syscon configs where is posible to enable or disable them just by changing a byte... but i never did read anything about it... so i dont nkow... is just my speculation by now

--------------
@M4j0r im trying to make a list of all the UART commands intended to read/write settings directly inside the "thermal config" area
And im also taking a look at some strings from inside a full syscon dump you shared and i noticed some interesting strings related with thermal config management

Fan initial time: %d(ms)
Fan initial time: %d(ms) -> disable

This means we need to convert the hex to decimal, and the "meassure unit" is miliseconds
I was brainstorming about this some weeks ago in the forum because i was not sure about the meassure unit, now is clear, but is still a bit weird because (as far i remember) the hex value for all PS3 models is 0x14 and thats 20 miliseconds (ridicully small doesnt looks realistic)

Btw, which command is used to "get" and "set" the "initial fan duty" and "initial fan time" ?... im taking a look at the command lists published in wiki and i cant figure it
As far i understand there must be one comand to "get" it because is the responsible of printing that strings
Also, in one of the strings is telling literally "disable" so i guess there is a way to change his status... and probably this status change is going to fill the byte with the time value to 0x00 or 0xFF that represents zero miliseconds... or is going to add some value in the "unknown" byte we have at his left in the code structure that is always 0x00

TShutdown Time:%d[s](default tshutdown time)
TShutdown Time:%d[s](0x%04x)

This ones are interesting because is also mentioned the "meassure unit"... im guessing that "[s]" means seconds, right ?

--------------------
By now i have this list of commands that are almost covering completly all the values stored in the thermal config area, please tell me if are intended to be used this way and if im missing something

>$ fantbl get 0
>$ duty getmin 0
>$ duty getmax 0
---policy command ?---
---select command ?---
---active command ?---

>$ tshutdowntime get
---initial fan duty command ?---
---initial fan time command ?---

>$ trp get 0
>$ tshutdown get 0
>$ hyst get 0

Im doing everything with id=0 just because we know the values for CELL have id=0 and is enabled in all PS3 models but it should work the same with other id's
For "trp", "tshutdown" and "hyst" commands sometimes is needed to use weird ids that differs from the other commands (id=14 for the southbridge of COK-001 and COK-002)... this seems to be because this settings are located at bottom of the thermal config (out of the tables)

 

[M4j0r]

The real reason why the first retail motherboards have room for up to 6 thermal sensors is because the way how the data is organized inside the "thermal config" is inherited from the prototype and other non-retail PS3 models
M4j0r made a complete list of all the thermal sensors that exists in preretail PS3 motherboards... for sure are some of that list
But if we use the logic there is no need to be an engineer to realize that the most important "hotspots" of the COK-001 are CELL, RSX, SB, EEGS, BEVR... because all them have a big contact to transfer the heat to either the main heatsinks... or have thermal pads to transfer it to the interference metal shields

Yes, prototype models even support way more (which also depends on the firmware version).
The DECR-1000 does have a hardcoded table in the firmware (the EEPROM region is empty):

Spoiler

> revision
revision
0F3B
> version
version
v1.0.5_c1
> tzone
tzone
00: 1st BE Primary
01: RSX Primary
02: XDR Primary
0A: Air Intake
0F: GbE
14: SB
> fantbl get 0
fantbl get 0
fancon No:00
P0: TempD:0.0(0x0000) - TempU:52.0(0x3400) duty:30%(0x4d)
P1: TempD:49.0(0x3100) - TempU:56.0(0x3800) duty:45%(0x73)
P2: TempD:53.0(0x3500) - TempU:60.0(0x3c00) duty:60%(0x99)
P3: TempD:57.0(0x3900) - TempU:64.0(0x4000) duty:80%(0xcc)
P4: TempD:61.0(0x3d00) - TempU:127.75(0x7fff) duty:100%(0xff)
P5: TempD:64.0(0x4000) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:66.0(0x4200) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:68.0(0x4400) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:70.0(0x4600) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:72.0(0x4800) - TempU:127.75(0x7fff) duty:100%(0xff)
> fantbl get 1
fantbl get 1
fancon No:01
P0: TempD:0.0(0x0000) - TempU:52.0(0x3400) duty:30%(0x4d)
P1: TempD:49.0(0x3100) - TempU:56.0(0x3800) duty:45%(0x73)
P2: TempD:53.0(0x3500) - TempU:60.0(0x3c00) duty:60%(0x99)
P3: TempD:57.0(0x3900) - TempU:64.0(0x4000) duty:80%(0xcc)
P4: TempD:61.0(0x3d00) - TempU:127.75(0x7fff) duty:100%(0xff)
P5: TempD:64.0(0x4000) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:66.0(0x4200) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:68.0(0x4400) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:70.0(0x4600) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:72.0(0x4800) - TempU:127.75(0x7fff) duty:100%(0xff)
> fantbl get 2
fantbl get 2
fancon No:02
P0: TempD:0.0(0x0000) - TempU:52.0(0x3400) duty:30%(0x4d)
P1: TempD:49.0(0x3100) - TempU:56.0(0x3800) duty:45%(0x73)
P2: TempD:53.0(0x3500) - TempU:60.0(0x3c00) duty:60%(0x99)
P3: TempD:57.0(0x3900) - TempU:64.0(0x4000) duty:80%(0xcc)
P4: TempD:61.0(0x3d00) - TempU:127.75(0x7fff) duty:100%(0xff)
P5: TempD:64.0(0x4000) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:66.0(0x4200) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:68.0(0x4400) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:70.0(0x4600) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:72.0(0x4800) - TempU:127.75(0x7fff) duty:100%(0xff)
> fantbl get 3
fantbl get 3
fancon No:03
P0: TempD:0.0(0x0000) - TempU:52.0(0x3400) duty:30%(0x4d)
P1: TempD:49.0(0x3100) - TempU:56.0(0x3800) duty:45%(0x73)
P2: TempD:53.0(0x3500) - TempU:60.0(0x3c00) duty:60%(0x99)
P3: TempD:57.0(0x3900) - TempU:64.0(0x4000) duty:80%(0xcc)
P4: TempD:61.0(0x3d00) - TempU:127.75(0x7fff) duty:100%(0xff)
P5: TempD:64.0(0x4000) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:66.0(0x4200) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:68.0(0x4400) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:70.0(0x4600) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:72.0(0x4800) - TempU:127.75(0x7fff) duty:100%(0xff)
> fantbl get 4
fantbl get 4
fancon No:04
P0: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P1: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P2: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P3: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P4: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P5: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P6: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P7: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P8: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P9: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
> fantbl get 5
fantbl get 5
fancon No:05
P0: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P1: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P2: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P3: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P4: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P5: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P6: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P7: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P8: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P9: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
> fantbl get 6
fantbl get 6
fancon No:06
P0: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P1: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P2: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P3: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P4: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P5: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P6: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P7: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P8: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
P9: TempD:0.0(0x0000) - TempU:0.0(0x0000) duty:0%(0x00)
> fantbl get 7
fantbl get 7
fancon No:07
P0: TempD:0.0(0x0000) - TempU:27.0(0x1b00) duty:30%(0x4d)
P1: TempD:26.0(0x1a00) - TempU:30.0(0x1e00) duty:40%(0x66)
P2: TempD:29.0(0x1d00) - TempU:32.0(0x2000) duty:50%(0x80)
P3: TempD:31.0(0x1f00) - TempU:34.0(0x2200) duty:70%(0xb3)
P4: TempD:33.0(0x2100) - TempU:37.0(0x2500) duty:80%(0xcc)
P5: TempD:35.0(0x2300) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:37.0(0x2500) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:39.0(0x2700) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:41.0(0x2900) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:42.0(0x2a00) - TempU:127.75(0x7fff) duty:100%(0xff)
> fantbl get 8
fantbl get 8
fancon No:08
P0: TempD:0.0(0x0000) - TempU:27.0(0x1b00) duty:30%(0x4d)
P1: TempD:26.0(0x1a00) - TempU:30.0(0x1e00) duty:40%(0x66)
P2: TempD:29.0(0x1d00) - TempU:32.0(0x2000) duty:50%(0x80)
P3: TempD:31.0(0x1f00) - TempU:34.0(0x2200) duty:70%(0xb3)
P4: TempD:33.0(0x2100) - TempU:37.0(0x2500) duty:80%(0xcc)
P5: TempD:35.0(0x2300) - TempU:127.75(0x7fff) duty:100%(0xff)
P6: TempD:37.0(0x2500) - TempU:127.75(0x7fff) duty:100%(0xff)
P7: TempD:39.0(0x2700) - TempU:127.75(0x7fff) duty:100%(0xff)
P8: TempD:41.0(0x2900) - TempU:127.75(0x7fff) duty:100%(0xff)
P9: TempD:42.0(0x2a00) - TempU:127.75(0x7fff) duty:100%(0xff)
> tshutdown get 0
tshutdown get 0
TZone No:00
1st BE Primary Temperature:100.0(0x6400)
> tshutdown get 1
tshutdown get 1
TZone No:01
RSX Primary Temperature:100.0(0x6400)
> tshutdown get 2
tshutdown get 2
TZone No:02
XDR Primary Temperature:85.0(0x5500)
> tshutdown get A
tshutdown get A
TZone No:0A
Air Intake Temperature:47.0(0x2f00)
> tshutdown get F
tshutdown get F
TZone No:0F
GbE Temperature:71.0(0x4700)
> tshutdown get 14
tshutdown get 14
TZone No:14
SB Temperature:75.0(0x4b00)
> diag fan_info all
diag fan_info all
FanInfoBE: Duty 0 [%] Rev 0 [rpm]
FanInfoRSX: Duty 0 [%] Rev 0 [rpm]
FanInfoFRONT: Duty 0 [%] Rev 0 [rpm]
FanInfoREAR1: Duty 0 [%] Rev 0 [rpm]
FanInfoREAR2: Duty 0 [%] Rev 0 [rpm]
> diag fan_shutdowntime get
diag fan_shutdowntime get
FAN Shutdown Time:10s(0x0A)
> fanconmode get 0
fanconmode get 0
fancon No:00
mode03: Minimum
> fanconmode get 1
fanconmode get 1
fancon No:01
mode03: Minimum
> fanconmode get 2
fanconmode get 2
fancon No:02
mode03: Minimum
> fanconmode get 3
fanconmode get 3
fancon No:03
mode03: Minimum
> fanconmode get 4
fanconmode get 4
fancon No:04
mode03: Minimum
> fanconmode get 5
fanconmode get 5
fancon No:05
mode03: Minimum
> fanconmode get 6
fanconmode get 6
fancon No:06
mode03: Minimum
> fanconmode get 7
fanconmode get 7
fancon No:07
mode03: Minimum
> fanconmode get 8
fanconmode get 8
fancon No:08
mode01: Vary Table
> fanconpolicy get 0
fanconpolicy get 0
fancon No:00
policy01: Auto
> fanconpolicy get 1
fanconpolicy get 1
fancon No:01
policy01: Auto
> fanconpolicy get 2
fanconpolicy get 2
fancon No:02
policy01: Auto
> fanconpolicy get 3
fanconpolicy get 3
fancon No:03
policy01: Auto
> fanconpolicy get 4
fanconpolicy get 4
fancon No:04
policy01: Auto
> fanconpolicy get 5
fanconpolicy get 5
fancon No:05
policy01: Auto
> fanconpolicy get 6
fanconpolicy get 6
fancon No:06
policy01: Auto
> fanconpolicy get 7
fanconpolicy get 7
fancon No:07
policy01: Auto
> fanconpolicy get 8
fanconpolicy get 8
fancon No:08
policy01: Auto

@M4j0r im trying to make a list of all the UART commands intended to read/write settings directly inside the "thermal config" area

I currently only have limited time and the thermal management on the DECR-1000 differs.
But there's one important thing to note: Every firmware alters the fan settings, you can check this by comparing "fantable get X" (version on RAM) vs "fantable getini X" (version on the EEPROM).

 

[sandungas]

But there's one important thing to note: Every firmware alters the fan settings, you can check this by comparing "fantable get X" (version on RAM) vs "fantable getini X" (version on the EEPROM).

I realized about this time ago mostly because the dumps shared by zecoxao and you (some was full eeprom dumps, others from ram, etc...), the differences i noticed affects only the values named "minduty", "maxduty", "policy", "select", "active" (1 byte each, always located near the ending of each fantable)
In lot of your dumps that 5 values are FF FF FF FF FF and i could not understand why
Actually, in some of the images graphs i made i was representing that bytes like that (but it was a bad decission, that images i made are NG)

But when we do a syscon dump with your python script of the NVS areas (including thermal config region, but some more regions)... or when using the "r" or the "EEP GET" commands... that 5 bytes appears with the values 33 FF 01 00 FF... and this are the real ones

I mean... the algorithm used by the eepcsum command considers them in his second form... otherway if we replace them with FF's the checksum is broken
I was checking it with the python script to calculate the eepcsum in PC you published here
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-236929

import sys
import struct

with open(sys.argv[1], 'rb') as f:
  data = f.read()
  checksum = 0
  for i in xrange(0, len(data), 2):
    checksum = (checksum + struct.unpack('<H', data[i:i+2])[0]) & 0xFFFF
  print hex(0x100FF - struct.unpack("<H", struct.pack(">H", checksum))[0])

Btw, the other day i found a nice feature of https://mh-nexus.de/en/hxd/ it allows to create "custom" checksum algorithms (it have a dialog where you can create them just by clicking with the mouse in some settings)
I was trying to "replicate" what you did in the python script with the eepcsum algorythm but no luck, i guess i need to try again other day because it could be handy


----------------------
There are several things that are making me brainstorm a bit from your logs of the DECR-1000 but just to comment one of them that seems we can conclude...

TShutdown Time:%d[s](default tshutdown time)
TShutdown Time:%d[s](0x%04x)

This ones are interesting because is also mentioned the "meassure unit"... im guessing that "[s]" means seconds, right ?

> diag fan_shutdowntime get
diag fan_shutdowntime get
FAN Shutdown Time:10s(0x0A)

Ok, so the "time meassure unit" for that command is seconds, i had doubts because in retail syscon firmwares the only other setting related with time was displaying it as "(ms)" and that brackets was a bit confusing
Btw, is not only the command what they changed (and the way how it prints the info), but also the lenght of it, 2 bytes for retail and only 1 byte for non-retail

I still dont understand the concept of that shutdown time (i guess is some kind of delay but this is just speculation)... in your config with a delay of 10 seconds looks a reasonable time (im not completly sure what is it, but 10 seconds doesnt looks so bad)... also it makes sense to have a lenght of 1 byte only because that allows to configure it up to 255 seconds... thats a lot of time
So the "rewriting" of this syscon function where they increased the lenght of the value to 2 bytes looks completly overkill
Dunno, just chilling, the only way i see to play around with this value is to configure the shutdown temperatures to very low values... lets say 60º or so... this way the PS3 is stable in main XMB but is easy to trigger it by entering a game... but it could be a pita because incase it does abrupt shutdowns (without giving the OS time to "unmount" filesystems and "park" the hdd heads) it could damage the hdd... not much than the frequent freezes/crashes we use to have when playing some games, but yeah... kind of that but repeated a bunch of times for science, kind of thing that is better to do with an "spare" hdd just incase

 

[M4j0r]

I still dont understand the concept of that shutdown time (i guess is some kind of delay but this is just speculation)... in your config with a delay of 10 seconds looks a reasonable time (im not completly sure what is it, but 10 seconds doesnt looks so bad)... also it makes sense to have a lenght of 1 byte only because that allows to configure it up to 255 seconds... thats a lot of time

The "fan_shutdowntime" is not the "tshutdown time".
All the cytology models keep the fans running after you shut them off (just like servers).

 

[vyktormvmpay25]

Tshutdown isn't for the maximum limit of that device attached on that sensor line. Like at that maximum unit will go panic?
Diag fan shutdown time 10 s isn't for inițial start checking time when fan is being started fast then slow down to 20 percent after those 10 seconds?

 

[sandungas]

The "fan_shutdowntime" is not the "tshutdown time".
All the cytology models keep the fans running after you shut them off (just like servers).

Hmmm, and what does the "FAN Shutdown Time:10s(0x0A)" in cytology ?, it stops the fan 10 seconds after turning the PS3 off ?

That thermal config from cytology can be "cropped" as a 0x200 bytes chunk ?, i would like to take a look at it, based in what you posted it look like his internal structure is different than the others i have
The oldest thermal config i have is from a COK-001 prototype but as far i remember his internal structure is identical to the retail COK-001

Tshutdown isn't for the maximum limit of that device attached on that sensor line. Like at that maximum unit will go panic?
Diag fan shutdown time 10 s isn't for inițial start checking time when fan is being started fast then slow down to 20 percent after those 10 seconds?

Yes, lets say... the value of tshutdown indicates when the PS3 enters in thermal panic, but the confusing thing is there are 2 values related with it "tshutdown temperature" and "tshutdown time"
The first one (tshutdown temperature) is specific for every thermal sensor, and the other (tshutdown time) is common for all the sensors, as example, in the thermal config of the COK-002 you posted a few days ago they looks like this:

CELL - tshutdown temperature = 85ºC
RSX - tshutdown temperature = 95ºC
SB - tshutdown temperature = 71ºC
ALL - tshutdown time = 0xFFFF

The value of tshutdown time is always 0xFFFF in all the samples we got from the PS3 retail models (doesnt looks realistic, it seems is disabed, or not used), this is why is a bit unknown, because we dont have any sample with a valid value different than 0xFFFF

-------
The only other setting in the thermal configs of the retail PS3's where is used a time is named "initial_fan_time" in the code structure published by m4j0r (and in the images i made), as far i remember is always value 0x14 in all retail PS3 models... and that 0x14 seems to be 20 miliseconds
But... 20 miliseconds is too fast
Time ago i was trying to meassure with a clock the time of the fan boost that happens inmediatly when we power on the PS3 and as far i remember it was something around 5 seconds or so

 

[vyktormvmpay25]

Ok then it should be that time of 10 seconds if cpu /gpu reach those max temperatures by any chance one or another, if it doesn't cool down in 10 seconds of that setup max will cut power? They probably forget sometimes fan to connect, or fan dies? Had ps4 with dead fan. Slim model before pro. SAE board. In all this years never seen dead fan on PlayStation.
This test can be monitored via UART, fan beside radiator, and wait that panic, will be time enough to boot XMB, should reach in 10 minutes that 85, probably faster only with radiator.

 

[sandungas]

Not sure but i like that idea... lets say... the "tshutdown time" could be like an ultimatum. The timer starts counting when the "tshutdown temperature" is exceeded
If the time passes but the temperature is not reduced then syscon triggers the poweroff sequence (and maybe this is the point where XMB displays a text warning, etc...)

------------
There is another unknown value related with shutdowns named "hyst", is specific for every sensor and can be get/set like this:

> hyst get 0     // for CELL
> hyst get 1     // for RSX
> hyst get 14     // for SB

The value is always 0x0200 in all samples of all retail PS3 models we got (and it seems to be 2ºC), i think it means hysteresis https://en.wikipedia.org/wiki/Hysteresis#Control_systems
Basically, it works like a range where the syscon is "insensitive" to the temperature, in this example in wikipedia can be understood better

For instance, if one wishes to maintain a temperature of 20 °C then one might set the thermostat to turn the heater on when the temperature drops to below 18 °C and off when the temperature exceeds 22 °C

It seems to be intended to "bypass" the thermal peaks that happens inside games, to prevent the fan increasing and decreasing the speeds constantly... this way the noise levels are more confortable for the user (some kind of acoustic placebo effect)

 

[vyktormvmpay25]

Hysteresis?usually is 3 in irons and heating tools, mostly on PID programming, but yes here is less because is faster.
My friend engineer has to know more about what he coded to those values on my fan accelerator and that controller for heating, remember something like this about different hysteresis then usually.
Should look at thermal ic and understand its datasheet then see what is write in syscon. This is more logical.
Can't be sure but if that ic will push some bytes instead of analog line then it's more a thing.

 

[M4j0r]

Hmmm, and what does the "FAN Shutdown Time:10s(0x0A)" in cytology ?, it stops the fan 10 seconds after turning the PS3 off ?

It means that the fans keep running for at least 10 seconds after the console goes in standby.
It's also interesting to note that the air intake temperature has to be below 47°C even though the manual says the operating temperature has to be lower than 35°C.

That thermal config from cytology can be "cropped" as a 0x200 bytes chunk ?, i would like to take a look at it, based in what you posted it look like his internal structure is different than the others i have
The oldest thermal config i have is from a COK-001 prototype but as far i remember his internal structure is identical to the retail COK-001

It's all FF on the eeprom, it's hardcoded in the firmware (in code, not data, so you can't easily dump it).

Yes, lets say... the value of tshutdown indicates when the PS3 enters in thermal panic, but the confusing thing is there are 2 values related with it "tshutdown temperature" and "tshutdown time"

My guesses are that the "tshutdown time" either specifies how long the "tshutdown temperature" has to be hold or how long it'll take before syscon does something after detecting the "tshutdown temperature".

This should be a complete list of the thermal related "get" commands on Cytology:

diag fan_info all
diag fan_shutdowntime get
                      getini
duty get [0-8]
     getmin [0-8]
     getinimin [0-8]
     getmax [0-8]
     getinimax [0-8]
fanconmode get [0-8]
fanconpolicy get [0-8]
             getini [0-8]
fantbl get [0-8]
       getini [0-8]
       getselect [0-8]
hyst get [0, 1, 2, A, F, 14]
     getini [0, 1, 2, A, F, 14]
tmp [0, 1, 2, A, F, 14]
trp get [0, 1, 2, A, F, 14]
    getini [0, 1, 2, A, F, 14]
tsensor [0, 1, 2, A, F, 14]
tshutdown get [0, 1, 2, A, F, 14]
          getini [0, 1, 2, A, F, 14]
tshutdowntime get
tzone

 

[sandungas]

It's all FF on the eeprom, it's hardcoded in the firmware (in code, not data, so you can't easily dump it).

Ok, i have some dumps from cytology, the other day i was burning my eyes in a hexeditor trying to find some area/s that could look a bit similar than the "pattern" of the other thermal configs, i guess tihis explains why i could not find anything

My guesses are that the "tshutdown time" either specifies how long the "tshutdown temperature" has to be hold or how long it'll take before syscon does something after detecting the "tshutdown temperature".

I remember you mentioned it somwhere before, and is pretty much the same suggested by vyktor, i guess you are right

This should be a complete list of the thermal related "get" commands on Cytology:

Cytology doesnt have a "getini" version of this ones ?, the list looks a bit incomplete without them

tshutdown getini [0, 1, 2, A, F, 14]
tshutdowntime getini
fanconmode getini [0-8]

Btw... some strings from the dumps that called my attention are this ones (copyed from a SW2-301 dump):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0002E870                          46 75 6C 6C 00 4D 69 6E          Full.Min
0002E880  69 6D 75 6E 00 4D 61 6E 75 61 6C 00 41 75 74 6F  imun.Manual.Auto
0002E890  00 55 6E 6B 6E 6F 77 6E 00 56 61 72 79 53 65 72  .Unknown.VarySer
0002E8A0  76 6F 00 56 61 72 79 54 61 62 6C 65              vo.VaryTable

That strings seems to be related with the commands "fanconpolicy" and "fanconmode"
I was reviewing what you wrote here about the policy
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-227226

Policy
0: Full
1: Auto (default)
2: Manual

Select
FF: Ram default
else: Rom default (default)

Active
0: Remove
FF: Use (default)

And a couple of commands examples from DECR-1000 output you posted yesterday:

> fanconmode get 7
fanconmode get 7
fancon No:07
mode03: Minimum

> fanconmode get 8
fanconmode get 8
fancon No:08
mode01: Vary Table

So... we have all this posible values, right ? (and the value "unknown" that is pointless, it just represents an "invalid" value)

fanconpolicy // 0=Full, 1=Auto, 2=Manual
fanconmode // 1=VaryTable, ?=VaryServo, 3=Minimun

Spoiler

Im guessing "VaryServo" is 2

But the real question is... at which offset of the thermal config area is stored the "fanconmode" ?
Im wondering if is missing it in your code struct (maybe is one of the bytes we are labeling as unknown?)... or there is something i dont understand related with this modes