fanservo just returns "Sorry, not suppoted." and fanservostat isn't available on Cytology.
Hmm, it could be one of the few cases where a syscon feature is available for retails but not for pre-retails... just because there was something related with it that was not ready for the PS3 release date
Im saying this because this commands exists even in the syscon firmware of the last superslim motherboard, as far i remember from what you wrote in wiki the first SW was missing them, but in SW2 they re-implemented one of them and in SW3 they reimplemented the other
Dunno, never minds, we are entering in tricky features and we have other more interesting things to comment
Ok,i was asking incase you had a 100% confirmation of it, but thats good enought for me
And yeah... even the syntax of the command (fantbl ---> select) looks similar to the other codenames, and it should be located inside each fantable
These are all not available. I double check everything by testing them and checking the firmware.
Ok, sorry for the brainstorming, it was just a blindshot
The special section differs between Cookie and Cytology, so it doesn't match.
Well, the point was that we have a unknown0 byte with value 0x00 in retails that seems to be inherited from pre-retails, the fact that is 0x00 means that is something otherway it would be 0xFF (that uses to represent an "erased" byte that never was written), sony likes it because exits up to the last superslim motherboard, actually that area of the struct had an important change specific for sherwoods (one more byte was added inmediatly after the unknown0) that created a displacement of the bytes that comes next to it
Actually... while thinking in this today i also thought maybe what they did was to increase the lenght of the "fan_shutdown_time" for sherwood to 2 bytes
That might be interesting, I found it in my notes, it maps the fantbl number to the thermal sensor id and the eeprom region:
Code:
Cytology
0 -> 0x00: 0x3B00 "1st BE Primary"
1 -> 0x01: 0x3B40 "RSX Primary"
2 -> 0x20: 0x3B80 "? (no name)"
3 -> 0x21: 0x3BC0 "? (no name)"
4 -> 0x02: 0x3C00 "XDR Primary"
5 -> 0x14: 0x3CC0 "SB"
6 -> 0x0F: 0x3C80 "GbE"
7 -> 0x0A: 0x3C40 "Air Intake"
Cookie OLD
0 -> 0x00: 0x3300 "1st BE Primary"
1 -> 0x01: 0x3340 "RSX Primary"
? -> 0x03: 0x3380 "BE VR"
3 -> 0x14: 0x33C0 "SB"
? -> 0x15: 0x3400 "EE+GS"
Cookie NEW
0 -> 0x00: 0x3300 "1st BE Primary"
1 -> 0x01: 0x3380 "RSX Primary"
? -> 0x14: 0x3400 "SB"
Really interesting
Let me make an small change in the offsets to make it a bit more intuitive, im going to replace the "absolute offsets" by "relative offsets" (from the start of the thermal config area), reorder the cytology ones based in that offset, some notes, and the sherwoods
Code:
Cytology (fantbl = 0x40 size each)
0 -> 0x00: + 0x0 "1st BE Primary"
1 -> 0x01: + 0x40 "RSX Primary"
2 -> 0x20: + 0x80 "? (no name)"
3 -> 0x21: + 0xC0 "? (no name)"
4 -> 0x02: + 0x100 "XDR Primary"
7 -> 0x0A: + 0x140 "Air Intake"
6 -> 0x0F: + 0x180 "GbE"
5 -> 0x14: + 0x1C0 "SB"
Cookie OLD (fantbl = 0x40 size each)
0 -> 0x00: + 0x0 "1st BE Primary"
1 -> 0x01: + 0x40 "RSX Primary"
? -> 0x03: + 0x80 "BE VR"
3 -> 0x14: + 0xC0 "SB"
? -> 0x15: + 0x100 "EE+GS"
Cookie NEW (fantbl = 0x80 size each)
0 -> 0x00: + 0x0 "1st BE Primary"
1 -> 0x01: + 0x80 "RSX Primary"
? -> 0x14: + 0x100 "SB"
Sherwood (fantbl = 0x70 size each)
0 -> 0x00: + 0x0 "1st BE Primary"
1 -> 0x01: + 0x70 "RSX Primary"
? -> 0x14: + 0xE0 "?" // probably SB
Actually, your cytology have 8 fantables, if we multiply the fantable size of 0x40*8 we have the complete 0x200 bytes of the "thermal config" area used by the fantables... so the "special section" of the struct is not inside it
While thinking in what you said the other day, that the "thermal config" area in cytology is like "composed" by different pieces at runtime that are spreaded "here and there" inside the syscon firmware functions i was thinking... ok... but there is some point where the syscon firmware joins together all that datas and creates some kind of virtual "thermal config" area in RAM ?, i didnt asked you about it but now it comes ontopic
The point is... at this point we are able to generate a chunk of 0x200 bytes that represents exactly that therorethical "thermal config" area in your cytology RAM... because you can use the syscon commands that "prints" the hex values coverted to "human readable"... so we can do the conversion in opposite direction to recover the hex values, then in a hexeditor join them in his positions, etc... (and assume some of the bytes for the "active" and the not-used FF's)
After that we can check the eepcsum of the file in PC with your python script... and you can run the "eepcsum" command to compare them... and they should match
The experiment is a bit pointless (unless you find a good use for it, or to add it in the collection of thermal configs for wiki) but i guess it should work
To solve the ? on Cookie just need to do some testing (change a value in the region and try different fantbl numbers to find it). The missing numbers (like 8 on Cytology) are generated by the firmware and not read from the EEPROM.
The value needs to be written in the "thermal config" area or in other areas ? ("board config" area, etc...)
Im asking because it seems it needs to be made 3 times:
cookie_old = COK-001 or COK-002
cookie_new = SEM-001 or DIA-001 or DIA-002
sherwood = VER-001 or newer
