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? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/21d23fec-ffdd-46b3-8197-c6639a724335%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
