Editing Talk:Undocumented SPU Channels

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
[[Category:Software]]
== Channel 67 ==
== Channel 67 ==


Line 7: Line 9:




<pre>uint8_t expectedConfigRing65[];
<code>uint8_t expectedConfigRing65[];
uint8_t expectedConfigRing90[];
uint8_t expectedConfigRing90[];
    
    
Line 42: Line 44:
     }
     }
    
    
}</pre>
}</code>


== Channel 64 ==
== Channel 64 ==
Used to control isolation-mode persistent storage (w:ch72/r:ch73) and probably config ring storage (r:ch67).


Other values written to channel 64 (on bootldr): 0x00, 0x02, 0x20000
Other values written to channel 64 (on bootldr): 0x00, 0x02, 0x20000
=== Isolation-mode control flags ===
* 0x0 : clear config ring storage?
* 0x2 : call hardware isolation exit function
* (0x1 | 0x2) = 0x3 : call hardware isolation load function, it will wait for isolated binary address through SPU_RdSigNotify1 & SPU_RdSigNotify2
* 0x10000 : reset persistent storage r/w index (writes to ch72 and reads from ch73 will start at index zero)
* 0x20000 : lock persistent storage write
* 0x40000 : lock persistent storage read
* (0x20000 | 0x40000) = 0x60000 : lock persistent storage r/w (reading from ch73 will return zero as long as the current isolated session lasts)
== Channel 13 (SPU_RdMachStat) ==
This channel used for some check before to write 0x60000 to ch64 (appldr, lv1ldr, lv2ldr, isoldr)
<pre>uint32_t spu_machine_status = spu_rdch(13);
if ((spu_machine_status & 0x40000) != 0)
{
  return -1;
}
else
{
  spu_wrch(64, 0x60000);
  return 0;
}
</pre>
== Some observations and questions ==
* spu_rdchcnt() returns 1 on the following channels: 64, 69, 70, 71, 74, but 0 on 73, why?
* It seems that LS isn't erased when calling the isolation load function from ch64, could we take some advantage from that?
* How many other undocumented channels exists? Is there any possibility to determine if specific channel exists?
* What is the purpose of other undocumented channels? H/W decryption facility? Validation? Something else?
* Is it possible to refill config ring storage?
* http://paste.ubuntu.com/23453452/
== Utility functions for channel fuzzing ==
<syntaxhighlight lang="c">
uint32_t get_channel_count(uint32_t n) {
static uint32_t f[] __attribute__ ((aligned(16))) = {
0x01E00003, // rchcnt $3, $ch(?)
0x35000000, // bi $LR
0x4020007F, // lnop
};
f[0] &= ~(0x7F << 7);
f[0] |= (n & 0x7F) << 7;
uint32_t (* pf)(void) = (void*)&f;
si_sync();
return pf();
}
uint32_t read_channel(uint32_t n) {
static uint32_t f[] __attribute__ ((aligned(16))) = {
0x01A00003, // rdch $3, $ch(?)
0x35000000, // bi $LR
0x4020007F, // lnop
};
f[0] &= ~(0x7F << 7);
f[0] |= (n & 0x7F) << 7;
uint32_t (* pf)(void) = (void*)&f;
si_sync();
return pf();
}
void write_channel(uint32_t n, uint32_t value) {
static uint32_t f[] __attribute__ ((aligned(16))) = {
0x21A00003, // wrch $ch(?), $3
0x35000000, // bi $LR
0x4020007F, // lnop
};
f[0] &= ~(0x7F << 7);
f[0] |= (n & 0x7F) << 7;
void (* pf)(uint32_t) = (void*)&f;
si_sync();
pf(value);
}
</syntaxhighlight>
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)
Retrieved from "http://www.psdevwiki.com/ps3/Talk:Undocumented_SPU_Channels"