Can’t get my PRU controller to work with 5.10.168-ti-r83 Trixie, Can get the linux /dev/bone/pwm to work correctly using a modified overlay form 6.18.x.
The code I am using has worked in the past. Does anyone have a solution to get this peripereal to work with the PRU’s?
PRU-EHRPWM1-2.dtso (2.4 KB)
these symlinks don’t work for pwm… they are manually created in the bb-symlinks startup script.
What bb-symlinks are you refering to? I have been able with 5.10 to get /dev/bone/pwm/1 & 2 both a and b setup on boot. I can then set the period, duty_cycle, and enable to work as expected.
I would think if I get the device tree overlay correct for pin muxing. Then direct register to the EHRPWM1&2 at address locations 0x48302000 and 0x48304000 respectively would work.
I’ll hopefully do a device tree for BBB and PB later today, my Linux code for programming the ePWM, still isn’t finished, there are a lot of registers to write, and want to do it in a systematic way …
did you mean /sys/class/pwm ? When I do “echo 0 > /sys/class/pwm/pwmchip0/export“ it creates a pwm, where you can set some parameters. Oddly it doesn’t exist on my BBB running Arch Linux.
Next I looked into device tree for getting eHRPWM* out on the BBB, only seem to be able to get eHRPWM1 & 2 out on the pin out (eHRPWM0 doesn’t seem to go to the headers - no sure where it goes). But whats very strange is its slightly different for the AM3558 and AM3559, when both these chips were used on BBB - I have a AM3559 device. Not sure if I’m doing something wrong …
I am running Debian Trixie with 5.10.168-ti-83. I don’t know how the /dev/bone/pwm symlinks are being created. Can’t find any reference in the Device Trees. It is got to becoming from my /boot/uEnv.txt:
enable_uboot_cape_universal=1. The am335x-boneblack-uboot-uinv.dtb is being loaded. Other then that no clue. Anyway if the symlinks don’t exist use the /sys/class/…… export to create the device. Can’t answer for Arch Linux.
yes problem on arch was I hadn’t loaded the device tree overlays. On 6.13 kernel they are called
BB-PWM0-00A0 BB-PWM1-00A0 BB-PWM2-00A0
So just tried writing to /sys/class/pwm variables (this is direct from kernel btw - not OS dependent, the TI PWM parts of kernel use SYSFS - and that give the /sys/class/pwm files you write to).
Anyway with the above DTOB files loaded, and trying to detect the signal on P9.31 P9.29 for PWM0 and P9.14 and P9.16 for PWM1 - and I get nothing out …
I may do a quick device tree specifically for the AM3459 CPU I have, now have the schematic for the BBB, so can trace the pins to pinouts … Think only for the RevC BBB, IIRC mine is RevA …
Can you on Arch enable overlays and uboot_cape_universal in the uEnv.txt, if that is the boot method?
The reason I use kernel 5.10 is because of cape_universal and /sys/class/… is still active. I think that it is obsolete with the newer kernels for gpio. I think that libgpiod is replaceing /sys/class/gpio. It has been some time that I used kernel 6.18 with the overlays BB-EHRPWM0-P9_29-P9_31 and they worked as expected. Don’t remember whether I used /sys/class/pwm or whether they were automatically installed with symlinks to /dev/bone/pwm/0/…. or not. Any way I suggest one of these images Latest Software Images - BeagleBoard . I have been using one of the non-graphical images.
$uname -a
Linux BeagleBone 5.10.168-ti-r83 #1trixie SMP PREEMPT Thu Aug 7 20:35:21 UTC 2025 armv7l GNU/Linux
In arch you modify /boot/boot.txt with uboot comands, compile to boot.scr, then uboot is set up to read it. So in my uboot.txt I have:
fdt addr ${fdt_addr_r}
load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/BB-PWM0-00A0.dtbo
fdt resize ${filesize}
fdt apply 0x88060000
load ${devtype} ${devnum}:${bootpart} 0x88070000 /lib/firmware/BB-PWM1-00A0.dtbo
fdt resize ${filesize}
fdt apply 0x88070000
load ${devtype} ${devnum}:${bootpart} 0x88080000 /lib/firmware/BB-PWM2-00A0.dtbo
fdt resize ${filesize}
fdt apply 0x88080000
fdt resize
You can then check what uboot has loaded in
/proc/device-tree/chosen/overlays/
And that shows I loaded the three PWM0-2 overlay blobs. Then that the pwm appear in /sys/class/pwm shows that the kernel modules have started.
So its done differently that in debian.
On BBB I’m stuck on 6.13 at the mo, the arch people don’t have a working beagle at the moment, so I need to prod them each time I need an update, and then do testing for them before they release …
I could spin my own kernel on the PB, but it something like a two day compile …
Just finished bit banger with the PRU’s. Now for my motor to arrive today for the real test. I have 3 apps/code for PRU0, PRU1, and Linux runing on Debian 13. I use CCS 12.8.1 for the PRU’s and Eclipse for Ubuntu 24.04 as the Cross Compiler/Debug for the BBB. At some point I will upload to:
gitklindsayjr · GitHub a zipped up CCS12.8.1 and Eclipse Project files. The issue here is the environment of Ubuntu has to be the same. Cross Compiler location and Pru Support package.
With my bespoke device tree blob - just got signals out on PWM2 on P8.45 and P8.46 … PWM1 was meant to working as well - but no love - let me check the pin out …
Edit 5 minute later: I miss counted P8.34 and P8.36 which is where PWM1 comes out…
@RobertCNelson so my AM3359 doesn’t seem to work with the PWM dtb that came with my kernel - but does work with my from TI SysConfig - this is on a BBB Rev A. I’ve a PB with the AM3358 that looks like a different device tree. Do you want me to test there? Then do you want me to upload?
And just wondering about getting PWM0 out - there are pins on the header - but they go to the Display interface (TDA19988) as well, so I’d have to disable that …