Difference between revisions of "PXI Registers"
Line 2: | Line 2: | ||
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 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]] | + | 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, 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. | + | 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== | ==Request== |
Revision as of 22:58, 9 April 2015
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
Registers
Old3DS | Name | Address | Width | Used by |
---|---|---|---|---|
Yes | PXI_SYNC9 | 0x10008000 | 4 | |
Yes | PXI_????9 | 0x10008003 | 1 | |
Yes | PXI_CNT9 | 0x10008004 | 4 | |
Yes | PXI_RECV_FIFO9 | 0x10008008 | 4 | |
Yes | PXI_SYNC11 | 0x10163000 | 4 | |
Yes | PXI_CNT11 | 0x10163004 | 4 | |
Yes | PXI_SEND11 | 0x10163008 | 4 | |
Yes | PXI_RECV_11 | 0x1016300C | 4 |
The PXI registers are similar to those on DS.
PXI_SYNC
Bit | RW | Description |
---|---|---|
0-3 | R | Data input from PXI_SYNC Bit8-11 of remote CPU (00h..0Fh) |
8-11 | R/W | Data output to PXI_SYNC Bit0-3 of remote CPU (00h..0Fh) |
13 | W | Send IRQ to remote CPU (0=None, 1=Send IRQ) |
14 | R/W | Enable IRQ from remote CPU (0=Disable, 1=Enable) |
23 | ? | ? |
PXI_CNT
Bit | RW | Description |
---|---|---|
0 | R | Send Fifo Empty Status (0=Not Empty, 1=Empty) |
1 | R | Send Fifo Full Status (0=Not Full, 1=Full) |
2 | R/W | Send Fifo Empty IRQ (0=Disable, 1=Enable) |
3 | W | Send Fifo Clear (0=Nothing, 1=Flush Send Fifo) |
8 | R | Receive Fifo Empty (0=Not Empty, 1=Empty) |
9 | R | Receive Fifo Full (0=Not Full, 1=Full) |
10 | R/W | Receive Fifo Not Empty IRQ (0=Disable, 1=Enable) |
14 | R/W | Error, Read Empty/Send Full (0=No Error, 1=Error/Acknowledge) |
15 | R/W | Enable Send/Receive Fifo (0=Disable, 1=Enable) |