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/ms
>> gid/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/CALHSORoSx%2B6r%2Bnbxzh-FLAOmn8EYTHyM7Ud6CCc8tBswHkT17g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to