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 TI,
I want to load and start remoteprocs (MCU2_0, MCU2_1, MCU3_0, MCU3_1, C66_1, C66_2, C71) via Linux. the lib/firmware directory looks like this:
lrwxrwxrwx 1 felix felix 43 Sep 15 09:29 j7-c66_0-fw -> vision_apps_evm/vx_app_rtos_linux_c6x_1.out lrwxrwxrwx 1 felix felix 43 Sep 15 09:29 j7-c66_1-fw -> vision_apps_evm/vx_app_rtos_linux_c6x_2.out lrwxrwxrwx 1 felix felix 43 Sep 15 09:29 j7-c71_0-fw -> vision_apps_evm/vx_app_rtos_linux_c7x_1.out lrwxrwxrwx 1 felix felix 41 Sep 15 10:25 j7-main-r5f0_0-fw -> ipc_echo_test_freertos_mcu2_0_debug.xer5f lrwxrwxrwx 1 felix felix 44 Sep 15 09:28 j7-main-r5f0_1-fw -> vision_apps_evm/vx_app_rtos_linux_mcu2_1.out lrwxrwxrwx 1 felix felix 41 Sep 15 11:53 j7-main-r5f1_0-fw -> ipc_echo_test_freertos_mcu3_0_debug.xer5f lrwxrwxrwx 1 felix felix 41 Sep 15 11:53 j7-main-r5f1_1-fw -> ipc_echo_test_freertos_mcu3_1_debug.xer5f lrwxrwxrwx 1 felix felix 49 Sep 15 09:28 j7-mcu-r5f0_0-fw -> pdk-ipc/ipc_echo_testb_mcu1_0_release_strip.xer5f
All firmware binaries include a .resource_table section, which is needed when booting these cores via Linux. (MCU3_1 fw as an example):
felix@felix-virtual-machine:~/ti-processor-sdk-linux-j7-evm-08_00_00_08/targetNFS/lib/firmware$ readelf -l ipc_echo_test_freertos_mcu3_1_debug.xer5f Elf file type is EXEC (Executable file) Entry point 0x0 There are 10 program headers, starting at offset 2344688 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000038 0x00000000 0x00000000 0x00df0 0x00df0 R E 0x8 LOAD 0x001000 0xa5100000 0xa5100000 0x0008c 0x0008c R 0x1000 LOAD 0x001400 0xa5100400 0xa5100400 0x00000 0x80000 RW 0x400 LOAD 0x001400 0xa5400000 0xa5400000 0x00000 0x181400 RW 0x80 LOAD 0x001400 0xa5581400 0xa5581400 0x005a0 0x005a0 R 0x8 LOAD 0x002000 0xa5582000 0xa5582000 0x00000 0x33c58 RW 0x2000 LOAD 0x002000 0xa55b5c58 0xa55b5c58 0x16298 0x16298 R E 0x8 LOAD 0x018300 0xa55cbf00 0xa55cbf00 0x00000 0x03a80 RW 0x80 LOAD 0x018300 0xa5ffac00 0xa5ffac00 0x00000 0x01400 R 0x4 LOAD 0x018300 0xa5ffc000 0xa5ffc000 0x00000 0x04000 RW 0x8 Section to Segment mapping: Segment Sections... 00 .freertosrstvectors .bootCode .startupCode .startupData .text.hwi .text.cache .text.mpu .text.boot .data_buffer .bss.devgroup* 01 .resource_table 02 .tracebuf 03 ipc_data_buffer __llvm_prf_cnts 04 .cinit 05 .bss 06 .text .const 07 .data 08 .irqStack .fiqStack .abortStack .undStack .svcStack 09 .stack
However, when booting, Linux stops here logBootIssue.txt .
So MCU2_0, MCU2_1, C66_1, C66_2 and C71 are loaded and started via U-Boot, and MCU3_0 and MCU3_1 are loaded and started via Linux. Linux Boot stops when it is trying to start MCU3_1.
When adding MCU3_0 and MCU3_1 also to the U-Boot start process I get this log: logBoot.txt
Here, Linux boots fine, but I get some error at around [ 19.124293]. Again, the application loaded on MCU3_0 and MCU3_1 are default ipc_echo_test_freertos applications.
To me it seems, that there is something broken concerning the booting of MCU3_0 and MCU3_1.
Can you please help me on that issue?
Thanks and best regards,
Felix
Hi Felix,
You are mixing the Vision Apps firmwares with the base IPC echo test firmwares, which have conflicting/overlapping memory regions.
[ 18.825193] platform 5e00000.r5f: configured R5F for remoteproc mode [ 18.917079] platform 5e00000.r5f: assigned reserved memory node vision-apps-r5f-dma-memory@a6000000 [ OK ] Created slice system-systemd\x2dfsck.slice. [ 19.237924] remoteproc remoteproc6: 5e00000.r5f is available [ 19.363087] m_can_platform 40528000.can: m_can device registered (irq=23, version=32) [ 19.376290] m_can_platform 40568000.can: m_can device registered (irq=25, version=32) [ 19.485001] platform 5f00000.r5f: configured R5F for remoteproc mode [ 19.513899] platform 5f00000.r5f: assigned reserved memory node vision-apps-r5f-dma-memory@a7000000 [ 19.604916] remoteproc remoteproc6: powering up 5e00000.r5f [ 19.610730] remoteproc remoteproc6: Booting fw image j7-main-r5f1_0-fw, size 2346888 [ 19.628565] remoteproc remoteproc6: bad phdr da 0xa4100000 mem 0x8c [ 19.639768] remoteproc remoteproc6: Failed to load program segments: -22
The K3 R5F and DSP remote processors do not use an MMU, so DDR memory needs to be reserved for each core. The remoteproc drivers perform a range check when loading firmware segments to ensure that one remoteproc firmware is not corrupting the memory segments used by another remoteproc.
The Vision Apps uses a different memory layout (Applied through the k3-j721e-vision-apps.dtbo overlay) and uses a different memory regions for MCU3_0 and MCU3_1 (other than MCU1_0 and MCU1_1, all other cores are affected). They use 16 MB at 0xa6000000 and 0xa7000000 instead of the default 0xa5000000 and 0xa6000000, and remoteproc load code errors out due to the mismatch. You can see the addresses assigned from the above snippet from your logBootIssue.txt.
U-Boot does not perform any range checks, but Linux kernel does. You will need to re-build the IPC example firmwares with updated linker command file and MPU settings matching the vision apps memory layout to run properly.
regards
Suman
Hi Suman,
thanks very much for your detailed answer.
When using default IPC echo test firmware for all remote cores, removing
run get_overlay_${kern_boot}
from U-Boot bootcmd to avoid loading k3-j721e-vision-apps.dtbo overlay solved the memory region mismatch.
When using vision_apps for all remote cores, booting with device tree overlay works fine, since the memory regions are correct here.
Best regards,
Felix
Hi Felix,
I am not sure if you are executing this step manually or leveraging the default bootcmd. Preferred way to do this is to modify the name_overlays or equivalent variable to not include the k3-j721e-vision-apps.dtbo. There can be other overlays as well, and removing the variable like above would not load any of them.
regards
Suman
Hi Suman,
I manually edited the default bootcmd, but you are right. Modifiying name_overlays would be a much cleaner way to not include specific DT overlays.
Thanks again and best regards,
Felix