Other Parts Discussed in Thread: SYSCONFIG
Dear TI supporters,
SDK8.0 supports to initialize DDR in SBL but does not has sample source running on DDR.
Can you provide me the steps to configure a R5/M4 application can execute on DDR?
Thanks
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.
Hi Thinh,
In the linker.cmd file add the below line to the MEMORY portion of the file
DDR_MEM_MCU0 : ORIGIN = 0x80000000 , LENGTH = 0x80000
Then you would assign the lines for SECTIONS to the defined DDR mem.
Hello Ahmad Rashed,
I have change linker as your suggestion in hello world sample.
But It seems that the R5F's helloworld sample does not run on DDR.
I debug ospi SBL by adding print log in function:
int32_t Bootloader_rprcImageLoad(Bootloader_Handle handle, Bootloader_CpuInfo *cpuInfo) { Bootloader_RprcFileHeader header; Bootloader_RprcSectionHeader section; int32_t status = SystemP_SUCCESS; Bootloader_Config *config = (Bootloader_Config *)handle; config->fxns->imgSeekFxn(cpuInfo->rprcOffset, config->args); status = config->fxns->imgReadFxn(&header, sizeof(Bootloader_RprcFileHeader), config->args); if(header.magic != BOOTLOADER_RPRC_MAGIC_NUMBER) { status = SystemP_FAILURE; } else { cpuInfo->entryPoint = (uintptr_t)header.entry; DebugP_log("cpuInfo->entryPoint=%x\r\n",cpuInfo->entryPoint); uint32_t i; for(i=0; i<header.sectionCount; i++) { status = config->fxns->imgReadFxn(§ion, sizeof(Bootloader_RprcSectionHeader), config->args); DebugP_log("section.addr=%x, cpu.id=%d \r\n", section.addr, cpuInfo->cpuId); section.addr = Bootloader_socTranslateSectionAddr(cpuInfo->cpuId, section.addr); DebugP_log("section.addr=%x, section.size=%x, \r\n"); /* TODO:Add check for SBL reserved memory */ status = config->fxns->imgReadFxn((void *)(uintptr_t)(section.addr), section.size, config->args); DebugP_log("Status=%d \r\n", status); } } return status; }
And log of SBL as below:
Starting OSPI Bootloader ... DMSC Firmware Version 21.5.0--v2021.05 (Terrific Llam DMSC Firmware revision 0x15 DMSC ABI revision 3.1 Bootloader_loadCpu: M4F Bootloader_loadCpu: R5F1 Bootloader_loadCpu: R5F1-1 Bootloader_loadCpu: R5F0 cpuInfo->entryPoint=0 section.addr=0, cpu.id=1 section.addr=700232f8, section.size=0, Status=0 section.addr=70080000, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=70080a80, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=70080f60, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=70081490, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=70081600, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=80000000, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=80012950, cpu.id=1 section.addr=70023310, section.size=2, Status=0 section.addr=80021c40, cpu.id=1 section.addr=70023310, section.size=2, Status=0 INFO: Bootloader_loadSelfCpu:199: CPU r5f0-0 is initialized to 800000000 Hz !!! INFO: Bootloader_loadSelfCpu:199: CPU r5f0-1 is initialized to 800000000 Hz !!! INFO: Bootloader_runCpu:147: CPU m4f0-0 is initialized to 400000000 Hz !!! INFO: Bootloader_runCpu:147: CPU r5f1-0 is initialized to 800000000 Hz !!! INFO: Bootloader_runCpu:147: CPU r5f1-1 is initialized to 800000000 Hz !!! INFO: Bootloader_runSelfCpu:216: All done, reseting self ...
I read through the MCU_SDK_8.0 and focusing on the bootloader_soc.c, the Bootloader_CoreAddrTranslateInfo gAddrTranslateInfo[] does not define the execution environment on DDR.
Can you help me to define the addrRegionInfo for MCU on DDR?
Thanks
Just to be sure, can you open the syscfg file in the SysConfig tool and then check the config under MPU ARMv7?
The bootloader and hello world application should have an MPU config for the DDR space if it isn't there already.
Also, you can check if DDR is configured successfully by checking the 0x8000 0000 memory address in the CCS Memory Browser. After the bootloader runs the DDR should be configured so within CCS connect to an R5F core and test whether the 0x80000000 address is writable.
Hello Ahmad,
Thank for your remind I have checked my FW It can run on DDR in debug mode as image
But when I flash fw binary in NOR, It does not operate. I didn't know. I will check my process.
Thanks for your suggestion.
Hello Ahmad,
I can implement the R5 firmware running on DDR.
I have also tried to do the same work on M4F core but not success. If add a
more MPU region on DDR then it will be overlapped RAT region#0.
Does TI support the isolated MCU core to run on DDR?
Thanks
Hi,
Yes, M4F MCU supports access to DDR. You can confirm that by access 0x8000_0000 via CCS memory browser from M4F.
Can you please let me know if you are facing any issues accessing DDR from M4F?
Regards,
Prasad, Sitara MCU+ SW Apps
Hello Prasad,
I load default sbl null:
python uart_uniflash.py -p /dev/ttyUSB0 --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg
After that, I run hello application of m4fss0_0_nortos as result:
CCS memory browser from M4F works well.
Another case, I modify the linker.cmd file to M4F firmware execute on DDR by below:
/* make sure below retain is there in your linker command file, it keeps the vector table in the final binary */ --retain="*(.vectors)" /* 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 SECTIONS { /* This has the M4F entry point and vector table, this MUST be at 0x0 */ .vectors:{} palign(8) > M4F_VECS .text: {} palign(8) > DDR_MEM_MCU0 /* This is where code resides */ .bss: {} palign(8) > DDR_MEM_MCU0 /* This is where uninitialized globals go */ RUN_START(__BSS_START) RUN_END(__BSS_END) .data: {} palign(8) > DDR_MEM_MCU0 /* This is where initialized globals and static go */ .rodata: {} palign(8) > DDR_MEM_MCU0 /* This is where const's go */ .sysmem: {} palign(8) > DDR_MEM_MCU0 /* This is where the malloc heap goes */ .stack: {} palign(8) > DDR_MEM_MCU0 /* This is where the main() stack goes */ /* General purpose user shared memory */ .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) : {} > IPC_VRING_MEM } MEMORY { M4F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000200 M4F_RAM : ORIGIN = 0x00000200 , LENGTH = 0x0003FE00 /* DDR execution area with 512 KB */ DDR_MEM_MCU0 : ORIGIN = 0x80000000 , LENGTH = 0x80000 /* shared memories that are used by all cores */ /* On M4F, * - By default MSMC RAM is not accessible to M4F, a RAT entry is needed to make it * accessible on M4F * - So make sure there is a RAT entry which has a 1:1 mapping from 0x70000000 to 0x70200000 */ USER_SHM_MEM : ORIGIN = 0x701D0000, LENGTH = 0x00004000 LOG_SHM_MEM : ORIGIN = 0x701D4000, LENGTH = 0x00004000 IPC_VRING_MEM: ORIGIN = 0x701D8000, LENGTH = 0x00008000 }
and then build/reload fw. The CCS memory browser :
with error:
BLAZAR_Cortex_M4F_0: GEL Output: CPU reset (soft reset) has been issued through GEL. BLAZAR_Cortex_M4F_0: File Loader: Verification failed: Values at address 0x80007FF0 do not match Please verify target memory and memory map. BLAZAR_Cortex_M4F_0: GEL: File: /home/brian/ti/mcu_plus_sdk_am64x_08_00_00_21/examples/kernel/dpl/hello_world/am64x-evm/m4fss0-0_nortos/ti-arm-clang/hello_world.release.out: a data verification error occurred, file load failed.
I don't know how modify which files to M4F firmware can be run on DDR.
I think that need to modify the syscfg file but now I don't know what should i do.
Please show me the step by step to config/setup a firmware of isolated M4F MCU run on DDR.
Thank you so much
Thinh
Hello Thinh,
As you were able to run R5 binary with DDR, I assume when you are running the M4 application you are following same steps to configure DDR and your DDR is configured correctly.
So for M4F access issues - have you configured RAT like below for enabling access from M4?
Regards,
Prasad
Hello Prasad,
As your RAT configuration of M4, I saw the helloworld of m4fss0_0 nortos in mcu_sdk 8.0 has already configured. So this issue is not resolved.
I think that to M4F run on DDR, I need to modify execution region of MPU_ARMv7 for mapping to DDR but do not overlap on the first RAT region0.
Hello Prasad,
In order to the M4F firmware run on DDR, I modified the linker file and sysconfig file as below:
Linker:
Entry point and vector table sections stil keep on RAM M4F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000200 // M4F_RAM : ORIGIN = 0x00000200 , LENGTH = 0x0003FE00 Other sections allocated on DDR at 0x90000200 (maybe change 0x90000000) M4F_RAM : ORIGIN = 0x90000200 , LENGTH = 0x0003FE00
In the sysconfg file:
MPU_ARMv7: CONFIG_MPU_REGION1: baseAddr = 0x90000000; size = 256KB RAT Regions: CONFIG_ADDR_TRANSLATE_REGION0: (do not overlap on MPU region1) localAddr = 0x80000000 sysAddr = 0x0 size: 256MB add one more Translate region CONFIG_ADDR_TRANSLATE_REGION4 localAddr = 0x90000000; sysAddr = 0x90000000; size = 256KB
Now my firmware works well. I only tested on gpio_blink_led and helloworld examples.
cheers,
Thinh
Hi Thinh,
Thanks for letting us know the fix. We see earlier RAT configuration of 512MB was conflicting for you so you had to split into two.
Thanks, Prasad