Disclamer: I am not a guru, but I play one on the internet. 
...seriously, I'm kind of reading between the lines a bit, but I think
I'm beginning to see the Device Forest through all the Device Tree
Overlays. <groan>
I recently built the latest Angstrom image for the BeagleBone
Black (B^3) and when I looked for the PRU device source files
(*,dts) I found two:1 - BB-BONE-PRU-01-00A0.dts 2 - BB-BONE-PRU-02-00A0.dts
The device tree source file content is provided below. Does anyone
know the difference between these two files? specifically in the
" BB-BONE-PRU-02-00A0.dts" file a new subnode "pruproc" is
declared and in the "compatible" field content is "ti,pru-rproc" as
opposed to the more common "prussv2" which is overlayed with
BB-BONE-PRU-01-00A0.dts but can be found in the am33xx.dtsi file.
Remember the fragments you are looking at are OVERLAYS, and get
applied on top of the existing device tree. You really have to have a
flat model of the device tree in mind when looking at the overlays.
If you want a flat model of the collapsed device tree (without
manually crawling through all the *.dts and *.dtsi files in the kernel
source), you can easily "de-compile" any device-tree blob with the dtc
program:
dtc -I dtb -O dts <device-tree-blob>
...this works for both full trees (*.dtb) and overlay (*.dtbo) files.
Back to the task at hand...notice that target of fragment 2 in the
first (and shorter) dts file is <&pruss> (not prussv2), but the target
of fragment 2 in the second (longer) dts file is <&ocp>.
The reason is because the larger dts file is defining interrupts, and
in order to do this it has to overlay some hardware at a level higher
than just the pruss, here it targets <&ocp>, or the
On-Chip-Peripherials, which is where *ALL* the TI specific stuff gets
defined in the device tree.
Also what is the significance of the "interrupts = <20 21 22 23 24
25 26 27>;" entry in the am33xx.dtsi under the pruss node? It can
also be found in the BB-BONE-PRU-02-00A0.dts file as well.
This is to allow the PRU to send interrupts to the ARM core. Section
6.2 of the AM335x Technical Reference Manual shows that the ARM core
interrupts 20-27 are tied to the PRUSS sub-system, and that's what is
being conveyed by this bit of code in the device tree overlay.
Finally, remember that the Device Tree and any overlays just store
data, nothing more. To actually see what any of these data chunks
actually *MEAN*, you have to follow them back to the driver(s) that
make use of the device tree data. Grepping for the pru-rproc string
in the kernel source for instance, will point you to the
drivers/remoteproc/pru_rproc.c file, which has the code that actually
does the work.
Similarly (but a bit harder to track), <&pruss> leads you to line 355
in arch/arm/boot/dts/am33xx.dtsi, where we find:
pruss: pruss@4a300000 {
compatible = "ti,pruss-v2";
ti,hwmods = "pruss";
...which leads you to drivers/uio/uio_pruss.c, which states:
static const struct of_device_id pruss_dt_ids = {
{ .compatible = "ti,pruss-v1", .data = NULL, },
{ .compatible = "ti,pruss-v2", .data = NULL, },
...and now you can look at any of the other bits in the device tree
stanza for the section you're working with, and match them up to code
that's doing something based on the value.
So, now you know that not only are the two PRU examples provided doing
different things, they're actually using different kernel drivers, and
you can identify and crawl through that driver code to see if it's
doing what you want/need/expect.
...as a final note: the pru_rproc.c doesn't turn into it's own driver,
but is part of the remoteproc.o driver (the remote processor
framework). Just in case you're confused as to why you don't have a
pru_rproc.o driver in /lib/modules/.
- --
Charles Steinkuehler
charles@steinkuehler.net