Ok, thank you.
Then i probably will just also use the
uio_pruss driver, maybe I get remoteproc working but if not it should also be fine.
giuliomoro so remoteproc0 seems to be the Cortex M3 core that is used for power management.
This makes sense and explains why
cat /sys/class/remoteproc/remoteproc0/firmware returns
I think using Code Composer Studio (eclipse) and writing in C is somewhat nicer as pure assembly + you can always embed assembly. But anyhow the result should be similar enough for my use case.
giuliomoro I think you may have to load one of the relevant PRU device overlays. Not sure where they would be on a regular beagleboard image (the online repo is here). On a Bela image they are in /opt/bb.org-overlays/
I already looked into the overlays, at first glance it seams I got them successfully loaded, but I have seen no change.
Maybe have done something wrong. I will try again.
There are also some kernel configuration differences between the kernel from the bela image and the beagle bone Debian image for example
CONFIG_PRU_REMOTEPROC=m but applying then to the RobertCNelson/ti-linux-kernel-dev xenomai kernel did not solve it for some reason (loading the modules does not create /sys/class/remoteproc/remoteproc 1 and to).
But I have not looked into the kernel sources, maybe these options doesn’t work at the moment.
uio_pruss driver seams to be the easiest solution to get going.