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.

Syslink / MessageQ Memory Configuration

Other Parts Discussed in Thread: OMAPL138

We are using SYS/BIOS 6.35.04.50 and SYSLINK 2.21.01.15 on an OMAPL138 dual core platform. Following various examples from TI's MCSDK and other sources, we have written applications to run on the DSP and ARM. The ARM side is running a Busybox-based Linux OS.

We are using the Notify and MessageQ APIs to transfer data between the two cores, primarily MessageQ transferring buffers from the DSP to the ARM. We are looking to increase the size of the HeapBufMP object used by the MessageQ objects but have run into some problems doing this:

1. When called from the ARM, what exactly does the regionId member of the HeapBufMP_Params struct refer to? Does it correspond to the SharedRegion information in our DSP application's .cfg file? e.g. "SharedRegion.setEntryMeta(0, new SharedRegion.Entry(...) )"

2. If so what configures our device's external memory map? Surely there must be a definition common between the DSP, ARM and Syslink kernel module? In the DSP's .cfg file there is the following comment:

/*  configure external memory cache property
 *
 *  C000_0000 - C7FF_FFFF   800_0000  ( 128 MB) Cache.MAR192_223
 *  ----------------------------------------------------------------------------
 *  C000_0000 - C1FF_FFFF   200_0000  (  32 MB) --------    don't care
 *  C200_0000 - C200_FFFF     1_0000  (  64 KB) SR_0        no-cache      MAR194
 *  C201_0000 - C2FF_FFFF    FF_0000  ( ~15 MB) SR_1        no-cache      MAR194
 *  C300_0000 - C37F_FFFF    80_0000  (   8 MB) DSP_PROG    cache enable  MAR195
 *  C380_0000 - C3FF_FFFF    80_0000  (   8 MB) --------    cache enable  MAR195
 *  C400_0000 - C7FF_FFFF   400_0000  (  64 MB) --------    don't care
 */

From what has this been generated? Can it be changed? 

3. How much shared memory needs to be reserved separately from our application's requirements? Presumably Syslink (Notify and MessageQ) require some internal shared state - where does this go?

  • Hi Ed,

    #1.  The 'regionId' is in reference to the Shared Region id as you suspected.

    #2.  The device's external memory map should have come from the platform that you are using to build the program.  Sure you can change it, but you would have to rebuild the platform package that you are using.  Or create your won platform.  Chapter 6 of the BIOS_User_Guide.pdf speaks about this.

    #3.  Notify and Message both have a local component and a shared state component.  I don't know the number off hand but they're not real big.

    What sort of problem have you encountered?

    Judaqh

  • Hi Ed,

    1. Yes, the regionId refers to the SharedRegion number.

    2.  If you look at on of the Syslink examples in the shared directory, there is a config.bld file that defines the platform memory for the DSP.  This is used DSP configuration file.  The regions c0000000 - c1ffffff and c4000000 - c7ffffff are reserved for Linux through your uboot args.  You can change the memory map in the config.bld, but make sure to change the uboot MEM args if necessary.

    3.  That amount of memory needed in SharedRegion 0 depends on your configuration (eg, how many GateMP gates, Notify events).  You can use ROV to look at SharedRegion 0 reservedSize field to see how much is being used.  You need to wait until Ipc_start() completes first.

    Best regards,

        Janet

  • Thanks both - this is helpful!

    I am a little confused still about how Linux gets the full memory map - currently we just boot it with "mem=96M" - at what point is Linux given the information that its map is split by a 32M region shared with a DSP?

    I'm not sure I understand what you mean by "using ROV". Diagnostics on memory usage would be very helpful - can you point me at the relevant documentation for doing this from the ARM?

  • Additionally - I see that HeapBufMP_Params.blockSize is in MAUs. Is this MAUs on the ARM or on the DSP? I believe the ARM can address single byte locations so 1MAU == 1byte, but that the DSP cannot so 1MAU == 2bytes. Can you confirm / correct this?

    Thanks.

  • Hi Ed,

    You can boot with mem=32M@0xc0000000 mem=64M@0xC4000000 to give Linux the two regions.

    ROV is a tool you can use in CCS for viewing BIOS objects.  Here is a link to ROV documentation:

    http://rtsc.eclipse.org/docs-tip/Runtime_Object_Viewer

    On the OMAPL138, a MAU is 1 byte for both the DSP and the Arm.

    Best regards,

        Janet

  • Janet -

    Thanks. Is there a way to check the condition of the MessageQ (how many messages waiting, for example) at runtime in our code? I tried to use "HeapBufMP_getExtendedStats" and "Memory_getStats" on the underlying heap's handle, but the HeapBufMP function always reports 0 allocated blocks, and the Memory function doesn't appear to modify the struct I pass in. I haven't tried "HeapBufMP_getStats", because I was unsure what the type of the Ptr argument should be (from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/2_00_04_83/exports/syslink_2_00_04_83/docs/html/_heap_buf_m_p_8h.html)

    Thanks,

    Ed

  • Hi Ed,

    There is a MessageQ_count() API that I found in ti/ipc/MessageQ.h:

    /*!
     *  @brief      Returns the number of messages in a message queue
     *
     *  This function returns the number of messages in a message queue.
     *
     *  @param[in]  handle      MessageQ handle
     *
     *  @return     Number of messages in the message queue.
     */
    Int MessageQ_count(MessageQ_Handle handle);

    Is that what you were looking for?

    Best regards,

        Janet