• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 2101 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.

AM5728: remoteproc bind/unbind vs start/stop with sysfs

Gunter Schmer
Genius 14412 points

Part Number: AM5728

Hi,

one of our customers is using the AM5728 with Linux 4.19 (SDK v6)

at one of our customer we are trying to get a full restart of the DSP firmware working reliably. Ideally while the Linux side application is still running. So therefore on the Linux application side there needs to be additional cleanup and restart implemented.

There are two options for stopping and starting the DSP:

Option #1: remoteproc stop/start

root@am57xx-evm:/sys/class/remoteproc/remoteproc2# echo "start" > state

root@am57xx-evm:/sys/class/remoteproc/remoteproc2# echo "stop" > state

What actually happens on the DSP in this scenario? I don't think the firmware gets reloaded, does the DSP go through a full reset and restart of the DSP application? Could someone explain what is happening under the hood for stop/start?

We don't see this option to be robust enough.

Option #2: remoteproc unbind/bind

root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > unbind
[ 733.522146] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.000.dsp > unbind
[ 733.528046] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 733.546799] remoteproc remoteproc2: stopped remote processor 40800000.dsp
[ 733.556897] remoteproc remoteproc2: releasing 40800000.dsp

root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > bind
[ 757.001989] omap-rproc 40800000.dsp: ignoring dependency for device, assuming no driver
[ 757.010220] omap-rproc 40800000.dsp: ignoring dependency for device, assuming no driver
[ 757.020351] omap-rproc 40800000.dsp: assigned reserved memory node dsp1-memory@99000000
[ 757.031781] remoteproc remoteproc2: 40800000.dsp is available
[ 757.073099] remoteproc remoteproc2: powering up 40800000.dsp
[ 757.078800] remoteproc remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 20481364
[ 757.087996] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[ 757.093929] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[ 757.101045] alloc_contig_range: [99000, 99003) PFNs busy
[ 757.106941] alloc_contig_range: [99004, 99007) PFNs busy
[ 757.112607] alloc_contig_range: [99000, 99003) PFNs busy
[ 757.118174] alloc_contig_range: [99004, 99007) PFNs busy
[ 757.136680] virtio_rpmsg_bus virtio2: rpmsg host is online
[ 757.146358] remoteproc remoteproc2: registered virtio2 (type 7)
[ 757.160159] remoteproc remoteproc2: remote processor 40800000.dsp is now up
[ 757.172875] virtio_rpmsg_bus virtio2: creating channel rpmsg-proto addr 0x3d

This seems to be a much more complete restart, reloading DSP firmware, etc. 

Is this the preferred method for a reliable restart?

In Linux 5.4, somehow I don't see this unbind/bind sysfs anymore. Is there something replacing it?

Thanks!

--Gunter

  • 0
    TI__Guru** 113810 points

    Sorry about the delayed response on this thread.

    We are trying to determine next actions on this thread - we will get back to you very soon.

  • 0 in reply to Karthik Ramanan
    TI__Guru*** 125105 points

    Hi Gunter,

    Both options do actually shutdown the DSP remoteproc. You can confirm using the omapconf utility (omapconf dump prcm dsp)

    The difference is that the DSP remoteproc device stays registered with the remoteproc core with the sysfs start/stop method, while the bind/unbind unregisters and re-registers the device. The bind/unbind does invoke the driver's probe and remove functions (omap_rproc_probe(), omap_rproc_remove() from drivers/remoteproc/omap_remoteproc.c), so does perform the unwinding and reparsing of the DTS nodes and device-specific CMA pool registrations, and so takes additional time. The sysfs start also reloads the firmware again.

    The bind/unbind method is also present on 5.4 kernel (these interfaces do not show up only if the .suppress_bind_attrs property is set to true in the platform driver attributes (eg: PRU remoteproc uses this).

    regards

    Suman