By entering this site you need to consent to the use of cookies and their functional use according to this privacy policy. Cookies help us to provide the functional services of the website. Kindly read the below message of use and consent to the use.
The following cookies are stored and shared when accessing this website:
- Internal cookies for the MediaWiki site. This is used for user authentication and article modifications.
- Third-party cookies from Google providing services for Google AdSense and Google Analytics
We will never use data collected outside of the above scope.
move protocol stuff to PXI Services since it is a FIRM construct
Line 1:
Line 1:
−
= 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).