Enable PWM on BBB Debian 4.1 Jessie

[dogan yazar]

Does anybody manage to enable PWM on BBB Debian 4.1 Jessie? I was expecting it to work after I run "config-pin overlay cape-universal" but I see that no chip is listed under "/sys/class/pwm/". Any ideas? 

[Robert Nelson]

Yes, pwm works in 4.1..

dmesg -c

config-pin overlay cape-universal

dmesg | pastebinit

Regards,


--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

Sorry, pwm is disabled in "cape-universal" overlay:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-universal-00A0.dts#L1533

It was causing hard locks last time i tried using it (according to
git, 2 months ago),

Feel free to fork:

https://github.com/beagleboard/bb.org-overlays

enable the pwm's and test it..

If you get it "working" please create a pull request..

[dogan yazar]

I verified it locally yesterday and it works fine. Have not seen any issues other than the already existing mysterious reboots which you are all aware of. 

Thanks a lot! 

On Tuesday, July 21, 2015 at 6:02:27 PM UTC+2, RobertCNelson wrote:

okay, had a chance to test this and enable them..

cd /opt/source/bb.org-overlays/
git pull
./install.sh

sudo reboot


root@beaglebone:~# config-pin overlay cape-universal
Loading cape-universal overlay
[   36.591695] bone_capemgr bone_capemgr: part_number
'cape-universal', version 'N/A'
[   36.612105] bone_capemgr bone_capemgr: slot #4: override
[   36.629826] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[   36.636895] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,cape-universal'
[   37.071214] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
[   37.098140] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
[   37.104719] gpio-of-helper ocp:cape-universal: Allocated GPIO id=2
[   37.148301] gpio-of-helper ocp:cape-universal: Allocated GPIO id=3
[   37.154883] gpio-of-helper ocp:cape-universal: Allocated GPIO id=4
[   37.194330] gpio-of-helper ocp:cape-universal: Allocated GPIO id=5
[   37.206406] gpio-of-helper ocp:cape-universal: Allocated GPIO id=6
[   37.236009] gpio-of-helper ocp:cape-universal: Allocated GPIO id=7
[   37.258126] gpio-of-helper ocp:cape-universal: Allocated GPIO id=8
[   37.264734] gpio-of-helper ocp:cape-universal: Allocated GPIO id=9
[   37.308109] gpio-of-helper ocp:cape-universal: Allocated GPIO id=10
[   37.314793] gpio-of-helper ocp:cape-universal: Allocated GPIO id=11
[   37.348126] gpio-of-helper ocp:cape-universal: Allocated GPIO id=12
[   37.354781] gpio-of-helper ocp:cape-universal: Allocated GPIO id=13
[   37.390272] gpio-of-helper ocp:cape-universal: Allocated GPIO id=14
[   37.396931] gpio-of-helper ocp:cape-universal: Allocated GPIO id=15
[   37.438234] gpio-of-helper ocp:cape-universal: Allocated GPIO id=16
[   37.444926] gpio-of-helper ocp:cape-universal: Allocated GPIO id=17
[   37.488201] gpio-of-helper ocp:cape-universal: Allocated GPIO id=18
[   37.494891] gpio-of-helper ocp:cape-universal: Allocated GPIO id=19
[   37.528007] gpio-of-helper ocp:cape-universal: Allocated GPIO id=20
[   37.534716] gpio-of-helper ocp:cape-universal: Allocated GPIO id=21
[   37.568106] gpio-of-helper ocp:cape-universal: Allocated GPIO id=22
[   37.574765] gpio-of-helper ocp:cape-universal: Allocated GPIO id=23
[   37.617756] gpio-of-helper ocp:cape-universal: Allocated GPIO id=24
[   37.641455] gpio-of-helper ocp:cape-universal: Allocated GPIO id=25
[   37.651377] gpio-of-helper ocp:cape-universal: Allocated GPIO id=26
[   37.677719] gpio-of-helper ocp:cape-universal: Allocated GPIO id=27
[   37.697700] gpio-of-helper ocp:cape-universal: Allocated GPIO id=28
[   37.717755] gpio-of-helper ocp:cape-universal: Allocated GPIO id=29
[   37.730354] gpio-of-helper ocp:cape-universal: Allocated GPIO id=30
[   37.750794] gpio-of-helper ocp:cape-universal: Allocated GPIO id=31
[   37.771213] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32
[   37.793389] gpio-of-helper ocp:cape-universal: Allocated GPIO id=33
[   37.813290] gpio-of-helper ocp:cape-universal: Allocated GPIO id=34
[   37.830964] gpio-of-helper ocp:cape-universal: Allocated GPIO id=35
[   37.850323] gpio-of-helper ocp:cape-universal: ready
[   37.869635] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 179,
base_baud = 3000000) is a 8250
[   37.913765] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 180,
base_baud = 3000000) is a 8250
[   37.965252] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 181,
base_baud = 3000000) is a 8250
[   38.056564] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[   38.083959] bone_capemgr bone_capemgr: slot #4: dtbo
'cape-universal-00A0.dtbo' loaded; overlay id #0
[   38.320777] CAN device driver interface
[   38.385921] pruss_uio 4a300000.pruss: pins are not configured from the driver
[   38.507182] c_can_platform 481cc000.can: c_can_platform device
registered (regs=fa1cc000, irq=190)
[   38.628029] c_can_platform 481d0000.can: c_can_platform device
registered (regs=fa1d0000, irq=191)
root@beaglebone:~# ls /sys/class/pwm/
pwmchip0  pwmchip2  pwmchip4  pwmchip6 pwmchip7

[Robert Nelson]

[Mark A. Yoder]

I'm have trouble reproducing this.  I'm running

cat /etc/dogtag

BeagleBoard.org Debian Image 2016-01-24

cat $SLOTS 

 0: PF----  -1 

 1: PF----  -1 

 2: PF----  -1 

 3: PF----  -1 

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln

Wire an LED to P9_14 and then:

cd /sys/class/pwm/pwmchip3

echo 0 > export

cd pwm0

echo 1 > enable

echo 1000000000 > period

echo  500000000 > duty_cycle

No errors, but the LED doesn't flash. The LED does turn on when I control via the GPIO.

What am I missing?

--Mrk

[Robert Nelson]

On Mon, Feb 8, 2016 at 4:22 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> I'm have trouble reproducing this. I'm running
>
> cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-01-24
> cat $SLOTS
> 0: PF---- -1
> 1: PF---- -1
> 2: PF---- -1
> 3: PF---- -1
> 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,cape-universaln
>
> Wire an LED to P9_14 and then:
> cd /sys/class/pwm/pwmchip3
> echo 0 > export
> cd pwm0
> echo 1 > enable
> echo 1000000000 > period
> echo 500000000 > duty_cycle
>
> No errors, but the LED doesn't flash. The LED does turn on when I control
> via the GPIO.
>
> What am I missing?

What's the status of P9_14?

sudo config-pin -q P9.14

sudo config-pin P9.14 pwm

then re-check:

sudo config-pin -q P9.14

[Mark A. Yoder]

Sorry, I left that out.

config-pin -q P9_14

P9_14 Mode: pwm

It appears to be set right.

--Mark

[William Hermans]

Have the pins "shifted" in this kernel again ?

--
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.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Mon, Feb 8, 2016 at 4:41 PM, William Hermans <yyr...@gmail.com> wrote:
> Have the pins "shifted" in this kernel again ?

or the pwm's moved and i didn't notice..

The only userspace pwm i've used is:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-BACONE-00A0.dts

and accessed the pwm's via:

https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-BONE-BACONE/example.sh

[Robert Nelson]

On Mon, Feb 8, 2016 at 4:22 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:

> I'm have trouble reproducing this. I'm running
>
> cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-01-24
> cat $SLOTS
> 0: PF---- -1
> 1: PF---- -1
> 2: PF---- -1
> 3: PF---- -1
> 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,cape-universaln
>
> Wire an LED to P9_14 and then:
> cd /sys/class/pwm/pwmchip3

Yeah this might have moved...

For the bacon cape, one pin was P9_14 i had used:

red="/sys/class/pwm/pwmchip0/pwm0"
green="/sys/class/pwm/pwmchip1/pwm0"
blue="/sys/class/pwm/pwmchip1/pwm1"

Try one of those..

[Mark A. Yoder]

Well....  /sys/class/pwm/pwmchip2/pwm0 worked!  Thanks...

So given the pin name (P9_14 for example) how do I find the pwm path? (I'm trying to port bonescript to Jessie.)

--Mark

[Robert Nelson]

On Mon, Feb 8, 2016 at 5:36 PM, Mark A. Yoder <mark.a...@gmail.com> wrote:
> Well.... /sys/class/pwm/pwmchip2/pwm0 worked! Thanks...
>
> So given the pin name (P9_14 for example) how do I find the pwm path? (I'm
> trying to port bonescript to Jessie.)

For the pwm, I think it's load order (scary).... not sure if we can
for an alias in the dt..

[Mark A. Yoder]

Well, they move around depending on which dts you boot under.  P9_14 appears at /sys/class/pwm/pwmchip2/pwm0 with

cat $SLOTS 

 0: PF----  -1 

 1: PF----  -1 

 2: PF----  -1 

 3: PF----  -1 

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,univ-emmc

But if you use:

cat $SLOTS 

 0: PF----  -1 

 1: PF----  -1 

 2: PF----  -1 

 3: PF----  -1 

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln

it appears at /sys/class/pwm/pwmchip4/pwm0!

Is there a way the pwm system can tell you which headers they are attached to?

--Mark

[William Hermans]

@Mark,

Yes,and no.

No, in that there is no way to differentiate which header the peripheral is physically attacked to.

Yes, in that device tree "defines" usually define a device module as something similar to:

device_tree_friendly_name@<peripheral module base address>

In other words, we should be able to extrapolate which device module, and pins are used based on their base address. There is also a place in a systems directory structure that sysfs uses the base address as part of the path for the device . . .but I can not recall exactly where that is :/

--

[William Hermans]

attached . . .but I figure you all knew that already ;)

[Mark A. Yoder]

Yup, here's the mappings depending on which dts file is used:

# universaln

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300200.ehrpwm/pwm/pwmchip0

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip4

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6

# cape-emmc

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 -> ../../devices/platform/ocp/48300000.epwmss/48300200.ehrpwm/pwm/pwmchip2

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 -> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6

Yes, the addresses are there, so I need to find a place that maps the addresses to the header pin numbers.

--Mark

On Monday, February 8, 2016 at 6:42:11 PM UTC-5, RobertCNelson wrote:

[William Hermans]

You know this makes me cringe when I think about it. But perhaps Bonescript needs it's own dt overlay ? One needs consistency when using a certain thing, and based on what I'm seeing, you're not guaranteed that. What's more, there is no real way you can expect this either, considering difference capes do different things.

*Or* there needs to be a mechanism in device tree, that populates some file somewhere, that lets the users know what's going on. This *can* be done via /dev/mem/ and using mmap() to read out register data for every pin, and perihperal to see what state it's in but man . . . that'd be an awful lot of work to do, just to port bonescript . . .

--

[Robert Nelson]

We could also add the alias to the am33xx.dtsi:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20

like:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee

[Robert Nelson]

give this a shot:

https://github.com/RobertCNelson/dtb-rebuilder/commit/27b496e93853a210fb79bc95681c54e69f20d494

git clone https://github.com/RobertCNelson/dtb-rebuilder
cd ./dtb-rebuilder/
git checkout origin/4.1-ti-pwm -b tmp
make
sudo make install

sudo reboot

[William Hermans]

We could also add the alias to the am33xx.dtsi:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20

like:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee

Yeah, but would that help with the given problem with what Mark is currently facing ? Look at the two capes, and base address, and mode each pwm chip is placed in.

[William Hermans]

Mark,
Quite honestly, I have no idea how both of those capes you're showing data on work. Each peripheral module between the two have different base addresses. Offset width, I can understand being different, but device module base address ? . . .I'm confused.

[Mark A. Yoder]

Robert:

  I tried it.  What should I see?  It looks like I get yet another ordering of the aliases.

# universaln

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300200.ehrpwm/pwm/pwmchip0

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip4

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6

# cape-emmc

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 -> ../../devices/platform/ocp/48300000.epwmss/48300200.ehrpwm/pwm/pwmchip2

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 -> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4

# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6

# New universaln (4.1-ti-pwm)

# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300200.ehrpwm/pwm/pwmchip0

# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2

# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip4 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip4

# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip5 -> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip5

# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip7 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7

--Mark

[Robert Nelson]

Thanks for testing Mark, looks like we need to patch the ecap/ehrpwm
driver to utilze the alias..

I'm going to be out of the lab today and tomorrow, so i'll take a look
at this thursday morning..

[Mark A. Yoder]

Thanks for the help Robert.  I'e hacked around the problem for the short term.

--Mark