• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 1683 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM437X: GPO pin undefined until PRU starts

Puneeth Bandikatla
Intellectual 715 points

Part Number: PROCESSOR-SDK-AM437X

Tool/software: Linux

Hi

In dts we specified Direction as Output and PULLDOWN for PRU-GPO pin, Direction is set properly but apparently there is no effect of PULLUP/PULLDOWN.

                     0xec  ( PIN_OUTPUT_PULLDOWN | MUX_MODE5 ) /* (A24) dss_ac_bias_en.pr0_pru1_gpo[9] */

So, We added an external pull-down(2.8KOhm). Now, the pin is low until Linux boots up completely and after that there is no predictable state and it can be either high or low untill pru firmware loads and accesses the PRU-GPO pin.
Can you guide us what is causing this random behavior of the pin even after adding external pull-down(2.8KOhm)

I found a similar issue on community and tried some solutions but no use.
e2e.ti.com/.../1523819
As per solution, Configure the pin as GPIO with PULLDOWN.  When ever PRU Application is about to start, Configure the pin as PRU output mode. But when i tried to modify of the pin mode using devmem2 it is reverting to mode7(GPIO).

root@am437x-evm:~# devmem2  0x44e108ec 
/dev/mem opened.
Memory mapped at address 0xb6fb8000.
Read at address  0x44E108EC (0xb6fb88ec): 0x08050007
root@am437x-evm:~# devmem2  0x44e108ec w 5
/dev/mem opened.
Memory mapped at address 0xb6f19000.
Read at address  0x44E108EC (0xb6f198ec): 0x08050007
Write at address 0x44E108EC (0xb6f198ec): 0x00000005, readback 0x00000005
root@am437x-evm:~# devmem2  0x44e108ec 
/dev/mem opened.
Memory mapped at address 0xb6f6b000.
Read at address  0x44E108EC (0xb6f6b8ec): 0x08050007

Thanks
  • 0
    TI__Guru** 110370 points
    Hello Puneeth,

    Ok, let's say Linux boots up and the output value goes either high or low. Does the output value stay constant at high or low until the PRU firmware loads? Or does it transition randomly between high and low until the firmware loads?

    My hunch is that the e2e post you referenced is correct: you need to be in a privileged mode of operation to change pinmuxing, so you cannot change pinmuxing from the PRU firmware or from the userspace devmem2. The poster's final solution of writing a kernel driver that changes pinmuxing from GPIO to PRU GPO might be the best solution for your use case.

    Regards,
    Nick
  • 0 in reply to Nick Saulnier
    TI__Guru** 110370 points

    Update: As per the TRM, "R30 may not be initialized after reset. To avoid outside effect, R30 should be initialized before PINMUX configuration."

    One possible solution may be to modify a kernel driver to initialize R30 and then change pinmuxing after Linux is up and running. Readers should note this would only be supported on processors that allowed changing pinmuxing at runtime - so it might work on AM437x, but it would not be feasable for AM57xx. If using the GPIO changed to PRU GPO method used in https://e2e.ti.com/support/arm/sitara_arm/f/791/p/426120/1523819 

    then you may want to look into setting ti,no-reset-on-init in the device tree to make sure the GPIO doesn't change the output value on the pin when it is initialized.

    I'm looking into a second solution, where in uboot you 1) initialize the PRU clocks, 2) initialize R30 to the correct value, and 3) set the pinmux to PRU GPO. If it works, I think this process would also be applicable for AM57xx users.

    Regards, 

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 715 points
    Hi Nick,

    We Resolved the Issue by configuring the pin as GPO with pulldown in dts, Once the Board boots up we are inserting a driver which changes the pin configuration to PRU_GPO.

    Thanks & Regards,

    Puneeth