Board: BeagleBone Black
Old image: Debian 10 (P9_19 toggled fine but with config-pin)
New image: Debian 13 (P9_19 won’t toggle)
What I need: treat P9_19 as a generic GPIO I can set 0/1 in userspace.
What works vs what doesn’t
- P8_33 (another GPIO I also use): works on Debian 13 and I can toggle it normally.
- P9_19: does not move on the logic analyzer on Debian 13 (it used to on Debian 10).
I used the same .c to configure them, so I suspect pinmux on P9_19 in Debian 13.
Userspace API I’m using (libgpiod v2)
// exactly what my app does today
chip_RS485_RTS = gpiod_chip_open_by_number(3);
line_RS485_x_RTS = gpiod_chip_get_line(chip_RS485_RTS, 13);
ret = gpiod_line_request_output(line_RS485_x_RTS, "RS485_1_RTS", 0);
/* later */
int rc = gpiod_line_set_value(line_RS485_x_RTS, 1);
rc = gpiod_line_set_value(line_RS485_x_RTS, 0);
Is there any problem with this API on Debian 13? (Again: this same code works for P8_33 on Debian 13, and P9_19 on Debian 10.)
gpioinfo (Debian 13) — gpiochip3
gpiochip3 - 32 lines:
line 9: "P8_33 [lcd d13]" output consumer="RS485_2_RTS"
...
line 12: "P9_20 [i2c2_sda]" input
line 13: "P9_19 [i2c2_scl]" output consumer="RS485_1_RTS"
line 14: "P9_26 [uart1_rxd]" input
line 15: "P9_24 [uart1_txd]" input
...
Even though P9_19 shows up as output, I doesn’t change polarity like P8_33.
Quick tests I tried
- gpioset (options first, as required by my version):
systemctl stop app_manager.service
killall gpioset || true
gpioset -z -c /dev/gpiochip3 13=0
gpioset -z -c /dev/gpiochip3 13=1
→ nothing on the logic analyzer (P9_19 stays flat).
- Through sysf:
sysfs mapping on this image shows:
/sys/class/gpio/gpiochip608 -> ...44e07000.gpio (GPIO0)
/sys/class/gpio/gpiochip512 -> ...4804c000.gpio (GPIO1)
/sys/class/gpio/gpiochip544 -> ...481ac000.gpio (GPIO2)
/sys/class/gpio/gpiochip576 -> ...481ae000.gpio (GPIO3)
So P9_19 = GPIO0_13 = 608 + 13 = 621. Forcing via sysfs:
echo 621 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio621/direction
echo 0 > /sys/class/gpio/gpio621/value
echo 1 > /sys/class/gpio/gpio621/value
→ still no movement on the logic analyzer.
Boot overlays I’m using (U-Boot)
uEnv.txt has (summarized):
enable_uboot_overlays=1
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr4=/lib/firmware/GTW-UTN-00A0.dtbo
uboot_overlay_debug=1
I wrote a tiny custom overlay that just sets P9_19 pad (I2C2_SCL at offset 0x17C) to mode7 (GPIO):
/dts-v1/;
/plugin/;
/{
compatible = "ti,beaglebone", "ti,beaglebone-black";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
rts_p9_19_pins: pinmux_rts_p9_19_pins {
pinctrl-single,pins = <0x17C 0x07>; /* P9_19 as GPIO */
};
};
};
};
Compiled with:
dtc -@ -I dts -O dtb -o /lib/firmware/GTW-UTN-00A0.dtbo GTW-UTN-00A0.dts
Even with this DTBO listed in uEnv.txt, after reboot P9_19 still looks like [i2c2_scl] input and won’t toggle physically. (I also tested a variant with a gpio hog using &gpio0 13, and another that disables &i2c2 — still no change on the pin.)
What I’m asking
- Is the pinmux offset/mode for P9_19 correct on AM335x? (I2C2_SCL = 0x17C, mode7 = 0x07).
- Is there a standard overlay (DTBO) in current Beagle Debian 13 that already sets P9_19 as GPIO (mode7) while keeping UART1 (P9_24/26) active? If yes, what’s its name so I can just drop it into
uboot_overlay_addrX=? - Could any built-in overlay/device be re-applying I²C2 on P9_19 after my DTBO, effectively winning the mux? If so, what’s the proper order or recommended override to make P9_19 stay as GPIO?
- Is
uEnv.txtreliably read from/boot/uEnv.txton these images, or should I edit/boot/firmware/uEnv.txtinstead? (I setuboot_overlay_debug=1; the boot log claims my DTBO loads.) - Any known gotchas on Debian 13 that would prevent P9_19 from being driven as GPIO from userspace, while P8_33 in the same app still works?
Thanks! I’m happy to post boot logs / gpioinfo dumps if needed. Once P9_19 muxes to GPIO again, the rest of my application works as before.
