PRU devices taking a very long time to start up

[wi...@geomonkey.com]

I have PRU code working great on my BeagleBone Black industrial boards using the latest Debian 9.5 2018-10-07 4GB SD IoT flashed to eMMC, but even though the board boots up very quickly, I have to wait about two minutes after boot-up before the PRU cores can be used. Here's the last part of the dmesg output showing what I mean:

debian@beaglebone:~$ dmesg | tail -n 22

...

[   41.174241] Mass Storage Function, version: 2009/09/11

[   41.174265] LUN: removable file: (no medium)

[   41.986075] usb0: HOST MAC 44:ea:d8:aa:3e:b5

[   41.987686] usb0: MAC 44:ea:d8:aa:3e:b6

[   42.002600] usb1: HOST MAC 44:ea:d8:aa:3e:b8

[   42.006444] usb1: MAC 44:ea:d8:aa:3e:b9

[   42.254313] configfs-gadget gadget: high-speed config #1: c

[   43.850644] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready

[  118.823084] pruss 4a300000.pruss: creating PRU cores and other child platform devices

[  118.859328] remoteproc remoteproc1: 4a334000.pru is available

[  118.859458] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully

[  118.896237] remoteproc remoteproc2: 4a338000.pru is available

[  118.896367] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully

[  119.798466] remoteproc remoteproc1: powering up 4a334000.pru

[  119.807907] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 99712

[  119.808701] pruss 4a300000.pruss: configured system_events[63-0] = 0x00000000.00030000

[  119.808715] pruss 4a300000.pruss: configured intr_channels = 0x00000005 host_intr = 0x00000005

[  119.814687] remoteproc remoteproc1: registered virtio0 (type 7)

[  119.814707] remoteproc remoteproc1: remote processor 4a334000.pru is now up

[  124.697746] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e

[  124.699741] virtio_rpmsg_bus virtio0: rpmsg host is online

[  124.774718] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30

I didn't snip the output above; there is seriously nothing happening from 44 seconds to 119 seconds!

I have a bash script to start my PRU program, which is executed by a systemd service, but I have to make the shell script wait in a while loop for a long time before it is able to echo 'start' to the appropriate link location, otherwise I get an error and my PRU program doesn't start up at all. This works, but having to wait a couple minutes is ridiculous:

#! /bin/sh

TIMEOUT=1

while [ ! -f /sys/class/remoteproc/remoteproc1/state ]; do

    sleep "$TIMEOUT"

done

echo 'start' > /sys/class/remoteproc/remoteproc1/state

Running modprobe -f pru_rproc before the two minutes have passed doesn't seem to help.

Has anybody else experienced this? Any idea why it takes so long? Or how I would go about debugging this incredibly long delay? Thanks!

-- Will Bain

[din...@gmail.com]

What does "systemd-analyze blame" return?