This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

contiguous memory (Linux Desktop SDK, C6678)



Hello!

I want to use the Linux Desktop SDK.  I'm reading the Development Guide, and I have a question about contiguous memory.

Here's what I'm trying to do, maybe there's a better solution! :)

  • I have ~2.0 GB of data in a lookup table
  • Every so-often, I'll need to transfer a ~20.0 MB "slice" from that lookup table into my DSP core for processing
  • The lookup table will be stored on my Host Linux PC, somewhere on the solid state drive
  • (My hardware, the Advantech 8681 (with Quad Shannon DSPs) will be connected via PCIe to my Linux Host)

When my system starts up, I believe I'll need to copy the lookup table's data into contiguous memory (on my Host computer) so it can be seen by the DSP via PCIe.

How do I set all of this up correctly?  What are my options for allocating & copying the 2GB memory at start-up and transferring the 20MB data to & from?     Thank you!!

  • Chris,

    This seems to be a duplicate of another thread (http://e2e.ti.com/support/embedded/bios/f/355/p/294168/1029447.aspx#1029447).  If that's correct, I will go ahead and delete this one.

  • They are related in nature, but definitely different.

    The other thread you mentioned had 1 specific question: how do I verify that I successfully followed the directions on the TI Wiki page for Desktop Linux SDK.

    This thread, on the other hand, is asking a generic question about using the Linux Desktop SDK:

    • When my system starts up, I believe I'll need to copy the lookup table's data into contiguous memory (on my Host computer) so it can be seen by the DSP via PCIe.  How do I do put the data on my Linux host computer into the contiguous memory that I just set-up?

    It this question does not make sense to anyone, then please point me to other informational materials, examples, etc. such that I can learn how to build a complete DSP solution using the TI hardware & software I am mentioning.

  • Chris,

    There doesn't seem to be the expertise to answer this question in the BIOS forum, so I have moved this thread over to the Linux forum in hopes that it will get an answer there.

  • Chris,

    I am assuming that you already have the 2 GB memory reserved for CMEM and allocation from application working.

    The filetest demo code can help you with different options to transfer data to DSP using the cmem buffers.

    Probably the one difference is that the filestest demo fills dynamic data every time from file. This can be skipped if it is one time filled. 

    Also if you are trying to use the dma for example, then the extra copy in filetest demo can be avoided by directly calling the pciedrv_dma_write_initiate & pciedrv_dma_read_initiate APIs.

    One thing  to note is that, there are options on how you can manage memory.

    For example,

    a) The cmem allocation can be done as one 2 GB chunk and the application can choose the section of memory to transfer  ( say 20 MB in your case) and call  the desktop linux sdk APIs.

    b) The cmem allocation can be done as 512 x 4 MB chunks and the data can be filled as needed.  Then appropriate sequence of buffers needed ( say 5 buffers of 4 MB) can be used to call the desktop linux sdk APIs.

    Please see the following note in  demos/filestestdemo/host/inc how the cmem sizes are used in filetstest demo. :

    /* This parameter is used to configure the CMEM host pools for use with
       mapping to DSP Memory range; should be 1MB, 2MB, 4MB or 8MB */
    #define DSP_OB_REGION_SIZE  0x400000
    #define HOST_CMEM_BUFFER_SIZE DSP_OB_REGION_SIZE

    Let me know if you have any questions.

    with regards,

    Sam

  • Sam, thank you for your help.

    The filetestdemo will give me some options to better understand the different transfers.

       

    In general, is the Desktop Linux SDK the best/easiest/most common/suggested method to get data from my Host PC into my DSPs (Advantech 8681)?

    I've also come across FatFS (http://processors.wiki.ti.com/index.php/FatFS_for_SYS/BIOS) which seems to give me the ability to read in a .txt file into my DSP.  Here's some sample C code from the SYS/BIOS FatFS example (from fattest1.c)

    /*
     *  ======== main ========
     */
    Void main()
    {
        Task_create(task, NULL, NULL);
    
        BIOS_start();
    }
    /*
     *  ======== task ========
     */
    Void task(UArg arg0, UArg arg1)
    {
        cat("fat:file1.txt");
        cat("fat:file2.txt");
    }
    /*
     *  ======== cat ========
     *  read 'filename' and output to stdout
     */
    Void cat(char *filename)
    {   
    	FILE *fp;
        char data[64];
        int size;
        
        fp = fopen(filename, "r");
        if (fp == NULL) {
        	printf("cannot open %s\n", filename);
        	System_exit(0);
        }
       
        do {
        	size = fread(data, 1, sizeof(data), fp);
        	fwrite(data, 1, size, stdout);
        } while (size == sizeof(data));
        
        fclose(fp);
    }

    Do I need a new thread?  Had I known about FatFS before I would have mentioned it in my original post here.  I am hoping in this thread to discover if Desktop Linux SDK is the software that best meets my needs.

  • I almost feel like I'm going in circles here, am I missing something?

     

    If it's not too confusing, here's what I'm trying to do with my system ...

    • I have ~2.0 GB of data in a lookup table.

    • Every so-often, my DSP will need to obtain & use approx 20.0 MB of data from that lookup table

    • The table should be stored on the Linux Host PC, because I have limited DDR3 on my DSP devices (c6678) and it won't fit!

    • Note: My hardware, the Advantech 8681 (with Quad Shannon DSPs) will be connected via PCIe to my Linux Host PC

     

    Note: my transfer from Linux PC to DSP cores (on the 8681) will not happen very often.  Perhaps, say, only 20MB of data every minute.  This is the rough order of magnitude.

    Because of my system needs I just described, I'm wondering if there is a simpler way to make this happen?

    I greatly appreciate everyone's help - please let me know if this does not make sense!

  • Again there are multiple ways to achieve this using Desktop Linux SDK.

    Here is a way to do this even without cmem: especially as these once a minute operation.

    a) Have a  reserved section of 20 MB on the DSP memory.  ( say dsp_reserved_address)

    b) Copy the 20 MB table of interest for your storage device to a Host memory ( This can be a malloc region or static array on the Host ). Say table_section[]

    b) And you can write the 20 MB table section to the DSP memory  using the following desktop linux SDK API

      pciedrv_dsp_write(dsp_id, dsp_reserved_address, table_pointer, 0x1400000);

    c) DSP can now access the table section of interest from the dsp_reserved address. Let me know if this will work for you.

  • Sam Nelson said:

    b) And you can write the 20 MB table section to the DSP memory  using the following desktop linux SDK API

      pciedrv_dsp_write(dsp_id, dsp_reserved_address, table_pointer, 0x1400000);

    Sam,

    Where can I get more information about this API? 

    Actually - is there any information for any of the Desktop Linux SDK API's?  Google search comes up with nothing, except your post from yesterday :)

    If the only references to the Desktop Linux modules are the actual .c & .h files themselves, I'll be more than happy to check them out!  Just want to double check here.  Thanks for your patience.

  • Chris,

    Unfortunately we don't have any other documentation on the API other than the .h & .c files themselves.

    Please look at the filetestdemo example code for usage.

    with regards,

    Sam

  • Thanks Sam.

    I'm curious, why does the filetestdemo disable the Cache (MAR) before waking up the cores and starting?  This is in /demos/filetestdemo/c66x/demo_loopback/src/main.c

  • The cache configuration is in general application specific.

    Currently in the demo the DSP memory areas used for communication with the PC Host are marked as un-cached.

    with regards,

    sam