PRU operation with Linux 4.1.1

I have a new Beaglebone Black booting the Debian 4GB SD image from 2015-03-01.
My Linux kernel is 4.1.1 built from “git://github.com/beagleboard/linux.git”.

I see that the kernel has a driver “uio_pruss” which from what I have read allows loading PRU code.

There is a LOT of web info on the PRU, but figuring out what is current and preferred is the puzzle.
There seems to be many approaches to using the PRU, i.e: ASM, C, Forth, Python, some robot
script language, etc…

Can anyone suggest the smooth/popular path?
A link to a doc that suggests which tools to grab and how to build and load PRU code that works with
this 4.1.1 kernel would be helpful.

My goal ATM is just to get a some simple PRU based LED blinker running.
Eventually I will need to acquire SPI data in the 10KHz range.

Regards,
Jalodi

Hi Jalodi,

Take a look at:
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-00B1.dts

Which is the only current 4.1.x/pru user..

make sure you boot with: dtb=am335x-boneblack-overlay.dtb

To get the pru pins..

btw, Elias has a good image here:

http://wiki.thing-printer.com/index.php?title=Kamikaze

Regards,

Thanks Robert.

Does this DTS set the I/O for use with the TI PRU Cape?
(www.ti.com.tool/prucape)

Also, is there a “Getting Started” guide that assumes use with Linux?
(The TI guide seems to ditch Linux and use StarterWare)

Regards,
Jalodi

That all assumes 3.8.x at the moment.. feel free to the first to port
it to 4.1.x :wink:

Regards,

Unfortunately I do not YET have enough experience with the Sitara, PRUs, Linux devie tree, etc. to jump into
making such a contribution. Have only been playing with the BBB for a week.

Can anyone point me to a kernel source that would be the best for a new-commer to play with the PRU?

Regards,
Jalodi

Can anyone point me to a kernel source that would be the best for a new-commer to play with the PRU?

DO you need to compile your own module(s)? If not then any of the latest 3.8.x kernels should work fine.

Here is a link to Robert’s build guide: https://eewiki.net/display/linuxonarm/BeagleBone+Black

But you’ll have to add the PRU stuff manually. Compilers, etc .

Yes, I do need to compile modules.

When you say “any latest 3.8” does that mean that I should grab it from kernel.org, or somewhere else?

BTW: One thing that I am not clear on is how to know if an “official” release from kernel.org has evolved
enough or when a specialized version is needed.

I currently have installed: arm-linux-gnueabi-gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1)

Adequate for compiling the kernel?

I saw a link on TI site for PRU assembler and C compiler which I assume I will also need.

Yes, I do need to compile modules.

When you say “any latest 3.8” does that mean that I should grab it from kernel.org, or somewhere else?

If you follow Robert’s guide, and use his script. The scripts will do all this for you through github. If you are familiar with the process, you should be able to read through his guide and see what is happening. Passed that, you’ll have to dive in an decipher his build scripts. Personally, I never felt the need. Also, his scripts pull in, and apply numerous patches that are required for the beaglebone kernel.

BTW: One thing that I am not clear on is how to know if an “official” release from kernel.org has evolved
enough or when a specialized version is needed.

I’m not sure I understand what you mean here. But, the “official” kernel is just the kernel sources, with various patches applied to make it run on the beaglebone black. It is also compiled with various modules in mind. Pretty much everything that the beaglebone has, or can use is “built in” module wise.

Off the top of my head: Specialized / customized kernel would only be needed if:

  • You need to minimize / reduce the size of the kernel because of size constraints.
  • You need to build in your own custom kernel modules.

There are other possibilities too I’m sure, but none that jump out at me right at this moment. Also, just for the record if you do not know already. Robert builds / maintains the official kernels, scripts, etc . . . if that is important to you.

I currently have installed: arm-linux-gnueabi-gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1)

Adequate for compiling the kernel?

No. If you look on the link I gave you to Robert’s guide, it will say which compiler is needed. That, and it is best that you follow his guide, until you’re comfortable enough to make changes on your own. In short though, you need the gnueabihf( hard float ) compiler.

I saw a link on TI site for PRU assembler and C compiler which I assume I will also need.

I’m not absolutely 100% sure, but I believe all this is available via Robert’s APT repo. SO you could just add his repository to your APT config file, and then apt-get update followed by apt-cache search to find the appropriate package name. You can also find, and experiment( after installing) with kernels in this manner as well.

Anyhow, if it is not in Robert’s repo yet ( which I’m fairly sure it is ) Jason Kridner has a github project for all the PRU “stuff”. assembler, C compiler, etc.

Also, just for the record if you do not know already. Robert builds / maintains the official kernels, scripts, etc . . . if that is important to you.

In the context of the beaglebone black.

So if you’re wondering otherwise when will the beaglebone black be mostly mainline Linux ? That I could not answer 100% for sure. But an effort is being made now with kernel 4.1.x Which, you can apt-get install a 4.1.x kernel for the beaglebone black right now. From Robert’s APT repo.

William, thanks for all the info. Good to know Robert is “The Man”. I will try working though the link to his stuff.

Re my comment about kernel.org - I am unfamiliar with the behind-the-scenes operation, but from what I observe
the source from kernel.org supports many arm processors and boards. At some point a new board comes along and
people start with the tree from kernel.org and make changes in their own separate tree to support the new board.
Later these changes are merged into a new version that is available from kernel.org, which I was calling “official”
for lack of a better term.

Anyway… setting aside my poor terminology… is is not clear to me when kernel.org becomes the best place to grab from.
It sounds like for the BBB it is not. i.e. Roberts stuff is best.

Regards.

mainline kernel.org runs fine..

It's just a lot of advanced things like the pru still need some work..

Regards,

Well the kernel sources do come from kernel.org. But many patches need to be applied for the board to function properly / completely.

So quite honestly I do not know who all is involved in making these patches, but I do know that Robert consolidates / tests these patches for the beaglebones. I do know that some community members contribute some patches, and have always assumed that Robert works on many. But, again, that’s an assumption on my own behalf.

Either way, the kernel sources do come from kernel.org.

Yeah, the PRU would be a great example in this context. No other processor manufacture has a PRU on their ARM die. Since this is “non standard” in the context of mainline Linux. “Something” additional must be done outside of mainline Linux.

Working through Robert’s guide I noticed this…

For Mainline v3.8.x: (full cape support)
For Mainline v4.1.x: (capemgr support)

Has something changed with regard to cape support?

Functionally it's not 100% compatible..

In 3.8.x you can remove or disable hdmi/eMMC in 4.1.x you have to use
the special *.dtb...

Regards,

4.1.x is a work in progress. 3.8.x has been around since the boards release( 2+ years ). Again, in the context of the beaglebone.

So how I view 4.1.x is that yes, it is newer, and in many cases it works fine. But not as much is working as is with 3.8.x.

This is not to say that 3.8.x is the best solution for everyones problem. As it does have issues of it’s own. Many / all of which may / may not be resolved with 4.1.x.

For instance 3.8.x has issues with USB hotplug. Not sure if these problems have since been resolved, but hotpluging USB with a 3.8.x used to cause a kernel fault. Also, 3.8.x has some issues with board powering, and / or suspending to RAM. And ethernet support can sometimes still be flaky.

Eventually I need to incorporate a TI PTP Ethernet Phy which is know to have had some problems that were
fixed in Linux 3.12.x Will also need stable USB support.

I noticed in Robert’s repository there are versions ranging from 3.1.x to 4.2.x

Would the 3.12.x version be as good as 3.8.x with regard to PRU support and better with regard to USB?

Nope...

3.8.x:
3.14.x-ti:
4.1.x/4.2.x:
(mainline):

Regards,

I am not positive but think that 3.12.x, 3.13.x, and 3.15.x are no longer being worked on. Not even sure 3.14.x is being worked on any longer, but it has been worked on recently. In the context of this community.

From what I can gather 4.1.x + is where the future is looking. As everyone is looking forward to getting as much as possible into mainline.

Also the answer I gave above, to the question you really did not ask( sorry about that - multitasking . . .). When I talk about kernel 4.x I tend to make it sound worse than it really is. But from what I can tell it is very solid. It does not have every peripheral working yet when compared to 3.8.x. But for what you seem to want to do, it may work fine. My only real reservation is that it is still a work in progress, and is not as mature as the rest. So, potential for something to go “wrong” that no one is currently aware of. So . . .

Would the 3.12.x version be as good as 3.8.x with regard to PRU support and better with regard to USB?

I would probably start at minimum with 3.14.x, but last I looked there were some complications when using the 3.14 - ti branch. Related to repo rebasing . . .

Then it sounds like I should aim for 4.1.x since that is where Robert and the community is going. I had no problem
getting 4.1.1 built and running, but the PRU is a black box for me.

So, regarding 4.1.1 - Is the PRU support known to be broken?

I would be happy to go through the process of trying a procedure that worked before (?) to see if it works now.

Is this the gold standard for PRU: https://github.com/beagleboard/am335x_pru_package

Also, here is my basic understanding of what is needed to use the PRU:
(Is this correct?)

  1. Kernel driver (uio_pruss) which allows loading code and starting the PRU.
  2. Some user app (X?) that can talk to uio_pruss.
  3. Some bin file that the PRU can execute.
  4. Some device tree file that sets up I/O for the PRU - Or can the PRU code
    optionally just do this for itself?

Regards,
J