01:05 <set_> whatever happened to the PWM peripheral on the am335x w/ the BBB?

01:12 <set_> Just some background...

01:13 <set_> I looked through u-boot, the fs on the actual board, and the .dtsi/.dts files.

01:18 <set_> I found it on am335x-boneblack.dts but my pwm files are not around...

01:19 <set_> the am335x-boneblack.dts I found is located in the kernel, though. Hmm.

09:02 <Tamarinen> I have a PRU problem. I'd like to read a non-PRU GPIO pin using PRU 1. That should be doable via OCP, but when I try, the PRU locks up. It can be stopped and started, but won't accept new firmware until reset using prudebug.

09:03 <Tamarinen> Code TL;DR:

09:03 <Tamarinen> config-pin P9_22 gpio

09:03 <Tamarinen> / Base address and offset for GPIO0

09:03 <Tamarinen> #define GPIO0 0x44E09000

09:03 <Tamarinen> #define GPIO_DATAIN 0x138 // Offset for reading GPIO data

09:03 <Tamarinen> / Address for GPIO0 data input

09:03 <Tamarinen> #define GPIO0_DATAIN (GPIO0 + GPIO_DATAIN)

09:03 <Tamarinen> / Pointer to GPIO0 data input register

09:03 <Tamarinen> volatile uint32_t *gpio0in = (volatile uint32_t *)GPIO0_DATAIN;

09:03 <Tamarinen> / And here the PRU comes to a screeching halt:

09:03 <Tamarinen> if (*gpio0in & P9_22) {

09:03 <Tamarinen> Full example available at https://columbiegg.com/gone/20241113/ocp.html .

09:05 <Tamarinen> I've tried usin gpio2 instead, with the same result. I suspect I don't treat the OCP correctly, and something doesn't translate as it should there, but I haven't been able to find examples reading GPIO pins, just writing them.

16:14 <dinuxbg> Tamarinen: You need to allow OCP access to PRU. Something like: CT_CFG.SYSCFG_bit.STANDBY_INIT = 0

16:14 <dinuxbg> Tamarinen: I've published an example using "SoC GPIOs" here: https://github.com/dinuxbg/pru-gcc-examples/tree/master/hc-sr04-range-sensor

16:15 <Tamarinen> Excellent, I'll take a look right away.

17:30 <Tamarinen> dinuxbg: It doesn't lock up anymore, thanks a lot! Would have taken me ages to find that out myself.

17:34 <Tamarinen> Now I'll have to find out why it doesn't seem to react to P9_22 going low. I suspect it is because gpioinfo says it is in use, and what is using it is probably UART2, which according to Internet wisdom should be possible to disable by not enabling the universal cape in uEnv.txt. Doesn't seem to make any difference, though. Maybe I'll have to mess with the dtbs to disable it and free that pin for gpio use?

20:01 <dinuxbg> Tamarinen: There used to be a user space tool to configure pinmux. Check if this works: sudo config-pin P9.22 gpio_input

20:03 <dinuxbg> But yes, you are correct that the proper method to disable UART2 and tweak the pin-ctrl would be DTS.