BeagleBoard/GSoC/2010 Projects/C6Run/Documentation - Revision history

Jsujjava: Add Category BeagleBoard

2011-05-06T18:36:53Z

Add Category BeagleBoard

Maltanar: typo fix

2010-08-16T15:06:34Z

typo fix

Maltanar: typo fix

2010-08-16T15:04:12Z

typo fix

Maltanar: typo fix

2010-08-16T15:03:47Z

typo fix

Maltanar: /* Receiving and Responding to RPC Requests */

2010-08-16T15:02:03Z

‎Receiving and Responding to RPC Requests

Maltanar: /* Structure of the RPC Package */

2010-08-16T14:59:36Z

‎Structure of the RPC Package

Maltanar: typo fix

2010-08-16T14:59:08Z

typo fix

Maltanar: typo fix

2010-08-14T19:00:55Z

typo fix

Maltanar: /* Usage */

2010-08-12T14:27:56Z

‎Usage

Maltanar: /* Usage */

2010-08-11T14:14:21Z

‎Usage

← Older revision		Revision as of 18:36, 6 May 2011
Line 380:		Line 380:

	in build/gpp_libs/C6Run.h		in build/gpp_libs/C6Run.h
		+	[[Category:BeagleBoard]]

@@ Line 342: / Line 342: @@
 We can see that the "same" buffer actually exists in three different locations (main memory, DSP cache, ARM cache), all of which can contain totally different data - in this case it is said that they are not coherent, and that we have a cache coherency problem.
-In most cached systems, there are cache coherency protocols which prevent these situations from occuring. The TMS320C64x+ DSP Cache User's Guide states:
+In most cached systems, there are cache coherency protocols which prevent these situations from occurring. The TMS320C64x+ DSP Cache User's Guide states:
 In the following cases, it is your responsibility to maintain cache coherence:

@@ Line 184: / Line 184: @@
 * '''RPC_MSG_RESPONSE'''    sent by the GPP side as a reply to every RPC request, both generic and specialized
 * '''RPC_MSG_MALLOC'''      specialized RPC function call request, for memory allocation
-* '''RPC_MSG_FREE'''        specialized RPC function call request, for memory dellocation
+* '''RPC_MSG_FREE'''        specialized RPC function call request, for memory deallocation
 * '''RPC_MSG_TRANSLATE'''   specialized RPC function call request, for address translation

@@ Line 165: / Line 165: @@
 === Address Translations and RPC Memory ===
-The GPP side server application is responsible for managing the shared memory regions used in RPC. Central to its workings is the CMEM kernel module which allocates contiguous memory regions and provides both physical and virtual addresses for accessing these. Since the CMEM module offers only physical-from-virtual address translation with base addresses, DSP-RPC-POSIX maintains an internal list of allocated buffers and their sizes to facilitate bidirectional address translation for any memory region lying within the allocated areas (ie, not just the allocated base addresses but incremented pointers referring to somewhere within that allocated block are also translateable). The list is kept as a doubly-linked list, which grows with rpc_malloc calls and shrinks with rpc_free calls. Using rpc_translate_address (which is also exposed through RPC on the DSP-side), the list can be searched to perform virtual->physical or physical->virtual translations. If any address translation goes unsuccessful (no corresponding allocation entries are found) the input address is returned unchanged, which can be used to detect if something has gone wrong.
+The GPP side server application is responsible for managing the shared memory regions used in RPC. Central to its workings is the CMEM kernel module which allocates contiguous memory regions and provides both physical and virtual addresses for accessing these. Since the CMEM module offers only physical-from-virtual address translation with base addresses, DSP-RPC-POSIX maintains an internal list of allocated buffers and their sizes to facilitate bidirectional address translation for any memory region lying within the allocated areas (ie, not just the allocated base addresses but incremented pointers referring to somewhere within that allocated block are also translatable). The list is kept as a doubly-linked list, which grows with rpc_malloc calls and shrinks with rpc_free calls. Using rpc_translate_address (which is also exposed through RPC on the DSP-side), the list can be searched to perform virtual->physical or physical->virtual translations. If any address translation goes unsuccessful (no corresponding allocation entries are found) the input address is returned unchanged, which can be used to detect if something has gone wrong.
 == DSP Side Architecture ==

@@ Line 161: / Line 161: @@
 === Receiving and Responding to RPC Requests ===
-The important task of servicing RPC requests - that is, carrying out the recieve-unmarshal-locate-execute-return steps, is currently done inside the C I/O service routines (since the RPC transport is carried out via the C I/O transport), located inside build/gpp_libs/cio_ipc.c.
+The important task of servicing RPC requests - that is, carrying out the receive-unmarshal-locate-execute-return steps, is currently done inside the C I/O service routines (since the RPC transport is carried out via the C I/O transport), located inside build/gpp_libs/cio_ipc.c.
 === Address Translations and RPC Memory ===

@@ Line 141: / Line 141: @@
 * '''Signature:''' function signature describing how the parameters section will be unpacked
 * '''Params:''' the function parameters, packed without any size promotions or alignment
-* '''0:''' the null-terminating zero signalling the end of the package
+* '''0:''' the null-terminating zero, marking the end of the package
 == GPP Side Architecture ==

@@ Line 5: / Line 5: @@
 "What functions are available on the GPP side, then?" one might ask. The answer is pretty much "everything that the hardware can do" or "everything you can do in your regular operating system" or something along the lines of that. From basic tasks like accessing the file system to more sophisticated things like sending a file over FTP, there's a myriad of possibilities.
-Two reasons as to why DSP->GPP RPC is desireable would be: access to otherwise (directly) inaccessible features and being able to reuse existing code. The reason why C6RunApp exists is because it's messy to write and run code for the DSP, especially if all you want to do is try out or experiment with things (prototyping). C6RunApp makes your life easier as a DSP-side developer by offering you easy compilation/running and access to console I/O (which is actually a limited form of RPC); DSP-RPC-POSIX expands this by granting you access to virtually any existing functionality you have on the GPP side.
+Two reasons as to why DSP->GPP RPC is desirable would be: access to otherwise (directly) inaccessible features and being able to reuse existing code. The reason why C6RunApp exists is because it's messy to write and run code for the DSP, especially if all you want to do is try out or experiment with things (prototyping). C6RunApp makes your life easier as a DSP-side developer by offering you easy compilation/running and access to console I/O (which is actually a limited form of RPC); DSP-RPC-POSIX expands this by granting you access to virtually any existing functionality you have on the GPP side.
 = Usage =

@@ Line 98: / Line 98: @@
 * '''avoid using doubles/floats in rpc_*printf functions! there are known alignment mismatch problems between the DSP and the GPP'''
-= Architectural Documentatin =
+= Architectural Documentation =
 == RPC Overview ==

@@ Line 90: / Line 90: @@
   c6runapp-cc --rpc --C6Run:debug hello_world.c -o hello_world_dsp
 </tt>
 = Architectural Documentatin =

← Older revision		Revision as of 14:14, 11 August 2010
Line 86:		Line 86:

	In case you run into problems with your application (such as unexpected termination or error messages), you can provide the --C6Run:debug switch while compiling to use the debug libraries for the build, and obtain C6Run/RPC/CMEM debug output when the application is ran.		In case you run into problems with your application (such as unexpected termination or error messages), you can provide the --C6Run:debug switch while compiling to use the debug libraries for the build, and obtain C6Run/RPC/CMEM debug output when the application is ran.
		+
		+	<tt>
		+	c6runapp-cc --rpc --C6Run:debug hello_world.c -o hello_world_dsp
		+	</tt>

	= Architectural Documentatin =		= Architectural Documentatin =