SK-AM64B: Query related to running led blink example on R5 core through linux

/* 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 plabed 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 disabled
 * - 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
{
    /* This has the R5F entry point and vector table, this MUST be at 0x0 */
    .vectors:{} palign(8) > R5F_VECS

    /* This has the R5F boot code until MPU is enabled,  this MUST be at a address < 0x80000000
     * i.e this cannot be placed in DDR
     */
    GROUP {
        .text.hwi: palign(8)
        .text.cache: palign(8)
        .text.mpu: palign(8)
        .text.boot: palign(8)
        .text:abort: palign(8) /* this helps in loading symbols when using XIP mode */
    } > MSRAM

    /* This is rest of code. This can be placed in DDR if DDR is available and needed */
    GROUP {
        .text:   {} palign(8)   /* This is where code resides */
        .rodata: {} palign(8)   /* This is where const's go */
    } > MSRAM

    /* This is rest of initialized data. This can be placed in DDR if DDR is available and needed */
    GROUP {
        .data:   {} palign(8)   /* This is where initialized globals and static go */
    } > MSRAM

    /* This is rest of uninitialized data. This can be placed in DDR if DDR is available and needed */
    GROUP {
        .bss:    {} palign(8)   /* This is where uninitialized globals go */
        RUN_START(__BSS_START)
        RUN_END(__BSS_END)
        .sysmem: {} palign(8)   /* This is where the malloc heap goes */
        .stack:  {} palign(8)   /* This is where the main() stack goes */
    } > MSRAM
	
	/* add the resource table */
    GROUP {
        /* This is the resource table used by linux to know where the IPC "VRINGs" are located */
        .resource_table: {} palign(4096)
    } > DDR_0


    /* This is where the stacks for different R5F modes go */
    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)
    } > MSRAM

    /* Sections needed for C++ projects */
    GROUP {
        .ARM.exidx:  {} palign(8)   /* Needed for C++ exception handling */
        .init_array: {} palign(8)   /* Contains function pointers called before main */
        .fini_array: {} palign(8)   /* Contains function pointers called after main */
    } > MSRAM

    /* General purpose user shared memory, used in some examples */
    .bss.user_shared_mem (NOLOAD) : {} > USER_SHM_MEM
    /* this is used when Debug log's to shared memory are enabled, else this is not used */
    .bss.log_shared_mem  (NOLOAD) : {} > LOG_SHM_MEM
    /* this is used only when IPC RPMessage is enabled, else this is not used */
    .bss.ipc_vring_mem   (NOLOAD) : {} > RTOS_NORTOS_IPC_SHM_MEM
    /* General purpose non cacheable memory, used in some examples */
    .bss.nocache (NOLOAD) : {} > NON_CACHE_MEM
}

/*
NOTE: Below memory is reserved for DMSC usage
 - During Boot till security handoff is complete
   0x701E0000 - 0x701FFFFF (128KB)
 - After "Security Handoff" is complete (i.e at run time)
   0x701F4000 - 0x701FFFFF (48KB)

 Security handoff is complete when this message is sent to the DMSC,
   TISCI_MSG_SEC_HANDOVER

 This should be sent once all cores are loaded and all application
 specific firewall calls are setup.
*/

MEMORY
{
    R5F_VECS  : ORIGIN = 0x00000000 , LENGTH = 0x00000040
    R5F_TCMA  : ORIGIN = 0x00000040 , LENGTH = 0x00007FC0
    R5F_TCMB0 : ORIGIN = 0x41010000 , LENGTH = 0x00008000

    /* memory segment used to hold CPU specific non-cached data, MAKE to add a MPU entry to mark this as non-cached */
    NON_CACHE_MEM : ORIGIN = 0x70060000 , LENGTH = 0x8000

    /* when using multi-core application's i.e more than one R5F/M4F active, make sure
     * this memory does not overlap with other R5F's
     */
    MSRAM     : ORIGIN = 0x70080000 , LENGTH = 0x40000
	
    /* Resource table must be placed at the start of the "external code/data mem"
     * section that Linux allocates for the core.
     * R5F0_0 default allocation is at 0xa0100000
     */
    DDR_0     : ORIGIN = 0xa0100000 , LENGTH = 0x100000

    /* This section can be used to put XIP section of the application in flash, make sure this does not overlap with
     * other CPUs. Also make sure to add a MPU entry for this section and mark it as cached and code executable
     */
    FLASH     : ORIGIN = 0x60100000 , LENGTH = 0x80000

    /* shared memory segments */
    /* On R5F,
     * - make sure there is a MPU entry which maps below regions as non-cache
     */
    USER_SHM_MEM            : ORIGIN = 0x701D0000, LENGTH = 0x80
    LOG_SHM_MEM             : ORIGIN = 0x701D0000 + 0x80, LENGTH = 0x00004000 - 0x80
    RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0x701D4000, LENGTH = 0x0000C000
}

Linker file linker.cmd using 09_00_00_35 SDK. This file was modified based on instructions on dev.ti.com/.../node

 /* 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    


    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 
    MSRAM   : ORIGIN = 0x70080000 , LENGTH = 0x40000 
    FLASH   : ORIGIN = 0x60100000 , LENGTH = 0x80000 
    DDR_0   : ORIGIN = 0xA0100000 , LENGTH = 0x1000 
    DDR_1   : ORIGIN = 0xA0101000 , LENGTH = 0xEFF000 
    LINUX_IPC_SHM_MEM   : ORIGIN = 0xA0000000 , LENGTH = 0x100000 
    USER_SHM_MEM   : ORIGIN = 0xA5000000 , LENGTH = 0x80 
    LOG_SHM_MEM   : ORIGIN = 0xA5000080 , LENGTH = 0x3F80 
    RTOS_NORTOS_IPC_SHM_MEM   : ORIGIN = 0xA5004000 , LENGTH = 0xC000 

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


}

Linker.cmd using 09_01_00_41 SDK. This file was created based on reference from YouTube video

Hi,

The subject matter expert is out of office and will get back to you by end of the week.

Regards,
Krunal

Apart from above query. I am adding another query related to same topic.

The LED blink example was working as expected (with SDK 09_01_00_41) on R5 core when I ran it from Linux.

But when I ran the I2C LED example, the LEDs (which are connected to IO expander) just remained ON and did not blink/flash as expected. I believe it has to do with interrupts handling when running from Linux. I am not very sure though. Kindly let me know what is going wrong there?

Thanks

Amey

Thank you Nick for your reply.

Nick Saulnier said:

If you give me a timestamp I can take a quick look.

I have attached the screenshot of the ppt as shown in the YouTube video in my first post above. In the image above you can see the timestamp where this information is shared in the video. 

Although there was not need to run this command, I was able to execute both the .out files (with and without armstrip command), I am just curious to know why it was needed. 

I will review the .map file. 

Please also look at another query (quoted below) whenever you can

Amey P said:

Apart from above query. I am adding another query related to same topic.

Thanks

Amey

Hello Amey,

the armstrip command

Ahh, ok. In this case, the strip command is removing any extra information in the binary that is not needed to run the program.

I am not an expert on exactly how the R5F firmware binaries are constructed, so I will only be able to talk about general concepts here. By default, when we build a remote core binary with the "debug" profile (and potentially also when we build the binary with the "release" profile), there is additional information called "symbols" that are built into the binary along with the instruction code and data code. https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/CCS_PROJECTS_PAGE.html#autotoc_md417

That "symbol" information is what allows the CCS debugger to map the project's source code with the compiled binary code running on the remote core. So if you want to be able to use CCS to debug your project while the project is running, you do NOT want to strip out the symbol data.

On the other hand, if you are just trying to make the binaries take up as little space in your filesystem as possible, then you would want to strip out the symbol data. I have not experimented with this feature yet, so I am not sure exactly how much space you save by stripping out the symbols.

Regards,

Nick

Hello Amey,

The I2C expander examples are not working when Linux is running 

Any MCU+ SDK I2C examples that use the I2C expander on the AM64x EVM will probably NOT work when Linux is running. We are actually currently debugging a similar issue with an R5F PRU Ethernet + Linux example, where both R5F and Linux want to use peripherals that are connected through the I2C expander that is controlled by Linux.

As we discuss in the AM64x academy, multicore module, page "How to allocate peripherals":
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AROmAnuFxeqz306G2XuoZw__AM64-ACADEMY__WI1KRXP__LATEST

In general, each peripheral should only be controlled by a single software instance. So in the case of AM64x EVM, I2C1 should be controlled by either Linux, OR one of the R5F cores. That is problematic, since we grouped a bunch of useful signals into the same I2C instance.

I am actually meeting with some of the developers who were working on the networking usecase later this week to see if they were ever able to work around it. But in the meantime, it would be better for the R5F core to use an I2C instance that is not controlled by Linux (or an I2C instance that can be disabled in Linux without losing key Linux functionality).

Regards,

Nick

Hello Nick

Thanks for your reply on armstrip command. That clarifies things

The I2C example uses I2C1 port for communicating with the LEDs because that is hardwired in the EVK. Hence changing I2C port in the LED example may not be possible unless I am using an external I2C chip via user expansion port.

I will see if I can disable the I2C1 in the Linux device tree so that this issue can be resolved

But lets say that Linux is using the I2C1, then for what will it use it? any references to this are available?

Thanks

Amey

Hello Amey,

What are you looking for in your final design?

If you are just looking for an LED example, and you do not care how you are connecting to the LED, then we also have an example that uses GPIO signals to control the LEDs:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_GPIO_LED_BLINK.html

If you are specifically looking for an example that controls LEDs over I2C, you could certainly try disabling I2C1 in the Linux devicetree to see what happens. I was going to do that, but then I got nervous about all the different signals (e.g., the SD card control signal) that Linux was using. I am not sure whether Linux would boot properly, or if Linux did boot if there would be issues (like if the SD card communication rate would be lowered).

Or for now, you could do the "I2C LED" part of your design separate from the rest of your design. Then once you have your own custom board where the Linux and the R5F core each have a separate I2C instance, you could combine those two projects into one single project.

Regards,

Nick

Hello Nick

I am trying to learn multi-core development. So trying I2C example was just a step. And during this test I realized that Linux is initializing peripheral which it may or may not use. It is possible in the final design one of the I2C and SPI (not OSPI) might not be needed in Linux.

I will try it out and post in separate thread if needed

Thanks

Hello Nick

I disabled the I2C1 in the dts file and copied the newly compiled dtb file in the SD card.

The I2C blink example is working now from Linux via remoteproc

Thanks

Amey

Hello Amey,

Glad to hear that things are working for you! Feel free to create a new thread if additional questions come up.

Regards,

Nick