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?
Yes, pwm works in 4.1..
dmesg -c
config-pin overlay cape-universal
dmesg | pastebinit
Regards,
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..
Regards,
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
Regards,
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!
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
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
Regards,
Sorry, I left that out.
config-pin -q P9_14
P9_14 Mode: pwm
It appears to be set right.
–Mark
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
Regards,
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..
Regards,
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
For the pwm, I think it's load order (scary).... not sure if we can
for an alias in the dt..
Regards,
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
@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@
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 
attached . . .but I figure you all knew that already 
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
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 . . .
We could also add the alias to the am33xx.dtsi:
like:
Regards,
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
Regards,