demo_loopback.c question -> Linux Desktop SDK

Chris Jagielski

Hello!

I'm researching the filetestdemo in Desktop Linux SDK 1.0.0.7 and reading the source files.

I notice the following code is where the copy is made of the data in the test.file

for(;;)
{
 /* check and wait for message from host */
 ...

 /* read mailbox to see if any messages */
 ...

 /* INSERT PROCESSING HERE */
 memcpy(&process_buf[DNUM*TESTMSG_MAX_BUFFER], (void *)testMsg.input_addr, testMsg.input_size);
 testMsg.output_size = testMsg.input_size;
 memcpy((void *)testMsg.output_addr, &process_buf[DNUM*TESTMSG_MAX_BUFFER], testMsg.output_size);

/* write mailbox to send message to host */
 ...
 
}

How do I modify this to, say, +1 to the data in the file before I send it back out? (let's assume I create the test.file with whatever data I want, so it's just a bunch of "floats"). Thanks for your help!!

over 12 years ago

0 Paula Carrillo over 12 years ago

TI__Mastermind 39620 points

Hi Chris, testMsg.input_addr is the pointer to the input message. so you can use this pointer for accessing/processing the data. Input/Output pointers are printed in the host side (demo_filetest.c) or alternatevely you use a Jtag, add some getchar(); in the host side in order to stop it, open CCS and connect the DSP core(s) you are using, load your .out program symbols, and put some breakpoints so you can check the buffers address and data values. Buffers values can be check using memory browser.

thank you,

Paula

0 Chris Jagielski over 12 years ago in reply to Paula Carrillo

Expert 1630 points

Paula, thank you for your help.

The second option you described, using JTAG to connect to the 8681 and checking the buffers via Memory Browser, makes sense to me. However, it doesn't seem to be "automatic" in the sense of a real-time solution.

The first option is still confusing to me. I have looked through demo_filetest.c and I am having a hard time understanding how it is related to demo_loopback.c.

In the "demo_loopback" Project, main.c calls out demo_loopback_test(). This function is found in demo_loopback.c.

Is demo_loopback.c only a small functional part of the overall filetest demo? I'm now rather confused how all of these .c files are related. The demo_loopback.c file calls Mailbox functions and calls memcpy() to do the actual processing ... is this right?

0 Paula Carrillo over 12 years ago in reply to Chris Jagielski

TI__Mastermind 39620 points

Hi Chris, About the JTAG + checking buffers via Memory Browser, you are right, this was suggested more for understanding the code going through it and for debugging purpose.

On the other hand, No sure if you have check our Linux SDK development guide wiki (http://processors.wiki.ti.com/index.php/Desktop-linux-sdk_01.00.00_Development_Guide) there you can find more details on the SDK modules and in a high level how filetes demo works. But in summary, the communication between host (demo_filetest.c) and DSP (main.c & demo_loopback_test()) is done via mailbox. So host keeps reading and posting mesages to DSP and viceverse. As you pointed out, inside demo_loopback.c is a memcpy() which is a dummy function simulation processing. There you can add your own functions for processing the data obtained from Host through PCI.

If you need to modify and rebuild the DSP side please check this link: http://processors.wiki.ti.com/index.php/Desktop-linux-sdk_01.00.00_DSP_Rebuild_Guide

Let me know if you have further questions

Thank you,

Paula

0 Chris Jagielski over 11 years ago in reply to Paula Carrillo

Expert 1630 points

I believe I understand it now. I'm doing some small modifications to the filetestdemo now, and I've spent quite some time reading the code and going through the mailbox details.

Thank you for your help!

0 Chris Jagielski over 11 years ago in reply to Paula Carrillo

Expert 1630 points

Paula, thank you so much for your help so far. Would you please take a look at my approach and provide some guidance?

I'm trying to modify the DSP side of the code. Using SYS/BIOS and the Linux Desktop SDK, I'd like to have the following sequence of events:

Initialize DSP #1 and load my custom .out file on Core #0
In main(), do the following:
1. dynamically create a SYS/BIOS task
2. mimic filetestdemo's main to demo_disableCache() & to initialize the platform
3. wake up the other cores, via IPC Generator Registers
4. BIOS_start()
(In the task I previously created) do the following:
1. Call demo_loopback_test()
2. Task will wait in while() loop, until the host gives a mailBox query
Now manually run the Host code (demo_filetest.c)

So far, I've only gotten parts of this sequence to work.

Note - I'm not going to try and run this via the same .sh file provided from the filetestdemo (e.g. ./run_dspmaptest.sh 1 0x400000). Instead I'll load onto the DSPs via CCS, and then modify a script to run the host code. Do you see any immediate problem with doing this?

My questions/concerns...

In #2, the filetestdemo code sequentially wakes up the other 7 cores. I read that making the core's IPCGR LSB = 1 will trigger an interrupt on that corresponding CorePac. If I'm running this code in main() of a SYS/BIOS project, do I still need to load the same .out file to all 8 cores? I'm confused how this works... in filetestdemo does only 1 core "wake up" the other cores? Or, does every single core send this IPC "wake up" to every other core for a total of 7+6+5+4+3+2+1=28 "wake up" messages?

In #3, my code gets "stuck" trying to open the second mailbox, the host<--dsp mailbox. The TI mailBox.c code does say that mailBox_open()is a blocking call, and will wait until the remote is ready. I see that the do/while loop it's stuck inside is dependent on:
- mailboxHeader.owner_code != MAILBOX_SLOT_OWNER_LOCAL (~ line 494)

so, this means that the function mailBoxGetHeader() is not returning the proper number. I inserted a printf, and saw that the returned variable owner_code=0. Might this mean that opening this mailBox relies on having the linux host also running? (the Development Guide states that mailBox_open"is called by both Host and DSP core to open the mailbox").

0 Hongmei Gou over 11 years ago in reply to Chris Jagielski

TI__Expert 4335 points

Hi Chris,

Please see below inline.

Instead I'll load onto the DSPs via CCS, and then modify a script to run the host code. Do you see any immediate problem with doing this?

[Hongmei: This should be fine. But what is the purpose of doing this?]

In #2, the filetestdemo code sequentially wakes up the other 7 cores. I read that making the core's IPCGR LSB = 1 will trigger an interrupt on that corresponding CorePac. If I'm running this code in main() of a SYS/BIOS project, do I still need to load the same .out file to all 8 cores? I'm confused how this works... in filetestdemo does only 1 core "wake up" the other cores? Or, does every single core send this IPC "wake up" to every other core for a total of 7+6+5+4+3+2+1=28 "wake up" messages?

[Hongmei: Only core-0 should wake-up all other cores. There are certain restrictions with memory map regarding placing initialized memory sections. NOINIT should be used for the DDR/MSMC data sections which are shared by multiple cores. Otherwise, the data initialized on one core (e.g., core 0) can be wiped out when loading .out file on other cores (e.g., core 1). ]

In #3, my code gets "stuck" trying to open the second mailbox, the host<--dsp mailbox. The TI mailBox.c code does say that mailBox_open()is a blocking call, and will wait until the remote is ready. I see that the do/while loop it's stuck inside is dependent on:
mailboxHeader.owner_code != MAILBOX_SLOT_OWNER_LOCAL (~ line 494)

[Hongmei: mailbox_open needs a hand-shake between host & dsp. DSP is going to busy wait until host reaches the same point and pokes the owner_code..]

As for using SYS/BIOS, we have MCSDK Video which builds on Desktop Linux SDK and uses mailbox communication in a SYS/BIOS context. MCSDK Video download page is @ http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk_video/02_02_00_28/index_FDS.html. MCSDK Video wiki pages:

Getting started guide: http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_Linux_Getting_Started_Guide

Demo guide: http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_PCIE_Demo_Guide

Development guide: http://processors.wiki.ti.com/index.php/MCSDK_VIDEO_2.1_PCIe_Demo_Development_Guide

Thanks,

Hongmei

0 Chris Jagielski over 11 years ago in reply to Hongmei Gou

Expert 1630 points

Thanks for the detailed answers Hongmei!

Hongmei Gou said:

Instead I'll load onto the DSPs via CCS, and then modify a script to run the host code. Do you see any immediate problem with doing this?

[Hongmei: This should be fine. But what is the purpose of doing this?]

I guess I thought this would be simpler for debug while changing my code on the DSP side. Looking at the Linux Desktop DSP Rebuild Guide, it seemed that it was a much larger effort to run all of those scripts in the Wiki each time I created a new .out file for the dspc8681... so I pondered if I could load the .out file(s) on the DSPs via CCS (which is easy to do) and then simultaneously manually run a script to start the Host side as well. Maybe I'm over complicating things!

Hongmei Gou said:

In #2, the filetestdemo code sequentially wakes up the other 7 cores. I read that making the core's IPCGR LSB = 1 will trigger an interrupt on that corresponding CorePac. If I'm running this code in main() of a SYS/BIOS project, do I still need to load the same .out file to all 8 cores? I'm confused how this works... in filetestdemo does only 1 core "wake up" the other cores? Or, does every single core send this IPC "wake up" to every other core for a total of 7+6+5+4+3+2+1=28 "wake up" messages?

[Hongmei: Only core-0 should wake-up all other cores. There are certain restrictions with memory map regarding placing initialized memory sections. NOINIT should be used for the DDR/MSMC data sections which are shared by multiple cores. Otherwise, the data initialized on one core (e.g., core 0) can be wiped out when loading .out file on other cores (e.g., core 1). ]

Thank you, this makes sense to me! The shared memory sections are very interesting to me and quite important.

Hongmei Gou said:

In #3, my code gets "stuck" trying to open the second mailbox, the host<--dsp mailbox. The TI mailBox.c code does say that mailBox_open()is a blocking call, and will wait until the remote is ready. I see that the do/while loop it's stuck inside is dependent on:
mailboxHeader.owner_code != MAILBOX_SLOT_OWNER_LOCAL (~ line 494)

[Hongmei: mailbox_open needs a hand-shake between host & dsp. DSP is going to busy wait until host reaches the same point and pokes the owner_code..]

This also makes sense and answers my question. I appreciate your help.

0 Hongmei Gou over 11 years ago in reply to Chris Jagielski

TI__Expert 4335 points

Hi Chris,

Another way to facilitate debugging is to load .out through Desktop Linux SDK, and then load symbols in CCS.

Thanks,

Hongmei

0 Paula Carrillo over 11 years ago in reply to Hongmei Gou

TI__Mastermind 39620 points

Hi Chris as Hongmei suggested it might be easier if you use the linux SDK scripts for downloading the .out to the DSP, and for debugging only load "symbols" instead of "program". One thing that I found useful for debugging was adding few getchar(); in the host side (e.g before mailbox communication) in that way I stopped the host application and give me time for loading the program symbols in CCS and/or step into the code. At high level the steps I use are:

- Loading .out using linux SDK scripts

- Run Host application using linux SDK scripts

- Connect cores

- Load symbols

- Step into the code

A 2-cents comment, please check that mailbox DDR region is a non-cache. For example

Inside .cmd file

DDR3_MAILBOX_RESERVED (RW) : org = 0x9FC00000, len = 0x8000

Inside .cfg file

Cache.setMarMeta(0x9FC00000, 0x8000, 0x0); //Mailbox non-cache

Thank you,

Paula

0 Chris Jagielski over 11 years ago in reply to Paula Carrillo

Expert 1630 points

I'm trying to write my own Linux host code using the SDK APIs, starting out by modifying the filetestdemo host source file demo_filetest.c

From the wiki (Linux SDK Development Guide):

http://processors.wiki.ti.com/index.php/Desktop-linux-sdk_01.00.00_Development_Guide#Download_Manager_.28dnldmgr.29 said:

At this time, application program must be loaded through download manager API [Only hex file format currently supported]

Does this mean that, in order to use the Linux Desktop APIs, that I must use the dnldmgr to Download the .out to the DSPs?

I notice a few dependencies in the filetestdemo that make me think so... here's my logic:

in demo_filetest.c: the function demo667x4_Config() is called in main(). That demo667x4_Config() function uses the global variable dsp2hostmailbox
dsp2hostmailbox is defined by the function dnldmgr_get_symbol_address(), found in dnldmgr.c
in the dnldmgr_get_symbol_address() function, dsp2hostmailbox is the out param, the "Entry point address for Program" according to the function's descriptive comments
dnldmgr_get_symbol_address() also uses the variable dsp_image_handle, which is an output parameter of the dnldmgr.c function called dnldmgr_get_image()
the input parameter to dnldmgr_get_image() function is argv[7], the "Dsp image name with path (any valid image hex or out file)" according to the function's descriptive comments
argv[7] is the input argument typed in the Linux Terminal by the user when running the run_dmatest.sh script, found in ../desktop-linux-sdk_01_00_00_07/demos/filetestdemo/scripts

So - it seems to me that it is impossible to run the host code without also letting the host code download the DSP image onto the DSPs. If the host code does not do this, then it will not get the "dsp_entry_point" or the "dsp_image_handle".

To recap,

without the "dsp_image_handle" variable (a pointer), the global uint32_t variables "dsp2hostmailbox" & "host2dspmailbox" will remain initialized but never get defined.
when the "demo667x4_Config()" function tries to create all the mailboxes, it will need the "dsp2hostmailbox" and the "host2dspmailbox" variables in order to know the correct memory start address for the mailBox_config_t mailBox_config.
this start address is passed into the mailBox_create() function inside mailBox.c
the mailBox_create() function will therefore have an invalid pointer to a nonsense memory

Is my understanding incorrect? Or is there another way to go about this?

0 Paula Carrillo over 11 years ago in reply to Chris Jagielski

TI__Mastermind 39620 points

Hi, as the best of my knowledge your understanding is correct. A quick note, if you modified the DSP project, please double check that the DSP entry point is still located at 0c000000

demo_loopback.map

OUTPUT FILE NAME: <../bin/demo_loopback.out>
ENTRY POINT SYMBOL: "_c_int00" address: 0c000000

Thank you,

Paula

Processors

Processors forum

demo_loopback.c question -> Linux Desktop SDK