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. On Monday, November 7, 2016 at 4:23:16 PM UTC-7, Neil Jubinville wrote: > > 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 > > > > > On Monday, November 7, 2016 at 2:39:36 PM UTC-7, William Hermans wrote: >> >> 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 <[email protected]> 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 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 < >>> [email protected]> 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, [email protected] >>>>>> 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, [email protected] >>>>>>>> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> > >>>>>>>>> > > On Tue, Nov 1, 2016 at 2:51 PM, Neil Jubinville < >>>>>>>>> [email protected]> 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 [email protected]. >>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/70a74fae-bf0e-4ebd-8cd2-25bc0d4792e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
