• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 226 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.

AM6422: Memory Map Layout

wanglili 王
Intellectual 700 points
Part Number: AM6422

Tool/software:

Hello，

    The version of the SDK we are using is 8.6, and it supports both Linux and FreeRTOS. During normal operation, only core 5F0-0 is utilized, so we allocated the memory resources of the other cores to this core, amounting to approximately 60M. Since the R5F core involves the process of parsing XML files during runtime, our tests revealed that the parsing time was progressively increasing, reaching a maximum of 80 seconds, which is unacceptable to us. My colleague discovered that the issue might be due to insufficient memory allocation, leading to memory fragmentation during memory requests and thus longer processing times for subsequent requests. To address this problem, we increased the memory allocated to R5F in the device tree to 300M. The system compiled and ran successfully, and the XML file parsing time was reduced to 10 seconds. Based on this observation, it appears that the issue was indeed caused by insufficient memory allocation. However, we still have some concerns. According to the DDR resource allocation defined in the link

https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/09_01_00_41/exports/docs/api_guide_am64x/MEMORY_MAP.html

the maximum available DDR resources for R5F only go up to 0xA5800000. Although our modification allows the system to run, we are worried about potential unforeseen impacts. We would greatly appreciate your feedback on this matter. Thank you very much!

  • 0
    TI__Mastermind 47046 points

    Hello Wanglili,

    When you increase the size of DDR from 1MB to 300MB for the R5F core , then you are overlapping the R5F application memory with Linux Memory allocation.

    This may create an issue. I am routing your query to Linux experts to comment on the above issue.

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Intellectual 700 points

    Is there any update regarding the questions I raised?

  • 0 in reply to wanglili 王
    TI__Guru** 101910 points

    Hello Wanglili,

    Apologies for the delayed response, I am back from vacation and working through my customer requests.

    The MCU+ MEMORY MAP page you linked shows the default memory allocations for R5F projects in the MCU+ SDK. However, those memory allocations are not fixed.

    As Anil said, the most important point is to make sure that the memory allocations are updated in the Linux devicetree file so that the memory allocations in the devicetree file match the memory allocations in your linker command file. Please refer to the AM64x academy for more information about memory allocation:

    Multicore > Memory > How to allocate memory
    https://dev.ti.com/tirex/explore/node?node=A__AWaFtb0qxzmpAt-FGjVcCA__AM64-ACADEMY__WI1KRXP__LATEST 

    Additional notes - TCM memory usage

    Since you are only using R5F0_0, are you actually using AM6422 with all R5F cores? Or are you using one of the other AM64x part numbers that has fewer R5F cores in it?

    If you are not using R5F0_1, I would suggest configuring your R5F subsystem to single core mode. That will free up the TCM memory that is normally reserved for R5F0_1 for use by the R5F0_0 core instead. For an example of how to set the R5F subsystem to single core mode, please refer to the AM64x academy:

    Multicore > Booting and Disabling Processor Cores > Disabling remote cores in Linux
    https://dev.ti.com/tirex/explore/node?node=A__AWQEpuVOCljkhxqRi05Qpw__AM64-ACADEMY__WI1KRXP__LATEST 

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 700 points

    Hello，

        In fact, we have already allocated the memory originally used by other R5F cores to R5F0-0, but that only amounts to 60M. However, in the device tree, we've actually defined it as 300M. Currently, it functions normally, but the defined address has far exceeded 0xA5800000. We're wondering if there are any other potential issues lurking. This is crucial information for us as it may impact our next - step solution design.

  • 0 in reply to wanglili 王
    TI__Guru** 101910 points

    Hello Wanglili,

    As per the "How to allocate memory" page, please make sure to update the linker.cmd file so that it aligns with the Linux devicetree file. If you are allocating 300 MB of DDR in Linux devicetree, you should be doing the same thing in the Linker.cmd file.

    I am not an expert at RTOS development, but you should make sure that you are not seeing any data overflows in your RTOS code. For example, sometimes some memory sections are placed at the beginning of the memory allocation, and are allowed to grow towards the end of the memory allocation. And sometimes some memory sections are placed at the end of the memory allocation (I have seen that for some MCU+ projects on AM62x, not sure if the same thing happens on AM64x projects). You want to make sure that your memory sections that grow will not overwrite the memory sections that come later.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 700 points

    Hello，

        Yes, after we modified the addresses in the device tree, the linkcmd file was updated accordingly, and currently, there have been no abnormal issues during usage. So, can it be understood that if I align the addresses on both sides, even when operating at 300 MHz, it won't affect the operation of both the Linux kernel and the RTOS?

        Thank you for your message.

  • 0 in reply to wanglili 王
    TI__Guru** 101910 points

    Hello Wanglili,

    Your understanding is correct. As long as the allocations are aligned, Linux and RTOS should not overwrite each other's memory.

    The only other thing to keep in mind is to make sure that there is enough DDR left for your Linux system to operate as expected.

    Regards,

    Nick