So here: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/include/dt-bindings/board/am335x-bbw-bbb-base.h#L88 your pin address seems to be correct.
Then here: http://beaglebone.cameon.net/home/pin-muxing says a couple of my assumptions were wrong. 0x25h seems correct. On Mon, Nov 7, 2016 at 7:08 PM, William Hermans <yyrk...@gmail.com> wrote: > 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 case a value of 0xD would be sufficient. For the mux mode( if you > do not need a pull up or pull down) Assuming my assumption is correct . . . > > On Mon, Nov 7, 2016 at 7:04 PM, William Hermans <yyrk...@gmail.com> wrote: > >> So if my assumption that the left most bit of the first nibble is meant >> to be 0 for input. You're device tree operation mode is incorrect. It'd be >> set in input mode with the current code I'm seeing. Mode 5 with output >> enabled. Should be 1101b or 0xDh. Then tacking on the 0x20h, you get >> 0x2Dh. LIke below: >> >> pru_pru_pins: pinmux_pru_pru_pins { >> pinctrl-single,pins = <0x1a4 0x2D>; /* >> mcasp0_fsr.pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU */ >> }; >> >> You really need to check the actual pin address, and the pinmux field >> though to make sure what I'm saying is valid. I honestly don't know for a >> fact. I'm making the assumption that the left most bit of the first nibble >> is in fact to set IO direction, and that your pin address is also valid. >> >> On Mon, Nov 7, 2016 at 6:48 PM, Neil Jubinville <n...@orbitalsoftware.ca> >> wrote: >> >>> *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.... >>> >>> Neil >>> >>> On Monday, November 7, 2016 at 6:29:38 PM UTC-7, William Hermans wrote: >>>> >>>> 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): ocp:P8_13_pinmux (GPIO UNCLAIMED) function >>>> pinmux_P8_13_pwm_pin group pinmux_P8_13_pwm_pin >>>> pin 18 (44e10848.0): ocp:P9_14_pinmux (GPIO UNCLAIMED) function >>>> pinmux_P9_14_pwm_pin group pinmux_P9_14_pwm_pin >>>> pin 19 (44e1084c.0): ocp:P9_16_pinmux (GPIO UNCLAIMED) function >>>> pinmux_P9_16_pwm_pin group pinmux_P9_16_pwm_pin >>>> pin 84 (44e10950.0): ocp:P9_22_pinmux (GPIO UNCLAIMED) function >>>> pinmux_P9_22_pwm_pin group pinmux_P9_22_pwm_pin >>>> pin 85 (44e10954.0): ocp:P9_21_pinmux (GPIO UNCLAIMED) function >>>> pinmux_P9_21_pwm_pin group pinmux_P9_21_pwm_pin >>>> >>>> >>>> On Mon, Nov 7, 2016 at 6:19 PM, Neil Jubinville < >>>> ne...@orbitalsoftware.ca> wrote: >>>> >>>>> 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, 2016 at 6:05:53 PM UTC-7, William Hermans wrote: >>>>>> >>>>>> It's also described here: https://groups.google.com/foru >>>>>> m/#!searchin/beagleboard/Robert$20Nelson$20remoteproc|sort:d >>>>>> ate/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 Hermans <yyr...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> 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 < >>>>>>> ne...@orbitalsoftware.ca> wrote: >>>>>>> >>>>>>>> Look up in this thread to Robert's post I believe both are >>>>>>>> disabled. You have to choose one and enable it. >>>>>>>> >>>>>>>> On Monday, November 7, 2016 at 5:52:59 PM UTC-7, William Hermans >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 7, 2016 at 5:39 PM, Greg <soapy...@comcast.net> 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 lsmod, I am seeing normal Remoteproc drivers after >>>>>>>>>> modprobe commands, except for the rpmsg driver which is not getting >>>>>>>>>> inserted when I think it should. >>>>>>>>>> >>>>>>>>>> I would think there is at least some element of the device tree >>>>>>>>>> entries in /sys which are independent of loadable kernel modules? >>>>>>>>>> I'm trying to understand the approach to debug this type of >>>>>>>>>> problem. >>>>>>>>>> I think I need to verify solid device tree entries for the PRUs >>>>>>>>>> and go from there. ??? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> So a while back, in one of the board overlay, or regular overlays, >>>>>>>>> maybe one of the includes( I forget which ) Robert had comments, and >>>>>>>>> commented out code for enabling UIO, or remoteproc in the latest TI >>>>>>>>> kernels. I'm not sure if the newer version of these files have the >>>>>>>>> remoteproc includes commented out or not. So what I'm saying here may >>>>>>>>> not >>>>>>>>> apply. >>>>>>>>> >>>>>>>>> Let me search the groups here and find what I'm thinking of. >>>>>>>>> >>>>>>>> -- >>>>>>>> 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...@googlegroups.com. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/beagleboard/58a346dc-09ce- >>>>>>>> 4e54-aa2b-ac48f52275aa%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/beagleboard/58a346dc-09ce-4e54-aa2b-ac48f52275aa%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...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/462d6573-2c1d- >>>>> 4856-ab73-a867686b9084%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/beagleboard/462d6573-2c1d-4856-ab73-a867686b9084%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/ms >>> gid/beagleboard/c907c710-189c-4df6-8958-674087a0cf9c%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/c907c710-189c-4df6-8958-674087a0cf9c%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/CALHSORprAv-RsrMUd8QT2LGD%3Dq_rLagDpJS0j7D4RaijKT0m1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
