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.
