PXI Services - Revision history

ElementW: Add to Category:Services

2024-09-18T09:27:17Z

← Older revision		Revision as of 13:27, 18 September 2024
Line 55:		Line 55:
	8 = pxi_ps		8 = pxi_ps
	9 = pxi_11		9 = pxi_11

			[[Category:Services]]

Neobrain: /* PXI service "pxi_11" */

2016-08-18T15:42:07Z

PXI service "pxi_11"

← Older revision		Revision as of 19:42, 18 August 2016
Line 31:		Line 31:
	\|-		\|-
	\| 0x00010040		\| 0x00010040
	\| PublishToSubscriber - this exposes [[Services\|"srv:" notifications]] to the Process9-side, to allow sending card-insert notifications etc. directly to ARM11.		\| 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.
	\|}		\|}

Dazzozo: forgot to put this up, oops

2016-08-18T15:31:51Z

forgot to put this up, oops

← Older revision		Revision as of 19:31, 18 August 2016
Line 18:		Line 18:
	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 command-handler(called from threads) which handles the actual command processing. With newer FIRM the pxi_id must be in a certain range.		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.		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).		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, to allow sending card-insert notifications etc. directly to ARM11.
			\|}

	==Request==		==Request==

Dazzozo at 05:36, 20 May 2016

2016-05-20T03:36:54Z

← Older revision		Revision as of 07:36, 20 May 2016
Line 44:		Line 44:
	7 = pxi_am		7 = pxi_am
	8 = pxi_ps		8 = pxi_ps
	9 = ~~stubbed~~		9 = pxi_11

Dazzozo at 20:24, 12 December 2015

2015-12-12T19:24:11Z

← Older revision		Revision as of 22:24, 12 December 2015
Line 11:		Line 11:
	*[[Process Services PXI\|pxi:ps9]]		*[[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 to the ARM9.		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.		Each PXI service can only have one session open for it at a time.
Line 18:		Line 18:
	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]](called from threads) which handles the actual command processing. With newer FIRM the pxi_id must be in a certain range.		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.		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).		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).

	==Request==		==Request==

Dazzozo: move protocol stuff to PXI Services since it is a FIRM construct

2015-12-12T19:18:00Z

move protocol stuff to PXI Services since it is a FIRM construct

← Older revision		Revision as of 22:18, 12 December 2015
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

Steveice10: More service links.

2015-10-26T23:42:38Z

Steveice10: Add some links to service pages.

2015-10-11T14:22:09Z

Add some links to service pages.

← Older revision		Revision as of 18:22, 11 October 2015
Line 5:		Line 5:
	*PxiFSB		*PxiFSB
	*PxiFSR		*PxiFSR
	*PxiPM		*[[Process Manager Services PXI\|PxiPM]]
	*pxi:am9		*[[Application Manager Services PXI\|pxi:am9]]
	*pxi:dev		*pxi:dev
	*pxi:mc		*pxi:mc
	*pxi:ps9		*[[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 to the ARM9.		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.		Each PXI service can only have one session open for it at a time.

Yellows8 at 23:09, 27 March 2015

2015-03-27T22:09:23Z

← Older revision		Revision as of 01:09, 28 March 2015
Line 12:		Line 12:

	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 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.

Plutooo at 22:25, 7 September 2014

2014-09-07T20:25:45Z

← Older revision		Revision as of 00:25, 8 September 2014
Line 9:		Line 9:
	*pxi:dev		*pxi:dev
	*pxi:mc		*pxi:mc
	*pxi:~~ps3~~		*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 to the ARM9.		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.

← Older revision		Revision as of 02:42, 27 October 2015
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]]
	*[[Process Manager Services PXI\|PxiPM]]		*[[Process Manager Services PXI\|PxiPM]]
	*[[Application Manager Services PXI\|pxi:am9]]		*[[Application Manager Services PXI\|pxi:am9]]
	*pxi:dev		*[[Gamecard Services PXI\|pxi:dev]]
	*pxi:mc		*[[Development Services PXI\|pxi:mc]]
	*[[Process Services PXI\|pxi:ps9]]		*[[Process Services PXI\|pxi:ps9]]