• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 100 subscribers
  • Views 863 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.

TDA4VH-Q1: C71 : Running memory of C71

chen chen
Intellectual 356 points
Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: MATHLIB, TDA4VH

Tool/software:

Hi,

  Platform：J784s4-evm  C71x(1 GHz)

  SDK：ti-processor-sdk-rtos-j784s4-evm-09_02_00_05

  There are several issues related to DSP C71 running memory. We now want to use the C71 to run some algorithms to reduce the operational burden of the A72 core(HLOS：Linux j784s4-evm 6.1.46).I found that the C71 program takes different time to link to different addresses(L2 Memory 512K / MSMC Sram 8M / DDR  ).

1、Where do the dsplib and mathlib test cases in the SDK you provide link to run? Whether the boot mode(No Boot Mode / SD Boot Mode) has any effect.

2、I found our program to run faster on L2 Memory and MSMC Sram，Due to size limitations we are going to link the program to the MSMC Sram.What makes us a little confused now is the address range of the MSMC Sram. We are currently using 0x70000000-0x70800000.You can also run the cat /proc/iomem command to verify(70000000-706effff : 70000000.sram sram@70000000). But I saw this definition in some link.cmd file in the RTOS SDK:
   MSMCSRAM (RWX) : org = 0x68000000, len = 0x300000   (ti-processor-sdk-rtos-j784s4-evm-09_02_00_05\dsplib_09_02_00_04\cmake\linkers\C7120\lnk.cmd)

   MSMC_C7x_1  ( RWIX ) : ORIGIN = 0x68000000 , LENGTH = 0x00300000   (ti-processor-sdk-rtos-j784s4-evm-09_02_00_05\vision_apps\platform\j784s4\rtos\c7x_1\j784s4_linker_freertos.cmd)

   So what does the 0x680000000-0x68800000 address range mean?

3、We're going to run bare metal without RTOS.Do we need to do memory mapping？

4、If we need to use Mmu_map for memory mapping, I have some confusion about the value of the attrs.attrIndx attribute.I've seen several examples where the addresses 0x00000000U, 0x20000000U, 0x40000000U, and 0x60000000U are configured as Mmu_AttrIndx_MAIR0（such as c7x_mmu.c). But these addresses don't seem to be used in the program.So I want to know what's the intention here.

5、I know that the address attributes are consistent (non-cached) when configured as Mmu_AttrIndx_MAIR4.Even though I read the C71x DSP Corepac Technical Reference Manual, I don't know what is the use of Mmu_AttrIndx_MAIR7 and Mmu_AttrIndx_MAIR0. 

6、I know that the address attributes are consistent (non-cached) when configured as Mmu_AttrIndx_MAIR4.In this way, ARM and DSP can get the same data directly from the same address. When I use MSMC Sram, DSP side needs to be synchronized(Call Cache_setL1DWBINV(1) function), otherwise ARM side can not read the correct data. However, frequent calls to the Cache_setL1DWBINV(1) function add time. Can I configure the MSMC Sram to the Mmu_AttrIndx_MAIR4 attribute, will this cause it not to use the Cache and make the program slower. So is there a good way to make the MSMC Sram cache-coherent?

Thanks,

  • 0
    TI__Guru* 84906 points

    Hi,

    Please expect a delay in response due to holiday in US on 27 May 2024.

    Regards,

    Nikhil

  • 0 in reply to Nikhil Dasan
    TI__Genius 10170 points

    Hello, 

    Since these are several questions on various topics, I will not be able to immediately respond to all questions. I may also have to follow up internally about a few of your questions, so do expect some delay in all your questions being answered. I have provided a response to some of your questions below to help you progress. 

    chen chen said:
    Where do the dsplib and mathlib test cases in the SDK you provide link to run?

    The default test cases that come with the library have the input buffers stored in L2SRAM. This should provide the best performance coupled with the C7x Streaming Engine feature that is utilized by the MATHLIB and DSPLIB functions. 

    chen chen said:
    We are currently using 0x70000000-0x70800000.You can also run the cat /proc/iomem command to verify(70000000-706effff : 70000000.sram sram@70000000). But I saw this definition in some link.cmd file in the RTOS SDK:
       MSMCSRAM (RWX) : org = 0x68000000, len = 0x300000   (ti-processor-sdk-rtos-j784s4-evm-09_02_00_05\dsplib_09_02_00_04\cmake\linkers\C7120\lnk.cmd)
    chen chen said:
     So what does the 0x680000000-0x68800000 address range mean?

    For TDA4VH, the "Compute Cluster" architecture is slightly different than other TDA4 devices. Each C7x core has it's own MSMC (MSMC1) and there is a global MSMC, MSMC3 shared with other cores. 0x68000000 is referring to the MSMC1 of C7x_1. A system level memory of map for TDA4VH is available at vision_apps/platform/rtos/system_memory_map.html which might provide more clarity. 0x70000000 would be in the MSMC3 space. Figure 6-1. COMPUTE_CLUSTER Overview in the TRM is also a helpful reference for this architecture.

    Best,

    Asha

  • 0 in reply to Asha Bhandarkar
    Intellectual 356 points

    Hi

      Can you give a brief explanation on the use of the Mmu_map() function?

    Thanks,

  • 0 in reply to chen chen
    TI__Genius 10170 points

    Hi,

    chen chen said:
    Whether the boot mode(No Boot Mode / SD Boot Mode) has any effect.

    No Boot mode uses GEL scripts to do various initializations whereas SD Boot Mode will use SBL or SPL. There are slight differences between the two. The performance of MATHLIB and DSPLIB have been documented when the EVM is set in No Boot Mode. I have not tested this myself, but I would not expect a significant performance difference between SD/No boot. 

    chen chen said:
    3、We're going to run bare metal without RTOS.Do we need to do memory mapping？

    Proper initialization of the MMU is needed for the C7x cache. 

    With regards to your MMU specific questions, I will do my best to update you by 6/3 as I need to reach out internally for some clarifications. 

    Best,

    Asha

  • 0 in reply to Asha Bhandarkar
    Intellectual 356 points

    Hi

      There is a question about the MSMC SRAM.Table 8-6. MSMC Memory Regions(669) of the TDA4AH Technical Reference Manual describes:

         MSMC SRAM         0x0070000000 0x00707FFFFF   8MB

       Then both DSP and ARM can only access 0x70000000-0x7070000000.

      

    root@j784s4-evm:~# devmem2 0x70000000
/dev/mem opened.
Memory mapped at address 0xffff80a32000.
Read at address  0x70000000 (0xffff80a32000): 0xAA0003F4
root@j784s4-evm:~# devmem2 0x70100000
/dev/mem opened.
Memory mapped at address 0xffffaf57f000.
Read at address  0x70100000 (0xffffaf57f000): 0x00000000
root@j784s4-evm:~# devmem2 0x70200000 
/dev/mem opened.
Memory mapped at address 0xffffbbd56000.
Read at address  0x70200000 (0xffffbbd56000): 0xFFF2001F
root@j784s4-evm:~# devmem2 0x70300000 
/dev/mem opened.
Memory mapped at address 0xffff8e331000.
Read at address  0x70300000 (0xffff8e331000): 0x00000000
root@j784s4-evm:~# devmem2 0x70400000 
/dev/mem opened.
Memory mapped at address 0xffff9b2ef000.
Read at address  0x70400000 (0xffff9b2ef000): 0x00000000
root@j784s4-evm:~# devmem2 0x70500000 
/dev/mem opened.
Memory mapped at address 0xffffaae4b000.
Read at address  0x70500000 (0xffffaae4b000): 0x00000000
root@j784s4-evm:~# devmem2 0x70600000 
/dev/mem opened.
Memory mapped at address 0xffffafc2f000.
Read at address  0x70600000 (0xffffafc2f000): 0x00000000
root@j784s4-evm:~# devmem2 0x70700000 
/dev/mem opened.[   70.778337] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError
[   70.778347] CPU: 0 PID: 790 Comm: devmem2 Not tainted 6.1.80-ti-g2e423244f8c0 #1
[   70.778352] Hardware name: Texas Instruments J784S4 EVM (DT)
[   70.778354] pstate: 60000000 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   70.778358] pc : 0000ffffbe341c28
[   70.778360] lr : 0000ffffbe343ed0
[   70.778361] sp : 0000fffff20e9900
[   70.778362] x29: 0000fffff20e9900 x28: 0000000000000000 x27: 0000000000412000
[   70.778369] x26: 0000ffffbe365000 x25: 0000fffff20e9cc8 x24: 0000fffff20e9ad0
[   70.778374] x23: 0000000000000003 x22: 0000000000000002 x21: 0000000000000048
[   70.778378] x20: 0000ffffbe36e360 x19: 0000ffffbe365000 x18: 0000000000000000
[   70.778382] x17: 0000ffffbe343e88 x16: 0000000000411ff8 x15: 0000000000000001
[   70.778386] x14: 0000000000000001 x13: 2073736572646461 x12: 0000ffffbe365000
[   70.778391] x11: 000000000000000e x10: 000000000000000a x9 : 0000fffff20e9944
[   70.778395] x8 : 0000000000000040 x7 : 3030303536336562 x6 : 0000000000400358
[   70.778399] x5 : 0000000000000000 x4 : 000000000040113d x3 : 0000000000000000
[   70.778402] x2 : 0000000000400708 x1 : 0000000000400708 x0 : 0000000000400550
[   70.778408] Kernel panic - not syncing: Asynchronous SError Interrupt
[   70.778410] CPU: 0 PID: 790 Comm: devmem2 Not tainted 6.1.80-ti-g2e423244f8c0 #1
[   70.778414] Hardware name: Texas Instruments J784S4 EVM (DT)
[   70.778416] Call trace:
[   70.778417]  dump_backtrace.part.0+0xdc/0xf0
[   70.778434]  show_stack+0x18/0x30
[   70.778438]  dump_stack_lvl+0x68/0x84
[   70.778445]  dump_stack+0x18/0x34
[   70.778448]  panic+0x188/0x348
[   70.778453]  nmi_panic+0xac/0xb0
[   70.778458]  arm64_serror_panic+0x6c/0x7c
[   70.778463]  do_serror+0x58/0x5c
[   70.778468]  __el0_error_handler_common+0x40/0xa4
[   70.778472]  el0t_64_error_handler+0x10/0x20
[   70.778476]  el0t_64_error+0x18c/0x190
[   70.778481] SMP: stopping secondary CPUs
[   70.778487] Kernel Offset: disabled
[   70.778489] CPU features: 0x40000,20028084,0000420b
[   70.778492] Memory Limit: none
[   70.964955] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

Memory mapped at address 0xffffbe365000.

    1、Why is 0x70700000-0x707FFFFF not available ?

    2、We plan to run the DSP algorithm program on the MSMC SRAM.I wonder what TI mainly uses this memory for？

    Theanks,

      

  • 0 in reply to chen chen
    TI__Genius 10170 points

    Hi,

    I'll need to reach out to our SDK team for more information on MSMC access and will try to get that response along with the MMU related questions. 

    For our general DSP development done for the C7x libraries, writeback of data back to MSMC is done in C7x VXLIB (due to larger 2D data compared to MATHLIB and most of DSPLIB). 

    Best,

    Asha

  • 0 in reply to Asha Bhandarkar
    TI__Genius 10170 points

    Hi,

    Getting back on some of the questions:

    chen chen said:
    5、I know that the address attributes are consistent (non-cached) when configured as Mmu_AttrIndx_MAIR4.Even though I read the C71x DSP Corepac Technical Reference Manual, I don't know what is the use of Mmu_AttrIndx_MAIR7 and Mmu_AttrIndx_MAIR0. 

    pdk/packages/ti/cls/arch/c7x/src/Mmu.c has the definitions for what Mmu_MAIR0, 4, and 7 are. Table 102 - 105 in the Corepac should help you decode them. 

    chen chen said:
    6、I know that the address attributes are consistent (non-cached) when configured as Mmu_AttrIndx_MAIR4.In this way, ARM and DSP can get the same data directly from the same address. When I use MSMC Sram, DSP side needs to be synchronized(Call Cache_setL1DWBINV(1) function), otherwise ARM side can not read the correct data. However, frequent calls to the Cache_setL1DWBINV(1) function add time. Can I configure the MSMC Sram to the Mmu_AttrIndx_MAIR4 attribute, will this cause it not to use the Cache and make the program slower. So is there a good way to make the MSMC Sram cache-coherent?

    Yes, you have the correct understanding here. MSMC3 (the global MSMC between the A72 cores and C7x cores) for J874S4 does not track the data from the C7x cores and only from A72. So as you have mentioned, your two options in this regard is utilizing the writeback/invalidate feature in the case of the A72 reading data that C7x has written or making the memory region non-cacheable. 

    chen chen said:
    1、Why is 0x70700000-0x707FFFFF not available ?

    There are some sections of the 8 MB of MSMC that are already reserved, I've included that below. That would be why some of the regions you are not able to access.

    However, I recognize that the address 0x70700000 is not within the MSMC_DMSC space. Let me investigate further on why you could be getting the error. 

    Best,

    Asha

  • 0 in reply to Asha Bhandarkar
    Intellectual 356 points

    Hi

    1、 Now we want to use all MSMC_SRAM 8M for DSP1-DSP4 program running.Is that possible? If possible, 0x70000000-0x70001ffff has data, how should we remove it? How do we access 0x70700000-0x707fffff?

    2、Does DSP C71 support the timer function?

    Thanks,

  • +1 in reply to chen chen
    TI__Genius 10170 points

    Hi, 

    The 0x70700000-0x707fffff region is reserved for DMSC IPC as mentioned and cannot be changed.

    chen chen said:
    2、Does DSP C71 support the timer function?

    Can you create a new thread for this question, so we can separate MSMC/MMU related questions into one thread, and other C7x questions into others? 

    Best,

    Asha