PRU Development

GoogleGroups
1

I’m trying to learn to program the PRU’s on the BeagleBone Black to provide a stable and accurate clock pulse in the 10kHz to 800kHz range and I’m having a difficult time finding what is best to learn. I started with the Exploring BeagleBone book by Derek Molloy which is fantastic but with the examples there I always get a Segmentation Fault. So I tried looking for additional information but much of it seems to be 2-3 years old.

Is there a recommended, known, good starting point with step-by-step instructions to get the PRU’s up and running? Ultimately, I want to be able to send clock and other pulses out of the PRU and receive pulses coming back in. Directions to the best starting point would be greatly appreciated.

Thanks,

Mike Pitman

2

Hi Mike-

There are several possible paths. Since you mentioned Derek Molloy’s book, here is my project which was inspired by his chapter on the PRU:

If you look at this, you will see that I used the RemoteProc framework. This framework is relatively new and experimental. I have found that TI is supporting this quite well and for the most part it worked well in the limited project space I have worked in at this time.

There is also the UIO based framework which is more mature and has many successful projects developed with it.

With regards to getting up and running, you need to be aware of some set-up you will have to do whatever route you chose.
Here is another project I have published which includes documentation to guide you through the set-up of RemoteProc framework.
There are some details which I think would also be useful if you go the UIO route:

I am still working on the above project to re-implement the web interface using a Node based server. Or maybe Python. Not sure yet.

In general if you Google search on the PRU, you are going to find many paths which lead you down a dead end.
There is a huge amount of obsolete data information out there. Even a lot of the TI stuff which is outdated was still out there the last time I looked.
For example, there are a lot of projects based on the PASM compiler. This is the original compiler for the PRU. That old compiler is good and used
by many successful project, but it is no longer supported by TI. The new C compiler (which also compiles assembly) is supported, and though similar
to the instruction set of PASM, there are some differences. So that is another decision node.

So that’s what I know, good luck with your project!

Regards,
Greg

3

Hi Mike,

As Greg said, PRU development is severely hampered by incomplete, out-dated, and mutually-exclusive sets of instructions. Derek Molloy’s book may be based on an older Beaglebone Black, but at least it’s self-contained and consistent. I struggled for a long time to get the PRU working on a “modern” (4.4?) kernel. Eventually I gave up and installed the 3.8.13-bone80 kernel, which runs all Derek’s examples fine. That is the direction I suggest for you.

I never would’ve gotten my PRU setup working without Derek’s book – I’d still be recompiling kernels and randomly applying patches according to contradictory Internet documentation.

BTW, your seg faults may be caused by not loading the PRU device-tree overlay. Derek provides a device-tree overlay and instructions for compiling it on page 510. The actual .dts file is on GitHub here:

https://github.com/derekmolloy/exploringBB/tree/master/chp13/overlay

Good luck,
Justin

4

Once you get it working on the old stuff, come back and ask how to get it moved forward. It is pretty easy once you know your PRU code is working.

With the remote-proc driver, you can throw the built .elf files into /lib/firmware and trigger them to load by the kernel, without needing to have a library or line of your own C code.

You can still mmap() the shared memory to have your userspace app communicate with the PRUs.

There are some other good sets of documents out here, but I’ll agree that nothing is as complete as Derek Molloy’s book.

5

I had the PRU’s working with an 4.x kernel around 4-5 months ago. Basically I downloaded Jason’s PRU github files, and got two of the examples working. Back then, you could only use the older UIO PRU source examples with the bone kernel, as TI’s kernel was remoteproc only. Now days, supposedly it’s possible to to use either with TI kernels by properly commenting / uncommenting a given device tree overlay, and blacklisting the driver modules you’re not going to use. I say “supposedly” as I do not know from first hand experience, because I’ve been too busy building a system professionally( day job ).

Robert has laid out the general procedure, and the given overlay files are commented well, in order to achieve the end goal of using pruss_uio, or remoteproc. However, knowing which file needs modification, and the rest can be hard to figure out if you’re unaware of these changes. Additionally, the less you know about Linux in general. The harder time you’re going to have setting up either UIO, or remoteproc.

The only time I ever saw a seg fault happen with the PRU example code. Was when I tried running the example code as a regular user. e.g. you need to run the examples with elevated permissions. Which means you must be the user root, or use sudo as a regular user.

6

I had the PRU’s working with an 4.x kernel around 4-5 months ago. Basically I downloaded Jason’s PRU github files, and got two of the examples working. Back then, you could only use the older UIO PRU source examples with the bone kernel, as TI’s kernel was remoteproc only. Now days, supposedly it’s possible to to use either with TI kernels by properly commenting / uncommenting a given device tree overlay, and blacklisting the driver modules you’re not going to use. I say “supposedly” as I do not know from first hand experience, because I’ve been too busy building a system professionally( day job ).

To make things simpler, I’d like to see Robert adjust the default to have remote-proc turned on and require UIO users alone to need to edit uEnv.txt.

What would be great is if someone helped edit the examples in the am335x_pru_package to use remote-proc. Shouldn’t be hard if mmap() is still used to do the live communications and remote-proc is mostly just replacing the loader.

Robert has laid out the general procedure, and the given overlay files are commented well, in order to achieve the end goal of using pruss_uio, or remoteproc. However, knowing which file needs modification, and the rest can be hard to figure out if you’re unaware of these changes.

They are documented in /boot/uEnv.txt.

7

Jason,

Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify the the board overlay file. Or maybe it was one of the includes, I forget which.

8

Jason,

Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify the the board overlay file. Or maybe it was one of the includes, I forget which.

There is also a kernel module blacklist configuration file. I’m not sure why that one needs to be touched.

Again, I think we should just make remote-proc the default and be done with it. A good GSoC project would be to port am335x_pru_package to remote-proc. I’d still want to keep ‘pasm’ support as a requirement because it is fully open source, but ‘clpru’ support would be a nice bonus.

I’ll add the project idea to a http://bbb.io/gsocideas.

9

Jason,

Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
the the board overlay file. Or maybe it was one of the includes, I forget
which.

There is also a kernel module blacklist configuration file. I'm not sure why
that one needs to be touched.

then it's just a race between teh two modules to grab the pruss node..

Again, I think we should just make remote-proc the default and be done with
it. A good GSoC project would be to port am335x_pru_package to remote-proc.
I'd still want to keep 'pasm' support as a requirement because it is fully
open source, but 'clpru' support would be a nice bonus.

So back to the way we had it before..

v4.4.x-ti default to remoteproc
v4.4.x-bone default to uio_pruss

User can enable uio_pruss on v4.4.x-ti by them selves.

Regards,

10

Jason,

Is this a pure uEnv.txt edit only now ? Last I looked, you had to modify
the the board overlay file. Or maybe it was one of the includes, I forget
which.

There is also a kernel module blacklist configuration file. I’m not sure why
that one needs to be touched.

then it’s just a race between teh two modules to grab the pruss node…

Again, I think we should just make remote-proc the default and be done with
it. A good GSoC project would be to port am335x_pru_package to remote-proc.
I’d still want to keep ‘pasm’ support as a requirement because it is fully
open source, but ‘clpru’ support would be a nice bonus.

So back to the way we had it before…

v4.4.x-ti default to remoteproc
v4.4.x-bone default to uio_pruss

User can enable uio_pruss on v4.4.x-ti by them selves.

:smiley:

Let’s see who screams.

Probably the same people as disabling root ssh access. :wink:

11

So, here are my thoughts about all that. Not that what I say really means a whole lot. Other than it’s just another opinion.

In all honestly, I do not really care what goes on with the TI kernels. Ti’s views with what is enabled, and how it’s enabled does not really jibe with the way I personally prefer to do things. Which is fine by me, as long as the bone kernel is not effected. Which as time goes on, it does seem how TI prefers to roll out their kernel does effect the bone kernel some.

The reason Why I preferred the bone kernel in the past. Is that “we” did not have to deal with removing unnecessary driver modules. To get a “pristine” minimalist system up and running. Now days, they both seem to load the same exact driver modules stock, with perhaps the bone kernel being more flexible in removing say the SPI TI kernel module. All this really bothers me having all this bloat running on a stock console image. I think 99% of us who are serious with this platform wont ever run audio, or need most of the modules for the system we plan on building. What makes things worse, is that the traditional Debian mechanisms for blacklisting modules, or keeping them from loading at boot do not necessarily work - At all. To keep these kernel module from loading at boot, one has to use “fakeinstall”. Which is pretty much a hack, at least in my mind.

Until recently I did not even know the systemd service that loads the scripts in /opt/scripts/. It was only accidentally, when troubleshooting a system, that I happened to see a bootlog( serial debug ) complaining that this service could not load a certain script. Which I promptly wrote down so I’d never forget the service name.

My point with all of this rambling ? I’d like to see images in the future reduce all this module fluff at boot. At minimum, the console images. It’s ok to have the modules there, ready, and functional for those who need them. But forcing these kernel modules on everyone, by way of loading them in a non standard way, making it extremely difficult to figure out how to remove them . . . Well, it’s not helping anyone.

The only real reason why I’ve never mentioned this too much in the past is that I’m not the one who does all this work. SO I did not want to seem ungrateful. Which I know I can come on pretty forceful, and strong sometimes, but I do appreciate all the work that’s been put into this platform. That, and I know people get busy, just like I’m busy right now doing my own thing.

12

Yeah i need to document that too..

I had just finished all BBB/BBBW/BBG U-Boot cape universal overlays..

Just need to tweak things for the BBGW.

Then those will be ready for users to move from kernel overlay
config-pin to u-boot overlay config-pin..

Regards,

13

Side note, v4.4.x-xenomai-ti will remain uio_pruss, as that's a custom
build for machinekit

Regards,

14

That's actually kind of funny. Funny in that recently I noticed that when
rebooting one of the later 2016 image from ssh. The ssh connection was not
properly terminating. I forget the exact fix, but it involves installing
two packages, one of which is a PAM related package. So this corrected the
ssh connection termination issue, but default forces the system to disable
root ssh capabilities. But there should be a fix for that. I remember
having this issue with my rpi3 a while back, and you have to enable this is
a PAM config file *somewhere*. But on the beaglebone I do not worry too
much about it. I just ssh in as the user debian, then run sudo su . . .

15

By the way, leaving root enabled via port 22 with no passwd, is an extremely bad idea. So may while those people will whine to no end about that “problem”. Perhaps they should be made to understand the implications of leaving port 22 wide open to root access ?

16

The above is disabled by default as of 2-3 weeks ago…

Regards,

17

I'm still kind of on the fence. I can completely understand wanting to just
type ssh root@beaglebone and *bam* be right where I need to be to start
working on a problem. I get it. But at the same time, I sit behind 3 layers
of routers between any local system, and the internet. I also understand
the implications of having root wide open to the world. Free to anyone with
a port scanner to exploit. Assuming I had a hole punched in our routers for
outside access. Still,it's not impossible for someone to "hack" in to our
network, but it would not be very easier either.

For those who still may not understand. Allowing root access to port 22(
ssh ) with no password is akin to allowing remote assistance access into a
Windows system with no admin password. Which just so happens to be a big
"player" in the reason why Windows is often seen as the most insecure
operating system in the wild. Because by default, and from the factory.
Windows does not setup an admin password, and default to allowing remote
access to anyone with the username, and password. IF the username is known
"admin" and no password . . . At this point, the operating systems software
architecture is irreverent, and is begging any, or all script kiddie with a
port scanner to take over your system.

18

Back on topic.

I wonder if it wouldn’t be simpler, and easier for everyone if someone where to just write / create a setup script for both options. It’s been a while, so I do not recall the finer details with each process. But I can say while I do not know everything, I’m also not a novice Linux user by far. And I was never able to get remoteproc setup correctly and working. Also, having documentation of the finer details for remoteproc is a must. Things like what is a *.hex file, and which options are required, or optional. In addition to what all these options mean. e.g. definitions are required.

Setting up uio_pruss was also no cake walk, But in the end I was able to get two of the examples working.

I still think that remoteproc in concept a pretty cool feature.I’d like to see a lot of people using it, and showing off really cool examples of it’s usage. Despite me thinking that remoteproc is better suited for systems with multi core application processors. e.g. running Linux on one core, and having the other cores running bare metal. Or some mixture in between that. But in all honestly, when was the last time you saw something really cool done with the PRU’s ? ~2013, using uio_pruss, to create an all software( in PRU ) VGA adapter ? That’s the last really cool project I remember achieved through the PRU’s anyway . . .

19

I take that back. The last thing I saw I thought was cool was this: https://github.com/boxysean/beaglebone-DMX

But also done in 2013 it seems. Matt R also had a github project working with ws28xx serial type LEDs. But it’s probably very similar to boxysean’s DMX project. Just a different serial protocol.

20

Back on topic.

I wonder if it wouldn't be simpler, and easier for everyone if someone where to just write / create a setup script for both options. It's been a while, so I do not recall the finer details with each process. But I can say while I do not know everything, I'm also not a novice Linux user by far. And I was never able to get remoteproc setup correctly and working. Also, having documentation of the finer details for remoteproc is a must. Things like what is a *.hex file, and which options are required, or optional. In addition to what all these options mean. e.g. definitions are required.

+1