AM5728: Runtime DSP function replacement from Linux

Hi,

You can refer to processors.wiki.ti.com/.../Processor_SDK_RTOS_BOOT_C66x to understand how to convert a DSP image into a binary. Then the Linux host needs to load this binary into certain DSP memory location. You need to know the entry address of DSP func0 and DSP fun1. Then in the task, using like dsp_func0 = (uint32_t (*) (void))dsp_func0_address; to execute the function.

Regards, Eric

Hi Eric,

Thanks for your reply. I believe the link you suggested is for KeyStoneI family such as C6678 and not so related to this topic. I think I know the basic approach to use hex6x to romize the total image. But in this case, they need to romize the specific function only. How to parse and extract the specific function data from elf formatted executable by using hex6x (or some other utilities) ? 

Best Regards,
NK

Hi,

The link I provided is for Keystone family but you are using the C66x of the DSP, this info also applies. Let me check how to romize a function and get back to you.

Regards, Eric

Thanks, Eric. I`ll wait for your reply here.

Best Regards,
NK

Kawada-san,

I am unclear about the usecase and why you need to create contiguous binary to implement this functionality. My recommendation would be to build a function table for the DSP functions where each function as an ID associated with it. When Linux makes calls to the DSP, it can pass the function ID as part of the message that helps the DSP determine which function needs to execute.

The other way would be to use function pointers. after the DSP binary has been loaded, the ARM Linux can send function pointer that points to the function that needs to be executed on the DSP.

If these approaches are not feasible, please provide more details on why this needs to be implemented using linker and compiler tools and not software running on the DSP?

Regards,
Rahul

PS: If you still want to explore the hex6x based tools. The documentation of creating contiguous binary/romize the binary is provided in the C6000 Compiler documentation included with CGTools in the SDK. It requires use of a .rmd file and hex6x .

Rahul-san,

I understand your points. From my thought,  the ways you suggested would be more generic manner. Or, memory overlay i mentioned in the previous mail may be feasible solution.  I think the customer wants to have OpenCL-like image replacement for DSP, just only for function calls rather than full dsp image to achieve minimal overhead in their app. Does it make sense ?

As per hex6x, i believe i`ve already know its basics and from my understanding, there is no way to romize only for the user-specified function calls. Correct ?

Best Regards,
NK

Any comments ?

Kawada-san,

In the approach that I recommended the over heard would be minimal as it would just be control code using single switch statement that will execute a different functionality based on the function ID. However if they have determined that this is not the path they want to pursue then you may be able to use openCL or the linker based technique for this implementation.

I am not the right expert to comment on hex6x and OpenCL so I will loop in the right experts to look at this issue.

Regards,
Rahul

OpenCL uses a dynamic loader integrated into the OpenCL host runtime running on A15/Linux to load OpenCL programs with OpenCL C kernels onto the DSP. The DSP functions mentioned earlier in the post somewhat correspond to OpenCL C kernels.

Here is a link to the OpenCL runtime's use of the dynamic loader: git.ti.com/.../ocl_load

More information on the C6000 dynamic loader: processors.wiki.ti.com/.../C6000_Dynamic_Loader

Ajay

Naoki Kawada said:

I've suggested another approach: Not exactly same with the above but similar approach may be memory overlay technique in C6x to realize remapping the functions to the same run address. That is described in this document:

http://www.ti.com/lit/an/spraa46a/spraa46a.pdf

This approach is unlikely to be helpful.  That application note describes (among other things) how to create an overlay within a single statically linked executable.  The use case is some part of memory is very fast, but small.  So you have multiple bits of code or data share it.  The UNION and copy table features of the linker make managing the symbols and copying things around very straightforward.  Though it does nothing with regards to managing lifetimes, i.e. making sure only one thing at a time is in the fast memory block.  At any rate, none of this seems to relate to the original problem statement.

Thanks and regards,

-George

George,

Yes, I know that. I have some experience with memory overlay in C6x and that's why i mentioned *similar*.  I thought their main goal was swapping the functions on an existing memory area. In this point of view, memory overlay is good approach. But it seems the customer does not want Self-managed approach in C6x context, but idea from A15 context.  We will ask the customer if OpenCL meets their request or not.

Best Regards,
NK