AM335x PWMSS_CTRL (0x44e10664) locked at 0 under Kernel 6.19.x with exclusive PRU bypass

General Discussion
, ,
1

I am writing an exclusive PRU0/PRU1 application on a BeagleBone Black running Debian 13 with Kernel 6.19.13-bone16. My goal is to completely bypass the standard Linux kernel drivers for epwmss0/1/2, ehrpwm, ecap, and eqep, giving the PRU cores full, exclusive register control via the OCP master port. [1]

While I have successfully disabled the Linux leaf drivers and my PRU core can successfully power up the modules via CM_PER, the Control Module’s Timebase Clock Enable register PWMSS_CTRL (0x44e10664) is completely stuck at 0.

Because PWMSS_CTRL reads back as 0, the internal sub-counters (TBCLK) never spin, rendering the hardware useless for my PRU firmware.

Here is what I have verified and attempted so far:

  1. Overlay Status: The overlay compiles and loads successfully. I can confirm /sys/class/pwm/ is completely empty and no Linux drivers are bound to the hardware addresses. [1]

  2. PRU OCP Access: In PRU C code, I am clearing the standby/idle bits in PRU_CFG_SYSCFG first. The PRU successfully writes 0x02 to CM_PER_EPWMSSx_CLKCTRL and the stabilization loops pass.

  3. The Lockout: Any attempt to modify 0x44e10664 from the PRU or via userspace busybox devmem 0x44e10664 w 7 is silently dropped by the hardware firewall and continues to read back as 0.

  4. Clock Tree Overrides: Attempting to force the ti,gate-clock nodes open inside the overlay fails to toggle the bits:

  5. dts

    &ehrpwm0_tbclk { status = "okay"; };
&ehrpwm1_tbclk { status = "okay"; };
&ehrpwm2_tbclk { status = "okay"; };

    Use code with caution.

  6. Bus Hack Attempt: Changing the parent epwmss blocks to compatible = "simple-bus"; with status = "okay" while keeping the child leaf drivers disabled still leaves PWMSS_CTRL un-allocated at 0.

It seems Kernel 6.x’s active pm_runtime clock gating or ti-sysc interconnect manager is aggressively gating off the Control Module bit shifts because it sees no active ARM kernel consumer.

My questions:

  1. Is there a new kernel boot argument (outside of clk_ignore_unused or iomem=relaxed) required to prevent the kernel from overriding this specific register on Kernel 6.x?

  2. How can I cleanly force the kernel to assert 0x7 to PWMSS_CTRL at boot time while ensuring the underlying platform drivers remain completely unbound from the memory space for exclusive PRU use?

Any insight from the maintainers would be greatly appreciated. Thanks!