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/ms
>>>> gid/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/CALHSORpr%2BO3TNr%2BtL3wGV_Mh_iNt%3DDQ5sDo5MDRKETWsBzwobg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
