Which one should I remove from the device tree for the firmware to control PWM in beagley-ai?

Hello,
I’m working on a BeagleY-AI (AM67A-based) board and I’m trying to control the EPWM1 module (pwm@23010000) directly from the R5 firmware, not from Linux.

Here is the relevant portion of the firmware code I’ve written:

void pwm_config(void)
{
    uint32_t *pwmClk = (uint32_t *)AddrTranslateP_getLocalAddr(0x4300A560);
    uint32_t *pwmMmr = (uint32_t *)AddrTranslateP_getLocalAddr(0x43011064);
    uint32_t *pwmPad = (uint32_t *)AddrTranslateP_getLocalAddr(0x000F419C);
    uint16_t *pwmPtr = (uint16_t *)AddrTranslateP_getLocalAddr(0x23010000);
    
    *pwmClk = 0x02; // Enable module
    *pwmMmr = 0x1;  // CTRLMMR_EPWM1_CTRL
    *pwmPad |= (1 << 6) | (1 << 15);   
    *pwmPad &= ~(1 << 18); // input buffer off, pull off
    *pwmPtr = (*pwmPtr & ~((0x7 << 10) | (0x7 << 7) | (0x3 << 0))) | ((0x6 << 10) | (0x0 << 7) | (0x3 << 0)); // TBCTL
    *((uint8_t *)pwmPtr + 0x2C) = 0x60; // AQCTLA

    DebugP_log("pwm config done\r\n");
}

void pwm_ctrl(int state, double hz)
{
    uint16_t *pwmPtr = (uint16_t *)AddrTranslateP_getLocalAddr(0x23010000);
    
    if(state) {
        uint16_t val = (uint16_t)(6250000. / hz);
        *((uint8_t *)pwmPtr + 0x0A) = val;      // TBPRD
        *((uint8_t *)pwmPtr + 0x16) = val / 2;  // CMPA
    } else {
        *((uint8_t *)pwmPtr + 0x16) = 0;        // CMPA = 0 → off
    }
}

Problem
Even though I directly access the PWM registers, values like CMPA and TBPRD are not reflected, and no PWM output is generated.
I tried setting status = "disabled" for the pwm@23010000 node in the device tree, but this alone does not release control to the firmware.
There is no PWM overlay loaded, so the device tree is not extended in that way either.

Questions

  1. In order to fully control PWM from R5 firmware, which node(s) or properties must be removed from the Linux device tree?
  2. Is setting status = "disabled" not enough to release the hardware ownership?
  3. Do I need to remove or override clocks, power-domains, or other resource entries to prevent Linux from holding them?
  4. Are there any specific conditions required for firmware to gain access to the EPWM registers and start generating signal?

Any insights or suggestions would be greatly appreciated.

Thanks in advance!

1 Like

You might have to write directly to the registers, just keep in mind this will make your system a train wreck in motion. If you find a solution for this please post and ping me.