• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Digital Signal Processors (DSP) » DaVinci™ Video Processors » DM3x DaVinci Video Processor Forum » Changing the CMEM layout.
Share
DaVinci™ Video Processors
  • Forums
  • Announcements
Options
  • Subscribe via RSS

Changing the CMEM layout.

Changing the CMEM layout.

This question is not answered
JamesS
Posted by JamesS
on Jul 17 2008 23:35 PM
Prodigy190 points

Hi,

I've got an Appro dev kit, DM355 based net camera.  AFAICT, it has 128 MB of DRAM, 80 MB for Linux, and 48 MB for CMEM.  The CMEM layout seems quite complex, as reported by cat /proc/cmem.

I found http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map , but this is aimed at the 6446.  Is there a similar doc for the 355?

Our own design will have 256 MB of DRAM, and I need to increase the encoded MPEG-4 stream buffer, to about 50 MB.  How do I do this?

Regards,

James. 

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Juan Gonzales
    Posted by Juan Gonzales
    on Jul 18 2008 09:50 AM
    Mastermind33965 points

    Two things that you need to consider come to mind

    1) You can redefine cmem memory range and buffer by editing loadmodules.sh file

    2) You will need to rebuild codec server used in demos (or your application) to make it aware of this new memory map, in a similar fashion to what is done in DM6446 article, except that the source tree may be a bit different for DM355.  The challenge would be tracking down the files where the memory layout is defined and modify them.  Unfortunately, there is no similar article for DM355, but it would make a great addition to the wiki once we figure this out.

    DM355 memory map
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Juan Gonzales
    Posted by Juan Gonzales
    on Jul 18 2008 11:37 AM
    Mastermind33965 points

    After digging a bit more into this, it appears there is no memory set aside for codec severs and hence step 2 in my previous e-mail is not necessary.  If you consider the DM355 EVM has 128MB of DDR2 and by default 116 MB is assigned to Linux (see u-boot bootargs) and 12 MB to cmem (see loadmodules.sh), all the DDR2 memory is either Linux or cmem.  This means that you probably only need to change loadmodules.sh to redefine cmem memory map and bootargs to set Linux memory map.   Codec engine for this platform is likely ARM/Linux and will allocate all memory resources it needs to load codecs from Linux portion of memory.

    DM355 cmem
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Bernie Thompson TI
    Posted by Bernie Thompson TI
    on Jul 18 2008 12:29 PM
    Mastermind41680 points

    As Juan mentions this should be simpler than the Wiki page for the DM644x describes, for defining the over all memory map you only change settings in U-Boot and in the loadmodules.sh script file that inserts the CMEM module.

    Though I am not sure if we are entirely clear on your question, aside from these configurations most any other memory management would be done within your appliation. To try to answer your question directly, I believe you would change the buffer of the compressed MPEG data from the codec in your application (malloc a larger buffer), which could be quite large considering your memory map adjustments. In this case the memory would be taken from Linux which you initially allocated for it in U-Boot.

    Hopefully these responses resolve your issue, if not please let us know.

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Juan Gonzales
    Posted by Juan Gonzales
    on Jul 18 2008 14:31 PM
    Mastermind33965 points

    James,

     Is the increased 50MB buffer used to pass video frames to codec (in which case it should come from CMEM), or is it contained and used by your Linux side application (no codec involvement), in which case it would come from Linux portion of memory?

    I think that by knowing that bootargs define Linux memory map, and loadmodules.sh defines CMEM memory map, you can probably figure out the rest, but do not hesitate to ask more questions if you require further assistance. 

     

     

    cmem memory map
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • JamesS
    Posted by JamesS
    on Jul 20 2008 18:03 PM
    Prodigy190 points

    Thanks to all for answering my question.

    The 50 MB buffer is to store encoded mpeg from the codec, just prior to bundling them and audio into an avi file.  It is implmented at the moment in CMEM, so I shall leave it that way.

    Cheers. 

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use