Trying to start PRUs quickly

General Discussion
1

I’m using the BBB to control our system and make use of the PRUs to do motor control. In attempt to minimize the boot up time, I have noticed that it takes a long time for the PRUs to come online. Since our program running in Linux depends on the PRUs being up, the whole system has to wait until they come online.
I was trying to follow another post I had found: Start pru at boot but when I copy our firmware over to /lib/firmware, rebuild the initramfs, and reboot, the start up time for the PRUs goes from 5ish seconds to around 40 and I have no idea why. I have noticed this slow behavior in both 4.4.X and 4.14.X kernels.
Here is version.sh output:

git:/opt/scripts/:[4ec0c8ed26872ace02789973ffce8477bbe1fbca]
eeprom:[A335BNLT00C02149SBB07823]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2017-03-19]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 2017.03-00002-gd12b1519b4 (Mar 14 2017 - 10:28:26)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2017.03-00002-gd12b1519b4]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
kernel:[4.4.54-ti-r93]
nodejs:[v4.8.0]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.1.20170309-0rcnee0~bpo80+20170309]
pkg:[bb-customizations]:[1.20151023-1~bpo80+20151023+1]
WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]
pkg:[bb-wl18xx-firmware]:[1.20170309-0rcnee1~bpo80+20170309]
pkg:[kmod]:[18-3]
pkg:[roboticscape]:[0.3.4-git20170307-0rcnee2~bpo80+20170307]:[GOT_REPLACED_BY_NEXT]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal netdev i2c bluetooth admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable]
dmesg | grep remote
[ 2.257642] remoteproc0: wkup_m3 is available
[ 2.257659] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 2.257667] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 2.351170] remoteproc0: powering up wkup_m3
[ 2.351253] remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[ 2.351513] remoteproc0: remote processor wkup_m3 is now up
[ 12.857592] remoteproc1: 4a334000.pru0 is available
[ 12.857618] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 12.857627] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 12.859018] remoteproc1: registered virtio0 (type 7)
[ 12.892959] remoteproc2: 4a338000.pru1 is available
[ 12.892985] remoteproc2: Note: remoteproc is still under development and considered experimental.
[ 12.892993] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn’t yet guaranteed.
[ 12.894383] remoteproc2: registered virtio1 (type 7)
[ 39.274622] remoteproc1: powering up 4a334000.pru0
[ 39.388713] remoteproc1: Booting fw image am335x-pru0-fw, size 137512
[ 39.434436] remoteproc1: remote processor 4a334000.pru0 is now up
[ 39.468931] remoteproc2: powering up 4a338000.pru1
[ 39.491081] remoteproc2: Booting fw image am335x-pru1-fw, size 125100
[ 39.529776] remoteproc2: remote processor 4a338000.pru1 is now up
dmesg | grep pru
[ 12.774841] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices
[ 12.776146] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[ 12.776796] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[ 12.857592] remoteproc1: 4a334000.pru0 is available
[ 12.890352] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru0@4a334000 probed successfully
[ 12.892959] remoteproc2: 4a338000.pru1 is available
[ 12.907041] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru1@4a338000 probed successfully
[ 39.274622] remoteproc1: powering up 4a334000.pru0
[ 39.388713] remoteproc1: Booting fw image am335x-pru0-fw, size 137512
[ 39.389006] ti-pruss 4a300000.pruss: configured system_events = 0x0000000000030000 intr_channels = 0x00000005 host_intr = 0x00000000
[ 39.434436] remoteproc1: remote processor 4a334000.pru0 is now up
[ 39.468931] remoteproc2: powering up 4a338000.pru1
[ 39.491081] remoteproc2: Booting fw image am335x-pru1-fw, size 125100
[ 39.491381] ti-pruss 4a300000.pruss: configured system_events = 0x0000000001fc0080 intr_channels = 0x0000000f host_intr = 0x0000000f
[ 39.491513] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e
[ 39.529776] remoteproc2: remote processor 4a338000.pru1 is now up
[ 39.546742] virtio_rpmsg_bus virtio1: creating channel rpmsg-pru addr 0x1f
[ 44.322306] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru30
[ 44.338432] rpmsg_pru rpmsg1: new rpmsg_pru device: /dev/rpmsg_pru31
dmesg | grep pinctrl-single
[ 2.078023] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

I do know with this “fresh” build that the kernel version and uboot versions are old. I have tried updating them and get the same results for the slow start up of the PRUs. Any help would be most appreciated! Thanks.

2

to really speed this up, your going to need to move that into a built-in kernel module and thus also include am335x-pru0-fw firmware into the kernel build process… We had left these as modules for ease of development… But i assume you’ve finished your pru firmware, now it’s just about startup speed…

Regards,

3

I appreciate the quick reply. Do you happen to have any links or posts to investigate to aid in the creation of the kernel level modules? Thanks again!

4

Well… that tag matches this commit:

only issue, the script on that date is in 2017, so teh build scripts would need to be updated…

Otherwise the full source can be found here, under this git tag:

Regards,

5

Any further thoughts as to why it appears remoteproc is delaying until the file system is loaded? The main reason I went back to the older kernel version was because the PRU’s were getting started early (and presumably didn’t have to wait on the FS). I understand why the TI developers changed the way it was loading but in our use case, having the PRU’s start earlier would definitely help.

6

In our default state, remoteproc firmware might be stored on the file system, so it’s waiting for /lib/firmware/

7

If I remove the PRU firmware files from the initramfs the dmesg output shows immediate failure in the early messages (the ones around 12secs). So it seems that is is checking there first but still delays to actually start and run them.

8

Yeap, stop them, re-echo them, then restart… Should work from the file system…

9

For anyone else who is trying to get their PRU’s to boot early on these earlier versions of the kernel, if you are able to run without using RPMsg references (I had to remove references in the resource table file of the PRU code), the pru_rproc kernel module will manually start the PRU. Around line 850 in pru_rproc.c is what helped me figure it out:

	 * rproc_add will boot the processor if the corresponding PRU
	 * has a virtio device published in its resource table. If not
	 * present, manually boot the PRU remoteproc, but only after
	 * the remoteproc core is done with loading the firmware image.
	 */
	if (!pru->use_eth) {
		wait_for_completion(&pru->rproc->firmware_loading_complete);
		if (list_empty(&pru->rproc->rvdevs)) {
			dev_info(dev, "booting the PRU core manually\n");
			ret = rproc_boot(pru->rproc);
			if (ret) {
				dev_err(dev, "rproc_boot failed\n");
				goto del_rproc;
			}
		}
	}

This is now what my dmesg output for the PRU’s looks like when I boot:

[    5.365508] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[    5.381234] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 !
[    5.468731]  remoteproc1: 4a338000.pru1 is available
[    5.489953] pru-rproc 4a338000.pru1: booting the PRU core manually
[    5.489985]  remoteproc1: powering up 4a338000.pru1
[    5.490537]  remoteproc1: Booting fw image am335x-pru1-fw, size 89044
[    5.490889] ti-pruss 4a300000.pruss: configured system_events = 0x0000000001fc0080 intr_channels = 0x0000000f host_intr = 0x0000000f
[    5.490902]  remoteproc1: remote processor 4a338000.pru1 is now up
[    5.490947] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss@4a300000/pru1@4a338000 probed successfully
[    5.525156]  remoteproc2: 4a334000.pru0 is available
[    5.538009] pru-rproc 4a334000.pru0: booting the PRU core manually
[    5.538045]  remoteproc2: powering up 4a334000.pru0
[    5.538650]  remoteproc2: Booting fw image am335x-pru0-fw, size 107732
[    5.538983] ti-pruss 4a300000.pruss: configured system_events = 0x0000000000030000 intr_channels = 0x00000005 host_intr = 0x00000000
[    5.538998]  remoteproc2: remote processor 4a334000.pru0 is now up
[    5.539048] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss@4a300000/pru0@4a334000 probed successfully

Thanks again for the help Robert!

1 Like