Surefire PRU Example

GoogleGroups
21

I didn’t adjust anything in the device tree. I never had to do that before to successfully run the Remoteproc examples. The only thing I have ever had to tweak is the pull-up/down resistors in the pads.

When I run lsmod, I am seeing normal Remoteproc drivers after modprobe commands, except for the rpmsg driver which is not getting inserted when I think it should.

I would think there is at least some element of the device tree entries in /sys which are independent of loadable kernel modules?
I’m trying to understand the approach to debug this type of problem.
I think I need to verify solid device tree entries for the PRUs and go from there. ???

22

So a while back, in one of the board overlay, or regular overlays, maybe
one of the includes( I forget which ) Robert had comments, and commented
out code for enabling UIO, or remoteproc in the latest TI kernels. I'm not
sure if the newer version of these files have the remoteproc includes
commented out or not. So what I'm saying here may not apply.

Let me search the groups here and find what I'm thinking of.

23

OK - I tried to modify the BB-BONE-PRU overlay and change the pimux mode of the target pin of P9.27 and check for change

root@beaglebone:/lib/firmware# cat $PINS | grep 9a4
pin 105 (44e109a4.0) 00000027 pinctrl-single

No change - always stays at 0000027 -

Seems like it is ignoring the directive to set as per the DT overlay when I echo it in to the slots. The DT overlay loads in and is listed fine.

24

Look up in this thread to Robert’s post I believe both are disabled. You have to choose one and enable it.

25

Yeah, Gregs’ working kernel is from before this change. So only had remoteproc ability. Where these new kernels have the ability to enable either / or.

26

It’s also described here: https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20remoteproc|sort:date/beagleboard/LOaTgWH7Tpo/T0eote3TAQAJ in John’s first post. Which was from Roberts original “how to” post several months back it seems.

27

Does anyone know how to verify a pinmux config is truly in place?

I am trying to set 0x1A4 mode 5 0x05 . The dts compiles and loads but I have a feeling it is not taking.

Is there a static file somewhere that holds the pru pin configs in the current state?

Neil

28

Something like this, but replace grep pwm with grep pru:

root@beaglebone:/home/william# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins |grep pwm
pin 8 (44e10820.0): ocp:P8_19_pinmux (GPIO UNCLAIMED) function pinmux_P8_19_pwm_pin group pinmux_P8_19_pwm_pin
pin 9 (44e10824.0): ocp:P8_13_pinmux (GPIO UNCLAIMED) function pinmux_P8_13_pwm_pin group pinmux_P8_13_pwm_pin
pin 18 (44e10848.0): ocp:P9_14_pinmux (GPIO UNCLAIMED) function pinmux_P9_14_pwm_pin group pinmux_P9_14_pwm_pin
pin 19 (44e1084c.0): ocp:P9_16_pinmux (GPIO UNCLAIMED) function pinmux_P9_16_pwm_pin group pinmux_P9_16_pwm_pin
pin 84 (44e10950.0): ocp:P9_22_pinmux (GPIO UNCLAIMED) function pinmux_P9_22_pwm_pin group pinmux_P9_22_pwm_pin
pin 85 (44e10954.0): ocp:P9_21_pinmux (GPIO UNCLAIMED) function pinmux_P9_21_pwm_pin group pinmux_P9_21_pwm_pin

29

grep comes back empty, implies dtbo has no effect? Can someone please post a working PRU Pin P9.27 dts config with confirmation out put like below?

I am trying to build one that uses the compatible = “bone-pinmux-helper” target atm to see if that makes a difference. syntax errors…

Neil

30

So if my assumption that the left most bit of the first nibble is meant to be 0 for input. You’re device tree operation mode is incorrect. It’d be set in input mode with the current code I’m seeing. Mode 5 with output enabled. Should be 1101b or 0xDh. Then tacking on the 0x20h, you get 0x2Dh. LIke below:

pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <0x1a4 0x2D>; /* mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */
};

You really need to check the actual pin address, and the pinmux field though to make sure what I’m saying is valid. I honestly don’t know for a fact. I’m making the assumption that the left most bit of the first nibble is in fact to set IO direction, and that your pin address is also valid.

31

Additionally, I have no idea what 0x20h is meant to do. I’m assuming it’s either for pull up or pull down enable, but I have not checked the documentation. I would think you could do away with the pullup / pulldown, for an output. But I honestly do not know what you’re attempting to do. In which case a value of 0xD would be sufficient. For the mux mode( if you do not need a pull up or pull down) Assuming my assumption is correct . . .

32

YES, that is the rub!

Robert’s description of what to do had to be stared at a bit, but actually it is very easy and it worked first time.

I’ve got a BB Green, so I will re-iterate the particular steps required for Remoteproc:

  1. Clone Robert’s github repository:
    git clone https://github.com/RobertCNelson/dtb-rebuilder

  2. cd dtb-rebuilder/
    cd src/arm

  3. Now you will need to find and edit the top of the device tree dts file.
    For BBG, this is:
    am335x-bonegreen.dts

The only thing you have to do is to uncomment:
/* #include “am33xx-pruss-rproc.dtsi” */

unquote the line:
#include “am33xx-pruss-rproc.dtsi”

Save and exit.

  1. cd /etc/modprobe.d
    Create a new file named:
    pruss-blacklist.conf

Add this single line to the file:
blacklist uio_pruss

Save and exit.

  1. cd back to dtb-rebuilder

make
sudo make install
sudo reboot

After the above process, PRUs entries appear in /sys/bus/platform/devices, and the RPMsg example with character device in /dev is working!

I will add the above process steps to the chapter on PRU compiler set-up in my Remoteproc ADC github project.

Thanks!
Greg

33

So here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/include/dt-bindings/board/am335x-bbw-bbb-base.h#L88 your pin address seems to be correct.

Then here: http://beaglebone.cameon.net/home/pin-muxing says a couple of my assumptions were wrong. 0x25h seems correct.

34

Then here: http://beaglebone.cameon.net/home/pin-muxing says a couple of my assumptions were wrong. 0x25h seems correct.

Blah, I got it wrong again. Seems 0xD was correct. But anyway, you have the means to do what you need. Just make sure you read the second link correctly. I got it wrong at first look because instead of reading what each bit Fields is intended to mean, I made assumptions again . . . like disabled = 0 when actually according to that page disabled = 1 . . .

35

I am working on a generic 0x1A4 0x05 mode setting, just sitting down now for some more punishment.

two other good resources on this are http://www.ofitselfso.com/BeagleNotes/UsingDeviceTreesToConfigurePRUIOPins.php

and this video at this time https://youtu.be/wui_wU1AeQc?t=630 it talks about the config pin byte structure.

I read another post about a guy having a similar issue to me in that the pin was not responding on the dtb/o at https://groups.google.com/forum/?hl=en#!category-topic/beagleboard/pru/k6RACGRSwfc turns out he was blocked by the HDMI - on P8

Make me wonder if some how these P9 pins in Roberts base dtb are somehow allocated. I’ll have to dig in deeper.

Neil

36

OK Success. Got it working.

I blended two types of overlays I have seen on the web, this is what the final working version looked like. My notable changes were in fragment 1 - pru_pru_pins_pinmux { } addition and the compatible = “bone-pinmux-helper”; (whatever that is :slight_smile: seemed helpful)

I also in fragment 0 set a basic output pinmux to mode / settings of 0x05 (simple output).

Thank-you everyone for digging in!

/dts-v1/;
/plugin/;

/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”;

/* identification */
part-number = “BB-BONE-PRU”;
version = “00A0”;

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
“P9.27”, /* pru0: pr1_pru0_pru_r30_5 /
__/ the hardware IP uses */__
"pr1_pru0_pru_r30_5";

fragment@0 {
target = <&am33xx_pinmux>;
overlay {

pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
0x1A4 0x05 // CS P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
>;
};
};
};

fragment@1 {
target = <&ocp>;
overlay {
pru_pru_pins_pinmux {
compatible = “bone-pinmux-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&pru_pru_pins>;
};
};
};

};

Now I get the proper pin config - P9.27 = Pin 105

pin 100 (44e10990.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 101 (44e10994.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 102 (44e10998.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 103 (44e1099c.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 104 (44e109a0.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 105 (44e109a4.0): ocp:pru_pru_pins_pinmux (GPIO UNCLAIMED) function pinmux_pru_pru_pins group pinmux_pru_pru_pins
pin 106 (44e109a8.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 107 (44e109ac.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 108 (44e109b0.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 109 (44e109b4.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 110 (44e109b8.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 111 (44e109bc.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 112 (44e109c0.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)