Surefire PRU Example

[Neil Jubinville]

Hi All, 

I have BBB rev c recently flashed to Debian 8 - kernel 4.4.   I have been struggling to get code into the PRUs since many of the demos on the web are fragmented in methods and dependencies which make it difficult to have a winning combination.  My goal is to have a configuration script that can setup all the requirements for the PRU to work.  

I also noticed that many users appear to be using uio_pruss for their loader and not remote_proc.  That said what img is the last known working image with uio_pruss ?

In the latest site listed image, uio_pruss module seems not to be included,  is there a separate package we need to install for this support? 

I am able to compile using gcc-pru and build elf files form the various demos.  In general I am trying to do this basic one https://github.com/Neil-Jubinville/pru-gcc-examples/tree/master/blinking-led   and use my init script here: https://github.com/Neil-Jubinville/pru/blob/master/prep_pru.sh

Using the uio_pruss method: 

- I get uio_pruss not found for the module.   Therefore subsequent commands yield:

root@beaglebone:~/pru-gcc-examples/blinking-led/host-uio# ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf

Initializing the PRUs...

pload: prussdrv_open open failed   ( how to get uio_pruss ? Do I have to compile this module? )

Using the remote_proc method:

The below commands fail with the module not found.   

sudo rmmod pruss_remoteproc
sudo modprobe pruss_remoteproc

So I am not having success with either method, each having missing dependencies.   The startup log below indicates also some availability and failing of default PRU loading from the /lib/firmware copies of the remote proc method.

Any ideas? Is there a surfire version / image that will 100% resulting gcc-pru compiled example loading into PRU.  I will certainly document it once I discover it.

BeagleBoard.org Debian Image 2016-05-13

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

root@beaglebone:~# uname -a

Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux

root@beaglebone:~# lsmod

Module                  Size  Used by

c_can_platform          6602  0

c_can                   9577  1 c_can_platform

can_dev                11663  1 c_can

spidev                  7523  0

pwm_tiecap              3652  0

pwm_tiehrpwm            4706  0

tieqep                  8758  0

pruss_intc              3571  0

snd_soc_hdmi_codec      5842  1

snd_soc_simple_card     8449  0

8021q                  17930  0

garp                    5769  1 8021q

mrp                     7239  1 8021q

stp                     2219  1 garp

llc                     5123  2 stp,garp

pru_rproc              11359  0

omap_aes_driver        19045  0

omap_sham              21340  0

pruss                  11679  1 pru_rproc

omap_rng                4423  0

snd_soc_davinci_mcasp    16653  2

snd_soc_edma            1290  1 snd_soc_davinci_mcasp

snd_soc_omap            3058  1 snd_soc_davinci_mcasp

rng_core                7703  1 omap_rng

tilcdc                 26338  0

usb_f_acm               7209  1

snd_soc_core          155549  5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap,snd_soc_simple_card

u_serial               11366  3 usb_f_acm

snd_pcm_dmaengine       5209  2 snd_soc_core,snd_soc_omap

usb_f_rndis            22191  1

g_multi                 5524  0

usb_f_mass_storage     42370  2 g_multi

u_ether                11898  2 usb_f_rndis,g_multi

libcomposite           43717  4 usb_f_acm,usb_f_rndis,g_multi,usb_f_mass_storage

snd_pcm                83341  5 snd_soc_hdmi_codec,snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine

snd_timer              19788  1 snd_pcm

spi_omap2_mcspi        11148  0

snd                    59495  3 snd_soc_core,snd_timer,snd_pcm

soundcore               7637  1 snd

evdev                  10695  2

tda998x                12523  0

uio_pdrv_genirq         3539  0

uio                     8822  1 uio_pdrv_genirq

root@beaglebone:~# modprobe uio_pruss

modprobe: FATAL: Module uio_pruss not found.

root@beaglebone:~#

[din...@gmail.com]

Hi Neil,

I think that for UIO you'll need to switch your kernel. See https://groups.google.com/d/msg/beagleboard/6vKLJpJoPGY/kc-iW_fbAgAJ .

For remoteproc, here are some points to check:

1. For loading PRU GCC ELF firmware you will need a kernel with this patch applied: 0001-Fix-remoteproc-to-work-with-the-PRU-GNU-Binutils-por.patch. Looks like your kernel 4.4.9-ti-rt-r25 is missing it. The Jessie testing images come with 4.4.27-ti-rt-r62 , which has this patch integrated. 
   
2. If you are using RPMSG communication, then please be aware that there are two remoteproc drivers circulating around :( The older one uses mailboxes for RPC (corresponding pru-gcc-examples branch "master"). If your kernel is newer, it probably runs the remoteproc driver that instead uses interrupts for RPC. You'll want to use the dev-for-v5-rpmsg branch of pru-gcc-example, which is based on the updated "5.0.0" pru-software-support-package from TI.

Regards,

Dimitar

[Brett Hamilton]

http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg is the best summary I've found for the remoteproc method and it definitely answered some questions that I didn't see anywhere else I looked. Definitely works on 4.4.23-ti-r52.

[Neil Jubinville]

I am trying to avoid buying that TI cape :)  

OK update:   Indeed running the  updatekernel.sh brought me to 4.4.27   This gave me the ability to run modprobe uio_pruss 

When I go to run the loader I am still getting the prussdrv_open failed message.   This tells me that normally the PRUs may not be enabled and to look for the HDMI pin conflict?  Chatting in the #beagle irc states that the default open pin is not in conflict to open the PRU after the init so I am not sure what is going on.   Maybe this has to do with the base cap-universal tree loaded at the start.

I have removed all DT from the slots till it was empty then loaded a variety of BB-BONE-PRU * and to no avail would it open/load.   So it is something more obscure.   I suspect the default DT.

I'll look into the remoteproc method after hacking DTs for a bit.

Thx for the notes. 

Neil

[Robert Nelson]

On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville <ne...@orbitalsoftware.ca> wrote:
> I am trying to avoid buying that TI cape :)
>
> OK update: Indeed running the updatekernel.sh brought me to 4.4.27 This
> gave me the ability to run modprobe uio_pruss
>
> When I go to run the loader I am still getting the prussdrv_open failed
> message. This tells me that normally the PRUs may not be enabled and to
> look for the HDMI pin conflict? Chatting in the #beagle irc states that the
> default open pin is not in conflict to open the PRU after the init so I am
> not sure what is going on. Maybe this has to do with the base
> cap-universal tree loaded at the start.
>
> I have removed all DT from the slots till it was empty then loaded a variety
> of BB-BONE-PRU * and to no avail would it open/load. So it is something
> more obscure. I suspect the default DT.

On the TI branch, we don't ship a default PRU driver, it's up to you
to configure it..

git clone https://github.com/RobertCNelson/dtb-rebuilder
cd ./dtb-rebuilder/

You have the "black", so edit one of the following:

#default: emmc + hdmi enabled:
nano src/arm/am335x-boneblack.dts

#: all overlays (emmc/hdmi disabled)
nano src/arm/am335x-boneblack-overlay.dts

#emmc enabled: hdmi disabled
src/arm/am335x-boneblack-emmc-overlay.dts

then look:

uio_pruss (3.8.x compabitl)

/*
* /etc/modprobe.d/pruss-blacklist.conf
*
* blacklist uio_pruss
*/
/* #include "am33xx-pruss-rproc.dtsi" */

Or remoteproc:

/*
* /etc/modprobe.d/pruss-blacklist.conf
*
* blacklist pruss
* blacklist pruss_intc
* blacklist pru-rproc
*/
/* #include "am33xx-pruss-uio.dtsi" */

So "pick on" copy the "blacklist.conf" settings and un-comment out the
"#include"..

Then just:

make
sudo make install
sudo reboot

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

Opps reversed them:

uio_pruss (3.8.x compatible)

/*
* /etc/modprobe.d/pruss-blacklist.conf
*
* blacklist pruss
* blacklist pruss_intc
* blacklist pru-rproc
*/
/* #include "am33xx-pruss-uio.dtsi" */

remoteproc (v4.4.x-ti)

/*
* /etc/modprobe.d/pruss-blacklist.conf
*
* blacklist uio_pruss
*/
/* #include "am33xx-pruss-rproc.dtsi" */

[Jason Reeder]

If you do come back around to RemoteProc and RPMsg and want to run some of the cape examples... the schematic for the PRU Cape is posted here: http://www.ti.com/lit/df/tidr938/tidr938.pdf

You could breadboard some of the circuits (LEDs, switches, etc) without having to spend the full $39.

[Mark A. Yoder]

Brett:

  Thanks for the feedback on the eLinux page.  I have more examples to develop when time permits.

--Mark

[Neil Jubinville]

OK This worked for the loading:

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf

Initializing the PRUs...

AM33XX

The code is 0Starting ...

Stopping PRU... done.

The I/O does not seem to toggle just yet,  I am loading the simple  BB-BONE-PRU that has one pin for output enabled -> P9.27 

Getting close though.   

When the message says stopping PRU in the pruss driver is it stopping the cpu/core execution ?   or is that indicating the end of the load?

Neil

[din...@gmail.com]

It means the Pru core is being stopped and reset. You may want to open pload.c and adjust the amount of time PRU is allowed to execute. By default it is 30 seconds.

Regards,
Dimitar

[Neil Jubinville]

Thx Dimitar, 

Ok so still no voltage toggle / led lighting on that  P9_27.    Any idea why the PRU will load but I am not seeing any I/O work?   

 I am using this overlay  :

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat /lib/firmware/BB-BONE-PRU-00A0.dts

/*

* Copyright (C) 2013 Matt Ranostay 

*

* This program is free software; you can redistribute it and/or modify

* it under the terms of the GNU General Public License version 2 as

* published by the Free Software Foundation.

*/

/dts-v1/;

/plugin/;

/ {

compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */

part-number = "BB-BONE-PRU-01";

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 */

"pru0";

fragment@0 {

target = <&am33xx_pinmux>;

__overlay__ {

pru_gpio_pins: pinmux_pru_gpio_pins {

pinctrl-single,pins = <

0x1a4 0x0f /* P9 27 GPIO3_19: mcasp0_fsr.gpio3[19] | MODE7 | OUTPUT */

>;

};

pru_pru_pins: pinmux_pru_pru_pins {

pinctrl-single,pins = <

0x1a4 0x25 /* mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */

>;

};

};

};

fragment@2 {

target = <&pruss>;

__overlay__ {

status = "okay";

pinctrl-names = "default";

pinctrl-0 = <&pru_pru_pins>;

};

};

};

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat $slots

^C

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1

 1: PF----  -1

 2: PF----  -1

 3: PF----  -1

 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-BONE-PRU 

[din...@gmail.com]

Could you double check that your pin mux is correct? On my kernel I can do it with this command:

   $ cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4

Which kernel are you using?

You may also try the "md5-check" example. If md5-check passes, then the PRU firmware is loaded and executed just fine. In such case you'll know that your "blinking-led" has an issue with the pin mux or LED wiring.

Regards,

Dimitar

[Neil Jubinville]

Looks like a pinmux issue - I know the LED wiring is good - tested that.   

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/pru# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4

pin 105 (44e109a4.0) 00000027 pinctrl-single

root@beaglebone:~/pru/pru-gcc-examples/md5-check/host-uio# ./out/pload ../pru/out/pru-core0.elf ../pru/out/pru-core1.elf

Initializing the PRUs...

AM33XX

Starting ...

Stopping PRU... _md5res: 0000100c

MD5 sum has been successfully calculated by PRU1.

done.

[Neil Jubinville]

I am using 4.4.27-ti-r62.

[Neil Jubinville]

Does this look right?

fragment@0 {

                target = <&am33xx_pinmux>;

                __overlay__ {

                        pru_gpio_pins: pinmux_pru_gpio_pins {

                                pinctrl-single,pins = <

                                        0x1a4 0x0f      /* P9 27 GPIO3_19: mcasp0_fsr.gpio3[19] | MODE7 | OUTPUT */

                                >;

                        };

                        pru_pru_pins: pinmux_pru_pru_pins {

                                pinctrl-single,pins = <

                                        0x1a4 0x25      /* mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */

                                >;

                        };

                };

        };

0x1a4 is  same memory address,  are they supposed to be defined twice there?  

[William Hermans]

I'm not sure what the first one i trying to do other than put the pin in GPIO mux mode.

The second seems to be the correct one. I'd have to look up what 0x20 is ( probably pull up or down ) but mux mode 5, and 6 is generally PRU mux mode. DO also keep in mind mode 5, and 6, one mode is input, whiel the other mode is output. I forget which is which. There is plenty of info on the web about this.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/39726e53-a6da-4ae4-b86e-980d53c75b5d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Ah, I think I see. Perhaps the left most bit is to indicate input( 0 ) or output( 1 ).

[Neil Jubinville]

5 is for output I recall...

To add 

root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat $PINS | grep 9a4

pin 105 (44e109a4.0) 00000027 pinctrl-single

Still no toggle.   Tonight I'll try to get the pin mode to change and see it in the pin debug.   

Neil

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Greg]

I'm also using 4.4.27-ti-r62.  In particular, the IOT distribution.

I'm seeing strange behavior attempting to run Remoteproc.  It's like the PRUs are missing from the device tree.  I think.

I'm comparing a working board built with 4.4.12-ti-r31 from a few months ago.  This one works perfectly.

So I am comparing the contents of this directory:

/sys/bus/platform/devices

I believe the above contains a listing of the "non-discoverable" devices which are present in the device tree blobs.

I'm still not getting the device tree that well, so my guess here could be totally incorrect.

So on the working board (4.4.12-ti-r31), I see these entries for the PRU in the above directory:

4a300000.pruss

4a320000.intc

4a334000.pru0

4a338000.pru1

For the badly behaving board (4.4.27-ti-r62):

ocp:pruss@4a300000

Why would these be different?

If I cat slots on the badly behaving board:

 0: PF----  -1 

 1: PF----  -1 

 2: PF----  -1 

 3: PF----  -1 

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,univ-emmc

This seems OK.  I see the same after running the PRUs on the working board.

I have not made any changes to uEnv.txt.

Very baffled by this and not making progress.

Regards,

Greg

[William Hermans]

What does lsmod have to say ? because . . .

william@beaglebone:~$ uname -r
4.4.14-ti-r34
william@beaglebone:~$ ls /sys/bus/platform/devices |grep pru
4a300000.pruss
william@beaglebone:~$ lsmod |grep pru
uio_pruss               4928  0
uio                     8822  2 uio_pruss,uio_pdrv_genirq

It sound as though perhaps the remotproc driver is not loaded, or you have the UIO driver loaded. You made the proper adjustment to the board file for the second board ?

[Greg]

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.  ???

[William Hermans]

On Mon, Nov 7, 2016 at 5:39 PM, Greg <soapy...@comcast.net> wrote:

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.  ???

 

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.

[Neil Jubinville]

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.

[Neil Jubinville]

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

[William Hermans]

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.

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/58a346dc-09ce-4e54-aa2b-ac48f52275aa%40googlegroups.com.

[William Hermans]

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.

[Neil Jubinville]

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/462d6573-2c1d-4856-ab73-a867686b9084%40googlegroups.com.

[Neil Jubinville]

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

[William Hermans]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c907c710-189c-4df6-8958-674087a0cf9c%40googlegroups.com.

[William Hermans]

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 . . .

[Greg]

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.

4.  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.

5.  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

[William Hermans]

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.

[William Hermans]

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 . . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4431b19a-668e-44bc-890d-9b2dc92c46b8%40googlegroups.com.

[Neil Jubinville]

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

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Neil Jubinville]

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 :) 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)