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 <[email protected]>
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 <[email protected]
>> > 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:
>>>> date/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 <[email protected]>
>>>> 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 <
>>>>> [email protected]> 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 <[email protected]> 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 [email protected].
>>>>>> 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 [email protected].
>>> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORqB7ZD2Hk4M%2BiDzoJxHWG_13aiGkiyH_Z8PBSkn3gj0Jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
