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.

TDA4VM: Error when loading remoteproc firmware via Linux

Part Number: TDA4VM

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: 

Fullscreen
1
2
3
4
5
6
7
8
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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

All firmware binaries include a .resource_table section, which is needed when booting these cores via Linux. (MCU3_1 fw as an example):

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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...
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    [ 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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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 

    Fullscreen
    1
    run get_overlay_${kern_boot}
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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