sandungas
Developer
@M4j0r the other day i realized about something i would like to comment with you, this is going to be tricky because the theory is based in a bunch of small details and speculations but i think it makes sense enought to drive you crazy a bit
The long story short is i think the thermal configs for sherwoods are only 0x1B0 lenght (instead of the 0x200 in mullions)
Pleae take a look at this table when reading my brainstroming and click in the arrow at top of the table to sort rows for sherwoods
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table
And this page too
https://www.psdevwiki.com/ps3/Template:Syscon_checksums
I was thinking in what im going to explain since some weeks ago, my first inspiration came from how the checksum protected regions are organized. In mullion there are 5 cheksums and we are considering the first checksum contains 2 areas named "Platform Config" and "Hardware Config" (0x100 bytes each). This names and the way how are splitted are custom, given by you time ago
But for the syscon firmware this 2 areas are a single entity, at least for the matter of how the checksums was implemented, is an area of 0x200 bytes protected by a single checksum
Eventually i was lurking the syscon FLASH dumps in a hexeditor and i realized the mullion firmwares contains 5 error strings associated with the 5 checksums (are posted at bottom of the second link) and we can see the codenames of the 5 regions in them
The first checksum belongs to a region codenamed MP_AREA. I cant imagine what means the MP but i guess we should join together "Platform Config" and "Hardware Config" in the same way sony is doing (and eventually change the custom name to the official codename if at some point we figure what means the MP)
Anyway.. thats another story... my main point about this is the regions we are naming "Platform Config" and "Hardware Config" are located together and consecutivelly (without gaps in between them, as said... it seems syscon firmware considers is a single region)
The other day, when you published the syscon patches for the frankenstein RSX (that requires writing in the region we are naming "Hardware Config") i realized in sherwoods both areas was moved before the thermal config region... and that made me return to the previous brainstorming
The point is... in shwerood there is only 1 checksum, protecting 0x800 bytes (includes several regions). I always though they never "unprotected" regions by removing or modifying the checksum protected regions but i was not able to make them match until now
As you can see, in the current version of the table im considering the region named "Config Ring" and "Debug 2" with 0x200 bytes each (names taken from the official codenames of the error strings) are located inmediatly after the "thermal config" region because this allows me to locate all the regions that was protected by checksums in mullions together in sherwoods
In other words... sherwoods only have a checksum, located at the last 2 bytes of the "Debug 2" (just because is the last checksum protected region)... but the checksum is protecting the same regions than mullion, is like they was trying to keep some kind of "backward compatibility" for the checksums
The region we are naming "On/Off Count/Time" is the first not protected by a checksum, and is located inmediatly after "Debug 2" region (in other words, inmedatly after the checksum of the previous 0x800 bytes)
The problem is more obvious in a hexeditor... go to offset 0x800 and drag the mouse to highlight the previous 0x400 ("Config Ring" and "Debug 2") and this position is the end offset of the "thermal region"
In other words... if we substract 0x400 to 0x800 it means the "thermal config" ends at 0x400
So... it seems the thermal config in sherwoods have a size of 0x1B0 (starts at 0x250 and ends at 0x400)
We always was considering the thermal config in sherwoods had a size of 0x200 (like mullion), but im wondering if we should consider that have a different size (in that case it would be needed to update some pages in wiki), what do you think ?, im asking with the hope you have some proof to confirm or debunk this theory about the thermal config size in sherwoods
The long story short is i think the thermal configs for sherwoods are only 0x1B0 lenght (instead of the 0x200 in mullions)
Pleae take a look at this table when reading my brainstroming and click in the arrow at top of the table to sort rows for sherwoods
https://www.psdevwiki.com/ps3/Talk:SC_EEPROM#Experimental_table
And this page too
https://www.psdevwiki.com/ps3/Template:Syscon_checksums
I was thinking in what im going to explain since some weeks ago, my first inspiration came from how the checksum protected regions are organized. In mullion there are 5 cheksums and we are considering the first checksum contains 2 areas named "Platform Config" and "Hardware Config" (0x100 bytes each). This names and the way how are splitted are custom, given by you time ago
But for the syscon firmware this 2 areas are a single entity, at least for the matter of how the checksums was implemented, is an area of 0x200 bytes protected by a single checksum
Eventually i was lurking the syscon FLASH dumps in a hexeditor and i realized the mullion firmwares contains 5 error strings associated with the 5 checksums (are posted at bottom of the second link) and we can see the codenames of the 5 regions in them
The first checksum belongs to a region codenamed MP_AREA. I cant imagine what means the MP but i guess we should join together "Platform Config" and "Hardware Config" in the same way sony is doing (and eventually change the custom name to the official codename if at some point we figure what means the MP)
Anyway.. thats another story... my main point about this is the regions we are naming "Platform Config" and "Hardware Config" are located together and consecutivelly (without gaps in between them, as said... it seems syscon firmware considers is a single region)
The other day, when you published the syscon patches for the frankenstein RSX (that requires writing in the region we are naming "Hardware Config") i realized in sherwoods both areas was moved before the thermal config region... and that made me return to the previous brainstorming
The point is... in shwerood there is only 1 checksum, protecting 0x800 bytes (includes several regions). I always though they never "unprotected" regions by removing or modifying the checksum protected regions but i was not able to make them match until now
As you can see, in the current version of the table im considering the region named "Config Ring" and "Debug 2" with 0x200 bytes each (names taken from the official codenames of the error strings) are located inmediatly after the "thermal config" region because this allows me to locate all the regions that was protected by checksums in mullions together in sherwoods
In other words... sherwoods only have a checksum, located at the last 2 bytes of the "Debug 2" (just because is the last checksum protected region)... but the checksum is protecting the same regions than mullion, is like they was trying to keep some kind of "backward compatibility" for the checksums
The region we are naming "On/Off Count/Time" is the first not protected by a checksum, and is located inmediatly after "Debug 2" region (in other words, inmedatly after the checksum of the previous 0x800 bytes)
The problem is more obvious in a hexeditor... go to offset 0x800 and drag the mouse to highlight the previous 0x400 ("Config Ring" and "Debug 2") and this position is the end offset of the "thermal region"
In other words... if we substract 0x400 to 0x800 it means the "thermal config" ends at 0x400
So... it seems the thermal config in sherwoods have a size of 0x1B0 (starts at 0x250 and ends at 0x400)
We always was considering the thermal config in sherwoods had a size of 0x200 (like mullion), but im wondering if we should consider that have a different size (in that case it would be needed to update some pages in wiki), what do you think ?, im asking with the hope you have some proof to confirm or debunk this theory about the thermal config size in sherwoods
Last edited: