AM335X PRU_RPROC cannot boot any firmware PRU state offline

[Wei Shi]

Hi, I'm trying to bring up the PRU on my BeagleBone Black. I was able to get it up using UIO method, but failed with PRU_RPROC driver.

The pru-software-support-package example compiled OK. I tried PRU_Direct_Connect0 and  PRU_RPMsg_Echo_Interrupt1. I copied generated .out file to /lib/firmware. BTW, there was conflicting instructions online about how to place the .out file. One mentioned copying to FILE /lib/firmware/am335x-pru0(1)-fw, and another mentioned copy to under DIRECTORY /lib/firmware/am335x-pru0(1)-fw/. I tried both, and both failed with the same symptom.

I have the following output in dmesg, and it looks as if PRU_RPROC have not even tried to load the .out file.

[   77.864792] pruss 4a300000.pruss: creating PRU cores and other child platform devices
[   77.934664] remoteproc remoteproc1: 4a334000.pru is available
[   77.934794] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   77.936497] remoteproc remoteproc2: 4a338000.pru is available
[   77.936603] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully

The state file under /sys/class/remoteproc/remoteproc2 is showing "offline"

my uEnv.txt file is below:

uname_r=4.14.69-ti-r76
enable_uboot_overlays=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
enable_uboot_cape_universal=1

And the configuration is:

git:/opt/scripts/:[d837f2b02f44fabe16353fd1226bb1f64e847c93]
eeprom:[A335BNLT00C02318BBBK19D2]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-08-30]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.09-00002-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.69-ti-r76]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20180914.0-0rcnee0~stretch+20180914]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.2-git20180829.0-0rcnee0~stretch+20180830]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[    1.120938] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[    1.132957] gpio-of-helper ocp:cape-universal: ready
END

Did I miss anything? Any help is really appreciated.

Wei

[Filippo Guerzoni]

Pleae have a look at

https://groups.google.com/d/topic/beagleboard/b8W1W3z_xYA/discussion

regards

[Wei Shi]

Thank you, Filippo! It was the exact same issue you mentioned in your post. I tried your solution and it worked like charm.

However, I have one more question. I actually tried to start the PRU using "sudo echo 'start' > /sys/class/remoteproc/remoteproc1/state" and it always failed with error "Permission denied", while in your case, you used sudo sh -c "echo ... Is there any significant difference between the two syntax?

[Dennis Lee Bieber]

On Mon, 24 Sep 2018 08:17:17 -0700 (PDT), Wei Shi
<weis...@gmail.com> declaimed the
following:

>However, I have one more question. I actually tried to start the PRU using "sudo
>echo 'start' > /sys/class/remoteproc/remoteproc1/state" and it always
>failed with error "Permission denied", while in your case, you used sudo sh
>-c "echo ... Is there any significant difference between the two syntax?

I believe the main difference is that the redirection is handled by
your user shell and only the command before it is passed to sudo.


--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Wei Shi]

This probably explained why my "sudo echo" got Permission denied.