Kernel 4.14: how to enable PRU access to PWMSS?

[masl...@gmail.com]

Hi,

during change from 3.8 kernel to 4.14 I struggled with an issue regarding PWMSS accessed by PRU.

On old kernel I load overlay am33xx_pwm to activate the PWMSS.

I verified this with: devmem2 0x483000000 (base address of PWMSS0)

With 4.14 kernel I get 'bus error' when I execute same 'devmem2 0x483000000'

Also PRU have no access to PWMSS.

But loading the am33xx_pwm seems succesful, at least the sysfs folder is populated with pwm folders.

How can the PRU gain access to PWMSS?

Best regards

[Daniel Kulp]

I wasn't able to get access to the PWM registers from the ARM side (same bus error), but the PRU can still access them fine.   For what I was doing a few weeks ago, I used the normal linux PWM devices to enable the PWM pin, but then used the PRU to configure the registers and such.  Seemed to work OK.

Dan

[Super Duper88]

Hi Daniel,

thanks for reply. Which kernel and overlay do you use?

How do you enable the PWM pins using PWM devices?

Usually I configure the pins in a overlay.

On Kernel 3.8 and 4.1 it seems to work. But on 4.9 and 4.14 PRU can't access PWMSS.

Best 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/Ia2OC_8wArE/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/e0bc70ce-afab-491d-b716-c742df377b7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Kulp]

I really just use the cape-universal.   I use the /sys stuff to export the pin as pwm.  I also use the sysfs interface to setup initial PWM values (period/duty_cycle/enable) and after that, the PRU seems to be able to manipulate the PWM registers to change the dutyscycles and such as needed.  

Dan

To unsubscribe from this group and all its topics, send an email to beagl...@googlegroups.com.

[TJF]

Do you enable the PWMSS-0 bit in the tbclken register? AFAIR the PRU cannot write to PWMSS-0 SS when the tbclk isn't enabled. See

https://groups.google.com/d/msg/beagleboard/eVgyVduT288/bSJXkkvsBwAJ

For libpruio I added a loadable kernel module to fix this issue.

Regards

[Super Duper88]

@Daniel:

Thanks for your hints. In my 4.14-bone kernel the pwm devices are already exported when overlay is loaded.

So I have to echo values to period, duty-cycle and enable to start PWM. In my case eCAP2(PWMSS2)

After that PRU has also access to ECAP2.

A little bit ugly procedure...

@TJF

I had also the idea to enable clock for PWMSS2 via enabling control module bit.

But writing to "pwmss_ctrl Register" 0x44E10664 didn't change behaviour.

Maybe I have to write also to "CM_PER_EPWMSS2_CLKCTRL Register" at 0x44E000D8?

Thanks for your input!

--

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/Ia2OC_8wArE/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/39052a41-6854-473c-81ae-639a2cde7691%40googlegroups.com.

[TJF]

I said:

AFAIR the PRU cannot write to PWMSS-0 SS when the tbclk isn't enabled.

That's wrong, sorry.

 

Am Samstag, 6. Juli 2019 02:24:02 UTC+2 schrieb Super Duper88:

I had also the idea to enable clock for PWMSS2 via enabling control module bit.

But writing to "pwmss_ctrl Register" 0x44E10664 didn't change behaviour.

How do you write? The PRU has no write access to that adress (just fails, no message). It needs the ARM in supervisor mode (kernel module).

 

Maybe I have to write also to "CM_PER_EPWMSS2_CLKCTRL Register" at 0x44E000D8?

Sure, this reg must contain the value 2. The PRU can write.

Regards

PS: You could use the loadable kernel module from libpruio to fix this issue. First, it enables all PWM module clocks [0-2] (like in 3.8 kernel). And later you can adapt the setting via sysfs (to synchonize PWM modules). Just install the libpruio-lkm package from Arends PPA. Find details at

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPreparation.html#SecDebPac

[Super Duper88]

Am Sa., 6. Juli 2019 um 07:08 Uhr schrieb TJF <jeli.f...@gmail.com>:

I said:

AFAIR the PRU cannot write to PWMSS-0 SS when the tbclk isn't enabled.

That's wrong, sorry.

No problem :-)

 

Am Samstag, 6. Juli 2019 02:24:02 UTC+2 schrieb Super Duper88:

I had also the idea to enable clock for PWMSS2 via enabling control module bit.

But writing to "pwmss_ctrl Register" 0x44E10664 didn't change behaviour.

How do you write? The PRU has no write access to that adress (just fails, no message). It needs the ARM in supervisor mode (kernel module).

 

You are completely right. After some reading, I found that in AM335x TRM:

Note: For writing to the control module registers, the MPU will need to be in privileged mode of operation
and writes will not work from user mode.

I assumed if PRU has access to global memory, I could write everywhere but that's obviously wrong.

Also thanks for the link to libpruio. Impressive work!

All in all getting PWMSS to work in 4.x was a much harder than expected.

Hopefully usage of SPI is less complicated...

Grüße aus Erfurt

Best regards

 

Maybe I have to write also to "CM_PER_EPWMSS2_CLKCTRL Register" at 0x44E000D8?

Sure, this reg must contain the value 2. The PRU can write.

Regards

PS: You could use the loadable kernel module from libpruio to fix this issue. First, it enables all PWM module clocks [0-2] (like in 3.8 kernel). And later you can adapt the setting via sysfs (to synchonize PWM modules). Just install the libpruio-lkm package from Arends PPA. Find details at

http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPreparation.html#SecDebPac

--

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/Ia2OC_8wArE/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/18b83539-f70a-457a-b54b-2d85a3f0f6d8%40googlegroups.com.

[jay]

--

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/97f80482-9338-4008-9e03-6ca26d8150e5%40googlegroups.com.

[TJF]

Am Dienstag, 9. Juli 2019 01:58:11 UTC+2 schrieb Super Duper88:

I assumed if PRU has access to global memory, I could write everywhere but that's obviously wrong.

Also thanks for the link to libpruio. Impressive work!

Only the Control Module registers are blocked for the PRU.

Yes, libpruio is impressive (I'm self-praising here :-). But users get no information on this forum. It's still an insiders tip.

Did you try the libpruio-lkm package? Does it fix your issue?

Liebe Grüße nach Thüringen