What does "systemd-analyze blame" return? On Tuesday, November 27, 2018 at 7:28:29 PM UTC+2, wi...@geomonkey.com wrote: > > > 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 >
-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f90cf563-54e8-4d97-bd77-999b8bd46a4d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
