Future proof development path for PRU on AM335x

[czin...@gmail.com]

I asked this question at TI's e2e forum, but was forwarded here due to usage of community support-only tools:

What is the most future-proof development path for PRU code on the AM335x? I'm currently using pasm on a Beaglebone Black with Debian 8. Until Kernel 3.8.x, using /dev/uio0 and Capemgr worked very smooth. Now I upgraded one BBB to Kernel 4.7.x and getting access to /dev/uio0 became unreliable (unloading kernel modules, changing dev tree, reloading, repeat). Am I following the wrong path? Shall I switch to the remoteproc system? What are you using?

Regards

Claudius

[TJF]

Hi Claudius!

remoteproc loads elf files only. You'll have to use a C compiler or transform the pasm binaries to elf format in order to load them.

And it's still experimental. It may work in entertainment applications, but for hard real time use cases in closed loop comtrollers t's much too slow and will never be an alternative for uio_pruss, unless the concept gets addapted massively (faster booting, less resources consumption, ...). So for me there's no chance to switch. Full sure I'll continue to use pasm and uio_pruss.

Now I upgraded one BBB to Kernel 4.7.x and getting access to /dev/uio0 became unreliable (unloading kernel modules, changing dev tree, reloading, repeat).

What kind of trouble did you get? Can you explain more details, please. I tested 4.1 and 4.4 versions without problems.

Regards.

[czin...@gmail.com]

On Thursday, September 29, 2016 at 4:45:42 PM UTC+2, TJF wrote:

And it's still experimental. It may work in entertainment applications, but for hard real time use cases in closed loop comtrollers t's much too slow and will never be an alternative for uio_pruss, unless the concept gets addapted massively (faster booting, less resources consumption, ...). So for me there's no chance to switch. Full sure I'll continue to use pasm and uio_pruss.

Ok, sounds good to me. I'll stick to uio_pruss. Actually I like the mmap-concept of interfacing. There are hard realtime constraints in entertainment, too ;)

 

Now I upgraded one BBB to Kernel 4.7.x and getting access to /dev/uio0 became unreliable (unloading kernel modules, changing dev tree, reloading, repeat).

What kind of trouble did you get? Can you explain more details, please. I tested 4.1 and 4.4 versions without problems. 

Kernel: 4.7.3 (AFAIK, no access to the updated system now.)
/dev/uio* nodes don't appear, so my code prussdrv_open fails. It just worked with 3.8.x. Capemgr seems to have changed, too (different path in /sys). Maybe my initialization is non-optimal:
[there's a dtbo describing some IOs and PRU at /lib/firmware/MY-PRU-00A0.dtbo]
echo "MY-PRU" >> /sys/devices/pl;atform/bone_capemgr/slots
modprobe uio_pruss
chmod 6600 /dev/uio*
chown :wheel /dev/uio*
[run some sample code on the PRU]

Shall I load the dtb in /boot/uEnv.txt?

[Robert Nelson]

Did you rebuild this "MY-PRU" with the newer compiler and the pru
changes needed? a 3.8.x overlay *.dtbo is not 100% compatible with
v4.1.x+ kernels.

Regards,


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

[czin...@gmail.com]

On Thursday, September 29, 2016 at 5:35:26 PM UTC+2, RobertCNelson wrote:

Did you rebuild this "MY-PRU" with the newer compiler and the pru
changes needed? a 3.8.x overlay *.dtbo is not 100% compatible with
v4.1.x+ kernels.

Yes. I used the compiler "Version: DTC 1.4.1-g1e75ebc9"
With "4.4.22-bone13", I can load my DTBO, uio_pruss, but don't get /dev/uio0
pinmux also seems not to work. Same with my DTBO as with the reference:
# echo uio_pruss_enable > /sys/devices/platform/bone_capemgr/slots
--> Nothing.
What steps are you using on a new image (Debian 8.6 console on BBB)?

Claudius