• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 342 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux/TDA2PXEVM: about non cache memory map, after changed the DDR from 1G to 512MB linux memory map

terence xia
Genius 3105 points
Part Number: TDA2PXEVM

Tool/software: Linux

Hello,

According to the chapter 6.6 from VisionSDK_UserGuide_MemoryMap.pdf, I see non cache is only 5MB, but the total sizes of  'virtqueue of  DSP size +REMOTE_LOG_SIZE+SYSTEM_IPC_SHM_SIZE+LINK_STATS_SIZE+HDVPSS_DESC_SIZE+SR0_SIZE+TRACE_BUF_LEN +EXC_DATA_LEN +PM_DATA_LEN' are over 5MB.

On the other hand, the start address of the second mem section should be 16MB aligned. But, it is set a 0x9FB00000, not 16MB  aligned. Also, I see that it said"This alignment is a must as a single 16MB mapping is used for EVE to map SR0, REMOTE_LOG_MEM sections."  Does it will affect EVE function?

Thanks

Terence

--------------------------------------------------------non cache defined in .xs file ----------------------------------------------------------------------

REMOTE_LOG_SIZE = 256*KB;
SYSTEM_IPC_SHM_SIZE = 512*KB;
LINK_STATS_SIZE = 512*KB;
HDVPSS_DESC_SIZE = 1024*KB;
SR0_SIZE = 1024*KB;
TRACE_BUF_LEN = 384*KB;
EXC_DATA_LEN = 64*KB;
PM_DATA_LEN = 512*KB;

//virtqueue of  DSP size =1M

  • 0
    TI__Genius 13395 points
    Terence
    No, the start address of the second mem section need not to be always 16MB aligned.
    But the size of second mem (non-cached) should be equal or greater than the total size of all these non-cached sections.
    when you does the non-cached mapping from some cores like DSP/EVE etc the minimum address range (mapping) is 16MB and hence these mapping will start from the immediate lower 16MB aligned address, that is all.

    regards, Shiju
  • 0 in reply to Shiju Sivasankaran
    Genius 3105 points
    Hi Shiju,
    Understood. While, the size of second mem (non-cached) is less than the total size of all these non-cached sections now.

    Thanks
    Terence
  • 0 in reply to terence xia
    TI__Genius 13395 points
    Hi Terence
    Ok, then this should be fixed
    That is, The size of second mem (non-cached) should be >= the total size of all these non-cached sections

    regards, Shiju
  • 0 in reply to Shiju Sivasankaran
    Genius 3105 points
    Hi Shiju,
    That is to say, the size of second mem (non-cached) show in the chapter 6.6 of TI VisionSDK_UserGuide_MemoryMap.pdf is mistake. If it need to be fixed. Do you have a recommended value?

    Thanks
    Terence
  • 0 in reply to terence xia
    TI__Genius 13395 points
    Hi Terence
    DDR3_BASE_SIZE_0 = 507*MB;
    then
    DDR3_BASE_SIZE_1 = 512-507*MB = 5MB
    what was the "total size of all these non-cached sections" in your case?

    Reduce DDR3_BASE_SIZE_0 to increase DDR3_BASE_SIZE_1
    All these non-cached sections get allocated in DDR3_BASE_SIZE_1 section.

    The patch and doc created from an older SDK version and hence this mismatch

    regards, Shiju'