Difference between revisions of "PXI Services"
Steveice10 (talk | contribs) m (More service links.) |
(move protocol stuff to PXI Services since it is a FIRM construct) |
||
| Line 14: | Line 14: | ||
Each PXI service can only have one session open for it at a time. | Each PXI service can only have one session open for it at a time. | ||
| + | |||
| + | = Protocol = | ||
| + | The communication protocol for normal PXI commands is documented below. The size of cmd_buf is calculated from the cmd_hdr. With newer FIRM the total size for command header + buffer must be at most 0x40 words, otherwise Process9 will panic. | ||
| + | |||
| + | Each pxi_id corresponds to a Process9 PXI [[PXI_Services|command-handler]](called from threads) which handles the actual command processing. With newer FIRM the pxi_id must be in a certain range. | ||
| + | |||
| + | There's a dedicated Process9 thread for receiving data from PXI(in newer FIRM this is the main-thread), once it finishes receiving a request it copies the cmd_buf into a buffer for the corresponding pxi_id then signals an event so that the cmd-handler thread can process it. Once a cmd-handler thread finishes processing a command, the thread itself then sends the response over PXI. This means that multiple commands for different pxiIDs can be be handled at the same time, even when one cmd-handler completely hangs/etc for example. | ||
| + | |||
| + | Process9 will execute [[SVC|svcBreak]] when it receives a PXI command with a pxi_id where another cmmand with that same pxi_id is still being processed by the command-handler(this won't happen with commands sent by the ARM11 PXI-module, since it waits for the command reply before sending another command request for that same pxi_id). | ||
| + | |||
| + | ==Request== | ||
| + | A11->A9 (u32) pxi_id | ||
| + | A11->A9 (u32) cmd_hdr | ||
| + | A11->A9 (u32[]) cmd_buf | ||
| + | |||
| + | ==Response== | ||
| + | A9->A11 (u32) pxi_id | ||
| + | A9->A11 (u32) cmd_hdr | ||
| + | A9->A11 (u32[]) cmd_buf | ||
| + | |||
| + | ==pxi_id== | ||
| + | 0 = pxi_mc | ||
| + | 1 = pxi_fs | ||
| + | 2 = pxi_fs | ||
| + | 3 = pxi_fs | ||
| + | 4 = pxi_fs | ||
| + | 5 = pxi_pm | ||
| + | 6 = pxi_dev | ||
| + | 7 = pxi_am | ||
| + | 8 = pxi_ps | ||
| + | 9 = stubbed | ||
Revision as of 22:18, 12 December 2015
PXI Services
The 'pxi' sysmodule contains the following services:
Each of these services has up to 4 static IPC buffers of size 0x1000. When any of these service ports are sync:d, the IPC cmdbuf (TLS+0x80+) is sent over PXI to the ARM9.
Each PXI service can only have one session open for it at a time.
Protocol
The communication protocol for normal PXI commands is documented below. The size of cmd_buf is calculated from the cmd_hdr. With newer FIRM the total size for command header + buffer must be at most 0x40 words, otherwise Process9 will panic.
Each pxi_id corresponds to a Process9 PXI command-handler(called from threads) which handles the actual command processing. With newer FIRM the pxi_id must be in a certain range.
There's a dedicated Process9 thread for receiving data from PXI(in newer FIRM this is the main-thread), once it finishes receiving a request it copies the cmd_buf into a buffer for the corresponding pxi_id then signals an event so that the cmd-handler thread can process it. Once a cmd-handler thread finishes processing a command, the thread itself then sends the response over PXI. This means that multiple commands for different pxiIDs can be be handled at the same time, even when one cmd-handler completely hangs/etc for example.
Process9 will execute svcBreak when it receives a PXI command with a pxi_id where another cmmand with that same pxi_id is still being processed by the command-handler(this won't happen with commands sent by the ARM11 PXI-module, since it waits for the command reply before sending another command request for that same pxi_id).
Request
A11->A9 (u32) pxi_id A11->A9 (u32) cmd_hdr A11->A9 (u32[]) cmd_buf
Response
A9->A11 (u32) pxi_id A9->A11 (u32) cmd_hdr A9->A11 (u32[]) cmd_buf
pxi_id
0 = pxi_mc 1 = pxi_fs 2 = pxi_fs 3 = pxi_fs 4 = pxi_fs 5 = pxi_pm 6 = pxi_dev 7 = pxi_am 8 = pxi_ps 9 = stubbed