AM5728: MessageQ questions

Rob,

I wanted to make sure you'd found:

processors.wiki.ti.com/.../Processor_SDK_Linux_IPC

This has a bit more of a Linux perspective with a lot of useful links. Hopefully it helps...

Our Linux MessageQ owner is out of town for a few days, so he will get back as soon as he returns.

Just following up on this as many days have passed.

I have noticed on the DSP running SYSBIOS the heap is created in the cfg file, explaining the absence of it in the code. Is this similar in Linux? is it being done elsewhere?

Where can I find some documentation on the sync object built into messageQ (both Linux and DSP SYSBIOS). I assume it is done that way so you can effectively use the sync object to inform the other end of the messageQ that a message is waiting and 'synchronize' the usage of access to it.

Thanks.

Rob,

Sorry for the long delay. This doc tries to help explain some of the MessageQ details:

processors.wiki.ti.com/.../MessageQ_Module

I took this statement from it:
If the destination queue is local, the message is placed on the appropriate priority linked list and the ISync signal function is called. If the destination queue is on a remote processor, the message is given to the proper transport and returns.

In the case of ARM <-> DSP, the rpmsg transport protocol is being used. rpmsg uses hardware mailboxes to synchronize the cores via interrupts.

A good example on the Linux side is in the root filesystem of our SDKs at /usr/share/ti/ti-ipc-tree/linux/src/tests/MessageQApp.c.

This video might go a long way to providing a good overview:

training.ti.com/am572x-build-run-ipc-examples

Many of the files are already in the Linux SDK and don't necessarily need to be built as the video implies.

I hope you find this useful.

Hi, Rob,

Which website is the sync object you mentioned from? Is it the MessageQ document in RTOS IPC User's Guide? The big data simple_buffer_example shows the transfer of data between ARM and DSP, but that document is for DSP only. So, not all things apply to Linux side, especially the sync object. You have looked too deep into the framework. There are APIs provided which should be used instead. The big data uses 2 heaps, one for the MessageQ setup from the first heap which is the same as other non-big data examples. For big data, it needs a large contiguous space from CMEM (as the 2nd heap) to hold the data. That is the sr1Heap in the code. The example shows how you get the MessageQ set up by calling MessageQ_create and MessageQ_open. In App_exec, it sets up CMEM and sharedRegion, then create HeapMP for big data by calling HeapMem_create. There is a HeapMem directory under big data for heap management. You should look for the heap APIs in it.

I hope these info answer your questions.

Rex

Thanks for your replies.  I'm not too deep into anything at this point.  More lost and not following.

Perhaps I can start with this One:

if we use the IPC_3_47_00_00 examples/DRA7xx_bios_elf\ex02_messageQ as an example.

In MaineDSP under either DSP it calls:

remoteProcId = MultiProc_getId("Host");

so I understand this to mean it's going out to get some handle/tag to the HOST processor.  Then you proceed to attach the IPC to this remoteProcId.... so that makes sense... each DSP will come up, run this code, reach out, find the HOST, and attach it's IPC to that host.

Also each DSP in server.c in server_init() calls Registry_addModule(..., MODULE_NAME) where MODULE_NAME is Server

so this looks like its 'registering' each DSP with a 'server' name...

Q1:  why is each DSP not using MultiProc functions?  why is it not uniquely assigning a name to Each DSP?

Then looking at the host code, the first thing is I don't see it 'registering' its name anywhere... so this raises the question of how when the DSPs ask to find the host, how they find it... where is the 'registration of the HOST hidden in this code?

Also on the Host side in MainHost.c it calls MultiProc_getId(SERVER);

since both DSPs register themselves as server is that the purposeful intent?  so when you call Ipc_attach on host side it attaches to both?

If so then in the Multiproc documentation why do you have something like:

MultiProc.setConfig("DSP", ["VIDEO", "DSS", "DSP"]);

To me this says your setting the name to DSP of the 3 available... so in our case it might be:

MultiProc.setConfig("DSP1", ["DSP1", "DSP2", "ARM"]);

or

MultiProc.setConfig("ARM",["DSP1", "DSP2", "ARM"]);

do you see the confusion?

Is this a bad example file for the AM5728 or out of date?

This just addresses how I'm perceiving the Multiproc part...

Regarding the Heap.

In SYS/BIOS, I figured out how to use your tool XGCONF, and I found that you essentially are assigning the heap in their, so even though in the listed IPC reference, you stated in the initial response it talks about calling the HEAP functions, it appears you have 'hidden' that in the SYS/BIOS so that I don't explicitly have to call that in my code... but when reading therough the wiki, it's not at first apparent why when I look at the sample code you don't have the heap assigned anywhere (because it's being done in the SYS/BIOS)...

Where in the Linux (ARM) side does that happen, or do we explicity need to do it manually in the code?

Conceptually I'm following... but I'm having lots of issues following what frunctions I DO use or Don't use, which at mandatory, etc...

Regarding the SYNC, yes in the first listed link you gave if you go down to where it talks about thread synchronization... it talks about how there is a signal and wait function...  

When I call MessageQ_put() from ARM to DSP or DSP to ARM its not clear how I use the functions.  In one sample file it shows that we can pass a parameter to get function that says basically to wait until it gets something... so that's effectively locking the processor waiting for received data...  can you ask it to 'check if there is a message and return immediately if not?  Can you setup an 'interrupt' based event mechanism so WHEN a message is sent an interrupt fires so the receiving processor responds, or is it strictly polling where the receiving processor/thread must call the Check for messages function... ie Polling for it...

So the question with sync objects is:

do we use them with interprocessor MessageQ?  or is it only local threads on the same processor that use the sync objects?  can we setup an interrupt type messageQ on the receiving processor?

Does that make sense?

Thanks very much for the support.

Sorry this is more of an understanding question so it's not very concise or perfectly clear.

Hi, Rob,

You do realize that the messageQ example you pointed out is for RTOS-RTOS application. For Linux-RTOS example, it should be under DRA7xx_linux_elf directory. For Linux-RTOS MessageQ example, all DSP cores are running as server and waiting for the message from the host, the host/App sends the message to the DSP core as indicated in the argument. Whoever gets message responds back. The ex02_messageQ is not a good example for multicore application. I'll have a DSP engineer to answer that part of question.

MessageQ_get does have a argument for timeout. MessqgeQ_FOREVER is set to 0xffff. Setting it to 0 should return immeidately. The MessageQ_get waits on a semaphore, and a mailbox interrupt releases it. It is interrupt triggered all hooks to mailbox interrupt are taken care by IPC in the background. 

It depends what your application trying to do. If it only needs to send/receive messages, then MessageQ APIs should be sufficient.

Rex. 

Thanks very much. Could the DSP engineer also answer the use of the Registry_addModule function vs using MultiProc functions, in addition to addressing the multicore question for addressing the processors.

Thanks.

Hi, Rob,

The response I got from DSP engineer is following:

" this line in the ex02_messageQ example, 

     result = Registry_addModule(&Registry_CURDESC, MODULE_NAME);

is for logging purposes only.

In MainHost.c, you’ll see this call,

     remoteProcId = MultiProc_getId(SERVER);

where SERVER is defined at the top of the file,

     #define SERVER "DSP1"

So if we wanted to use DSP2 we would change this define.

MessageQ then uses the remoteProcId found above to retrieve the name of the remote processor and uses this as a unique key for the message.

System_sprintf(msgqName, App_SlaveMsgQueName,

     MultiProc_getName(remoteProcId));

     do

     {

         status = MessageQ_open(msgqName, &Module.slaveQue);

The DSP adds its ID, xdc.global.procName="DSP1",  through the cfg file and this name has to be included in ipc.cfg.xs: var procNameAry = ["DSP1","DSP2","EVE1","EVE2","EVE3","EVE4","IPU1","IPU2","HOST"];"

If the info answer your question, please click "Resolved" button. Thanks!

Rex

Thanks that helps a lot.

Can I infer from this if the HOST wants to talk to BOTH DSPs that you would have say:
remoteProcId = MultiProc_getId(SERVER1);
remoteProcId2 = MultiProc_getId(SERVER2);

where SERVER1 and 2 are DSP1 and DSP2

then later I would call the IPC_Attach(remoteProcId);
and IPC_Attach(remoteProcId2);

would that appropriately attach the underlying hardware for IPC between the host and DSP1 and the host and DSP2?

Now this was for the RTOS RTOS example is what I understood.

If I look at the slightly different code for the LINUX-RTOS code it looks like in the host you call:

MultiProc_getName(remoteProcID)

inside a sprint function that creates a name for a message buffer to open.

I don't see any call to IPC_attach in this one?

In this case how is all the IPC setup taken care of in IPC_start?



Is there anywhere you outline what function calls I should be calling when?

So if I have a ARM running Linux and two DSPs running SYS/BIOS, what documentation can I read that will show me what functions I should be calling?

Thanks.

Hi, Rob,

All APIs are in IPC User's Guide. The IPC module APIs are in processors.wiki.ti.com/.../Ipc_Module

In RTOS-RTOS case, DSP are configured using ProcSync_PAIR, and Ipc_attach() call is needed.

In Linux-RTOS case, Linux gets configuration from LAD which is configured using ProcSync_ALL. Hence Ipc_attach() call is not needed.

IPC synchronization process is explained in the IPC module document on the behavior of different ProcSync options.

We found a gap in documentation in Linux getting configuration from LAD. We'll update the documentation accordingly.

Rex