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.

AM5728: DSP, IPU, PRU issue with reinitialization in Linux

Part Number: AM5728

Hello

We have the following situation.

We need to load and start DSP / IPU / PRUSS cores as fast as possible with TI RTOS applications, so we use multi-core application binary loaded via SBL.

We also have SPL as an application for A15 core in the multi-core application.

The A15 core is loaded with SPL -> u-boot -> Linux.

Linux resets and reinitializes DSP / IPU / PRUSS cores (we do not know where) and tries to load them with default applications (with remoteproc driver).

If we delete default applications (located in lib/firmware) cores are still reset on Linux startup.

We have to get rid of resetting and reinitializing DSP / IPU / PRUSS cores in Linux, so the applications loaded via SBL still continue working after Linux is loaded.

How can we achieve this?

P.S. We also need to have IPC functionality between Linux and TI RTOS applications in cores. The possible solution should not affect it.

I think that remoteproc driver has to be functional in this case.

  • The software team have been notified. They will respond here.
  • Pavel,

    The Linux remoteproc driver will reset, load, and then run the cores (DSP/IPU/PRU) during the Linux boot process, as you've seen. The easiest way to stop this from happening is to disable the device tree nodes that correspond to the cores. However, this will make Linux completely unaware of the cores existence so you will lose the IPC functionality between the Linux and TI RTOS applications (if your IPC depends on the Linux remoteproc driver).

    One solution would be for you to leave the device tree alone, but modify the remoteproc drivers' functionality to stop the Linux boot process from attempting to reset/reload your cores. The probe function for the DSP and IPU cores can be found in the 'omap_rproc_probe' function of the drivers/remoteproc/omap_remoteproc.c file. The probe function for the PRU cores can be found in the 'pruss_probe' function of the drivers/remoteproc/pruss.c file.

    So, the three options I see are:

    1. Use the provided/supported remoteproc drivers to load the IPU/DSP/PRU cores
      1. Your cores will start up during the Linux boot process which may not be soon enough for you
    2. Disable the IPU/DSP/PRU nodes in the device tree to stop Linux from resetting/reloading them
      1. This will allow you to load the cores during your SBL process and Linux should leave them alone
      2. You will most likely need to modify your IPC between the cores because Linux will no longer be aware of the cores since they are not in the device tree
    3. Modify the remoteproc Linux drivers to no longer perform the reset/reload functionality
      1. It may be possible to still have the IPC functionality between Linux and the DSP/IPU/PRU cores and not perform the reset/reload functions of the driver
      2. This is not one of our supported use cases so you will need to make these modifications yourself

    Jason Reeder

  • Pavel,

    The usecase that you are describing is referred to as "Early boot and Late Attach" feature which is currently supported in DRA7xx but isn`t currently supported on AM572x. You can refer to implementation of this feature on DRA72xx in the wiki article here:
    processors.wiki.ti.com/.../Early_Boot_and_Late_Attach_in_Linux

    Please note that using SBL from processor SDK RTOS along with u-boot has some risks. The SBL calls into the board library and initializes clocks and pinmux and DDR which is then overridden by the uboot so we don`t recommend SBL usage as you have described here.

    In systems with ARM Linux and RTOS On DSP/IPU we currently expect ARM Linux to boot up and then load the firmware on the IPU and DSP as described here:
    processors.wiki.ti.com/.../Linux_IPC_on_AM57xx

    Regards,
    Rahul

  • We have followed instructions of adding peripherals to IPC examples as described in processors.wiki.ti.com/.../Linux_IPC_on_AM57xx
    These examples are to be loaded from Linux.

    But we need the same for booting via multi-core application file from MLO.

    We have added bios/ex02_messageq example contents into our GPIO applications for DSP and IPU, but we could not connect them.
    (one of the applications fails on MessageQ_open)

    We also need to have IPC connection between Linux on A15 and TI RTOS on DSP/IPU which are loaded from MLO.

    Are there any specific issues whith IOMMU settings on IPU cores when booting from MLO.

    Or is there any guide of how to add peripherals to IPC TI RTOS examples and how to boot them (in particular, IPU) via MLO?
  • Hi, Pavel,

    Your last post is RTOS related. Could you open a new thread? I see you have another thread related to this thread for early boot/late attach. Can we close this one and move to that thread?

    Thanks!

    Rex
  • Ok. We can close this thread