Using PRU to control PWM peripheral on kernel 4.1 - DTO problem?

[Justin Pearson]

I wrote pasm code that has the PRU set up a 10%-duty-cycle 33kHz square wave using PWM on the ehrpwm1B peripheral (which maps to P8_34 in mode 2).

It worked on the 3.18 kernel but doesn't work on 4.1.12.

When my C code tries to start the PRU code, prussdrv_open returns -1 (bad).

I think the problem is related to the device-tree. I'm using the overlays:

- am33xx_pwm

- bone_pwm_P8_34

- EBB-PRU-Example (from Derek Molloy's book)

When loading EBB-PRU-Example, I get a "No children" message from the pruss_uio subsystem:

[ 3822.302571] bone_capemgr bone_capemgr: part_number 'EBB-PRU-Example', version 'N/A'

[ 3822.302633] bone_capemgr bone_capemgr: slot #8: override

[ 3822.302671] bone_capemgr bone_capemgr: Using override eeprom data at slot 8

[ 3822.302713] bone_capemgr bone_capemgr: slot #8: 'Override Board Name,00A0,Override Manuf,EBB-PRU-Example'

[ 3822.308128] gpio-of-helper ocp:gpio_helper: ready

[ 3822.308324] bone_capemgr bone_capemgr: slot #8: dtbo 'EBB-PRU-Example-00A0.dtbo' loaded; overlay id #2

[ 3822.402747] pruss_uio 4a300000.pruss: No children

Also, my 4.1.12 kernel didn't seem to include the bone_pwm_P8_34 overlay (so I found it online). Is bone_pwm_P8_34 the "old way", and the "new way" involves loading the "universala.dts" overlay and then using the config-pin script? 

Here is my code:

https://www.dropbox.com/sh/0mk6g4bd12spp9x/AAArsHYddApMdMWgKb4PbtcHa?dl=0

The 'build-and-run.sh' is how I compile and run everything.

I'd really appreciate any help -- either with this specific problem, or resources for debugging problems with device-tree overlays. I'm a control-theory guy, not a kernel guy, but I'm happy to learn.

Thanks,

Justin

[Justin Pearson]

Sorry, I'm using 

# uname -a

Linux beaglebone 4.1.12-bone-rt-r16 #3 Mon Jan 9 19:44:59 PST 2017 armv7l GNU/Linux

# lsb_release -a

No LSB modules are available.

Distributor ID: Debian

Description: Debian GNU/Linux 8.7 (jessie)

Release: 8.7

Codename: jessie

[TJF]

Hi Justin!

The initial device tree changed between kernel 3.8 and 4.x. In 4.x the Control Module register pwmss_ctrl (@664h) gets cleared at boot. This register can get used to sychronize several PWM subsystems. A feature that isn't supported by the kernel nor by any of it's drivers. So no reason to change the initial state and clear that register. This just disables all PWM subsystems and makes kernel versions incompatible. (You may call it an official kernel virus).

Anyway, in order to get the PWM subsystems working in kernel 4.x you have to make sure that the register doesn't get cleared at boot. Ie. you can invert the bit-logic. Therefor download the device tree sources, edit file am33xx-clocks.dtsi, find the following nodes and make them look like (= add tag ti,set-bit-to-disable)

    ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
        #clock-cells = <0>;
        compatible = "ti,gate-clock";
        clocks = <&l4ls_gclk>;
        ti,bit-shift = <0>;
        ti,set-bit-to-disable;
        reg = <0x0664>;
    };

    ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
        #clock-cells = <0>;
        compatible = "ti,gate-clock";
        clocks = <&l4ls_gclk>;
        ti,bit-shift = <1>;
        ti,set-bit-to-disable;
        reg = <0x0664>;
    };

    ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
        #clock-cells = <0>;
        compatible = "ti,gate-clock";
        clocks = <&l4ls_gclk>;
        ti,bit-shift = <2>;
        ti,set-bit-to-disable;
        reg = <0x0664>;
    };

Then compile and install the binary trees. PWM subsystems will work after reboot.

Regards

[Justin Pearson]

Hi TJF, thanks for your note. Are you saying that the only way to get PWM in a 4.x kernel is by modifying am33xx-clocks.dtsi? Also, how can I verify whether the register is set correctly? 

Thanks,

Justin

[TJF]

Am Samstag, 1. April 2017 22:18:30 UTC+2 schrieb Justin Pearson:

Are you saying that the only way to get PWM in a 4.x kernel is by modifying am33xx-clocks.dtsi?

No. The kernel driver should also work (untested). But in your case (controlling the PWM subsystem by PRU code) you have to modify that file. (Or you can develop a loadable kernel module that writes to the register.)
 

Also, how can I verify whether the register is set correctly?

The PRU cannot write to the Control Module registers, but it can read them. Get a word from 0x44E10664 and pass it to the ARM code. Bits 0:2 must be set to get output from all PWM subsystems. In your case bit 1 set is sufficient to get ehrpwm1B working.

Regards

[Justin Pearson]

Thank you TJF, I never would have known about that register if you hadn't mentioned it. One more question (see below):

On Sat, Apr 1, 2017 at 9:20 PM, TJF <jeli.f...@gmail.com> wrote:

Am Samstag, 1. April 2017 22:18:30 UTC+2 schrieb Justin Pearson:

Are you saying that the only way to get PWM in a 4.x kernel is by modifying am33xx-clocks.dtsi?

No. The kernel driver should also work (untested). But in your case (controlling the PWM subsystem by PRU code) you have to modify that file. (Or you can develop a loadable kernel module that writes to the register.)

On the 3.18 kernel, I was able to control the PWM with the PRU without needing the PRU to initialize the PWM. The trick was to load the PWM capes "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also loading Derek's cape to initialize the pruss.) Loading the capes causes some PWM kernel driver to initialize the PWM registers, I assume. Once that's done, the PRU just has to tweak a couple registers to change the duty cycle. Is this trick what you're referring to when you say "The kernel driver should also work"? 

Would this trick of pre-loading the capes also work in a 4.x kernel?

Thanks for all your help!

Justin

 

 

Also, how can I verify whether the register is set correctly?

The PRU cannot write to the Control Module registers, but it can read them. Get a word from 0x44E10664 and pass it to the ARM code. Bits 0:2 must be set to get output from all PWM subsystems. In your case bit 1 set is sufficient to get ehrpwm1B working.

Regards

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/LZhL4S9taic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jelena Freiherr]

Hi Justin!

I just tried to answer you mail, but the google board doesn't work (once
again). I try to answer from my mail client, which I never did before.

Am Sonntag, 2. April 2017 17:26:10 UTC+2 schrieb Justin Pearson:
> On the 3.18 kernel, I was able to control the PWM with the PRU without needing the PRU to initialize the PWM. The trick was to load the PWM capes "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also loading Derek's cape to initialize the pruss.) Loading the capes causes some PWM kernel driver to initialize the PWM registers, I assume. Once that's done, the PRU just has to tweak a couple registers to change the duty cycle. Is this trick what you're referring to when you say "The kernel driver should also work"?
>
> Would this trick of pre-loading the capes also work in a 4.x kernel?
>

Sorry, I don't know any of the overlays you mentioned. And, as I said, I
never used any kernel driver for GPIO, QEP, CAP, PWM or ADC. Instead I
use an all-in-one driver (which I named libpruio), that handles all that
stuff easier, more flexible and faster than any kernel driver framework.
In order to get PWM output, there're just a few registers to set (see
file pruio_pwmss.p in the package), so no need for all that multi source
overhead.

BTW: You're developing PRU code and you're using a real time kernel. May
I ask why? Since the PRUSS are very efficient for real time tasks, I see
no reason for using additionally a real time kernel.

Regards

PS:
I just checked Derek's cape. From a first glance I found the line

compatible = "ti,beaglebone", "ti,beaglebone-black";

is wrong. The order is important, most specific first. It must be

compatible = "ti,beaglebone-black", "ti,beaglebone";

And it does more than just enabling the PRUSS (you're loading
unnecessary overhead). In the libpruio package there's the tool
dts_custom, which you can use to easy create, compile and install
minimal custom overlays (single source, no overhead).

Am 02.04.2017 um 17:25 schrieb Justin Pearson:
> Thank you TJF, I never would have known about that register if you hadn't
> mentioned it. One more question (see below):
>
> On Sat, Apr 1, 2017 at 9:20 PM, TJF <jeli.f...@gmail.com> wrote:
>
>> Am Samstag, 1. April 2017 22:18:30 UTC+2 schrieb Justin Pearson:
>>>
>>> Are you saying that the only way to get PWM in a 4.x kernel is by
>>> modifying am33xx-clocks.dtsi?
>>>
>>
>> No. The kernel driver should also work (untested). But in your case
>> (controlling the PWM subsystem by PRU code) you have to modify that file.
>> (Or you can develop a loadable kernel module that writes to the register.)
>>
>
> On the 3.18 kernel, I was able to control the PWM with the PRU without
> needing the PRU to initialize the PWM. The trick was to load the PWM capes
> "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also
> loading Derek's cape

> <https://github.com/derekmolloy/exploringBB/blob/master/chp13/overlay/EBB-PRU-Example.dts>

> to
> initialize the pruss.) Loading the capes causes some PWM kernel driver to
> initialize the PWM registers, I assume. Once that's done, the PRU just has
> to tweak a couple registers to change the duty cycle. Is this trick what

> you're referring to when you say "*The kernel driver should also work*"?

>
> Would this trick of pre-loading the capes also work in a 4.x kernel?
>
> Thanks for all your help!
> Justin
>
>
>
>
>>
>>
>>> Also, how can I verify whether the register is set correctly?
>>>
>>
>> The PRU cannot write to the Control Module registers, but it can read
>> them. Get a word from 0x44E10664 and pass it to the ARM code. Bits 0:2 must
>> be set to get output from all PWM subsystems. In your case bit 1 set is
>> sufficient to get ehrpwm1B working.
>>
>> Regards
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/beagleboard/LZhL4S9taic/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to

>> beagleboard...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%40googlegroups.com

>> <https://groups.google.com/d/msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

[Justin Pearson]

Hi Jelena, thanks for your message. See my inline responses:

On Sun, Apr 2, 2017 at 9:39 AM, Jelena Freiherr <jeli.f...@gmail.com> wrote:

Am Sonntag, 2. April 2017 17:26:10 UTC+2 schrieb Justin Pearson:
>     On the 3.18 kernel, I was able to control the PWM with the PRU without needing the PRU to initialize the PWM. The trick was to load the PWM capes "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also loading Derek's cape to initialize the pruss.) Loading the capes causes some PWM kernel driver to initialize the PWM registers, I assume. Once that's done, the PRU just has to tweak a couple registers to change the duty cycle. Is this trick what you're referring to when you say "The kernel driver should also work"?
>
>     Would this trick of pre-loading the capes also work in a 4.x kernel?
>

Sorry, I don't know any of the overlays you mentioned. And, as I said, I
never used any kernel driver for GPIO, QEP, CAP, PWM or ADC. Instead I
use an all-in-one driver (which I named libpruio), that handles all that
stuff easier, more flexible and faster than any kernel driver framework.
In order to get PWM output, there're just a few registers to set (see
file pruio_pwmss.p in the package), so no need for all that multi source
overhead.

Thank you for mentioning libpruio. I don't know very much about how device tree overlays interact with linux kernel drivers, so until I can find a good description of that, I'm inclined to use a more wasteful (but well-documented) method of configuring the I/O. Do you know of a good way to learn the details of how a device tree overlay is used by the kernel to configure the SoC registers? So far I haven't found much good documentation besides Derek Molloy's book.

 

BTW: You're developing PRU code and you're using a real time kernel. May
I ask why? Since the PRUSS are very efficient for real time tasks, I see
no reason for using additionally a real time kernel.

My team is working on a time-synchronization platform that aims to synchronize devices' clocks on a network. It's sort of like NTP, but allows users to specify the resolution of the time synchronization that they require. Here is a paper on it for more info:

https://users.ece.cmu.edu/~agr/resources/publications/RTSS16-timeline.pdf

We need the real-time Linux kernel for precise time synchronization, so that's why we're using a real-time kernel. Additionally, we're using the PRU to get precise I/O for some distributed control systems.

Best,

Justin

 

>> beagleboard+unsubscribe@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%40googlegroups.com

>> <https://groups.google.com/d/msgid/beagleboard/3041a94e-58ab-4c28-ad29-ad3a2b90315b%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 a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/LZhL4S9taic/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/85f0fe91-f65e-82f8-c6a0-5c8d133db5c4%40gmail.com.

[Jelena Freiherr]

Hi Justin!

Thanks for the info on the rt needs.

Am 02.04.2017 um 20:32 schrieb Justin Pearson:
> Thank you for mentioning libpruio. I don't know very much about how device
> tree overlays interact with linux kernel drivers, so until I can find a
> good description of that, I'm inclined to use a more wasteful (but
> well-documented) method of configuring the I/O. Do you know of a good way
> to learn the details of how a device tree overlay is used by the kernel to
> configure the SoC registers? So far I haven't found much good documentation
> besides Derek Molloy's book.

As I said, I don't use kernel drivers. They are badly documented, slow,
not very flexible, they always miss the feature I need and they change
from version to version. For my buisiness it doesn't make sense to
follow a moving target. My systems must run reliable in a 24/7 manner.

So instead, I configure the SoC registers directly by PRU code. All I
need/use is the TRM for the SoC. This is much easier and faster than
learning how to use kernel drivers (and update that knowledge all the
time). And my code runs on any kernel version (as long as a new kernel
version doesn't change default settings of the related registers).

Regards

[John Syne]

On Apr 2, 2017, at 11:32 AM, Justin Pearson <justin....@gmail.com> wrote:

Hi Jelena, thanks for your message. See my inline responses:

On Sun, Apr 2, 2017 at 9:39 AM, Jelena Freiherr <jeli.f...@gmail.com> wrote:

Am Sonntag, 2. April 2017 17:26:10 UTC+2 schrieb Justin Pearson:
>     On the 3.18 kernel, I was able to control the PWM with the PRU without needing the PRU to initialize the PWM. The trick was to load the PWM capes "am33xx_pwm" and "bone_pwm_P8_34" before running the PRU code. (And also loading Derek's cape to initialize the pruss.) Loading the capes causes some PWM kernel driver to initialize the PWM registers, I assume. Once that's done, the PRU just has to tweak a couple registers to change the duty cycle. Is this trick what you're referring to when you say "The kernel driver should also work"?
>
>     Would this trick of pre-loading the capes also work in a 4.x kernel?
>

Sorry, I don't know any of the overlays you mentioned. And, as I said, I
never used any kernel driver for GPIO, QEP, CAP, PWM or ADC. Instead I
use an all-in-one driver (which I named libpruio), that handles all that
stuff easier, more flexible and faster than any kernel driver framework.
In order to get PWM output, there're just a few registers to set (see
file pruio_pwmss.p in the package), so no need for all that multi source
overhead.

Thank you for mentioning libpruio. I don't know very much about how device tree overlays interact with linux kernel drivers, so until I can find a good description of that, I'm inclined to use a more wasteful (but well-documented) method of configuring the I/O. Do you know of a good way to learn the details of how a device tree overlay is used by the kernel to configure the SoC registers? So far I haven't found much good documentation besides Derek Molloy's book.

 

BTW: You're developing PRU code and you're using a real time kernel. May
I ask why? Since the PRUSS are very efficient for real time tasks, I see
no reason for using additionally a real time kernel.

My team is working on a time-synchronization platform that aims to synchronize devices' clocks on a network. It's sort of like NTP, but allows users to specify the resolution of the time synchronization that they require. Here is a paper on it for more info:

https://users.ece.cmu.edu/~agr/resources/publications/RTSS16-timeline.pdf

Hi Justin

Are you using a disciplined clock on the BBB?

Regards,

John

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/CABCHBhKKct1cK1dM%2Bh%2BVgLNomvD1i2iPF1rPpXKi_RmmXi-3ag%40mail.gmail.com.