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.

AM6441: Sharing memory between R5 and M5 with Linux running on A53

Part Number: AM6441

Tool/software:

Hello Team

In my previous Post I was running a IPC example with shared memory between R5 and M4 core and sharing UART data. This example worked for me. This was NORTOS based example.

Now I want to try this example but with Linux running on A5 core. I want to share a variable in the user shared memory between M4 (running UART Echo example) and R5 (GPIO LED Blink example). There is no need of spinlock because M4 will always write this variable when some text is received on UART and R50_0 will always read its value & then blink the LED.

Background: I have successfully built and run standalone GPIO LED Blink example with R50_0 on Linux.

Now I created a system project. In which I added this R50_0 example and M4 based UART Echo example. As soon as I do this I get following error in the example.syscfg file of M4

Above is M4 configuration.

Below are the memory configuration of R5 in sys config. There is no error in this configuration

I am also attaching the linker file of R50_0 for reference to understand the memory and section better.


 /* This is the stack that is used by code running within main()
  * In case of NORTOS,
  * - This means all the code outside of ISR uses this stack
  * In case of FreeRTOS
  * - This means all the code until vTaskStartScheduler() is called in main()
  *   uses this stack.
  * - After vTaskStartScheduler() each task created in FreeRTOS has its own stack
  */

 --stack_size=16384
/* This is the heap size for malloc() API in NORTOS and FreeRTOS
* This is also the heap used by pvPortMalloc in FreeRTOS
*/
 --heap_size=32768
-e_vectors  /* This is the entry of the application, _vector MUST be placed starting address 0x0 */

/* This is the size of stack when R5 is in IRQ mode
 * In NORTOS,
 * - Here interrupt nesting is enabled
 * - This is the stack used by ISRs registered as type IRQ
 * In FreeRTOS,
 * - Here interrupt nesting is enabled
 * - This is stack that is used initally when a IRQ is received
 * - But then the mode is switched to SVC mode and SVC stack is used for all user ISR callbacks
 * - Hence in FreeRTOS, IRQ stack size is less and SVC stack size is more
 */
__IRQ_STACK_SIZE = 256;
/* This is the size of stack when R5 is in IRQ mode
 * - In both NORTOS and FreeRTOS nesting is disabled for FIQ
 */
__FIQ_STACK_SIZE = 256;
__SVC_STACK_SIZE = 4096; /* This is the size of stack when R5 is in SVC mode */
__ABORT_STACK_SIZE = 256;  /* This is the size of stack when R5 is in ABORT mode */
__UNDEFINED_STACK_SIZE = 256;  /* This is the size of stack when R5 is in UNDEF mode */



SECTIONS
{
    .vectors  : {
    } > R5F_VECS   , palign(8) 


    GROUP  :   {
    .text.hwi : {
    } palign(8)
    .text.cache : {
    } palign(8)
    .text.mpu : {
    } palign(8)
    .text.boot : {
    } palign(8)
    .text:abort : {
    } palign(8)
    } > R5F_TCMA  


    GROUP  :   {
    .text : {
    } palign(8)
    .rodata : {
    } palign(8)
    } > DDR_1  


    GROUP  :   {
    .data : {
    } palign(8)
    } > DDR_1  


    GROUP  :   {
    .bss : {
    } palign(8)
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)
    .sysmem : {
    } palign(8)
    .stack : {
    } palign(8)
    } > DDR_1  


    GROUP  :   {
    .irqstack : {
        . = . + __IRQ_STACK_SIZE;
    } align(8)
    RUN_START(__IRQ_STACK_START)
    RUN_END(__IRQ_STACK_END)
    .fiqstack : {
        . = . + __FIQ_STACK_SIZE;
    } align(8)
    RUN_START(__FIQ_STACK_START)
    RUN_END(__FIQ_STACK_END)
    .svcstack : {
        . = . + __SVC_STACK_SIZE;
    } align(8)
    RUN_START(__SVC_STACK_START)
    RUN_END(__SVC_STACK_END)
    .abortstack : {
        . = . + __ABORT_STACK_SIZE;
    } align(8)
    RUN_START(__ABORT_STACK_START)
    RUN_END(__ABORT_STACK_END)
    .undefinedstack : {
        . = . + __UNDEFINED_STACK_SIZE;
    } align(8)
    RUN_START(__UNDEFINED_STACK_START)
    RUN_END(__UNDEFINED_STACK_END)
    } > DDR_1  


    GROUP  :   {
    .ARM.exidx : {
    } palign(8)
    .init_array : {
    } palign(8)
    .fini_array : {
    } palign(8)
    } > DDR_1  

    .bss.user_shared_mem (NOLOAD) : {
    } > USER_SHM_MEM    

    .bss.log_shared_mem (NOLOAD) : {
    } > LOG_SHM_MEM    

    .bss.ipc_vring_mem (NOLOAD) : {
    } > RTOS_NORTOS_IPC_SHM_MEM    

    .bss.nocache (NOLOAD) : {
    } > NON_CACHE_MEM    


    GROUP  :   {
    .resource_table : {
    } palign(4096)
    } > DDR_0  


}


MEMORY
{
    R5F_VECS   : ORIGIN = 0x0 , LENGTH = 0x40 
    R5F_TCMA   : ORIGIN = 0x40 , LENGTH = 0x7FC0 
    R5F_TCMB0   : ORIGIN = 0x41010000 , LENGTH = 0x8000 
    NON_CACHE_MEM   : ORIGIN = 0x70060000 , LENGTH = 0x8000 
    MSRAM   : ORIGIN = 0x70080000 , LENGTH = 0x40000 
    USER_SHM_MEM   : ORIGIN = 0x701D0000 , LENGTH = 0x80 
    LOG_SHM_MEM   : ORIGIN = 0x701D0080 , LENGTH = 0x3F80 
    RTOS_NORTOS_IPC_SHM_MEM   : ORIGIN = 0x701D4000 , LENGTH = 0xC000 
    FLASH   : ORIGIN = 0x60100000 , LENGTH = 0x80000 
    DDR_1   : ORIGIN = 0xA0101000 , LENGTH = 0xEFF000 
    DDR_0   : ORIGIN = 0xA0100000 , LENGTH = 0x1000 
    LINUX_IPC_SHM_MEM   : ORIGIN = 0xA0000000 , LENGTH = 0x100000 

    /* For memory Regions not defined in this core but shared by other cores with the current core */


}

Kindly let me know why is this error showing up in M4. Isn't MSRAM available for memory sharing usage?

Should the section be allocated only in DDR?

Thanks

Amey

  • The above issue was resolved when I removed the Memory Segments which were giving error. This Memory region are already defined in R5 configuration.

    Was this error because there was duplicate entry for same Memory Region ( this is a system project)?

    Below is the new configuration. I was able to share the memory and make this project run via Linux remoteproc

    Thanks

    Amey

  • Hello Amey,

    You are using SDK 9.1 or later, right? I would not be surprised if this was one of the shared memory errors caused by the new memory configurator tool.

    For future readers, here's the shiny new documentation that I wrote based on some of Amey's feedback a couple months ago:
    https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AbPlFhzNu.K.laEXM3Gx1A__AM64-ACADEMY__WI1KRXP__LATEST

    Amey, one thing to keep in mind is that with a system project, each shared memory region is only defined once, in the example.syscfg file for one of the processor cores. Then the example.syscfg files for the other cores in the project should just contain a reference to that memory region instead of re-defining it, if I recall correctly. I am not sure if there is a specific pattern for which processor core's example.syscfg project has the shared memory definition or not.

    Regards,

    Nick

  • Thanks Nick for the reply.

    I am using mcu_plus_sdk_am64x_09_02_00_50 SDK for this. Yes the mistake was that I had defined the USER_SHM_MEM twice (and same for other regions).

    Regards

    Amey