@John3909: Am Montag, 27. Juni 2016 11:19:13 UTC+2 schrieb john3909: > > While I haven’t tried this, I don’t believe there is anything in the > RemoteProc/RPMSG framework that prevents you from doing this now. You can > still use RemoteProc to load/start/stop your PRU firmware and you don’t > have to use virtio or rpmsg, but rather create a new KM to do just this. > Suman does this make sense? > So, thinking a little more about this, this new KM would support mmap() so > that your userspace app/lib could access this memory directly. Linux is out > of the way and yet everything is still secure ;-) >
Good John, you're closing up to this discussion. You're at this point now (three days ago): [Suman: Right, the basic infrastructure is already there and you would need >> only to build upon it. For eg., at the moment, all you would need is a >> small kernel module, use pruss_request_mem_region to gain ownership of PRU >> memories, export it to userspace and use it however you want. The >> interrupts would have to go through kernel though. Maybe it is the same >> module that exports the above desired sysfs interfaces too.] >> > > Am I reading right here? My message is: > > - Reduce resource consumption on a small SoC. > > And your advice is: > > - Add a further module to a bloated framework. > > Go ahead! Once you're on track, it wouldn't need any "childish antics" any more. I can hardly wait reading your opinion on the PRU virus issues. BR -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a0fcf7b0-3682-4c4f-90de-a00fcfbdf0c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
