Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

*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

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

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 On Monday, November 7,

Re: [beagleboard] Re: Surefire PRU Example

On Mon, Nov 7, 2016 at 5:39 PM, Greg 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

Re: [beagleboard] Re: Surefire PRU Example

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. On Mon, Nov 7, 2016 at 6:03 PM, William

Re: [beagleboard] Re: Surefire PRU Example

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. On Mon, Nov 7, 2016 at 5:58 PM, Neil Jubinville wrote: > Look up in this thread to Robert's post I believe both are

Re: [beagleboard] Re: Surefire PRU Example

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) 0027 pinctrl-single* No change - always stays at 027 - Seems like it is ignoring

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

On Mon, Nov 7, 2016 at 5:07 PM, Greg wrote: > 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

Re: [beagleboard] Re: Surefire PRU Example

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.

Re: [beagleboard] Re: Surefire PRU Example

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) 0027 pinctrl-single Still no toggle. Tonight I'll try to get the pin mode to change and see it in the pin debug. Neil On Monday, November 7,

Re: [beagleboard] Re: Surefire PRU Example

Ah, I think I see. Perhaps the left most bit is to indicate input( 0 ) or output( 1 ). On Mon, Nov 7, 2016 at 2:32 PM, William Hermans wrote: > 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

Re: [beagleboard] Re: Surefire PRU Example

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,

Re: [beagleboard] Re: Surefire PRU Example

Does this look right? fragment@0 { target = <_pinmux>; __overlay__ { pru_gpio_pins: pinmux_pru_gpio_pins { pinctrl-single,pins = < 0x1a4 0x0f /* P9 27 GPIO3_19:

Re: [beagleboard] Re: Surefire PRU Example

I am using 4.4.27-ti-r62. On Monday, November 7, 2016 at 11:39:50 AM UTC-7, Neil Jubinville wrote: > > 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 |

Re: [beagleboard] Re: Surefire PRU Example

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) 0027 pinctrl-single*

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

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)

Re: [beagleboard] Re: Surefire PRU Example

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 On Saturday, November 5, 2016 at 9:13:50 AM UTC+2, Neil Jubinville wrote: > OK This worked for the loading: > >

Re: [beagleboard] Re: Surefire PRU Example

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

[beagleboard] Re: Surefire PRU Example

Brett: Thanks for the feedback on the eLinux page. I have more examples to develop when time permits. --Mark On Tuesday, November 1, 2016 at 2:18:11 PM UTC-4, Brett Hamilton wrote: > > http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg is the > best summary I've found for the

Re: [beagleboard] Re: Surefire PRU Example

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

Re: [beagleboard] Re: Surefire PRU Example

On Tue, Nov 1, 2016 at 2:57 PM, Robert Nelson wrote: > On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville > wrote: >> I am trying to avoid buying that TI cape :) >> >> OK update: Indeed running the updatekernel.sh brought me to 4.4.27 This >>

Re: [beagleboard] Re: Surefire PRU Example

On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville 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

[beagleboard] Re: Surefire PRU Example

I am trying to avoid buying that TI cape :) OK update: Indeed r*unning 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

[beagleboard] Re: Surefire PRU Example

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. -- For more options, visit

[beagleboard] Re: Surefire PRU Example

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: