• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1330 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.

Original question:

TDA4VM: when I change /lib/firmware/j7-main-r5f1_0-fw , linux can't boot up

TDA4VM: Error when loading remoteproc firmware via Linux

felix_123
Expert 1251 points
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: 

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

  • +1
    TI__Guru** 111215 points

    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

  • 0 in reply to Suman Anna
    Expert 1251 points

    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

  • 0 in reply to felix_123
    TI__Guru** 111215 points

    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

  • 0 in reply to Suman Anna
    Expert 1251 points

    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