PXI Services: Difference between revisions
Created page with "= PXI Services = The 'pxi' sysmodule contains the following services: *PxiFS0 *PxiFS1 *PxiFSB *PxiFSR *PxiPM *pxi:am9 *pxi:dev *pxi:mc *pxi:ps3" |
m Add to Category:Services |
||
| (11 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
= PXI Services = | = PXI Services = | ||
The 'pxi' sysmodule contains the following services: | The 'pxi' sysmodule contains the following services: | ||
*PxiFS0 | *[[Filesystem services PXI|PxiFS0]] | ||
*PxiFS1 | *[[Filesystem services PXI|PxiFS1]] | ||
*PxiFSB | *[[Filesystem services PXI|PxiFSB]] | ||
*PxiFSR | *[[Filesystem services PXI|PxiFSR]] | ||
*PxiPM | *[[Process Manager Services PXI|PxiPM]] | ||
*pxi:am9 | *[[Application Manager Services PXI|pxi:am9]] | ||
*pxi:dev | *[[Gamecard Services PXI|pxi:dev]] | ||
*pxi:mc | *[[Development Services PXI|pxi:mc]] | ||
*pxi: | *[[Process Services PXI|pxi:ps9]] | ||
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_Registers|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. | |||
The PXI protocol is bidirectional - both processors can host a PXI service for a given pxi_id. In practice, Process9 hosts all but one of the services (pxi_11 is hosted by pxi-module instead). Each pxi_id corresponds to a 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 [[SVC|svcBreak]] when it receives a PXI command with a pxi_id where another command 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). | |||
=PXI service "pxi_11"= | |||
{| class="wikitable" border="1" | |||
|- | |||
! Command Header | |||
! Description | |||
|- | |||
| 0x00010040 | |||
| PublishToSubscriber - this exposes [[Services|"srv:" notifications]] to the Process9-side using [[SRV:PublishToSubscriber]] (with flags=1), to allow sending card-insert notifications etc. directly to ARM11. | |||
|} | |||
==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 = pxi_11 | |||
[[Category:Services]] | |||
Latest revision as of 13:27, 18 September 2024
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.
The PXI protocol is bidirectional - both processors can host a PXI service for a given pxi_id. In practice, Process9 hosts all but one of the services (pxi_11 is hosted by pxi-module instead). Each pxi_id corresponds to a 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 command 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).
PXI service "pxi_11"
| Command Header | Description |
|---|---|
| 0x00010040 | PublishToSubscriber - this exposes "srv:" notifications to the Process9-side using SRV:PublishToSubscriber (with flags=1), to allow sending card-insert notifications etc. directly to ARM11. |
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 = pxi_11