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.

RTOS/PROCESSOR-SDK-AM57X: OCMC RAM usage

Part Number: PROCESSOR-SDK-AM57X

Tool/software: TI-RTOS

Hello again,

I have a question about using OCMC RAM in my user application after the PDK bootloader has completed. Specifically, please see the following picture, which is from this link on the wiki: http://processors.wiki.ti.com/index.php/Processor_SDK_RTOS_BOOT_AM57x#Application_Integration

The wiki page has the following notes under this image:

  • Once the application boots and is running it is free to use the SBL_MEM region .
  • During the Board initialization, applications are not supposed to modify the first 192KBytes of the OCMC region starting from 0x40300000 to avoid pinmux data corruption.
  • The reserved memory area contains Pinmux and IO delay configurations code and data area and should not be used for other purposes.

My first question is: After the bootloader has run to completion and my board has been completely initialized, am I able to use the entire OCMC RAM in my application code, or must I not use the "reserved mem" part between 0x40300000 and 0x40330000? If the answer is that I cannot use the "reserved mem" portion, then I would like to understand why that is the case.

My second question is: I noticed that when I build the bootloader and look at the MAP file, the BOARD_IO_DELAY_CODE and BOARD_IO_DELAY_DATA sections are not allocated to the "reserved mem" area; they are actually in the other part of MSMC RAM. This leads me to ask, shouldn't these two sections be allocated to OCMC_RAM1 in pdk_am57xx_1_0_9\packages\ti\boot\sbl\soc\am57xx\linker.cmd? I think this omission might be a minor bug in the PDK.

Thanks as always,
Dave

  • Dave,

    Having re-read the notes under the graphic, I think those notes are a little vague in the information that it is trying to convey and inaccurate as far as placement of BOARD_IO_DELAY_CODE and BOARD_IO_DELAY_DATA  is concerned so I will answer your questions here and then try to update those notes to add more clarification.

    After the bootloader completes executing and the board is initialized, you can use the entire OCMC RAM in your application code. Ideally, all of the initialization should be consolidated in the bootloader so that the app doesn`t have to re-do these initialization.

    Having said that we have observed some application code written in a way where it may try to access the pinmux data to check the muxmode or re-uses this data to restore default setup pin setup. this is just a caution statement to make the user aware of the usage so they don`t accidentally corrupt the data before Board_init is called to setup pinmux.

    I check the linker.cmd file and the sbl.map file for bootloader and agree with your analysis in the second question that the pinmux data in BOARD_IO_DELAY_CODE and BOARD_IO_DELAY_DATA  is not being placed in the OCMC_RAM1. All the SBL code and data is currently located in a section called SBL_MEM. 

    The way to put those sections in OCMC_RAM1 would require you to add the following in the linker command file.

    BOARD_IO_DELAY_CODE :
    {
     . = ALIGN(4);
     *(BOARD_IO_DELAY_CODE*)
    } > OCMC_RAM1
     
    BOARD_IO_DELAY_DATA :
    {
     . = ALIGN(4);
     *(BOARD_IO_DELAY_DATA*)
    } > OCMC_RAM1

    I agree this is a minor bug that I will file to get it resolved. While this is a deviation from the current documentation, there is no issues with this implementation as the main thing to adhere to is to run the pinmux configuration code from onchip memory rather than external memory as specified in the TRM.

    Regards,

    Rahul

    PS: Issue can be tracked using bug ID PRSDK-3464

  • Rahul, thank you very much! You answered my question completely. Have a great day.

    Best regards,
    Dave