loading firmware fails with error -22

[jjkunn...@gmail.com]

Going through the first PRU example in Exploring Beaglebone (2nd ed). When I try to start the pru I get this:

debian@beaglebone:/sys/class/remoteproc/remoteproc1$ echo start > state
-bash: echo: write error: Invalid argument

I get this from dmesg:

[  100.249395] remoteproc remoteproc1: powering up 4a334000.pru
[  100.249525] remoteproc remoteproc1: loading /lib/firmware/am335x-pru0-fw failed with error -22
[  100.249537] remoteproc remoteproc1: Direct firmware load for am335x-pru0-fw failed with error -22

I finally found out a workaround after an embarrassing amount of time: replace the am335x-pru*-fw files in /lib/firmware with the the ones in /opt/scripts/device/bone/pru-rpmsg_client_sample/. I actually found them on Robert Nelson's github page and only found out later that they were on the BBB the whole time.

I've tried a few of the latest images (as of March 2020) from rcn-ee.com and have still been unsuccessful in working with the PRU. In those cases, I don't even see any mention of the PRUs in dmesg.

Is this a bug, or is there an SOP I haven't found yet?

[Robert Nelson]

Please run & report:

sudo /opt/scripts/tools/version.sh

you might be fighting a mis-configuration due to u-boot.. ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[jjkunn...@gmail.com]

git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]
eeprom:[A335BNLT00C02516BBBK1ED1]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2019-08-03]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
kernel:[4.14.108-ti-r113]
nodejs:[v6.17.0]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=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.14.20200312.0-0rcnee0~stretch+20200312]
pkg:[bb-wl18xx-firmware]:[1.20200226.1-0rcnee0~stretch+20200226]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~stretch+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc admin spi tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[    1.305558] remoteproc remoteproc0: wkup_m3 is available
[    1.387041] remoteproc remoteproc0: powering up wkup_m3
[    1.387157] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[    1.391579] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   24.891910] remoteproc remoteproc1: 4a334000.pru is available
[   24.895704] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   24.852363] pruss 4a300000.pruss: creating PRU cores and other child platform devices
[   24.891910] remoteproc remoteproc1: 4a334000.pru is available
[   24.892039] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   24.895704] remoteproc remoteproc2: 4a338000.pru is available
[   24.892039] pru-rproc 4a334000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
[   24.895704] remoteproc remoteproc2: 4a338000.pru is available
[   24.895822] pru-rproc 4a338000.pru: PRU rproc node /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
dmesg | grep pinctrl-single
[    0.951949] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
dmesg | grep gpio-of-helper
[    0.964308] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

[Robert Nelson]

On Thu, Mar 19, 2020 at 7:12 AM <jjkunn...@gmail.com> wrote:
>
> git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]
> eeprom:[A335BNLT00C02516BBBK1ED1]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2019-08-03]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
> kernel:[4.14.108-ti-r113]

> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]

Okay you are fine..

(my version of that book was at work)

Look closer at Derek's examples, he's doing it as root, as debian you
can't just "echo > something" without proper permissions...

His examples also relied on v4.9.x-ti (so hopefully TI didn't break
something with regards the v4.14.x-ti we ship..)

[jjkunn...@gmail.com]

I swear I tried all of this, but in lieu of good notes (which I rarely take unfortunately), I decided to redo everything from scratch today to make sure I didn't hallucinate through all the different iterations I tried.

Ok, so first I downloaded the IoT image at https://debian.beagleboard.org/images/bone-debian-9.9-iot-armhf-2019-08-03-4gb.img.xz and flashed it onto a card.

Looking at Exploring BB, Derek's using kernel 4.14.67-ti-rt-r73. Mine shows as 4.14.108-ti-r113. I disabled video in uEnv.txt and rebooted. After re-checking that PRU related messages showed up in dmesg, Here's a transcript of me trying to turn PRU0 on, both as root and debian

root@beaglebone:~# cd /sys/class/remoteproc/remoteproc1
root@beaglebone:/sys/class/remoteproc/remoteproc1# ls
device    firmware  power  state    subsystem  uevent
root@beaglebone:/sys/class/remoteproc/remoteproc1# cat state
offline
root@beaglebone:/sys/class/remoteproc/remoteproc1# echo 'stop' > state

-bash: echo: write error: Invalid

argument
root@beaglebone:/sys/class/remoteproc/remoteproc1# echo 'start' > state

-bash: echo: write error: Invalid

argument
root@beaglebone:/sys/class/remoteproc/remoteproc1# exit
logout
debian@beaglebone:~$ cd /sys/class/remoteproc/remoteproc1
debian@beaglebone:/sys/class/remoteproc/remoteproc1$ echo 'stop' > state

-bash: echo: write error: Invalid argument
debian@beaglebone:/sys/class/remoteproc/remoteproc1$ echo 'start' > state
-bash: echo: write error: Invalid argument

I got the same firmware load failure messages in dmesg that I first reported. After copying over the firmware in /opt/scripts:

debian@beaglebone:/opt/scripts/device/bone/pru-rpmsg_client_sample$ sudo cp * /lib/firmware
debian@beaglebone:/opt/scripts/device/bone/pru-rpmsg_client_sample$ cd /sys/class/remoteproc/remoteproc1
debian@beaglebone:/sys/class/remoteproc/remoteproc1$ echo start > state
debian@beaglebone:/sys/class/remoteproc/remoteproc1$ cat state
running

I'm going to try to load up a recent image from your site and see if I get the same thing. I'll report back. This epidemic's given me a chance for a lot of play time while I'm on the clock :)

[jjkunn...@gmail.com]

Tried it with bone-debian-10.3-iot-armhf-2020-03-16-4gb.img. Same thing: copying over firmware fixed it.

[Robert Nelson]

On Thu, Mar 19, 2020 at 11:01 AM <jjkunn...@gmail.com> wrote:
>
> Tried it with bone-debian-10.3-iot-armhf-2020-03-16-4gb.img. Same thing: copying over firmware fixed it.

Now that i think about it. The udev rule, to set the permissions is
only triggered when the firmware exists.

Not sure how we actually fix your issue, beside shipping a default
firmware.. We could do a blank, "nop" firmware, by default??? (or
would this kill power?) Then the remoteproc presmissions would be
properly set.

[Jason Kridner]

What would you think about a default firmware that provided some response to pokes to /dev/rpmsg_pru30 and /dev/rpmsg_pru31?

I started some hacks to try to make a "pruspeak" instance on the PRUs as examples, but haven't finished: https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/.work-in-progress/pruspeak.pru0.c

What if we just made some simple echo servers that would allow you to see the PRU is alive? Maybe we could look at the power impact, but I'd expect it to be very minor.

I'm happy if there are other default candidates, like libpruio, but we need to be careful they don't interfere with the Linux peripheral accesses.

For my PRU workshops on PocketBeagle TechLab, I've been using https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/TechLab/sleep.pru0.c to stop the PRU so that it isn't doing anything. 

Install is 'make -f /var/lib/cloud9/common/Makefile TARGET=sleep.pru0' from within that directory.

Doh! It highlights an unmet dependency I made in the latest Makefile on /usr/share/ti/starterware/pru/libdrivers.a.  That library isn't that useful, so I need to remove it.

[Jason Kridner]

Double-ugh. PocketBeagle/TechLab/.challenges/analogIn.pru0.c depends on the staterware header files. I'll need to either use different header files or add Starterware. :-( 

[jjkunn...@gmail.com]

Just something that would keep a newbie from getting wrapped around an axle trying to get it to work(like I did, lol). Echo server seems like a good idea.

On Thursday, March 19, 2020 at 2:46:41 PM UTC-4, Jason Kridner wrote: