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

TDA4VH-Q1: firmware loading with remoteproc in split mode

Matthias Schellhase
Prodigy 41 points

Part Number: TDA4VH-Q1

I am using remoteproc to start and stop the firmwares on a J784S4 platform.

The r5 cores are operating in split mode. In order to deploy firmware on the second core (e.g. mcu2_1)
I need to deploy a firmware on the mcu2_0-core first. Otherwise, the whole system freezes.

A similar problem has been reported two years ago:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1028833/tda4vm-system-blocked-after-booting-fw-with-remoteproc-mode

In my case the problem doesn't seem to be related to the firmware size. Is this workaround still needed or is there a fix available?


Regards,

Matthias

  • 0
    TI__Guru* 78165 points

    Matthias

    Matthias Schellhase said:
    The r5 cores are operating in split mode. In order to deploy firmware on the second core (e.g. mcu2_1)
    I need to deploy a firmware on the mcu2_0-core first. Otherwise, the whole system freezes.

    This is a requirement due to the integration of the R5F cluster on the device. Core 1 can not be at a higher state than Core 0 of the same cluster. So this has to be adhered to now as well.

    Can you please elaborate on your booting sequence? Is the MCU2 cluster being booted by u-boot or are you relying on Kernel to do this? I believe we recently fixed made a change to the kernel remoteproc driver to boot Core 0 before Core 1 and not boot them in any random order based on the size of the firmware - I need to double check this.

    Matthias Schellhase said:
    In my case the problem doesn't seem to be related to the firmware size. Is this workaround still needed or is there a fix available?

    Please elaborate on the boot flow and which stage boots the R5F clusters.

    Regards

    Karan

  • 0 in reply to Karan Saxena
    Prodigy 41 points

    Hello Karan,

    Thanks for your reply.

    Currently, I load both firmwares manually by writing to the sysfs: 

    echo ipc_echo_test_freertos_mcu2_0_debug.xer5f > /sys/class/remoteproc/remoteproc1/firmware
echo start > /sys/class/remoteproc/remoteproc1/state

echo my_firmware_mcu2_1.xer5f > /sys/class/remoteproc/remoteproc2/firmware
echo start > /sys/class/remoteproc/remoteproc2/state


    This is my setup I use for development. Neither u-boot or the Kernel load any firmware at bootup.
    Eventually the Kernel bootup shall start the MCU2 cluster, but this is currently not the case:

    ...
[    7.280485] platform 5c00000.r5f: configured R5F for remoteproc mode
[    7.280838] platform 5c00000.r5f: assigned reserved memory node r5f-dma-memory@a2000000
[    7.281677] remoteproc remoteproc2: 5c00000.r5f is available
[    7.282326] platform 5d00000.r5f: configured R5F for remoteproc mode
[    7.282708] platform 5d00000.r5f: assigned reserved memory node r5f-dma-memory@a3000000
[    7.283851] remoteproc remoteproc3: 5d00000.r5f is available
[    7.298780] platform 5e00000.r5f: configured R5F for remoteproc mode
[    7.301003] platform 5e00000.r5f: assigned reserved memory node r5f-dma-memory@a4000000
[    7.302088] remoteproc remoteproc4: 5e00000.r5f is available
[    7.303880] platform 5f00000.r5f: configured R5F for remoteproc mode
[    7.305254] platform 5f00000.r5f: assigned reserved memory node r5f-dma-memory@a5000000
[    7.306618] remoteproc remoteproc5: 5f00000.r5f is available
[    7.312253] remoteproc remoteproc5: Direct firmware load for j784s4-main-r5f1_1-fw failed with error -2
[    7.312270] remoteproc remoteproc5: powering up 5f00000.r5f
[    7.312292] remoteproc remoteproc5: Direct firmware load for j784s4-main-r5f1_1-fw failed with error -2
[    7.312297] remoteproc remoteproc5: request_firmware failed: -2
[    7.312329] remoteproc remoteproc4: Direct firmware load for j784s4-main-r5f1_0-fw failed with error -2
[    7.312335] remoteproc remoteproc4: powering up 5e00000.r5f
[    7.312351] remoteproc remoteproc4: Direct firmware load for j784s4-main-r5f1_0-fw failed with error -2
[    7.312355] remoteproc remoteproc4: request_firmware failed: -2
[    7.312386] remoteproc remoteproc3: Direct firmware load for j784s4-main-r5f0_1-fw failed with error -2
[    7.312390] remoteproc remoteproc3: powering up 5d00000.r5f
[    7.312405] remoteproc remoteproc3: Direct firmware load for j784s4-main-r5f0_1-fw failed with error -2
[    7.312409] remoteproc remoteproc3: request_firmware failed: -2
[    7.316138] platform 5900000.r5f: configured R5F for remoteproc mode
[    7.318510] platform 5900000.r5f: assigned reserved memory node r5f-dma-memory@a6000000
[    7.322557] remoteproc remoteproc2: Direct firmware load for j784s4-main-r5f0_0-fw failed with error -2
[    7.322574] remoteproc remoteproc2: powering up 5c00000.r5f
[    7.322608] remoteproc remoteproc2: Direct firmware load for j784s4-main-r5f0_0-fw failed with error -2
[    7.322613] remoteproc remoteproc2: request_firmware failed: -2
[    7.323375] remoteproc remoteproc6: 5900000.r5f is available
[    7.323730] remoteproc remoteproc6: Direct firmware load for j784s4-main-r5f2_0-fw failed with error -2
[    7.323737] remoteproc remoteproc6: powering up 5900000.r5f
[    7.323756] remoteproc remoteproc6: Direct firmware load for j784s4-main-r5f2_0-fw failed with error -2
[    7.323761] remoteproc remoteproc6: request_firmware failed: -2
[    7.324813] platform 5a00000.r5f: configured R5F for remoteproc mode
[    7.325520] platform 5a00000.r5f: assigned reserved memory node r5f-dma-memory@a7000000
[    7.326429] remoteproc remoteproc7: 5a00000.r5f is available
[    7.326553] remoteproc remoteproc7: Direct firmware load for j784s4-main-r5f2_1-fw failed with error -2
[    7.326560] remoteproc remoteproc7: powering up 5a00000.r5f
[    7.326578] remoteproc remoteproc7: Direct firmware load for j784s4-main-r5f2_1-fw failed with error -2
[    7.326583] remoteproc remoteproc7: request_firmware failed: -2
...


    Here it seems that the order of loading is random. Please send me a link to the fix in the remoteproc driver,
    so we can cherry-pick it. We are using a custom 6.1 Kernel.

    Thanks!

    Regards
    Matthias

  • 0 in reply to Matthias Schellhase
    TI__Guru* 78165 points

    Hi Matthias

    Matthias Schellhase said:

    This is my setup I use for development. Neither u-boot or the Kernel load any firmware at bootup.
    Eventually the Kernel bootup shall start the MCU2 cluster, but this is currently not the case:

    Do you have the firmware's elf images in the /lib/firmware/ and also named appropriately as below:

    /lib/firmware/j784s4-main-r5f1_0-fw

    /lib/firmware/j784s4-main-r5f1_1-fw

    /lib/firmware/j784s4-main-r5f2_0-fw

    /lib/firmware/j784s4-main-r5f2_1-fw

    Regards

    Karan

  • 0 in reply to Karan Saxena
    Prodigy 41 points

    Hi Karan

    these files don't exist yet and this is fine. I copy the firmware images manually to /lib/firmware and use sysfs to run them.
    Sorry for the confusion, I just listed the Kernel output because of the peculiar order in which the driver wants to load the images.
    But as you mentioned there is a fix for this...?

    I think my initial question is already answered: I need something running on Core 0 before I may use Core 1. This is a requirement.

    I have some follow-up questions:
    1. Does "Core 1 can not be at a higher state than Core 0" also require that Core 0 must not be stopped before Core 1?
    2. Is firmware re-launching via remoteproc a supported feature on TDA4VH-Q1?

    Regards
    Matthias

  • 0 in reply to Matthias Schellhase
    TI__Guru* 78165 points

    Matthias

    Matthias Schellhase said:
    1. Does "Core 1 can not be at a higher state than Core 0" also require that Core 0 must not be stopped before Core 1?

    This is correct, Core0 can not be stopped without stopping Core1.

    Matthias Schellhase said:
    2. Is firmware re-launching via remoteproc a supported feature on TDA4VH-Q1?

    This is currently not supported, booting remotecores from u-boot and Kernel is supported. I'm checking when is this feature planned.

    Regards

    Karan

  • 0 in reply to Karan Saxena
    TI__Guru* 78165 points
    Karan Saxena said:
    This is currently not supported, booting remotecores from u-boot and Kernel is supported. I'm checking when is this feature planned.

    This is tentatively planned for SDK9.2 i.e. March 2024.

    Regards

    Karan