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. On Mon, Nov 7, 2016 at 2:25 PM, Neil Jubinville <n...@orbitalsoftware.ca> wrote: > 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? > > > > > On Monday, November 7, 2016 at 11:56:40 AM UTC-7, Neil Jubinville wrote: >> >> 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 | 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. >>> >>> On Monday, November 7, 2016 at 11:29:28 AM UTC-7, din...@gmail.com >>> wrote: >>>> >>>> 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 >>>> >>>> On Monday, November 7, 2016 at 6:24:30 PM UTC+2, Neil Jubinville wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> On Saturday, November 5, 2016 at 4:19:27 AM UTC-6, din...@gmail.com >>>>> wrote: >>>>>> >>>>>> 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: >>>>>> > >>>>>> > >>>>>> > >>>>>> > 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 >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Tuesday, November 1, 2016 at 2:02:02 PM UTC-6, RobertCNelson >>>>>> wrote:On Tue, Nov 1, 2016 at 2:57 PM, Robert Nelson < >>>>>> robert...@gmail.com> wrote: >>>>>> > >>>>>> > > 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: >>>>>> > >>>>>> > >>>>>> > >>>>>> > 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" */ >>>>>> > >>>>>> > >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > Robert Nelson >>>>>> > >>>>>> > https://rcn-ee.com/ >>>>>> >>>>>> -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/39726e53-a6da-4ae4-b86e-980d53c75b5d%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/39726e53-a6da-4ae4-b86e-980d53c75b5d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoj9fc3Oy5vVcfvvD%2BXH9gy%2BQYyqVEU3_R71FZa-oouhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.