GSoC Weekly Report #2

Weekly Report #2

Submitted on 2010-05-31

Covers 2010-05-23 to 2010-05-31

Corresponding Draft Schedule Item:

Familiarize with DSP/BIOS Link and its various modules. Experiment with GPP-DSP communication and compilation processes to identify potential issues and useful features. Review existing RPC protocols and create one suitable for DSP-GPP communication over DSP/BIOS Link.

Status and Accomplishments

• initially built DSP/Link module and examples using OpenEmbedded
• modified DSP/Link examples and built them using the ti-devshell script with the OE toolchain
• successfully compiled and tried out C6RunApp on the BeagleBoard, using both OE and CodeSourcery toolchains
• created the dsp-rpc-posix branch at http://gforge.ti.com/svn/dspeasy/C6RunApp/branches/dsp-rpc-posix (no commits yet, though)
• did some more studying of the C6RunApp source code, better understanding when one sees it in action

Plans and Tasks

• more experimentation with DSP<->GPP communication and especially with DSP side code
• benchmark some DSP/Link on the Beagle, mainly NOTIFY and MSGQ, may be useful to have numbers around
• study how C6RunLib does RPC calls from GPP to DSP to get some inspiration for implementing the reverse
• come up with a finalized list for the order in which the POSIX wrappers will be written

Risks, issues, blockers

• probably not an issue but worth a mention: the speed at which DSP/Link conveys messages and notifications may have a performance impact, but this isn't expected to be a major issue since the primary goal is easy prototyping on the DSP anyway
• how best to determine which C standard library functions are used the most often / are the most useful? (aside from personal experience) statistics? polls?
• the original project definition contains a few too many references to POSIX - Daniel Allred pointed out that there are many fine details and many, many functions in the standard itself. full POSIX compatibility could be an eventual goal (but why full compliance is such a good idea is open to discussion) but it looks wiser and more productive to start and progress with commonly used / useful functions.
• providing easier prototyping will lower the entry level and this may, in turn, mean there will be more inexperienced behavior regarding the dsp. some basic "baby-sitting" (perhaps checking/loading the needed kernel modules automatically at the app startup, and catching Ctrl-C signals so we can cleanup before the exit) may be necessary.
• DSP works with physical addresses, while the GPP works with virtual ones. what if the user wants to print a string which is allocated from the DSP heap? the issue can be handled by copying buffers to POOL buffers and passing them in this manner (this is what C6RunApp currently does) but the issue itself is worth further investigation. is there a better approach? will POOL buffer copying be sufficient, or is there something it won't be able to handle correctly?