• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 580 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CMEM allocation in BSP 6.14

DavidVescovi
Genius 5470 points

Other Parts Discussed in Thread: OMAP3530

I am questioning how the following lines in DVSDK_Integeration.reg file under the CMEMK key are arrived at:

"PhysicalStart0"=dword:86300000

"PhysicalEnd0"=dword:87300000

 

I read the comment above the settings but it does not make sense. These memory regions do not allign with anything in the CONFIG.BIB map.

IF

 

BSP_SDRAM_BANK1_ENABLE

NK 84001000 047FF000 RAMIMAGE

 

; 72MB - 4K

DISPLAY 88800000 01000000 RESERVED

 

; 16MB

CMEM_DSP 89800000 02800000 RESERVED

 

; 40 MB

RAM 8C000000 08000000 RAM

 

; 128MB

ELSE

NK 84001000 01FFF000 RAMIMAGE

 

; 32MB - 4K

RAM 86000000 02800000 RAM

 

; 40 MB

DISPLAY 88800000 01000000 RESERVED

 

; 16MB

CMEM_DSP 89800000 02800000 RESERVED

 

; 40 MB

ENDIF

I am assuming this is an error and the codec frameworks works only by pure chance (probably using the memory pools first). Shouldn't this be something like:

"PhysicalStart0"=dword:89800000

"PhysicalEnd0"=dword:8C000000

 

If this is not the case where did these number come from?

  • 0
    TI__Genius 12865 points

    Hi David,

    DSP memory area is reserved using CMEM_DSP in config.bib. Note that this is a virtual address range. To my understanding, on the OMAP3530 the virtual memory range 0x89800000 to 0x8C000000 corresponds to physical memory range 0x85800000-0x88000000. This area is subdivided as followed in DVSDK 1.0:

    Component             Start physical memory address     End physical memory address

    CMEM                                    0x86300000                                       0x87300000

    DSP Server                           0x87300000                                       0x88000000

    (RESET_VECTOR + DDR2 + DDRALGHEAP + DSPLINK. See server.tcf in dvsdk_wince_1_00_00_05\cs1omap3530_1_00_01\packages\ti\sdo\server\cs for details on placement of these memory sections.)

    There is an unused gap between 0x85800000 to 0x86300000 that is available for CMEM (or other software components)  to 'grow' into if necessary.

    Best regards,

    Vincent

  • 0 in reply to Vincent W.
    Genius 5470 points

    I understand the allocation now. Thanks.

    One more question. If I have a custom platform where the memory layout is slightly different and I need to reassign the location of CMEM_DSP.

    I believe I will then have to rebuild the server?

    I assume I just need to redefine:

    var BASE_ADDR_BOTTOM  = 0x88000000

    Is that all I need to modify for a different CMEM_DSP location?

    Is the server the only thing that needs to be rebuilt?

  • 0 in reply to DavidVescovi
    TI__Genius 12865 points

    Yes, you will need to rebuild the server after setting BASE_ADDR_BOTTOM. This takes care of placing the DSP image at the location of your choice. In the tcf file you can figure out the memory range used by the DSP (I think it starts with the reset vector at RESET_VECTOR_BASE_ADDR = (BASE_ADDR_BOTTOM - DSPLINKMEM_SIZE - DSPEXTMEM_SIZE - DDRALGHEAP_SIZE) & 0xFFF00000) . After that you need to inform WinCE by redefining your memory map in config.bib. CMEM_DSP needs to span the range defined in the tcf file in addition to what has been configured for CMEM, while keeping in mind that CMEM_DSP is a virtual address range. You may also need to change the placement of other memory regions in config.bib so that they don't overlap one another.

    Furthermore, any application (e.g. TI's DirectShow filters, DMAI-based applications, Codec Engine-based applications) that uses the DSP server you have modified would also need to be rebuilt against the new server, so that the ARM side 'learns' about the memory map on the DSP side. This is necessary so that Codec Engine creates an engine based on the new server, which allows DSPLINK (the interprocessor communication layer) to communicate properly with the DSP image.

    Best regards,

    Vincent 

  • 0 in reply to Vincent W.
    Genius 5470 points

    Thanks Vincent ..this is very helpfull.

    I am familiar with modifing the config.bib and addrtab_cfg.inc for different physical and virtual memory layouts.

    I probably can rebuild the server but I was hoping to avoid redoing the filters or for that matter anything else. I guess this is not the case as there must also be hard coded addresses in the filters and else where?

    Would the same (distributed) codec and parser dlls work unmodified?

    DV

  • 0 in reply to DavidVescovi
    TI__Genius 12865 points

    Hi David,

    As far as the Directshow filters are concerned, the one DLL that requires a rebuild is TIMM.dll (see http://processors.wiki.ti.com/index.php/TI_DirectShow_Filters#Decode_System_Architecture for system diagram.). This is the DLL that talks to Codec Engine and DSPLINK. At build time, it configures codec engine via a cfg file using a tool called configuro. This configuration step needs to be re-run as part of the rebuild process. If you change the memory map on the DSP this is a necessary step to ensure DSPLINK is configured accordingly. See the release notes in the dshow_x_xx_xx_xx directory in the DVSDK for details on how to rebuild.

    The parser dlls and the individual codec-specific filter dlls do not need to change. You can tweak builddshow.bat and/or dshow_x_xx_xx_xx/project/prelink.bat so that it does not rebuild the filters directory.

    As for the examples TI provides with DMAI, you can decide whether you need them or not. Just keep in mind if you do want to run them a rebuild is required as well.

    Best regards,

    -Vincent