Using kernel 5.10.168-ti-r83 Trixie, Aug 7, 2025. I can’t write to the register at 0x44e10664 in the control module to enable the PWM clocks.
I have used PRU0 and busybox for write’s as follows with a read at that address returns 0 instead of a 1:
$ sudo busybox 0x44e10664 w 0x01
$ sudo busybox 0x44e10664
0x00000000
I can write to the Kick Registers (0x44e10608 and 0x44e1060c) are successfully unlocked because you can write to other pinmux registers in the same block (like 0x44e10800).
Even with the Kick registers open, 0x44e10664 remains at 0x00000000 and ignores all devmem writes.
I found that writing to the sysfs /dev/bone/pwm/0/period, and enable file for the PWM’s does successfully clock the module, proving the hardware is alive, but direct register access is still being intercepted or discarded by the L3/L4 interconnect.
Can Nelson or someone clarify:
-
L3 Firewall Policy: Whether the newer kernels have a default “Firewall” policy in the Interconnect (not just the Control Module) that explicitly drops non-kernel writes to the PRU-ICSS configuration space.
-
Clock Dependency: If that register is physically behind a clock gate that only the ti-pwm or pru-rproc drivers have the authority to toggle.
1 Like
Hi Kenneth. Yes thats the CTLMOD->pwmss_ctrl register, that locks the EHRPWM clock to the system clock, this is effectively what enables the PWM to run, although not really described that way.
The critically of this register is you have to disable the clock, to write to any PWM register, that isn’t buffered. Most registers are buffered, and you can write, but some (such as the chopper aren’t). Without being able to unlock and lock the clocks, these registers can’t be written to.
Now the linux kernel can write to this register. I tried looking into why, all I’ve found so far is in : pwm-tiehrpwm.c which calls clock_enable and line 319, that I think is what is changing this register.
Problem here is this is really deep in how the am33xx chips work, and how the kernel does it. Texas Instruments effectively controls both, so I suspect they are the only ones that know the solution. At lest Texas Instruments is responsive.
Will they ever share the solution? Why not through an overlay give an option to enable the clocks. I suppose we could call a script or something at boot time to start the PWM clocks, some option in the uEnv.txt maybe.
Well its probably in the TRM somewhere - the TI TRM are fairly good in that respect, but where in the TRM is tricky. I’m usually fairly good at knowing when to look in the TRM, as I’ve done it so much - that said though this one has me stumped. I can’t see how the kernel can lock it, so suspect the lock is in hardware - but not been able to find any documentation that tells me what to do …
I used google/gemini AI to help me, without any success. They were helpful with correcting some statements in my EHRPWM code. I am now in the process of writing a small C/C++ code that starts the clocks in the PWM’s using writes to /dev/bone/pwm0/a to set the period to some value then enabling with the duty_cycle left at 0 (default). Then calling that function from uEnv.txt. Let you know how that goes.