• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 985 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.

DM365 IPNC - bootargs - cmemk parameters, pool size calculation

panshi
Intellectual 580 points

Hi,

I am working on DM365 APPRO IPNC. In the user guide of it bootargs are defined as below.

setenv bootargs 'mem=48M console=ttyS0,115200n8 root=/dev/mtdblock3 rootfstype=squashfs ip=dhcp eth=$(ethaddr) lpj=741376 cmemk.phys_start="0x83000000"
cmemk.phys_end="0x88000000" cmemk.phys_start_1="0x00001000" cmemk.phys_end_1="0x00008000" cmemk.pools_1="1x28672" cmemk.allowOverlap="1" quiet'

With reference to above I have below quires.

1) Why two blocks are define cmemk.phys_start="0x83000000" and cmemk.phys_start_1="0x00001000"?

2) Why second block is define at 0x00001000?

3) Why pool size is define as 28672. Can we modify same?

Please help me to understand.

Regards,

panshi

  • 0
    TI__Mastermind 18260 points

    panshi said:

    1) Why two blocks are define cmemk.phys_start="0x83000000" and cmemk.phys_start_1="0x00001000"?

    The first block is for general CMEM allocations.  The second block (phys_start_1=0x00001000) is a special on-chip memory area on the DM365, and would be used for high-speed memory needs by codecs.

    panshi said:

    2) Why second block is define at 0x00001000?

    The block actually starts at address 0x00000000, but you can't pass a physical address of 0 to mmap(), and the physical address must be a multiple of PAGE_SIZE (0x1000 on ARM), hence the minimum address passed to mmap() is 0x00001000.

    panshi said:

    3) Why pool size is define as 28672. Can we modify same?

    The DM365 on-chip memory is 32KB in size, but since we're forced to use a starting address of 0x00001000 (4096) we need to subtract 4096 from 32768.  You could modify that size to be less than 28672 but not more.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Intellectual 580 points

    Dear Rob,

    Thank you for the answers.

    Could you please share the reference link for same to go in to more deatails.

    Regards,

    panshi 

  • 0 in reply to GAnthony
    Intellectual 580 points

    Hi Gil,

    Thank you.

    With reference to the documented suggested For 'http://processors.wiki.ti.com/index.php/Changing_the_DVEVM_memory_map' for D1 rsolution we have to define pools/buffers of more than 812K size (which i see logical), in appro's boot arguments we are defining buffer of 28672 (i.e. 28K) size which is too less.

    Please help me to understand.

    Regards,

    panshi

     

  • 0 in reply to panshi
    TI__Mastermind 18260 points

    Panshi,

    1) Your original post showed that you are not configuring any pools for CMEM's block 0 (the big one starting at 0x83000000).  When no pools are specified, the whole block becomes a heap.  CMEM heap allocations are performed with CMEM_alloc() with CMEM_AllocParams.type=CMEM_HEAP.  You could allocate your buffers this way if you're not worried about the typical heap issue of fragmentation.

    2) If you want to configure pools in CMEM's block 0, you would do:
        cmemk.pools=2x831488,10x4096
    for instance, to get two 812K byte buffers and ten 4K byte buffers.  You're free to configure the whole block with whatever pool buffer geometry you need, as long as that geometry fits within the block.

    The cmemk.pools_1=1x28672 configures CMEM's block 1 to have 1 pool containing 1 buffer of size 28672 bytes.  To allocate from block 1 you would need to use the CMEM_alloc2(1, ...) function (the '1' specifies block 1).  CMEM_alloc() implies block 0.

    Regards,

    - Rob