PocketBeagle适配MCP3204 ADC设备树覆盖层加载报错排查求助
Hey there, let's work through this frustrating issue together—It’s super annoying when you’ve double-checked the basics (structure, pin offsets, mux values) and still hit errors loading your overlay. Let’s break down the key steps to narrow down the root cause:
First, Share Critical Details
Before diving deeper, it’ll be impossible to pinpoint the issue without two key pieces of info:
- Your full device tree source (.dts) file—even small typos in property names or node paths can break things.
- The exact error messages from
dmesg—look for lines mentioningbone_capemgr,spi, ormcp3204specifically. These messages will tell us if it’s a binding mismatch, resource conflict, or overlay formatting error.
Step-by-Step Troubleshooting Checks
1. Verify SPI Controller & Bus Availability
MCP3204 relies on an SPI bus, so first confirm the PocketBeagle’s SPI controller you’re targeting is enabled:
- Check if the SPI device nodes exist:
ls /dev/spi* - List loaded overlays to spot conflicts:
cat /sys/devices/platform/bone_capemgr/slots
Look for any overlays that might be using the same SPI controller or pins as your MCP3204 setup.
2. Double-Check Device Tree Binding Properties
The kernel’s MCP3204 driver (spi-mcp3x0x.c) expects specific properties—even a minor mistake here will prevent matching:
compatible: Must be exactlymicrochip,mcp3204(older kernel versions might use justmcp3204—verify by checking your kernel’s driver source).reg: Sets the SPI chip select (CS) line (e.g.,<0>for CS0,<1>for CS1).spi-max-frequency: Match this to the MCP3204’s specs (max 10MHz, but start lower like 1MHz if you’re testing).vref-supply: Ensure this points to a valid 3.3V power node in your PocketBeagle’s base device tree (e.g.,&vdd_3v3—if it doesn’t exist, you may need to define a simple regulator node).
Example correct node structure:
/dts-v1/; /plugin/; #include <dt-bindings/pinctrl/am33xx.h> #include <dt-bindings/gpio/gpio.h> / { compatible = "ti,am335x-pocketbeagle", "ti,am33xx"; fragment@0 { target = <&spi1>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <&spi1_pins>; status = "okay"; mcp3204@0 { compatible = "microchip,mcp3204"; reg = <0>; spi-max-frequency = <10000000>; vref-supply = <&vdd_3v3>; }; }; }; fragment@1 { target = <&am33xx_pinmux>; __overlay__ { spi1_pins: spi1-pins { pinctrl-single,pins = < 0x190 0x30 /* SPI1_SCLK, MODE0, PULLUP */ 0x194 0x30 /* SPI1_D0 (MISO), MODE0, PULLUP */ 0x198 0x10 /* SPI1_D1 (MOSI), MODE0, NO PULL */ 0x19c 0x30 /* SPI1_CS0, MODE0, PULLUP */ >; }; }; }; };
3. Validate Pin Multiplexing & Status
Even if you think your mux values are correct, confirm the hardware is actually using them:
- Check the pin status with:
cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins - Look for your SPI pins (e.g., SPI1_SCLK is pin
0x190in the am335x pinmux) and verify theirmux_regvalue matches what you set in the overlay, and that they’re not claimed by another device.
4. Check Overlay Loading Mechanics
- Ensure you compiled the overlay correctly with
dtc:dtc -O dtbo -o mcp3204-overlay.dtbo -b 0 -@ mcp3204-overlay.dts - When loading, use the exact path to your dtbo file, and check the capemgr output:
Then runcp mcp3204-overlay.dtbo /lib/firmware/ echo mcp3204-overlay > /sys/devices/platform/bone_capemgr/slotsdmesg | grep bone_capemgrto see if it reports an override, missing dependencies, or a format error.
5. Kernel Version Compatibility
Older Linux kernels might not support the microchip,mcp3204 compatible string. Check your kernel version with uname -r, then look up the spi-mcp3x0x.c driver source for that version to confirm the expected compatible values. If needed, adjust your overlay’s compatible property to match.
内容的提问来源于stack exchange,提问作者Billy Kalfus

