Hi everyone,
Blog post of the weekly report #4 at
http://maltanar.blogspot.com/2010/06/gsoc-weekly-report-4.html - text
also available below.
I'd appreciate some views/suggestions on the memory sharing issues,
and on how to provide function signatures to the
marshaller/unmarshaller.
Regards,
Yaman
Weekly Report #4
Submitted on 2010-06-14
Covers 2010-06-07 to 2010-06-14
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
My exchange period in Sweden ended and I had to move back to Turkey,
so couldn't really get as much work done as I'd like to, but now I
have access my evil scientist laboratory headquarters 
I'll be based
here for the rest of the summer.
I now have an RPC implementation for DSP->GPP calls, composed of four
parts: DSP-side function stubs, DSP-side marshaller/unmarshaller and
transport functions, GPP side marshaller/unmarshaller and transport
functions, and GPP side stubs/invokers. No dynamic loading on the GPP
side, the invocation is a simple static jump table and there's no
support for pointer parameters but it works fine otherwise.
had some time to play around with kernel module loading. didn't really
discover anything groundbreaking, but noticed that C6Run doesn't work
with the *.ko's that came with my Ångström. probably version
differences which won't be an issue if one builds C6Run libraries and
the distro itself using OpenEmbedded, but in the other case we could
have a config file on the Beagle which points to the appropriate
module filenames, and load these ones at startup instead.
Plans and Tasks
right now the stubs are doing most of the work for marshalling, this
will make it difficult to add new RPC functions in the future. have a
marshaller that can pack variable number of parameters into the data,
I've already have had some success with this. I'm planning to have a
string "function signature" for each stub, and feed this along with
all the parameters to the marshaller. bad idea? should each stub keep
doing its own packing to increase efficiency?
passing pointer parameters is still a big issue due to memory sharing,
we have to make sure that any direct memory pointers are mutually
accessible after address translation, look into this.
finalize and commit my initial group of DSP-side wrappers with integer
parameters and return types (mostly is*() functions from ctype.h)
Risks, issues, blockers
Memory issues still here: C6RunLib can utilize the CMEM interface to
get DSP-GPP shareable contiguous memory regions, but there is no CMEM
on the DSP side - what'll be the cure for this? force allocating
everything from POOL buffers if they are to be passed as RPC
parameters? set the DSP linker parameters to allocate the heap from a
pre-determined shared region and do the address translation manually?
copy and back-copy the DSP-side buffers manually into/out of the
message buffers during marshalling and unmarshalling (but how do we
know the size of a void* buffer, for example?)?