Hey Adrian, let's figure out why your PRU pinmux changes aren't showing up in the pingroups output. I've run into this exact issue with BeagleBone Black before, so here are the most likely fixes to walk through:

1. First, Confirm Your Modified DTB Is Actually Being Loaded #

Compiling the DTS successfully doesn't guarantee the kernel is using your new device tree. Let's verify:

• Check which DTB the system loaded at boot:

  cat /proc/device-tree/model
  # Then cross-check this with the filename of your compiled DTB in /boot/
  

• Open /boot/uEnv.txt and make sure the dtb= line points to your modified DTB file (not the stock one). If you're using a device tree overlay (dtbo), ensure no overlays are overriding your PRU pin assignments—check loaded overlays with:

  cat /sys/devices/platform/bone_capemgr/slots
  

2. Fix Your DTS Syntax & Pin Group Binding #

PRU pins belong to dedicated pin groups tied to the PRUSS subsystem, so you need to bind your pinmux config directly to the pruss node, not just define the pins. Here's the correct structure for your pins (double-check the register offsets and mux values against the AM335x TRM):

&am33xx_pinmux {
    pru0_pins: pinmux_pru0_pins {
        pinctrl-single,pins = <
            0x150 0x55  /* P9_24: PRU0_R30_0, MUX5, pull-up enabled */
            0x154 0x55  /* P9_26: PRU0_R30_1, MUX5, pull-up enabled */
            0x158 0x55  /* P9_27: PRU0_R31_0, MUX5, pull-up enabled */
            0x15c 0x55  /* P9_30: PRU0_R31_1, MUX5, pull-up enabled */
        >;
    };
};

&pruss {
    pinctrl-names = "default";
    pinctrl-0 = <&pru0_pins>;  /* Bind the pin group to PRUSS */
    status = "okay";            /* Ensure PRUSS is enabled */
};

• The 0x55 value breaks down to: MUX mode 5 (0x5), pull-up enabled (0x10), and pull enable bit set (0x40)—this matches the AM335x pinmux register format.
• If you're using PRU1 instead of PRU0, use pru1_pins and the corresponding PRU1 signal names.

3. Check for Conflicting Pin Assignments #

Other subsystems (like GPIO, SPI, or I2C) might be grabbing those pins first. To check:

• Look up the current pin configuration for your target pins:

  cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinconf-pins | grep -E "150|154|158|15c"
  

  The hex value at the end should match your 0x55 (or whatever mux config you set). If it's different, another device is using the pin.
• Check if any GPIO drivers are claiming the pins:

  ls /sys/class/gpio/ | grep -E "gpio46|gpio47|gpio44|gpio45"
  # These are the GPIO numbers for P9_24, P9_26, P9_27, P9_30 respectively
  

  If they exist, you'll need to disable the GPIO assignment in your DTS or overlays.

4. Make Sure PRU Support Is Enabled in the Kernel #

Even with correct DTS changes, the PRU subsystem won't initialize if it's disabled in the kernel:

• Verify the kernel config:

  zcat /proc/config.gz | grep CONFIG_PRU_ICSS
  

  It should return CONFIG_PRU_ICSS=y or CONFIG_PRU_ICSS=m. If it's m, load the module with modprobe pru_rproc.

5. Check the Right Pinctrl Node for Pingroups #

Pin groups tied to the PRUSS might not show up in the main 44e10800.pinmux node—they're often registered under the PRUSS's own pinctrl context. Use this command to find and check the correct node:

PRUSS_PINCTRL=$(grep pruss /sys/kernel/debug/pinctrl/*/name | cut -d/ -f6)
cat /sys/kernel/debug/pinctrl/$PRUSS_PINCTRL/pingroups

Your pru0_pins group should appear here if the binding worked.

内容的提问来源于stack exchange，提问作者Adrian Peniak