Other Parts Discussed in Thread: TMDS64EVM, SYSCONFIG
MCU+SDK 9.1
Linux+SDK 8.6
TMDS64EVM
Hello:
During our testing, we encountered a problem that the program ran slower on DDR than on MSRAM. The link above is the question we FAE asked earlier and also the background to my question.
First answer the questions raised in the previous link:
The example I use is gpio_led_blink, which comes from the MCU+SDK 9.1 package. The project name for the example is gpio_led_blink_am64x_evm_r5fss0-0_nortos_ti-arm-clang. As we can see, this is a program running on the R5F0-0 kernel. I have seen the program before, only the example code control of the peripheral is the output of GPIO, not the input. My understanding is that it does not have the input interrupt related issues mentioned in the above link.
The gpio_led_blink example is successfully configured to boot from Linux to the DDR, and the LED light can be observed blinking.
I've also seen the AM64x academy Multicore module development documentation, which doesn't seem to mention how to allocate SRAM nodes in the device tree on Linux systems.
https://dev.ti.com/tirex/explore/node?node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST
I want to implement Linux system boot R5F CPU project running on MSRAM:
For the CCS project, I refer to and compare the linker.cmd and example.syscfg files running on the DDR and MSRAM programs. The following configuration is done for example.syscfg file (MCU+SDK 9.1 linker.cmd can be modified in example.syscfg, and the resource table size is set to 0x1000.)
MSRAM : ORIGIN = 0x70080000 , LENGTH = 0x40000
Change to
MSRAM0 : ORIGIN = 0x70080000 , LENGTH = 0x1000
MSRAM1 : ORIGIN = 0x70081000 , LENGTH = 0x3F000
Change on SECTION
MSRAM0 –> resource_table
MSRAM1 -> Text Segments 、Code and Read-Only Data、Data Segment、Memory Segments、Stack Segments、Initialization and Exception Handling
After testing with the above changes, I found that the program did not load successfully.
Based on the above test and previous responses on the post, I have the following questions:
>First, if I recall correctly that reserved-memory section that was modified in the customer's device tree is for the DDR specifically. You can find the SRAM allocations in the am64-main.dtsi file. So if the customer is adding an SRAM allocation, they need to add it to the SRAM node instead of the DDR node.
Where is the SRAM node in the k3-am64-main.dtsi file? How do I allocate SRAM? What changes do I need to make to the k3-am642-evm.dts file after SRAM allocation?
>Second, please note that we have only tested the 1MB VIRTIO section as working in the DDR, NOT in the SRAM. I am not sure whether the resource table also needs to be in DDR, or if it can go into the SRAM. But that is another thing to test.
Is it verified that the R5F CPU program is booted into MSRAM memory by Linux system? Or does it work in theory?
If it has been verified and feasible, can TI provide a modification example for our reference, including the modification of the device tree file?
