On 31.05.2018 14:50, Roger Oberholtzer wrote: > On Thu, May 31, 2018 at 1:32 PM, Andreas Färber <afaer...@suse.de> wrote: > >>> I think Andre[a]s (in Cc) played with PRU already. >> >> I had prepared a cross-compiler toolchain, but it was not yet upstream >> at the time and I haven't updated the packages for some years - SRs welcome. >> >> https://build.opensuse.org/project/show/home:a_faerber:pru > > I see that. > >> Matwey and Alex will know more, but at the time there was only a uio >> driver. The remoteproc driver was still missing upstream, and I still >> don't see any with pru in the name: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/remoteproc > > I need to see how one should really use the PRU. I kind of assumed > that one generated code somewhere (using some tool chain - TI's?) that > one then loaded into the PRU. How you talk to or control it is > unclear. I want it to do some fast processing of a couple I/O lines, > and occasionally send out some information. Perhaps just even an > interrupt that a Linux all or driver could sense and act on. > > We tried having a Raspberry PI 3 monitor these lines (which trigger an > interrupt), but even in C in a dedicated kernel driver (no context > switching), it could not keep up. We are hoping that the PRU may do > better. No idea. >
Basically you have to compile your binary code using TI toolchain or GCC toolchain. And follow TI docs to interact with hardware. Then there is your user-space application which loads this binary to the hardware and exchange the data with your firmware. The application has to use appropriate host kernel interface to upload binary. The interface implementation for BBB is currently missing part in upstream linux kernel. > > > > -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
